Loop Engineering：从提示工程到循环工程的范式跃迁

摘要

随着AI编码智能体（Coding Agent）的快速发展，开发者与智能体之间的交互模式正在经历根本性转变。Loop Engineering（循环工程）作为2026年6月兴起的新兴工程范式，主张开发者不再逐轮手动提示智能体，而是设计一个能够自主发现工作、分派任务、验证结果并持续迭代的自动化系统。本文基于Addy Osmani、Cobus Greyling及LangChain等多方论述，系统阐述Loop Engineering的核心概念、构成要素与设计哲学。

一、背景与起源

过去两年间，开发者与AI编码智能体的交互遵循一种线性模式：编写提示（prompt）、提供上下文、阅读输出、再编写下一轮提示。开发者始终充当"持有工具的人"，以逐轮对话方式驱动智能体完成任务。

2026年6月，PSPDFKit创始人Peter Steinberger在社交平台发表观点：“开发者不应该再手动提示编码智能体，而应该设计能够提示智能体的循环系统。” Anthropic公司Claude Code负责人Boris Cherny亦表达了相似立场：“我不再手动提示Claude，我有循环在运行，它们负责提示Claude并决定下一步做什么。我的工作是编写循环。”

这些论断标志着一个重要转折——工程杠杆点已从"精心设计单次提示"转移至"设计编排智能体的控制系统"。

Google工程总监Addy Osmani随后在其博客中系统化阐述了这一概念，将Loop Engineering定义为：用开发者自身替代手动提示智能体的角色，转而设计一个能够自主完成提示工作的系统。此处的"循环"可理解为一个递归目标——开发者定义目的，AI持续迭代直至目标完成。

二、Loop Engineering的定位：Harness之上的一层

在理解Loop Engineering之前，有必要厘清其与相关概念的层级关系。

Agent Harness Engineering（智能体装具工程）关注的是单个智能体运行所处的环境——包括工具配置、上下文注入、安全防护等。而Loop Engineering位于Harness之上，它不仅包含装具层面的设计，还增加了定时调度、并行派生、自我反馈等能力。用Osmani的表述：Harness是智能体的运行外壳，Loop则是让这个外壳按照节拍自动运转、生成子助手并自我补给的控制系统。

三、五大构建模块 + 记忆层

根据Osmani的框架以及Cobus Greyling在GitHub参考仓库中的系统化整理，一个完整的Loop由五个核心构建模块加一个记忆层组成：

1. 自动化调度（Automations / Scheduling）

自动化是Loop真正成为"循环"而非"单次执行"的关键要素。它使系统能够按照预设节拍（定时或事件驱动）自主执行发现和分类工作。例如，每日自动读取CI失败记录、归类开放issue、生成提交摘要等。

在Codex中，开发者通过Automations面板配置项目、提示、频率和执行环境。在Claude Code中，等效机制通过/loop（按频率重复执行）、/goal（持续运行直至条件满足）、hooks以及GitHub Actions实现。

/goal原语尤为值得关注：它在每轮执行后使用一个独立的小型模型检验完成条件，确保"编写代码的智能体"与"评判代码的智能体"相互分离。

2. 工作树隔离（Worktrees）

当多个智能体并行运行时，文件冲突是首要故障模式。Git worktree提供了解决方案——为每个智能体分配独立的工作目录和分支，共享同一仓库历史，从而实现物理层面的执行隔离。

3. 技能（Skills）

技能是将项目知识持久化的机制。其格式为包含SKILL.md文件的目录，记录项目规范、构建步骤、约束条件等。技能解决了Osmani所称的"意图债务"（Intent Debt）问题——如果不将项目意图外化存储，智能体每次运行都将从零开始推导项目逻辑，并以"自信的猜测"填补认知空白。

4. 插件与连接器（Plugins & Connectors）

基于MCP（Model Context Protocol）构建的连接器使循环能够触达文件系统之外的真实工具链——issue跟踪器、数据库、staging API、Slack等。连接器将循环从"告知开发者应该做什么"提升为"在真实环境中自主执行操作"。

5. 子智能体（Sub-agents）

子智能体实现了循环中最关键的结构性拆分：编写者与检查者分离。Osmani指出，编写代码的模型在评判自己产出时存在系统性偏差。通过配置独立的验证子智能体（可使用不同模型、不同指令、不同推理强度），循环获得了在无人值守时仍可信赖的质量保障机制。

6. 记忆/状态（Memory / State）

记忆是循环的"脊柱"，存在于单次对话之外。其形式可以是Markdown文件（如STATE.md、AGENTS.md）或通过连接器接入的Linear看板。由于模型在运行间会遗忘一切，持久化状态必须写入磁盘而非依赖上下文窗口。Osmani精辟总结：“智能体会遗忘，仓库不会。”

四、一个典型循环的运作形态

Osmani给出了一个具象的循环描述：

1. 自动化任务每日早间在仓库上运行
2. 其提示调用分类技能，读取CI失败、开放issue和近期提交，将发现写入状态文件
3. 对于每个值得处理的发现，系统在隔离的worktree中派生子智能体起草修复
4. 第二个子智能体根据项目技能和已有测试审查该草案
5. 连接器负责打开PR、更新ticket
6. 循环无法处理的内容落入开发者的分类收件箱
7. 状态文件记录已尝试、已通过、仍待处理的事项，次日循环据此继续

开发者仅在初始阶段设计此循环一次，后续无需逐步提示任何步骤。

五、设计哲学与警示

Loop Engineering的倡导者们一致强调，循环放大判断力——无论是好的还是差的。

三个随循环成熟而加剧（而非缓解）的问题：

1. 验证仍然是人的责任：无人值守的循环也意味着无人值守的错误。即便存在验证子智能体，"完成"也只是声明而非证明。

2. 理解力债务（Comprehension Debt）加速增长：循环越快地交付开发者未亲手编写的代码，代码库实际状态与开发者认知之间的鸿沟就越大。

3. 认知投降（Cognitive Surrender）的诱惑：当循环自主运转时，开发者极易停止形成独立判断，接受循环返回的一切。设计循环如果出于逃避思考的目的，则与出于深刻判断力的目的，虽然动作相同，结果截然相反。

Osmani的结论发人深省：“构建循环。但要像一个意图继续做工程师的人那样构建它，而非仅仅做一个按下启动键的人。”

六、小结

Loop Engineering代表了AI辅助软件开发的新阶段演进。它并非否定提示工程的价值，而是将其提升至系统设计层面——开发者的核心能力从"如何编写一个好提示"转变为"如何设计一个好的智能体编排系统"。这一范式对开发者提出了更高的工程素养要求：不仅要理解智能体的能力边界，还要具备分布式系统思维、状态管理能力以及对质量验证的清醒认知。

参考来源：

• Addy Osmani - Loop Engineering
• Cobus Greyling - loop-engineering (GitHub)
• LangChain - The Art of Loop Engineering

（本文内容基于上述来源进行归纳和重新组织，遵循合规使用原则。）