很早之前就想写一篇关于如何测试一个 agent 的文章，一直拖到现在，在这里我将分出十篇文章，来回答” 如何测试一个 agent？“这个比较大的问题

本篇主题

第一篇我想讲一下 agent 的评测和观测有什么区别，该怎么做。

首先，很多人测试 Agent 时，第一反应是看最后回答对不对。但这是远远不够的，对 LLM 来说，黑盒状态下我们只能看到 prompt - answer，对于 agent 来说，关键并不在于它会不会生成文本，而在于它会在任务执行过程中做决策：它会读上下文、制定计划、调用工具、更新状态、写入记忆、处理失败，触发兜底策略等等。

如上所说，我们设计不同的 prompt，对 answer 进行一些维度的打分和评估，比如这个答案符不符合预期，写出来的格式对不对，回答风格怎么样，这就是效果评测 (Agent Evaluation)；而我们如果测试它任务执行过程中做的决策，这就是过程观测 (Agent Observation / Trace Analysis)。

一个完整的 Agent 测试体系，至少要同时回答两个问题：效果评测回答 “任务有没有完成”，过程观测回答 “任务是怎么完成的”。

效果评测和 Trace 观测的分工

效果评测关注结果：

• 任务是否完成。
• 输出是否正确、完整、符合格式。
• 业务状态是否达到预期。
• 用户是否可接受。
• 成本、耗时、重试次数是否在阈值内。

Trace 观测关注过程：

• Agent 看到了哪些上下文。
• 它做了什么计划。
• 调用了哪些工具。
• 参数是否正确。
• 工具返回是什么。
• 它如何解释 observation。
• 状态如何变化。
• 失败后如何恢复。
• 是否触发权限、审批或安全拦截。

效果评测像验收结果，Trace 观测像调查证据。只看效果，无法定位问题；只看 Trace，没有评分，也无法判断质量是否达标。

常见失败模式

常见问题不要只按 “答对 / 答错” 分类，而要按证据缺口分类：

• 最终答案正确但过程违规：例如调用了不该调用的工具、读取了越权数据，或者没有按标准流程执行。需要看 tool call、permission decision 和 audit trace。
• 最终答案错误但原因不明：通常是只保存了输出，没有保存中间步骤。需要补齐 trace/span、工具返回和上下文快照。
• 成功不可复现：换模型、换 prompt 或换环境后结果漂移。需要记录 dataset、model、prompt、tool 的版本。
• 失败被包装成成功：工具已经返回错误，Agent 仍继续编出 “已完成”。需要检查 tool error 和 final answer grounding。
• 评测无法回归：没有 case、baseline 和固定 rubric，导致每次都只能人工重看。需要 case YAML、score、report 和 artifact。

应该设计哪些测试样本

第一批样本不要只放成功路径。一个最小 Agent 评测集至少要覆盖：

• 正常成功任务：验证主流程是否跑通。
• 缺少上下文任务：验证 Agent 是否会追问或检索。
• 干扰上下文任务：验证是否被无关信息带偏。
• 工具失败任务：验证是否重试、换工具或停止。
• 权限不足任务：验证是否请求审批或拒绝。
• 长任务任务：验证 context、state、memory 能否维持。
• 禁止动作任务：验证安全边界是否生效。
• 回归任务：验证改模型、prompt、工具 schema 后是否退化。

Trace / Span 应该记录什么

一个最小 trace 应至少包含：

• task_id、run_id、dataset_id。
• 用户输入、任务目标、成功标准。
• 模型、prompt、工具列表、权限配置。
• 每个 LLM turn。
• 每个 tool call 的工具名、参数摘要、返回摘要、错误、耗时。
• state before / state after。
• checkpoint、retry、approval、denial。
• final answer、score、人工复核结论。

OpenTelemetry 的通用模型里，trace 是完整链路，span 是其中一次操作。迁移到 Agent 测试里，可以把一次任务作为 trace，把模型调用、工具调用、检索、审批、状态更新和评分都作为 span。

如何评分

不要只给一个总分。建议从一开始就拆成多层：

• 任务级：任务有没有完成，业务状态是否达到成功标准。
• 结果级：输出是否正确、完整、格式合规，并满足业务约束。
• 轨迹级：步骤是否合理、可解释、可复盘。
• 工具级：工具选择、参数、顺序和工具结果使用是否正确。
• 状态级：任务进度和中间结果是否一致。
• 记忆级：跨任务信息是否正确写入和使用。
• 安全级：是否出现越权、泄露、注入或审批绕过。
• 成本级：token、耗时、重试次数和失败率是否在阈值内。

最小案例

任务：让一个代码 Agent 修复登录失败 bug。

最低可接受 Trace：

task: 修复登录失败 bug
context: 读取 auth 模块、测试文件、错误日志
plan: 先复现失败，再定位原因，再修改，再跑测试
tool: Bash npm test -> Read auth.ts -> Edit auth.ts -> Bash npm test
observe: 第一次测试失败，第二次测试通过
state: failing -> investigating -> patched -> verified
score: result_pass=true, tool_args_pass=true, trace_pass=true

如果最终回答说 “已修复”，但 trace 里没有测试命令、没有文件 diff、没有错误输出，那就不能算完整通过。

Checklist

• 是否定义了 task run，而不是只定义 prompt。
• 是否同时评估最终结果和中间轨迹。
• 是否保存了工具调用参数、返回、错误和耗时。
• 是否能从失败样本追溯到模型、工具、数据、权限或状态问题。
• 是否区分 Context、State、Memory。
• 是否有 golden case、失败 case 和安全边界 case。
• 是否有人工复核入口。
• 是否能做 baseline 和 candidate 对比。 ## Agent Loop 里的位置

从 Claude Code 官方文档看，一次 agentic loop 可以简化成三段：gather context、take action、verify results。Agent SDK 的 loop 则进一步拆成：接收 prompt，模型评估并返回文本或工具调用，执行工具，把工具结果反馈给模型，循环直到没有工具调用，再返回最终结果。

在测试视角里，可以把它改写成：

Task
-> Context
-> Plan
-> Tool / Act
-> Observe
-> State
-> Memory
-> Failure Recovery
-> Safety
-> Regression

这个顺序不是为了画漂亮流程图，而是为了提醒测试人员：Agent 的质量问题可能发生在任意中间环节。上下文拿错，计划再漂亮也会偏；工具参数错，最终答案可能只是编得像；状态更新错，下一轮会重复执行；记忆写错，后续任务会被污染。