Codex循环模式：AI代理从单次任务到持续循环的范式转变

核心观点：从一次性任务到持续循环

Boris Cherny提出了一个超越"AI代理写代码提交diff"的全新工作模式。他同时运行多个会话，大量使用子代理，并依赖 /loop 命令来管理持续性的工程工作。这标志着AI代理使用方式的一次重要范式转变——从一次性任务执行，转向持续循环监控与响应。

子代理（Sub-agent）是指在主AI代理会话中派生出的独立执行单元，每个子代理拥有自己的上下文窗口和任务范围，能够并行处理不同的工程任务。这种架构类似于操作系统中的进程派生模型，主代理充当调度器角色。/loop 命令则是Claude Code等AI编程工具中的一种持续执行指令，它让代理进入一个watch-act循环，类似于Linux中的inotifywait或文件系统监控守护进程，持续检测状态变化并做出响应，而非执行完单条指令后就退出。

这个转变背后的核心洞察在于：软件工程中大量工作并非一次性的代码编写，而是持续的状态监控与响应。PR在review后需要修改，CI在依赖缓存过期后需要处理，部署后需要验证——这些本质上都是状态监控问题，而非一次性编辑问题。

在分布式系统工程中，状态监控是一个经典范式。从Nagios到Prometheus再到现代的可观测性平台，工程界一直在构建越来越精密的监控-响应系统。Boris将AI代理定位为这一范式的新载体，本质上是将传统需要人类判断力的监控响应环节（如代码review回复、CI故障根因分析）交给具备推理能力的AI代理，而非仅限于基于规则的自动化脚本。这与控制论中的反馈控制回路（feedback control loop）概念一脉相承——感知状态、判断偏差、执行修正、验证结果。

循环工作流的五大核心要素

一个完整的AI代理循环工作流包含五个核心组件：

触发器（Trigger）：什么事件启动这个循环
作用域（Scope）：循环关注的范围边界
行动预算（Action Budget）：允许消耗的资源上限
停止条件（Stop Condition）：何时终止循环
报告路径（Reporting Path）：结果如何反馈给人类

这五个要素构成了循环模式的基础框架。与传统的一次性代理调用不同，循环模式承认了工程工作的持续性本质，并为AI代理提供了在时间维度上持续工作的结构化方式。

循环模式为何优于一次性代理

一次性代理擅长有边界的编辑任务——给定明确输入，产出明确输出。但现实工程中的大量工作是状态驱动的：

PR review响应：提交后reviewer留下评论，代码需要相应修改
CI故障诊断：流水线因依赖缓存过期而失败，需要诊断和修复
部署后验证：完成部署后需要持续验证服务健康状态
用户反馈处理：反馈持续涌入，需要聚类分析形成可操作的洞察

这些场景的共同特征是：它们不是"做一次就完"的任务，而是需要持续监控、判断、响应的循环过程。一次性代理在这些场景中力不从心，而循环模式恰好填补了这个空白。

循环契约：让AI代理的持续工作可控

每个有用的循环都应该明确指定一份循环契约（Loop Contract），包含以下要素：

名称：清晰标识这个循环的用途
触发频率：多久检查一次状态变化
作用域：只关注哪些仓库、服务或系统
权限：允许执行哪些操作
预算：最多消耗多少token或API调用
停止条件：什么情况下自动终止
报告机制：如何向人类汇报进展和异常

这份契约的价值在于让AI代理的持续工作变得可预测、可审计、可控制。没有契约的循环就像没有SLA的服务——迟早会出问题。

SLA（Service Level Agreement，服务等级协议）是云计算和SaaS领域的核心概念，它明确规定了服务的可用性、响应时间、故障恢复时间等指标，以及违约时的补偿机制。Boris将循环契约类比为SLA，揭示了一个深层洞察：当AI代理从临时工具变为持续运行的基础设施时，它需要与人类运维的服务一样具备可观测性和可问责性。没有契约的AI循环就像没有监控的微服务——在出问题之前你甚至不知道它在运行，出问题之后你也无法追溯根因。

在循环模式下，Token预算是一个关键的工程约束。Token是大语言模型计费的基本单位，每次API调用都会消耗输入和输出token。由于代理持续运行，token消耗可能呈线性甚至超线性增长。例如，一个每5分钟检查一次PR状态的循环，如果每次检查消耗2000 token，一天就会消耗约576,000 token。按照当前GPT-4级别模型的定价，这可能意味着每个循环每天数美元到数十美元的成本。因此，预算机制不仅是防止失控的安全阀，更是工程经济学层面的必要约束。

四个值得立即运行的循环

PR保姆循环（PR Babysitter）

监控PR状态变化，自动响应review评论，处理合并冲突，确保PR不会在review流程中停滞。这是最直接能提升团队代码交付速度的循环之一。

在大型工程团队中，PR（Pull Request）的平均生命周期往往远超预期。GitHub的行业数据显示，许多组织的PR从提交到合并的中位时间超过24小时，其中大量时间浪费在等待review回复、处理合并冲突等非创造性工作上。PR保姆循环本质上是将PR的状态机管理自动化——它监控PR从"待review"到"需修改"到"已批准"到"可合并"的每个状态转换，并在每个转换点自动执行相应操作，从而压缩PR生命周期中的等待时间。

CI健康循环（CI Health Loop）

持续监控CI流水线状态，诊断失败原因，区分代码问题和基础设施问题，自动修复可处理的故障。减少开发者花在排查CI红灯上的时间。

CI（Continuous Integration，持续集成）流水线的故障可以分为确定性故障和非确定性故障。确定性故障通常由代码变更直接导致（如编译错误、测试断言失败），而非确定性故障（flaky failures）则可能源于网络超时、依赖缓存过期、资源竞争、第三方服务不稳定等基础设施问题。Google的工程实践报告指出，大型代码库中约16%的测试失败属于flaky failure。CI健康循环的核心价值在于自动区分这两类故障，避免开发者将时间浪费在排查非代码原因的红灯上。

部署验证循环（Deploy Verification Loop）

部署后持续检查服务健康指标，验证新版本行为符合预期，在发现异常时触发告警或回滚。将部署后的人工盯盘转化为自动化监控。

反馈聚类循环（Feedback Clustering Loop）

持续收集用户反馈，进行语义聚类，识别新出现的问题模式，生成可操作的洞察报告。让产品团队更快捕捉到用户痛点的变化趋势。

失败模式与防范策略

循环模式并非没有风险。Boris指出了四个需要警惕的失败模式：

持续消耗（Resource Drain）：循环可能在没有产出价值的情况下持续消耗资源。预算机制和明确的停止条件是核心防范手段。

隐藏陈旧假设（Stale Context）：循环可能基于过时的上下文做出错误判断。需要定期刷新循环的知识基础，避免在过期信息上反复操作。这个问题在长时间运行的循环中尤为突出——随着代码库演进、团队成员变动、架构决策更新，循环初始化时的上下文假设可能逐渐失效，导致代理做出看似合理但实际有害的操作。

缺乏所有权（No Ownership）：每个循环都需要明确的人类负责人，否则会变成无人维护的僵尸进程，悄悄消耗资源却无人问津。

在Unix/Linux系统中，僵尸进程（zombie process）是指已经终止但其父进程尚未回收其资源的进程，它们占用进程表项却不做任何有用工作。Boris将无人维护的AI循环类比为僵尸进程，这个比喻精准地捕捉了一个风险：在组织中，启动一个AI循环的成本很低（可能只需要一条命令），但如果没有明确的所有权和生命周期管理，这些循环会像技术债务一样悄然积累，消耗计算资源和API配额，却无人审视其产出是否仍有价值。

缺乏升级机制（No Escalation Path）：循环遇到超出能力范围的问题时，必须有清晰的升级路径将问题交还给人类，而不是在死胡同里反复重试。这与运维领域的On-call升级机制（escalation policy）异曲同工——一个成熟的告警系统不会让同一个人无限期处理同一个问题，而是在超时后自动升级到更高层级的响应者。AI循环同样需要这种分层响应机制。

趋势判断：循环契约决定团队竞争力

Boris的核心论断是：重复性的工程工作即将被AI代理循环所管理，胜出的团队将是那些拥有最清晰循环契约的团队。

这个判断值得认真对待。当前大多数团队使用AI代理的方式仍停留在"人类发起→代理执行→人类验收"的单次模式。循环模式代表了下一个阶段——AI代理成为持续运行的工程基础设施的一部分，而非临时调用的工具。

这一转变可以类比为云计算的演进路径：从最初的"按需启动虚拟机执行任务"到"始终运行的容器化微服务"，再到"事件驱动的Serverless函数"。AI代理的使用模式正在经历类似的演进——从"按需调用"走向"持续运行的智能基础设施层"。拥有清晰循环契约的团队，本质上是在构建一套可管理、可扩展的AI运维体系，这与DevOps运动中"基础设施即代码"的理念一脉相承。

对于工程团队而言，现在值得思考的问题是：你的团队中有哪些重复性工作可以被循环化？你能否为这些循环定义清晰的契约？这可能是未来工程效率竞争的关键维度。