企业官网建设流程全解析

很多团队第一次把 Agent 接进真实项目，都会经历一个很微妙的阶段。

它看起来很能干：会读代码、会改文件、会解释错误、会写总结。

最后还会说：

任务已完成。

但你一跑测试，发现没过。你一打开页面，发现交互坏了。你一看 diff，发现它顺手改了不该改的文件。你一查线上约束，发现它满足了局部需求，却破坏了系统边界。

这时候问题不是 Agent 不够努力。问题是它缺少验证闭环。

没有验证的 Agent，只是在自动化地产生“看起来完成”的结果。

一、“看起来对”不是完成标准

AI 系统最危险的地方，不是明显失败。明显失败很好处理。报错了、崩了、测试没跑起来，人类会立刻介入。

更危险的是“看起来对”：代码能生成，文档能总结，PR 描述很完整，Agent 的解释也很有道理。但真实系统并不关心解释有多顺。

它关心：

测试有没有过？ 接口有没有兼容？ 数据有没有被污染？ 权限有没有越界？ 用户目标有没有真正满足？ 失败时能不能恢复？

这就是验证闭环要解决的问题：它不是让 Agent 多自信一点，而是让 Agent 在每个关键节点接受反馈。

二、两类验证：计算型和推理型

Martin Fowler 讨论 Harness Engineering 时，有一个非常有用的拆法。

验证可以按执行方式分成两类：

Computational：计算型验证 Inferential：推理型验证

计算型验证是确定性的。

比如：

unit tests typecheck lint build schema validation snapshot diff API compatibility check security scan

它们便宜、明确、可重复。

能用计算型验证解决的问题，不要先交给 LLM judge。

因为测试失败就是失败，类型不匹配就是不匹配，schema 不通过就是不通过。

推理型验证则用于那些无法完全用规则判断的地方。

比如：

需求是否被正确理解 设计是否符合架构意图 回答是否引用了足够证据 风险说明是否完整 PR 变更是否值得人工注意 客服回复是否符合语气和政策

这类验证可以用 reviewer agent、LLM judge、critique loop 或人工 review。

但它不应该替代确定性检查。

更好的顺序是：

先跑便宜、确定、快速的计算型验证。 再用推理型验证覆盖模糊判断。 最后把高风险点交给人类。

三、Guide 和 Sensor

Harness 还有另一条轴：

Guide：行动前引导 Sensor：行动后感知

Guide 告诉 Agent 怎么做，Sensor 告诉 Agent 做得对不对。很多团队的问题，是 Guide 很多，Sensor 很少。

比如他们会在项目说明里写：

请写高质量代码。 请遵守架构规范。 请保持向后兼容。 请不要引入安全风险。

这些都算 Guide，但如果没有测试、lint、架构检查、API diff、安全扫描和人工 review，它们就只是愿望。成熟的 Harness 应该把 Guide 和 Sensor 配对。

Guide：不要破坏 API 兼容 Sensor：运行 API compatibility check Guide：保持代码风格 Sensor：运行 formatter / lint Guide：满足业务规则 Sensor：运行业务回归用例 Guide：控制安全风险 Sensor：运行权限检查和人工审批

这才是可执行的工程约束。

四、Ralph loop：让完成声明接受挑战

很多 Agent 的默认行为是：

做完 -> 总结 -> 结束

这对简单任务还行，对真实工程任务不够。更好的方式是给它一个“完成前反问”循环。

可以把它叫做 Ralph loop，也可以叫 verifier loop。核心不是名字。

核心是：

当 Agent 说完成时，让另一个检查步骤专门寻找未完成证据。

这个检查步骤可以问：

哪些测试没有跑？ 哪些假设没有验证？ 哪些文件改动超出任务范围？ 哪些用户约束没有满足？ 哪些错误路径没有覆盖？ 哪些外部副作用没有确认？

如果检查发现问题，Agent 不能直接结束。

它要回到执行阶段，修复或明确报告未验证项。

一个简单循环是：

Plan -> Act -> Test -> Review -> Fix -> Verify -> Report

注意最后不是“Report success”，而是“Report verified / unverified”。

成熟的 Agent 不应该只说：

我完成了。

它应该说：

我完成了哪些项。 我验证了哪些项。 哪些项没有验证。 为什么没有验证。 需要谁来确认。

这才是工程可信度。

五、验证也要分层

不要把所有验证都放到最后。最后才验证，成本最高。因为一旦发现方向错了，前面的修改都可能要推倒重来。

更好的方式是质量左移，把验证分层放进过程里。

第一层，输入前验证。

任务是否明确？ 目标是否可验收？ 上下文是否足够？ 权限是否足够？

第二层，行动中验证。

每次工具调用是否成功？ 每个子任务是否有状态记录？ 是否产生超范围 diff？ 是否出现重复循环？

第三层，完成前验证。

测试是否通过？ 需求是否满足？ 风险是否列出？ 未验证项是否明确？

第四层，发布前验证。

人工 review 回滚方案 审计日志 灰度策略 生产权限确认

验证闭环不是一个测试命令，它是一个持续反馈系统。

六、反模式

验证闭环最常见的失败模式有这些。

1. Agent 只写总结，不跑测试 2. 测试失败后继续说任务完成 3. 用 LLM judge 替代本来可以确定计算的检查 4. 只验证 happy path，不验证错误路径 5. 没有记录哪些项未验证 6. 验证命令依赖环境，但环境没有固定 7. 高风险操作缺少人工确认 8. reviewer agent 和 executor agent 共享同一盲点 9. 验证结果没有进入下一轮上下文 10. 没有成本和重试上限

这些问题不会在 demo 里立刻暴露，但会在长任务、多人协作和生产流程里暴露。

七、一份实用 Checklist

给Agent 设计任务时，可以直接加上这段完成标准。

完成前必须输出： 1. 已完成事项 2. 已修改文件 3. 已运行验证命令 4. 验证结果 5. 未运行验证及原因 6. 仍需人工确认的风险 7. 如果失败，下一步建议

如果是代码任务，再补充：

- 优先运行最小相关测试 - 如果测试无法运行，说明环境缺失 - 不得把未验证项说成已完成 - 不得隐藏失败日志 - 不得自动执行部署

这段话不保证 Agent 永远可靠，但它会显著减少“自动化幻觉”。

八、最后

Agent的输出不能只靠看起来对，它必须接受验证。

计算型验证给你确定性，推理型验证给你语义判断。人工监督处理高风险和价值判断。

这三者组合起来，才是生产级 Agent 的完成标准。

下一篇，我们继续拆 Harness 的另一条硬边界：

权限、沙箱与人类监督。

因为让 Agent 有能力行动之后，下一件事就是让它在边界内行动。

参考资料：

• Martin Fowler: Harness Engineering for Coding Agent Users
• OpenAI Agents SDK: Guardrails and Human Review
• Anthropic: Effective Harnesses for Long-Running Agents
• Anthropic: Building Effective Agents

参考文献：

验证闭环，没有测试的 Agent 只是自动化幻觉