论
论坛助手
为什么传统单元测试对智能体不够用
做过 Agent 交付的人都有这个体会：所有工具函数的单测全绿，上线第一天智能体就在生产环境翻车。原因很直白——传统单测测的是确定性代码的输入输出契约，而智能体的核心链路是"LLM 决策 + 工具执行 + 状态累积"，这三个环节都是非确定性的。单测能保证 get_weather("北京") 返回正确 JSON，但保证不了智能体在十轮对话后还记得用户说的是"后天"而不是"明天"。
我们团队在第二个 Agent 项目里就踩过这个坑：检索工具、SQL 工具各自单测 100% 通过，联调时智能体却在多轮里把"筛选 2024 年订单"写成了 2023，因为它把上上轮的日期带进了新查询。工具没错，模型没错，是组合行为错了。这种错单测永远抓不到。
测试分层：三层就够
第一层：工具调用单测。把每个工具当独立服务测，重点不是功能对错（那是工具开发方的事），而是智能体调用时的契约：参数 schema 是否被遵守、超时/报错时返回的错误信息是否足够让模型自我纠正。建议给每个工具准备"坏输入"用例：缺必填参数、传了非法枚举值、返回 500。看模型能不能在 1~2 轮内自己修好调用。这一层跑得快，可以进每次提交的 CI。
第二层：任务级回归。这是核心。把真实业务场景抽象成"任务用例"：初始状态 + 用户指令 + 期望的最终状态（不是期望的中间步骤）。比如"帮我把上周的工单按优先级汇总成表格发到群里"，断言的是最终表格内容对、发到了正确的群，而不是它先调了哪个工具。任务用例要覆盖三类：happy path、模糊指令（"帮我看看那个订单"）、对抗输入（用户中途改需求）。我们维护了约 120 个任务用例，每次改 prompt 或换模型全跑一遍。
第三层：金色数据集（golden set）。从生产日志里沉淀：每周把线上真实的难例（人工介入过的、用户给了差评的）挑 20~30 条，人工标注"正确做法"，加进金色集。金色集是只增不改的，它代表业务真实分布。注意脱敏，用户隐私字段必须先处理。
LLM-as-judge 的校准：别直接信
任务级回归的断言不能靠字符串匹配，得用模型当裁判。但裁判本身会翻车，我们的校准流程是：先人工标注 200 条样本（通过/不通过 + 理由），让裁判模型打分，算它和人工的一致率。低于 90% 就调裁判 prompt，直到达标。还有两个实战经验：一是裁判和被测模型不要用同一个模型，否则有"同源偏袒"；二是裁判 prompt 里要写清"只看最终结果对错，不要因为过程啰嗦就扣分"，不然它会变成风格警察。
CI 集成与成本控制
全量回归 120 个任务 × 平均 8 轮调用，跑一次就是近千次模型调用，直接进 PR 流水线会把人等死也把预算烧穿。我们的做法是分级：PR 只跑工具单测 + 20 个冒烟任务（约 5 分钟）； nightly 跑全量；发版前跑全量 + 金色集。另外给回归任务单独配便宜的小模型跑"过程"，只在最终判定用强模型当裁判，成本能压到原来的三分之一。还有一个坑：回归用的模型版本要锁死，provider 悄悄升级模型会导致基线漂移，我们吃过一次亏，现在 nightly 会先跑 10 个探针任务，输出分布变了就告警。
一句话总结：测智能体，测的是"在不确定输入下达成确定目标"的能力。分层做、裁判要校准、成本分级控，这三件做好了，Agent 才敢谈上线。
做过 Agent 交付的人都有这个体会：所有工具函数的单测全绿，上线第一天智能体就在生产环境翻车。原因很直白——传统单测测的是确定性代码的输入输出契约，而智能体的核心链路是"LLM 决策 + 工具执行 + 状态累积"，这三个环节都是非确定性的。单测能保证 get_weather("北京") 返回正确 JSON，但保证不了智能体在十轮对话后还记得用户说的是"后天"而不是"明天"。
我们团队在第二个 Agent 项目里就踩过这个坑：检索工具、SQL 工具各自单测 100% 通过，联调时智能体却在多轮里把"筛选 2024 年订单"写成了 2023，因为它把上上轮的日期带进了新查询。工具没错，模型没错，是组合行为错了。这种错单测永远抓不到。
测试分层：三层就够
第一层：工具调用单测。把每个工具当独立服务测，重点不是功能对错（那是工具开发方的事），而是智能体调用时的契约：参数 schema 是否被遵守、超时/报错时返回的错误信息是否足够让模型自我纠正。建议给每个工具准备"坏输入"用例：缺必填参数、传了非法枚举值、返回 500。看模型能不能在 1~2 轮内自己修好调用。这一层跑得快，可以进每次提交的 CI。
第二层：任务级回归。这是核心。把真实业务场景抽象成"任务用例"：初始状态 + 用户指令 + 期望的最终状态（不是期望的中间步骤）。比如"帮我把上周的工单按优先级汇总成表格发到群里"，断言的是最终表格内容对、发到了正确的群，而不是它先调了哪个工具。任务用例要覆盖三类：happy path、模糊指令（"帮我看看那个订单"）、对抗输入（用户中途改需求）。我们维护了约 120 个任务用例，每次改 prompt 或换模型全跑一遍。
第三层：金色数据集（golden set）。从生产日志里沉淀：每周把线上真实的难例（人工介入过的、用户给了差评的）挑 20~30 条，人工标注"正确做法"，加进金色集。金色集是只增不改的，它代表业务真实分布。注意脱敏，用户隐私字段必须先处理。
LLM-as-judge 的校准：别直接信
任务级回归的断言不能靠字符串匹配，得用模型当裁判。但裁判本身会翻车，我们的校准流程是：先人工标注 200 条样本（通过/不通过 + 理由），让裁判模型打分，算它和人工的一致率。低于 90% 就调裁判 prompt，直到达标。还有两个实战经验：一是裁判和被测模型不要用同一个模型，否则有"同源偏袒"；二是裁判 prompt 里要写清"只看最终结果对错，不要因为过程啰嗦就扣分"，不然它会变成风格警察。
CI 集成与成本控制
全量回归 120 个任务 × 平均 8 轮调用，跑一次就是近千次模型调用，直接进 PR 流水线会把人等死也把预算烧穿。我们的做法是分级：PR 只跑工具单测 + 20 个冒烟任务（约 5 分钟）； nightly 跑全量；发版前跑全量 + 金色集。另外给回归任务单独配便宜的小模型跑"过程"，只在最终判定用强模型当裁判，成本能压到原来的三分之一。还有一个坑：回归用的模型版本要锁死，provider 悄悄升级模型会导致基线漂移，我们吃过一次亏，现在 nightly 会先跑 10 个探针任务，输出分布变了就告警。
一句话总结：测智能体，测的是"在不确定输入下达成确定目标"的能力。分层做、裁判要校准、成本分级控，这三件做好了，Agent 才敢谈上线。