从 Prompt Engineering 到 Loop Engineering：AI 编码的下一个边界

四个演进阶段
[Loop Engineering 到底是什么](#Loop Engineering 到底是什么 "#2-loop-engineering-%E5%88%B0%E5%BA%95%E6%98%AF%E4%BB%80%E4%B9%88")
[五构件 + 一记忆：环路的原子结构](#五构件 + 一记忆：环路的原子结构 "#3-%E4%BA%94%E6%9E%84%E4%BB%B6--%E4%B8%80%E8%AE%B0%E5%BF%86%E7%8E%AF%E8%B7%AF%E7%9A%84%E5%8E%9F%E5%AD%90%E7%BB%93%E6%9E%84")
四层环路堆叠
它跟其他概念什么关系
实战建议
五个你一定会踩的坑
工具现状
接下来会怎样

1. 四个演进阶段

Loop Engineering 不是被哪家公司发布会"发布"的。它是 AI 辅助编程在两年内走了四步之后，自然走到的地方。

阶段一：Prompt Engineering（2022--2023）

最初大家都卡在同一个问题上：怎么写提示词能让模型输出正确的东西？怎么措辞？是不是加上"我的工作取决于你，不要犯错"会更好？这些讨论在当时是合理的------模型还没聪明到能理解含糊的指令。

但模型迭代太快了。到了 2023 年底，从模糊意图中推断清晰目标已经不是主要瓶颈。单独磨提示词的边际收益在急剧下降。更根本的问题是，提示工程本质上是开环的：你输入一些文本，拿到输出，然后祈祷它是对的。如果有人一直守在旁边检查每个结果，那叫劳动力，不叫工程。

阶段二：Context Engineering（2023--2024）

下一步自然就是把更多上下文塞进对话。写好 AGENTS.md / CLAUDE.md，把项目文档喂进去，精选哪些文件进入窗口。当模型知道你的代码规范、构建流程和历史决策后，它的输出质量确实上了一个台阶。

问题在于，上下文工程仍然是开环的。你给了它一堆信息，它给你一个输出，中间没有任何验证步骤。你还是在祈祷。

阶段三：Feedback Loop Engineering（2024--2025）

这一步才是真正的转折点。不再是"祈祷它对"，而是让代理能在真实环境里验证自己的输出。跑测试、查编译错误、截图比对、调 staging API------每个输出都带着证据回来，而不是"我觉得这样应该可以"。

Daniel Demmel 给了一个很简洁的层级：

vbnet 复制代码

Prompt Engineering < Context Engineering < Feedback Loop Engineering < Harness Engineering

大多数人停在第一级；少数人走到第二级；真正把事情做稳的人，都在第三级以上。

阶段四：Loop Engineering（2025 至今）

前三步回答的是"我怎么让这次输出更好"。第四步问的是另一个问题："我怎么设计一个系统，让它替我不断地做前三步？"

Peter Steinberger 的说法被引用了很多次，这里再引用一次也无妨：

"你不应该再手动 prompt 编码代理了。你应该设计 loops，让 loops 来 prompt 你的代理。"

Boris Cherny（Anthropic 那边 Claude Code 的负责人）也说过类似的话：

"我不再手动 prompt Claude 了。我有 loops 在运行，它们 prompt Claude 并决定下一步做什么。我的工作变成了写 loops。"

这个转变从"人 prompt 机器"到"人设计系统，系统 prompt 机器"------不是功能升级，是范式切换。提示工程、上下文工程、反馈环路工程是 Loop Engineering 的构成要素，但 Loop Engineering 本身是一套把它们组合成自主运行体系的方法论。

2. Loop Engineering 到底是什么

简洁版本：

Loop Engineering 是一种工程实践，关注如何设计、构建和优化自主反馈环路，使得 AI 代理能在最少人工介入的情况下持续执行复杂任务、自我验证、并从执行结果中迭代改进。

如果这个定义听着太正式，换一种说法：

传统工作方式是------你写一段话，代理干活，你看结果，你再写一段话，代理接着干，以此类推。你是那个循环中的人力齿轮。

Loop Engineering 做的事情是：你把自己从这个齿轮位置替换下来。你设计一套系统，这套系统自己知道什么时候该干什么、怎么检查干得怎么样、怎么记录进度、怎么决定下一步。你的角色从"操纵者"变成了"设计者"。

核心转变用一张表看比较清楚：

传统	Loop Engineering
你写 prompt	你写生成 prompt 的系统
你逐轮检查输出	自动化验证管道 + 异常上报
一次性对话	持久化、可恢复的多轮流程
一个模型从头干到尾	多个子代理分工（设计/实现/验证）
状态在模型上下文里	状态在文件系统或外部存储里

3. 五构件 + 一记忆：环路的原子结构

Addy Osmani 在 2026 年 6 月的文章里给了一个很实用的框架。他说一个完整的 loop 需要五个构件，外加一个记忆系统。这六个东西缺一个，你的 loop 就不可持续。

3.1 自动化 / Automations------环路的心跳

Automations 是区分"一个你手动运行的脚本"和"一个真正的自循环系统"的关键。

什么是 automations：按计划自动做任务发现和分类。

具体来说：定时触发（每天、每小时、自定义）、自动做 triage、结果汇总到一个收件箱、无发现时自动静默归档。

我在几个团队里看到的真实用法：

每天早上自动扫一遍 open issues，按 urgency 分类
CI 失败后自动分析日志、生成根因分析
每周自动写一份 commit 摘要发到团队频道
低优先级 bug 自动分配，不需要人介入

关键在于，automation 可以调用 skill。你不需要在 cron 配置里贴一篇没人会更新的小作文。

3.2 工作树 / Worktrees------并行不打架

一旦你开始跑两个以上代理，文件冲突会迅速成为最主要的失败模式。两个代理同时写同一个文件，跟两个人在同一段代码上改、没沟通一样。

Git worktree 解决了这个问题：每个代理拿到一个独立的 work directory，共享同一份 repo 历史，但各自工作在单独的分支上。一个代理的改动不会污染另一个的沙箱。

Codex 和 Claude Code 对此都有内建支持------一个线程一个 worktree，子代理用完即焚。实现细节不同，但解决的问题一样。

3.3 技能 / Skills------把项目知识固化下来

Skills 解决的是每次新会话、模型都从零猜你的项目惯例的问题。格式很简单：一个文件夹 + SKILL.md + 可选脚本和参考资料。模型在启动时读到这份文件，就知道你的约定、构建命令、代码风格、避坑指南------不需要你每次重新说一遍。

值得注意的一点：skill 是创作格式 ，plugin 是分发格式。你把几个 skill 捆在一起，加上 MCP 连接器配置，打成 plugin，团队伙伴一键安装就能用。这个区分在实操中很重要。

3.4 插件和连接器 / Plugins & Connectors------连接到真实系统

一个只能操作文件系统的 loop 是信息孤岛。Connectors------基于 MCP 协议------让代理能读 issue tracker、查数据库、打 staging API、往 Slack 发消息。Plugins 是这些 connector 和 skill 的打包层。

一个能"在工单里贴修复方案"的代理跟一个能"自动创建 PR、关联 Linear 工单、等 CI 变绿后在频道发通知"的 loop 之间的差距，就是 connectors 带来的。

3.5 子代理 / Sub-agents------写代码的人不要负责检查代码

这是 loop 设计中最核心的结构决策。

写代码的那个模型对自己的输出太宽容。让它同时负责验证自己的输出，相当于让同一个人写代码又做 code review------不是不可以，但你不会相信那个结果。

理想的模式是：

Designer Agent：分析需求、定方案
Implementer Agent：按方案实现
Verifier Agent：跑测试、查编译、做静态分析
失败的话，feedback 回到 implementer 迭代

每层的 system prompt 和 tool access 可以不同。验证代理可以指定一个更谨慎的模型，也可以拥有更多诊断工具的权限。

3.6 记忆 / State------模型会忘，仓库不会

这个机制简单到你看一眼会觉得不值一提，但没有它，任何长期运行的 loop 都会缓慢地、不可逆地退化。

问题很简单：模型在每次调用之间不保留任何状态。上下文窗口打开、关闭，下一次打开时它什么都不记得。你不可能在对话里维护一个跨会话的 TODO list。

解决方案也很简单：把状态存放在对话之外。Markdown 文件、Linear board、SQLite------任何可以写入和读出的持久化介质都可以。标准做法是维护一个 progress.md 或类似的文件，记录"已经完成什么"、"下一个是什么"、"当前有哪些未解决的问题"。

每次新的代理启动时，先读这个文件。每次迭代后，更新它。模型会忘，但文件不会。

4. 四层环路堆叠

LangChain 那篇《The Art of Loop Engineering》把环路组织成了四个层次，每一层解决一类不同的问题。这个框架的可贵之处在于它不只是一个理论模型------它直接对应你能在 LangChain 和 Claude Code 里调用的原语。

第一层：Agent Loop（代理环路）

核心逻辑极其朴素：给 LLM 上下文，让它在一个循环里调用工具，直到任务做完。这是 LangChain 的 create_agent 做的事，也是 /goal 背后的机制。

拿一个文档维护代理举例：收到改进请求，plan 一下，读 repo，写文档，开 PR。这就是 Level 1。

第二层：Verification Loop（验证环路）

第一层能干活，但不保证活干对了。验证环路在外面套一层：执行完代理，跑一个 grader（可以是 deterministic 的测试管道，也可以是 LLM-as-judge），不通过就带着 feedback 重试。

拿上面那个文档代理来说，grader 会检查：所有链接能 resolve？CI 全绿？diff 范围正确？不需要人工介入就能捕获这几类错误。

代价：latency 和 cost 都会涨。验证粒度跟你的场景走------debug 环境可以松一点，production 必须紧。

第三层：Event-Driven Loop（事件驱动环路）

代理不是你坐在终端前 python run.py 调用的东西。在 Level 3，代理是持续运行在更大系统中的组件。事件------新工单、定时器、webhook------触发它，它干完活，更新真实系统，然后继续等下一个事件。

文档代理的实际运行方式就是：监听 #docs-plz Slack 频道，有人发消息就触发一次。不需要人手动启动它。

第四层：Hill Climbing Loop（爬山环路）

前三层都在回答"怎么把活干完"，第四层回答"怎么让每一轮干得比上一轮更好"。

每次代理运行都会产生 trace：它做了什么、调了哪些工具、grader 反馈了什么。爬坡环路跑一个分析 agent 来处理这些 trace，根据发现重写 harness 配置------prompt 调优、工具调整、grader 优化。外层每循环一次，内部 loop 的效果就往上爬一级。

关键设计点：feedback 的回路不只是回到当前任务，而是向内修改驱动配置本身。对于跑开源模型的团队，这个层甚至可以 feed 到 RL fine-tuning 里。

Level	做了什么	解决的问题	对应原语
1	模型调工具直到任务完成	自动化	`create_agent`, `/goal`
2	输出被评分，不过关带着反馈重试	质量校验	Grader, Rubric
3	事件触发代理执行并写回系统	规模化	Cron, Webhook
4	Trace 驱动配置自动优化	持续改进	Engine, Trace Analysis

5. 它跟其他概念什么关系

Loop Engineering vs Prompt Engineering：前者不替代后者。Prompt engineering 仍然在 loop 的每一轮内部发生，只是写 prompt 的变成了系统而不是人。

Loop Engineering vs Context Engineering：Context 是 loop 的输入；loop 是 context 的来源------你的自动化做好了，context 会自动积累和优化。

Loop Engineering vs Harness Engineering：Birgitta Böckeler 的定义是 Agent = Model + Harness，harness 包括 feedforward（prompt、type system、lint rules）和 sensor（验证、日志、trace）。在 Daniel Demmel 的层级里，harness engineering 是 Frame，loop engineering 是 Frame 内部最关键的 Sensor。后者是前者的子集，也是当前 ROI 最高的部分。

Loop Engineering vs Agentic AI：Agentic AI 描述的是能力------模型能推理、能规划、能用工具。Loop Engineering 是驾驭这种能力的工程实践。前者回答"它能做什么"，后者回答"我们怎么确保它做对"。

6. 实战建议

从里往外建。 先把 Level 1 跑通，再加 Level 2 验证，再接 Level 3 事件驱动，最后才考虑 Level 4 自优化。试图一步到位建四层的结果大概率是调试时间比干活时间还长。

分离 maker 和 checker。 写代码的代理和检查代码的代理应该是两个不同的 entity。可以指定不同的 system prompt、工具权限、甚至不同的模型。验证者不需要创造力的风格，要的是严苛。

Skill 要写得紧。 好的 skill 是一份可以被自动 dispatch 的、没有歧义的操作手册。措辞不需要漂亮，但边界要清晰。当代理能根据你的 task description 自动匹配并调用 skill 时，说明你写对了。

Connector 不是可选项。 一个只能操作文件系统的 loop 跟一个能读 Jira、查 PagerDuty、写 Slack channel 的 loop 之间隔着一条分界线。后者才能在真实环境中闭环。

状态放外面。 只要你的 loop 还在把状态塞在对话上下文里，它就无法恢复、无法审计、无法扩展。一个简单的 progress.md 或一个 Linear board，比任何精心设计的 system prompt 都重要。

在每一层留人工接口。 验证环路可以自动跑自动化测试，但关键决策------比如"这个框架选型是否合适"------需要人工判断。好的 loop 不是把人类踢出去，是把人类从重复劳动里解放出来，放到只有人类能增值的位置上。

Token 成本要盯着。 Loop 可以极其迅速地消耗 token。尤其是 Level 2（验证）和 Level 4（trace 分析）。设定 per-run 预算；在不需要完全准确的地方用便宜模型做 grader；引入缓存避免重复分析。

7. 五个你一定会踩的坑

Loop Explosion。 一个简单的操作被多层 loop 包裹：外面是验证环，里面是重试，再里面还有个 sub-agent。你写了一个 hello world，触发了两百次 API 调用。每个 loop 都必须有明确的终止条件------最大迭代次数、超时、/goal 的 verifiable condition。没有终止条件就不是 loop，是内存泄漏。

Token Debt。 一个每小时触发一次的 automation + verification loop + trace analysis，如果没有任何预算控制，你的账单会在三天内翻五倍。设定 token budget，在不需要精确的地方用便宜模型，实施结果缓存。

Echo Chamber。 验证环在验证自己的输出，优化环在优化自己的驱动。如果外部没有裁判，整个系统会在一个错误方向上自信地越跑越偏。引入外部校验点------定期人工抽样、独立的评估数据集。

Over-engineering。 不是每件事都需要四层 loop。替换一行配置的简单任务如果也跑完整 verification + trace analysis，你需要的不是 loop engineering，是学会判断什么时候不用 loop。根据任务的 criticality 选择合适的 loop depth。

Parallelism Tax。 同时跑五个 agent 的时候，你的 review bandwidth 变成瓶颈，不是 tools。Worktree 解决了文件冲突，但你仍然是天花板。从两个 agent 开始，逐步加，同时建立明确的 review priority 分级。

8. 工具现状

截至 2026 年中，主流的 AI 编码工具在 loop engineering 的核心构件上已经基本对齐。Codex 和 Claude Code 的命名不同，但能力集高度同构。

构件	Codex	Claude Code
Automations	Automations 标签页；`/goal`	`cron`、`/loop`、`/goal`、hooks
Worktrees	线程内建 worktree	`git worktree`、`--worktree` flag
Skills	`SKILL.md`，可自动 dispatch	`SKILL.md`
Connectors	MCP + Plugin 分发	MCP Server + Plugin
Sub-agents	`.codex/agents/` TOML 配置	`.claude/agents/`，Agent Teams
State	Markdown / Linear via connector	AGENTS.md / Linear via MCP

一旦你接受这个能力集是趋同的，你不会再花时间争论"用哪个工具"，而是开始设计一个不管工具怎么换都能跑的 loop。

9. 接下来会怎样

Loop Engineering 正在从"少数人觉得好用"的状态，过渡到 AI 辅助软件开发的基本架构层。就像面向对象设计不是某种语言的功能、而是思考方式一样------loop 思维会成为看待 AI 集成的方式。

在模型层面，对于跑开源模型的团队，Level 4（Hill Climbing Loop）可以自然延伸到 RL fine-tuning：production trace 作为训练信号，直接微调模型本身。Prompt 和 tool 配置是最简单的优化目标，但它们不会是终点。

在系统层面，"loop of loops"已经在被认真讨论------多个独立设计的 loop 系统之间互相发现、协商、协作。这听起来有点遥远，但架构上并不是不可实现。

在组织层面，Satya（LangChain）的说法值得再引一次：

"那些早期建立 learning loops 的公司------让人的判断力和 token 的算力叠加在一起------会建立起竞争对手难以复制的时间优势。"

这不是关于哪家公司的工具更好用。这是关于谁的团队先建立了一套能自我迭代的工程系统。