长程智能体的可靠性还没有到位。WeaveBench 这个专门用来测试长程智能体能力的基准目前表现最好的模型也只拿到了 41.2% 的成绩。这个数字放在当前大模型集体“卷”能力的背景下显得很刺眼。很多人看到这类分数第一反应是“哪个模型最强”。但如果你真的做过 Agent 落地就会明白这个数字背后的信息量远不止排名。它不是模型聪明不聪明的问题而是我们离“让智能体可靠地完成长任务”这件事还有相当距离。1. 长程智能体为什么这么难做问题不在单步在全程先把这个概念拆开。长程智能体指的是需要连续执行多个步骤、跨越多个工具或环境、最后完成一个复杂目标的智能体系统。和单轮问答不同长程任务的典型特征是步骤多、依赖长、中间状态会累积错误。1.1 单步能力再强也扛不住长链路消耗我经常用一个比喻来解释这个问题你让一个实习生去办一件事如果他只做一步比如查个资料大概率能办得不错但如果你让他负责一个跨三个部门、需要五轮沟通、还要在截止日期前完成的项目哪怕他每一步都只出 5% 的偏差最后的结果也可能完全跑偏。长程智能体的处境和这个实习生非常像。每一步都需要依赖前一步的输出前一步的错误如果不被及时纠正后续所有步骤都建立在错误的基础上。到第 10 步的时候这个系统可能已经在沿着一个完全错误的方向执行任务但它自己浑然不觉。这就是为什么长程任务的得分普遍低于短程任务——不是模型能力不够而是错误沿着链条不断放大。1.2 长程任务的三个“看不见”的难点从工程实践看长程智能体真正难的地方有三个状态维护它必须记住自己已经做了什么、还差什么、当前处于整个流程的哪个位置。上下文一长最早的信息往往被稀释甚至被遗忘。错误恢复它做错一步之后能不能发现问题、回退、修正还是说继续硬着头皮往下做后一种情况在真实系统里极其常见。任务分解与验证它是否知道自己每一步做完之后结果对不对如果中间没有可验证的中间目标它就只能在黑暗中摸索。这三个问题每一个都不是单靠“把模型换个更大的”就能解决的。所以 WeaveBench 的 41.2% 并不是一个惊喜它只是把这块短板明明白白地摆了出来。2. WeaveBench 在测什么不是智商测试而是“长时间工作可靠性”测试现在需要认真看一下 WeaveBench 这个基准本身。从命名和当前信息结构看它面向的核心是“长程智能体”核心指标落在“可靠性”上。2.1 这类基准和传统评测有什么不同传统评测更像是考试。给模型一个明确的问题人工或模型判断答案对不对。这种模式下模型只需要在给定上下文里完成一次推理不存在长链路积累的问题。长程基准则更像是“实习期考核”。会让模型在一个多步骤任务环境里自己规划、执行、校验中间还要调用工具、读取反馈、修正方向。它测的不是“知不知道答案”而是“能不能在一段时间里稳定地把一件复杂事情做完”。这就让评测结果的解释方式完全不同了传统评测得高分说明模型知道得多、推理能力强。长程基准得低分说明的是在真实执行流程中模型的稳定性、纠错能力和长期规划能力还没有达到可靠水平。所以 41.2% 这个数字更准确的理解应该是即使在最优配置下长程任务依然有接近六成的概率会在某个环节出问题。这是一个可靠性数字不是一个智力数字。2.2 最佳 41.2% 说明什么当前技术路线还没跨过可靠性门槛这个“最佳”值得留意。它意味着不是某个模型特别拉胯而是当前这个技术方向上所有模型的表现都还处于比较早期的阶段。从常见工程经验看一个基准上如果最佳成绩在 80% 以上通常意味着这个方向已经有相对成熟的解法如果最佳成绩停留在 40% 左右则说明大家还在“能跑通”和“能不能稳定跑通”之间挣扎。这也回应了一个很多人关心的问题为什么一些长程 Agent 演示看起来很惊艳推广到真实业务里就频繁翻车因为在演示环境里路径是设计好的反馈是干净的模型只需要沿着可控路径走一遍而在真实场景里用户输入是杂乱的、工具反馈是有噪音的、环境状态是动态变化的长程系统的可靠性短板就会被彻底暴露。提醒不要因为一个长程智能体在某几个演示任务上表现出色就默认它可以在生产环境里长期稳定运行。演示测的是上限生产环境考验的是平均可靠性。3. 从 41.2% 往回看长程智能体离落地还有几块拼图既然分数不高那问题出在哪从目前的技术结构和工程实践来看差距主要体现在四个具体层面。3.1 规划层模型“想得远”但往往“想不细”长程任务需要先做出一个合理的整体规划。这要求模型对任务目标、可用工具、环境约束有全局理解。但当前很多模型在做长程规划时容易出现一个问题大方向对细节经不起推敲。它能说出“第一步做什么、第二步做什么”但具体到第二步的输入格式、工具返回值的处理方式、异常分支的应对往往规划得不够细致。这就导致执行到中间步骤时需要临时应对的情况远超规划范围。3.2 记忆层中间状态容易丢失上下文一旦变长就“失忆”我前面提到长程任务的核心是状态维护。一个执行了 20 步的任务模型需要清楚地知道最初的目标是什么。已经完成到哪一步。哪些中间结果是可信的。哪些步骤产生了副作用。这些信息都要放在上下文里。但模型对长上下文的利用效率并不像理论容量那样乐观。上下文过长时早期关键信息被稀释或被忽略是实际评测中很容易观察到的问题。这也解释了为什么很多长程任务越到后面越容易出现“偏离原始目标”的情况——不是模型突然变笨而是它把起点和约束条件弄丢了。3.3 工具调用与反馈校验会用工具但不会判断工具结果长程智能体几乎必然要调用工具查数据库、发请求、读写文件、执行脚本。这一层最大的问题不是“能不能调用”而是“拿到结果之后怎么处理”。很多系统在正常情况下可以把工具调用做对但一旦工具返回异常内容、超时、格式不符合预期系统就会陷入迷茫。它倾向于继续尝试而不是停下来检查原因。这就像一个人在路上走遇到路障时不是停下来看地图而是继续往前开结果越偏越远。3.4 纠错机制当前系统的短板中的短板真正可靠的长程智能体必须在不完美执行的过程中主动纠错。它要能发现自己的错误、判断错误类型、选择回退或修正策略。但这一点恰恰是当前最欠缺的。从很多评测案例看当模型做出一个错误决策后它有很大概率会在后续步骤中不断巩固这个错误甚至生成一套听起来很合理但已经偏离目标的解释。这种“一本正经地做错事”的行为本质上是因为模型缺少可靠的中间验证机制。从工程角度看长程智能体落地的关键不是把每一步都做到 100% 正确而是在出错之后能及时发现、及时止损、及时修正。4. 长程可靠性为什么难提升三个层面各有各的难处4.1 数据层长程任务的训练数据本来就稀缺要让模型学会长程任务需要大量“长轨迹”数据一个任务从开始到结束的完整执行记录包括中间的错误、重试和修正过程。但这类数据在互联网上很少人工标注成本又极高。相比之下短问答的数据几乎取之不尽而长程执行数据则必须靠合成、仿真或人工搭建环境来生成。数据量不足直接限制了模型的训练上限。4.2 评测层很多现有基准存在“任务套路化”问题另一个被低估的问题是评测本身的干扰。如果长程基准里的任务一旦被模型“记住”或“猜中规律”那么评测分数就会虚高失去对真实可靠性的反映能力。这也是 WeaveBench 这类新基准出现的意义所在它试图用更严格、更接近真实执行环境的方式重新校准我们对智能体能力的认知。即便它的绝对分数不高它提供的这个参照系本身对行业判断“长程智能体到底发展到什么程度了”是有价值的。4.3 模型层推理、记忆、规划是三个引擎但协同还不到位长程任务同时需要推理能力、长上下文记忆能力、任务规划能力和工具交互能力。这些能力在单独任务中都能表现良好但在长程协同场景里相互之间容易出现优先级冲突。比如模型在规划时过于关注细节反而忽略了整体进度或者在记忆回溯时耗费了太多上下文空间导致后续执行空间不足。这不是某一个模型独有的问题而是当前架构下比较普遍的现象。5. 作为开发者和使用者我们应该怎么看这个数字5.1 判断基线不同使用场景对可靠性的容忍度完全不同41.2% 这个数字如果放到不同场景里含义是不一样的。如果你只是做一个研究 Demo或者内部探索性工具40% 左右的成功率是可以接受的因为它可以展示能力方向。如果你要做一个面向客户的自动化流程比如自动处理工单、自动生成报告、自动操作业务系统那 41.2% 还远远不够。因为每两次执行就有一次会失败这个失败率对任何业务来说都是不可接受的。所以长程智能体的应用边界不是由模型能力单独决定的而是由“失败代价”决定的。失败代价越高对可靠性的要求就越高对当前这类系统的接受度就越低。适合优先尝试长程智能体的场景建议选择低风险、高重复、结果可人工复核的内部工具型任务。先把流程跑通再逐步扩大范围不要一开始就交给它面向客户的完整业务。5.2 实践建议从“模型为中心”转向“流程为中心”普通使用者很容易把长程智能体当成“只要模型够强就能自动完成一切”。但工程经验告诉我更稳妥的思路是把长程任务设计成多个可校验的短程节点然后用流程控制来减少模型自由发挥的空间。具体做法可以是降低任务长度把一个 20 步的长任务拆成 4 个 5 步的子任务每完成一个先做结果校验。引入人工闸点在关键步骤之后设置人工确认环节避免错误一路滚下去。限定工具返回格式让工具返回尽量规范、可解析的内容降低模型处理异常的能力要求。记录轨迹日志长程任务执行时记录每一步的输入、输出和决策依据出了问题可以回溯定位。小样本试运行先跑 20 条测试任务统计失败模式找到最集中的失败环节再针对性优化。这些方法不会把 41.2% 直接改写成 100%但会显著提高你在真实业务中使用长程智能体时的下限。6. 写在最后长程智能体还有很长的路但这段路值得走WeaveBench 最佳 41.2% 的成绩可以被理解成一次清醒的提醒我们对大模型能力的感知很大程度上是被短程任务的高分“惯”出来的。长程执行要进入生产环境还需要跨过可靠性这道坎。但反过来看这个数字也不代表这条路走不通。它只是说明当前这个阶段的长程智能体更像是“能做事但还不能稳定交付”的初级员工需要一个成熟的管理框架来配合它工作。把任务拆小、把校验做细、把失败处理写进流程这些工程手段短期内比单纯换一个“更聪明”的模型更可靠。如果你准备开始尝试长程智能体我的建议很简单先别追求一步到位挑一个低风险、边界清晰的内部任务跑起来重点观察它在第几步开始出错、以什么方式出错、能否及时发现并纠正。把这些观察记录下来你就能比只看评测分数的人更清楚地知道长程智能体现在到底能做什么不能做什么。