之前在做智能体Agent落地的时候我反复卡在一个问题上单次工具调用的准确率已经很高了可一旦任务拉长最终成功率就断崖式下跌。后来看到 WeaveBench 公布的长程智能体评测结果——最佳方案也只有 41.2%——一下把这个问题摆到了台面上。这篇文章就围绕这个评测基准聊聊长程智能体为什么不可靠、问题出在哪、工程上可以怎么改。1. 从存储可靠性测试到智能体可靠性做存储开发的同事经常使用 SSD 读写可靠性测试工具对硬盘做满盘读写、坏块扫描、掉电保护测试。这类工具的核心逻辑是先定义故障模型再通过压力环境把隐藏问题暴露出来。长程智能体靠不靠谱其实也可以用同样的思路来评估。1.1 长程智能体是什么长程智能体并不是一个神秘概念。它指那些需要执行多步推理、多次工具调用并且通常要跨较长上下文窗口来完成任务的 AI 系统。举个典型场景用户让 Agent 帮忙整理一个季度的销售数据。Agent 需要先连接数据库取数再分析汇总再生成表格最后发送到指定邮箱。这个流程看起来不复杂但每一步之间都有依赖关系。第 2 步依赖第 1 步的返回结果第 3 步依赖第 2 步的取数是否完整。任何一步的状态丢失都会导致后续动作偏离预期。我把这类任务称为“过程敏感型任务”。它们和单轮问答完全不同。单轮问答只看回答质量长程智能体看的是“过程是否从头到尾没有出错”。1.2 为什么不能只看单步准确率很多团队在评估 Agent 时习惯先测“工具调用准确率”“指令遵循率”。这些指标单独看可能很高比如模型在测试集上单步准确率达到 95%。但长任务有一个残酷的数学现实如果一条链路需要 20 步每一步成功率都是 95%那么整体成功率大约是 0.95 的 20 次方也就是约 35.8%。如果每一步成功率是 98%20 步整体成功率约为 66.7%。只有做到单步 99% 以上20 步才能勉强超过 80%。这也是为什么 WeaveBench 这类基准出现后行业开始重新审视“智能体是否真的可用”。当我们在讨论“最佳仅 41.2%”时本质上是在说当前最强模型在长程任务上的端到端成功率连一半都不到。1.3 用压测思维理解基准测试SSD 可靠性测试工具有一个特点它不是为了测正常工况而是为了测极端工况。长程智能体评测也一样。WeaveBench 在设计任务时往往会故意增加干扰项、引入长上下文、要求多工具协作甚至安排一些“陷阱步骤”看模型是否能在复杂环境中保持稳定。在工程上我建议每个团队都建立这样一套属于自己的“智能体压测用例”。不要只测模型能力要测“整个链路在压力下是否还能完成”。2. WeaveBench 是什么2.1 评测基准的定位WeaveBench 是一套专门面向长程智能体任务的评测基准。它把“长程任务完成率”作为核心指标用来衡量一个 Agent 在真实业务场景中的可靠性。它和传统评测集不太一样的地方在于任务是多步骤的而不是一问一答。评测环境允许 Agent 调用工具、读写中间状态。判定标准不是“模型说了什么”而是“模型最终是否完成了任务”。评测过程关注完整链路一旦中途出错就算失败。这种设计更接近生产环境。生产环境中没有哪个用户会关心模型中间解释了多漂亮的思路只关心任务是否交付。2.2 任务类型覆盖范围根据公开资料和评测设计思路长程智能体的评测任务通常覆盖几类场景信息检索与整理从多个文档中提取信息并按照指定格式汇总。多轮工具调用调用外部 API、操作数据库、访问文件系统。复杂问题分解把一个复杂目标拆成多个子问题逐步解决。长上下文理解在长时间对话或长文档环境中保持目标不丢失。跨环境操作在不同软件环境之间切换。这些场景对 Agent 的要求不只是“聪明”而是“稳”。2.3 最佳结果只有 41.2% 意味着什么41.2% 这个数字如果放在普通选择题评测里属于不及格水平。但放在长程智能体评测里它反映了当前技术的真实上限。它说明在包含大量步骤、工具调用和状态依赖的任务中即使最优秀的大模型也会因为某一步的状态错误、上下文丢失或工具返回异常最终导致整个任务失败。对做工程的人来说这个数字是坏消息也是好消息。坏消息是现在的 Agent 离“稳定生产”还有距离。好消息是它告诉我们问题在评测中暴露出来了接下来可以去修。3. 41.2% 背后的可靠性缺口3.1 误差累积是最大的敌人长程智能体任务最容易忽略的就是误差累积。想象一个 30 步的任务。假设模型每一步都很稳定单步成功率是 97%。30 步下来整体成功率是 0.97 的 30 次方约 40.1%。这几乎正好对应 WeaveBench 的 41.2% 结果。也就是说即使每一步都“基本靠谱”长任务依然会有很高概率失败。这提示我们只优化模型单步推理能力还不够必须从架构上降低误差累积的影响。3.2 状态不一致导致任务中断很多长程 Agent 失败并不是模型不会推理而是状态不一致。例如第一步生成了一个临时文件路径 /tmp/data_2024.csv。第三步模型又用了一个新路径 /tmp/result_2024.csv。但第二步生成的中间结果实际保存在第一个路径中。模型在第三步读取不到数据只能猜测或者生造一个错误结果。这种情况在开发中非常常见。只要 Agent 没有显式的状态管理机制模型就会在长链路中慢慢丢失对“当前状态”的准确认知。3.3 上下文窗口的“虚假安全感”大模型的上下文窗口越来越大听起来似乎长任务不再受限制。但真实情况是模型在 10 万 token 上下文中很难精准回忆起第一句用户指令里提到的限制条件。长上下文不等于长记忆。上下文窗口更像一块白板你可以在上面写很多内容但模型在读取时注意力会分散。前期关键信息会被后续大量内容淹没。这也是 WeaveBench 任务设计故意设置长上下文的原因它想测试模型是否能在信息过载的环境中依然锁定核心目标。3.4 对工程实践的启示如果现在要在生产环境使用长程 Agent我的建议是不要赌模型能在长链路中保持完美。你要做的是把系统设计成“允许出错、快速恢复”。要么降低单条任务的长度要么在关键节点增加校验和恢复机制。否则 40% 左右的成功率很难支撑核心业务。4. 拆解长程智能体的故障模式4.1 状态丢失中间结果被遗忘状态丢失几乎是长程任务最常见的问题。模型在执行第 8 步时已经不记得第 3 步得到的精确数值。它可能只记得一个模糊印象然后基于这个印象继续操作。如果是小数值误差还好但如果是文件路径、用户 ID、API 密钥这类关键信息出错后续步骤就全错了。检测方法在日志中记录每一步的关键变量。任务结束后回放检查第 N 步是否使用了正确的上一步结果。对失败任务做 diff观察状态信息是否前后一致。4.2 目标漂移做着做着就偏了目标漂移是指 Agent 在长流程中逐渐偏离用户最初的需求。一个经典例子用户要求“汇总华东区 Q3 销售额并发送给总监”。Agent 前两步判断为“访问销售表”“计算汇总金额”没问题。但到了第五步它开始自主增加分析维度又去查了同比增长率还生成了图表。看起来很有价值但用户原始要求里没让它做。在长任务中这种“创造力的副作用”会导致两个问题成本增加因为多做步骤会消耗额外 token。结果不可控因为每多一步就有新的出错可能。4.3 无效循环重复执行相同动作循环失败是长程任务里特别让人头疼的一类问题。表现是Agent 反复调用同一个工具传入几乎相同的参数得到相同的失败结果然后继续重试。模型似乎进入了死循环因为没有检测到“当前策略无效应该更换方案”。一个简单的循环检测思路是对工具调用的参数和返回结果做哈希如果哈希连续出现多次就触发熔断或切换策略。4.4 指令不遵循格式解析失败在带工具调用的 Agent 架构中模型输出需要被解析成结构化的工具调用指令。如果模型没有按约定格式输出解析器就会失败。常见现象包括多输出了一段自然语言解释导致 JSON 解析失败。漏掉必填参数。参数类型不对把数组传成了字符串。这类问题单看每次调用好像影响不大但在长任务中一次格式错误需要重试重试会引入新的状态变化可能导致后续步骤错位。4.5 成本与超时还没做完就被终止长程任务在真实系统中还有预算限制和超时限制。如果 Agent 执行 30 步每步消耗 5000 token总共就是 15 万 token 的输入输出。这个成本在高频业务场景中不可忽视。另外外部 API 往往有响应时间限制如果每个工具调用耗时 5 秒30 步就是 150 秒超出了很多前端请求的超时阈值。很多团队最后放弃长程 Agent不是因为模型能力不够而是因为成本不可控、响应时间不可控。5. 工程改进状态管理、循环防护与工具协议前面分析了故障模式这一节给出可落地的工程改进方案。我不会只讲抽象原则会给出可以直接参考的代码和配置思路。5.1 显式状态管理把记忆从提示词里拿出来很多人以为长程 Agent 只需要把历史消息一股脑塞给模型。这是误区。更可靠的做法是建立显式的状态管理把每一步的中间结果保存到结构化存储中。下面是一个用 JSON 文件保存 Agent 状态的示例。# 文件路径agent_state.py import json from pathlib import Path from datetime import datetime class AgentState: 一个简单的长程智能体状态管理器。 把每一步的关键信息保存到本地 JSON 文件中避免上下文遗忘。 def __init__(self, task_id: str, workdir: Path): self.task_id task_id self.workdir workdir self.state_file workdir / f{task_id}_state.json # 初始化任务状态 self.state { task_id: task_id, status: running, steps: [], memory: {}, created_at: datetime.now().isoformat(), updated_at: None, } def set_memory(self, key: str, value): 写入一条中间记忆例如文件路径、查询结果等。 self.state[memory][key] value self._save() def get_memory(self, key: str, defaultNone): 读取一条中间记忆。 return self.state[memory].get(key, default) def add_step(self, step_name: str, summary: str, detail: dict): 记录一步执行信息方便任务结束后回溯。 self.state[steps].append({ step: len(self.state[steps]) 1, name: step_name, summary: summary, detail: detail, time: datetime.now().isoformat(), }) self._save() def mark_done(self): 标记任务完成。 self.state[status] done self.state[updated_at] datetime.now().isoformat() self._save() def mark_failed(self, reason: str): 标记任务失败并记录原因。 self.state[status] failed self.state[fail_reason] reason self.state[updated_at] datetime.now().isoformat() self._save() def _save(self): 序列化保存状态文件。 self.state[updated_at] datetime.now().isoformat() self.workdir.mkdir(parentsTrue, exist_okTrue) self.state_file.write_text( json.dumps(self.state, ensure_asciiFalse, indent2), encodingutf-8 ) if __name__ __main__: # 演示用法 state AgentState(task_demo, Path(./agent_states)) state.set_memory(report_path, /tmp/report_2024.csv) state.add_step(fetch_data, 成功拉取销售数据, {rows: 1024}) state.add_step(calc_summary, 汇总金额为 358 万元, {}) state.mark_done() print(状态文件已生成, state.state_file)这个类的核心作用在于模型不再需要靠上下文回忆“上一步结果是什么”而是可以直接通过 get_memory 读取。如果后续步骤需要使用某个中间结果只要提前 set_memory 进去就不会丢失。在实际项目中你可能需要把存储换成 Redis 或数据库但设计思路是一样的。关键点是关键状态必须结构化保存并且每个步骤都可以追溯。5.2 循环检测与终止策略为了防止 Agent 在一个错误策略上反复打转我建议在调度层加一个循环检测器。# 文件路径loop_detector.py from collections import defaultdict import hashlib import json class LoopDetector: 循环检测器。 每次工具调用时注册动作、参数和结果摘要 如果相同调用重复出现多次则判定为疑似循环。 def __init__(self, max_steps: int 30, loop_threshold: int 3): self.max_steps max_steps self.loop_threshold loop_threshold self.call_count 0 self.fingerprint_counter defaultdict(int) def register_call(self, action: str, args: dict, result: str): 注册一次工具调用。 self.call_count 1 fingerprint self._compute_fingerprint(action, args, result) self.fingerprint_counter[fingerprint] 1 def is_looping(self) - bool: 判断是否出现连续重复调用。 return any(count self.loop_threshold for count in self.fingerprint_counter.values()) def should_terminate(self) - bool: 判断是否应该强制终止任务。 if self.call_count self.max_steps: return True if self.is_looping(): return True return False def _compute_fingerprint(self, action: str, args: dict, result: str) - str: 对动作、参数和结果做规范化哈希。 raw json.dumps({ action: action, args: args, result_preview: str(result)[:200], }, ensure_asciiFalse, sort_keysTrue) return hashlib.md5(raw.encode(utf-8)).hexdigest() if __name__ __main__: detector LoopDetector() # 模拟一个正确流程 detector.register_call(query_sales, {date: 2024-09-01}, success: 100 rows) detector.register_call(calc_summary, {metric: amount}, success: 3580000) # 模拟连续三次相同的失败调用 detector.register_call(query_sales, {date: bad}, error: param invalid) detector.register_call(query_sales, {date: bad}, error: param invalid) detector.register_call(query_sales, {date: bad}, error: param invalid) print(是否循环, detector.is_looping()) print(是否终止, detector.should_terminate())这里的循环检测原理很简单如果同一个动作、同一组参数、相同的结果摘要连续出现超过阈值就说明当前策略没有产生新进展应该终止任务或者切换策略。更精细的做法是忽略 result只比较 action 和 args因为有时模型会不断尝试同一个错误动作无论返回什么结果。在工程中可以根据实际场景调整。5.3 工具调用协议规范化另一个提升可靠性的手段是给每个工具定义严格的输入输出协议。推荐使用 JSON Schema 校验参数。举个例子一个查询工具的定义可以写成{ name: query_sales, description: 查询指定日期的销售数据, parameters: { type: object, properties: { date: { type: string, format: date, description: 查询日期格式为 YYYY-MM-DD }, region: { type: string, enum: [east, west, south, north], description: 大区名称 } }, required: [date, region] } }在 Agent 解析模型输出时先做 JSON Schema 校验。如果缺少必填参数或字段类型不对直接返回给模型一个明确的错误信息而不是让下游程序抛异常。这样做的好处是错误发生在工具调用前而不是调用过程中。模型可以收到“参数缺失”的明确反馈从而自行修正。下游系统不会因为非法请求被打挂。5.4 上下文压缩与关键信息锁定长任务中如果每次对话都保留全部历史很快上下文就会爆炸。一个常见手段是“记忆压缩”。思路是每一轮结束后用模型或规则把当前进展概括成一小段摘要连同关键状态记忆一起保存。下一轮只把“摘要 最近几步详细记录 用户原始需求”传给模型。伪代码如下def build_prompt(original_goal: str, summary: str, recent_steps: list[str], memory: dict): prompt f原始需求{original_goal}\n prompt f当前进度摘要{summary}\n prompt 最近几步\n for step in recent_steps[-5:]: prompt f- {step}\n prompt f关键状态{json.dumps(memory, ensure_asciiFalse)}\n prompt 请继续执行下一步。 return prompt核心思路是让原始目标、进度摘要、关键状态始终在模型视野中避免被长历史稀释。6. 自建评测脚本验证你的改进是否有效如果要做 Agent 相关开发我建议尽早自建一套小规模评测脚本。你不需要一开始就做得像 WeaveBench 那样庞大只需要能回答一个问题改动前后完成率变了吗下面是一个极简评测框架的设计思路。6.1 评测任务定义为了快速跑通我会定义一个模拟任务环境中有 10 个连续步骤需要完成Agent 每次调用 do_step 就会推进一步。如果 Agent 在 20 步内没有完成判定为失败。# 文件路径eval_simple_agent.py import random import asyncio class LongTaskEnv: 模拟一个需要多步操作才能完成的评测环境。 真正评测时可以替换为真实 API 或数据库环境。 def __init__(self, total_steps: int 10): self.total_steps total_steps self.completed_steps 0 async def step(self, action: str) - dict: if action ! do_step: return {status: error, msg: unknown action} self.completed_steps 1 if self.completed_steps self.total_steps: return {status: success, done: True} return {status: success, done: False} # 一个模拟智能体策略 def random_policy(state: dict) - str: 模拟智能体决策。生产场景中这里会调用大模型接口。 为了演示这里混入随机失败90% 概率执行正确动作10% 概率乱来。 if random.random() 0.9: return do_step return random_invalid_action async def run_once(env: LongTaskEnv, policy, max_steps: int 20) - dict: 运行一次任务返回是否完成和步数。 for step in range(1, max_steps 1): action policy(env) result await env.step(action) if result.get(done): return {solved: True, steps: step} if result.get(status) error: # 这里可以做异常恢复演示里只记录次数 pass return {solved: False, steps: max_steps} async def evaluate(policy, trials: int 50): 批量运行多次统计任务完成率。 solved_count 0 total_steps_list [] for _ in range(trials): env LongTaskEnv(total_steps10) result await run_once(env, policy) if result[solved]: solved_count 1 total_steps_list.append(result[steps]) success_rate solved_count / trials * 100 avg_steps sum(total_steps_list) / len(total_steps_list) print(f评测次数{trials}) print(f成功次数{solved_count}) print(f成功率{success_rate:.1f}%) print(f平均步数{avg_steps:.1f}) return success_rate if __name__ __main__: # 固定随机种子方便复现 random.seed(42) asyncio.run(evaluate(random_policy, trials100))运行这段脚本会输出类似评测次数100 成功次数42 成功率42.0% 平均步数19.3可以看到即使单步有 90% 概率做对10 步任务的成功率也只有 35% 到 45% 左右。你可以把 random_policy 替换成真实的大模型调用然后用同一套框架对比不同提示词、不同模型、不同工程方案的端到端成功率。这是我建议每个 Agent 项目都做的第一步。没有评测脚本所有优化都是盲目的。6.2 失败原因分类在真实项目中建议把失败原因分类记录下来。比如TIMEOUT超时。LOOP循环检测触发终止。PARSE_ERROR模型输出无法解析。STATE_ERROR状态不一致。BUDGET_EXCEEDED预算超限。有了这些标签你就能快速定位当前 Agent 的瓶颈到底是模型能力问题还是架构问题。7. 常见问题与排查思路下面汇总长程智能体开发过程中常见的问题以及对应的排查思路。问题现象常见原因解决思路任务进行到一半模型忘记初始指令上下文过长关键信息被淹没引入摘要机制始终保留原始目标用显式状态管理保存关键信息工具返回结果无法解析工具返回格式非结构化或缺少错误码统一工具返回 JSON 格式增加 schema 校验模型反复调用同一个工具循环检测缺失或提示词没有约束重试逻辑接入循环检测器达到阈值后强制切换策略某一步失败后后续所有步骤崩溃没有异常恢复机制每步增加重试和回退逻辑关键中间结果持久化任务耗时太长前端超时长任务没有拆分或异步化使用异步任务队列把长任务拆成独立子任务token 成本飙升历史记录全量保留导致输入膨胀使用上下文压缩定期清理无关历史模型确实执行了但结果不符合业务规则缺少业务规则校验层在工具调用前增加规则引擎或参数校验排查长程任务问题我建议始终遵循一个顺序先看日志定位是第几步失败的。再看失败那一步的输入和输出。检查这一步是否依赖前面某一步的状态。看这个状态是否被正确保存和传递。最后再判断是模型问题、工具问题还是架构问题。不要一上来就归咎于“模型能力不足”。很多时候问题出在状态管理、工具协议这些工程细节上。8. 最佳实践与工程建议8.1 把可靠性当作系统指标来设计在传统分布式系统里我们很少指望每个节点 100% 可靠而是通过超时、重试、熔断、降级来保证整体可用性。长程智能体也应该采用同样的思路。我建议在项目初期就定义清楚单步超时时间。最大重试次数。最大总步数。预算上限。失败后的回退策略。是否需要人工审批环节。这些参数比提示词更能决定线上稳定性。8.2 长任务优先拆分为子任务如果一条链路超过 15 步我会强烈建议拆分为多个子 Agent 或子任务。拆分的好处是每个子任务单独评测、单独优化。某个子任务失败后不影响其他部分。方便缓存中间结果下一次从失败点继续。这其实是把长程任务变短程任务。短任务的成功率控制起来容易得多。8.3 明确“计划-执行-验证”三阶段给 Agent 增加一个验证阶段是提升可靠性的低成本手段。执行完一个动作后不要急着进入下一步而是先问一句这一步返回的结果是否符合预期有没有出现空值、异常、超时当前状态是否需要更新到记忆中如果验证不通过可以触发重试或回退而不是盲目继续。在提示词层面可以要求模型在关键步骤后输出“校验结果”。在代码层面可以通过规则自动校验工具返回值。两者结合更稳妥。8.4 日志与可观测性长程 Agent 的日志比普通后端日志更重要因为它的执行是一个动态决策过程。建议记录以下信息每一步的输入提示词摘要。模型原始输出。工具调用参数。工具返回值。状态变更 diff。耗时和 token 消耗。触发终止的原因。理想情况下每条任务都应该有一个 trace_id。这样出了问题你能完整回放整个决策过程。8.5 安全与权限边界给 Agent 配置工具权限时要遵循最小权限原则。一个查询任务只需要只读权限就不应该给它删除或写入权限。尤其在生产环境涉及数据库、文件系统、API 写操作时必须明确指定允许操作的表、路径、接口。对危险操作增加二次确认。记录操作审计日志。预留一键熔断开关。长程任务的不可预判性更高所以安全边界要比普通代码更严格。不要因为 Agent 是“智能”的就放松控制恰恰相反越智能的系统越需要有边界的操作环境。8.6 评测驱动迭代我强烈建议把评测嵌入到 Agent 的开发流程中。每次修改提示词或调整架构都要跑一遍你的评测集。如果成功率没有提升甚至下降了那就不要上线。这比人工观察十几个案例靠谱得多。评测集可以小但不能没有。先有 20 条覆盖核心场景的用例再逐步扩充。这也是理解 WeaveBench 这类基准对行业最大价值的起点它把“感觉不行”变成了“具体哪里不行”。9. 当前挑战与下一步学习方向WeaveBench 仅 41.2% 的结果说明长程智能体在真实的复杂任务中还有明显短板。但换个角度说在工程上我们还有很大优化空间。模型单步能力在提升架构层面的可靠性手段也在快速发展比如记忆管理系统、多 Agent 协作框架、任务评测平台。如果你现在要动手做长程 Agent我建议从最小可用的闭环开始选择一个 5 到 10 步的任务加上状态管理和循环检测然后用评测脚本验证效果。不要一上来就追求大而全先把可靠性跑通再扩展任务复杂度。关于智能体可靠性的学习路线可以按这个顺序推进理解长程任务的基本流程和工具调用协议。写出可观测的 Agent 日志和状态管理。搭建一个极简评测集持续记录成功率。根据失败原因分类逐个击破。再研究更复杂的记忆机制、多 Agent 协作和强化学习。如果你在实际开发中也遇到过“单步准确率高、长任务还是失败”的情况欢迎把失败现象和排查过程记录下来。这类真实问题的复盘往往比看十篇论文更有效果。希望这篇围绕 WeaveBench 的可靠性拆解能帮你少踩一些坑。