当一个 Agent 项目还很早期时，很多人会说：

  • 先别写测试，先把功能做出来

这句话在最开始的 1 到 2 周通常没问题。
但一旦系统已经开始具备这些能力：

  • 多步骤流程
  • 人工审批
  • 多轮反馈
  • 冲突确认
  • 质量闸门
  • 自动回炉

如果还完全不补测试，后面的迭代成本会迅速上升。

所以这章要讲的是：

Agent 项目的自动化测试，应该从哪里开始补，补什么最值，怎么结合当前项目落地。

为什么 Agent 项目特别容易“改着改着就坏了”

这类项目的特殊之处在于，它不只是普通 CRUD，也不只是单次模型调用。
它有很多“流程语义”。

比如当前项目里就有很多非常容易被改坏的地方：

  • rewrite 后是不是一定会触发自动回炉
  • 自动回炉成功后是不是一定会走第二次 Reviewer
  • 冲突确认后是不是一定会写回 effective_feedback
  • 进入审批点后旧错误态是不是会被清空

这些东西都不是靠看一眼页面就能长期保证正确的。

所以测试在这里的价值，不是追求形式上的覆盖率，而是：

把最关键的流程语义锁住。

当前项目为什么现在正是补测试的合适时机

一个很现实的判断标准是：

如果你的系统已经有一些“不是一眼就能看懂”的流程逻辑，就该开始补测试了。

当前项目已经明显到了这个阶段。

因为它不再只是：

  • 创建任务
  • 调模型
  • 输出结果

而是已经有了：

  • 失败重试
  • 自动回炉
  • 冲突确认
  • 上下文状态写回
  • 审批恢复

这些能力一旦没有测试保护，后续稍微改一点流程代码，就可能把关键语义弄坏。

Agent 项目补测试，第一步不要追求“全测”

这是非常重要的一点。

很多人一想到测试，就会进入两个极端：

极端一：完全不写

结果就是每次改逻辑都只能手工点一遍页面，成本越来越高。

极端二：一上来就想把所有页面、所有接口、所有模型调用全测了

结果很容易把自己拖进“测试工程比业务工程还大”的状态。

当前项目更适合的路线是：

先测最关键、最容易被改坏、最值钱的流程语义。

当前项目最近先补了哪些测试

当前项目已经开始做这件事，而且路线很对。

目前已经补上的测试，重点覆盖了三类关键语义。

1. 自动回炉完整闭环

当前已经有测试验证：

  • Reviewer 判定 rewrite
  • 系统触发 reviewer_auto_rewrite
  • 自动回炉 Writer draft
  • 第二次 Reviewer
  • Writer revision
  • 最终停在 revision_done

这条测试的价值非常高，因为它锁住的是一整条复杂流程。

2. 自动回炉阶段参数

当前还专门测试了：

  • 自动回炉 Writer draft 用的是不是更长超时
  • 自动回炉阶段的温度参数有没有按设计传递
  • revision 阶段是不是用了另一组参数

这类测试乍一看很细，但它很有价值，因为这些参数后面很容易被无意改掉。

3. 冲突确认写回有效上下文

当前还补了冲突相关测试，验证：

  • 多轮 reject 会不会触发冲突
  • resolve_pending_conflict() 后
    • pending_conflict 会不会清空
    • effective_feedback 会不会更新
    • 旧问题会不会标记为 resolved

这条测试锁住的是“多轮反馈治理”最关键的语义。

为什么这三类测试最值钱

因为它们都不是简单的“输入输出校验”，而是在保护系统最核心的行为约定。

自动回炉闭环

保护的是：

系统会不会在明显不合格内容上先自救。

自动回炉参数

保护的是：

这次自救是不是用对了策略。

冲突确认写回上下文

保护的是：

多轮修订后的最终标准有没有真正写回系统状态。

这些都属于“如果坏了，用户体验会明显下降”的关键点。

当前项目为什么先用 unittest

当前项目没有一开始引入很重的测试框架，而是先用标准库里的：

  • unittest

这是一个很务实的选择。

原因是：

  • 不需要额外依赖
  • 非常适合先补服务层测试
  • 对当前这种单仓库、单机项目足够用

这也符合整个项目一贯的思路：

先做成，先锁关键点，再决定要不要上更重的工具。

Agent 项目里最适合先写哪类测试

结合当前项目经验，我会推荐按下面的顺序补。

第一类：服务层流程语义测试

这是最值得先补的。

比如：

  • 自动回炉
  • 冲突确认
  • 审批恢复
  • 失败重试语义

原因是它们：

  • 最核心
  • 最容易被改坏
  • 运行快
  • 不依赖页面

第二类：关键规则转换测试

比如：

  • Quality Gate 解析
  • effective_feedback 生成
  • 冲突分类

这类测试能很好地保护“文本规则 -> 结构化状态”这条链路。

第三类：少量页面层验证

页面层可以有，但建议后补。
因为当前项目的核心风险更多在流程语义，而不是页面 CSS。

一个很实用的测试原则

做 Agent 项目测试时，我很推荐一个原则：

优先测试“系统承诺了什么”，而不是“模型会不会写出某段具体文案”。

比如，好的测试是：

  • 当 Reviewer 返回 rewrite 时，系统是否自动回炉

而不是：

  • 模型是否一定会写出某一段固定文本

前者稳定，后者很脆弱。

这也是为什么当前项目现在的测试，主要都落在：

  • 状态变化
  • 步骤顺序
  • 参数传递
  • 上下文写回

而不是去断言具体生成内容长什么样。

后面还可以继续补哪些测试

如果沿着当前路线继续往下做，最值得补的下一批测试包括：

  • Dispatcher 一致性检查测试
  • 普通失败重试语义测试
  • 审批通过 / 驳回后的恢复路径测试
  • 页面层关键审批交互测试

这些测试不需要一次性全上，但可以随着功能稳定逐步补齐。

这一章的结论

Agent 项目补测试，最重要的不是先追求覆盖率，而是先锁住关键语义。

当前项目最近已经给出了一个很好的起点：

  • 自动回炉完整闭环
  • 自动回炉参数
  • 冲突确认写回有效上下文

这说明测试在 Agent 项目里的最佳切入点，不是“全测一遍”，而是：

先把最贵、最脆、最容易被改坏的流程语义保护起来。

这一阶段教程的收束

到这里，这套“开发 Agent 入门教程”已经不仅讲了：

  • 为什么做
  • 做什么
  • 怎么跑起来

还进一步讲到了：

  • 上下文系统
  • 多轮反馈治理
  • 质量闸门
  • 调试体系
  • 自动回炉与失败恢复
  • 自动化测试

这基本已经覆盖了一个入门级 Agent 产品从 0 到 1、再到 1 到 1.5 的关键问题。