怎么测一个 Agent

普通软件测试已经够难，Agent 又加了几个量级：输出非确定（同一输入每次结果不同）、多步执行（中间任何一步可能出错）、依赖外部工具（工具变了 Agent 就崩）。很多团队因此放弃测 Agent，全靠手动试——上线靠运气。

这篇给一套可落地的 Agent 测试策略，分层覆盖。

一、Agent 测试的难点

先正视难点：

• 非确定性：assert "输出等于 X" 几乎不可行。
• 多步链路：Agent 一次任务调多次模型/工具，错在任何一步。
• 外部依赖：工具连真实服务，测试不该真发邮件/真转账。
• 成本：跑一次 Agent 要花 token，全量测试集跑一遍不便宜。

所以 Agent 测试不能照搬传统单测，要分层、要Stub、要评质量而非等值。

二、分层测试策略

单元(工具)  →  集成(端到端)  →  评测(质量)  →  混沌(容错)

四层各有重点。

三、第一层：单元测试（工具函数）

Agent 的工具（search、query_db、send_email）是确定性函数，正常做单测：

• 参数校验对不对（非法参数抛错）。
• 正常输入返回对不对。
• 边界（空输入、超长、特殊字符）。
• 错误处理（上游失败时返回可读错误）。

test("query_order rejects other user's order", async () => {
  await expect(queryOrder({ id: "o_other", userId: "u_me" }))
    .rejects.toThrow("forbidden");
});

这一层是基础——Agent 行为不对，先怀疑工具。工具稳了，再测 Agent 编排。

四、第二层：集成测试（端到端，但 Stub 模型/工具）

测整个 Agent 的编排逻辑：给它任务，看它调对工具、走对流程。难点是非确定，对策是Stub：

• Stub 模型：不让 Agent 真调 LLM（贵+不确定），用一个 mock 返回预设的"工具调用决策"。测的是"给定模型要调 X，编排层会不会正确执行 X 并回灌"。
• Stub 工具：工具不连真实服务（send_email 不真发），返回预设结果。测的是"工具返回 Y 时，Agent 怎么继续"。

test("agent calls search then answers", async () => {
  const agent = createAgent({
    llm: mockLLM([                // 预设模型的两步决策
      { tool: "search", args: { q: "x" } },
      { text: "答案是…" },
    ]),
    tools: { search: async () => "搜索结果…" },
  });
  const result = await agent.run("问个问题");
  expect(result).toContain("答案是");
  expect(toolCalls).toEqual([["search", { q: "x" }]]);
});

这一层验证编排逻辑（顺序、回灌、停止条件），不验证模型智力（那是评测层的事）。

五、第三层：评测集（质量，最关键）

集成测试只测"流程对不对"，测不了"答得好不好"。质量靠评测集：

• 20–100 条 任务 → 期望属性/参考答案。
• 每次改 Agent（prompt/模型/工具）跑一遍。
• 用 LLM-as-judge 或规则打分。

指标按 Agent 类型选：

• 正确性：答案对不对（对比参考答案/关键事实）。
• 格式合规：该输出 JSON 时是否合法、字段全。
• 安全：不该做的操作有没有做（越权、泄露）。
• 效率：平均步数、token 消耗（同样的活步数变多 = 退化）。

这一层是 Agent 质量的真正保障。没有评测集的 Agent，改 prompt 全凭感觉；有了它，改动可回归。

六、第四层：混沌测试（容错）

Agent 在真实环境跑，工具会失败、模型会超时、网络会断。测它在故障下还稳不稳：

• 模拟工具失败：让 search 随机返回错误，看 Agent 能不能优雅处理（重试/换路/告知用户），而不是崩。
• 模拟模型超时：看超时机制生效、fallback 触发。
• 模拟返回异常：工具返回非法 JSON，看 Agent 能不能恢复。

混沌测试揭露"快乐路径测试"覆盖不到的脆弱点。Agent 的生产事故，多数不是正常流程崩，而是某个工具偶发失败导致 Agent 跑飞。

七、用 trace 复现 bad case

Agent 出 bug，最难的是复现（非确定）。解决：每次运行录 trace（每步的输入/输出/工具调用），出问题时用 trace 重放。

• trace 让你能精确看到"第几步、哪个模型调用、什么 prompt、什么返回"出了问题。
• 对特别难复现的，把 trace 转成回归测试（固定那次运行的工具返回，测编排层）。

没有 trace 的 Agent，调试全靠玄学。trace 是 Agent 可调试性的根基。

八、成本控制

跑 Agent 测试要花 token，控制：

• CI 用便宜模型：评测集跑在 Haiku/Mini 上（验证流程 + 粗略质量），正式评测用强模型。
• 采样：不改 Agent 的 PR 不跑全量评测（只跑集成测试）。
• 缓存：工具的 mock 结果缓存，模型对相同输入的输出缓存（评测复跑时省）。

九、一个最小起步

别一上来铺四层全做，按这个顺序：

1. 先建工具单测（最便宜、最基础）。
2. 加端到端集成测试（Stub 模型/工具），覆盖核心场景。
3. 建一个 20 条的评测集，每次改 prompt/模型跑一遍。
4. trace 上线，开始积累 bad case。
5. 混沌测试，等 Agent 稳定后加。

前三步投入小、收益大，能让你的 Agent 从"上线靠运气"到"上线有底气"。

小结

Agent 测试要分层，不能用传统单测硬套：

• 单元测工具（确定性，正常测）。
• 集成测编排（Stub 模型/工具，测流程）。
• 评测集测质量（最关键，质量可回归）。
• 混沌测容错（故障下的鲁棒性）。
• trace 复现 bad case，转回归。

记住一句：Agent 的非确定性不等于"测不了"，而是"换种方式测"。把这套分层策略落地，你的 Agent 才能从"demo 能跑"走到"生产可信赖"——这件事的价值，怎么强调都不过分。