长程智能体为何不可靠？WeaveBench评测揭秘与工程改进方案

之前在做智能体（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, default=None): """读取一条中间记忆。""" 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(parents=True, exist_ok=True) self.state_file.write_text( json.dumps(self.state, ensure_ascii=False, indent=2), encoding="utf-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_ascii=False, sort_keys=True) 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_ascii=False)}\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_steps=10) 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, trials=100))

运行这段脚本，会输出类似：

评测次数：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. 常见问题与排查思路

下面汇总长程智能体开发过程中常见的问题，以及对应的排查思路。

排查长程任务问题，我建议始终遵循一个顺序：

1. 先看日志，定位是第几步失败的。
2. 再看失败那一步的输入和输出。
3. 检查这一步是否依赖前面某一步的状态。
4. 看这个状态是否被正确保存和传递。
5. 最后再判断是模型问题、工具问题还是架构问题。

不要一上来就归咎于“模型能力不足”。很多时候问题出在状态管理、工具协议这些工程细节上。

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 的可靠性拆解，能帮你少踩一些坑。