Loop Engineering（Agent 闭环工程）
Loop Engineering（闭环工程）的本质，是将你从"手动投喂 Prompt 的人体 API"这一角色中彻底剔除。你转而设计一套能自动驱动工作流运转的底层系统。此处的"闭环（Loop）"可理解为一种递归式目标：你只需定义终态，AI 便会持续迭代直至收敛。它底层由 5 大核心组件构成，而 Claude Code 和 Codex 目前均已点亮这五块技能树。
毫无疑问，这大概率是我们未来与 Coding Agent 协同的终极形态。尽管处于极早期，我们需要保持克制——尤其是你必须对 Token 燃烧率（Burn Rate）保持高度敏锐（Token 自由与 Token 拮据，对应的工程模式天差地别）。你依然需要引入质量卡口来防止代码劣化，业界对于"AI 生成垃圾代码（Slop）"的担忧绝非杞人忧天。即便如此，我们仍值得去进行深度剖析（Drill-down）。
@steipete[2] 近期断言[3]："你绝不该再手动给 Coding Agent 写 Prompt 了。你应该设计一套闭环，让系统自动去 Prompt 你的 Agent。"无独有偶，Anthropic 的 Claude Code 负责人 @bcherny[4] 也表态[5]：“我已彻底摒弃手动 Prompt Claude。我正在运行一些闭环，由它们去自动 Prompt Claude 并调度下一步决策。我现在的核心工作，就是编排闭环（Writing loops）。”
所以，这套理念到底意味着什么？
过去两年，你想从 Coding Agent 那里榨取价值，标准动作是：手搓极其考究的 Prompt，喂足上下文。你敲一段指令，读回复，再敲下一段。Agent 只是个工具，而你始终被死死绑定在执行回路上（Human-in-the-loop），一轮一轮死磕。这种低效模式正在消亡，或者至少先锋开发者们认为它正在走向终结。
现在，你是在架构一个微型系统：让它自己找活、分发任务、校验交付物、落盘进度，然后自主决断（Route）下一步行动。你让这套系统去"驱动"Agent，而不是你亲自下场。我之前布道过它的前置形态——Agent Harness Engineering（智能体底座工程）[6]，即打造包裹单 Agent 运行的沙盒环境；以及 Factory Model（工厂模式）[7]——构建软件的流水线基建。Loop Engineering 就架设在 Harness 这一层之上。它本质也是一个底层框架，但被挂载了定时器（Timer），能自动拉起（Spawn）子助手，并且实现了实现上下文自驱的迭代闭环。
令人震撼的是，这已然跨越了"工具层面"。一年前，想要跑通一个闭环，你得手撸一堆 Bash 脚本，且必须承担这堆私有"祖传代码"的终身维护成本。如今，这些基座能力已原生内置于产品中。Steinberger 梳理的清单不仅与 Codex 严丝合缝，在 Claude Code 上也实现了像素级对齐。一旦你看透两者底层架构的同构性，便无需再陷入工具选型之争。你只需专注设计一套工具无关（Tool-agnostic）的通用闭环，无论挂载在哪个底座上都能无缝运转。
5 大核心组件，外挂记忆层（Memory）
一个高优闭环[8]必备 5 个核心组件，外加一个状态持久化（State Persistence）容器。我们先做全盘枚举，再逐一映射。
- Automations（自动化机制）：按调度节奏运转、自主完成异常发现与问题分流（Triage）。
- Worktrees（工作树）：物理隔离并行环境，斩断多 Agent 并发时的"相互踩踏"。
- Skills（技能包）：沉淀私有项目上下文，拒绝让 Agent 靠"盲猜"写代码。
- Plugins & Connectors（插件与连接器）：让 Agent 将触角深入你现存的业务主流程工具链。
- Sub-agents（子智能体）：在架构上彻底解耦"出方案的执行者（Maker）“与"做校验的审查者（Checker）”。
然后是第六大核心：Memory（记忆层）。一个 Markdown 进度文件，或一块 Linear 看板——任何游离于单次会话之外、能持久化"已完成什么"与"待办是什么"的存储介质。这听起来平淡无奇。但正如我在长周期 Agent[9]里拆解的，这是所有长生命周期智能体赖以生存的底座技巧：大模型在两次运行之间会清空所有状态，所以记忆必须落盘（Disk-backed），绝不能塞在上下文里。智能体会遗忘，但代码库不会。
目前这两大产品均已原生集齐这 5 块拼图。
命名策略可能略有差异，但底层能力完全对等。我们需要逐个 Drill-down，因为坦白讲，工程细节决定了一个闭环是严丝合缝，还是到处内存泄漏（Leakage）。
Automations（自动化机制）：闭环的"心跳"
Automations 是让一个 Loop 成为真正"闭环"而非"一次性跑批任务"的灵魂。在 Codex 应用中，你在 Automations 面板进行编排：挂载项目、注入它要跑的 Prompt、配置调度频率，并设定它是跑在你的本地工作区（Checkout）还是后台 Worktree 里。发现 Issue 的运行会自动流转至问题分流收件箱（Triage inbox），而未捕捉到异常的运行则自动归档，体验极佳。OpenAI 内部用它们来吃掉枯燥的基建杂活：比如每日 Issue 分流、聚类 CI 报错、自动生成 Commit 简报、甚至追溯上周某人引入的 Bug 源头。更强的是，Automations 可以直接拉起 Skill，从而保障高频任务的长期可维护性：只需触发skill-name，而不是在没人维护的定时任务里硬编码一坨如山般的长文本 Prompt。
Claude Code 依靠调度（Scheduling）与钩子（Hooks）打通了相同的逻辑。你可以用/loop挂载定时 Prompt 或命令，跑 Cron 任务；利用 Hooks 在 Agent 生命周期的特定节点拉起 Shell 命令；或是干脆将整个工作流推入 GitHub Actions，实现关上笔记本后的"离线托管"。其底层思路如出一辙：定义一个自主任务，注入节拍，让结果自动推送到你面前，杜绝人肉轮询。
此外，还有一个必须提及的 Session 级原语（in-session primitive），它直击本文核心。/loop侧重于按固定节拍重跑；而/goal则是持续运转，死磕直到你预设的条件绝对成立。每次迭代（Iteration）后，系统会拉起一个全新的模型实例来做验收校验——彻底掐断写代码的模型"既当裁判又当选手"的作弊可能。你可以下达这样的指令：“确保 test/auth 目录下的测试全绿，且 Lint 零警告”，然后就能放心切出去喝咖啡。Codex 也实装了同名原语/goal，支持跨多轮运转直至可验证的终止条件触发，并支持暂停与恢复。同一个原语，双端通用，这也几乎贯穿了全文的主线逻辑。
所以，这个模块专攻"发现需求"。闭环的后续模块，专攻"干掉需求"。
Worktrees（工作树）：斩断并发时的"互相踩踏"
只要你的并发 Agent 数量大于一，文件读写冲突就是必然的灾难点。两个 Agent 强行修改同一文件，和两个碳基工程师没有对齐就向同一块代码提交 PR 是一样的痛点。git worktree是完美的解法：它提供独立的工作目录，挂载在独立分支上，却共享同一份代码的历史树。这从物理层面掐断了一个 Agent 污染另一个 Agent 工作区的可能性。
Codex 在底层原生融合了 Worktree 机制，多线程（Threads）并发打向同一个 Repo 也绝对不会互踩。Claude Code 同样提供了极致的隔离：借助git worktree、--worktree标志位在独立的隔离区中启动会话；你还可以为子智能体打上isolation: worktree标签，确保每个助手被拉起时都获得一个纯净且用后即焚的沙盒。我在编排税（The Orchestration Tax）[10]一文中探讨过这背后的"人效博弈"：Worktree 虽然抹平了机器层面的物理碰撞，但你个人的心智带宽依旧是系统的瓶颈。你能 Review 多少代码，决定了并发量的上限，而非工具的 QPS。
Skills（技能包）：拒绝冷启动时的"上下文复读"
Skill 的存在，是为了让你不用像金鱼一样，在每次新 Session 开启时都要向模型复述项目的上下文。两款工具遵循同样的工程范式：建立一个包含SKILL.md的目录，内部封装指令与元数据，并可外挂脚本、参考文档与静态资源。在 Codex 中，敲击$或/skills即可唤起，甚至当任务命中 Skill 描述时会隐式触发——这也是为什么一段克制且严谨的描述，永远秒杀抖机灵的 Prompt。Claude Code 采用了像素级一致的机制，我在Agent Skills[11]里详细拆解过该模式。
Skill 也是终结你反复为"意图（Intent）“买单的破局点。正如我在意图债（The Intent Debt）[12]中的推演：Agent 的每次运行都是纯粹的冷启动，它会用迷之自信的"幻觉猜测"填补你意图里的任何空洞。Skill 本质就是"意图的固化”：代码规约、构建链路、“上次引发线上事故后绝对禁止的写法”——这些血泪教训只需沉淀一次，Agent 每次拉起都会自动加载。没有 Skill，闭环每次都在徒手推演你的项目逻辑；有了 Skill，它才能产生复利。
有一点必须厘清：Skill 是"编写格式"，而 Plugin 是"分发渠道"。当你需要跨 Repo 共享 Skill，或者将一组高内聚的 Skill 打包时，你就将其封装为 Plugin。Codex 如此，Claude Code 亦然。
Plugins & Connectors（插件与连接器）：让闭环打通真实工具链
一个只能在本地文件系统里打转的闭环，充其量是个玩具。连接器（基于 MCP 协议构建）让 Agent 真正长出了触角：去读取 Issue 追踪看板、直连数据库捞数据、调取 Staging 环境 API、或是向 Slack 频道推送告警。Codex 与 Claude Code 均深度支持 MCP，这意味着你为其中一端手搓的连接器，通常能直接在另一端无缝运行。而 Plugin 则将 Connector 与 Skill 打包在一起，让你的团队可以一键拉取你的配置，而不是靠记忆重新搭环境。
这就是"Agent 嘴上说’这是修复方案’“与"系统自己拉起 PR、自动关联 Linear Ticket、并在 CI 爆绿后自动 Ping 业务群"之间的绝对降维打击。连接器赋予了闭环在你真实线上环境里执行动作（Act）的权限，而不再是抛出"理论可行方案”。
Sub-agents（子智能体）：架构上的 Maker/Checker 解耦
闭环中最具威力的架构设计，绝对是将"写代码（Maker）"和"审代码（Checker）"的智能体进行硬解耦。让模型对自己的产出物打分，无异于监守自盗。引入第二个被注入了不同指令（甚至搭载不同底层模型）的 Agent，能精准狙击第一个 Agent"自圆其说"的漏洞。
Codex 仅在显式请求时才会拉起（Spawn）子智能体，它们并行运算，随后将结果折叠（Fold）进最终答复。你在.codex/agents/下用 TOML 文件声明专属 Agent：定义名称、职责边界，及可选的模型与推理阈值。因此，你的安全审查官可以是一头挂载了高强度推理模型的巨兽，而探索者则是一个疾速的只读轻量模型。Claude Code 也在.claude/agents/与 Agent Teams 下实装了同样的架构，并支持上下文流转。大厂当前的常规拆分是：一个专攻探索，一个负责落地，一个对齐 PRD 严格校验。
我曾在代码智能体乐团[13]与对抗式代码审查（Adversarial Code Review）[14]中两度重申该理念。这种拆分在闭环中极其致命，因为闭环是在你"挂机（Unattended）"状态下运转的。一个经得起拷问的 Verifier，是你敢切出去喝咖啡的唯一护城河。子智能体的代价是激增的 Token 消耗量，因为每次拉起都在跑独立的模型与 Tool-call，好钢必须用在刀刃上：只在"值得花钱买 Second Opinion"的关键链路投入。这实际上也就是 Claude Code 的/goal底层在做的事：由一个隔离的全新模型实例来宣判闭环是否终止，绝不让干活的模型自己喊停。Maker 与 Checker 的解耦，被原生固化在了终止条件里。
一个高阶业务闭环（Full Loop）长什么样？
将上述组件拼接，单点对话就会跃升为一个微型控制中枢（Control Panel）。这是我高频复用的一套实战拓扑：
每天清晨，一个 Automation 挂载在主 Repo 上按时拉起。它的 Prompt 会唤醒一个分流 Skill，拉取昨晚 CI 的飘红日志、Open Issues 及最新 Commits，并将汇总态写入 Markdown 文件或 Linear 看板。面对每一个值得跟进的异常，该链路会自动开辟一个物理隔离的 Worktree，拉起一个子智能体去起草修复方案（Draft fix），紧接着拉起第二个子智能体拿着项目的私有 Skill 和存量测试用例对其进行暴力 Review。
连接器赋予闭环自动提 PR、流转 Ticket 的权限。任何超纲的 Edge Case 会被捕获并回退至我的分流收件箱中。状态持久化文件则是整条流水线的骨干（Backbone）：它锁死了哪些方案试过、哪些测试 Pass、哪些点依然 Open。明早的自动化链路，会精准对齐今天的断点继续跑。
复盘一下你的实际投入：你只在架构期做了一次设计。你没有为其中任何一个执行动作写过一句手动 Prompt。这正是 Steinberger 观点的硬核落地，无论是在 Codex 还是 Claude Code 中，这套闭环跑得同样丝滑，因为底层基建高度同源。
闭环依然无法替你兜底的"坑"
闭环重塑了研发流，但绝对没有把你从链路中删掉。甚至，随着闭环愈发强大，有三个系统性风险会变得极度尖锐，而非缓解。
代码问责（Accountability）永远在你。一个无人值守运转的闭环，同样具备无人值守搞砸一切的破坏力。你强行解耦审查者与执行者，唯一目的是让闭环输出的"LGTM（搞定了）"稍微有点含金量。但这充其量只是一句系统声明，绝非数学定理。我依然要复述 AI 时代的代码审查[15]里的那条铁律：你的核心工作，是交付你本人亲自 Verify 且敢于兜底的代码。
警惕"理解力剥离"。闭环帮你 Delivery 的速度越快，产出的代码与你大脑中真实掌控的逻辑之间的鸿沟就越深。这便是理解债（Comprehension Debt）[16]。一条异常顺滑的闭环只会让这笔技术债呈几何级膨胀——除非你强迫自己去读它吐出的逻辑。
警惕"认知让渡（Cognitive Surrender）"。当系统全自动运转时，人类的天性会诱发你放弃判断力，直接 Merge 它扔给你的任何东西。带着敬畏心去架构闭环，它是提效的解药；为了逃避动脑去滥用闭环，它就是崩溃的催化剂。动作相同，因果倒置。
去架构你的闭环。但务必坚守极客底色
毫无疑问，这是我们研发生态演变的一次预演。话虽如此，如果我彻底放弃亲身 Review，或者盲目依赖自动化 Loop 去修 Bug，我的产品质量迟早会崩盘。我大概率会陷入"越填坑越深"的向下螺旋。
放手去搭你的 Loop。但也别忘了，直接用 Prompt 驱动 Agent 在某些场景下依然高效。真正的工程素养，在于寻找那个精妙的平衡点。
同样的 Loop 引擎，交由不同人调度，结局大相径庭。有人用它去加杠杆，打穿自己具备极高认知的领域；有人用它去逃避理解工作本身。Loop 引擎不关心这其中的区别。但你必须心知肚明。
正因如此，架构一套闭环远比手写 Prompt 困难得多，而非更简单。Cherny 的潜台词并不是"研发变简单了"，而是工程杠杆的支点，已经彻底转移了。
构建闭环。但请以一个"打算继续掌控系统的工程师"的姿态去构建，而不是沦为一个只会无脑按下"Start"键的按键机器。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～