在 AI 辅助编码的模式下，工程师先理解需求、定位代码，再借助 AI 编写或修改代码，随后运行测试并决定下一步。当团队想进一步让 Agent 自主推进规划、构建、测试和修正时，原先由工程师完成的状态确认、故障分流和结果检查，也需要相应的工具与执行规则来支撑。
2026 年 10 月，Meta 在「How Meta Built Forum With AI-Native Engineering」中，介绍了独立群组应用 Forum 的开发实践。团队围绕代码架构、模拟器状态查询、自动化验证和沙箱构建做了改造，尝试减少工程师逐步操作的投入。这些改造涉及三个相互关联的问题：任务怎样才算完成，谁控制执行顺序与失败去向，运行环境怎样提供可信的状态和验证结果。结合 Stripe、OpenAI、Warp 和 Google 的实践，可以进一步分析这些条件如何落地，以及现有项目怎样分步改造。
找出 Loop 断点
人工主导开发时，工程师会确认安装的是本次构建，发现模拟器失联后重新连接，区分代码错误与环境故障，再判断是否提交评审。Agent 接手后，先要定位具体断点。代码位置和运行状态如何获取、检查结果怎样决定下一步、试验代码是否进入生产包，都需要由相应的工具和流程处理；仍依赖人工补充信息或操作的环节，会让任务停下来等人，或在错误前提下继续推进。
如果把编译通过当作任务完成，运行效果就可能未经验证。目标页面是否正确、导航路径是否完整、反复操作后内存是否持续增长，都需要运行检查。如果任务在构建成功后结束，评审者就要重新启动环境补做验证，节省的编码时间可能消耗在末端返工中。
执行过程也可能缺少约束，把"修改后运行测试"写入指导，或在会话结束时触发脚本，并不能单独保证结果被处理。检查失败后仍进入提交阶段，说明失败信号没有改变后续路径。
修改对象还可能不明确。Agent 会参考已有代码模式，隐式依赖和不良实现可能被后续修改沿用；静态文档又不能说明应用当前显示什么。Meta 曾遇到要求修改群组主页，Agent 却去修改首页信息流，或在模拟器中猜测控件坐标的情况。
产品接近生产后，还会出现试验边界问题。团队希望继续生成早期原型，同时保护正式应用。仅关闭运行时开关，不能证明原型实现已经退出生产包。
用检查结果控制流程
Meta 将工程师的职责定位为设定目标、监督偏航和审批结果，逐步让 Agent 推进执行步骤。目前部分阶段已经自主运行，另一些阶段仍需工程师参与每次迭代。
在任务开始前，团队加强上游拆解和机器可读上下文，将规划作为技术规范。对于页面修改，入口、预期行为、修改范围和验收路径需要明确。任务结束时，标准则推进到自动测试与视觉检查通过，变更附带预填充的测试计划、构建和测试结果，以及录制的验证会话。导航 Agent 可以操作运行中的应用、读取屏幕并报告回归。
Meta 用规则、Skill、专用 Agent、命令和钩子组织这些工作。规则保存项目约定，Skill 提供可复用步骤，专用 Agent 承担检查，命令连接复现、修复和评审等流程；钩子在每轮 Agent 交互后运行静态检查、安装前检查模拟器连接、创建合并请求前验证测试。
这些组件的约束方式不同，规则与 Skill 需要模型读取并遵循；钩子负责触发程序。只有执行系统读取检查结果，并据此阻止不满足条件的任务继续推进，才形成运行时约束。检查未执行、环境不可用和断言失败，需要分别处理；缺失报告或超时不能计为通过。Meta 披露了触发时机，没有展开完整的失败转移实现。
Stripe 在「Minions: Stripe's one-shot， end-to-end coding agents---Part 2」中，介绍了内部编码系统 Minions 无人值守执行任务、再由工程师审查结果的流程。系统用代码定义执行蓝图，将"实现任务""修复持续集成失败"等 Agent 节点，与"运行配置好的静态检查""推送修改"等程序节点混合编排。模型处理需要理解上下文的问题，程序执行预先确定的步骤。据此可以整理成具体的修复流程：
-
Agent 修改代码后，程序运行规定检查；
-
代码或断言错误返回负责修正的 Agent，模拟器失联则先恢复环境并确认安装状态。
-
构建和运行条件满足后，再检查目标页面、用户路径及预期行为。
规定的测试与视觉检查通过后，汇总对应版本的结果和验证材料，生成待审查的修改；恢复失败或预算耗尽时，保留"未通过"或"未完成"状态，保存已有改动、错误和现场信息后交回工程师。后者可以保留分支或草稿，但不能标记为验证通过。
图 1：一次检查后的执行分支。
测试计划和录像有助于复核，但材料存在不等于行为正确。程序可以检查报告是否齐备、版本是否对应，验收结论仍须由实际测试、断言和视觉检查结果支持。
修复还要注意成本边界。Stripe 在本地运行部分静态检查，再推送并运行持续集成；可自动修正的问题先由工具处理，其余失败给 Agent 一次修复机会。第二次推送和检查后，无论结果如何都交回工程师审查。这个一至两轮的上限针对完整持续集成，不能直接套到全部工具调用；环境恢复次数、超时和总任务预算需要另外约定。中断恢复前，还应核对推送或创建合并请求是否已经完成，避免重复执行。
查清代码与运行状态
流程能够按顺序推进，仍可能围绕错误对象工作。代码层面需要识别修改边界，运行层面需要确认应用实例、页面和元素；两类依据要分别建立。
Meta 对关键架构做了模块化处理，在复用成熟基础设施的同时方便 Agent 接入。对于难以清晰解耦的复用部分，团队选择重新实现，以降低复用率换取执行效率。团队还指出，Agent 会沿用所读代码的模式，因此清理现有不良实现，也能减少后续会话继续复制它们的机会。
这一取舍可以从修改范围理解。页面若同时处理请求、缓存、权限与全局状态，局部改动就可能触碰多个隐藏前提。拆出接口和依赖边界后，修改范围更容易限定，也便于检查是否越界。重写同时带来解耦和回归成本，存量项目应优先处理高频任务反复受阻的路径。
OpenAI 在「Harness engineering: leveraging Codex in an agent-first world」中，介绍了用 Codex 从零构建内部产品的实验。为约束 Agent 持续生成的代码，团队用自定义静态检查和结构测试约束模块依赖方向，并把修正指引写入报错；简短的 AGENTS.md 指向详细仓库知识。Agent 收到违规位置和指引后修改，再运行检查，减少依赖人工评审纠正重复违规的次数。这些检查覆盖已编码的架构规则，业务行为仍需另外验证。
运行现场则会随操作变化。Meta 针对改错页面和猜测坐标，提供读取模拟器实时视图层级、列出可见元素和查询目标页面导航路径的工具。例如，群组主页内也可能包含信息流。页面身份和父子关系有助于区分它与首页信息流，不能只匹配元素名称。以下简化层级示意：
Plain
当前页面：群组主页
└── 页面根视图
├── 群组标题（可见）
├── 发布入口（可见）
└── 内容区域
└── 群组信息流（可见）查询结果也有有效范围，导航前读取当前位置，导航后确认目标页面，操作后再次查询，能够减少错误前提向后传播。重新渲染可能使旧元素标识失效，进程重启后页面也可能变化。视图层级提供当前观察，不能一次查询后沿用到任务结束，也不能单独证明已经定位到对应源码。
并行执行还需要管理状态归属，OpenAI 为每个工作树启动应用实例，并提供临时、独立的日志、指标和链路追踪环境，任务结束后清理相应资源。该案例使用浏览器工具观察和操作应用。
将这种安排迁移到移动端时，要另行关联工作区、构建版本、应用实例和观测数据，并管理端口、模拟器及测试数据。否则，即使文件修改已经隔离，两个任务仍可能操作同一实例，用彼此的运行结果验证自己的代码。中断任务是否保留现场、何时清理资源，也需要单独设计。
图 2：任务与运行现场的对应关系。
压测应用并隔离原型
常规单元测试和路径走查主要覆盖预设行为，反复滚动、切页和加载媒体后，应用还可能出现资源增长和状态累积问题。Meta 配置了高频滚动、随机浏览群组、快速导航及重复加载媒体的压力场景，在不同构建间例行运行，观察崩溃、内存增长、缺页次数与界面回归。
上线前的一次压测暴露了内存问题。Agent 使用同一套压测环境完成复现、缩小触发序列、提出修复方案和复测，架构取舍由工程师决定。
复用时，先要缩小随机发现与稳定复现之间的差距。如果只留下"出现内存异常"，下次运行可能走到另一条路径，无法判断问题消失还是尚未触发。应按问题需要记录动作序列、时间、输入和初始状态，逐步缩小复现范围。这些记录有助于调查，不能单独保证外部环境已经复原。
修复前后还要使用可比条件，设备、系统版本、构建类型和媒体负载不同，内存变化可能来自环境差异。发现异常的资源曲线、定位触发条件的运行记录及修复后的复测结果，应分别支持对应结论。上述记录和比较方式属于迁移建议，不能当作 Meta 已公开的压测配置。
Forum 接近生产阶段后，试验又提出了新的交付边界：设计师等协作方继续用 AI 制作原型，生产包则只包含完成并经审查的功能。运行时开关控制功能是否启用，但不能单独保证相关代码和依赖退出打包、链接或初始化过程。Meta 为此采用独立的沙箱构建变体，共享代码库、框架和设计系统，实验功能通过插件与预留插槽接入，原型代码被排除在生产构建之外。协作方可以在沙箱中快速试验，成熟实现也能沿用共享基础设施迁入正式版本，降低重新实现的成本。
图 3：生产与试验构建的分流。
这项保证针对被排除的原型实现，它不进入生产包，其代码也不会在该包内执行。目录独立仍不足以证明排除成立，生产目标实际采用的依赖、资源收集和注册逻辑都要检查，防止原型被重新带入。
共享框架的变化仍可能影响正式功能，应按影响范围进行回归；无法明确影响面时，再扩大覆盖。新增构建变体、插件接口和测试矩阵也需要维护。原型迁入生产仍须经过评审，以及兼容性、性能和权限检查。
维护规则与排查依据
单次流程运行之后，重复错误和生产反馈会继续产生维护需求。前者关系到后续任务是否再次等待人工纠正，后者关系到线上现象能否形成可验证的修复线索。
Meta 在同一错误重复超过两次时，将修正写入永久项目规则。Anthropic 在文章「How Warp builds self-improving agents on Claude」中，介绍了开发工具团队 Warp 维护代码审查和问题分流 Agent 的做法：基础 Skill 执行任务，定时运行的改进 Skill 收集人工反馈，提出小范围调整，经维护者审查合并后生效。
在 Warp 的问题分流示例中，维护者指出 Agent 漏标了可进入规格设计的问题，并说明理由。改进 Skill 调用随附 Python 脚本提取带反馈的记录，再提出基础 Skill 文件的修改。人工纠偏经审查写入基础 Skill 后，后续任务可以读取，修改也能随版本记录追溯和回滚。
复用这条路径时，可以把能够客观判定的重复违规转为静态检查。提示中仍可保留约束摘要和修正入口，不必因程序已经检查就机械删除所有说明。规则修改是否有效，要在后续同类任务中检验，不能把反馈被采纳等同于质量已经改善。
应用上线后，调查也需要可用依据。Meta 在 Forum 信息流运维中让调查 Agent 收集线索、生成结构化报告和修复建议，由工程师判断是真实缺陷还是产品取舍。一类调查起初质量较弱，补充相关代码位置、查询示例和设计文档后质量改善。
代码位置缩小阅读范围，查询示例帮助获取运行数据，设计文档提供预期行为。后续会话可以复用这些资料，但资料仍要随系统变化维护。报告也应区分已观察事实、可能解释和尚未验证的条件，避免推测进入修复阶段后被当作既定根因。
版本是另一项对应关系。Google 在「The Outer Loop, Insights First: An Ambient Quality Agent That Diagnoses Your Production Agent」中，介绍了质量诊断参考实现 AQuA，并以旅行助手演示已部署业务 Agent 的质量排查。该参考实现在部署时保存按部署版本索引的不可变源码快照；按需调查时，将失败轨迹与对应源码共同分析，服务端校验引用的文件与行号。AQuA 本身不修改代码或创建合并请求，引用有效也不能证明根因成立。
后续 Agent 承接诊断时，还要确认问题在当前分支是否仍存在。历史会话输入可以用于重放，但不会自动恢复旧数据库、外部接口和动态对话状态；能够重建的部分用于验证，其余依赖需要固定或模拟。诊断报告提供修复输入，不能替代修复验收。
分步改造并检验收益
Meta 的 Forum 项目在八周内达到 Facebook Groups 的核心功能对齐；前述内存问题修复后，内存占用和缺页次数约减少一半。部分研发阶段仍需工程师参与每次迭代，所有交付都需要工程师最终签署。
Forum 与 OpenAI 的案例都从新项目开始，较早设计模块边界的空间更大。存量系统还包含历史依赖、隐含规则和不稳定测试，收益要与解耦、环境维护和验证成本一起评估。现有项目可以先选一类高频、边界较清楚的页面修改或组件修复，记录工程师在哪些步骤介入。反复指定代码位置、启动环境、指认页面和解释报错，分别暴露不同缺口，改造顺序应由实际断点决定。
随后针对这些缺口补齐查询和执行入口，再接入静态检查、构建及相关测试。执行系统要读取结果，区分代码错误和环境问题，限制恢复次数、超时与任务预算。检查本身若频繁误报，应先改善其可靠性，否则自动修复会围绕错误信号消耗时间。
试运行时，逐项核对任务是否操作了对应构建与应用实例、规定检查是否完成、失败是否进入预定分支，以及评审者能否复核结果。比较人工推动次数、等待时间和返工的同时，也要观察回归情况。重复纠偏逐步沉淀为文档、Skill 或检查规则，确认阻塞减少后，再扩大执行范围。
工程师继续负责目标选择、架构取舍和最终质量判断。Agent 能够连续推进多少工作，取决于环境是否提供了可查证的行动依据、受控的执行路径和足以支撑交付的验证结果。