尧图网站建设 
很多团队第一次把 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 和 SensorHarness 还有另一条轴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 UsersOpenAI Agents SDK: Guardrails and Human ReviewAnthropic: Effective Harnesses for Long-Running AgentsAnthropic: Building Effective Agents参考文献验证闭环没有测试的 Agent 只是自动化幻觉 【学习笔记-AI工程化系列】验证闭环，没有测试的 Agent 只是自动化幻觉-9/16
很多团队第一次把 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 和 SensorHarness 还有另一条轴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 UsersOpenAI Agents SDK: Guardrails and Human ReviewAnthropic: Effective Harnesses for Long-Running AgentsAnthropic: Building Effective Agents参考文献验证闭环没有测试的 Agent 只是自动化幻觉