AI改完代码后如何自我验证Open Agents验证循环完整指南【免费下载链接】open-agentsAn open source template for building cloud agents.项目地址: https://gitcode.com/GitHub_Trending/op/open-agentsOpen 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 步从锁文件自动识别包管理器智能体会读取项目根目录的锁文件来判断该用哪个包管理器锁文件识别结果bun.lock/bun.lockbbunpnpm-lock.yamlpnpmyarn.lockyarnpackage-lock.jsonnpm规则明确要求绝不假设包管理器永远从锁文件或 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是学习如何给不同大模型写系统提示词的很好范本。四、验证与云沙箱、自动提交的衔接验证循环不是孤立存在的它嵌在整条交付链路里智能体只改文件不碰 Git云沙箱指令明确规定智能体只做文件系统修改禁止执行git commit、git pushGit Write Rules提交由应用层的broker负责完成后汇报验证结果任务结束时的标准动作是报告改了什么 跑了哪些验证这是交给下一环节自动提交的依据危险命令需要审批验证过程中如果触发了破坏性命令如rm -rf、curl、访问敏感文件沙箱的 bash 工具会拦截并要求人工批准模式清单见 bash 工具的危险命令检测验证通过才进入自动提交自动提交流程 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 的验证循环有三点可以直接借鉴验证是系统提示词里的硬约束不是可选建议——每次修改后必须验证、失败不许前进尊重项目的既有工具链——先读 AGENTS.md 和 scripts而不是凭模型记忆跑通用命令诚实高于面子——无法验证时要显式说明绝不空口宣称代码能跑。核心文件速查模块路径验证循环与系统提示词packages/agent/system-prompt.ts智能体工具集含 bash 审批packages/agent/tools/项目 AI 协作规范AGENTS.md踩坑经验记录docs/agents/lessons-learned.md自动提交实现apps/web/lib/chat/auto-commit-direct.ts想深入了解项目全貌可以阅读根目录的 README.md它涵盖了本地启动、部署到 Vercel 的完整步骤。【免费下载链接】open-agentsAn open source template for building cloud agents.项目地址: https://gitcode.com/GitHub_Trending/op/open-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考