AI改完代码后如何自我验证：Open Agents验证循环完整指南

AI改完代码后如何自我验证：Open Agents验证循环完整指南

【免费下载链接】open-agentsAn open source template for building cloud agents.项目地址: https://gitcode.com/GitHub_Trending/op/open-agents

Open Agents 是一个用于构建**云端 AI 编程智能体（cloud agents）**的开源模板。它的核心设计之一是内置了一套严格的「验证循环（Verification Loop）」机制：每当 AI 智能体在云沙箱里改完代码，系统会自动强制执行类型检查、代码规范和测试，并循环修复直到全部通过——绝不"口头声称代码能跑"。本文带你完整看懂这套 AI 代码自验证机制是如何工作的，以及它背后的几个关键设计决策。

一、为什么 AI 智能体必须"自己检查自己"

想象一下：AI 帮你改了一个函数，但它怎么证明改对了？

大多数 AI 工具的风险在于"幻觉式交付"——模型自信地告诉你"已完成"，但类型检查报错、测试挂掉、甚至构建失败。Open Agents 的解法是把验证从"建议"变成"强制规则"，直接写进智能体的系统提示词中，让模型在每次代码修改后必须走完一整条验证流水线。

它的三层架构是理解这一切的基础：

Web 界面 -> Agent 工作流 -> Sandbox 虚拟机

智能体运行在沙箱外部，通过工具（读文件、编辑、搜索、Shell 命令）与沙箱交互。验证循环就发生在这个"智能体驱动沙箱执行检查命令"的过程中。架构细节可参考 docs/agents/architecture.md。

二、验证循环：改完代码后的 7 步强制流程

核心规则写在系统提示词的 Verification Loop 段落中，原文的要求是："After EVERY code change, validate your work and iterate until clean"（每次代码修改后，验证你的工作并迭代直到干净）。

具体流程分 7 步：

第 1 步：只用项目自己的脚本，绝不裸跑工具命令

这是最容易被忽视的一条规则。如果项目定义了bun run ci或turbo typecheck，智能体必须用这些命令，而不是直接跑npx tsc、eslint .之类的通用命令。

原因很实际：项目通常为自己的工具链配置了特定的参数、插件和路径。绕过脚本直接调用底层工具，会得到错误或不完整的检查结果。

第 2 步：从锁文件自动识别包管理器

智能体会读取项目根目录的锁文件来判断该用哪个包管理器：

规则明确要求"绝不假设包管理器，永远从锁文件或 AGENTS.md 验证"——对非 JS 项目则检查Cargo.lock、go.sum等对应文件。

第 3 步：固定顺序执行验证

按类型检查 → Lint → 测试 → 构建的顺序依次运行。这个顺序刻意从"快"到"慢"：类型检查最快、反馈最直接，能尽早暴露低级错误，避免浪费时间在后续更耗时的构建上。

第 4 步：发现错误就修，修完重跑

如果验证发现错误是由智能体自己的修改引入的，它必须修复后重新运行验证，然后重复，直到所有检查通过。原文规定："Do not move on with failing checks"（带着失败的检查不许往下走）。

这与 系统提示词中"任务坚持"原则 形成呼应：遇到错误就调试；修复引入了新错误，就继续修新的；这个循环一直转到全部通过。

第 5 步：无法验证时，必须诚实说明

两条硬性红线：

• 如果既有的历史失败阻塞了验证，要清楚说明，并限定自己的声明范围（"我改的部分通过了，但项目原本就有 3 个测试挂着"）；
• 每次完成后必须报告运行了哪些命令、通过与否；
• 最核心的一条：在没有运行过验证命令、且没有明确说明"为何无法验证"的情况下，永远不允许声称代码能正常工作。

三、针对不同大模型的"严格度补丁"

有意思的是，Open Agents 针对不同模型家族加了不同的行为覆盖层（overlay），全部定义在 system-prompt.ts 中。

其中最"狠"的是给 GPT 家族的指令，它直接点名了行业通病：

"Test your code using the tools provided, and do it multiple times to catch edge cases.Failing to test rigorously is the number one failure mode"（不严格测试是第一失败模式）

即：要求多轮测试以捕获边界情况，并且"必须迭代到问题彻底解决才能结束回合"。

而 Claude 家族的补丁则强调：发现 10 个类型错误时，要为每个错误单独建一条待办，逐个修复、逐个打勾，给用户实时可见的进度。

这套"基础提示词 + 模型专属补丁"的组装顺序在代码注释中写得很清楚（buildSystemPrompt），是学习"如何给不同大模型写系统提示词"的很好范本。

四、验证与云沙箱、自动提交的衔接

验证循环不是孤立存在的，它嵌在整条交付链路里：

1. 智能体只改文件，不碰 Git：云沙箱指令明确规定智能体"只做文件系统修改"，禁止执行git commit、git push（Git Write Rules），提交由应用层的"broker"负责；
2. 完成后汇报验证结果：任务结束时的标准动作是"报告改了什么 + 跑了哪些验证"，这是交给下一环节（自动提交）的依据；
3. 危险命令需要审批：验证过程中如果触发了破坏性命令（如rm -rf、curl、访问敏感文件），沙箱的 bash 工具会拦截并要求人工批准，模式清单见 bash 工具的危险命令检测；
4. 验证通过才进入自动提交：自动提交流程 auto-commit-direct.ts 会先检查是否有未提交改动、核验仓库访问权限、生成提交信息，再经 GitHub API 创建签名提交并推送。

也就是说：验证循环是"AI 代码能否到达你的仓库"的守门员。

五、一个真实教训：为什么要写"先查 AGENTS.md"

这个项目把自己的踩坑记录沉淀在 docs/agents/lessons-learned.md 中，其中关于验证的一条值得每个 AI 工具开发者收藏：

验证指令必须让智能体先查 AGENTS.md 和 package.json scripts，再列出"类型检查→Lint→构建"这类通用步骤；否则模型会默认使用裸命令（npx tsc、eslint .），绕过项目特定的工具配置（如 turbo 流水线、tsconfig 引用），产生错误或不完整的结果。

这正是第一优先级规则存在的背景——它是被真实事故"打"出来的经验，而不是理论设计。

六、总结：三条可复用的设计思想

如果你也在构建自己的 AI 编程智能体，Open Agents 的验证循环有三点可以直接借鉴：

1. 验证是系统提示词里的硬约束，不是可选建议——"每次修改后必须验证、失败不许前进"；
2. 尊重项目的既有工具链——先读 AGENTS.md 和 scripts，而不是凭模型记忆跑通用命令；
3. 诚实高于面子——无法验证时要显式说明，绝不空口宣称"代码能跑"。

核心文件速查：

想深入了解项目全貌，可以阅读根目录的 README.md，它涵盖了本地启动、部署到 Vercel 的完整步骤。

【免费下载链接】open-agentsAn open source template for building cloud agents.项目地址: https://gitcode.com/GitHub_Trending/op/open-agents