Loop 工程：Agent 的心跳是怎么跳的

你有没有用过全自动洗衣机？你把衣服扔进去，按一下启动键，然后……它就自己开始干了：进水 → 搅洗 → 排水 → 漂洗 → 脱水。如果水太浑浊，它会自动多漂洗一轮；如果衣服不平衡，它会暂停重新调整再继续脱水。整个过程中你什么都不用管——但它的每一步都有明确的判断逻辑：什么时候进入下一步、什么时候多做一轮、什么时候彻底停下来。AI Agent 的工作方式跟这台洗衣机惊人地相似。今天我们就来拆解 Agent 内部的这台”自动洗衣机”——Loop 工程。

这是「小白讲 AI」系列的第 15 篇。我们正在走一条进化线：第 5 篇讲了 Prompt Engineering（怎么说话），第 13 篇讲了 Context Engineering（管好信息），第 14 篇讲了 Harness 工程（搭好骨架）。今天是进化线的终点站——Agent 骨架搭好之后，它的”心跳”到底是怎么跳的？

一、进化线全景回顾

在正式进入 Loop 工程之前，让我们站在山顶上回看一下走过的路：

篇目	概念	核心问题	一句话概括
第 5 篇	Prompt Engineering	怎么跟 AI 说一句话？	把指令写清楚
第 13 篇	Context Engineering	AI 该看到什么信息？	精选最有价值的信息
第 14 篇	Harness 工程	Agent 的系统骨架怎么搭？	工具 + 护栏 + 状态 + 编排
第 15 篇	Loop 工程	Agent 的循环怎么转？	让 Agent 靠谱地持续工作

从左到右，我们的视角在不断升高：从一条指令 → 一个上下文窗口 → 一套系统架构 → 一个运行时过程。

Prompt Engineering 决定了 Agent 的”语言质量”，Context Engineering 决定了 Agent 的”信息质量”，Harness 决定了 Agent 的”骨架”——而 Loop 工程决定了 Agent 的”行为质量”。一个 Agent 跑起来之后，它的每一步决策、每一次工具调用、每一次自我反思，都是 Loop 在驱动。

Loop 是 Agent 的心跳——它停了，Agent 就停了；它乱了，Agent 就乱了。

二、Agent Loop 的基本结构

在第 8 篇里，我们用 ReAct（Reasoning + Acting）模式介绍了 Agent 的工作循环。但那时候我们从”概念”的角度来看 ReAct——“哦，Agent 会想、会做、会观察”。今天我们要从”工程”的角度来看：这个循环到底怎么设计才靠谱？

一个生产级的 Agent Loop 通常有五个步骤：

Step 1：Plan（规划）

Agent 拿到任务后，第一件事不是直接干活，而是想一想该怎么干。

用户：帮我分析一下我们网站最近一个月的流量数据，
找出流量下降的原因。

Agent 的规划：
1. 先获取最近 30 天的流量数据
2. 对比上个月同期数据
3. 按渠道（搜索、社交、直访等）分别分析
4. 找出下降幅度最大的渠道
5. 搜索可能导致该渠道下降的外部原因
6. 整理成分析报告

注意，这个规划不需要百分之百正确——它更像是一张”草稿路线图”，后面的步骤可以根据实际情况调整。但有了规划，Agent 就不会”走一步看一步”地乱撞。

Step 2：Execute（执行）

根据计划中的当前步骤，Agent 选择合适的工具并执行操作。

当前步骤：获取最近 30 天的流量数据
→ 调用工具：query_analytics(period="last_30_days")
→ 等待返回...

Step 3：Observe（观察）

工具执行完毕后，Agent 查看返回的结果。

工具返回：
{
  "total_visits": 45230,
  "previous_period": 52100,
  "change": "-13.2%",
  "by_channel": {
    "organic_search": {"visits": 18900, "change": "-24.5%"},
    "social": {"visits": 12300, "change": "+5.2%"},
    "direct": {"visits": 8100, "change": "-3.1%"},
    "referral": {"visits": 5930, "change": "-8.7%"}
  }
}

Step 4：Reflect（反思）

这一步是 Loop 工程的关键，也是 ReAct 原始论文中最重要的创新——Agent 不只是机械地执行下一步，而是回头看看当前的进展：

Agent 的反思：
- 总流量下降了 13.2%
- 最大的下降来源是 organic_search，降了 24.5%
- 我的原始计划是按渠道分析，看来应该优先深入分析搜索渠道
- 需要调整计划：加一步"搜索引擎排名变化分析"

Step 5：Decide（决策）

基于反思的结果，Agent 做出一个关键决策：继续、调整还是结束？

• 继续：按计划执行下一步
• 调整：修改计划，加入新的步骤或跳过某些步骤
• 结束：任务已完成（或无法继续），停止循环

决策：调整计划，下一步深入分析搜索渠道的排名变化。
→ 回到 Step 2（Execute），执行新的步骤

然后循环继续转：Execute → Observe → Reflect → Decide → Execute → ……直到 Agent 认为任务完成或触发了熔断机制。

三、三大设计决策：让 Loop 靠谱的关键

Loop 的基本结构不复杂——Plan → Execute → Observe → Reflect → Decide 的循环。但要让这个循环在真实世界中可靠运行，有三个关键的设计决策需要仔细思考。

决策一：什么时候停？（终止条件）

“知道什么时候该停”可能是 Agent Loop 中最难的问题。人类做一件事，直觉会告诉你”差不多了”或者”够了”。但 Agent 没有这种直觉——它需要明确的终止条件。

方法 1：目标达成检测

Agent 在每一轮 Reflect 阶段评估”任务目标是否已经完成”。这要求你在任务开始时就给 Agent 一个清晰的目标定义。

目标：生成一份包含以下要素的分析报告——
✅ 总流量变化数据
✅ 各渠道分解分析
✅ 下降原因识别
✅ 改进建议

Agent 每一轮检查这些 checkbox，全勾上了就停。

方法 2：硬性限制

不管目标是否达成，到了限制就停。在第 14 篇里我们讲过：

• 最大步数（比如 25 步）
• 最大 Token 消耗（比如 50,000 Token）
• 最大运行时间（比如 5 分钟）

方法 3：两者结合（推荐）

目标达成检测 + 硬性限制，哪个先触发就停。这是生产环境中最常用的方式——正常情况下 Agent 在完成目标时优雅退出，异常情况下被硬性限制兜底。

决策二：出错了怎么办？（回退策略）

Agent 在执行过程中一定会遇到错误——工具调用超时、API 返回错误、搜索结果不相关、代码执行报错……关键是：出错后怎么办？

策略 1：重试（Retry）

最简单的方式：出错了再试一次。通常配合指数退避（Exponential Backoff）——第一次等 1 秒重试，第二次等 2 秒，第三次等 4 秒，避免连续快速重试把系统打崩。

第 1 次调用：失败（超时）
→ 等 1 秒
第 2 次调用：失败（超时）
→ 等 2 秒
第 3 次调用：成功！

策略 2：降级（Fallback）

高级方式失败了，换一种简单的方式。比如：

• 调用 GPT-4o 失败了 → 改用 GPT-4o-mini（更小的模型，更不容易超时）
• 搜索引擎 API 报错了 → 改用网页爬虫直接抓取
• 精确查询没有结果 → 放宽搜索条件

策略 3：求助人类（Human Escalation）

Agent 自己搞不定的时候，把问题抛给人类。这就是 Human-in-the-Loop（人在回路中） 机制。

Agent：我无法确定这个操作是否安全。需要你的确认：
      是否允许删除 /data/old_backups/ 目录下的文件？
      [允许] [拒绝] [跳过此步骤]

Human-in-the-Loop 不是 Agent “认输”的表现，而是成熟 Agent 的标志——知道什么时候该让人类介入，比什么都自己扛着要靠谱得多。

决策三：什么时候该”叫人”？（升级机制）

紧接着上面的 Human-in-the-Loop，一个更细致的问题是：Agent 应该在什么情况下主动”叫人”？

• 高风险操作：删除文件、发送邮件、修改数据库、支付操作
• 低置信度决策：Agent 对自己的判断不确定（比如”我 60% 觉得该选方案 A，但方案 B 也有道理”）
• 连续失败：同一个步骤失败了 3 次，可能不是运气问题而是方向错了
• 信息不足：Agent 缺少完成任务所需的关键信息，但自己无法获取

好的升级机制让 Agent 在”自主”和”谨慎”之间取得平衡——不是每件事都问用户（太烦），也不是什么都自己扛（太危险）。

四、自我反思（Reflection）：Agent 的”内省”能力

在五步循环中，Reflect（反思）是最容易被忽视但最有价值的一步。它让 Agent 从”只会执行”进化到”会思考自己做得对不对”。

内循环 vs 外循环

成熟的 Agent 通常有两层循环：

内循环（Inner Loop）：每一步执行后的即时反思。

“这一步的工具调用成功了吗？返回的数据有用吗？我该继续还是换个方向？”

这是快速、轻量的反思，发生在每一轮 Loop 中。

外循环（Outer Loop）：每隔 N 步做一次全局反思。

“我已经走了 10 步了。让我回头看看整体进展：原始目标是什么？我现在完成了多少？之前的步骤有没有走弯路？接下来的计划需要调整吗？”

这是深度、全局的反思，发生的频率更低（比如每 5 步或每 10 步）。

# 双循环反思（伪代码）
for step in range(MAX_STEPS):
    # 内循环：每一步
    result = execute_step()
    inner_reflection = reflect_on_step(result)  # "这步做得怎么样？"
    
    # 外循环：每 5 步
    if step % 5 == 0 and step > 0:
        outer_reflection = reflect_on_progress(
            original_goal, 
            all_steps_so_far
        )  # "整体进展如何？需要调整计划吗？"
        if outer_reflection.should_revise_plan:
            update_plan(outer_reflection.new_plan)

为什么外循环很重要？因为 Agent 在执行过程中很容易”只见树木不见森林”——每一步看起来都有道理，但走了 10 步之后发现已经完全偏离了原始目标。外循环就是那个让 Agent 偶尔”抬起头来看看全局”的机制。

五、多 Agent 场景下的 Loop 嵌套

在第 8 篇里，我们聊了多 Agent 协作——多个 Agent 组成团队，各自负责不同的任务。那在 Loop 工程的视角下，多 Agent 场景有什么特别之处呢？

答案是：Loop 嵌套。

想象一个”团队领导 + 三个组员”的多 Agent 系统：

外层 Loop（Orchestrator / 团队领导）
│
├─ Step 1：把大任务拆成 3 个子任务
│
├─ Step 2：分配给 Worker A
│  └─ 内层 Loop A（Worker A 自己的执行循环）
│     ├─ Execute → Observe → Reflect → Decide
│     ├─ Execute → Observe → Reflect → Decide
│     └─ 完成，返回结果给 Orchestrator
│
├─ Step 3：分配给 Worker B
│  └─ 内层 Loop B
│     └─ ...
│
├─ Step 4：分配给 Worker C
│  └─ 内层 Loop C
│     └─ ...
│
├─ Step 5：收集三个 Worker 的结果
│
├─ Step 6：Reflect ——三个结果拼在一起完整吗？有冲突吗？
│
└─ Step 7：整合最终输出

这里有几个工程上的重点：

1. 每一层 Loop 都需要自己的熔断机制：Worker 的 Loop 有自己的最大步数，Orchestrator 的 Loop 也有。不能因为一个 Worker 陷入无限循环就拖垮整个系统。

2. 层间通信要精简：Worker 的执行过程可能有 20 步，但返回给 Orchestrator 的应该是一段精练的结果摘要，而不是 20 步的完整日志。这又回到了 Context Engineering 的范畴。

3. Orchestrator 的 Reflect 需要”跨 Worker 比较”：不只是看每个 Worker 的单独结果，还要判断它们之间是否一致、是否互补、是否有矛盾。

六、生产环境的 Loop 陷阱

理论上的 Loop 很优雅，但在真实生产环境中，有几个经典陷阱需要特别警惕。

陷阱一：无限循环（Infinite Loop）

Agent 陷入重复行为，一直在做同一件事或者在两个状态之间来回切换。

典型场景：

Agent：调用搜索工具，搜索"Python 性能优化"
结果：找到 5 条结果
Agent（反思）：这些结果不够详细，我需要更具体的搜索
Agent：调用搜索工具，搜索"Python 代码性能优化最佳实践"
结果：找到 4 条结果
Agent（反思）：还是不够好，再搜一次
Agent：调用搜索工具，搜索"Python 高性能编程技巧 2026"
...（无限重复）

解法：除了最大步数限制，还可以加重复检测——如果 Agent 连续 3 次调用同一个工具且参数相似度超过阈值，自动触发中断或切换策略。

陷阱二：幻觉雪球（Hallucination Snowball）

这个我们在第 8 篇提过，但值得用 Loop 工程的视角重新审视。

Agent 在第 3 步产生了一个小错误（比如误解了一条搜索结果），这个错误被当作”事实”写入了状态。第 5 步基于这个错误做了进一步推理，产生了一个更大的错误。第 8 步基于前两个错误得出了一个完全偏离现实的结论。

Step 3：搜索结果提到"Python 3.12 移除了 GIL"
       → Agent 理解为"Python 3.12 已经完全移除了 GIL"
       （实际上是"实验性可选移除"）
Step 5：基于错误理解，建议用户"直接用多线程替代多进程"
Step 8：生成了一套完全基于"GIL 已移除"假设的架构方案

解法：

• 外循环反思时对之前步骤的关键结论进行交叉验证
• 在关键决策点调用独立的”事实检查”工具
• 每 N 步清除可能存在幻觉的中间状态，从原始数据重新推理

陷阱三：Demo-to-Production Gap（演示与生产的鸿沟）

这是 2026 年 Agent 领域最被广泛讨论的问题之一。

在 demo 中：

• 网络永远通畅，API 永远有响应
• 数据格式永远规范，没有异常值
• 用户的问题永远清晰明确
• Agent 跑 3 步就能完成任务

在生产环境中：

• API 随时可能超时或返回 500 错误
• 数据缺字段、格式混乱、有特殊字符
• 用户的问题模棱两可，甚至自相矛盾
• Agent 可能需要 30 步，中间 10 步是在处理异常情况

解法：Loop 的设计从一开始就要考虑”不幸福路径”（unhappy path）——不只是规划”正常流程”，更要规划”出错了怎么办”。每一种工具调用都要有错误处理，每一种用户输入都要有异常应对。

陷阱四：评测的虚假信心

2026 年 4 月，UC Berkeley 的一项研究引起了轰动：他们开发了一个叫 BenchJack 的工具，用来测试主流 AI Agent 基准测试的安全性。结果令人震惊：

• Terminal-Bench（89 个任务）：100% 被破解
• SWE-bench Verified（500 个实例）：100% 被破解
• WebArena（812 个任务）：~100% 被破解

怎么做到的？BenchJack 利用了基准测试环境中的七种漏洞——比如 Agent 可以直接读取参考答案、评估器和 Agent 共享同一个环境等。一个完全没有解题能力的 Agent，通过利用这些漏洞，可以在主流基准测试中拿到满分。

这对 Loop 工程意味着什么？

• 不要盲目相信基准测试分数来判断你的 Loop 设计是否优秀
• 真正的评测应该在隔离的、模拟真实场景的环境中进行
• Agent 在基准测试中跑得好，不代表它在生产环境的 Loop 中也能可靠运行

七、一个好的 Loop 设计清单

最后，给你一个实用的 Loop 设计清单，帮你检查自己的 Agent 是否具备一个健壮的循环：

✅ 基本结构

• 有明确的 Plan → Execute → Observe → Reflect → Decide 步骤
• 每一步之间有清晰的数据传递

✅ 终止条件

• 有目标达成检测逻辑
• 有最大步数限制
• 有超时机制
• 三者结合使用

✅ 错误处理

• 工具调用失败有重试逻辑（含指数退避）
• 有降级方案（高级失败时切换低级）
• 有 Human-in-the-Loop 机制
• 连续失败时有升级策略

✅ 反思机制

• 每步有内循环反思
• 每 N 步有外循环全局反思
• 反思时会检查是否偏离原始目标

✅ 防御性设计

• 有重复行为检测
• 有关键结论的交叉验证
• 异常路径的处理不弱于正常路径
• 在真实场景（而非基准测试）中验证过

总结

让我们回顾一下今天的内容：

• Loop 是 Agent 的心跳——它驱动着 Agent 的每一步决策和行动。
• 五步循环：Plan → Execute → Observe → Reflect → Decide，其中 Reflect 是最被低估但最有价值的步骤。
• 三大设计决策：终止条件（什么时候停）、回退策略（出错了怎么办）、升级机制（什么时候叫人）。
• 双层反思：内循环看每一步，外循环看全局——防止”只见树木不见森林”。
• 多 Agent 的 Loop 嵌套：每层有自己的熔断，层间通信要精简。
• 四大陷阱：无限循环、幻觉雪球、Demo-to-Production Gap、评测虚假信心。

到这里，我们的进化线就走完了：

Prompt Engineering → 写好一句话
Context Engineering → 管好看到的信息
Harness 工程 → 搭好系统骨架
Loop 工程 → 让心跳可靠地持续跳动

从一条指令到一个持续运行的系统——这就是 Agent 时代的工程进化之路。

---

延伸阅读

1. ReAct: Synergizing Reasoning and Acting in Language Models —— ReAct 模式的原始论文，Loop 工程的学术起源。
2. BenchJack: UC Berkeley Study on Agent Benchmark Vulnerabilities —— 揭示 Agent 基准测试可被系统性破解的研究，对 Loop 评测设计有重要启示。
3. Building effective agents - Anthropic —— 关于 Agent 循环设计、错误处理和人机协作的工程实践指南。

---

小白讲 AI 系列第 15 篇完。进化线走完了，但 Agent 的故事还没完。下一篇我们进入一个全新的话题——MCP 协议：Agent 循环中的”行动”步骤需要调用工具，但每个工具的接入方式都不一样怎么办？MCP 就是 Agent 世界的”USB 接口”，让所有工具即插即用。