Agent评测方法论梳理#

本文梳理了 Agent 评测的完整方法论体系，涵盖 Agent 发展阶段、评测框架、落地路径及相关 benchmark 资源，为 Agent 系统的能力评估与迭代提供体系化参考。关键要点包括：

1. Agent 核心定义与发展阶段：Agent 是具备运行时持续决策能力的系统，发展依次经历 Execution、Control、Coordination、Governance 四个阶段，分别对应执行落地、运行约束、多角色协作、长期业务落地的核心需求。
2. Agent 评测核心变化趋势：评测从单一结果判断转向三维观测，即从仅看最终结果转向同时观测执行过程、从单系统评估转向多组件协同评估、从瞬时表现评估转向长期运行行为评估。
3. 三层评测观测框架：包含结果层（验证任务完成的非偶然性）、过程层（评估规划、反馈修正、工具调用、记忆等核心模块能力）、安全与成本层（校验运行是否处于可接受的风险、资源与用户信任边界内）。
4. 「实现 × 架构」二维评测空间：以组件、模型、系统三层实现维度，匹配四类 Agent 架构的差异化评测重点，避免将局部特性误判为系统整体能力。
5. 领域 Agent 评测落地方法：需从业务场景出发，将核心业务判断抽象为带选错成本的决策点，再反向设计对应评测维度，避免与通用模型评测混淆。
6. Agent 评测迭代飞轮机制：通过固定运行变量、采集全链路 trace、分类归因失败类型，针对性从能力、策略、结构、环境四个维度迭代优化，形成可闭环的系统改进路径。
7. 配套评测资源矩阵：覆盖基础能力、交互执行、专项领域、多智能体、过程观测、安全风险六大类近百个成熟 benchmark，支撑不同维度的 Agent 能力验证。

介绍：

我们的方法论由认知层与执行层两部分构成，认知层负责建立对 Agent 本身的理解，明确其能力结构及这些能力在不同条件下如何被触发、放大或削弱。为评测提供必要的语义基础，使后续的评测设计能够有针对性地刻画关键能力，而非停留在表层现象。

认知层首先关注 What——评测应当观察什么。Agent不再仅以最终结果作为评判依据，而是从结果、过程与风险三个层面刻画 Agent 的行为表现，从而获得对其运行状态的结构化认知。在此基础上，认知层进一步回答 How——这些行为是如何产生的。这里以“实现 × 架构”为原则从将能力如何被工程化承载、以及不同Agent架构如何改变评测信号出发，构造二维评测空间，用于确保不同执行方式、控制强度与系统复杂度下的关键能力与风险均被纳入刻画。认知层还回答 Where——这些能力在什么语境下才真正成立。通过将能力置于具体任务目标、约束条件与风险结构中考察，使评测不再脱离具体使用场景而空转。

在认知基础之上，方法论进入执行层，将上述理解转化为可操作的评测流程。通过任务设计触发关键行为，通过环境与用户模拟使行为在真实约束下发生，并结合过程观测与对照分析，使评测信号具备可解释性与可复现性。最终，评测结果被反馈为可验证的系统改进依据，使评测不再只是对结果的判断，而成为支撑系统能力的持续演进与可靠落地对一环。

1. 从大模型到Agent#

1.1 Agent是什么#

Agent是一种在运行时持续做出“下一步行动决策”，并对这些决策后果负责的系统。

与传统的大模型调用或流程自动化不同，Agent的行为路径并非在设计阶段被完全确定，而是在执行过程中，随着环境状态、工具反馈与中间结果不断生成与调整。是否具备“运行时决策能力”是区分Agent与模型调用、与workflow的关键边界。

1.2 Agent的必然性#

当大模型开始被大规模使用时，我们对它的期待非常直接：更聪明的助手、更高效的问答系统、更强的内容生成能力。但当模型被用于真实任务时，一个问题迅速显现：真实任务不是问答，而是执行。执行意味着目标需要被拆解，步骤需要被衔接，工具需要被调用，失败需要被处理，任务需要被推进到结束。

在这一过程中，模型往往只能给出方向正确的建议，而真正的推进仍然依赖人类不断介入，持续决定“下一步该做什么”。正是在这种反复的人机接力中，一个新的需求逐渐变得清晰起来：如果模型已经具备足够的理解与推理能力，是否可以让它在一定范围内“自己继续往下做”？

1.3 Agent的发展#

2023 年春天，AutoGPT给出了一个并不成熟、但极具启发性的回答。它没有引入新的模型能力，而是尝试将模型置于一个持续执行的结构中：给定一个目标，系统开始自行拆解任务、调用工具，并根据中间结果继续推进。

虽然这些系统也很快暴露出稳定性不足、频繁跑偏等问题，却第一次在工程实践中验证了“模型可以在一定范围内自己继续往下做”这一设想。模型不再只是被动响应下一条指令，而开始在执行过程中连续做出决策，其行为呈现为一条随环境变化不断展开的轨迹。

小Tips：需要指出的是，在强化学习与多智能体研究中，Agent早已作为一种标准抽象存在，通常指在给定状态与动作空间中、围绕明确奖励信号进行决策的策略主体。但AutoGPT、BabyAGI以及ReAct等工作，使Agent脱离了封闭环境与显式奖励，被置于开放工具与真实任务中运行，是一个“运行时决策与行动耦合”的系统。

自此，Agent的讨论重心从能力设想转向执行现实。围绕执行所暴露出的不稳定性、复杂性与风险，Agent对设计经历了对控制、协作与治理的系统性探索。

1.3.1 Execution：当模型第一次被要求“把事做完”#

最早的Agent实践，做的是一件非常具体的事：让模型进入一个可以持续执行的循环。如ReAct、AutoGPT等工作，它们并没有改变模型本身，而是让模型成为一个正在运行的系统的一部分，在“思考—行动—观察”的闭环中不断前进。

部分Agent系统还引入显式或隐式的记忆机制用于保留跨步骤的信息状态，这样执行过程不再局限于即时反应，能够在更长时间范围内维持上下文一致性，从而支撑复杂任务的连续推进。

这一阶段，一次成功往往具有较强的偶然性，不能充分反映其在复杂执行过程中的稳定性。

1.3.2 Control：当“能执行”开始变成“不可控”#

一旦Agent开始在真实环境中运行，问题立刻出现：跑偏、死循环、错误调用工具、成本失控。 很多早期的尝试是把流程写得更细，但很快发现无济于事。原因在于Agent的关键决策发生在运行时，而不是设计时。因此，第二个阶段随之到来：控制（Control）。Agent引入运行时约束与纠偏机制，例如对步数、成本或工具使用范围的限制，以及对异常行为的检测与中断，确保执行过程始终处于可控边界之内。

在高成功率表象下，Agent也可能依赖过度约束或隐性兜底。

1.3.3 Coordination：当一个Agent不再够用#

随着任务变长、目标变复杂，单个Agent成为瓶颈。它既要规划，又要执行，还要纠错，系统复杂度迅速上升。此时，Agent的演化并没有走向更大的模型，而是走向角色拆分与协作：规划、执行、验证被交给不同的Agent，通过通信与协调完成整体目标。

在这种结构中，有时部分Agent会被设计成专门负责协调任务进度、评估中间结果或决定是否触发重试与回退（如supervisor结构）。

系统行为受到通信方式、信息共享策略与角色分工结构的影响，性能提升可能源于群体协同效应，而非单个Agent。

1.3.4 Governance：当Agent进入真实业务世界#

当Agent被用于客服、开发、运营等真实业务场景时，问题再次发生转移。系统是否稳定、失败代价是否可控、行为是否可审计、长期成本是否合理，开始比“能不能完成一次任务”更重要。此时智能不再体现在某一次执行中，而体现在长期行为模式与风险边界之内。

Agent在长期轮运行中可能出现的策略漂移、风险累积或进化，呈现出与单次运行显著不同的模式。

在这一阶段，部分系统还会基于长期运行数据对策略或参数进行受控调整。

2. Agent评测的变化趋势#

2.1 从结果到过程：能力不再集中于终点#

在Agent场景中，完成一次任务往往涉及多个步骤、工具调用以及对中间结果的反复处理。即便最终结果看似正确，不同的执行路径也可能对应截然不同的系统特性。因此，单次成功越来越难以作为能力的充分证据。Agent的关键差异，往往隐藏在执行过程中——路径选择是否稳定、失败是否可恢复、决策是否随环境变化而调整。这些特征无法通过仅观察最终结果来可靠捕捉。

当过程本身成为能力的重要载体时，评测的关注点也必须随之移动。

2.2 从个体到系统：表现开始难以归因#

Agent 系统逐步引入规划、记忆、工具调用等设计，它的最终表现不再由单一模型能力决定，而是由多个组件的协同作用共同塑造。此时性能提升往往并非来自某一能力的线性增强，而是源于系统结构、或决策路径的改变。当系统从单Agent演化为多Agent协作时，这种不可归因性会被进一步放大。多个Agent 之间的分工、博弈与协作关系，信息的暴露顺序使最终结果变为一种群体行为的涌现结果。

在这种情况下，传统以“模型能力”为中心的评测范式将不可避免地失效：我们往往无法判断性能提升究竟来自模型能力、系统结构，还是多 Agent 协同所带来的涌现效应。

当评测无法区分“能力提升”与“结构变化”的贡献时，评测结论本身变得不稳定。

2.3 从瞬时表现到长期行为：时间维度的引入#

在持续运行或重复使用的情境中，Agent系统还会暴露出时间尺度上的差异。一些系统在短期内表现良好，却在多轮运行后出现策略漂移、风险累积或稳定性下降；也有系统在初期看似平庸，却随着运行逐渐趋于稳定。

这些现象虽然并不一定意味着Agent具备显式的学习机制，但它们表明系统行为在时间维度上并非静态。单次或短期观察，往往无法揭示这些变化，而这些变化恰恰决定了Agent是否适合被部署于真实环境中。

当时间成为不可忽略的变量时，评测所面对的问题随之发生扩展。

综合上述变化，Agent评测的目标，不再只是回答“这个系统能不能完成任务”，而是需要进一步回答：它在什么条件下完成任务，以什么方式完成任务，以及在多次运行中是否保持一致。评测逐渐从单一分数的给定，转向对系统行为的定位：定位其能力边界、稳定边界与风险边界。

3. Agent评测的观测框架#

当评测对象发生迁移时，评测应当从哪些层面观察这些行为，才能避免将局部现象误判为系统能力？如果仍然沿用单一结果导向的评测方式，评测结论往往难以解释，也难以被合理外推。

3.1 结果层：Agent能否完成任务#

结果层关注的是Agent系统在一次完整运行结束后，是否达成了预期任务目标，以及这一结果在相同条件下是否具备基本的可复现性。即系统能不能把事情做成，而且不是偶然地做成。

在Agent场景中，结果层的“完成”要脱离模型输出，通常是指系统运行结束后，任务在系统层面达到明确的完成状态。例如，目标操作是否被正确执行、外部系统是否发生预期变化。

另一方面，一次跑通可能来自偶然路径、或隐性兜底等机制的介入。因此，结果层评测通常需要在固定环境与策略条件下进行多次运行，以判断任务完成是否具备短期、条件内的稳定性。当然，结果层中的“稳定完成”具有明确的适用边界，不涉及执行过程是否合理等考虑。一个系统即使在结果层表现稳定，仍可能在执行过程中存在大量无效尝试，或在长期运行中暴露出风险与成本问题。

因此，结果层结论只能用于判断系统的基本可用性，它通常在Agent评测中扮演的是“入口条件”的角色：决定评测是否有继续深入的必要，但并不决定评测是否已经充分。只有在结果层确认系统具备基本可用性之后，才有意义进一步考察的必要。

3.2 过程层：Agent是如何完成任务的#

过程层评测关注的是系统在执行过程中真实发生的行为，以及这些行为是否合理、是否符合任务与环境约束。

在Agent系统中，许多关键能力并不会直接反映在结果上。例如，模型是否进入了合适的规划分支、是否在恰当的时机调用了正确的工具、是否根据环境反馈调整了后续行为。一个系统即使最终完成任务，如果其执行过程依赖大量试错、频繁回退或明显冗余的步骤，其工程风险也已经在过程层中显现。

过程问题并不一定会导致结果失败。过程层评测的价值，正是在结果尚可的情况下，识别这些被掩盖的结构性缺陷。从过程视角看，Agent 并非一个单一的决策体，而是由若干功能模块协同运作的系统。这些模块分别承担理解、规划、记忆、工具交互、反馈修正等不同职责，其行为质量共同决定了 Agent 的整体稳定性与可控性。因此，过程层评测的关键在于对这些核心功能模块进行可分解、可诊断的评估。随着 Agent 架构与应用场景的演进，每一类模块也逐步形成了对应的评测方法与能力发展路径，构成了过程层评测的基本分析框架。

3.2.1 规划决策#

Agent 的规划/决策模块评测在不完备信息 + 约束 + 时间推进 + 交互干预下，Agent 是否能把目标稳定地编译成可执行的策略，并在执行反馈中持续做出正确的下一步决策。

规划/决策模块是一个把目标持续“编译—澄清—合成—执行—再规划”的闭环。

输入编译层：GroundCocoa就强调规划的第一性问题是约束与条件是否被正确表示。也就是Agent 是否把自然语言目标编译成可操作的状态表示：硬约束（必须满足）、软偏好（可权衡）、资源/预算/时间窗、先后依赖、以及需要补齐的缺失信息。这里的失败模式约束没抽出来、条件逻辑提取错、把不确定当确定。

交互决策层：规划往往不是一步生成，而是持续决策：什么时候该问、问什么最值、什么时候该查工具、先查哪个、何时停止信息收集进入执行。PIPA认为交互式规划的质量不应只由最终任务完成与否决定，而应通过诊断中间决策过程，比如状态一致性、工具使用效率与交互行为模式的分析，揭示 Agent 是否在不确定性下做出了合理的澄清、信息收集与工具使用选择。

计划合成层：PLANET指出规划能力必须在多种结构要求下稳定成立，因为计划质量不看文采，更看结构，包括是否有目标分解、是否显式依赖、是否考虑资源占用与并行、是否能在多个候选方案间做权衡。

执行层：规划模块最容易被忽略的是“执行中的决策”：环境反馈、延迟、打断、失败恢复、以及无解/不该继续时的停止判断。Robotouille提出要评调度与中断鲁棒性；Plancraft强调“可行性判断”和“在工具与信息噪声下的目标不漂移”。GraphicBench中的任务需要通过多轮迭代逐步收敛需求，评的是“规划在多轮设计决策中是否保持方向一致、避免目标漂移”。

3.2.2 反馈感知与自我修正#

反馈感知与自我修正而是一项决定系统是否具备长期可靠性与可持续改进能力的核心能力。关注的是：当 Agent的行为已经发生偏差、错误或低效时，它是否能够感知失败信号、理解失败原因，并据此调整后续决策路径。

Self-Reflection in LLM Agents的实验表明，只有当模型被迫对失败进行显式反思，而非简单重试时，后续行为才会出现系统性改善； Failure Makes the Agent Stronger进一步证明，在工具交互等可执行场景中，只有将反馈组织为结构化的错误诊断与修正建议，Agent才能减少重复失败并稳定提升成功率。这说明自我修正能力必须在失败之后被评测。因此评测应当构造必然产生失败或不完备行为的任务设置，使 Agent暴露其错误假设、错误策略或执行偏差，随后观察 Agent 是否能够基于失败生成明确的错误解释或改进方向，并在后续行为中体现出可验证的修正效果。

如Tool-Reflection-Bench通过程序化构造的“错误调用 → 反思 → 修正调用”轨迹来评估Agent自我修正能力。在这个 benchmark 里，Agent必须先在破坏轨迹中基于错误信号进行诊断，再提出一个结构上有效且可执行的修正调用，最后由评测程序验证调用的结构有效性、可执行性、参数正确性以及结果一致性四个维度，考察反思本身是否能生成高质量的错误定位与修正策略。

文中构造的错误调用的4种类型：Call-order swap（顺序错位 / 交换）、Redundant call（冗余重复调用）、Missing call（缺失前置调用 / 漏调用）、Argument error（参数错误：类型/范围/缺字段/别名等）

进一步来说，有价值的自我修正并不止于“当前任务的修复”，还体现在对未来类似情形的迁移与预防。Re-ReST与多层反思类工作表明，当Agent能够将失败模式抽象并积累为可复用经验时，后续行为会呈现出错误复发率下降、决策效率提升的趋势。这提示评测还应关注：修正是否改变了Agent的策略空间，而不仅是单次输出。

3.2.3 工具调用#

工具调用会直接改变外部世界状态、触发真实副作用，甚至带来安全与合规风险，因此评测需要关注“是否在正确的时机、以正确的方式、在安全边界内调用工具”。

首先τ-bench与 τ²-bench的核心思想是工具调用能力必须在动态交互中评估，而不是在静态单轮任务中评估。 因为失败往往源于对“是否应该调用工具”、“是否已经具备调用前提”、“是否理解当前状态”的误判。因此，评测应关注 Agent是否能够在交互中保持工具使用策略的一致性、是否能在状态变化后调整调用计划，而不是单次 API 是否正确。

其次，工具调用能力本质上是规划、执行与反馈耦合下的能力。就像Tool-Reflection-Bench的设计：一个真正具备工具使用能力的 Agent，不仅要能调用工具，还必须在调用失败后生成结构化的错误诊断，并据此提出可执行的修正策略。这里的关键是能否定位失败原因（工具选错、参数错误、调用时机不当、前置条件缺失），并将反思转化为下一步行动。由此可见，工具调用评测也结合包含“失败—反思—修正—再执行”的过程，而不是只看最终是否成功。

进一步地，工具调用评测必须将安全性纳入核心指标。SafeToolBench强调：一个安全的 Agent，首先应当学会不调用工具，即在不安全、不确定或越权的情境下主动放弃执行。

综合这些研究，一个合格的工具调用 Agent必须同时满足三个条件：在交互中知道何时不该调用，何时该调用、该调用什么，该如何调用；在执行中能够基于反馈修正策略而非盲目重试；在决策前能够感知并遵守安全与合规边界。因此，工具调用评测应采用多轮、轨迹级、带失败注入与安全约束的评测设计，将工具选择、调用顺序、反思修正与风险规避统一纳入同一评测框架，而不是分散地用成功率或格式正确率进行度量。

3.2.4 记忆机制#

Agent 记忆评测正在从“模型是否还能在上下文里找回一句话”，转向“在时间推进、角色受限、任务持续演化的情况下，Agent 是否在正确的时刻使用正确范围内的记忆，并由此导向了合理的行为结果。

在早期，有一些研究会假设记忆就是上下文长度问题，但是MemBench等研究开始将对话切成多个session，甚至跨越上万 token、数百轮交互，测试原始信息已经不在上下文中时，Agent是否还能通过记忆机制维持状态连续性，而非单纯的检索能力。

其次，记忆的评测对象本身发生了变化。记忆不再只指明确的事实条目信息（姓名、年龄等），而是扩展为抽象化、可归纳、可压缩的长期信息：事件、习惯、性格、关系变化。MemBench区分factual与reflective memory，LoCoMo直接以事件与因果链为核心，MTPChat引入persona随时间演化的多模态信号。这说明Agent 记忆评测转向一个更高层的问题：模型是否在“记忆中形成了可被未来行为消费的结构”，而不是零散信息集合。

TimeChara还把记忆与幻觉结合，指出记忆不是越多越好，而是必须受时间约束。通过考察Agent 是否知道“此刻它不该知道什么”，让记忆评测第一次系统性地引入了可见性边界，把记忆错误从“忘了”扩展为“提前知道了”。

另外，对于Agent最重要一个评测角度是，脱离行为的记忆评测是残缺的。单独测QA、测回忆准确率，只能说明记忆模块是否存在；但真正重要的是，记忆是否改变了 Agent 的决策路径——是否避免了重复询问、是否影响了工具选择、是否让策略在长期交互中发生了合理偏移。长期对话评测、persona一致性、时间感知响应预测，都是在考察记忆有没有成为决策的因变量，而不仅是一个可被查询的数据库。

最后，MemBench还引入容量、效率、时间成本，关心记忆机制在真实部署中是否稳定、是否可扩展、是否会在长期运行中崩塌。

3.3 安全与成本层：Agent运行是否处于可接受边界内#

即使在结果正确、过程合理的情况下，一次运行也可能已经越过了安全或成本边界。安全与成本层评测关注的，正是Agent在运行过程中是否处于可接受的约束范围内。

不必要的高频工具调用、过度消耗计算资源、触发安全策略、或产生潜在风险行为，这些问题即使没有影响任务结果，也会直接影响系统的工程可行性与部署边界。

在社区的研究中，Agent的安全与成本评测从关注模型是否违反显式安全规则，转向评估在时间推进、工具介入、环境耦合与目标持续演化的条件下，Agent 的整体运行是否始终处于人类可接受的风险与成本边界内。

早期安全评测主要被建模为一种内容级或规则级属性，默认安全失败是瞬时的、可在单轮输出中被捕捉的。评测关注模型是否生成违规文本、拒绝危险请求、遵循明确给定的安全策略。但当LLM 被置于Agent架构中，情况发生了变化。Agent-SafetyBench明确将评测对象从“文本输出”推进到多步行动与工具调用轨迹，并发现即便在相同系统设计下，模型在首轮对齐良好，安全性也会在后续步骤中显著退化。说明安全不再是一次性属性，而是随执行过程演化的系统性特征。

与此同时，成本开始在评测中被显性纳入考量。评测不再只关注系统是否完成任务，而是进一步关注为此付出的资源代价与所创造的实际价值之间的关系。BountyBench通过将Agent修复漏洞可获得赏金定义为收益信号，评测不再只是判断“做得对不对”，而是在刻画其在真实系统中的潜在价值上限。也就是更高的执行成本并非天然劣势，只要其能够换取足够高的系统价值。

当Agent直接进入人类工作流时，成本还呈现出另一种形式。以 Human-Centered GUI Agent 评测框架为代表的研究指出，即便 Agent没有造成明确安全事故，只要其行为不可预测、难以理解、无法被及时中断或纠偏，人类仍会选择放弃使用。此时，安全与成本不再体现为系统日志中的错误、资源消耗，而体现为信任的流失与自动化程度的下降。

4. Agent的评测空间：实现 × 架构#

在Agent系统中，同一层面的观测可以来自不同的工程实现。例如，结果层的稳定性可能取决于模型决策，也可能由系统级兜底机制保证；过程层中的不合理行为，既可能源于工具组件的失败，也可能来自模型选择或系统调度策略。

进一步地，不同 Agent 架构在执行方式、控制强度与协作机制上的差异，会系统性地改变“哪些能力可以被暴露、哪些风险会被放大、以及哪些评测信号本身是不可见的”。

因此，引入「实现 × 架构」的评测空间，通过将能力如何被工程化承载、以及架构如何决定可评测内容与评测重点，明确纳入评测设计本身，确保评测空间足够完整，评测更有针对性。

4.1 实现视角：Agent能力如何被工程化承载#

在Agent系统中，评测所面对的并非抽象能力，而是系统在运行过程中通过具体工程实现所暴露的行为与结果。理解这些表现由哪些实现层级产生，是构建完整评测覆盖、避免关键问题被系统性遗漏的基础。

从工程实践与评测需求出发，无论系统设计多么复杂，能力都不可能脱离这三类承载形态而独立存在：被封装为可调用的功能单元、由模型在运行时做出决策，系统机制在运行层面统一调度与约束。

组件层：显式能力、执行路径与局部成本#

组件层通常指如我们在3.2章节介绍的外部工具、记忆等模块。从评测视角看，组件层直接塑造了Agent执行路径的形态与局部成本结构。组件是否被真实调用、是否在合适的时机被触发、以及多个组件在多步执行中的组合方式，都会显著影响系统的稳定性。它的触发、输入输出与执行结果通常以结构化形式记录下来，构成Agent过程评估中的重要观测基础。

更重要的是，组件层往往是成本与失败代价最早显现的地方。高延迟或高费用的工具调用、重复触发的外部请求都会在组件层迅速放大资源消耗。即使端到端结果成功，这些局部成本问题也可能在规模化运行中成为系统的主要瓶颈。

模型层：规划与决策生成#

模型层承担的是Agent在运行过程中对信息的理解、决策生成职责。在评测视角下，模型层的核心价值在于其在关键节点上如何做出选择。例如，在多步任务中，模型是否选择了合适的行动方向、是否在相似条件下保持决策一致，以及是否遵循已有约束继续推进任务。

模型的中间输出通常也会被 trace 记录下来，作为过程评估的一部分，用于观察其规划与决策质量。而模型层是过程评估中最容易暴露路径波动与策略不稳定的地方，模型在中间决策阶段的偏移可能导致执行过程出现绕行、重复或偶然成功的情况。正由于这种不确定性，单次运行难以反映其真实表现，往往需要结合多次端到端结果评估，对决策稳定性与一致性进行观察。

系统层：端到端结果、稳定性与运行边界#

系统层指的是支撑Agent持续运行的整体机制，包括任务调度、状态管理、异常兜底、权限控制以及资源限制等。在评测视角下，系统层不仅承载端到端结果，执行路径是否频繁回退、是否依赖多次重试才能推进、以及在相似条件下整体执行轨迹是否保持一致，这些都属于系统层过程评估的核心内容，这依赖于对全局执行轨迹、状态演化与调度行为的持续记录，而非局部步骤的分析。

同时，系统层也是运行边界的关键承载者，整体的成本与风险是判断其是否具备真实部署价值的重要依据。

4.2 不同架构下的实现差异化#

组件、模型与系统构成了评测所面对的基本实现层级。不同架构下，它们在系统中的具体配置方式、承担的责任边界以及所受的约束条件，都会发生系统性变化，同时这也影响评测中哪些维度更关键、哪些现象应被谨慎解读。

在 Execution 架构中，系统主要依赖逐步执行本身来体现正确性。组件通常以明确的工具或子模块形式存在，评测关注组件是否按预期触发以及调用是否可靠、调用结果是否符合预期；模型的作用集中在即时判断当前这一步该如何行动，评测重点在于其局部规划与决策质量；而系统层的调度与状态管理相对轻量，通常不承担复杂的路径控制职责。整体上，评测更关注执行流程能否持续推进，是否容易陷入卡死、循环或依赖偶然成功完成任务。

在 Control 架构中，系统会引入显式的控制与纠偏机制。组件层通常增加约束、校验、反思或兜底模块，用于在执行过程中发现并干预潜在错误，评测关注这些控制组件是否真实生效；模型不再只负责决定“下一步做什么”，还需要在约束条件下判断“这样做是否合理”，评测重点在于其决策稳定性与对控制信号的响应遵循能力；系统层开始承担路径管理、失败处理与回退逻辑，评测关注控制机制是否能够有效防止系统一路跑偏，而非仅在事后掩盖问题。

• 约束规则、反思模块、兜底组件是否生效；
• 在受限条件下的决策合理性
• 控制机制是否真正防止失控
• 是否出现“表面服从、实则规避”
• 是否频繁依赖外部人工 / 强规则
• 异常是否被及时捕获
• 回退 / 重规划是否真的发生
• 控制成本

Coordination

P（过程）

P（过程）

O（结果） + RC（风险）

• 通信接口是否清晰
• 是否理解角色分工
• 性能提升是否来自协同结构
• 信息是否冲突 / 丢失
• 是否具备基本协作推理能力
• 整体通信开销
• 共享记忆是否一致

Governance

RC（风险 / 成本）

P（过程）+RC（风险）

RC（风险）

• 日志 / 审计是否完整
• 行为是否随时间漂移
• 长期稳定性
• 是否支持回溯与回滚
• 错误是否被放大
• 风险累积
• 运维与观测成本
• 成本控制
• 学习与进化

5. Agent评测的语境化：从通用能力到领域语义#

当Agent评测不再是对单一输出的判断，而是对行为、路径与后果的系统观察时，这些观测信号，究竟应当如何被解读？成功如何被定义、能力如何被理解？答案取决于Agent所处的应用语境。

对于通用Agent，评测往往从抽象能力出发：是否具备规划、推理、工具使用、记忆与迁移等通用能力。而领域 Agent的出现，评测不再从“你具不具备某种能力”开始，而是从“在这个具体业务中，什么才算正确行为”开始。

5.1.1 结果定义不再抽象#

领域Agent的第一个重要特征，是结果定义不再抽象。以客服Agent为例，成功是是否在合规前提下解决问题、是否触发了恰当的升级流程、是否被用户接受。这些指标并非为Agent特别设计，而是长期存在于客服业务中的成熟评估标准。

类似地，在AI4SE Agent中，成功也并不完全等同于生成正确代码。而是代码是否通过测试、是否符合工程规范、是否引入隐性风险、是否破坏既有系统假设。这些判断标准同样源自软件工程实践，而非Agent研究本身。

这说明领域Agent并没有引入一套全新的“Agent 专属能力”，而是将原本属于业务或模型评测的能力，重新纳入到 Agent的整体评测中。不同之处在于，这些能力必须通过Agent的完整行为过程来体现。

5.1.2 业务能力被重新放置#

想象我们正在评测客服Agent，有一个问题是像意图识别、情绪理解、这在模型评测中已经考察过的能力，是否还有必要在Agent评测中重复？

实际上，在模型评测中，意图识别通常意味着“模型能不能把用户输入分到正确的意图类别”；而在客服Agent 中，意图识别的真正含义变成了：Agent是否基于正确的意图，选择了正确的处理路径、工具调用方式或升级策略。

同样，在 AI4SE场景中，模型级能力可能评测的是代码理解或补全是否准确，而Agent 评测关注的则是：是否在正确理解问题背景后，选择了恰当的修改策略、验证流程与回退方式。

以上，这些业务能力被嵌入到Agent的行动决策链条之中，也是领域Agent评测的核心挑战。因此往往需要对完整的执行过程进行评测。

5.1.3 从业务语境到领域Agent评测设计#

当我们在评测领域Agent时，不再首先思考这个Agent有什么能力？要不要测记忆 / 推理 / 工具。而是先问这个业务领域里，哪些判断是关键判断？哪些判断如果错了，结果不可接受 / 风险不可逆？

比如在客服场景里，这个待处理的任务分类是咨询？投诉？退款？能不能自动处理？还是必须升级？能不能承诺？还是必须先核验？这些问题分类在业务里本来就存在，是我们期望Agent替代人类完成的工作，并非因Agent而特殊存在。

一个决策点，本质是多条可选路径且每条路径后果不同，即有明确的选错成本。这些决策点是Agent真正发挥智能的地方。比如在客服里常见的决策点：

• 自动处理 vs 升级人工
• 直接回复 vs 信息查询
• 立即退款 vs 要求补充信息
• 安抚用户 vs 拒绝请求
• Step 3：从“决策点”反推评测怎么设计

决策点明确后评测设计变得具体、可落地。我们不再评测Agent 会不会意图识别？而是在“是否升级”的决策点 上，对于需要升级的任务，选择了升级，反之继续处理。评测可以关注：

结果层：最终走了哪条业务路径？是否符合业务定义的“成功”？

过程层：在决策前是否使用了必要信息？ 是否调用了该用的工具？有没有跳过不该跳过的步骤？

风险层：有没有做出越权承诺？

通过这一方式，领域 Agent 的评测既不会退化为模型能力的简单复用，也不会陷入为Agent人为设计新能力的陷阱。评测关注的始终是：在具体业务语境中，哪些能力是决定行为走向的，以及这些能力是否被可靠地嵌入到了 Agent 的行动之中。

6. Agent的评测的实施#

6.1 评测任务设计：从题目到行为触发器#

在Agent场景下，评测任务的作用并不仅是检验“能否完成目标”，而更重要的是触发特定类型的系统行为。同样是完成一个任务，考察一个能力，不同的任务设计会激活Agent在执行、控制、协作或长期决策层面的完全不同表现。

因此，任务设计首先需要回答的不是有多难，而是这个任务会迫使Agent在哪些关键节点做出选择。

实践中，一个有效的评测任务通常具备以下特征之一： 它要么包含多个步骤之间的行为依赖，要求Agent在执行过程中维持一致的决策逻辑；要么信息并不完备，需要通过探索或交互逐步补全；要么允许失败但可恢复，从而暴露Agent的控制与调整能力；又或者任务本身具有长期性，只有在多轮运行后才会显现出系统差异。

这些特征并非任务天然具备，而是评测设计中有意引入的结构性约束。通过这些设计，任务不再只是一个等待被解答的问题，而成为触发系统行为、放大能力差异的机制。在这种视角下，任务不再是静态的问题描述，而更像是一个行为触发器。不同任务，可以在如上的二维评测空间中激活不同的观察位置：有的主要落在 Execution × 过程层，有的则会暴露 Coordination 或 Control层面的风险。

任务结构：是否引入行为依赖#

“是否引入多步依赖”并不是指任务表面上包含多少操作步骤，也不是前序的行为仅仅会触发后续的步骤。而是指评测是否让早期决策真实地约束后续行为空间。

一个具有代表性的多步任务环境是ALFWorld。在该环境中，Agent需要通过文本指令完成目标导向的操作任务，例如查找物品、操纵对象。任务的完成依赖于明确的步骤顺序，早期决策的错误往往会在后续阶段被放大，甚至直接导致任务无法继续推进。在这种设定下，评测结果不再由某一次决策决定，而是高度依赖于整个执行路径的组织方式。

相比之下，WebArena将多步依赖进一步引入到更复杂的交互环境中。Agent需要在模拟的网页系统中完成跨页面、跨状态的操作任务，每一步操作都会显式改变环境状态，如改变页面结构、改变可访问按钮、改变 session / 登录态。

这里的评测重点不在于单次点击是否正确，而在于Agent是否能够在不断变化的环境中牢记目标，并在遇到失败时合理调整后续行为。这类任务能系统性地暴露出Agent在连续决策中的稳定性差异。

从评测视角看，这类多步任务并不是更难的题目，而是对评测对象的重构。让执行路径的连贯性、错误传播方式以及控制机制的有效性，成为评测结论的核心依据。

任务信息完备性：是否必须通过探索与交互补全信息#

在许多任务设定中，Agent在任务开始时即可获得完成目标所需的全部信息。这类任务中，系统的最优行为往往可以在一次推理中被直接计算出来，后续执行只是对既定决策的展开。在这种条件下，Agent是否主动探索、是否具备澄清意识，并不会对结果产生实质影响。

然而在真实应用场景中，Agent面对的往往是信息不完备的环境：关键条件缺失、目标存在歧义。如以τ2-bench为代表的交互式Agent评测中，用户并不会一次性给出完整需求，Agent需要通过多轮对话逐步澄清目标、补全约束条件，并据此调整后续行为。在这类设定下，评测的可以考察系统是否识别信息缺口，并主动通过提问或确认来补全关键信息。

更有意思的是，有时信息不完备并不总是以“缺失”的形式出现。如在FANToM这个多主体交互任务中，关键信息分散在不同角色或视角之中，Agent 所面临的挑战不在于获取新信息，而在于是否意识到自身掌握的仅是局部视角，并据此调整其推理与行动假设。 在此类任务中，评测关注的也不再只是是否提出澄清问题，而是系统是否具备对他人知识状态与信息不对称性的建模能力。

失败可恢复性：失败是否被允许成为行为的一部分#

在许多评测设定中，失败即意味着任务终止，系统没有机会基于失败结果进行任何调整。在这种条件下，即便Agent内部具备反思或控制机制，这些能力也无法被观察，评测结果自然退化为对首次决策质量的判断。这也是传统多选类与一次性任务型 benchmark难以用于 Agent 评测的根本原因：它们在评测结构上默认错误不可恢复，从而在观测层面排除了对反思、调整与控制能力的刻画空间。

相对而言，像SWE-bench所刻画的软件修复任务，提供了一种不同的评测条件。初始尝试失败后，系统可以获得明确的反馈（如测试用例失败信息），并被允许在同一任务上下文中继续尝试。这种设定为恢复行为的发生提供了必要前提。

在这种任务结构下，Agent的架构差异开始显现：有的系统在失败后直接终止，有的会重复相同策略，而有的则能够根据失败反馈调整后续行为。评测关注的正是这种差异。从评测视角看，失败可恢复性的引入，本质上是将 Control 层的行为暴露为可观察对象。

长期性：考察Agent是否出现演化与风险累积#

任务设计中还需要考虑长期性这一维度。这里的长期性指评测是否将一系列相关任务置于同一连续上下文中进行观察。

在缺乏长期维度的评测设定中，不同Agent系统往往在短期内表现相近。即便架构上存在显著差异，例如是否具备记忆机制、是否会根据历史行为调整策略，这些差异也可能被单次或少量运行所掩盖。评测结果因此容易高估偶然成功路径的价值，而低估长期行为稳定性的重要性。

一类具有代表性的长期任务设定，是将Agent置于同一环境中，要求其连续完成多个相互关联但并非重复的子任务。比如Voyager，是一个在 Minecraft 环境中持续运行的Agent系统。它需要在同一环境中长期执行大量相关但非重复的任务。

另外在基于游戏或仿真环境的评测中，任务并不在一次完成后立即重置，而是允许系统在后续任务中继续使用此前产生的状态与经验。如CATArena: Evaluation of LLMAgents Through Iterative Tournament Competitions提出了一种“迭代式对抗评测”范式，用多轮、跨阶段的Agent对抗过程来评测Agent的探索效率、路径选择以及对已有经验的复用程度。因为是否能够避免重复试错、是否能在后续任务中减少无效行动，通常只有在多轮运行后才会变得清晰。

这里任务设计所提供的是让跨任务行为模式成为可观察对象的条件。如果评测任务始终以独立、一次性的形式出现，那么系统在时间维度上的差异就无法被显式评估。从评测视角看，引入长期性，意味着将评测对象从单次任务结果扩展为跨任务的行为轨迹，为后续分析策略漂移、风险累积与资源消耗趋势提供基础。

6.2 评测环境设计：让行为真实发生#

在Agent评测中，环境的价值并不完全在于“看起来像真实世界”，而在于Agent的行为是否会对环境状态产生真实影响，错误是否会带来后果。一个缺乏反馈的环境，即使任务再复杂，也只能评测Agent的“表演能力”。

用户模拟：真实性与对抗性的双重考虑#

用户模拟的价值已在多个研究领域中被提出。在推荐领域，RecUserSim: A Realistic and Diverse User Simulator for Evaluating Conversational Recommender Systems为了提升模拟的多样性与现实相关性，设计了包含用户个人特征、历史行为轨迹与情境需求变化的用户模拟方法，用于生成更具复杂性的测试交互样例。

另外，也有专门的模拟框架专注于构建更具现实感的用户行为模型，用于评估Agent在多轮交互场景中的性能。例如SAGE: A Top-Down Bottom-Up Knowledge-Grounded User Simulator for Multi-turn Agent Evaluation提出了结合顶层知识与底层业务信息的用户模拟方法，以产生更贴近真实业务情境的对话行为，并发现这种模拟方式能够揭示出更多Agent错误。

在评测中引入用户模拟，有两个主要作用：

• 提供动态输入与反馈循环：模拟用户能够在交互中持续对Agent的问询、建议或输出进行响应，从而迫使Agent执行澄清、探索或错误纠正等决策。
• 桥接评测与真实行为分布：尽管模拟不能完全复刻真实用户的全部行为分布，但通过引入结构化的用户行为模型，可以使得评测结果更接近系统在实际部署中的交互需求。

在一些任务中，真实性是首要目标。例如，在对话型助手或客服Agent的评测中，用户行为的语言风格、意图变化方式、信息提供的不完整性，都会直接影响Agent的策略选择。如果用户模拟严重偏离真实用户分布，评测结果很容易高估系统能力。另一方面，也有一类评测将用户模拟作为压力生成器。例如在交互博弈、协商、或多轮澄清任务中，研究者往往刻意引入指令歧义、目标频繁变更、前后不一致的反馈。其目的主要是放大Agent在意图追踪、上下文维护与策略一致性方面的缺陷。因此，用户模拟的设计应服务于具体评测目标：在强调能力估计与系统可用性的场景中，应尽量贴近真实用户分布；而在强调缺陷暴露与鲁棒性分析的场景中，则可以有意识地引入偏离与对抗，以放大关键行为差异。

环境的真实性会直接影响评测结果#

REAL: Benchmarking AutonomousAgents on Deterministic Simulations of Real Websites 复制了11个真实网站场景，包含112个日常交互任务，并对多个前沿 LLMAgent进行了测试。结果显示，即便是最先进的模型，其总体成功率在这种真实网站仿真上最高仅有约 41%，明显低于常见的简化或静态环境评测结果。环境真实性可以体现在：

软件OS

真实环境不是干净的，而是充满历史包袱和底层约束的。

• 依赖深度耦合：Agent要具备像真人工程师一样处理“编译报错”等问题的能力。
• 工具链的不完整： Agent需要适应环境，能通过包管理器完成自主安装，
• 权限与安全边界： Agent 必须在受限条件寻找解决路径。

真实环境不是孤岛，而是处于复杂的交互网中。

• 非理想态： 包括网络抖动、高延迟、DNS 解析失败以及 API 的频控限制等。考察 Agent 是否具备容错处理（重试、退避策略）的逻辑。
• 外部服务的一致性： 环境提供真实的数据库、缓存或消息队列，而非Mock 数据。Agent 的操作会真实改变这些服务的状态。

状态需要持续演进，真实环境是有记忆的，操作是不可逆的。

• 环境漂移： Agent 之前的操作（如下载的文件、修改的环境变量）会污染后续任务。真实性体现在它必须学会“清理现场”或在“污染的环境”中继续工作。
• 非确定性反馈： 同样的命令在不同负载下返回时间不同。环境不能为了适配 Agent 而过度简化输出，应保留原始的、包含大量噪音和 Warning 的日志，考察Agent的信息提取能力。

Web类

真实的网页不是静态的代码块，而是高度不确定的动态实体。

• 渲染延迟： 真实的 Web 环境中，数据是通过异步 API 加载的。Agent 能会在按钮还没渲染出来时就尝试点击。环境真实性要求模拟这种加载延迟，测试 Agent 是否有等待逻辑。
• 深度体现： 评测环境不应为了模型方便而提供干净的简化 HTML，而应提供包含大量广告、弹窗、追踪代码和嵌套 iframe 的原始 DOM 树。

身份验证与会话持久性

• 真实环境会有登录过期、验证码等策略。环境是否模拟了“登录被登出”或“账号被限流”的情况，迫使 Agent 去处理重新登录逻辑。

在Agent评测中，引入Docker等容器化技术通常被视为解决环境一致性的关键手段。比如Swe-Bench通过Docker将测试框架、编译工具、运行时库在镜像中预先确定，减少因环境漂移造成的结果差异。但MiMo-V2-Flash在分析Agent在 SWE-bench 上的表现时明确指出：在非严格隔离的评测设置中，环境残留（如依赖缓存、构建产物、文件状态）会抬高后续任务的成功率，但这种提升并不来自Agent能力本身。具体来说，在多轮 patch / test 循环中，如果repo状态、依赖安装或测试产物未被完全回滚，Agent会间接继承前一次运行的成果，从而造成性能虚高。这也是 SWE-bench-Live 之后强调对评测中的每一个任务实例，提供彼此完全隔离、独立的执行环境，在该实例内部不回滚行为，但在实例之间不共享任何状态。

因此在Agent评测中，应当明确将环境清理是否彻底作为评测前置校验项，而非工程假设，包括：

• 使用 per-task container / sandbox，而非session 级别复用
• 明确区分：Agent合法写入的“记忆”与环境侧隐式残留（cache / artifact / temp file）

6.3 过程观测与trace采集：看见中间发生了什么#

在Agent系统中，Trace 的目标不是尽可能多地记录信息，而是以最小但结构化的方式，完整还原一次任务推进的行为路径。系统中每一个具有语义意义的行为，都被视为一个可被观测、可被串联的事件节点。这些过程信息支撑了多种评测需求：它们是过程评估的直接依据，是失败分析与误判排查的基础，也为后续的长期行为观察提供原始素材。

比较有代表性的工具是LangSmith，其设计核心目标是让开发者能够清晰地看到一个 LLM / Agent 系统是如何被执行的。在LangSmith中，一次运行会拆解为一系列有结构的调用过程，并通过 trace / span 的形式呈现出来。

• 每一次模型调用、工具调用、链式执行都会被记录为一个 Run / Span
• 各个步骤之间通过父子关系连接，形成一棵清晰的调用树
• 用户可以直观看到谁调用了谁、执行顺序是什么、在哪一步失败或变慢

Langfuse同样提供对 LLM / Agent 执行过程的记录能力，并且进一步支持对行为进行标注和统计分析，包括

• 对多次运行结果进行聚合
• 对行为进行分类与统计
• 支持离线评测和质量分析

（更多LangSmith与Langfuse区别）

需要注意的是，Trace本身并不是评测指标。它的价值在于为后续能力提供基础，包括但不限于：过程一致性评估（是否频繁反复 / 震荡）、决策合理性审计（是否在错误条件下触发关键行为）、失败归因（模型问题 vs 工具问题 vs 环境问题）、长期行为漂移监测（在 Governance 层面尤为关键）。

而过程评估并不等同于对子模块逐一打分。更多多时候它关注的是路径本身：哪些行为被触发、在什么条件下被触发、触发后系统如何继续推进。

6.4 评测配置与对照设计#

随着Agent架构逐渐复杂，一个常见风险是：系统表现的变化并不来自Agent能力本身，而是来自环境、配置或资源投入的变化。因此，在Agent评测中，对照设计（control）与消融实验（ablation）是必要的手段。

如在ToolBench的实验中，一个被观察到现象是只要工具足够强，不同模型的success rate差距会显著缩小。因此评测需要：

• 固定工具集合对Agent策略、规划方式进行对照
• 反过来，在策略不变的情况下，改变工具能力

在真实系统评测中，以下三类变量往往比Agent中的模型能力本身更具决定性，却最容易被忽略：

资源预算对照

• token 上限

评测需要报告：

• 最大步数
• 成功率
• 并行调用数
• 成本曲线
• 重试次数

人工或规则兜底的隐性介入

• 人工确认

这属于外部辅助条件，而非Agent自身能力。

• 容错重试

环境智能水平的变化

• 更智能的搜索引擎

这些变化往往会：

• 更稳定的 API
• 系统性抬高Agent表现
• 更干净的数据接口
• 却无法迁移到其他环境

7. Agent评测飞轮： 从执行观测到失败诊断，再到结构性改进#

在Agent场景中，评测的目标是持续回答系统为什么在这里失败，以及怎样改才能让同类失败更难再次发生。因此，Agent评测是一个运行 → 观测 → 诊断 → 修正 → 再评测的飞轮，并通过这个飞轮压缩失败空间。

7.1 飞轮的输入条件：让失败可解释#

飞轮的起点是Agent在真实环境中的运行行为，为了让评测具备可解释性，Agent必须在受控配置下运行。否则，当性能发生变化时将无法判断改进来自模型本身，还是系统配置的改变。

在实际工程中，随着Agent架构日益复杂，性能往往并非由模型能力单独决定，而是受到多种外部因素共同影响，例如环境设定、工具能力、资源预算以及兜底策略等。如第 5 章所述，这些因素的变化本身就足以显著改变系统表现。

因此，评测需要明确区分并固定以下关键要素：

• Agent 架构本身（是否启用记忆、反思、多 Agent 协作等）
• 工具集合与接口能力
• 资源预算（如 token 上限、执行步数、重试策略）
• 外部兜底与规则系统

如果在失败发生时无法明确是哪些条件导致了失败，那么该失败对系统改进几乎没有价值。进一步地，飞轮机制强依赖于可追溯的执行轨迹：只有当失败能够被还原为清晰的“行为路径”，才能定位问题来源、抽象失败模式，并将其转化为可复用的改进策略。否则，失败只是一次孤立事件，无法驱动系统演化。

7.2 飞轮的核心引擎：把失败变成可复用的诊断结论#

有了执行轨迹，我们需要设计合理分析方法来衡量Agent行为过程的以及完成结果质量。首先Tackling the “Partial Completion” Problem in LLM AIAgents指出LLM经常存在部分完成的问题，面对包含多子任务的复杂指令时，模型往往只完成其中一部分就停止。在一次针对多步骤任务的评测中，即便表现最好的Claude 3.5模型也仅能完全完成24%的任务，因此，评估首先不仅要看是否完成，还应量化完成度，区分完全成功、部分成功或失败。

另一个重要方面是漂移检测，即发现Agent在执行过程中是否跑题或停滞不前。例如，在WebArena代理的轨迹分析What we’ve learned from analyzing hundreds of AI webAgent traces中，死循环（Looping）被发现是最常见的问题之一：即代理可能陷入重复点击同一按钮的死循环。通过检测trace中重复动作的模式，可以自动识别出这些陷入循环的情况，从而判断Agent已偏离了有效进展。

通过路径分析把成功或失败归因到轨迹中的具体决策步骤或环境因素，对改进Agent很有帮助。WebArena在判断任务成功时不仅检查Agent最终输出，还通过程序化的状态检查和数据库验证等手段核对代理是否真正完成了中间所需的操作。AgentBench的研究通过系统评测不同模型在多环境任务中的细粒度表现，归纳出失败往往源于模型长程推理不足、决策不当或指令遵循不佳等原因。Invariant Labs分析了上百条网页代理轨迹后，除了上述提到的死循环，也总结出起几类其他主要失败模式：比如幻觉（hallucinations，即编造不存在的信息）、环境错误（如界面元素异常导致操作无效）、忽略部分指令等。

进一步Why Do Multi-Agent LLM Systems Fail? 把Multi-Agent的失败归类为：协调失败：局部合理但全局不收敛、角色错位：职责理解与系统设定不一致、责任扩散：关键子任务无人真正承担、错误放大/误导性反馈闭环：错误中间结论被反复确认、层层强化。通过这样的路径分析，我们可以总结并针对不同失败类型制定更具体的诊断和改进策略。

综上，飞轮真正转起来，不是因为记录了很多 Trace，而是因为能把失败从一个 case提升为一个模式。这里我们将归因粗略分层为能力、策略、结构、环境四类：

分类

表现

本质

评测特征

能力型失败（推理/规划/理解不足）

目标理解失败

• 错误理解任务约束

任务语义建模错误，后续决策全部在“错误前提”上展开。

• Trace中早期就出现目标偏移
• 子目标偏离原始目标
• 后续步骤逻辑自洽，但整体不符合任务要求
• 过早认为任务已完成

状态维护失败

• 遗忘早期关键信息

跨时间区间的一致性断裂。

• 前后决策假设不一致
• 信息在Agent间传递后被扭曲
• 性能随Agent数增加而下降
• 决策链条过长，反馈滞后

交互型失败

工具选择失败

• 选择了不合适的工具

决策到工具映射关系错误。

• Trace 中工具调用与任务目标弱相关
• 忽略更直接或更安全的工具路径

（Web/工具接口不稳定、不可操作）

• 更换工具集合后性能大幅变化

工具使用失败

• 参数设定不当

对工具语义或接口规范理解不足。

• 重试多次仍无法推进状态
• 调用格式错误
• 错误集中在工具调用节点
• 调用成功但效果无效

环境诱发失败

• 界面不可操作

环境能力与Agent假设不匹配。

• 同一策略在不同环境稳定性差异巨大
• 状态不可观测
• 合法操作被环境拒绝执行

通常，我们可以借助额外的诊断Agent或脚本，必要时候引入人工进行失败的诊断分析。

7.3 飞轮的输出验证：从失败诊断到可验证改进#

能力型修正：从模型规模到可验证推理能力#

当系统失败被归因为规划、目标理解失败时，最简单的想法是是提升底层模型能力。Invariant Labs 的研究显示，在相同系统设计下，用更强的基础模型替换较弱模型，可以在多个Agent任务中立即带来性能提升。这一现象与Rich Sutton提出的“The Bitter Lesson”高度一致：在长期尺度上，增加计算与数据往往比精巧的算法设计更有效。除模型替换外，能力层修正还包括：

• 通过强化学习或对齐训练，提升模型对复杂指令的遵循能力
• 针对特定任务或工具场景进行SFT，弥补长程规划或格式化输出上的系统性不足

另一类重要修正方向是记忆修正，主要针对长程任务中的遗忘、状态污染与重复犯错问题。典型做法包括：

• 引入外部记忆机制（如向量数据库）保存中间结果，供后续步骤查询
• 优化 prompt 结构，使关键信息在多步执行中保持可见

在一些长程任务、复杂约束、代码修复任务中，修正还需要验证闭环辅助。如SWE-bench类任务的经验强调提升不只靠生成，更关键是把流程变成“规划—编辑—测试—再修正”的闭环；否则很多改动不可验证，失败难以定位。对策可以是：

• 引入显式规划/分解
• 引入可检验的中间目标与验证步骤（例如测试、断言、状态检查）
• 必要时再讨论更强模型/训练

策略型修正：减少错误路径的重复#

如Reflexion的设计思路是Agent在每次失败后生成语言层反思，总结错误原因并写入记忆，从而在后续尝试中避免重复同类错误。实验结果表明，在代码生成等任务中，引入Reflexion 后成功率可显著提升。这类方法的核心价值在于将失败转化为经验，阻断错误路径的反复出现，适用于解决：

• 盲目重试、局部修补反复失败
• 在同一类型 case 上持续复现同类错误

需要强调边界如果失败来自结构或环境，反思可能会把错误解释固化为经验，反而更糟。

结构型修正：多Agent优先划责而非加人#

许多研究，如How Multi-Agent Coordination Failures Unleash Dangerous Hallucinations指出，多Agent常见失败不是因为Agent不够多，而是因为责任边界不清、通信协议低效、协作目标不一致。因此修正优先级通常是：

• 明确角色职责与交付物（谁必须产出什么）
• 减少无目标协商回合（把讨论收敛到可执行决策）
• 限制反馈闭环深度（防止错误共识自我强化）
• 再考虑扩大Agent数/复杂度