大模型AI-LoopEngineering

一句话理解 Loop Engineering
Loop Engineering（循环工程）的核心定义来自 Google AI 总监 Addy Osmani 在 2026 年 6 月发表的博客，原文只有一句话：

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. （循环工程，就是把你从"给 Agent 写提示词的人"这个位置上替换掉。你不再亲自写提示词，而是去设计一套能自动完成这件事的系统。）

换句话说，AI 开发的重心正在从"手写 Prompt"转向"设计一套能自动完成提示、执行、验证、迭代的闭环系统"。工程师的角色也随之从"操作者"升级为"系统设计者"。

这个转变有一条清晰的演进脉络：

从 Coding 到 Vibe Coding：我们从"自己写代码"变成了"提需求"。

从 Vibe Coding 到 Loop Engineering：我们从"提一个需求"变成了"提一套闭环流程"——不再只告诉模型做什么，而是把开发、测试、验收、调优、反馈迭代的完整链路都定义好，让模型在流程里自己转起来。

兴起背景：为什么大佬们突然都在谈 Loop
近期 AI 行业几位标志性人物密集讨论这一话题，构成了 Loop Engineering 走红的直接背景：

Boris Cherny（Anthropic，Claude Code 负责人）：公开表示自己使用 Claude Code 时已经不再手写 Prompt，而是转向编写 Loop，用 Loop 驱动工作流。原话流传甚广："I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops."

Peter Steinberger（OpenClaw / 小龙虾创始人）：在 X 上指出"你不应该再手动提示编码 Agent，而应该设计让循环去提示它们的系统"，该观点约 650 万浏览，引爆讨论。

Andrej Karpathy（Vibe Coding、LLM-Wiki 提出者）：强调"你必须把你自己从 Loop 的执行过程中移除出去"。

Addy Osmani（Google AI 总监）：2026 年 6 月发表长文，系统性定义 Loop Engineering，提出六大构建块，为一个病毒式观点提供了可讨论的工程词汇。

根本动因，是人们在原有基础上对效率的再一次追求。回顾 AI Coding 的演进：先是不满足于自己写代码（让 AI 写），再不满足于短任务（用 Agent 跑长链条），再不满足于只在本机跑（上云、上移动端，如 OpenClaw），再不满足于 Skill 静态固定（希望自进化）；而现在，人们不再满足于工具本身仍需大量人工交互，于是希望把"开发→验证→反馈调优"的整个循环都设计好，让 Agent 自主 Loop 出一个更完善的系统。一个系统能否把这个外部 Loop 跑得又好又稳，才真正体现了它处理长程任务的核心能力。

四代演进：从一句话到一个系统
把 Loop Engineering 放进 AI 工程的演进史中看，它是"视角不断向模型外部膨胀"的第四代。每一代都不是否定前一代，而是发现前一代解决的问题只是冰山一角，真正的瓶颈在更外层。

代际

时间

关心什么

核心问题

放大倍率

Prompt Engineering

2022

一次推理的措辞

怎么措辞让模型输出更好

几百 token

Context Engineering

2025

一次推理的整个输入窗口

窗口里装什么、丢什么

十几万 token

Harness Engineering

2026 初

模型外的整套运行环境

工具/沙箱/记忆怎么搭

模型外全部脚手架

Loop Engineering

2026-06

跨多次推理的时间控制

何时继续/停止/回退

完整循环系统

演进的驱动逻辑是"上一代解决自身问题后暴露出更外层瓶颈"：

Prompt 措辞再精妙，若 context 缺关键信息，模型仍做不对 → 催生 Context Engineering。

Context 管好了，但工具接口差、无沙箱、无持久记忆 → 催生 Harness Engineering。

静态组件搭好了，但循环怎么跑（何时停、错误怎么恢复、成本怎么控、长 Loop 怎么防 context rot）成了核心难题 → 催生 Loop Engineering。

一个便于记忆的类比：Prompt 是"写一封邮件的措辞"，Context 是"邮件里附什么附件"，Harness 是"整个办公桌的布置（纸笔、电话、文件柜、门锁）"，Loop 则是"每天的工作节奏（何时处理邮件、开会、复盘、下班）"。

Agent = Model + Harness。 Harness 又分静态部分（搭一次跑很久的"舞台"：工具定义 Tool Surface、Agent-Computer Interface、安全沙箱 Sandbox、磁盘记忆 Memory Files）与动态部分（每次推理都在变的"节奏"：Context Engineering 管单次输入，Loop Engineering 管多次推理的串联）。这条"静态/动态"分界线揭示了三点：四代演进是包含而非替代；静态部分的设计质量决定动态部分的上限；当模型能力增长放缓时，Harness 的工程质量会从"加分项"变成"决定生死的全部"。

三派观点与争议
乐观派（Steinberger、Osmani、Cherny）：工程师角色从操作者升级为系统设计者；Boris Cherny 透露大量代码由 routines 编写，Claude Code 用户报告同时运行 10-15 个并行 Agent。

实用派（nrs、Jason Zhou）：关键不是"是否用循环"，而是"你设计的是哪种循环"——量化研究循环、设计迭代循环、编码循环、产品反馈循环各有不同。

审慎派（AlphaSignal 等）：① 验证不可靠——Agent 自称"完成"≠真正完成，必须信任确定性验证器；② 理解力债务——"Loop 交付了，不代表你理解它"；③ 认知投降——循环越顺，人越容易放弃判断力；④ 成本爆炸——token 消耗极快，应分诊阶段保持低成本。

Osmani 特别强调，Loop 改变了工作方式，但没有把人从工作中删除，反而放大三个老问题：验证仍在你（无人值守也会无人值守地犯错，verifier 的 "done" 是声明不是证明）；理解力会腐烂（comprehension debt，Loop 越快产出你没写的代码，你对代码库的理解差距越大）；舒适姿态最危险（cognitive surrender，很容易停止思考、接受一切输出）。他的忠告是："Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."

Loop Engineering 的六大核心构件
Addy Osmani 把一个完整的 Loop 拆解为若干系统级原语。综合几篇文章，可归纳为"五个构件 + 一个记忆层"，且这些能力已内建于 Codex 与 Claude Code——这意味着 Loop 设计不再绑死于某个工具。

1. Automations（自动化触发）——Loop 的心跳
没有它，Loop 只是"手动跑了一次"。职责是 discovery + triage（发现 + 分类），而非直接写代码：自动巡检昨天的 CI 失败、新增 issue、最近 commit 引入的问题、依赖安全漏洞、长期未处理的 TODO——把团队的被动响应变成主动巡检。

Codex：Automations 面板选项目、写 Prompt、定频率、选本地或后台分支跑；有问题进 Triage 收件箱，无问题自动归档。/goal 命令会在多轮对话中持续工作，直到设定条件满足，支持暂停/恢复/清除。

Claude Code：靠 Cron 调度 + Hook 实现。/loop 让 Prompt 按间隔重复跑，/goal 持续执行到可验证条件成立，还能在 Agent 生命周期节点用 Hook 触发 Shell 命令。

/loop 与 /goal 的区别很关键：/loop 按固定节奏重复同一个 Prompt（如每天凌晨跑一次 lint）；/goal 持续执行直到独立小模型判定"可验证条件成立"（如"所有测试通过且 lint 无误"）——判定者不是写代码的那个 Agent，这是 maker-checker 分离在退出条件上的应用。

2. Worktrees（工作树隔离）——多 Agent 并行的物理隔离
多个 Agent 同时改同一文件会冲突，就像两个工程师不打招呼往同一行代码提交。Git Worktree 是磁盘上一个独立的工作目录，有自己的分支但共享同一仓库历史，因此一个 Agent 的改动碰不到另一个的代码。注意它不是 branch（逻辑概念），而是物理隔离；最后通过 git merge 合回。

Codex：内置 Worktree，每个 thread 自动隔离。

Claude Code：--worktree 参数在独立 checkout 开会话，或给子 Agent 设 isolation: worktree，每个 Agent 拿到一份用完自动清理的代码副本。

3. Skills（可进化的技能包）——把项目知识外化到磁盘
Skill 是可渐进式披露、可复用的能力包，由 Markdown 文档（SKILL.md）+ 脚本 + 资源组成。它与"规则/约定"不同：规则是一句话约束（如"不要 mock 数据库"），始终遵守；Skill 是操作流程（如"对这个 repo 做 PR review"），被触发时执行。

Osmani 提出 intent debt（意图债务）：Agent 每次启动都会失忆，用自信的猜测填补意图空白。Skill 把意图外化到磁盘、消除猜测。没有 Skill 的 Loop 每轮从零推导项目约定，有 Skill 的 Loop 能力可以复利积累——越跑越聪明。经验法则：同一套操作让 Agent 做三次以上，就该提取成 Skill。

4. Connectors / Plugins（连接器/插件）——让 Loop 触达真实工具链
基于 MCP 协议，把外部 API 接入 Agent：读 Linear/Jira 的 issue、查数据库、调 staging API、发 Slack、开 PR。没有 Connector，Agent 只是封闭的推理引擎；有了它，Loop 才从"告诉你它能修什么"变成"自动开 PR、关联 ticket、CI 绿了通知 channel"。Codex 与 Claude Code 都说 MCP，Connector 通常可跨产品复用。这也是目前落地最广泛的基础设施。

5. Sub-agents（子智能体）——Loop 中最有价值的结构
Osmani 原话称其为 Loop 中最有价值的结构，核心原则是：**写代码的模型不能给自己打分。**典型分工是一个 explore（探索）→ 一个 implement（实现）→ 一个 verify against spec（对照规范验证）。

之所以不让主 Agent 自我检查，是因为它"当局者迷"——就像人写完代码总觉得完美，换个人一看就发现问题。引入独立的验收 Sub-agent，本质是用角色隔离打破认知盲区，刻意制造一种"博弈"关系。在无人值守的 Loop 里，一个你真正信任的 verifier，是你能放心离开的唯一理由。

注意事项：Sub-agent 并非越多越好，缺乏主 Agent 的有效调度会导致各干各的、失去一致性；探索/分析类子任务可大胆拆分，但最终结果须汇总回主 Agent，验证类 Sub-agent 务必保持独立（避免"既当运动员又当裁判员"）。每个 Sub-agent 都有独立的模型调用与工具交互，token 消耗更高，应花在值得 second opinion 的地方。

6. Memory / State（记忆/状态）——Loop 的脊柱
追踪"哪些事已经做完了"。可以用 Markdown 文件（AGENTS.md、progress 文件、STATE.md、LOOP-STATE.json），也可以通过 MCP 连接 Linear 这类工具同步。核心是任何"活在单次对话之外"的持久存储，记录 discovered → triaged → in-progress → verified → done 以及失败原因。

为什么重要：Agent 在 session 之间会完全失忆，没有 Memory，明天的 Loop 不知道今天做过什么，会重复劳动或遗漏。Osmani 说它"Sounds too dumb to matter"，但这正是每个长时运行 Agent 依赖的核心 trick。

工具原语对照表
构件

核心角色

Claude Code 实现

OpenAI Codex 实现

Automations

心跳调度，"偶尔检查"变自动循环

/loop、/goal、cron、Hooks、GitHub Actions

Automations 面板、/goal

Worktrees

隔离并行 Agent 工作目录

git worktree、--worktree、subagent isolation: worktree

内置 per-thread worktree

Skills

跨会话项目知识，避免冷启动

CLAUDE.md + Skills 插件

SKILL.md + Agent Skills

Connectors/Plugins

连接 GitHub/Slack/Jira 等

MCP servers + Plugins

MCP Connectors + Plugins

Sub-agents

Maker/Checker 分离，上下文隔离

.claude/agents/、agent teams

.codex/agents/ TOML 定义

Memory/State

跨会话持久状态

STATE.md、LOOP-STATE.json

Markdown / Linear via MCP

Maker / Checker 分离：为什么必须"生成者不当裁判"
这是 Loop 可靠性的基石，值得单独展开。根本问题是：同一个模型给自己生成的东西打分，天然有 bias——生成时注意力天然倾向自己输出的 token，模型没有真正的"自我怀疑"机制，在开放式任务（无客观 ground truth）中更容易自我确认。

分离 maker 和 checker，本质是把"生成"和"判断"解耦，用不同上下文、不同指令、甚至不同模型逼近更客观的验证。

Maker（生成者）：产生候选方案，指令鼓励发散创造，可用温度较高、更大的模型；输入 = 目标 + 历史尝试记录（含被拒原因）+ 可用技能/工具。

Checker（验证者）：判断是否满足预设条件，指令严格保守、逐条核对（"宁可误杀，不可放过"），可用温度低、逻辑严谨的模型甚至规则引擎 + 小模型混合；输出必须结构化：通过/不通过 + 违反了哪条规则 + 建议修改方向，这样 maker 下一轮才有修正依据。

改造模式（针对单个目标的闭环）：

用户请求 + 目标 + 约束
↓
outer loop 初始化 state（空尝试记录）
↓
┌─────────────────────────────────┐
│ maker 生成方案（参考历史失败原因） │
│ ↓ │
│ 执行方案（调用工具/修改配置） │
│ ↓ │
│ checker 验证方案 │
│ ├─ 通过 → 输出方案，结束 │
│ └─ 不通过 → 记录失败原因到 state │
│ ↓ │
│ 回到 maker（重试） │
└─────────────────────────────────┘
一键获取完整项目代码

关键改动点：不再让同一 Agent 既生成又验证；增加持久化的失败记忆（把"方案 + 拒绝原因"写入 state，下轮提醒 maker 避坑）；设置重试上限（如 3 次，超限挂起转人工）；支持并行 maker（高自由度任务同时生成多个方向，各自由 checker 验证只留通过的）。

需要澄清的三组混淆：

Maker/Checker ≠ 单元测试：单元测试是固定确定性的；checker 可以是动态的、甚至由模型驱动。

Maker/Checker ≠ RLHF：RLHF 是离线训练偏好模型做 alignment；checker 是在线运行的实时验证器，直接参与 loop 决策。

Maker/Checker ≠ Self-critique：Self-critique 是同一模型自己批评自己，仍有 bias；分离（尤其用不同模型）后 bias 明显降低。

递归 Goal：从"写步骤"到"写目标"
与 maker/checker 并列的另一大启发，是从 workflow（DAG，显式编码求解路径）升级为递归 goal（声明可验证的目标条件 + 允许的行动空间，由闭环系统自行寻找步骤序列）。

/goal 就是这个原语的实现：给一个可验证目标（如"test/auth 全部通过且 lint 无误"），系统持续迭代直到独立 checker 判定为真；每次尝试结果写入外部 state 供下轮参考。核心特征是目标驱动（从 how 到 what）、递归迭代、分离校验、持久化记忆。

维度

workflow（旧做法）

递归 goal

工程师输入

步骤序列 + 分支条件

目标条件 + 验收脚本 + 约束

路径确定

预先编码

运行时动态搜索

循环/迭代

手动展开或硬编码 while

递归调用自身，自动迭代

停止判断

DAG 条件节点

独立 checker 实时评估

失败后行为

走备选分支或终止

记录失败原因 → 重新规划 → 再试

对业务变化适应

低（需改 DAG）

高（只改目标条件）

注意点：目标必须可验证（模糊目标如"做得更好"无法工作）；警惕搜索空间爆炸与成本不可预测（需硬上限 + 预算仪表盘）；checker 误判会让 loop 失效（关键决策多 checker 投票或人工 fallback）；它不必完全替换 workflow——稳定、路径已知的任务用 workflow 更高效，递归 goal 适用于探索性、变化频繁、路径不确定的任务。

伪代码 vs 真实差距
社区反复出现的 Loop 伪代码骨架：

state = init_state(goal) # 递归目标 + 暂存区
for step in range(MAX_STEPS): # 硬性上限：防止无限循环
thought = model.reason(state) # ReAct：先推理
action = model.choose_action(state)
result = tools.execute(action) # 触达真实环境
state = update(state, thought, action, result)
state = compact(state) # 控制上下文窗口
if verifier.passes(state): # 确定性验证 = 奖励信号
return success(state)
if no_progress(state) or budget.exhausted():
return escalate_to_human(state) # 死胡同 → 升级给人类
return escalate_to_human(state) # 超出步数 → 交还人类
一键获取完整项目代码

真正有工程价值的决策都在这十几行之外——模型是中间的黑盒，工程在于围绕它的循环。

维度

伪代码假设

真实挑战

验证

verifier.passes 一行搞定

确定性检查覆盖有限，LLM-as-judge 可被自圆其说

上下文

compact 一行搞定

长循环上下文窗口必然溢出，需精细外部化策略

终止

no_progress 一行搞定

重复同一错误与尝试新方案难以区分

目标

假设 goal 清晰可验证

"让 CI 变绿"是好 goal，"改善代码"是坏 goal

成本

不在伪代码中

无值守 Loop 的 token 成本可以轻易失控

长 Loop 的三大失败模式与对策
Loop 越长，以下三个问题越致命（短 Loop 里不严重，因为人每步都在）：

失败模式

含义

对应方案

Context rot（上下文腐烂）

早期决策被遗忘，重新引入多轮前已修过的 bug

Compaction 历史压缩、Memory Files 磁盘持久化

Self-grading bias（自评偏高）

模型给自己的工作打分总是偏高

Sub-agent maker/checker 分离，验证者与执行者不同

No persistent state（无持久状态）

session 间失忆，下次不知上次做到哪

磁盘文件（feature_list.json、progress.txt、git commit）

这三大失败模式恰好对应 Harness 动态部分的三个层次：Context rot 由 Context Engineering 防，Self-grading bias 由 Loop 的 Sub-agent 架构防，No persistent state 由 Loop 的 Memory 层防。

使用建议与适用边界
Loop 不是银弹，用之前要想清楚：

适用场景：需求明确、验证标准清晰、可自动判定的任务。

风险提示：用 Loop 后中间过程你不参与，如果开头没把需求和验证逻辑写清楚，Loop 很可能从一开始就跑偏，烧了大量 token 结果还偏离预期。因此 Loop 对使用者"描述需求和验证的能力"要求其实更高了。

固定流程优先沉淀为脚本/Skill：如果流程固定、不需模型每次重新推理，直接写成脚本更稳、更省；每天重跑 Loop 既费 token，实现路径又可能漂移、不好复现。确实需要模型动态判断的任务，才做成可复用的 Skill 或 Loop。

能力不足时回归 HITL：如果你很难把需求和验证写清楚、把控不住 Loop 效果，老实回到 Human-in-the-Loop、先人工迭代几轮更稳妥经济。

一句话立场：**技术方法论没有对错，只有适不适合。**当你有明确需求和清晰验证标准时，Loop 是提效神器；当需求和验证都模糊时，人在中间反复反馈校正，反而可能更稳妥。别为了用而用。

一点延伸思考：范式迭代的速度与人的能力
从 prompt 到 loop，中间隔着 agent、workflow、state、checker、worktree、skill……而且它们不是简单替代，是叠加：你既要懂旧的，还得会新的。对比服务端从微服务到 serverless 走了六七年、每阶段都有缓冲期，LLM 应用这边的概念迭代只用了约两年，更像"进化、飞升"。

由此浮现的真正风险，不只是个人学不学得会，而是整个软件工程的稳定性：当工具在指数级进化、而人的能力在平均化甚至退化时，那些原本负责代码审查、架构设计、边界判断的"守门员"若被替换，LLM 生成的代码直接上线、Loop 自动跑，可能没有人有能力判断它跑得对不对。Osmani 的三个警告（验证在你、理解债、认知投降）会因此更尖锐。

因而，Loop 越强大，人的审查与判断力就越珍贵。未来的核心竞争力，或许不再是"写代码"，而是"敢不敢让机器写代码 + 有没有能力兜底"——而后者远比前者难。让 Loop 做重复、可验证的工作，把省下的精力投入到理解、验证与判断上，才是"写 Loop 的人"真正该做的事。
————————————————
版权声明：本文为CSDN博主「匿名侠士」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012605629/article/details/162946437