Loop Engineering时代，产品人必须懂的14种概念

第一部分· 原因与测试​

循环工程正在取代你作为提示者.​

循环工程是指构建一个小型系统，该系统发现任务，将其交给智能体，检查结果，记录发生的情况，并自主决定下一步行动——这一切均由系统自行完成。你只需设计一次这个系统。此后，系统将提示客服人员。​

阿迪·奥斯曼尼将其分为六个部分：​

​

​

这一数字尚存争议，但机制本身并无分歧：关键的杠杆点已从输入提示语，转向设计能够触发提示的循环结构.​

在构建任何东西之前先进行四条件测试。​

循环只有在满足四个条件时才能收回成本。只要漏掉其中任何一条，循环的成本就会高于其带来的收益。这是AlphaSignal分析得出的中肯结论，也是大多数X线程往往忽略的部分：​

​

​

用通俗易懂的语言解释的四个条件：​

•

任务会重复执行。循环会将其初始化开销分摊到多次运行中。对于一次性任务，使用合适的提示词往往更快、更经济。如果这项工作并非每周重复，那就谈不上循环——你有的只是一个只运行过一次的脚本。​

•

验证是自动化的。循环需要某种机制，能够在无人值守的情况下判定工作是否失败。例如测试套件、类型检查器、代码风格检查工具或构建流程。如果没有自动化检查，你就又得坐在椅子上逐行审阅每一份差异——而这恰恰是循环本该帮你省去的工作。​

•

您的 Token 预算足以消化这些浪费。循环会反复读取上下文、重试并进行探索，无论这次运行是否生成任何结果，都会消耗 Token。这种技术的效率与预算规模密切相关，因此在拥有近乎免费 Token 的用户看来显得理所当然，而在采用按量计费方案的用户眼中则显得过于冒进。​

•

该工程师拥有资深工程师的全套工具。日志、复现环境，以及运行自己编写的代码并观察哪些地方会出错的能力。否则，整个开发流程就只能盲目地重复。​

​

谁赢，谁输。循环有利于那些能够花钱的人。​

经济模型并非放之四海而皆准。那些认为循环工程显而易见的人，往往持有无计量的代币。​

那些觉得这很冒险的人，通常都用着每月20美元的普通套餐，试图在不触发流量上限或遭遇意外账单的情况下运行复杂的验证流程。​

在实际中，究竟谁会受益：​

•

拥有重复性、可由机器验证的工作且具备相应预算的团队——持续进行测试分类、依赖项升级、代码质量检查与修复、以及在测试覆盖率较高的代码库上自动生成从问题到 Pull Request 的草稿。​

•

拥有强大现有测试套件的代码库。如果一名初级工程师只需按照检查清单就能完成任务，且测试套件能够发现其错误，那么采用循环就非常合适。​

•

采用多智能体模式的异步优先团队已在实际应用中。对于这些团队而言，例程正是缺失的编排层。​

今天哪些人应该跳过：​

•

面向消费者套餐的单人开发者——令牌账单先到，生产力提升却姗姗来迟。​

•

任何在没有自动化验证的情况下编写代码的人。一个没有任何真正检查的循环，无异于让程序在一次次重复中与自己达成一致。​

•

那些真正的瓶颈在于代码评审能力，而非打字速度的团队。一个循环会生成更多代码；如果评审本身已是瓶颈，那只会让待审队列变得更长。​

对于一次性任务、探索性工作，或者任何“完成”取决于主观判断的场景，一条精准有效的提示依然更胜一筹。这篇文章的坦率表述是：循环工程确实存在，但大多数开发者目前尚无需它。​

​

30秒循环检查。​

步骤2中的四条件测试是战略决策。而这一项则是战术层面的——即在将某项任务纳入循环之前，你所执行的检查清单。​

漏掉一个选项，就将其保留为手动提示。​

该任务至少每周执行一次。若低于每周一次，则设置成本将永远无法摊销。​

测试、类型检查、构建或代码检查工具都可能拒绝不合格的输出。如果没有自动化关卡，则由代理人自行批改自己的作业。​

代理可以运行它所修改的代码。缺乏复现环境 → 迭代过程盲目。​

循环设有硬性终止条件。无论是代币预算、迭代次数还是时间限制，只要缺少其中任何一项，循环就会一直运行，直到有人注意到账单为止。​

在合并、部署或依赖项变更之前，由人工进行审核。任何不可逆的操作在执行前都必须经过人工审批环节。​

首次贡献循环：​

•

CI故障分类 - 每晚，处理扫描失败，归类原因，并为简单问题起草修复PR。​

•

依赖项升级PR - 每周，扫描更新，测试兼容性，提交PR。​

•

代码检查与修复遍历 - 在每次拉取请求打开时，自动应用样式修复。​

•

易失败测试的复现 - 循环执行，直到某个理论通过测试。​

•

从问题到PR的草稿 针对那些拥有强大测试的代码，其中不良输出会被测试套件拒绝。​

​

​

糟糕的首次循环 - 这些需要人工介入：​

•

架构重写​

•

身份验证或支付代码​

•

生产部署​

•

模糊的产品工作​

•

任何“完成”取决于主观判断的事项​

​

第二部分·五大构建模块​

自动化：生命的脉搏。​

自动化是让循环真正成为循环的关键，而不仅仅是一次性的单次运行。它们可以按计划、在特定事件触发或满足触发条件时自动执行。它们就像循环的心跳——循环中的其他一切都依赖于它们。​

​

​

在两款关键工具中的呈现效果如下：​

•

法典。“自动化”选项卡——选择一个项目，设置触发条件，设定执行频率，选择本地检出或后台工作树。成功运行的会进入“待处理”收件箱；未找到任何结果的则会自动归档。​

•

克劳德代码。三种原语可组合成相同的形状：​

/用于会话范围的循环节奏、用于重启容错的桌面计划任务、以及用于笔记本电脑关机后云端运行的例程。再搭配生命周期事件钩子使用。​

自动化中包含的两种原语，用于将工作循环与昂贵的循环分离：​

•

/loop 按固定频率重复运行。当您希望无论状态如何都定期执行检查时，请使用它。​

•

/goal 会持续执行，直到你编写的某个条件真正成立为止。一个独立的小型模型负责检查任务是否完成，因此编写代码的智能体并不负责对其进行评价。​

这是应用于停止条件本身的生成者与检查者的划分。​

​

代码块​

Bash

> /loop 30m /goal All tests in test/auth pass and lint is clean.​

Scan src/auth for new failures, propose fixes in claude/auth-fixes,​

open draft PR when goal condition holds.​

​

▲ Claude​

CronCreate(*/30 * * * * : auth quality loop)​

Stop condition: tests pass + lint clean (verified by checker)​

✓ Scheduled. Will continue past intermediate completions​

until /goal condition is met by independent checker.​

​

工作树：并行而不混乱。​

一旦运行超过一个代理，文件就会开始冲突。两个代理同时写同一个文件，其麻烦程度与两名工程师在未事先沟通的情况下同时修改同一段代码如出一辙。​

​

​

Git 工作树就能解决这个问题——它是在同一仓库历史的基础上，为每个分支单独创建一个工作目录，因此某个代理的修改根本不会影响到其他代理的检出内容。​

它在两款工具中的呈现方式：​

•

Codex 在工作树支持方面有所改进——多个线程可以同时访问同一个代码库，而不会相互冲突。​

•

Claude Code直接暴露了 git worktree，提供了一个 --worktree 标志，用于在其独立的检出目录中启动会话，并在子代理上设置了 isolation: worktree 选项，使每个辅助工具都拥有一个全新的检出目录，且在使用完毕后会自动清理。​

工作树消除了机械上的冲突，但你的上限依然存在。决定你实际能够同时运行多少个并行代理的，是你的审查能力，而非工具本身。​

​

技能：撰写项目知识一次. 每次运行时都阅读。​

技能是一种让你不再像金鱼一样每场会议都重复解释同一项目背景的方法。两款工具采用相同的格式：一个文件夹，内含名为 SKILL.md 的文件，其中存放操作说明与元数据，还可附加可选的脚本、参考资料和相关资源。​

这为何对循环尤其重要：在没有技能的情况下，每次循环都会从零重新推导整个项目上下文。而有了技能，意图便会不断累积。 ​

那些约定、构建步骤，以及“我们之所以不这么干，是因为那一次事故”——只需在外部写明一次，每次运行都会被所有人读到。​

​

代码块​

YAML

name: ci-triage​

description: Classify CI failures by root cause (env, flake, real bug,​

dependency, infra), draft fixes for the easy ones, escalate the rest.​

Trigger whenever a workflow run fails or on the morning triage loop.​

---​

​

# CI triage skill​

​

## Classification rules​

- env: missing secret, wrong env var, infra not provisioned. # human​

- flake: passes on retry without code change. # retry once, then file​

- bug: deterministic failure tied to recent commit. # draft fix​

- dependency: failure tied to a version bump. # draft rollback​

​

连接器：循环与您的实际工具相连接。通过MCP实现。​

只能访问文件系统的循环是一个微型循环。连接器基于模型上下文协议（MCP），使代理能够读取您的问题跟踪系统、查询数据库、调用预发布环境的 API，或在 Slack 中发送消息。​

Codex 和 Claude Code 都支持 MCP，因此您为其中一种编写的连接器通常在另一种中也能直接使用。​

​

​

这正是“这里有一个修复方案”的代理与一个在 CI 状态变为绿色后自动打开 PR、关联 Linear 工单并提醒相关频道的循环之间的区别. ​

连接器是使循环能够在你的实际环境中运行的原因，而不仅仅是告诉你如果它能运行会怎样。​

对于循环而言，回报最快的连接器按顺序如下：​

•

GitHub - 阅读仓库、创建分支、提交拉取请求、评论问题、响应 Webhook 事件。这是任何代码开发流程在第一天就能带来的最大收益。​

•

Linear 或 Jira - 随着循环的推进更新工单，将 PR 关联回问题，并在验证通过时自动关闭相关事项。​

•

Slack - 发布故障分级结果、在升级时提醒相关人员、并在早晨汇总夜间运行情况。​

•

Sentry / 您的错误追踪工具 - 让循环机制实时分析告警，并为高频问题快速拟定修复方案。​

​

二级代理人：让制作者远离审核者。​

在循环中，最有用的结构设计无疑是将负责写代码的智能体与负责检查代码的智能体分离。奥斯曼的表述十分精准：编写代码的模型“对自己做的作业打分时过于宽容”。而另一个遵循不同指令、有时使用不同模型的智能体，则会揪出第一个智能体自我安慰后产生的错误。​

​

​

这就是Anthropic 2024年12月工程帖中以新名称提出的评估器—优化器模式。一个模型负责生成，另一个负责评价，循环往复。2026年爆火的这一术语早在十八个月前便已见诸文献。​

子代理如何同时入驻两款工具：​

•

Codex 仅在您发出请求时才会生成子代理，同时运行这些子代理，并将结果汇总为一个答案。您可以将自定义的代理以 TOML 文件的形式定义在 .codex/agents/ 目录下——包括名称、描述、指令，以及可选的模型和推理开销。​

您的安全审核员可以是一个高投入的强力模型，而您的探索器则是一个快速的只读工具。​

•

Claude Code 也对位于 .claude/agents/ 目录中的子代理以及在它们之间传递任务的代理团队采取同样的做法。通常的分工是：一个代理负责探索，一个代理负责实现，另一个代理则依据规范进行验证。​

它在循环内部尤为重要的原因：循环会在你未关注时持续运行，因此唯有你真正信任的验证器，才能让你放心地放手。子代理会消耗更多代币，因为每个子代理都会独立完成模型和工具相关的工作——请在值得支付第二意见的场景中使用这些代币。​

​

第三部分 · 做对还是不做​

状态文件。 代理会遗忘，而文件不会。​

这正是那个听起来愚蠢得似乎无关紧要，却实际上构成了每个有效工作流程核心的部分。一个 Markdown 文件、一块 Linear 板、一份 JSON 状态——任何存在于单一会话之外、用来记录已完成事项与下一步计划的东西。​

为什么这很重要：默认情况下，智能体的记忆很短。它们在本次会话中学到的内容，若不加以记录，明天就会消失。​

奥斯马尼的规则：代理人会遗忘，而回购协议不会。没有持久化状态的循环每次运行都会重新开始；有状态的循环则会从中断处继续执行。​

​

代码块​

Markdown

# Loop state · ci-triage​

​

## Last run​

2026-06-09 03:30 UTC · 7 failures classified, 3 fixes drafted, 4 escalated​

​

## In progress​

- claude/fix-auth-token-refresh — tests passing locally, awaiting CI​

- claude/fix-flaky-payment-webhook — retry pattern applied, monitoring​

​

## Completed today​

- claude/bump-axios-1.7.4 → merged (CI green, deps loop verified)​

- claude/lint-fix-pass-june-9 → merged​

​

​

状态文件存放的两种模式：​

•

仓库中的 Markdown 文件 - 放在根目录下或 .claude/ 目录内。版本控制，简单易懂，便于查看差异。最适合单人或小型团队使用。​

•

外部系统（线性、GitHub Issues、数据库）——可在多个仓库间持久化，支持查询，并具备全团队可见性。非常适合需要多人实时了解流程状态的生产环节。​

对于那些可能偏离目标的长时间运行循环，应将状态文件与一份持续存在的高层次规范——VISION.md 或 AGENTS.md——配合使用，以便智能体在每次运行时重新读取该规范。状态文件告知智能体它所处的位置，而规范则指引它该前往何处.​

​

最小可行循环。​

如果您在第2步通过了4条件测试，请先构建一个能正常运行的最小循环在进行任何复杂操作之前。四个部分，不使用群集。​

​

​

这四个部分，用通俗易懂的语言来说：​

•

一种自动化。一种按固定频率触发、并在满足特定条件时停止的定时运行。可在 Claude Code 中使用 /loop，或在 Codex 中创建自动化。当您希望它持续运行直至达到某一指定条件时，请搭配 /goal 使用。​

•

一项技能。一个单独的 SKILL.md 文件，用于存储代理在每次运行时本应从零重新推导出的项目上下文。​

•

一份状态文件。 一个 Markdown 文件或 Linear 板，用于记录已完成的工作与接下来的计划。明天的执行将从中断处继续，而非重新开始。​

•

一道关卡。测试、类型检查或构建一旦失败，就会自动导致工作出错。这正是决定循环是有助还是徒劳的关键所在。​

顺序很重要：先确保一次手动运行可靠无误，将其转化为一项技能，再用循环封装起来，最后安排定时执行。在生产环境中，跳过这一步骤正是导致循环失效的根源。​

真正关键的指标是每项被接受变更的成本——而不是已消耗的令牌、已尝试的任务，也不是已安排的循环。如果你的变更通过率低于50%，那就说明你在做那些本该由评审环节避免的工作，而这个评审循环实际上是在“亏本”。​

​

拉尔夫·维格姆的循环。那些悄然失效的循环。​

工程师杰弗里·亨特利记录并命名了这种故障模式。一个本应在任务完成时才发出完成标记的代理，却过早地发出该标记，导致循环在任务尚未完全完成的情况下就提前退出。若缺乏严格的门控机制，循环会悄然失败，并持续消耗资源。​

​

​

拉尔夫·维格姆循环是指当：​

•

没有真正的验证者。 只有一位被要求“审核”的二号特工，没有任何客观依据。两个乐观主义者达成了一致。​

•

软完成条件。“完成”由代理的判断来界定，而非由测试、构建或类型检查决定。​

•

没有硬性终止条件。循环会持续运行，直到外部因素将其终止（如达到速率限制或您主动停止），而不是等到验证成功为止。​

修复就是第11步中的那道门——一种能够判定工作是否失败的客观标准。一个通过或失败的测试，一个能编译或不能编译的构建，一个返回零或非零值的代码检查工具。而不是一个带有主观意见的验证器。​

其他值得了解的已测失败模式：​

•

长时间运行时目标漂移。每一步的摘要都存在信息损失；“不要做X”的约束在第47轮时便已消失。缓解措施：每次运行后都应重新阅读一份固定的VISION.md或AGENTS.md文件。​

•

自我偏好偏差。编写代码的主体在给自己的作业打分时过于“仁慈”。缓解措施：引入一个独立的验证子代理，使其无法接触到生成者自身的推理过程。​

•

代理式懒惰。该循环在尚未完全完成时便宣告“已足够”。缓解措施：使用带有由全新模型检查的目标终止条件的/目标。​

​

理解债务与认知屈从。​

这是一种随着循环变得更好而愈发显著的失效模式，而非恶化。以下是奥斯曼尼论文中提到的两项风险：​

•

理解债务。代码回路越快地交付你并未编写的代码，仓库中的内容与你的理解之间的差距就越大。真正让人头疼的，并不是那些微不足道的小问题，而是当你不得不去调试一个团队里没人读过的系统时的那一天。​

•

认知上的屈服。这是一种停止形成自身观点、转而接受回路所输出之物的倾向。当你带着判断去设计这个回路时，它便是良药；而当你为逃避思考而设计它时，它反而成了助燃剂。同样的行动，却带来截然相反的结果。​

这些缓解措施并非技术性的：​

•

阅读差异内容。如果你不仔细查看循环所提交的内容，就是在以复利方式累积理解上的负债。​

•

对门禁进行抽查。 选取几个由该循环打开的PR，并验证批准它们的测试是否确实能够捕获您关注的故障模式。门禁会腐烂。​

•

将循环阻断在架构工作之外。让它仅限于小型、可由机器验证的变更。一旦允许它介入主观判断，理解债务便会加速累积。​

•

与队友一起设计循环。在设计循环时，第二双眼睛能够发现那些若不如此便会被循环永久忽视的盲点。​

​

安全税。无人值守的环路就是一个无人值守的攻击面。​

无人值守运行的循环也是一个无人值守的攻击面。​

你的循环需要防范的威胁模型：​

•

生成的代码未经审查即被提交。循环会以远超人类阅读速度的速度打开拉取请求。如果没有包含安全检查（SAST、依赖项审计、机密扫描）的准入门槛，不安全的代码就会被自动合并。​

•

技能作为注入载体。一个会自动安装技能的循环，会继承其描述中隐藏的每一条提示注入。在安装前请先审核技能来源。​

•

日志中的凭据。在长时间运行的循环中启用调试日志记录，会导致敏感信息散落在您未监控的日志中。请在生产环境的循环中禁用详细日志记录，并对实际记录的内容进行脱敏处理。​

•

权限范围的无序扩张。一个仅以只读权限进行测试的循环，为了方便起见被额外授予了“一项”写权限，此后却再未重新审计。每30天对权限进行一次重新审计。​

​

§ 使循环变成资金黑洞的常见错误​

•

未执行四条件测试就构建循环。第二步的存在自有其道理。大多数开发者至少会遗漏其中一项条件。​

•

没有客观的准入门槛。一个未经测试、类型检查或构建就要求“审查”的第二位开发者，不过是个第二个乐观主义者罢了。​

•

一名代理人同时负责撰写与核查。自我偏好偏差。制作者给自己批改作业，结果总是“A+”。​

•

无状态文件。明天的运行将从零开始，而非继续上次的进度。​

•

模糊的停止条件。“看起来不错就结束”从来行不通。请使用测试、类型通过或通过构建来判断。​

•

无令牌预算上限。循环会重新读取上下文并重试。如果没有上限，雄心勃勃的循环可能会消耗你预期的5到10倍的令牌。​

•

在采用严格验证的消费套餐上运行循环。无论是令牌计费还是速率限制，二者必居其一。​

•

正在自动安装社区技能。在已审计的17,022个技能中，有520个存在凭据泄露风险。请在安装前仔细阅读相关来源。​

•

在需要主观判断的工作上设置闭环。架构、身份认证、支付以及那些模糊的产品决策，都应聚焦于代码检查与修复的闭环，而非战略层面。​

•

未阅读差异。理解债务以复利累积。当你不得不去调试一个无人读过的系统时，其代价远高于当初那些代码片段的开销。​

​