Loop Engineering，从 Prompt 工程师到 Loop 架构师的 14 步路线图
大多数开发者至今仍在手动给编程 Agent 写提示词：输入，等待，看 diff，再输入。十个开发者里有九个，从未写过一个替自己向 Agent 发送提示词的循环。
没有自动化，没有状态文件，没有验证器，没有定时调度。杠杆点已经转移了，从"写提示词"变成了"设计一套替你写提示词的系统"。这就是从提示词写手到循环设计师的 14 步路线图。
本文内容来源于 Anthropic 的工程文档、Addy Osmani 关于循环工程的长文，以及近期的效能研究。
三个层级：先判断你是否真的需要循环，再学习五个核心模块，最后构建一个最小可用的循环。
14 个步骤，3 个层级。别再手写提示词了，开始设计循环。
第一部分：为什么要做，以及怎么判断该不该做
01. 循环工程，就是用系统取代你自己来写提示词
过去两年，使用编程 Agent 的方式是：写提示词、提供上下文、看返回结果、再写下一条提示词。Agent 是工具，你全程握着它。这个阶段正在结束。
循环工程是构建一个小系统，它能自动找到任务、交给 Agent、检查结果、记录发生了什么，并决定下一步该做什么，全程无需人工介入。你只需设计一次这个系统，之后由它来给 Agent 下达提示词。
Addy Osmani 把它拆解为六个组成部分：
Anthropic 的工程师现在每天合并的代码量是 2024 年的八倍。Anthropic 自己也承认这个数字"几乎肯定夸大了真实的生产力提升"。
具体数字有争议，但机制没有争议：杠杆点已经从写提示词，转移到了设计发送提示词的循环上。
02. 在动手之前，先跑一遍四条件测试
循环只在四个条件同时满足时才划算。少一个，循环的成本就会超过收益。这是来自 AlphaSignal 分析的真话，也是大多数文章会跳过的部分：
四个条件具体来说：
任务是重复的。
循环的搭建成本需要通过多次运行来摊薄。一次性任务用好的提示词更快更便宜。如果一项工作不是每周都出现，那它不需要循环，一个一次性脚本就够了。
验证可以自动化。
循环需要一个你不在场也能否决结果的机制：测试套件、类型检查、Linter、构建。没有自动检查，你又回到了逐条看 diff 的老路，而这恰恰是循环本该替你省掉的工作。
Token 预算扛得住浪费。
循环会反复读取上下文、重试、探索。无论最终是否产出可交付的结果，Token 都在消耗。Token 额度充裕的团队会觉得循环理所当然，而按量计费的开发者则需要认真评估投入产出比。
Agent 拥有高级工程师的工具链。
日志、可复现的环境、运行自己写的代码并看到哪里报错的能力。缺少这些条件，循环的每一轮迭代都无法获得有效反馈。
03. 谁赢谁输？循环偏爱有预算的人
循环工程的经济性因人而异。Token 预算充足的团队自然觉得它值得投入，而使用消费级套餐的个人开发者在跑重度验证循环时，需要面对限额和成本压力。
实际受益的人：
- 拥有重复性、机器可检查的工作且有预算的团队，例如持续测试分诊、依赖更新、Lint 修复、Issue 转 PR 草稿（前提是代码库有强测试覆盖）。
- 测试套件完善的代码库。判断标准是：如果一个初级工程师按清单就能完成任务，测试套件能覆盖他的错误，那这类工作就适合交给循环。
- 已经在使用多 Agent 模式的异步协作团队。循环为这类团队补上了缺失的编排层。
现阶段应该跳过的人：
- 用消费级套餐的独立开发者。Token 账单到得比生产力提升快。
- 缺乏自动化验证的代码库。没有客观检查机制的循环，本质上是 Agent 在反复确认自己的产出，没有纠错能力。
- 瓶颈在代码评审而非编码速度的团队。循环会产出更多代码，如果评审已经是瓶颈，它只会让待审队列更长。
对于一次性任务、探索性工作，或者"完成"本身需要主观判断的场景，一条精准的提示词仍然是更高效的选择。循环工程的价值是真实的，但在当前阶段，大多数开发者还不需要它。
04. 30 秒循环检查清单
第 2 步的四条件测试是战略层面的决策。这里是战术层面的，针对具体任务决定是否值得做成循环的快速检查。
有一条不满足，就继续用手动提示词。
- 任务至少每周发生一次。频率低于每周，搭建成本永远收不回来。
- 测试、类型检查、构建或 Linter 能自动否决不合格的产出。没有自动门禁，等于让 Agent 自己评判自己的结果。
- Agent 能运行自己修改的代码。没有可复现的运行环境，迭代就缺乏有效反馈。
- 循环有硬性终止条件：Token 预算、迭代次数上限或时间限制。缺少终止条件的循环会持续运行，直到有人注意到异常开销。
- 合并、部署或依赖变更前必须有人审核。所有不可逆操作都需要设置人工审批节点。
好的第一个循环：
- CI 失败分诊：每晚扫描失败，分类原因，为简单问题起草修复 PR。
- 依赖升级 PR：每周扫描更新，测试兼容性，开 PR。
- Lint 修复：每次 PR 打开时自动应用代码风格修复。
- Flaky 测试复现：循环运行直到一个假设经受住测试。
- 有强测试覆盖的代码库中，从 Issue 到 PR 草稿的转换。
不适合做第一个循环的（这些需要人全程参与）：
- 架构重写
- 认证或支付代码
- 生产环境部署
- 模糊的产品需求
- 任何"完成"需要主观判断的工作
第二部分：五个核心模块
05. 自动化：心跳
自动化是让循环区别于"手动跑一次"的关键。它按定时、事件或触发条件启动，构成循环的心跳，其他所有组件都依赖它来驱动。
在两个主流工具中的实现方式：
Codex.
通过 Automations 面板配置：选择项目、设定提示词和运行频率，选择本地签出或后台 worktree。有发现的运行进入 Triage 收件箱，无发现的自动归档。
Claude Code.
提供三个可组合的原语：
/loop用于会话级定时，桌面端定时任务在重启后仍然存活，Routines 支持离线云端运行。可配合 hooks 处理生命周期事件。
自动化内部有两个关键原语，直接决定循环的效率：
/loop按固定频率重复运行，适用于需要定期检查的场景，不依赖状态变化。
/goal持续运行直到指定条件满足。由一个独立的小模型来判断是否达成目标，避免让写代码的 Agent 自行评判完成状态。
这体现了"制作者与检查者分离"的原则，并将其应用于循环的终止条件。
06. Worktree：并行而不混乱
同时运行多个 Agent 时，文件冲突不可避免。两个 Agent 写同一个文件，本质上和两个工程师在不沟通的情况下修改同一段代码是一样的问题。
Git worktree 提供了解决方案：为每个 Agent 创建独立的工作目录，各自在独立分支上工作，同时共享仓库历史。从物理层面隔离了不同 Agent 的修改。
两个工具中的实现方式：
Codex
内建了 worktree 支持，多个线程可以同时操作同一个仓库而互不干扰。
Claude Code
直接暴露 git worktree 能力，通过
--worktree标志在独立签出中打开会话。子 Agent 可设置isolation: worktree，获得独立的签出环境，完成后自动清理。
Worktree 解决了文件层面的冲突问题，但真正的瓶颈在于人。你的代码评审带宽决定了实际能同时运行多少个并行 Agent，工具本身不是限制因素。
07. Skills：项目知识写一次，每次运行都能读取
Skill 的作用是将项目上下文持久化，避免每次开启新会话都重新解释一遍。两个工具采用相同的格式：一个包含 SKILL.md 的文件夹，存放指令和元数据，可选附带脚本、参考资料和素材。
这对循环尤为重要：没有 Skills 的循环在每轮运行时都要从零推导项目上下文。有了 Skills，知识可以跨运行积累。项目约定、构建步骤、特定的技术决策和历史教训，只需写入一次，后续每次运行都能直接读取。
08. 连接器：通过 MCP 让循环接入你的真实工具
只能访问文件系统的循环，能力范围非常有限。连接器基于模型上下文协议（MCP）构建，让 Agent 可以读取 Issue 追踪器、查询数据库、调用预发环境 API、在 Slack 中发送通知。
Codex 和 Claude Code 都支持 MCP，因此为一个工具开发的连接器通常可以在另一个中直接复用。
连接器的价值在于：它让循环从"告诉你应该怎么修"变成"自己开 PR、关联工单、CI 通过后在频道里通知"。循环因此可以在你的真实工作环境中直接执行操作。
按投入产出比排列，最值得优先接入的连接器：
- **GitHub：**读仓库、建分支、开 PR、评论 Issue、响应 Webhook 事件。对任何代码循环来说，这是第一天就能产生最大价值的连接器。
- **Linear 或 Jira：**随循环进展更新工单状态，将 PR 关联到 Issue，验证通过时自动关闭。
- **Slack：**发布分诊结果，需要人工介入时发送通知，每天早上汇总过夜运行情况。
- **Sentry 或其他错误追踪器：**让循环自动调查线上告警，为高频问题起草修复方案。
09. 子 Agent：让制作者远离检查者
循环中最有价值的结构设计，是将生成代码的 Agent 和验证代码的 Agent 分离。
Osmani 对此有一个准确的观察：生成代码的模型在评估自身产出时缺乏客观性。引入一个使用不同指令、甚至不同模型的第二个 Agent 来做验证，能有效发现第一个 Agent 自身无法识别的问题。
这本质上就是 Anthropic 在 2024 年 12 月工程博客中描述的"评估者-优化者"模式。一个模型负责生成，另一个负责批判，交替进行。这个概念在 2026 年被广泛讨论，但实际上在十八个月前就已有工程文档记录。
两个工具中的实现方式：
Codex
按需创建子 Agent，并行运行后将结果合并。你可以在
.codex/agents/中通过 TOML 文件定义自己的 Agent，包括名称、描述、指令，以及可选的模型和推理力度配置。例如安全审查员可以使用强模型配合高推理力度，而探索器使用轻量级只读模型。Claude Code
通过
.claude/agents/中的子 Agent 和 Agent 团队实现类似功能，支持在多个 Agent 之间传递工作。典型分工是：一个负责探索，一个负责实现，一个负责对照规格验证。
这在循环场景中尤为关键：循环在无人监督的情况下运行，一个可靠的独立验证者是你能放心离开的前提。子 Agent 会带来额外的 Token 开销，因为每个 Agent 都有独立的模型调用和工具使用。应当将这部分预算集中投入到真正需要第二意见的环节。
第三部分：要么做对，要么别做
10. 状态文件：Agent 会遗忘，文件不会
状态文件的概念看似简单，却是每个可用循环的核心支撑。它可以是一个 Markdown 文件、一个 Linear 看板或一个 JSON 文件，形式不重要，关键是它存在于单次对话之外，持续记录"已完成"和"待完成"的内容。
Agent 默认没有跨会话记忆。本次运行中积累的上下文，下次运行时就不存在了，除非显式写入外部存储。
Osmani 的总结很精确：Agent 会遗忘，仓库不会。没有持久状态的循环每次都从头开始；有状态的循环可以断点续跑。
状态文件有两种常见的存放方式：
仓库中的 Markdown 文件：
放在根目录或
.claude/下的 STATE.md。纳入版本控制，简单直观，diff 可读。适合个人或小团队。**外部系统（Linear、GitHub Issues、数据库）：**跨仓库存活，支持查询和团队级可见性。适合需要多人了解循环运行状态的生产级场景。
对于长期运行且存在目标漂移风险的循环，状态文件应配合一个常驻的高层规格文档（如 VISION.md 或 AGENTS.md），Agent 在每次运行时重新读取。状态文件告诉 Agent 当前进度，规格文档告诉它最终目标。
11. 最小可行循环
通过了第 2 步的四条件测试后，应从最小可用的循环开始构建。四个组成部分，不需要复杂的集群架构。
四个组成部分：
一个自动化。
按固定频率触发、在明确条件下停止的定时运行。在 Claude Code 中使用
/loop，在 Codex 中使用 Automation。如果需要运行到特定条件满足为止，配合/goal使用。一个 Skill。
一个 SKILL.md 文件，持久化项目上下文，避免 Agent 在每次运行时重新推导。
一个状态文件。
Markdown 文件或 Linear 看板，记录已完成和待完成的事项。确保下次运行是继续推进，而不是从头开始。
一个门禁。
测试、类型检查或构建，能自动否决不合格的产出。这个环节决定了循环是在创造价值还是在消耗资源。
构建顺序很重要：先让一次手动运行稳定可靠，再将其封装为 Skill，再包装成循环，最后设置定时调度。跳过中间步骤是循环在生产环境失败的主要原因。
衡量循环效果的核心指标是**每个被接受变更的成本，**而不是 Token 消耗量、任务尝试次数或循环调度次数。如果变更的接受率低于 50%，说明你在替循环承担它本该省掉的评审工作，这种情况下循环是亏损的。
12. “Ralph Wiggum 循环”：悄悄失败的循环
工程师 Geoffrey Huntley 记录并命名了这种失败模式：Agent 在任务尚未完成时就提前发出完成信号，循环基于这个错误信号退出，产出是半成品。缺乏硬性门禁的循环会以这种方式静默失败，同时持续消耗资源。
这种循环通常出现在以下场景：
缺少客观验证机制。
只有一个被要求"审查"的第二个 Agent，但没有可量化的信号。两个模型相互认同，实际上没有形成有效的质量控制。
完成条件不明确。
"完成"由 Agent 自行判断，而非由测试、构建或类型检查来确定。
没有硬性终止机制。
循环持续运行直到被外部因素中断（触达限额或被人发现），而不是在成功验证后主动停止。
解决方案就是第 11 步提到的门禁：一个能客观否决产出的机制。通过或失败的测试，编译成功或失败的构建，返回零或非零的 Linter。关键在于门禁必须是客观的，而不是依赖模型的主观判断。
其他经过验证的失败模式同样值得关注：
长会话中的目标漂移。
每次上下文摘要都伴随信息损失。"不要做 X"这类约束在经过数十轮迭代后可能被丢弃。对策是维护一个常驻的规格文档（VISION.md 或 AGENTS.md），在每次运行时重新加载。
自我偏好偏差。
生成代码的 Agent 在评估自身产出时天然缺乏客观性。对策是引入一个从未接触过生成过程的独立验证子 Agent。
提前声明完成。
循环在任务部分完成时就报告成功。对策是使用带有客观终止条件的
/goal，由独立模型来判断条件是否真正满足。
13. 理解力负债与认知投降
这是一种随循环效率提升而日益突出的失败模式。Osmani 在文章中定义了两个风险：
理解力负债（Comprehension Debt）。
循环交付代码的速度越快，仓库中实际存在的内容与团队成员理解的内容之间的差距就越大。长远来看，真正高昂的成本不是 Token 消耗，而是某天需要调试一个团队中没有人真正读过的系统。
认知投降（Cognitive Surrender）。
指逐渐放弃独立判断，转而无条件接受循环返回结果的倾向。带着判断力设计循环，它是效率工具；为了回避思考而依赖循环，它就成了风险放大器。同样的行为，结果取决于使用者的态度。
应对措施主要不在技术层面：
审阅 diff。
不阅读循环产出的代码变更，等于在持续积累理解力负债。
定期抽查门禁。
选取循环提交的部分 PR，验证其通过的测试是否真正覆盖了你关注的失败场景。门禁的有效性会随时间衰减。
限制循环的工作范围。
只让循环处理小型的、可机器验证的变更。一旦将需要工程判断的决策交给循环，理解力负债会加速积累。
协作设计循环。
多人参与循环的设计过程，有助于发现单人视角下的盲点。这些盲点一旦被忽略，循环会在后续运行中持续放大它们的影响。
14. 安全税：无人看管的循环就是无人看管的攻击面
无人值守的循环，本质上也是一个无人值守的攻击面。
需要纳入考量的威胁模型：
未经审查的代码发布。
循环创建 PR 的速度远超人工审阅速度。如果门禁中不包含安全检查（SAST、依赖审计、密钥扫描），存在安全隐患的代码可能被自动合并。
Skills 成为注入向量。
自动安装第三方 Skills 的循环，会继承隐藏在 Skill 描述中的提示词注入风险。安装任何 Skill 之前应先审计其来源和内容。
日志中的敏感信息泄露。
长时间运行的循环在调试日志中可能记录密钥等敏感信息。生产环境的循环应关闭详细日志输出，并对必要的日志进行脱敏处理。
权限范围蔓延。
最初以只读权限测试的循环，后续可能因便利需要被逐步添加写权限，且不再被重新审计。建议每 30 天对循环的权限配置进行一次审计。
把循环变成烧钱机器的典型错误
- 跳过四条件测试直接构建循环。大多数开发者至少不满足其中一个条件，第 2 步的测试是必要的筛选。
- 缺少客观门禁。一个被要求"审查"但没有配套测试、类型检查或构建验证的 Agent，无法提供有效的质量控制。
- 同一个 Agent 同时负责生成和验证。自我偏好偏差使得产出缺乏客观的质量评估。
- 没有状态文件。每次运行都从零开始，无法利用之前的进展。
- 终止条件不明确。主观判断式的完成标准不可靠，应使用测试通过、类型检查通过或构建成功等客观指标。
- 没有设置 Token 预算上限。循环会反复读取上下文和重试，缺少上限的情况下，实际消耗可能达到预期的 5 到 10 倍。
- 在消费级套餐上运行重度验证循环。会先遇到限额或产生超出预期的账单。
- 自动安装社区 Skills。在被审计的 17,022 个 Skills 中，有 520 个存在凭证泄露问题。安装前应审阅源码。
- 在需要工程判断的工作上使用循环。架构设计、认证、支付、模糊的产品决策应由人来处理，循环适合 Lint 修复这类机械性任务。
- 不审阅 diff。理解力负债以复利方式增长。当你需要调试一个团队中无人读过的系统时，付出的代价远高于 Token 开销。
结论：杠杆点转移了，你的角色也是
过去两年，使用编程 Agent 的核心杠杆在提示词上：更好的提示词，更好的上下文，更好的单次输出质量。
这个阶段正在结束。Agent 的能力已经足够强，下一个杠杆点上移了一层，即设计一个系统来决定 Agent 做什么、什么时候做、用什么门禁验证、以及在运行之间保留哪些状态。
但务实的判断是：不是所有人都应该立即投入循环工程。大多数开发者在当前阶段还不需要它。只有当任务持续重复、验证可以自动化、预算能承受试错成本、Agent 具备完整的工具链时，循环才有正向回报。缺少任何一个条件，循环的成本都会超过收益。
如果你通过了测试，从最小规模开始：一个自动化、一个 Skill、一个状态文件、一个门禁。先让手动运行稳定可靠，再封装为 Skill，再包装成循环，最后设置定时调度。顺序很重要，跳过步骤意味着你在为一个自己无法完全掌控的系统承担风险。
杠杆点已经转移。构建循环，但始终保持工程师的判断力。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～