Loop Engineering 深度解析与落地【完整版】
Loop Engineering 深度解析与落地
一、行业趋势：为什么该停止写 Prompt
我们不可能永远手把手地给大模型发指令。如果每一次使用 AI 都需要人工盯着，出错一次就得手动修正一次，那么整体效率的瓶颈就完全卡在人的精力和时间上。这种工作模式就像带着一名刚入行的实习生：你坐在他身后盯着屏幕，告诉他先写需求文档，写完发现格式不对再退回修改，修改完再指挥下一步——全程依赖人肉发指令、做反馈。不仅人累，系统的效率上限也由此锁定。
行业内越来越多的前沿实践者已经意识到这一困境。OpenAI 的 Peter曾明确指出，我们不应该再亲自给代码智能体手写提示词，而应该去设计一个循环，让这个循环系统自动与智能体交互、自动生成提示词。Claude Code 的负责人 Boris也表达了一致的观点：他现在根本不直接给 Claude 写提示词，日常工作就是编写和运行各种各样的循环系统，由系统自动向模型发送指令并决定下一步动作。
这背后的信息非常清晰：大模型应用要真正落地并产生生产力，绝不能靠人在对话框里天天敲提示词，而必须依靠一套能自动运转的系统。
二、工程层次全景
从提示词到自动化闭环，工程关注点逐层演进，四个层次的关系如下：
| 层次 | 核心关注 | 解决的问题 |
|---|---|---|
| Prompt Engineering | 提示词设计（角色、输出格式等） | 让 AI 理解你的问题 |
| Context Engineering | 上下文、记忆、状态管理 | 让 AI 知道"有什么"（对话历史、代码、工程信息等） |
| Harness Engineering | 架构思想：沙箱、隔离、工具调用 | 让 AI安全运行，是完成复杂任务的"底座" |
| Loop Engineering | 自动化闭环：发现→执行→验证→循环 | 让 AI持续完成目标，是完成任务的"路口" |
核心关系：Harness Engineering 是底座/方法论，Loop Engineering 是基于该底座的落地手段。现有成熟框架（如 Deep Agent）已满足 Harness 的架构要求，可基于其构建 Loop Engineering。
三、什么是 Loop 工程
1. Loop 的本质定义
循环工程（Loop Engineering）可以被理解为一个"自动驾驶"系统。就像扫地机器人：你只需将它放在地上，它便能自主发现灰尘、规划路线、避开障碍、完成清扫并自我检验，最后自动回充等待下一次工作。整个过程中，它是一个完全闭环、自己跑起来的系统。
在 AI 领域，真正的 Loop 工程就是让 AI 像扫地机器人一样：
- 自己发现任务并拆解为子任务，
- 分派给不同的智能体（Agent）去执行，
- 执行完毕后自行验证结果，
- 如果不对就自行调整并继续，直到问题被彻底解决。
2. Loop 工程的"三要素"
设计一个完整的循环，需要抓住三个关键点：
- 从哪里开始——给系统一个初始任务或目标，例如"修完这个开源项目中的某个 Bug"。
- 重复做什么——系统根据当前状态持续执行、获取反馈并调整，这是一个自适应过程，而非死板的固定步骤。具体下一步怎么走，由调度系统灵活决定。
- 什么时候停——必须设定明确的终止条件，否则系统可能掉入无限循环，在几分钟内消耗大量 Token 和预算。
3. Loop 工程的安全防线
为防止智能体失控，必须内置以下防线（含基础三防和扩展机制）：
| 防线类型 | 说明 |
|---|---|
| 迭代轮数上限 | 无论任务完成与否，最多运行固定轮数（如 100 轮）后强制退出 |
| 资金/Token 硬限制 | 预算耗尽即阻断，杜绝超支 |
| 状态停滞自动退出 | 连续多轮无实质性进展（如重复相同动作），立即暂停并移交人工 |
| 升级机制（Escalation） | 搞不定时通知人类，如三次重试失败 → 创建 Issue 并 @ 负责人 |
| 退出条件（Exit） | 明确完成判定标准，退出后保留日志供人工审查 |
有了这些防线，才能放心让自动驾驶系统自主运行。
四、AI 智能体工程的三层架构体系
要实现工业级稳定性的智能体，工程架构可划分为三个层次，类比计算机体系如下：
底层：上下文工程（Context Engineering）——内存
它解决"模型眼前能看到什么"的问题。大模型的输入窗口、历史对话、检索到的文档都属于这一层。典型工作包括：搭建 RAG 流水线、记忆摘要、压缩历史对话、编写技能描述文件（skill.md），这些本质上都是在帮助模型整理和优化眼前的信息内存。中层：驾驭工程（Harness Engineering）——操作系统
它保证单个智能体在单次会话中的稳定运行。就像操作系统为进程提供运行环境和规则，这一层决定了模型如何调用工具、代码出错后如何重试、如何在沙箱中安全执行。具体工作包括编写智能体行为规范（agent.md）、通过 MCP 连通各种工具、设计验证和评估机制，相当于为智能体套上"缰绳"。顶层：循环工程（Loop Engineering）——调度器
它超越单个智能体和单次对话，从全局角度回答：谁来决定下一步运行什么、何时运行、运行多久。这一层需要解决定时自动化触发、目标达成判断、Triage 收件箱设计，以及将任务智能分发给不同子智能体。相关实践包括编写调度脚本、设计状态进度文件和多智能体编排流程。
过去我们只聚焦于写提示词，实际上一直停留在上下文工程层面。要做出真正可商用的 AI 系统，必须将三层工程体系完整搭建起来。
五、Loop Agent 设计要素
1. Loop Engineering 五大构建块
| 构建块 | 说明 |
|---|---|
| 自动化调度 | 定时或事件驱动触发 Loop 运行 |
| 隔离（含 Maker-Checker） | 安全隔离环境，执行者与检查者相互独立 |
| Skill（渐进式披露） | 按需加载的技能描述，避免上下文溢出 |
| 连接器/工具调用 | MCP 等标准化工具调用协议 |
| 子 Agent 协作 | 多 Agent 分工协同 |
附加能力：记忆层管理，负责跨会话的知识持久化。
2. Loop Agent 设计要素（11 项）
| 要素 | 说明 |
|---|---|
| 目标（Objective） | 明确优化目标，如"保持 CI 绿色" |
| 触发（Trigger） | 运行时机：定期轮询或事件驱动 |
| 发现（Discover） | 如何找到待处理任务（读取日志、Issues 等） |
| 工作空间（Workspace） | Agent 安全操作的隔离环境（如 Git Worktree） |
| 上下文（Context） | 持久化知识（SKILL.md、CLAUDE.md），跨会话保留 |
| 委托（Delegation） | 多 Agent 分工：执行者不检查，检查者不执行，相互独立 |
| 验证（Verification） | 判断做对的标准（测试通过 / 独立评估器判定） |
| 状态（State） | 跨会话存活信息（进度文件、看板），与 Context 紧密关联 |
| 预算（Budget） | 停止条件：最大轮数、Token 上限、时间限制 |
| 升级（Escalation） | 失败时如何通知人类（如三次重试失败 → 创建 Issue 并 @ 负责人） |
| 退出（Exit） | 完成判定标准，退出后保留日志供人工审查 |
3. 主要风险点
| 风险 | 描述 |
|---|---|
| 无限循环 | 现有框架下容易死循环，必须设置预算边界 |
| 目标漂移 | 需求不明确时 Agent 易跑偏，需将目标和边界定清晰 |
| 上下文溢出 | 需具备压缩能力或人为介入管理 |
| 静默失败 | Loop 看似运行正常，实则无产出（Maker-Checker 协调问题） |
| Token 成本爆炸 | 死循环带来极高费用 |
六、典型案例：合同智能完善系统
以下通过一个"合同智能完善系统"的完整案例，展示 Loop Engineering 各要素在实际落地中的具体形态。
1. 系统概述
该系统实现了一个基于多轮 Editor-Reviewer 协作的智能合同完善流程。系统持续监听pending_contracts/文件夹，自动发现待处理的合同文件，通过 Python for 循环驱动 Editor 和 Reviewer 两个 Agent 协同工作，直至合同通过审查或达到上限轮次后转人工处理。
2. 系统流程图
┌─────────────────────────────────────┐ │ 📂 pending_contracts/ │ │ 待处理合同（TXT格式） │ │ ┌─────────────────────────────┐ │ │ │ 📄 contract_v1.txt │ │ │ └─────────────────────────────┘ │ └─────────────────────────────────────┘ │ ▼ ═══════════════════════ ║ 每 10 秒扫描一次 ║ ═══════════════════════ │ ▼ ┌─────────────────────────────────────┐ │ 🐍 Python for 循环控制 │ │ 循环入参：文件路径、轮次、轮次上限 │ │ 当前：第 N 轮 │ │ │ │ ┌─────────────┐ ┌───────────────┐ │ │ │Editor │ │SKILL.md │ │ │ │1.读取原文 │ │✅条款完整性 │ │ │ │2.对照四维度 │ │✅格式规范性 │ │ │ │3.补充调整 │ │✅权利义务平衡 │ │ │ │4.写入新版本 │ │✅合规性审查 │ │ │ └─────────────┘ └───────────────┘ │ └─────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 📝 contract-editor │ │ · 读取合同原文 │ │ · 对照 SKILL.md 四大维度检查 │ │ · 补充缺失条款，调整措辞表述 │ │ · improve_contract 写入完善版本 │ │ │ │ 工具：read_contract | improve_contract │ └─────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 💚 contract-reviewer │ │ · 独立读取合同（只读权限） │ │ · 逐项检查四大维度 │ │ · 给出审查结论 │ │ │ │ 工具：read_contract (只读) │ │ ✅ 审查通过 ❌ 审查不通过 │ └─────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 🟠 Python 判断 · 结果分流处理 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────┐ │ │ │✅通过 │ │🔵不通过 │ │⛔耗尽 │ │ │ │合同定稿 │ │回到循环 │ │转人工 │ │ │ │移出队列 │ │重新Editor│ │兜底 │ │ │ └──────────┘ └──────────┘ └──────┘ │ └─────────────────────────────────────┘ │ ▼ ═══════════════════════ ║ ↩ 回到循环开头 ║ ║ 继续扫描文件夹 ║ ═══════════════════════3. 各设计要素在案例中的体现
| 设计要素 | 在合同系统中的具体实现 |
|---|---|
| 目标（Objective） | 产出通过审查的合同定稿版本 |
| 触发（Trigger） | 每 10 秒轮询扫描pending_contracts/文件夹 |
| 发现（Discover） | 文件系统监听，识别新增的contract_*.txt文件 |
| 工作空间（Workspace） | 文件系统隔离，Editor 拥有读写权限，Reviewer 仅拥有只读权限 |
| 上下文（Context） | 合同原文 + SKILL.md（四大维度规范）作为持久化知识 |
| 委托（Delegation） | Editor 负责修改，Reviewer 负责独立审查，两者互不干扰 |
| 验证（Verification） | Reviewer 独立给出"通过/不通过"的布尔结论 |
| 状态（State） | 当前轮次、文件路径、审查结论记录在循环变量中 |
| 预算（Budget） | for 循环轮次上限（如 3 轮） |
| 升级（Escalation） | 超过上限轮次 → 转人工处理 |
| 退出（Exit） | 审查通过即退出循环，合同定稿移出队列；耗尽退出则保留日志移交人工 |
4. 案例中的五大构建块
| 构建块 | 在该系统中的对应实现 |
|---|---|
| 自动化调度 | 每 10 秒扫描文件夹的轮询机制 |
| 隔离（Maker-Checker） | Editor 写 + Reviewer 只读审查，执行者与检查者完全分离 |
| Skill（渐进式披露） | SKILL.md 以四大维度方式按需加载至各 Agent 上下文 |
| 连接器/工具调用 | read_contract、improve_contract等标准化文件操作工具 |
| 子 Agent 协作 | Editor Agent 与 Reviewer Agent 通过文件系统和循环控制协作 |
5. 风险防范在案例中的对应机制
| 风险 | 该系统的防范措施 |
|---|---|
| 无限循环 | for 循环设置固定轮次上限（如 3 轮） |
| 目标漂移 | SKILL.md 明确四大维度作为固定评审标准 |
| 静默失败 | 每轮审查产出明确结论（通过/不通过），不通过则继续修改 |
| Token 成本爆炸 | 轮次上限 + 单轮上下文固定（合同 + SKILL.md），成本可预期 |
| 上下文溢出 | SKILL.md 为固定长度规范文档，合同原文为单个文件，整体可控 |
6. 案例总结
该案例完整覆盖了 Loop Engineering 的核心要素：
- 起点：
pending_contracts/文件夹中新增合同文件 - 循环体：Editor 完善 → Reviewer 审查 → 判断分流
- 停止条件：审查通过（成功退出）或达到轮次上限（耗尽退出）
- Maker-Checker 分离：Editor 和 Reviewer 权限隔离、角色独立
- Skill 驱动：SKILL.md 作为标准规范贯穿全过程
- 升级兜底：系统无法完成时自动转人工处理
七、微架构组件与宏观架构的双驱并行
在企业实际生产中，可以采用"微观组件"与"宏观架构"双区并行的方式推进。
1. 微架构层：Agent 智能组件与部署
我们将开发工作模块化为15 个微观驾驭组件，分为三类：
- 基础与知识类：规范生成引擎、技能库、记忆系统等，用于建立认知。
- 执行与连接类：工具集、多智能体协同、结构化输出等，让智能体能够干活。
- 控制与治理类：沙箱隔离、任务编排、可观测性等，确保安全和受控。
在此基础上，Micro Loop 组装引擎根据业务需求自动选配和组装这些组件。例如，一个内部数据分析场景不需要高并发，引擎会自动退订异步通信组件；但因为数据敏感，引擎会强制加入沙箱隔离和权限治理。整个过程就像在流水线上按需组装一辆定制汽车，最终直接交付运行边界清晰、安全稳定的企业级智能体。
2. 宏观层：17 层 AI 原生应用架构与演进
宏观层面关注"当企业有成千上万个 Agent 时，整个技术生态与治理架构如何自动演进"。
根据第一性原理：
- AI 原生应用 = 功能侧架构（11 层） + 治理侧架构（6 层）
功能侧架构（11 层）：
流量网关、Agent API 网关、消息队列（MQ）、主从 Agent 业务逻辑、Skills 层、AI 网关、模型层、MCP 网关、知识库及记忆系统层。
治理侧架构（6 层）：
AI 配置中心、AI 注册中心、AI 评估体系、AI 安全体系、AI 治理体系、AI 弹性伸缩体系。
宏观 Loop 组装引擎的使命：
根据企业复杂的业务大流，自动统筹、调度和组装这 17 层架构中的治理和功能模块，实现无需人工重构代码即可输出可扩展的 AI 整体架构。
八、人机协同的新范式与企业核心资产
1. 人机解耦新范式
循环工程深刻重塑了人与 AI 的协作方式，表现为一种人机解耦的新范式。
| 维度 | 传统提示词驱动 | 自动化闭环（Loop） |
|---|---|---|
| 交互特征 | 高频同步（发指令→等结果→纠错） | 低频异步（给定目标→系统自动流转） |
| 人类生态位 | 执行链中的"肉身控制器" | 系统边界外的顶级设计者和合规审计者 |
| 核心关注点 | 局部指令微调（如何"哄好"模型） | 规则、工具集、评估标准的制定 |
| 运行方式 | 人下班，系统停 | 可 24×7 不间断自动演进 |
我们不再需要时刻盯着模型，而是退到后台，专注于设计严密的任务拆解逻辑、精准的中间状态评估标准和科学的终止边界。
2. 人的新角色
- 人不能完全放手，需参与：
- 调整提示词、优化 Skill / 工具 / 代码逻辑
- 代码审查（Code Review）
- 开发监控面板，观测 Loop 运行状态和 Token 消耗
- 未来开发者工作重心从"写代码"转向"开发工具、完善 Skill、优化 Loop 设计"，但代码功底仍是必需的。
3. 企业核心资产的重新定义
在 Loop 工程时代，企业的核心竞争力不再是那些记事本中密密麻麻的提示词库，而是两样新的资产：
- 高鲁棒性的底座组件库：是否有标准化、模块化的工具接口，沙箱隔离是否到位，状态管理器是否稳定。这决定智能体在执行单步任务时能否绝对可靠。
- 高精度的调度与评价体系：任务拆解逻辑是否严密，中间状态评估是否精准，终止边界是否科学，这决定了系统能否安全、高效地自动化运行。
4. 未来趋势
- 2026 年下半年预计出现 Loop 监控/管理框架（类似 Deep Agent 或 Cloud Code 提供的能力）
- 开发者应及时拥抱这类新工具
未来智能化软件工程的核心命题已经转变：我们不再研究如何对大模型发指令，而是研究如何构建一套让大模型安全、高效、合规运行的自动化运转温室。这就像从一位每天给植物浇水、逐片修剪叶子的园丁，转变为设计一座全自动现代温室的设计师。只有将精力和时间从具体的提示词微调中彻底解脱出来，聚焦于系统级的调度机制与底层基础设施建设，才能真正推开企业级 AI 应用降本增效的大门。