AI 新范式：普通人三年自救之 Loop 工程指南

发布日期：2026 年 6 月 7 日核心议题：从“提示智能体”进化至“设计循环”

所谓 Loop Engineering（循环工程），本质是将“作为提示者的人类”替换掉。你需要构建一套系统，由它来执行这项任务。

此处的 loop，可视为一种递归目标：你设定一个终点，随后让 AI 持续迭代，直至达成。

我坚信，这或许将成为我们未来驾驭 coding agents 的主流模式。当然，目前尚处早期阶段。对此我仍存疑虑，且务必警惕 token 成本。资源丰富与否，将导致使用模式天差地别。因此，我想深入拆解：它究竟为何物，又意味着什么。

Peter Steinberger 近期曾言：

“别再直接提示 coding agents 了。你应当设计 loops，让这些 loops 去驱动你的 agents。”

无独有偶，Anthropic 旗下 Claude Code 的负责人 Boris Cherny 也表示：

“我不再亲自提示 Claude 了。我有若干 loops 在运转，它们会提示 Claude 并判定行动方向。我的职责仅是编写 loops。”

那么，这些言论究竟意指何为？

过去约两年间，若想从 coding agent 获取成果，方式莫过于撰写优质 prompt 并提供充足上下文。

你输入一句，阅读反馈，再输入下一句。agent 仅是工具，而你始终手握此工具，进行一轮又一轮的操作。

这一阶段已近尾声，或至少部分人士认为其即将终结。

如今，你构建的是一个微型系统。该系统将：

由系统去触发 agents，而非你亲力亲为。

我曾撰文介绍过其近亲，名为 agent harness engineering，即为单个 agent 的运行环境进行工程化；另有 factory model，即构建软件的系统。

Loop engineering 则位于 harness 之上的一层。

它拥有 harness，但能按定时器运行，可派生子助手，且具备自我喂养能力。

令我惊讶的是，这已不再单纯是工具问题。

一年前，若需一个 loop，你得编写大量 bash 脚本，并永久维护它们。那是你的私有物，仅属于你。

而今，这些组件已直接内置于产品之中。

Steinberger 所列之物，几乎与 Codex app 完全对应；同时也高度契合 Claude Code。

一旦你察觉它们的形态一致，便不再纠结选用何种工具，转而着手设计一个 loop，使其无论身处哪个工具皆能运作。

一个 loop 需具备五要素，外加一处记忆存储之所。

先予罗列，再行映射。

依计划自动触发，自主完成发现与分类。

确保两个并行 agents 互不干扰。

记录项目知识，防止 agent 凭空猜测。

将 agent 接入你已在使用的工具链。

令一个 agent 提出构想，另一个 agent 负责核查。

接着是第六要素：memory（记忆）。

它可以是一个 markdown 文件，亦可是 Linear 看板。任何存于单次对话之外、用于记载“已完成事项与待办任务”的载体皆可。

听起来似乎愚蠢且无关紧要。

但这却是所有长期运行 agent 所依赖的同一技巧。我在 long-running agents 文中亦提及：模型在不同运行间会遗忘一切，故 memory 必须驻留磁盘，而非上下文之中。

agent 会遗忘，但 repo 不会。

如今两款产品均已囊括全部这五个要素。

名称虽有细微差别，但能力实为同一种事物。

坦白说，细节决定一个 loop 是稳健运行，还是悄然四处泄漏。

Automations 是让 loop 真正成为 loop 的关键，而非仅运行一次的临时任务。

在 Codex app 中，你可于 Automations 标签页创建自动化流程，并选择：

找到结果的运行将进入 Triage 收件箱；未找到结果的运行会自动归档，此举甚佳。

OpenAI 内部亦用它处理一些枯燥却有益的事务，例如：

且 automation 可调用 skill，从而使这类重复性事务保持可维护性。

你触发的是$skill-name，而非将一大堵无人更新的指令墙粘贴进调度表中。

Claude Code 则通过 scheduling 与 hooks 达到同等效果。你可利用/loop 按间隔运行 prompt 或命令；可安排 cron 任务；可在 agent 生命周期的特定节点触发 shell 命令；若欲使其在合上电脑后继续运行，可将整件事推送至 GitHub Actions。

完全是同一理念：

定义一个自主任务，设定频率，让发现结果主动呈递于你，而非你四处搜寻。

另有一个值得了解的 in-session 原语，更贴近本文核心主旨。

/loop 将按频率重复执行。

/goal 则持续运行，直至你设定的某个条件真正成立。每轮之后，会有一个独立小模型检验事宜是否完结，故编写代码的 agent 并非自我评分者。

你可赋予其如下目标：

然后便可离开。

Codex 亦具备同类功能，同样名为/goal。它将跨轮次持续工作，直到可验证的停止条件达成，并支持 pause、resume 及 clear 操作。

两款工具，同一原语。这基本上构成了全文的模式。

因此，此部分负责让工作浮出水面。

loop 的其余部分，则负责对这些工作采取行动。

一旦运行超过一个 agent，文件冲突便会涌现，成为失败之源。

两个 agents 同时写入同一文件，与两位工程师同时提交相同代码行却缺乏沟通，乃是同样的头疼难题。

git worktree 可解决此问题。

它在独立分支上创建工作目录，同时共享同一 repo 历史，使得一个 agent 的改动在物理层面无法触碰另一个 agent 的检出内容。

Codex 已将 worktree 支持直接内置，故多个 threads 可并发处理同一 repo 而互不撞车。

Claude Code 则通过以下方式获取同等隔离效果：

如此每个 helper 都能获得全新 checkout，并在结束后自行清理。

我在 orchestration tax 中曾论述此事的人类侧面：

worktrees 解决的是机械碰撞，但你仍是上限。你能审查多少，决定了实际可运行的 agent 数量，而非工具本身决定。

skill 是你避免每个 session 都像金鱼般重新诠释同一项目上下文的方式。

两款工具采用同一种格式：

SKILL.md 保存指令与元数据；此外还可包含可选脚本、参考文献及资产。

Codex 会在你使用$或/skills 调用时运行 skill，亦会在任务匹配 skill 描述时自动调用。

这便是为何紧凑、平淡的描述胜过聪明伶俐的描述。

Claude Code 做法如出一辙，我此前也在 agent skills 中写过此模式。

Skills 亦是 intent 不再反复消耗成本之处。

我在 intent debt 中提出：agent 每个 session 起始均为冷启动，它会用自信猜测填补你意图中的任何空白。

skill 即是将那份 intent 外化，将这些内容一次性写下：

以便 agent 每次运行皆可读取。

若无 skills，loop 每个周期都将从零重新推导整个项目。

有了 skills，它在某种程度上将产生复利效应。

有一点需明确区分：

skill 是创作格式，而 plugin 是你发布它的方式。

当你欲跨 repos 分享 skill，或将数个 skill 打包时，便将其封装为 plugin。

Codex 如此，Claude Code 亦然。

一个仅能看见文件系统的 loop，实属渺小。

Connectors 基于 MCP 构建，它们使 agent 能够：

Codex 与 Claude Code 均支持 MCP，故你为其中之一编写的 connector，通常亦能在另一款中运作。

Plugins 则将 connectors 与 skills 打包，让你的队友一次性安装你的配置，而非依靠记忆重建一切。

这便是 agent 说：

“这是修复方案。”

与 loop 自行完成以下动作的区别：

connectors 是 loop 能在你的真实环境中行动的原因，而非仅告知你：

“若我能做，我会如何做。”

loop 中最具价值的结构性设计，远胜于将“撰写者”与“检查者”分离。

编写代码的模型极易在自我评分时过于宽容。

第二个 agent，携带不同指令，有时甚至采用不同模型，可捕捉第一个 agent 自我说服的那些问题。

Codex 仅在你要求时生成 subagents。它们并发运行，随后将结果折叠回单一答案。

你可于.codex/agents/中将自有 agents 定义为 TOML 文件。

每个 agent 拥有：

故你的安全审查员可是强力模型并开启高努力模式；而你的探索者可是某快速只读之物。

Claude Code 亦利用.claude/agents/中的 subagents 与 agent teams 践行此事。这些 agent teams 可相互传递工作。

两款工具中常见的拆分是：

我已两次阐述此观点，一次在 code agent orchestra，另一次在 adversarial code review。

其在 loop 中尤为关键的原因是：

loop 是在你未监视时运行的。故一个你真正信任的 verifier，是你能够离开的唯一理由。

Subagents 确会燃烧更多 tokens，因每个 subagent 皆执行自身的模型与工具工作。

故唯有当第二意见值得付费时，才将 token 花费于此。

这也基本上即是 Claude Code 的/goal 底层所行之事：

由新模型判断 loop 是否完成，而非让执行该事的模型自我判断。

maker 与 checker 的拆分，被应用到了停止条件本身。

将这些组件拼合，单一线程即变为小型控制面板。

这是我一直在用的一种形态。

一个 automation 每日清晨在 repo 上运行。

其 prompt 调用 triage skill，读取：

随后将 findings 写入 markdown 文件或 Linear 看板。

对于每一个值得处理的 finding，该 thread 将打开隔离的 worktree，并派遣 sub-agent 起草修复方案，再派第二个 sub-agent 依据项目 skills 及既有 tests 审查此草案。

Connectors 使 loop 可开启 PR，并更新 ticket。

loop 无法处理的任何事宜，都将进入 triage inbox，移交于我。

state file 是整件事的脊梁。

它铭记：

故明日清晨的运行可接续今日之位继续。

继而审视你实际上做了什么。

你仅设计了一次。

你未提示这些步骤中的任何一步。

此即 Steinberger 观点的现实版本。

且无论在 Codex 还是 Claude Code 中，皆是同一 loop，因组成部分乃同一种组成部分。

loop 改变了工作，但它并未将你从工作中剔除。

且随着 loop 日益完善，有三个问题实际上将变得更为尖锐，而非轻松。

一个无人值守的 loop，亦是一个无人值守地犯错的 loop。

你将 verifier sub-agent 与 maker 拆分的全部缘由，即为让 loop 宣称“已完成”这句话具备意义。

即便如此：

“已完成”仍是一种主张，而非证明。

我在 code review in the age of AI 中一直重复同一句话：

你的职责是交付你确认过能工作的代码。

若你允许的话。

loop 越快交付你未亲手编写的代码，实际存在之物与你真正理解之物间的差距便越大。

此即 comprehension debt（理解债务）。

一个顺滑的 loop 只会加速其增长，除非你去阅读 loop 生成的内容。

当 loop 自行运行时，极易诱使你停止保有自身判断， merely 接受它给予的任何东西。

我称之为 cognitive surrender（认知投降）。

当你带着判断力去行动时，设计 loop 是解药。

当你为避免思考而这么做时，它便是加速剂。

同一动作，截然相反的结果。

我认为，这是我们工作方式即将演化的预演。

换言之，若我不亲自 review 代码，或若我完全依赖自动化 loops 来修复它，我产品的质量必将受损。

我很可能陷入下降螺旋，不断将自己挖入更深的坑洞。

话虽如此，去配置你的 loops 吧，但切勿忘记：

直接提示你的 agents 也同样有效。

关键在于寻得正确平衡。

Loops 亦会因使用者不同而产生迥异结果。

两人可构建完全相同的 loop，却得到完全相反的结局。

一人用它在自己深刻理解的工作上跑得更快。

另一人用它逃避理解工作本身。

loop 不知晓两者的区别。

你知晓。

这便是为何 loop design 比 prompt engineering 更难，而非更简单。

Cherny 的观点并非工作变简单了，而是杠杆点发生了移动。

构建 loop。但要像一个打算继续做工程师的人那样构建它，而非像一个只想按下启动按钮的人。

原文：Addy Osmani,Loop Engineering 链接：https://addyosmani.com/blog/loop-engineering/