关于 Codex 的一点思考：为什么需要拥抱 Loop Engineering？

最近看了很多关于 Loop Engineering 的系列探讨，Peter Steinberger 和 Anthropic Claude Code 的负责人 Boris Cherny 都曾指出类似的观点：AI 时代工程师的核心交互方式，正在经历一次底层的范式转移。

这篇文章，就是我对 Loop Engineering 这个概念，再结合 Codex 这个真实产品做的一次思考复盘。

一、什么是 Loop Engineering

首先，如何定义 Loop Engineering 呢？

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

（循环工程就是取代你作为提示代理人的角色。你去设计执行该任务的系统。）

1、Prompt 工程与 Loop 工程

过去，我们与大模型交互的主流方式是对话式。这种模式的优势在于极低的门槛和即时的正反馈。

但它的劣势也很明显：人类成为了整个系统的性能天花板。

之前为了优化大模型的生成效果，需要花大量时间坐在屏幕前进行人工的 prompt 调优和数据分析。敲下一段指令，等待模型返回，阅读结果，再敲下一段。Agent 只是一个被动的工具，你必须全程紧紧握住它。一旦你停下，工作流就停止了。

而 Loop Engineering 恰好相反。它的突破点在于你不再微操每一步，而是建立一个小型系统：让这个系统去发现工作、分发任务、检查结果、记录状态，并自主决定下一步。

之前探讨过的拉尔夫循环（Ralph Loop）中，那个无限运行的 while true 脚本就是为了抵抗上下文腐烂而设计的系统级脚手架（Harness）。而 Loop Engineering，就是跑在这个脚手架之上、更高维度的业务流水线。

2、从 Chat 到 Loop：架构的演进

当面对复杂的软件工程需求，单纯的聊天窗口是远远不够的。于是就有了以下工具架构的演进：

• 纯 LLM Chat：一问一答。受限于人类的耐心和模型的注意力衰减。
• 任务委派：给模型一个明确的单一任务（比如「修这个 bug」），模型在本地或沙盒中执行完毕，人类来 Review 代码。
• Loop Engineering：设定一个目标（如「迁移某个旧模块」），定义好验收测试，然后系统自动派生多个子智能体，在隔离的环境中并行修改、自测、相互审查，直到达成目标。

二、「设计循环」：AI 开发者的新范式

理解了上述的演进，会发现一个问题：如果系统如此自动化，那人类工程师的价值在哪呢？

答案是：工作从「执行者」变成了「循环设计师 + 审核员」。

这与在做产品时的思路很像。比如开发一个需求文档自动化生成工具时，单纯靠一段超长的 prompt 效果会极不稳定。真正的解法是把「写文档」这个大动作，拆解成结构化的 SOP 工作流。

在代码世界也是一样。Boris Cherny 说：「我不再 Prompt Claude，而是让运行中的循环驱动 Claude 自主决策。我的工作已转变为编写循环逻辑。」

过去，是通过写具体的代码来定义产品；在 AI 早期，是通过写 Prompt 来指导模型；而现在，是通过设计 Evals（评测）和 Stopping Conditions（停止条件）来校准和约束系统。

你的判断力、你的系统审美品味，以及你对错误边界的定义，构成了这个 Loop 的底线。

三、在 Codex 中如何实践 Loop Engineering？

Codex 这个产品，就是 Loop Engineering 理论在真实工程环境中的完美映射。它不是一个聊天工具，而是一个「Loop-native 的软件工程控制台」。

可以将 Codex 的核心机制提炼为三个维度的关注点。

1、Skills 与 State：解决 Agent 失忆问题

面对长周期任务，上下文污染一直是一个致命的问题。在处理庞杂且动态的文档上下文时，如果只是把所有的背景信息全塞给大模型，它的注意力很快就会崩溃。

Skills（AGENTS.md）：这是给 Agent 的黄金规范。不需要每次都在对话框里重复「我们的代码规范是什么」，而是把它写在项目目录下的 SKILL.md 中。这其实就是将领域知识前置做了一次「预处理切块」，Agent 在需要时才会隐式或显式地调用它。

State（状态机）：这就像之前在多智能体协作中提到的，需要一个团队白板来同步共识。在 Codex 中，一个简单的 Markdown 文件或 Linear 面板就是这个状态机。它记录了「尝试了什么，通过了什么，还剩下什么」。明天早上你的 Automation 醒来时，读的就是这个状态文件，而不是昨天几万 token 的废话日志。

2、Worktrees 与 Sub-agents：定义「Maker-Checker」的隔离机制

在并行工作流中，两个 Agent 同时修改同一个文件，就像是人类工程师在毫无沟通的情况下修改同一个代码仓库。

Worktrees：Codex 内置了 Git worktree 支持，为每个并行的子任务分配了绝对干净的、物理隔离的工作目录。这完美呼应了 Anthropic 在 Managed Agents 架构中「把沙盒变成牛」的设计哲学：沙盒只是一个干脏活的隔离环境，大脑（Harness）可以在一个又一个隔离环境里调度代码，彼此绝不干扰。

Sub-agents：这是对结果质量的保障。自己写代码的模型，往往会陷入幻觉，觉得自己写得无懈可击。Codex 允许拉起平行的 Sub-agents（比如一个探索者、一个实现者、一个安全审查员），这就相当于在产品中设定的自动化负面评测系统，用另一个带有批判视角的 Agent 来守住质量的下限。

3、Automations 与 /goal：驱动系统的「目标函数」

这是 Loop 真正跑起来的引擎。

Automations：这个自动化功能就像产品的定时跑批任务。设定好频率和对应的 Skill，让 Agent 每天早上自己去扫 CI 失败日志、提炼 Bug，把结果推送到 Triage 收件箱，以供审查。

/goal：这是最能体现这个新范式的指令。我们给出的不再是「改这行代码」，而是「跑到所有测试全绿为止」。Codex 会在每次流转后，用一个独立的模型来评判当前状态是否满足了你设定的 Stopping Condition。

四、循环，新一代工程师的核心杠杆

从理论到 Codex 的产品落地，我们可以清晰地看到技术范式的转变：Build the loop. Stay the engineer.

当 Loop 运行得越来越顺畅，我们很容易陷入一种舒适的「Cognitive Surrender（认知放弃）」：停止思考，全盘接受 AI 的产出。

但这是危险的。

Loop 只是放大了杠杆。同样一个自动修复 Bug 的 Loop，懂业务的人用它来快速清理技术债，将精力投入到更底层的架构思考中；而试图逃避思考的人，只会用它在代码库里埋下更多看不见的隐患。

最后

在 AI 优先的世界里，系统的壁垒不再是敲击键盘的速度，而是我们如何定义正确的品味，以及设计这些循环。