Loop Engineering详解：从Prompt到循环工程的AI Agent演进之路

从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering，如今又冒出一个新词——Loop Engineering（循环工程）。当业界的术语更新速度快过我们的学习速度时，人们不禁要问：这究竟是又一次营销炒作，还是真正代表了 AI Agent 演进的下一个阶段？

要回答这个问题，最好的方式是沿着技术演进的脉络一路走下来，看看每一层"工程"到底解决了什么问题，以及为什么我们需要它们层层叠加。

从 Prompt 到 Context：Agent 学会自己填充上下文

一切的起点是 Prompt Engineering（提示工程）。假设我给 Agent 一句指令："你是一个乐于助人的客服代表，请对我的客户友好一些。"这就是提示工程——通过 Prompt 隐式地告诉 Agent 该做什么。之后无论用户问什么，Agent 都会基于这个提示扮演客服的角色。简单、直接、有效。

Prompt Engineering 作为与大语言模型交互的基础方法论，其核心原理建立在 Transformer 架构的注意力机制之上。模型通过对输入 token 序列的概率分布进行条件生成，因此输入的措辞、结构和示例选择会显著影响输出质量。业界已经发展出了 few-shot prompting、chain-of-thought、self-consistency 等系统化技术，使得 Prompt Engineering 从一种"试错艺术"逐步演变为可复现的工程实践。

那为什么还需要 Context Engineering（上下文工程）？关键在于，我们写下的那个提示只占据了 Agent 上下文窗口的一小部分，剩下的空间其实还能做更有价值的事。这里需要理解一个关键的技术约束：上下文窗口（Context Window）是大语言模型一次推理能处理的最大 token 数量，由模型架构中的位置编码方案和训练时的序列长度决定。从 GPT-3 的 4K token 到 Claude 3 的 200K token，再到 Gemini 1.5 Pro 的百万级 token，窗口容量不断扩大但始终有限。更关键的是，"有效上下文"远小于理论窗口——研究表明模型在处理长文本时存在"lost in the middle"现象，即对中间位置信息的召回率显著低于头尾位置。

于是问题变成：能不能给 Agent 自主权，让它主动调用工具，根据任务需求自己去填充上下文？

这正是上下文工程的开端。Agent 现在可以读取文件、加载并修改内容，甚至通过 MCP（Model Context Protocol）与数据库和外部应用交互，自主地为自己"装载"所需信息。MCP 是 Anthropic 于 2024 年底推出的开放标准协议，旨在为 AI 模型与外部数据源、工具之间建立统一的通信接口。它采用客户端-服务器架构：AI 应用作为 MCP 客户端发起请求，而数据库、API、文件系统等作为 MCP 服务器暴露标准化能力。MCP 的核心价值在于解决了此前各 Agent 框架各自为政、工具集成碎片化的问题，类似于 USB 协议统一了硬件接口。目前 MCP 已获得 OpenAI、Google、Microsoft 等主要厂商的支持，正在成为 Agent 工具调用的事实标准。

举个例子，当你问 ChatGPT"地球到月球之间能塞下多少个芝士汉堡"时，它只需要基于已有知识推理即可——这是纯粹的提示工程；但当你问"NASA 最新的发现是什么"时，它必须联网搜索、抓取相关信息——这就是上下文工程在起作用。

从 Context 到 Harness：管理长任务的外部框架

上下文工程听起来已经很完善了，为什么还要 Harness Engineering（框架工程）？

问题不在于上下文工程本身有缺陷，而在于它有明确的边界。上下文工程并不擅长处理耗时超过 5 到 10 分钟的长任务。原因很直接：长任务往往需要的上下文远超 Agent 的处理能力。虽然 Agent 可以在逼近上限时不断压缩、总结自己的上下文，但这个过程"漏水"严重——每一次总结都会丢失一些关键细节，累积下来就会导致执行崩溃。

这个过程在学术上被称为"上下文蒸馏"或"滚动摘要"。每一轮压缩本质上是一次有损编码——模型必须判断哪些信息"重要"、哪些可以丢弃，而这个判断本身就可能出错。在多轮压缩后，错误会级联放大，类似于反复对 JPEG 图片进行有损压缩，最终导致信息严重失真。这就是为什么在实际工程中，超过一定复杂度的任务几乎必然需要外部状态管理机制。

因此，我们需要一个位于上下文工程之外的系统，从外部来管理 Agent 内部的上下文——这个外部系统就是框架工程。它从外向内管理上下文，帮助 Agent 的运行时把用户需求拆解成更稳定的执行步骤。

框架工程的核心思想源自经典软件工程中的"分而治之"原则，但在 Agent 领域有了新的含义。传统的任务编排（如 DAG 有向无环图）是静态的，而 Agent 框架工程允许动态重规划——Agent 可以在执行过程中根据中间结果调整后续步骤。典型的实现包括 LangGraph 的状态图、CrewAI 的多 Agent 协作流程，以及 Anthropic Claude 内置的 extended thinking + tool use 循环。这些框架的共同点是在 Agent 的上下文之外维护一个持久化的执行状态，使得即使单次推理的上下文被清空，整体任务进度也不会丢失。

还是用例子来理解。当我让 Claude Code"克隆整个 NASA 网站"时，这就是框架工程的用武之地。NASA 网站极其复杂，仅靠上下文工程去做这类任务不仅耗时，而且很可能中途"卡住"。框架工程提供了一套外部机制，管理上下文和运行时，让 Agent 能够有条不紊地走完一长串任务清单。

Loop Engineering 登场：循环之上的循环

如果你留意，会发现这里浮现出一个清晰的模式——循环（Loop）。

在上下文工程中，存在一个循环：Agent 递归地一个接一个调用工具，直到它认为已经收集到足够的信息来回答问题。在框架工程中，同样存在一个循环：Agent 在上下文窗口之外维护一份任务清单，不断迭代任务，直到整个操作完成。

换句话说，我们本质上是在把一个循环叠在另一个循环之上。而 Loop Engineering（循环工程） 就是在框架工程之外再套一层循环，从外部引导框架运行。

为什么还要再加一层脚手架？循环工程瞄准的核心是——人类交互本身。到目前为止我们看到的所有例子，无论是"多少个芝士汉堡"、"NASA 最新消息"还是"克隆 NASA 网站"，都需要人类主动去 prompt Agent。而循环工程的目标，是构建一套外部脚手架，让 Agent 能够自己给自己下达提示，判断它认为需要做什么。这才是循环工程的灵魂所在。

值得注意的是，循环工程中的"定时触发"看起来与传统 cron job 类似，但本质区别在于决策的自主性。传统自动化是确定性的——预先编写好脚本，按固定逻辑执行固定操作。而循环工程中的 Agent 每次被触发后，会根据当前环境状态自主判断需要做什么、怎么做、甚至是否需要做。这意味着同样的定时触发，Agent 在不同时刻可能采取完全不同的行动。这种"感知-推理-行动"的闭环循环，更接近于控制论中的反馈控制系统，而非传统的开环自动化。

从系统架构的视角来看，Loop Engineering 的引入使得 AI Agent 系统呈现出明显的分层递归结构，这与计算机科学中操作系统的分层设计有异曲同工之妙。最内层是单次 LLM 推理（Prompt Engineering），中间层是工具调用循环（Context Engineering），再外层是任务编排循环（Harness Engineering），最外层则是自主触发的元循环（Loop Engineering）。每一层都为上一层提供抽象和封装，同时依赖下一层的能力。这种"洋葱模型"也意味着，系统的复杂度和调试难度随层数增加而指数级上升。当 Agent 在最外层循环中做出错误判断时，这个错误会向内层层传播，可能导致大量无效计算。因此，Loop Engineering 的工程实践中，可观测性（Observability）和断路器（Circuit Breaker）机制变得至关重要——需要在每一层设置监控指标和熔断条件，防止系统进入失控的正反馈循环。

实际案例：自我维护的世界杯网站

理论听起来有些抽象，我们用一个场景来落地。

假设我用 Codex 构建了一个追踪世界杯比分的网站。Codex 会综合运用提示、上下文和框架工程，为我写出一个精美的网站。但问题来了：世界杯每天都有比赛，为了维护这个网站，我必须不断地提示 Agent 去更新比分、修复用户反馈的 bug。

如果我改用定时任务呢？让 Agent 每小时自动检查一次是否有新数据需要更新，同样让它自主检查用户报告的 bug 并修复。这时你就看到了——一个位于框架工程之外的、自我引导而非人类引导的循环正在形成。

配合已经安装在 Codex 环境中的 skills 和 plugins，Agent 可以访问现有知识库持续改进；它还能调用子 Agent（sub-agents）来验证自己的工作，并通过 work tree（工作树）机制同时处理多个修复任务，避免运行时相互污染。Work Tree 概念借鉴自 Git 的 worktree 功能，允许 Agent 在隔离的环境中并行处理多个任务分支。在 Codex 等编码 Agent 的实现中，每个子任务会被分配独立的文件系统快照和运行时沙箱，确保一个任务的修改不会污染另一个任务的执行环境。任务完成后，结果会像 Git merge 一样被合并回主分支。这种机制不仅提高了并行效率，更重要的是提供了天然的故障隔离——如果某个子任务失败，可以直接丢弃该分支而不影响全局状态。

这些正是 Addy Osmani 在其博客中提出的循环工程六大组件：自动化（Automation）、工作树（Work Tree）、技能（Skills）、插件与连接器（Plugins & Connectors）、子 Agent（Sub-agents）和状态（State）。

Addy Osmani 提出的六大组件中，"状态（State）"是最容易被忽视但最为关键的部分。在循环工程中，Agent 需要跨多次触发维护持久化状态，包括已完成的任务记录、上次检查的时间戳、已知问题列表等。这本质上是将 Agent 从无状态的请求-响应模式转变为有状态的长期运行服务。实现上通常依赖外部数据库或文件系统来存储这些元信息，Agent 在每次被触发时先读取历史状态，再决定当前行动，最后更新状态。这种设计模式与微服务架构中的 Saga 模式有相似之处——通过外部状态协调跨多个执行周期的长流程，同时保证每个单独执行周期的原子性和可恢复性。

Loop Engineering 是真突破还是流行词？

如果这一切让你觉得有点"玄乎"，你并不孤单。

业界有相当一部分声音认为，循环工程不过是又一个 buzzword，本质是鼓励大家烧更多的 token、生产更多的"AI 垃圾（AI slop）"。这一担忧并非空穴来风。AI Slop 是 2024 年兴起的术语，指由 AI 大量生成的低质量、重复性内容。在循环工程的语境下，如果 Agent 不断自我触发、自我提示，每一次循环都会消耗大量 API 调用和 token，而产出的边际价值可能递减。以 GPT-4 级别模型为例，一次完整的 Agent 循环可能消耗数万 token，折合成本数美元。如果循环频率设定不当或终止条件设计不佳，系统可能陷入"空转"——持续产生 token 消耗却没有实质性产出。这不仅是经济成本问题，也是碳排放和计算资源的浪费。

截至目前，我们确实还没有看到循环工程在实际中带来颠覆性差异的案例，它的真正潜力在很大程度上仍停留在理论层面。

但换个角度看，它也可能代表着工程哲学的下一次进化——随着 Agent 能力边界不断扩张，它能帮我们处理的事情越来越复杂。需要强调的是，循环工程并不意味着底层的提示、上下文、框架工程变得不重要或不再需要，恰恰相反，它是建立在这些基础之上的。循环叠加循环，只是为了帮我们完成更复杂的工作。

总结：AI Agent 自主性的演进方向

从 Prompt 到 Context 再到 Harness，最后到 Loop，我们看到的其实是同一条主线：让 Agent 承担越来越多的自主性，逐步把"人类必须亲自 prompt"这件事往外推。 循环工程是否会成为主流范式还有待观察，但理解这条演进脉络，能帮助我们看清 AI Agent 究竟在向哪个方向生长。至少现在，当你下次听到"某某 engineering"这个新词时，可以先问一句：它到底新增了哪一层循环？

值得关注的是，Agent 自主性的提升也带来了新的治理挑战。当 Agent 从"被动响应"转向"主动行动"，安全边界的设定变得更加微妙。业界目前正在探索多种控制策略，包括人在回路（Human-in-the-Loop）审批机制、预算上限（Budget Cap，限制单次循环的最大 token 消耗）、权限沙箱（限制 Agent 可访问的工具和资源范围），以及基于意图验证的"宪法式"约束（类似 Anthropic 的 Constitutional AI 方法）。随着这些工程层次的叠加，AI 安全不再仅仅是模型对齐问题，更成为系统工程层面的设计问题。