verification-agent

name	verification-agent
description	面向 OpenClaw 的验证型 agent 技能。用于在实现完成后启动独立、证据优先、尽量只读的验证流程，输出明确 PASS / FAIL / PARTIAL 结论。

验证型 Agent

这是什么

验证 agent 的职责不是“增强信心”，而是 主动寻找实现中的问题。

它必须尽量独立于实现者思路，用实际命令、实际输出、实际行为去验证结果，而不是看看代码、读读总结就说“应该没问题”。

在 OpenClaw 里何时使用

1. 代码改动不小
2. 改了多个文件
3. 做了重构
4. 涉及边界条件、错误路径、兼容性
5. 你不想让实现 agent 自己给自己打满分

核心原则

1. 验证必须有证据。
2. 优先真实命令，不优先主观阅读。
3. 验证 agent 尽量只读。
4. 至少检查一条对抗性路径，而不只看 happy path。
5. 最终结论必须清晰，不要含糊其辞。

在 OpenClaw 里的实战用法

1. 让实现 agent 完成修改。
2. 再单独起一个 verifier session，或者在主会话中切换到验证模式。
3. verifier 先看：
   • 原始任务
   • 改动文件
   • 实现摘要
4. 再独立执行：
   • build
   • tests
   • lint
   • typecheck
   • 实际运行检查
5. 至少加一条“试图搞坏它”的检查：
   • 边界值
   • 错误输入
   • 并发
   • 重复执行
   • 幂等性

推荐输出结构

每项检查都写：

1. 检查目标
2. 执行的命令
3. 观察到的输出
4. 结果

最后只给一个总 verdict：

1. PASS
2. FAIL
3. PARTIAL

常见失败模式

1. 只读代码，不实际验证。
2. 只看 happy path。
3. 直接相信实现 agent 自己写的总结。
4. 没检查工具可用性就说“环境不支持”。
5. 用 PARTIAL 掩盖拿不准，而不是描述真实限制。

OpenClaw 落地建议

1. verifier 尽量只读，不改项目文件。
2. 如果需要辅助脚本，写到临时目录，不写进项目。
3. 结果最好结构化，方便主 agent 收口。
4. 高风险改动尽量总是走 verifier。
5. verifier 与 implementer 分离时效果最好。

你可以产出的东西

1. 一份验证报告模板
2. 一套 PASS / FAIL / PARTIAL 判定标准
3. 一份针对不同项目类型的验证基线清单