1. 先说结论长程智能体真正缺的不是“能跑”而是“跑得稳”长程智能体Long-Horizon Agent是当前大模型应用落地里最常被提起、也最难真正兑现的概念之一。它要解决的问题很具体让智能体不是只回答一个问题、执行一次工具调用而是能连续完成十几个、几十个步骤的任务比如整理一份跨多平台的数据报告、对接多个业务系统完成一整套流程、或者在长文档体系里完成检索、归纳、校验和输出。这类任务真正的难点不在于单个步骤的模型能力而在于整个链条的可靠性。任何一步判断错误、工具调用失败、输入格式偏差都会在后面的步骤里被放大。更麻烦的是长程任务的错误往往不是当场报错而是等任务跑到最后你才发现中间某一步拿到的数据本身就是错的。这种“延迟暴露”的问题比单纯的报错难排查得多。WeaveBench 就是一个专门用来评估这种长程可靠性的测试集。从我的角度看这个基准最值得关注的不是“哪个模型能跑通”而是它给出了一个很扎眼的数字最佳方案也只有 41.2%。这意味着目前没有哪个模型或框架敢说自己已经解决了长程智能体的稳定性问题。41.2% 这个成绩放在单轮问答或短链路工具调用上可能还算能接受但放到真实业务环境里基本等于每 5 个长程任务里有 3 个会在中途出错、跑偏、或产出不可信结果。这篇文章不打算重复评测报告里的排名表而是想拆开来讲为什么长程智能体的成绩普遍偏低WeaveBench 这种基准到底在考察什么以及如果你想做长程智能体的开发、评测、或者生产落地应该从哪里入手。2. 先把长程智能体的“可靠性”拆成四个可验证的层面很多人一提到长程智能体第一反应是“模型要会规划”。这没有错但规划只是起点。真正决定一个长程任务能不能稳定跑完的是下面四个层面是否同时可靠。2.1 任务拆解层模型能不能把大目标拆成可执行的小步骤长程任务的第一步往往是任务规划。模型要把“帮我整理一份关于某行业近三年的政策变化报告”这样的模糊目标拆成“确定时间范围、检索政策来源、筛选相关条目、按时间线整理、核对引用来源、生成输出文件”等具体步骤。这一层看起来简单实际最容易出问题。因为任务拆解不是把一句话变成几个动作就结束了而是要保证步骤之间有正确的依赖关系。有些步骤必须串行比如先检索再归纳有些步骤可以并行比如同时查多个数据源有些步骤需要回退比如检索结果不足时要调整关键词重新检索。模型如果在这个阶段就漏掉关键环节后面所有步骤都会白跑。WeaveBench 的测试设计里很大一部分考察的就是这种拆解能力。但要注意拆解能力强不等于任务能成功。很多模型能列出看起来合理的步骤实际执行时却在某一步拿不到预期输入或者中间某一步的输出格式和下一步的预期不一致整个链条就断掉了。2.2 工具调用层每一步调用是否参数正确、返回可处理长程智能体几乎一定会依赖外部工具比如搜索接口、数据库查询、文件读写、代码执行、内部 API 等。工具调用层面的可靠性主要体现在三个方面。第一是参数传递。模型需要根据当前任务状态生成正确的工具参数包括查询关键词、筛选条件、页码、文件路径等。参数错误是长程任务里最常见的失败原因之一而且很多错误不在报错信息里而是工具返回了空结果或错误结果模型却没有发现。第二是返回结果处理。工具返回的数据可能是 JSON、纯文本、表格、HTML、或错误码。模型需要正确解析这些数据并把有用信息提取出来放到记忆里。很多长程任务失败并不是工具没有返回数据而是模型没有把返回结果正确写入下一步的上下文。第三是异常处理。工具调用有可能超时、限流、返回格式变化、或者出现临时性错误。可靠的智能体应该能识别这类异常并采取重试、降级、或向用户请求确认等策略。目前大多数长程智能体在这方面的能力还比较弱一旦遇到非预期返回整个任务就容易卡死。2.3 状态管理层多步任务之间如何保存、更新、使用中间信息单工具调用不需要太多状态管理但长程任务里模型需要持续跟踪“到目前为止完成了什么、下一步还需要什么、哪些信息是可信的、哪些需要再次验证”。这一层目前最能拉开差距。有些模型每执行完一步就把结果原封不动地堆到上下文里导致上下文越来越长、关键信息被淹没有些模型会把中间结果整理成结构化摘要但摘要过程本身可能丢失重要细节有些模型引入了外部记忆模块但记忆的写入、读取、更新策略还不成熟。状态管理的失败模式很隐蔽。比如模型在第五步需要用到第二步的结果但第二步的结果在后续步骤中被覆盖了或者被摘要压缩得只剩一个模糊结论第五步就会基于不完整信息继续执行。最终结果看起来格式完整实际上内容已经偏离原始事实。2.4 自我校验层模型能否发现错误、及时回退、给出可信输出长程任务里错误几乎不可避免。关键是有没有校验和纠正机制。目前很多长程智能体的做法是“一口气跑到底”中间不做校验直到生成最终输出。这种方式在短任务里问题不大但在长任务里风险极高。一个数值引用错误、一个文件路径写错、一个筛选条件偏差会在最终结果里被当成正确内容输出。更好的做法是在关键节点加入校验步骤比如“检查当前收集到的数据是否覆盖了所有子问题”“对比两个数据源的结果是否一致”“确认最终输出里的引用是否都能追溯到原始材料”。这种校验会增加额外开销但对于可靠性优先的场景这是必须付出的代价。WeaveBench 把评估重点放在这些层面说明它想要捕捉的不是“模型有多聪明”而是“模型在真实长链条任务里有多靠谱”。理解了这一点再看 41.2% 的最高成绩就不会觉得意外了。3. WeaveBench 到底怎么测又是怎么暴露长程问题的要判断一个基准分数有没有参考价值最好先搞清楚它的测试流程和判定方式。WeaveBench 的设计思路和常见的单轮问答、多轮对话评测不太一样它更偏向“完整任务执行”的视角。3.1 多阶段任务的串联方式每个步骤都在给下一步埋雷或铺路WeaveBench 的任务不是孤立的单轮问题而是把任务拆成多个阶段前一阶段的输出会成为后一阶段的输入。比如一个任务可能是“从多个文档中检索指定信息然后基于检索结果生成汇总再对汇总内容进行事实核查最后输出一份带引用的报告”。这种串联方式最大特点是错误会传播。第一阶段如果漏掉了一条关键信息第二阶段无论如何优化 prompt 都补不回来。第三阶段做事实核查时如果没有外部知识来源它只会检查自身生成内容的一致性而不会发现“引用内容本身就不存在”。这正是长程智能体和普通对话模型的本质区别。对话模型只需要在当前轮次给出合理回复而长程智能体必须保证每一步都在为后续步骤服务。WeaveBench 的串联设计能把这种连续性压力明确地暴露出来。3.2 评测维度不只看到没完成任务更看“做对了哪些环节”只看最终成功率的评测有两个问题。第一它会掩盖部分成功的情况一个任务可能在 80% 的步骤上都做得很好只在最后一步输出格式错误最终被判定为失败。第二它很难告诉开发者具体应该优化哪个环节。从材料来看WeaveBench 的评测维度更细致会记录任务在不同阶段的表现。这种设计对开发者更有价值。因为长程智能体的问题往往不是全局性的而是集中在某个特定环节比如“工具参数生成不准”“中间信息记忆丢失”“多步结果合并时出现重复或遗漏”。我自己做长程任务评测时也习惯把任务按阶段拆开记录成功情况而不是只记录最终结果。原因很简单如果只知道任务失败了排查时就是无头苍蝇但如果知道“前 5 步全部成功第 6 步开始出现信息丢失”你就能直接定位到状态管理模块而不是去改模型 prompt。3.3 最佳 41.2% 到底意味着什么41.2% 这个数字需要放到评测背景里理解。它不是某个单步骤的成功率而是整个长程任务完整成功的比例。也就是说即便模型在绝大多数子步骤上表现良好只要链条中任意一环出错最终任务就可能被判定为失败。这个成绩首先说明长程智能体离“可靠生产”还有相当距离。如果你的业务场景允许人工介入纠错或者单次任务价值不高、失败后重跑成本低那么 41.2% 的模型能力可能还可以接受。但如果你的任务是一次性高价值操作比如自动生成财务分析报告、自动完成多系统数据迁移、自动处理客户全流程请求那这个成功率远远不够。其次这个成绩也说明当前长程智能体的瓶颈不在单一能力上。模型推理能力、工具生态、状态管理机制、评测方法每个环节都有提升空间单独优化哪一项都不足以让整体成绩发生质变。4. 如果我要做一个长程智能体项目会怎样评估和改进可靠性前面讲了 WeaveBench 的评测视角这里把它转换成实际开发中的行动建议。无论你是刚接触长程智能体还是已经在做相关项目下面这套思路都可以复用。4.1 第一步先跑通单链路最小任务再谈复杂场景很多人一开始就把目标定得很宏大比如“让智能体自动完成跨 5 个系统、30 步的完整业务流程”。我建议反过来先设计一个只需要 3 到 5 步、依赖单一工具的最小任务确认整条链路跑通。最小任务的意义不是测试模型能力而是验证你的工程框架是否完备。包括任务如何传入、工具如何注册和调用、中间结果如何存储、最终结果如何输出、各个模块的日志如何串联。如果最小任务都跑不稳定就不要急着加复杂场景。因为复杂场景只会放大基础框架的缺陷而你到时候很难分辨问题出在框架还是出在模型。4.2 第二步为每个步骤设计明确的成功标准长程任务经常出现“看起来在执行实际已经跑偏”的情况。要避免这个问题最好为每个关键步骤预设成功标准。比如检索步骤的成功标准是“返回结果数量大于 0 且与查询主题相关”。如果模型在条件明显不符时仍然继续下一步就说明它在校验能力上存在缺陷。又比如汇总步骤的成功标准可以是“覆盖了输入材料中所有必选条目”。你可以把必选条目提前列出来在汇总完成后自动比对而不是只靠模型自己判断。这些成功标准不需要一开始就非常精细但至少要能捕获明显错误。随着测试用例增多再把标准逐步细化。4.3 第三步把日志当作第一排查工具而不是直接改 prompt长程智能体出问题时开发者最容易犯的错误是直接调整 prompt或者换一个更强的模型。这不一定是错但效率很低因为你没有确认问题到底出在哪一层。正确的排查顺序应该是先看完整日志定位是哪一步开始偏离预期。再看这一步的输入是否来自上一步的错误输出。然后看这一步的工具调用参数是否正确、返回结果是否被正确处理。最后再看模型本身是否在推理或生成阶段出现了问题。很多“模型不够聪明”的情况实际是工具返回数据没有被正确传递或者上一步的摘要丢失了关键字段。这些问题改 prompt 是解决不了的。4.4 第四步加入自动校验和人工抽查的双重机制在开发阶段人工抽查必不可少可以帮你判断错误模式。但一旦进入批量测试或小规模生产人工不可能逐个检查这时候就需要自动校验。自动校验可以放在任务结束后也可以放在关键节点中。常见做法包括输出格式校验日期、数字、引用格式是否符合预期。信息完整性校验任务要求中列出的必答项是否都有对应内容。一致性校验同一信息在不同位置出现时是否互相矛盾。来源校验输出里的引用是否能对应到输入材料。这些校验不一定要很复杂甚至可以用简单的规则实现。但在长程任务里它们能帮你拦截大量明显错误减少最终输出的不可信情况。一下模型本身在推理或生成阶段出现了问题。4.5 第五步用“失败重跑”代替“微调”验证稳定性很多人遇到长程任务失败第一反应是收集样本去微调模型。但长程智能体失败的原因非常分散可能是模型推理、工具异常、输入格式、状态管理、甚至外部服务限流。如果不对错误进行充分分类微调只会让模型记住碎片化的模式很难带来整体提升。更稳妥的做法是先做同一任务多次重跑观察失败是否稳定复现。如果任务时好时坏优先排查外部工具和状态管理如果任务每次都失败在同一个步骤再去考虑调整 prompt、增加校验、或者针对该步骤做专项优化。对于一个连续性差的任务重跑 3 次得到 1 次成功和 10 次得到 9 次成功表面都是“可以跑通”但可靠性差异巨大。WeaveBench 这类基准之所以强调成功率就是因为真正的生产场景需要的是稳定复现而不是碰运气。5. 从 41.2% 反推长程智能体落地到底应该抱有怎样的预期当一个基准显示最佳方案只有 41.2% 时很容易走两个极端。一个极端是全面悲观认为长程智能体完全不值得投入另一个极端是觉得“反正都有 41% 了稍微优化一下就能到 70%”。两种想法都不太准确。5.1 哪些场景现在就可以用哪些还要再等如果目标是高频次、低风险、允许失败后人工补救的任务长程智能体现在就有实际价值。比如自动生成文档草稿、批量处理标准化数据、辅助信息检索和整理。这些场景里智能体跑失败造成的损失可控你可以把人工介入当作兜底。如果目标是低频次、高风险、结果必须精确且不能出错的任务比如自动完成资金操作、自动修改生产环境配置、自动生成对外发布的正式报告那 41.2% 的成功率明显不够。在这些场景里智能体更适合作为辅助工具先给出建议方案和执行步骤再由人工确认后执行。关键是不要拿自己最复杂的业务场景去要求一个还在发展初期的技术。长程智能体的能力边界需要根据实际任务评估而不是只看总分数。5.2 评测分数和真实业务之间有一条“适配鸿沟”WeaveBench 上的 41.2%只能代表它在特定测试集、特定任务设计、特定环境下达到的成绩。真实业务里你的任务类型、工具接口、数据格式、输出要求都和评测集不同实际表现可能高于这个数字也可能远低于这个数字。这也是为什么我不建议直接“引用一个基准分数来决定技术选型”。更合理的做法是把你自己的 3 到 5 个典型任务做成小型测试集跑一遍被评估的模型或框架看看它在你的数据分布上表现如何。这个结果比任何公开榜单都更有参考价值。5.3 未来提升方向不会只靠模型变大从 WeaveBench 暴露的问题来看长程智能体可靠性的提升更可能来自系统工程而不是单纯模型能力升级。具体方向包括更好的任务规划与重规划机制让模型在任务跑偏时能及时回到正轨。更强的状态管理能力比如结构化记忆、关键信息锁定、中间结果版本管理。更可靠的工具调用协议包括参数校验、返回格式约定、自动重试和降级机制。更完善的评测和可观测能力让开发者能够清楚定位每一处失败。如果你的目标是长期做长程智能体方向可以围绕这几个方向积累经验而不是只追着新模型跑。6. 一个更务实的做法先定义“够用”再谈“可靠”最后回到实际决策上。不管 WeaveBench 这个基准以后分数涨到多少都不会自动决定你的项目能不能上线。决定因素只有一个在你的具体任务和容错范围内智能体的表现是否够用。我建议你做一个简单的可靠性评估表把典型任务填入然后从三个维度打分评估维度具体问题最低可接受标准成功率任务完整成功比例是多少比如 ≥ 90% 或 ≥ 60%取决于任务风险失败模式失败是集中在少数几步还是随机分布集中型可以针对性优化随机型需要更全面改进补救成本每次失败需要多少人工介入成本人工成本是否低于手动处理该任务的成本如果成功率达标、失败模式可优化、补救成本可控那么即使模型在公开基准上的分数不高也可以考虑小范围试用。反之如果三个维度里有一个明显不达标就应该继续优化工程能力而不是急着扩大应用范围。长程智能体是一条值得长期投入的路线但它现在明显处于“能力已可见、可靠性仍未至”的阶段。WeaveBench 的 41.2% 不是一个让人绝望的数字而是一个提醒要想把长程任务真正落地除了让模型更聪明更要把任务拆解、工具调用、状态管理、自我校验这一整套工程链路打磨到稳定。单点能力再强链条不稳最后还是会在真实任务里露馅。