从 Prompt 到 Loop：AI Agent 的下一个生产单位

ReelOS.AI 禅定｜一句话看懂本文

Loop Engineering 不是把 Prompt 写长，而是把 Agent 的生产单位从一次请求升级成可验证、可观察、可记忆的智能回路。

模型越来越强。
但单轮 Prompt 只能解决一次表达。
任务一变长，反馈、验证、状态和权限都会脱节。
反馈不真实，Agent 就会自我说服。
验证不独立，完成声明就不是证明。
状态不持久，每轮都会从零开始。
权限不分级，自动化会放大风险。
所以瓶颈不再只是模型会不会回答。
而是系统能不能持续启动、执行、观察、验证和记忆。
Automations 负责启动节奏。
Worktrees 负责并行隔离。
Skills 负责沉淀操作规程。
Connectors 负责接入真实环境。
Sub-agents 负责把执行和验证分开。
Memory 负责让经验留在系统外部。
所以 Loop 的本质，不是更高级的 Prompt，而是 AI 原生组织的最小智能生产回路。

Claude Fable 5 为什么像 Loop 时代最严厉的父亲？

过去一年，AI Coding 的主线看起来是模型越来越强、上下文越来越长、工具调用越来越稳。但如果只看模型能力，很容易错过一个更底层的变化：

AI 原生工程的杠杆支点，正在从 Prompt 转向 Loop。

Prompt 是一次请求。
Loop 是一条生产线。

一张图解释从 Prompt 到 Loop：AI Agent 的生产单位从一次请求变成可启动、执行、观察、验证、反思和记忆的生产线。 — 一张图看清楚这篇文章：Prompt 解决一次表达，Loop 设计一条可持续运行的生产线。

Prompt 时代，人类不断给 Agent 下指令：改这里、查那里、跑一下测试、再修一下报错。

Loop 时代，人类不再反复提示 Agent，而是设计一个系统，让系统持续发现问题、分配任务、执行修改、验证结果、沉淀状态，并决定下一步。

这不是交互方式的小变化，而是软件生产方式的变化。

以前是：

人 -> Prompt -> Agent -> 代码

现在变成：

人 -> 设计 Loop -> Loop 调度 Agent -> Agent 写代码 / 跑测试 / 查问题 / 开 PR / 记录状态

工程师不是消失了，而是位置变了。

人从执行者，变成了系统设计者。
从写代码的人，变成了设计代码生产系统的人。
从提示 Agent 的人，变成了设计“提示 Agent 的系统”的人。

这就是 Loop Engineering 的核心。

AI Agent 的生产单位从人类反复提示 Agent，迁移到人类设计 Loop 再由系统调度 Agent。 — Prompt 时代的杠杆在表达，Loop 时代的杠杆在系统设计。

一、Loop 到底是什么？

Loop 可以理解为一个递归目标系统：

你定义一个目的，AI 持续迭代，直到目标被验证为完成。

它不是简单的 while 循环，也不是让模型“多思考几步”。真正的 Loop 至少包含六个部分：

Goal       目标
Act        执行
Observe    观察反馈
Verify     独立验证
Reflect    修正策略
Memory     记录状态

Loop 由 Goal、Act、Observe、Verify、Reflect、Memory 六个环节构成。 — Loop 不是让模型多说几轮，而是让任务进入可观察、可验证、可记忆的循环。

如果画成工程结构，大概是这样：

目标契约
  ↓
任务调度器
  ↓
执行 Agent
  ↓
工具 / 环境 / 代码库 / 数据库
  ↓
反馈结果
  ↓
验证 Agent
  ↓
状态文件 / 记忆库
  ↓
继续、暂停、升级给人类

这套结构里，最关键的不是“模型多强”，而是“反馈是否真实、验证是否独立、状态是否持久、停止条件是否明确”。

没有这些东西，Loop 只是自动化幻觉。
有了这些东西，Loop 才可能成为 AI 原生工程的最小生产单位。

Loop 的工程结构包含目标契约、任务调度器、执行 Agent、工具环境、验证 Agent 和状态记忆。 — 真正可用的 Loop，要把执行、反馈、验证和状态记忆连成工程结构。

二、为什么说 Prompt 时代正在结束？

这里的“结束”不是说 Prompt 没用了，而是说 Prompt 不再是最高杠杆。

Prompt 解决的是一次交互里的表达问题。
Loop 解决的是持续执行中的系统问题。

Prompt 时代，你的能力体现在：

能不能把需求说清楚；
能不能给足上下文；
能不能让模型少犯错；
能不能通过追问把结果修好。

Loop 时代，你的能力体现在：

能不能定义可验证目标；
能不能把项目知识固化成 Skill；
能不能让多个 Agent 并行且不互相污染；
能不能把执行者和验证者分开；
能不能设计记忆机制，让每次运行都有复利；
能不能控制成本、权限和失败回滚；
能不能在人类判断力不退场的前提下提高自动化程度。

这就是为什么 Loop Engineering 比 Prompt Engineering 更难。

Prompt 更像沟通能力。
Loop 更像系统架构能力。

Prompt 能力和 Loop 能力的对照：前者偏表达，后者偏目标、验证、权限、记忆和架构。 — Prompt Engineering 训练表达，Loop Engineering 训练系统。

三、一个真正可用的 Loop，需要六个组件

Addy Osmani 在 Loop Engineering 中把 Loop 拆成 Automations、Worktrees、Skills、Connectors、Sub-agents 和 Memory。这个拆法很重要，因为它把“让 Agent 自动干活”拆成了可设计、可治理、可迭代的工程组件。

一个可用 Loop 需要 Automations、Worktrees、Skills、Connectors、Sub-agents 和 Memory 六个组件。 — 六个组件分别解决启动、隔离、知识、环境、验证和长期性问题。

1. Automations：让 Loop 自己启动

自动化调度是 Loop 的心跳。

如果一个任务还需要你每天手动打开工具、复制 prompt、检查仓库、查看 CI、总结 issue，那它还不是 Loop，只是“人肉自动化”。

真正的 Loop 应该可以定时或条件触发。例如：

每天早上检查昨天 CI 失败原因；
每天下午扫描新增 issue；
每周生成代码健康报告；
每次 PR 更新后自动审查变更；
部署失败后自动收集日志并生成修复建议。

自动化调度让 Agent 从“被你叫醒”变成“按系统节奏醒来”。这也是 AI Agent 从助手走向生产系统的第一步。

2. Worktrees：让多个 Agent 并行而不互相踩踏

当你同时让多个 Agent 改同一个代码库时，最先爆炸的不是模型能力，而是文件冲突。

一个 Agent 改登录模块。
另一个 Agent 改权限模块。
第三个 Agent 顺手重构了同一个配置文件。

如果没有隔离，它们会像多个工程师同时在同一个工作目录里乱改，最后产生无法合并的混乱。

Worktree 解决的是机械层面的隔离。每个 Agent 拿到独立工作目录、独立分支、独立修改空间。它们可以并行尝试，不会直接污染主工作区。

但这里有一个非常重要的判断：

Worktree 解决的是文件冲突，不解决认知冲突。

你能同时跑多少 Agent，不取决于工具支持多少并发，而取决于你有多少 Review 带宽。

并发不是免费的。
并发会把执行压力转化为审查压力。

多个 Worktree 可以隔离并行 Agent，但最终都会汇聚到 Review 带宽上。 — 并行能力越强，越要提前设计审查带宽。

3. Skills：把项目知识写到系统外部

每次新对话都重新解释项目背景，是极大的浪费。

项目怎么启动？测试怎么跑？哪些目录不能动？哪个 API 有历史坑？PR 标题怎么写？错误日志怎么看？这个团队的代码风格是什么？

如果这些信息只存在于人脑或聊天上下文里，Agent 每次启动都会重新猜。

Skill 的价值，就是把这些项目知识、工作流程、约束条件、工具使用方法写到系统外部，让 Agent 每次运行都能读取。

没有 Skill 的 Loop，每轮都从零开始。
有 Skill 的 Loop，每轮都站在上一次沉淀的经验上。

更准确地说，Skill 不是“提示词包”，而是“操作规程包”。它把隐性的项目经验，变成可加载、可复用、可分发的执行标准。

4. Connectors：让 Loop 接入真实工作环境

一个只能读写本地文件的 Loop，能力很有限。

真实工作发生在很多系统里：

GitHub / GitLab
Linear / Jira
Slack / 飞书
数据库
日志系统
CI/CD
文档系统
staging API
监控告警平台

Connector 的作用，就是把 Loop 接入这些真实环境。

有了 Connector，Agent 不只是说“我建议你开一个 PR”，而是真的可以读取 issue、关联任务、修改代码、开 PR、查看 CI、更新 Linear 状态、在 Slack 里通知结果、把失败原因写回状态文件。

这就是“建议系统”和“执行系统”的分界线。

只会输出建议的 Agent，是顾问。
能在受控环境中行动的 Loop，才是生产力系统。

5. Sub-agents：让执行者和验证者分开

Loop 里最重要的结构设计之一，是把 maker 和 checker 分开。

写代码的 Agent，不应该给自己的代码打分。
提出方案的 Agent，不应该决定方案是否合格。
执行任务的 Agent，不应该独自宣布任务完成。

因为模型很容易说服自己：

“这应该差不多了。”
“这个错误应该不影响。”
“测试没跑完，但逻辑上应该通过。”
“我已经满足目标了。”

所以，成熟 Loop 需要第二个 Agent：

一个 Agent 负责探索；
一个 Agent 负责实现；
一个 Agent 负责验证；
一个 Agent 负责安全审查；
一个 Agent 负责对照规格检查是否真的完成。

这不是为了堆复杂度，而是为了降低自我评价偏差。

尤其是长期无人值守任务，验证子 Agent 是你敢让 Loop 跑下去的基本前提。

但是，Sub-agent 也不是越多越好。每个 Agent 都会消耗 token、上下文和审查成本。真正好的设计，是把第二意见花在高风险、高价值、高不确定性的地方。

6. Memory：让 Loop 具备长期性

Loop 的第六个组件看起来最朴素，却最关键：

一个 Markdown 文件。
一个状态表。
一个 Linear 看板。
一个数据库表。
一个 repo 里的 progress.md。

它记录：

做过什么；
失败过什么；
哪些假设被验证；
哪些路径被放弃；
哪些问题还没解决；
下一轮从哪里继续；
哪些经验应该变成规则。

模型会忘。上下文会被压缩。会话会结束。
但仓库不会忘，状态文件不会忘，数据库不会忘。

所以，长期 Agent 的记忆不能只放在上下文里，必须写到外部系统里。

这也是为什么真正的 Loop 本质上不是聊天系统，而是状态机。

四、/goal 是 Loop 的最小产品化形态

如果说 Automations 是按时间启动 Loop，那么 /goal 是按完成条件驱动 Loop。

普通 prompt 是：

帮我修复 auth 测试

更像 Loop 的 goal 是：

目标：修复 auth 模块下所有失败测试。

完成条件：
1. test/auth 下所有测试通过；
2. lint 无错误；
3. 不修改 public API；
4. 每轮记录修改内容、测试结果和下一步判断；
5. 如果三轮后仍无法解决，输出阻塞原因、已尝试路径和需要人类决策的点。

这背后的关键变化是：

你不是要求 Agent 做一个动作，而是定义一个完成契约。

一个好的 goal 至少包含五件事：

目标是什么；
什么算完成；
如何验证完成；
哪些边界不能破坏；
如果失败，如何记录和升级。

这就是从 Prompt 到 Loop 的核心转变。

Prompt 说的是“你要做什么”。
Goal 说的是“系统如何知道你真的做完了”。

普通 prompt 只描述动作，goal contract 则描述目标、完成条件、验证方式和失败升级路径。 — Goal 是完成契约，不只是更长的 prompt。

五、Claude Fable 5 为什么像 Loop 时代最严厉的父亲？

Fable 5 值得关注，不只是因为它更强，而是因为它把一个事实推到台前：

越强的模型，越不适合只靠单轮 prompt 使用。

Lance Martin 的实验很有代表性。他不是让模型直接回答问题，而是把 Fable 5 放进一个长期工程挑战里：模型需要编辑训练代码、启动训练、读取日志、观察分数、决定下一轮实验方向，并持续迭代。

这类任务的难点不是“会不会写代码”，而是：

能不能从失败中学习；
能不能根据真实反馈调整策略；
能不能避免只做小修小补；
能不能承担结构性改动的风险；
能不能在多轮实验里保留有效记忆；
能不能把一次经验提炼成下一次可用的规则。

这正是 Loop 的能力边界。

Fable 5 在这类任务里表现强，不是因为它被一个神奇 prompt 激活了，而是因为它在有反馈、有评分、有记忆、有验证的环境中更能发挥能力。

所以说它像 Loop 时代最严厉的父亲：

它不是陪你聊天的朋友。
它会逼你写清目标。
逼你定义评分标准。
逼你设置停止条件。
逼你把记忆放到磁盘。
逼你把验证者从执行者里拆出来。
逼你承认：没有工程化环境，再强的模型也会被浪费。

Fable 5 的真正启发不是“换一个更强模型”，而是：

强模型正在倒逼我们升级 Agent 的运行环境。

Fable 5 在长期工程挑战中经历编辑训练代码、启动训练、读取日志、查看分数并决定下一轮实验方向。 — 强模型的能力，要放进反馈、评分、记忆和验证环境里才会真正释放。

六、但 Fable 5 也暴露了 Loop 时代的新问题：信任成本

Fable 5 的争议同样重要。

当模型能力越来越强，安全机制也会越来越强。
当安全机制越来越强，模型行为就可能变得更不透明。

它可能拒绝。
可能切换模型。
可能触发分类器。
可能对某些任务降低帮助程度。
可能让开发者不知道到底是自己 Loop 设计失败，还是模型安全策略介入了。

这对 Loop 是一个大问题。

因为 Loop 依赖稳定性。
Loop 依赖可观测性。
Loop 依赖每一次失败都能被归因。

如果一次任务失败了，你必须知道原因：

是目标写错了？
是 Skill 不完整？
是工具权限不够？
是测试环境坏了？
是 verifier 太宽松？
是模型能力不足？
是安全分类器拒绝？
是底层模型被自动切换了？

如果这些不可观测，Loop 就会从工程系统退化成黑箱祈祷。

所以，Fable 5 的另一个启发是：

未来的 Loop 不能只设计执行层，还必须设计观测层。

一个生产级 Loop 至少要记录：

每轮使用了哪个模型；
是否发生模型切换；
是否触发拒绝；
工具调用是否成功；
verifier 给出的失败原因；
人类最终是否接受结果；
token 成本是多少；
任务是否真的进入生产。

没有这些日志，Loop 越自动，风险越大。

生产级 Loop 需要观测模型版本、模型切换、拒绝触发、工具成功率、验证失败原因、token 成本和生产采纳结果。 — Loop 要成为生产系统，必须能解释自己为什么失败。

七、Loop 做不了的三件事

Loop 会改变工作，但不会把人从工作中删除。相反，Loop 越强，三个问题越尖锐。

1. 验证仍然是你的责任

Loop 可以让 Agent 写代码，可以让另一个 Agent 检查代码，也可以让测试自动跑。

但“完成”只是一个声明，不是证明。

真正要上线的代码，仍然需要人类确认：

需求是否正确；
业务语义是否正确；
设计取舍是否合理；
风险是否可接受；
用户体验是否变差；
有没有隐藏的长期技术债。

AI 可以提高验证效率，但不能替你承担责任。

2. 你的理解会腐烂

Loop 让代码生成速度变快，但也让一个危险问题加速出现：

代码库真实发生的变化，超过了你理解它的速度。

这叫理解债。

你以为自己拥有了更高生产力，实际上只是让系统在你看不懂的方向上更快生长。

所以，Loop 不能只生成代码，还必须生成解释、变更摘要、设计记录和回滚路径。

一个好的 Loop 不只是把事情做完，还应该帮助你保持理解。

3. 不思考会被放大

Loop 最危险的地方，是它会给人一种“我可以不用判断”的幻觉。

当系统每天自动跑、自动改、自动开 PR、自动总结，你很容易开始接受它给出的东西。

这不是自动化，这是认知放弃。

同一个 Loop，在不同人手里会产生完全不同的结果：

一个理解业务的人，用 Loop 放大判断力；
一个逃避理解的人，用 Loop 放大错误；
一个有工程审美的人，用 Loop 提高质量；
一个没有审美的人，用 Loop 制造垃圾。

Loop 不知道这个区别。
人知道。

Loop 做不了的三件事：替人承担验证责任、阻止理解债、避免认知放弃。 — Loop 放大执行力，也会放大判断力的缺席。

八、给 AI 原生团队的 Loop 设计原则

如果要在团队里真正引入 Loop，不建议一开始就做复杂多 Agent 系统。

更好的路径是从一个低风险、高重复、可验证的场景开始。

原则一：先做 Triage Loop，不要先做 Commit Loop

不要一上来就让 Agent 自动改代码、自动合并。

先让它做：

issue 归类；
CI 失败总结；
日志聚合；
PR 风险标注；
代码变更摘要；
每日项目健康报告。

这些任务有价值，但风险相对低，适合训练团队的 Loop 感。

原则二：所有 Loop 都必须有完成条件

不要写：

持续优化代码质量

要写：

扫描最近 24 小时失败的 CI；
按失败原因聚类；
每类给出相关 PR、可能责任文件、复现命令；
只输出需要人类关注的前三项。

Loop 最怕目标虚。

目标越虚，模型越容易自我发挥。
目标越实，系统越容易验证。

原则三：执行者和验证者必须分开

任何高价值 Loop，都应该至少有两个角色：

Worker：负责执行；
Verifier：负责验证。

更复杂一点，可以拆成：

Explorer：找问题；
Implementer：写方案；
Reviewer：审查；
Reporter：写报告；
Human：最终决策。

不要让同一个模型既写答案又宣布答案正确。

原则四：Memory 必须在系统外部

不要把记忆只放在聊天上下文里。

应该写入：

loop_state.md
decision_log.md
experiments.md
known_issues.md
Linear / Jira 状态
数据库表
运行日志

长期任务的关键，不是模型记住了什么，而是系统记录了什么。

原则五：先限制权限，再扩大能力

Loop 能行动，就一定有风险。

建议从只读开始：

只读仓库和日志；
允许生成报告；
允许创建 issue；
允许创建 PR；
允许修改代码；
允许自动合并。

每一级都要有权限、日志、回滚和人类确认。

Loop 的权限阶梯从只读仓库和日志，到生成报告、创建 issue、创建 PR、修改代码，最后才是自动合并。 — 不要一开始就追求全自动，先把权限阶梯设计清楚。

原则六：成本是架构的一部分

Sub-agent、长上下文、持续运行、自动调度都会消耗 token。

Loop 不是免费劳动力，而是一种新型计算资源调度系统。

所以要记录：

每个 Loop 的 token 消耗；
每类任务的成功率；
每次人工接管比例；
每个 PR 的实际采纳率；
每个 Loop 节省的人类时间；
每个 Loop 引入的返工成本。

不能度量成本，就不能规模化 Loop。

九、一个适合团队落地的最小 Loop

可以从这个版本开始：

名称：Daily Engineering Triage Loop

触发：
每天早上 8:30

输入：
1. 最近 24 小时 CI 失败记录
2. 新增 issue
3. 新增 PR
4. 最近 commit
5. 项目 Skill
6. loop_state.md

执行：
1. 汇总异常
2. 按影响范围排序
3. 判断是否已有重复问题
4. 给出前三个最值得处理的问题
5. 为每个问题生成复现命令和初步修复建议
6. 如果问题明确，创建独立 worktree 草拟 patch
7. 由 verifier 子 Agent 审查 patch
8. 不自动合并，只生成 PR 草案或报告

输出：
1. 今日工程风险摘要
2. 推荐处理顺序
3. 已尝试路径
4. 需要人类判断的问题
5. 下一轮要继续跟踪的状态

这个 Loop 不追求“完全自动化”，而是先追求：

稳定；
可解释；
可复盘；
可验证；
可被团队接受。

这比一开始追求“全自动工程师”更现实。

Daily Engineering Triage Loop 从 CI 失败、Issue、PR、Commit 和项目 Skill 中输入，经过 Triage、Patch 草拟、Verifier 审查后输出工程风险摘要。 — 最小 Loop 应该先解决高重复、低风险、可验证的工程分诊任务。

十、最终判断：Loop 是 Agent 的工作单位，也是组织智能的最小回路

Prompt 是人与模型之间的一次交流。
Loop 是组织把目标、流程、工具、经验和判断力沉淀成系统的一种方式。

从这个角度看，Loop 不只是 AI Coding 的新技巧，而是 AI 原生组织的基本结构。

一个公司未来的 AI 能力，不只取决于它买了什么模型，而取决于它有没有能力把重复工作变成 Loop：

销售线索 Loop；
客服总结 Loop；
代码审查 Loop；
产品反馈 Loop；
内容生产 Loop；
投研信号 Loop；
运维诊断 Loop；
组织知识沉淀 Loop。

模型是大脑。
工具是手脚。
Skill 是操作规程。
Connector 是神经系统。
Memory 是组织记忆。
Verifier 是免疫系统。
Human 是最终判断力。

所以，Loop 不是让人退场。
Loop 是让人的判断力有更大的杠杆。

真正的风险不是 Agent 太强，而是人太早放弃判断。
真正的机会不是自动化替代工程师，而是工程师开始设计可以持续进化的智能系统。

过去，我们学习写 Prompt。
现在，我们要学习设计 Loop。
未来，每个高效组织都会拥有自己的 Loop Library。

这会成为 AI 原生公司的新资产。

不是 prompt 库。
不是知识库。
而是一组能够持续运行、持续反馈、持续改进的智能生产回路。

高效组织会把销售、客服、代码、产品、内容、运维和知识沉淀等重复工作沉淀成 Loop Library。 — AI 原生公司的新资产，不是 prompt 库，而是可持续运行的 Loop Library。

全站检索