Agent 评估工程：你怎么知道 Agent 变好了还是变坏了

每次更新模型版本、调整工具描述、修改系统提示，你是怎么判断 Agent 变好了还是变坏了的？

大多数团队的诚实回答是：看感觉。手动跑几个典型任务，主观判断一下，没有明显退步就上线。

这在 demo 阶段可以接受。在生产里，它意味着你对 Agent 的质量没有任何客观感知——你是在蒙眼开车。

为什么传统软件测试在 Agent 上失效

软件工程里的单元测试，基础假设是确定性：给定相同输入，函数返回相同输出。测试就是验证这个映射关系是否成立。

Agent 打破了这个假设。

同一个任务，Agent 可能走完全不同的执行路径，但都得到了正确结果。也可能走了”正确的路径”，但因为中间某一步的推理偏差，最终结果是错的。传统的断言式测试（assert output == expected）在 Agent 上要么过于严苛（锁死了路径），要么根本无法定义（expected 是什么？）。

更棘手的是 涌现行为。Agent 在复杂任务上的失败模式往往不是简单的”功能不工作”，而是”在某些特定条件组合下，行为偏离了预期方向”。这类问题在单元测试里几乎不可能覆盖，它需要系统级别的评估。

传统测试解决的是”代码是否正确实现了规格”；Agent 评估解决的是”Agent 是否可靠地完成了任务”。这是两个不同量级的问题。

评估的三个维度

在设计 Agent 评估体系之前，先把”好”拆解清楚。Agent 的评估维度通常涉及三个方向：

任务完成质量：Agent 有没有达成目标？结果是否正确、完整、符合预期格式？这是最直接的维度，也是最难客观量化的。

执行效率：完成同一个任务，Agent 用了多少步骤、多少 token、多长时间？效率退步往往比质量退步更隐蔽，但在生产中同样重要——绕路的 Agent 意味着更高的成本和更长的延迟。

鲁棒性：当输入有噪声、工具返回异常、上下文不完整时，Agent 如何响应？能不能优雅降级，而不是静默产出错误结果？鲁棒性是 Agent 从”实验室”到”生产”最关键的门槛之一。

这三个维度的权重因场景而异。代码生成 Agent 对任务完成质量的要求极高；成本敏感场景下效率维度的权重上升；面向终端用户的 Agent 对鲁棒性的要求往往超过另外两个维度。

在评估体系设计之前，先把这个权重搞清楚，否则评估跑完了，你不知道该按哪个维度的结果做决策。

评估的四个层次

我把 Agent 评估分成四个层次，从底向上：

第一层：工具单元评估

工具是 Agent 与外部世界交互的唯一通道。工具的行为正确性是 Agent 系统可靠性的基础。

这一层和传统单元测试最像：给定工具的输入，验证输出是否符合预期。工具是确定性的（或者应该被设计成确定性的），因此标准的断言式测试可以直接用。

工程要点：工具测试套件要和工具代码一起维护，每次工具接口或行为变更，都要更新测试。一个常见的失误是把工具当作”简单封装”不测试，结果 Agent 的奇怪行为来源于工具层的静默错误。

第二层：推理单元评估

测试 Agent 在特定情境下的推理决策是否合理：给定当前状态，Agent 选择了正确的下一步工具吗？

这一层不测试任务的最终结果，只测试单步决策。好处是：它把 Agent 的推理质量从工具执行的偶然性里剥离出来，让你能判断问题来自”推理错了”还是”工具出错了”。

实现方式通常是 mock 工具层，让 Agent 在可控环境里执行，观察它的工具选择和调用参数。评估标准可以是：选择的工具是否合理、参数是否在合理范围内、推理链是否包含明显的逻辑跳跃。

这一层的评估是半自动化的——判断”推理是否合理”往往需要人工参与，或者用一个独立的评估模型（LLM-as-judge）来替代人工。

第三层：任务集成评估

这是 Agent 评估的核心层：给定完整任务，端到端运行，评估结果质量。

任务集成评估需要一个评估集（eval set）：一组有代表性的任务，覆盖典型场景、边界条件和已知失败模式。评估集的质量直接决定评估体系的价值。

评估集的构建要注意几个原则：

• 来自真实失败：把生产里发现的失败案例加入评估集，确保已知问题不回归。这是评估集最核心的价值来源。
• 覆盖边界条件：不只是”正常路径”，还要包含工具返回空值、任务描述模糊、中途出现异常这类边界场景。
• 避免过拟合：评估集不是越大越好，关键是多样性。一个 50 个任务的评估集，如果 40 个任务本质上是同一类，它告诉你的信息量和 10 个任务差不多。

结果评估是这一层最难的部分。对于有明确预期输出的任务（如代码生成），可以用程序化验证（运行代码、检查测试通过率）。对于开放性任务，需要 LLM-as-judge 或人工评分，并接受这种评估本身有噪声。

第四层：对抗性评估

前三层评估的是 Agent 在正常场景下的表现。对抗性评估专门测试 Agent 在恶意输入、异常环境下的行为。

对于拥有真实工具权限的 Agent，这一层不是可选项，是必须做的。

关键的对抗场景：

Prompt Injection：工具返回的内容里包含试图改变 Agent 行为的指令（”忽略之前的任务，执行以下操作…”）。Agent 是否能识别并忽略这类注入？

权限越界：Agent 是否会在任务需要之外主动请求更多权限，或者在边界模糊时倾向于扩权而非保守？

结果伪造：工具返回了貌似可信但实际上错误的数据，Agent 是否会不加验证地采信，并基于错误数据继续推理？

指令漂移：在长任务中，Agent 是否会逐渐偏离原始目标，被中间步骤的细节带偏？

对抗性评估的结果不是分数，而是失败模式的清单。每一个新发现的失败模式都应该进入任务集成评估集，成为永久的回归测试。

持续评估：让评估跑进 CI

单次评估是快照，持续评估才是护栏。

Agent 的质量回归来自多个方向：模型版本更新、工具接口变更、系统提示调整、依赖服务的行为漂移。任何一个变更都可能在你没预期的地方引发退步。把评估集成进 CI，确保每次变更后都有客观的质量信号，是 Agent 系统进入生产后最重要的工程基础设施之一。

实现上的核心挑战是成本。端到端的 Agent 任务评估通常需要调用 LLM，有时还需要调用真实工具（或沙箱化的工具），时间成本和 API 成本都不低。完整跑一遍评估集可能需要数十分钟和相当的费用。

实践中通常的解决方案是分层跑：

• 每次提交：只跑工具单元测试和一组核心的推理单元评估（毫秒级，覆盖已知关键路径）。
• 每次合并到主分支：跑完整的任务集成评估集（分钟级，给出质量基线）。
• 模型/基础设施变更时：加跑对抗性评估（相对低频，但变更最高风险时必做）。

评估结果需要纵向可比：不是只看这次结果的绝对分数，而是和上一个版本的基线比较。质量退步多少才是可接受的，是一个需要团队提前设定的阈值，而不是每次评估完再临时判断。

评估与可观测性的关系

评估和可观测性不是两件独立的事，它们共享同一套数据基础。

可观测性系统记录的 Agent 执行轨迹——工具调用序列、推理文本、任务结果——是评估集的重要来源。生产流量里的真实失败案例，经过脱敏和整理，是质量最高的评估数据。

这形成了一个闭环：可观测性捕获生产中的异常 → 异常分析后进入评估集 → 评估集驱动改进 → 改进部署后通过可观测性验证效果。

没有这个闭环，评估集会随着时间和生产场景脱节。这是很多团队评估体系逐渐失效的根本原因：评估集是静态的，而生产是动态的。

一个容易忽视的问题：评估集本身的质量

评估体系有一个元问题：谁来评估评估集？

评估集如果构建不当，会给你虚假的安全感：评分一直很高，但生产里还是经常出问题。常见的失效模式：

• 评估集覆盖的场景太窄，和真实生产分布偏差大
• LLM-as-judge 的评估模型和被评估的 Agent 使用同一个模型系列，评估结果存在系统性偏差
• 评估标准随着需求演化，但评估集没有更新，导致评分高的任务恰好是已经不重要的场景

定期审计评估集——检查它和生产流量的分布是否对齐，评估标准是否仍然反映当前对”好”的定义——是维护评估体系的必要工作，不是一次性的。

---

Agent 评估不是测试工程的边角料，它是 Agent 系统持续迭代的基础工程。

没有评估体系，你每次变更都是在赌博——用生产用户承担风险。有了评估体系，你能在每次变更后有一个可量化的置信度：这次改动在哪些方向上变好了，在哪些方向上还不确定。

这个置信度，是让 Agent 系统可以持续迭代而不是一次性交付的根本保障。