Prompt Engineering到Loop Engineering：AI编码新边界

来源：互联网 2026-07-10 06:32:18

从提示工程到循环工程，这是AI编码的范式转变：不再直接操控模型，而是设计让模型自主运行的环路系统。其原子结构包括自动化、工作树、技能、插件连接器、子模型和外部记忆。环路分四层：模型环路、验证环路、事件驱动环路和爬山环路，实现持续自优化与质量保障。

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 给出了一个非常简洁的层级关系：

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

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

阶段四：Loop Engineering（2025 至今）

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

Peter Steinberger 的说法被引用了很多次，这里再提一次也不过分：

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

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

2. Loop Engineering 到底是什么

简洁版本如下：

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

传统工作方式——你写一段话，模型去干活，你来看结果，再写一段话，模型继续干，如此循环往复。你就是那个循环中的人力齿轮。

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 Bckeler 的定义是 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