本文基于"模智空间"PPT《Prompt · Context · Harness · Loop 四大AI工程支柱》的 Loop Engineering 部分内容扩展创作，深入探讨 Agent 循环的设计理念、六大组件与工程实践。
一、什么是 Loop Engineering？
1.1 从"人驱动模型"到"循环驱动模型"
Loop Engineering 代表了一种全新的 AI 工程协作范式。它的核心思想是：不再由人手动反复向 AI 智能体下发指令，转而搭建一套自动化工作循环，由系统自主调度智能体、推进各项任务。
传统模式：人 → 指令1 → AI执行 → 人检查 → 指令2 → AI执行 → 人检查 → ...
Loop模式：人设计循环 → [循环：感知→推理→行动→观察→判断→继续/停止] → 最终结果
也就是说，过去是人不断驱动智能体；现在开始变成人设计循环，循环驱动智能体。
Loop Engineering 不是某一个具体产品的专属功能，而是一种新的工程协作模式——它把 AI 从"一次性工具"变成了"持续运行的自动化系统"。
1.2 Loop 与其他三大工程的关系
在前面的文章中，我们讨论了：
- Prompt Engineering：解决"怎么问"的问题
- Context Engineering：解决"让 AI 看到什么"的问题
- Harness Engineering：解决"AI 在什么环境里工作"的问题
而 Loop Engineering 解决的是最关键的一步："AI 做完一步后怎么办？"
它是将前三个工程串联起来的"胶水层"——在 Loop 中，Prompt 定义了每一步的输入格式，Context 提供了每一步的信息支撑，Harness 保障了每一步的安全执行，而 Loop 本身决定了整个流程的节奏、分支和终止条件。
二、智能体的内循环与外循环
2.1 智能体的内循环：感知-推理-行动-观察
每个智能体内部都在运行一个标准的控制循环：
┌──────────────────────────┐
│ │
▼ │
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│ 感知 │ → │ 推理 │ → │ 行动 │ → │ 观察 │
│Perceive│ │Reason │ │ Act │ │Observe│
└───────┘ └───────┘ └───────┘ └───────┘
│
│
┌───────┐ │
│ 判断 │ ←─────┘
│Decide │
└───┬───┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
继续循环 修正重试 终止输出
这个循环有几个关键特性：
连续性：每一步的输出是下一步的输入，形成信息传递链。这意味着循环中的任何一步出现偏差，都可能在后续步骤中被放大。
状态依赖：循环中每一步的决策都依赖于当前状态（包括历史步骤的结果、环境反馈、剩余资源）。状态管理是 Loop Engineering 的核心挑战。
条件分支：循环不是线性的——根据观察结果，可能进入不同的分支（继续、修正、重试、回退、终止）。
2.2 外循环：触发、管控与持久化
Loop Engineering 的核心关注点并非单轮大模型的工具调用细节，而是完整的管控逻辑：
| 关注点 | 核心问题 | 工程挑战 |
|---|---|---|
| 触发时机与触发源 | 什么条件触发循环？定时？事件？手动？ | 触发条件的设计、防重复触发 |
| 执行任务 | 每个循环周期执行什么任务？ | 任务拆分、依赖管理 |
| 校验规则 | 如何判断执行结果是否正确？ | 校验标准的设计、自动化验证 |
| 迭代决策 | 校验通过/失败后如何处理？ | 重试策略、升级机制、终止条件 |
| 状态持久化 | 如何保存全流程运行状态？ | 数据结构设计、故障恢复 |
三、Loop Engineering 的六大组件
把一典型的 Loop 拆分开，就是六个常见的 Agent 系统组成部分：
┌─────────────────────────────────────────────────────────┐
│ Loop Engineering │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 自动化机制 │ │ Worktree │ │ Skill │ │
│ │ (心跳) │ │ (并行隔离) │ │ (知识沉淀) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ MCP连接器 │ │Sub-Agent │ │ Memory │ │
│ │ (连接枢纽) │ │ (执行验证) │ │ (持久记忆) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────┘
3.1 自动化机制：持续运行的心跳
一个 Loop 之所以叫 Loop，不是因为它执行了一次任务，而是因为它会持续运行。自动化机制就是这个循环的"心跳"。
自动化机制的几种形态：
定时触发（Cron-based）：
- 每天定时运行代码审查、日报生成、数据同步
- 适用于周期性任务，节奏固定
事件驱动（Event-driven）：
- 收到新 PR 时自动触发代码审查
- 监控告警触发时自动进行故障排查
- 适用于响应式任务，节奏由外部事件决定
条件触发（Condition-based）：
- 当任务队列积压超过阈值时启动处理
- 当测试覆盖率下降到阈值以下时触发优化
- 适用于需要动态判断的场景
设计自动化机制的关键考量：
- 防重复：同一事件不应触发多个相同循环实例
- 幂等性：同一个循环执行多次，结果应一致
- 超时控制：设置最大执行时间，防止循环无限运行
- 优雅降级：当触发条件不满足时，不应崩溃，而是跳过或延迟
3.2 Worktree：并行协作的隔离机制
Worktree 是解决多智能体并行工作冲突的核心机制。当多个 AI Agent 同时处理同一个项目时，最常见的问题就是文件覆盖、代码冲突。
Worktree 的工作原理：
基于同一个 Git 仓库，创建多个独立的工作目录和分支。每个 Agent 在自己的 Worktree 中工作，编辑操作完全隔离、互不干扰。
主仓库 (main)
├── Worktree 1 (Agent A: 实现功能 X)
│ ├── branch: feature/x
│ └── 独立工作目录
├── Worktree 2 (Agent B: 修复 Bug Y)
│ ├── branch: fix/y
│ └── 独立工作目录
└── Worktree 3 (Agent C: 重构模块 Z)
├── branch: refactor/z
└── 独立工作目录
核心价值：
- 完全隔离：不同 Agent 的修改互不影响，无需担心文件锁或覆盖
- 并行高效：多个 Agent 可以同时工作，不互相阻塞
- 原生合并：基于 Git 的分支合并机制，冲突解决有成熟的工具支持
- 可追溯：每个 Agent 的修改历史独立记录，便于审计
与传统并行开发的对比：
| 方式 | 隔离性 | 冲突处理 | 适用场景 |
|---|---|---|---|
| 同一分支 | 差 | 文件锁/手动合并 | 简单任务 |
| 不同分支 | 好 | Git 合并 | 传统开发 |
| Worktree | 最好 | 独立工作目录+Git合并 | 多 Agent 协作 |
3.3 Skill：知识沉淀的底座
在传统 AI 使用中，每次开启新会话都是空白状态，需要重复告知项目规范、构建流程、特殊禁忌。一旦信息缺失，AI 就会凭主观猜测补全逻辑，产生大量偏差。
Skill 机制的核心思想：将项目核心知识、编码规范、流程步骤、历史踩坑经验，统一写入结构化的 Skill 定义文件中，一次性配置完成后，AI 循环任务可以自动读取复用。
一个典型的 Skill 定义：
# Skill: code-review
## 触发条件
- 当有新的 Pull Request 提交时
- 当用户请求代码审查时
## 审查规范
- 遵循项目 ESLint 配置
- 函数不超过 50 行
- 必须包含单元测试
- 禁止使用 any 类型
## 审查流程
1. 检查代码风格是否符合规范
2. 检查是否有明显的逻辑错误
3. 检查是否有安全漏洞
4. 检查测试覆盖率
5. 输出审查报告
## 输出格式
- 使用 Markdown 格式
- 每个问题标注严重程度（Critical/Major/Minor）
- 给出具体的修改建议和代码示例
Skill 的价值：
- 知识固化：将隐性知识（老员工的编码习惯）转化为显性规则（Skill 文件）
- 一致性保障：所有 Agent 遵循同一套规范，输出风格一致
- 降低沟通成本：不再需要每次重复告知项目规范
- 持续积累：新的经验和规范可以持续追加到 Skill 中
3.4 插件和连接器：连接的枢纽
如果一个 Loop 只能读写本地文件，它的能力其实很有限。真正有价值的 Loop，必须能连接实际使用的工具。
MCP（Model Context Protocol） 是当前最主流的标准化连接方案。它定义了：
- 工具发现：Agent 如何知道有哪些工具可用
- 工具调用：Agent 如何调用工具
- 结果返回：工具如何返回结果给 Agent
- 资源访问：Agent 如何访问外部资源（文件、数据库、API）
MCP 的典型应用场景：
Agent Loop
│
├── MCP Server: GitHub
│ ├── 读取 PR 信息
│ ├── 提交代码审查意见
│ └── 创建 Issue
│
├── MCP Server: Database
│ ├── 查询数据
│ └── 执行迁移
│
├── MCP Server: Slack
│ ├── 发送通知
│ └── 读取消息
│
└── MCP Server: File System
├── 读写文件
└── 搜索代码
连接器设计的核心原则：
- 标准化接口：所有工具遵循统一的接口规范，降低集成成本
- 安全隔离：每个连接器有独立的权限范围
- 错误处理：连接器应优雅处理网络故障、超时、权限不足等异常
- 可观测：所有工具调用都有日志记录，便于追踪和调试
3.5 Sub-Agent：执行与验证分离
AI 普遍存在"自审盲区"——执行任务的 AI 很难发现自己写出的漏洞和逻辑问题。正如一个人很难完全客观地评审自己的作品。
Sub-Agent 的核心思想：通过拆分智能体角色，实现执行与验证的分离，避免单一智能体既当"运动员"又当"裁判"带来的自我评估偏差。
典型的 Sub-Agent 分工模式：
主 Agent（协调者）
│
├── Sub-Agent: 编码工程师
│ ├── 职责：根据需求编写代码
│ └── 输出：代码文件 + 实现说明
│
├── Sub-Agent: 代码审查员
│ ├── 职责：审查编码工程师的代码
│ └── 输出：审查报告 + 修改建议
│
├── Sub-Agent: 测试工程师
│ ├── 职责：编写和执行测试用例
│ └── 输出：测试报告 + 覆盖率数据
│
└── Sub-Agent: 安全审计员
├── 职责：检查安全漏洞
└── 输出：安全审计报告
交叉验证的价值：
- 编码工程师可能忽略的边界条件，测试工程师会覆盖
- 测试工程师可能遗漏的安全性题，安全审计员会检查
- 代码审查员可能没注意的性能问题，测试工程师的基准测试会发现
设计 Sub-Agent 的关键考量：
- 角色边界清晰：每个 Sub-Agent 的职责范围明确，不重叠
- 信息隔离：Sub-Agent 之间不应共享"偏见"——审查员不应该知道编码工程师的"自评"
- 结果汇总：主 Agent 需要汇总各 Sub-Agent 的反馈，做出最终决策
- 冲突处理：当不同 Sub-Agent 的意见冲突时，需要明确的决策机制
3.6 Memory：外部持久化记忆
AI 模型每次重启、每次循环结束后都会清空上下文记忆（无状态）。Memory 组件是应对这一"失忆"问题的核心机制。
Memory 的核心功能：
- 记录历史状态：已完成的工作、当前进度、待办事项
- 记录错误经验：哪些方法尝试过但失败了，失败原因是什么
- 记录决策逻辑：为什么选择方案 A 而不是方案 B
- 支撑断点恢复：任务中断后，可以从 Memory 中恢复状态继续执行
Memory 的存储结构示例：
{
"task_id": "build-api-service-2024",
"status": "in_progress",
"created_at": "2024-06-15T10:00:00Z",
"updated_at": "2024-06-15T14:30:00Z",
"goal": "构建用户管理 REST API",
"completed_steps": [
{
"step": "设计数据模型",
"status": "completed",
"result": "已创建 User 模型的 Prisma Schema",
"artifacts": ["prisma/schema.prisma"]
},
{
"step": "实现 CRUD 接口",
"status": "completed",
"result": "已实现 GET/POST/PUT/DELETE 接口",
"artifacts": ["src/routes/users.ts"]
}
],
"current_step": {
"step": "编写单元测试",
"status": "in_progress",
"progress": "已完成 60%"
},
"pending_steps": [
"添加认证中间件",
"编写 API 文档"
],
"error_log": [
{
"step": "实现 CRUD 接口",
"error": "TypeError: Cannot read property 'id' of undefined",
"resolution": "添加了空值检查",
"timestamp": "2024-06-15T12:00:00Z"
}
]
}
Memory 的设计原则：
- 结构化存储：使用 JSON、YAML 等结构化格式，便于 Agent 解析和更新
- 增量更新：只更新变化的部分，而不是整体重写
- 版本控制：关键状态变更应保留历史版本，支持回滚
- 磁盘持久化：写入磁盘而非仅依赖内存，确保重启后不丢失
四、Loop Engineering 的工程实践
4.1 循环设计模式
在实际工程中，Loop 通常采用以下几种设计模式：
顺序循环（Sequential Loop）：
步骤1 → 步骤2 → 步骤3 → ... → 步骤N → 完成
适用于步骤明确、依赖关系清晰的线性任务。
自适应循环（Adaptive Loop）：
步骤1 → 检查 → 通过？→ 步骤2 → 检查 → 失败？→ 重试步骤2 → 检查 → 通过？→ 步骤3 → ...
适用于需要根据中间结果动态调整的任务。
分层循环（Hierarchical Loop）：
主循环（协调层）
├── 子循环1（执行层）
├── 子循环2（验证层）
└── 子循环3（修正层）
适用于复杂任务，需要多层级的协调与控制。
并行循环（Parallel Loop）：
主循环
├── 并行任务A → 结果A
├── 并行任务B → 结果B
└── 并行任务C → 结果C
↓
汇总结果
适用于可以并行的子任务，提高执行效率。
4.2 循环的终止条件设计
Loop 必须设计明确的终止条件，否则可能陷入无限循环。常见的终止条件包括：
| 终止条件 | 说明 | 示例 |
|---|---|---|
| 成功终止 | 任务目标达成 | 测试全部通过 |
| 最大步数终止 | 防止无限循环 | 最多执行 50 步 |
| 超时终止 | 防止长时间运行 | 超过 30 分钟 |
| 成本终止 | 防止资源耗尽 | Token 消耗超过预算 |
| 质量阈值终止 | 即使未完美，达到可接受水平 | 覆盖率 > 80% |
| 人工干预终止 | 无法自动决策时 | 需要人工确认的决策点 |
推荐实践：组合使用多种终止条件，形成"安全网"：
终止条件优先级：
1. 成功终止（最高优先级，正常退出）
2. 人工干预终止（遇到无法自动决策的情况）
3. 成本终止（防止资源浪费）
4. 超时终止（防止无限等待）
5. 最大步数终止（最后的兜底保护）
4.3 循环的监控与调试
Loop 的运行比单次 AI 调用更难调试——因为问题可能出在循环的任何一步。
关键监控指标：
- 循环次数：每个任务平均循环多少轮？是否存在异常多的重试？
- 步数分布：大部分时间花在哪一步？是否存在瓶颈？
- 终止原因分布：正常终止 vs 异常终止的比例？
- 成功率：按任务类型统计成功率
- 成本分布：Token 消耗按任务类型和步骤分布
调试技巧：
- 记录每一步的完整输入输出：包括中间推理过程，便于回溯
- 可视化执行链路：使用工具（如 LangSmith）可视化循环的执行过程
- 设置断点：在关键步骤设置人工确认点，暂停循环等待审查
- 回放机制：基于记录的状态文件，回放循环的执行过程
五、Loop Engineering 与其他三大工程的关系
四大工程不是孤立的，而是一个有机整体：
┌──────────────────┐
│ Loop Engineering │
│ "做完一步后怎么办" │
└────────┬─────────┘
│ 编排与调度
┌────────────────┼────────────────┐
│ │ │
┌────────▼────────┐ ┌────▼──────┐ ┌───────▼────────┐
│Prompt Engineering│ │ Context │ │ Harness │
│ "怎么问" │ │Engineering│ │ Engineering │
│ │ │ "看什么" │ │ "怎么安全执行" │
└─────────────────┘ └──────────┘ └────────────────┘
在 Loop 的每一次迭代中：
- Prompt 定义了当前步骤的输入格式和任务指令
- Context 提供了当前步骤所需的信息（知识库、历史状态、工具结果）
- Harness 保障了当前步骤的安全执行（权限校验、沙箱隔离、错误处理）
- Loop 决定了下一步做什么（继续、修正、重试、终止）
六、总结
Loop Engineering 代表了 AI 工程从"工具"到"系统"的范式跃迁。它的核心价值在于：
- 从被动到主动：AI 不再等待人类指令，而是自主推进任务
- 从单次到持续：从一次性的问答，到持续运行的自动化循环
- 从人到循环：人设计循环，循环驱动智能体，人从执行者变为设计者
六大组件构成了 Loop 的完整架构：
| 组件 | 角色 | 一句话概括 |
|---|---|---|
| 自动化机制 | 心跳 | 让循环持续运行 |
| Worktree | 隔离 | 让多 Agent 并行不冲突 |
| Skill | 知识 | 让经验可沉淀复用 |
| MCP 连接器 | 枢纽 | 让循环连接真实世界 |
| Sub-Agent | 分工 | 让执行与验证分离 |
| Memory | 记忆 | 让循环拥有持久状态 |
Loop Engineering 的终极目标是构建一个自驱动、自修正、自完善的 AI 工作系统——它不仅能执行任务，还能在循环中持续学习、持续优化、持续进化。
上一篇：Harness Engineering —— 系统的安全护栏
（全文完）
本文是"AI 工程四大支柱"系列的第四篇。本系列基于"模智空间"的 PPT 内容扩展创作，补充了技术细节、行业实践与工程思考，旨在为 AI 工程化实践提供系统性的参考框架。
