大多数开发者至今仍在手动给编程 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.mdAgent 在每次运行时重新读取。状态文件告诉 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时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 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.mdAgent 在每次运行时重新读取。状态文件告诉 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时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】