Agent 规划能力怎么测？推理深度、任务分解与自我纠错的评估实战

凌晨三点，屏幕上第 47 次报错。我盯着那个 Agent 跑了一整夜的评测结果——准确率 94%，看起来挺漂亮。可实际部署到生产环境，三天内用户投诉了 11 次，全是一个毛病：任务做到一半就卡住了，要么无限循环调用同一个工具，要么突然跳过重要步骤。

那晚我意识到一件事：传统评测方法在骗我。准确率 94% 只说明它能答对单次问答，却完全看不出它能不能完成一个需要七八步推理的任务。这就像考试只考选择题，却要判断一个人的实际工作能力——能拿高分，但干不了活。

后来我花了两周时间研究 Agent 评测方法论，踩了不少坑。这篇文章就是我想分享给你的：Agent 规划能力到底该怎么测，为什么单纯看准确率不够用，以及怎么搭建一套真正能发现问题的评测体系。

一、为什么 Agent 评测比模型评测复杂？

模型评测其实挺直接的：给一道题，看答案对不对。选择题选 A 还是 B，代码生成能不能通过测试用例，翻译质量好不好——维度虽多，但逻辑清晰。

Agent 不一样。Anthropic 的工程团队在 2025 年的一篇博客里提过一个观点：Agent 的能力是”过程能力”，不是”单点能力”。你测的不是”它知不知道”，而是”它能不能在复杂环境下做出一系列正确决策”。

具体来说，Agent 需要六类核心能力：

1. 工具调用能力：知道什么时候该用什么工具，参数传对没
2. 任务分解能力：把大目标拆成可执行的小步骤，而且步骤之间要有合理的依赖关系
3. 推理能力：能处理多跳推理，不是一步到位，而是一步一步推导
4. 记忆能力：记住之前的上下文，别做第二步忘了第一步
5. 自我纠错能力：做错了能发现，能调整，别一条道走到黑
6. 长期规划能力：几十步的长任务链，中间不出岔子

你看，传统评测指标——准确率、F1、BLEU——全是针对单点输出的。Agent 需要的是评测”过程”，这事儿就复杂了。

举个例子。你让 Agent 帮你订一张从北京到上海的机票，要求是明天下午的航班，预算不超过 800 块。这个任务看起来简单，但实际上涉及：

• 先查航班信息（工具调用）
• 从结果里筛选符合条件的（推理能力）
• 如果没有完全符合条件的，要决定是放宽时间还是放宽预算（决策能力）
• 选定后要调用订票接口（工具调用）
• 如果接口报错，要能处理异常（自我纠错）

任何一步出问题，任务就失败。但你如果只看最终结果——“订没订成功”——就会漏掉很多信息。可能它选的航班时间不对，可能是预算超标了但它自己觉得没问题，也可能是接口报错了但它没重试。

这就是为什么 eval-driven development（评测驱动开发）在 Agent 领域这么重要。Anthropic 推荐的做法是：在开发阶段就把评测设计好，用评测来指导 Agent 的迭代，而不是等上线了再发现问题。

二、Agent 规划能力评测的核心维度

Agent 规划能力的评测，核心就三个维度：任务分解、推理深度、长期一致性。听起来挺抽象，我一个个拆给你说。

任务分解能力

简单说，就是看 Agent 能不能把一个大目标拆成可执行的小步骤，而且这些步骤之间的关系要合理。

评测这个能力的核心指标叫 Plan Graph Coherence（规划图一致性）。什么意思？你把 Agent 生成的任务步骤画成一个有向图，每个节点是一个子任务，边表示依赖关系。然后检查两件事：

1. 拓扑排序有效性：能不能找到一个合理的执行顺序，不存在”先做 B 才能做 A，但做 A 又要先做 B”这种死循环
2. 无循环依赖：图里不能有环

我之前遇到过这样的失败案例：让 Agent 写一个数据分析报告，它生成的计划是：

1. 收集数据
2. 清洗数据
3. 分析数据
4. 生成报告
5. 根据分析结果补充数据收集

看到问题没？第 5 步要回到第 1 步，但前面已经执行过了。Agent 自己没意识到这是个循环，于是整个流程就卡在那里反复执行。

典型的任务分解失败模式有三种：

• 循环依赖：像上面那个例子，步骤之间形成环
• 跳步：直接跳到结论，中间的重要步骤漏掉了
• 子任务不完整：分解出来的步骤压根不够完成目标

推理深度

这个维度测的是 Agent 能不能处理多步推理。DeepSeek-V3-0324 在多跳推理测试上的准确率是 91%，这个数据来自其技术报告。但”多跳”具体指什么？

简单说，就是从一个已知事实出发，需要经过 N 步推导才能得到最终答案。比如：

• 已知：A 比 B 大，B 比 C 大
• 问：A 和 C 谁大？
• 这就是个 2 跳推理问题

Agent 在真实场景里遇到的往往是 5 步甚至更多的推理链条。比如用户问”帮我找到上个月销售额最高的产品，然后分析它为什么卖得好”。这个任务需要：

1. 查询上个月的销售数据
2. 排序找到最高产品
3. 分析该产品的特征
4. 对比其他产品
5. 总结原因

每一步都需要基于前一步的结果继续推理。评测这个能力的指标是多跳推理准确率，但要细分：不同跳数的准确率分别是多少。很多时候 3 跳还行，5 跳就崩了。

长期规划一致性

这是最容易出问题的维度。一个需要 50 步的任务，Agent 执行到第 30 步的时候，还能记得最开始的上下文吗？

评测指标叫 State Drift Rate（状态漂移率），计算方式是：在长任务执行过程中，Agent 内部状态与预期状态不一致的次数，除以总步数。

我见过一个真实的案例：一个客服 Agent 在处理用户退款请求，前面一切都正常，用户说了句”不对，我说的是另一个订单”，Agent 一下子就乱了，后面所有对话都围绕那个”另一个订单”，但实际上用户要退的还是最开始那个。这就是状态漂移——在长对话过程中，Agent 丢失了最初的上下文锚点。

理想的 State Drift Rate 应该低于 0.05，也就是 100 步里最多 5 次状态不一致。但实际测试中，很多开源 Agent 的漂移率在 0.15 到 0.25 之间，差距相当大。

三、主流 Benchmark 深度对比

现在市面上 Agent 评测的 benchmark 不少，但各有各的侧重点。我挑四个主流的给你详细说说，顺便给你一个选型建议。

AgentBench：通用型选手

AgentBench 是清华团队在 ICLR’24 发表的，覆盖面最广。它测的是 LLM 作为 Agent 的综合能力，包含 8 个环境：

• 操作系统交互
• 数据库查询
• 知识图谱推理
• 购物场景
• 搜索引擎
• 家务规划
• 网页浏览
• 电子游戏

这套 benchmark 测试了 29 个主流 LLM，提供了非常全面的横向对比数据。如果你想快速了解一个模型的 Agent 能力处于什么水平，用 AgentBench 的简化版跑一遍就够了。

但它有个明显的不足：没有覆盖自我纠错能力的评测。也就是说，它只测”第一次能不能做对”，不测”做错了能不能自己发现并修正”。而自我纠错恰恰是 Agent 在真实场景里最需要的能力之一。

ACPBench：推理深度专家

IBM 的 ACPBench 专注测规划逻辑的深度推理。ACP 是 Action, Change, Planning 的缩写，名字就说明了一切。

它的特点是形式化推理验证。什么意思？它不只是看输出结果对不对，而是检查推理过程本身是否符合逻辑规则。比如你让 Agent 规划一个行程，它会验证每一步的前提条件是否满足，因果关系是否成立。

适合场景：你需要深入测试 Agent 的规划推理能力，而不只是看最终结果。缺点是覆盖面比较窄，主要集中在规划逻辑，对工具调用、多模态等维度不涉及。

ToolBench：工具调用专用

ToolBench 测的是 API 工具调用能力。如果你在开发一个工具型 Agent——比如能调用各种外部 API 的助手——这个 benchmark 最合适。

它提供了大规模的 API-planning 测试场景，测的是：

• 能不能正确选择要调用的 API
• 参数传得对不对
• 多个 API 串联调用的逻辑对不对
• API 调用失败时能不能处理

这套测试对于评估 Agent 的工具使用能力非常实用。

DeepPlanning：长周期规划

DeepPlanning 专注测长周期的 Agentic Planning。其他 benchmark 可能只测 5-10 步的任务，DeepPlanning 会测 20-50 步甚至更长的任务链。

这对评测长期规划一致性特别重要。Agent 能不能在几十步之后还记得最初的目标？中间会不会迷失方向？这些都是 DeepPlanning 能帮你发现的。

选型建议

场景	推荐 Benchmark	原因
初期快速验证	AgentBench 简化版	覆盖面广，能快速定位水平
规划能力专项	ACPBench	深度推理验证，形式化检查
工具型 Agent	ToolBench	API 调用专项测试
生产级验收	组合使用	多维度覆盖，互相补充

我个人的建议是：先用 AgentBench 跑一个基准线，知道你的 Agent 大概在什么水平。然后针对你业务最需要的维度，用专项 benchmark 深入测试。比如你的 Agent 主要做工具调用，就重点跑 ToolBench；如果主要做复杂规划，就用 ACPBench 和 DeepPlanning。

四、自我纠错能力评测实战

说实话，这一章可能是整篇文章最重要的部分。为什么？因为 Agent 在真实环境里不可能永远不出错。重点是：出错了能不能自己发现？能不能自己修正？

自我纠错有多重要？

数据说话。Reflexion 是一个经典的自我反思框架，它把 HumanEval 任务的通过率从 80% 提升到了 91%。提升幅度 11 个百分点，这可不是小数目。在 AlfWorld 环境测试中，Reflexion 解决了 134 个挑战中的 130 个，成功率 97%。

"Reflexion 是一个自我反思框架，通过让 Agent 在失败后分析原因并调整策略，将 HumanEval 任务通过率从 80% 提升至 91%，AlfWorld 挑战解决率达 97%（130/134）。"

另一个研究（Galileo 团队）的数据显示，自我反思机制能让问题解决性能提升 9% 到 18.5%。差距就这么大。

Reflexion 架构是怎么工作的

核心机制其实很简单，就四步：

1. 执行：Agent 尝试完成任务
2. 反思：如果失败，Agent 分析失败原因
3. 纠错：基于反思结果调整策略
4. 重试：用新策略再试一次

重点在于”反思”这一步。不是简单的”再试一次”，而是要能说出”为什么错了”、“应该怎么改”。这需要 Agent 具备元认知能力——能审视自己的思考过程。

怎么评测自我纠错能力？

我给你一个实操方案：

第一步：注入可控错误

你在测试环境里故意制造一些错误场景，比如：

• 工具调用超时
• API 返回错误码
• 参数格式不对
• 资源不存在

这些错误要能复现，这样你才能对比不同 Agent 在相同错误条件下的表现。

第二步：观察 Agent 的反应

记录这些信息：

• Agent 能不能识别出发生了错误？
• 它有没有尝试分析错误原因？
• 它采取了什么纠错策略？
• 纠错后成功了吗？
• 重试了几次？

第三步：统计指标

核心指标有三个：

1. 纠错成功率：错误发生后，Agent 自己修正并最终成功的比例
2. 平均重试次数：从错误到成功，平均需要重试几次
3. 最终达成率：考虑所有任务（包括那些需要纠错的），最终完成的百分比

一个设计良好的评测，应该能区分”一次就做对”和”做错了但能修正”这两种情况。前者可能基础能力强，后者则体现了自我纠错能力。

一个实际例子

我之前测过一个 Agent，给它一个任务：从数据库里查询用户信息然后生成报告。

第一次运行，它查询语句写错了，数据库返回空结果。这时候分两种情况：

• 不具备自我纠错能力的 Agent：直接用空结果生成报告，内容全是”未找到数据”
• 具备自我纠错能力的 Agent：发现结果为空，反思是不是查询条件有问题，修正后再试

评测就是要捕捉这种差异。你可以在评测报告里单独列出：

• 首次成功率：第一次就做对的比例
• 纠错后成功率：需要纠错但最终成功的比例
• 彻底失败率：纠错后仍然失败的比例

这三组数据加起来才是完整的 Agent 能力画像。

五、构建你的 Agent 评测体系

好了，理论说了不少，该落地了。我给你一个三层评测架构，直接能拿来用。

三层评测架构

第一层：基础能力层

测单点技能，每个能力单独评测：

• 工具调用正确率：调用的 API 和参数是否正确
• 小任务分解正确率：简单任务能不能拆成合理的步骤
• 单步推理准确率：一步推理能不能做对

这一层用单元测试的思路，每个测试独立运行，互不影响。

第二层：场景任务层

测真实业务场景的模拟任务：

• 设计几个典型的业务流程
• 每个流程包含 5-15 步
• 有正常流程，也有异常分支（需要纠错的场景）

这一层测的是能力组合，不是单点能力。

第三层：综合评估层

把所有测试结果聚合起来：

• 各维度的得分汇总
• 加权计算综合得分（根据业务重要性调整权重）
• 生成可视化报告

评测流程标准化

如果你要搭建一个可重复运行的评测体系，建议这样组织：

# 启动评测环境
docker compose -f eval-spec.yml up --build

# 运行指定 benchmark，重复 3 次取平均值
python run_eval.py --benchmark agentbench-v2.1 --num-trials 3

# 导出评测报告
python export_report.py --format markdown --output eval_results.md

重点是”重复 3 次”。Agent 的输出有一定随机性，单次测试结果不稳定，多跑几次取平均值更可靠。

核心指标清单

我给你整理了一张表，直接能当评测标准用：

指标	计算方式	理想阈值	我的建议
Tool Call F1	参数级 token 匹配	>= 0.92	工具型 Agent 的核心指标
Plan Coherence	拓扑有效性 + 无循环	1.0	必须满分，有循环就废了
State Drift Rate	状态不一致次数 / 总步数	< 0.05	越低越好
Recovery Rate	错误恢复成功次数 / 总错误次数	>= 0.8	自我纠错的直接体现
首次成功率	第一次就做对的比例	>= 0.85	基础能力
最终达成率	考虑纠错后的总成功率	>= 0.95	包含纠错能力

这些阈值是我根据实际经验给出的参考值。当然，具体标准要看你的业务场景——有的场景要求更高，有的可以适当放宽。

结论

说了这么多，核心观点就一个：Agent 评测不是看最终结果，而是看过程质量。传统评测指标只能告诉你”做对了还是做错了”，但 Agent 需要的是更细粒度的过程分析——它是怎么一步步走到那个结果的，中间有没有走弯路，走错了能不能自己调整回来。

eval-driven development 应该成为 Agent 开发的标配流程。不要等到上线了才发现问题，在开发阶段就把评测体系搭好，用评测数据指导迭代方向。

如果你现在就要开始做，我建议这样入手：

1. 先用 AgentBench 跑个基准测试，知道你的 Agent 在什么水平
2. 根据业务场景，选 2-3 个专项 benchmark 深入测试
3. 搭建三层评测架构，把评测流程标准化
4. 每次迭代都跑评测，用数据对比变化

Agent 的可靠性不是靠”感觉”来判断的，得靠评测数据说话。这篇文章的方法论和实操指南，希望能帮你少踩一些坑。

---

参考资料

• Anthropic Engineering: Demystifying evals for AI agents - 官方工程博客，2025
• AgentBench: Evaluating LLMs as Agents (ICLR’24) - 清华团队，学术 benchmark
• Survey on Evaluation of LLM-based Agents - arXiv 综述，2026
• Self-Reflection in LLM Agents - Reflexion 论文
• ACPBench: Reasoning about Action, Change, and Planning - IBM 研究

常见问题

Agent 评测和传统大模型评测有什么本质区别？

传统评测测的是单点能力（问答准确率、代码生成质量），Agent 评测测的是过程能力——包括工具调用、任务分解、推理深度、记忆、自我纠错、长期规划六类核心能力。Agent 需要在复杂环境下做出一系列正确决策，不是答对一道题就行。

如何选择合适的 Agent 评测 Benchmark？

根据场景选择：

• 初期快速验证：AgentBench 简化版（覆盖 8 环境，29 个 LLM 横向对比）
• 规划能力专项：ACPBench（形式化推理验证）
• 工具型 Agent：ToolBench（API 调用专项）
• 长周期规划：DeepPlanning（20-50 步任务链）
• 生产级验收：组合使用，多维度覆盖

Agent 规划能力评测有哪些关键指标？

三个核心指标：

• Plan Coherence（规划一致性）：检测循环依赖和跳步，理想值 = 1.0
• 多跳推理准确率：测 2-5 跳推理链条，DeepSeek-V3-0324 达 91%
• State Drift Rate（状态漂移率）：长期任务中的上下文保持，理想值 < 0.05

自我纠错能力如何评测？

使用 Reflexion 框架进行评测，核心指标：

• 纠错成功率：错误后自主修正的比例，应 >= 80%
• 平均重试次数：从错误到成功需要的尝试次数
• 最终达成率：包含纠错后的总成功率，应 >= 95%

Reflexion 将 HumanEval 通过率从 80% 提升至 91%，AlfWorld 成功率达 97%。

搭建 Agent 评测体系的步骤是什么？

三层评测架构：

• 基础能力层：单点技能测试（工具调用正确率、小任务分解、单步推理）
• 场景任务层：模拟真实业务流程（5-15 步，包含正常和异常分支）
• 综合评估层：多维度指标聚合、加权计算、可视化报告

建议每次评测重复 3 次取平均值，用 AgentBench 建立基准线后叠加专项 Benchmark。