没有验证闭环的 Agent 不值得信任
Agent 的交付说明里，最重要的不是它做了什么，而是它如何证明自己做对了。
Agent 最容易制造的一种错觉是：它看起来很自信。
但自信不是可靠。一个 Agent 如果不能验证自己的结果，它越会表达，越容易让人误判。
为什么验证比回答重要
传统 Chatbot 的输出是一段回答，用户自己判断是否可信。
Agent 不一样。Agent 会改文件、跑命令、发请求、写文档、操作系统。它的输出如果不可验证，风险会直接进入真实环境。
所以 Agent 的交付说明里，最重要的不是“我做了什么”，而是“我怎么证明它做对了”。
Claude Code 的验证模式
Claude Code 好用的一点，是它经常会把验证动作纳入工作流。
典型路径是：
修改代码 -> 运行 lint/build/test -> 观察错误 -> 修复 -> 再验证 -> 汇报结果
这让用户看到的不是一段自我声明，而是一组证据。
代码改了没改对，不靠模型嘴上说，而靠工具输出、类型检查、测试结果、页面截图和 git diff。
验证可以分层
不是所有任务都需要同一种验证。
我会把验证分成五层：
- 静态验证：类型检查、lint、格式化
- 运行验证：测试、构建、脚本执行
- 行为验证：浏览器操作、截图、接口返回
- 数据验证：数量、结构、字段、边界值
- 人工确认：高风险决策、审美判断、业务取舍
不同任务选择不同验证层。不要为了形式感跑无意义测试，也不要跳过关键验证。
Agent 应该主动暴露未验证部分
一个成熟 Agent 不应该假装所有事情都已经确定。
如果它没有跑测试，就应该说没有跑。 如果它没有浏览器验证，就应该说还没看页面。 如果它只验证了桌面端，没有看移动端，也应该说清楚。
这不是显得弱，而是建立信任。
验证失败不是坏事
验证失败其实是好信号。它说明系统进入了真实反馈循环。
比起一次性生成“看起来正确”的结果，我更信任能这样工作的 Agent：
- 先给出方案
- 执行小步修改
- 跑检查
- 看到失败
- 解释原因
- 修复
- 再验证
这和真实工程师的工作方式更接近。
应用到自己的项目
如果我要给 OpenClaw 设计验证层，我会让每个任务类型都绑定默认验证策略。
比如：
- 写代码：lint、build、相关测试、diff 摘要
- 写文章：标题、摘要、结构、链接检查
- 做调研：来源链接、日期、交叉验证
- 操作飞书：目标文档、写入结果、回读检查
- 操作浏览器：截图、可见文本、关键状态
Agent 不应该每次临时想怎么验证。验证策略应该是工作流的一部分。
一个简单规则
Agent 的最终交付，至少应该回答三个问题：
- 改了什么？
- 怎么验证的？
- 还有什么没验证？
如果一个 Agent 只能回答第一个问题，它还只是自动执行器。能回答后两个问题，它才开始像一个可靠协作者。