Loop Engineering：从 Prompt Engineering 到迭代式智能体工程

当 Prompt Engineering 还在讨论如何写好一条提示时，Loop Engineering 已经在讨论如何让系统自己跑起来。Loop Engineering 不是一个新词，也不是某个巨头发布的框架，它是自 2023 年以来在 Agent 工程实践中逐步沉淀出来的一套方法论。本文试图把这件事讲透。

一、什么是 Loop Engineering

Loop Engineering 的核心命题只有一句话：把 LLM 从"单次问答机"改造为"持续决策循环" 。

具体而言：一个智能体拿到一个任务后，不是一次性输出答案，而是在一个结构化的循环中反复执行"观察—思考—决策—行动—再观察"的过程，直到满足终止条件。这个循环中，每一步都可能调用工具、查询外部知识、反思自己的判断，甚至把任务拆给另一个智能体。

它区别于 Prompt Engineering 的关键点在于：

• Prompt Engineering 优化的是"单次调用的输出质量"。
• Loop Engineering 优化的是"多次调用的整体成功率"。

前者关心一条 prompt 写得好不好，后者关心一条链路能不能闭环。

二、为什么 Loop 是必须的

任何做过 LLM 落地的人都会遇到三个瓶颈：

1. 上下文窗口有限：长任务必须切片处理，切片就带来状态管理问题。
2. 单次推理不可靠：一个模型在单步回答中的准确率可能只有 70%，但如果给它三次自检机会，准确率可以升到 95% 以上。
3. 需要与外部系统交互：查数据库、调 API、读文件、写结果——这些都不是一次生成能完成的。

这三个问题决定了：面向生产的 LLM 应用，几乎必然是循环式架构。把模型当函数用一次就走的，多半只能做 demo。

三、Loop 的最小结构：Observe → Think → Act

一个最小可用的循环由三个阶段组成：

Observe  →  Think  →  Act  →  (循环回到 Observe)

这不是什么新发明，它源自控制论中的经典反馈环，也和强化学习中的 Agent-Environment 交互结构一致。LLM 出现后，这个环被重新表述为：

• Observe（观察）：收集当前上下文、历史对话、工具返回结果、知识库片段。
• Think（思考）：由 LLM 基于观察做推理，决定下一步做什么。
• Act（行动）：调用工具、输出结果、更新状态。

循环的终止条件可以是：达到目标、达到最大轮数、连续多步无进展、用户中断。

下面是一个最简单的伪代码：

state = initial_state(task)
for step in range(max_steps):
    observation = observe(state)
    decision  = think(observation)   # LLM 推理
    if decision.is_final():
        return decision.result
    state = act(state, decision)     # 调用工具/更新状态
return "未完成"

这段代码几乎是所有 Agent 框架的骨架。

四、经典循环范式比较

目前工程实践中至少有五类被反复验证过的循环范式。它们不是互相取代的关系，而是在不同场景下的最优选择。

1. ReAct 范式（Reasoning + Acting）

ReAct 是最朴素、也最常用的一种循环。它的核心是让 LLM 在每一步输出"Thought / Action / Observation"三段式文本，从而把思考过程显式地保留在上下文中。

一个典型的 ReAct 步骤长这样：

Question: 张三 2024 年 3 月的销售额是多少？
Thought  : 我需要先知道张三的员工编号，才能查销售数据。
Action   : Search("员工表 查询 张三")
Obs 1    : 员工编号 E1024，部门销售二部。
Thought  : 有了编号，查 2024-03 的销售明细。
Action   : SQL("SELECT sum(amount) FROM sales WHERE emp_id='E1024' AND month='2024-03'")
Obs 2    : sum = 184200.00
Thought  : 已有结果，返回。
Answer   : 184200.00 元

ReAct 的优点：实现简单，上下文自然保留，容易调试。ReAct 的缺点：每轮都要重新看历史，长任务容易跑偏。

2. Plan-and-Execute 范式

这个范式把循环拆成两层：

• 外层：规划器输出一个步骤清单 Plan。
• 内层：执行器按 Plan 逐项执行，失败时回传重新规划。

Plan  : [A, B, C, D]
Run A → OK
Run B → 失败 → RePlan → [B', C', D]
Run B'→ OK
Run C'→ OK
Run D → OK

它适合任务结构相对明确的场景，比如代码生成、数据分析、文档整理。LangGraph 中的"Plan-and-Execute"就是典型实现。

3. Reflexion / Self-Reflection 范式

这个范式的核心是：在 Action 之后加入一个 Review 步骤，由同一个或另一个模型对刚才的产出打分、提意见，然后把意见塞回循环里重做。

Draft → Review(critique) → Revise → Review(critique) → Final

很多人忽视了 Reflexion 的价值。在写作、代码修复、长文档摘要这类任务上，一个 2-3 轮的反思循环，往往比直接让更强的模型单次输出效果更好，成本还更低。

4. Tree of Thoughts / Graph of Thoughts

当解空间高度离散（比如 24 点、逻辑推理）时，线性循环不够。这时要允许模型同时探索多条路径，最终择优。Tree of Thoughts 让模型在每个节点生成 k 个候选思路，然后评估、剪枝、回溯。Graph of Thoughts 更进一步，允许思路之间合并与引用。

这类方法在特定推理题上效果显著，但工程复杂度高，生产中用得相对克制。

5. Multi-Agent 协作范式

当一个循环内部的角色分化足够大时，把它们拆成多个 Agent 分别跑自己的 Loop，会比单 Agent 更容易稳定。典型的分工是：

• Planner：拆解任务
• Researcher：查资料
• Coder：写代码
• Reviewer：审代码
• Executor：跑代码、返回结果

这本质上是把一个大循环变成了多个小循环的编排。好处是每个 Agent 的职责单一，prompt 更好写；代价是需要一套消息总线/状态存储来协调。

五、从 ReAct 出发，手写一个最小 Agent

下面用 40 行 Python 写出一个能跑的 ReAct Agent。这不是展示用的玩具，而是很多生产 Agent 的最小实现，只要把工具接入就能干活。

def run_react(task: str, tools: dict, llm, max_steps: int = 8) -> str:
    history = [f"任务：{task}"]
    for step in range(max_steps):
        prompt = build_react_prompt(history, list(tools.keys()))
        reply  = llm(prompt)                              # 调模型

        thought = extract_tag(reply, "Thought")
        action  = extract_tag(reply, "Action")
        final   = extract_tag(reply, "FinalAnswer")

        if final:
            return final

        if not action:
            history.append(f"[第{step+1}步] Thought: {thought}（无 Action，跳过）")
            continue

        tool_name, args = parse_action(action)
        if tool_name not in tools:
            history.append(f"Observation: 未知工具 {tool_name}")
        else:
            obs = tools[tool_name](**args)                # 调工具
            history.append(f"Thought: {thought}\nAction: {action}\nObservation: {obs}")

    return "已达到最大步数，未能完成任务。"

这段代码里有三个工程要点：

1. 结构化输出：要求模型用 <Thought>、<Action>、<FinalAnswer> 包裹内容，然后用正则或 JSON 解析。让模型输出自由文本再去猜，是很多新手掉的第一个坑。
2. 工具错误回传：工具调用失败时，一定要把错误信息写回 Observation，让模型自己修。
3. 最大步数保护：任何循环都必须有硬上限，否则任务模糊时会无限烧 token。

六、状态管理：循环的脊梁

Loop 写起来不难，难的是状态管理。状态管理做不好，三轮之后 Agent 就失忆了。

一个 Agent 的状态通常至少包含：

• 任务描述（原始目标）
• 已执行步骤与结果
• 当前可用工具列表
• 短期记忆（最近 N 条 Observation）
• 长期记忆（向量库中检索到的片段）
• 运行预算（剩余 token / 剩余步骤 / 剩余花费）
• 失败原因与重试策略

状态管理中有两条经验规则值得直接抄：

规则一：状态必须可序列化。 把每一轮的完整状态（prompt、reply、工具返回）落盘或入库。生产中的 Agent 几乎都是"可回放"的——出问题时能把同一状态重新喂给模型，定位哪一步跑偏了。

规则二：短期记忆做滑动窗口，长期记忆做检索增强。 把最近 N 轮的完整对话塞进上下文；更早的内容只保留摘要或向量索引。窗口大小是一个需要根据任务调的超参数。

七、工具调用（Function Calling）工程要点

Loop Engineering 的另一半工作在"Act"阶段——工具调用。这里列几条被反复踩过的坑。

1. 工具描述要短、要准

工具的 description 不是写给人看的，是写给模型看的。它在每一轮都会被塞进上下文，写长了烧 token，写含糊了模型会选错工具。一个常见错误是把工具描述写成散文：

"这个工具可以帮你分析数据，支持多种查询方式，非常灵活……"

正确写法是命令式、带约束：

"输入员工编号，返回该员工指定月份的销售额（number）。参数：emp_id, yyyy-mm。"

2. 工具参数 Schema 要严格

参数能给 enum 的给 enum，能给正则的给正则，能给默认值的给默认值。模型对结构化 Schema 的理解能力远强于自然语言。

3. 工具失败要分类型返回给模型

工具调用失败至少分三类：

• 参数错：模型填的参数不合 Schema → 让模型重填。
• 权限 / 网络错：工具本身不可用 → 让模型换工具或放弃。
• 结果为空 / 无意义：工具正常返回但信息不足 → 让模型换查询方式。

把这三类失败用不同的 Observation 文本回传，模型的自修复能力会显著提升。

4. 同步工具优先，异步工具排队

大多数生产 Agent 不需要并行调用工具。并行让状态管理复杂度翻倍，调试也更难。除非有明确的性能要求，否则同步调用、一次一个工具，是最稳健的做法。

八、循环中的可靠性工程

可靠性是 Loop Engineering 和 Prompt Engineering 最大的分水岭。prompt 写得再好，跑十轮里只要有一轮工具调用崩溃，整个 Agent 就不可用。这里给一份可靠性检查清单：

1. 最大步数与超时

• 每个 Agent 必须有 max_steps（通常 8-20）
• 每个工具调用必须有超时（通常 10-30 秒）
• 每个 Agent 整体必须有超时（通常 3-10 分钟）

2. 模型重试

LLM 调用有一定概率失败（网络抖动、限流、内容审核）。对这类"软失败"需要做指数退避重试：

for attempt in range(max_retries):
    try:
        return llm(prompt)
    except RateLimitError:
        sleep(backoff(attempt))

3. 输出解析器容错

模型可能不按约定格式输出。解析失败时，不要直接抛错，而是把解析失败的信息作为 Observation 回传给模型，让它重新输出一次：

Observation: 未能解析 Action，格式应为 <Action>tool_name(arg=value)</Action>

4. 异常收敛策略

当 Agent 在多轮内没有产出新信息（重复调用同样的工具、返回同样的结果），应主动标记"疑似卡死"，并触发：

• 降低温度重新推理
• 切换备用模型
• 人工介入（返回给用户一个不完整结果，让用户决定是否继续）

九、成本控制：别让 Agent 把预算跑空

一个被忽视的事实：Agent 的成本往往不是推理本身，而是循环次数 × 上下文长度。一个 10 轮、每轮 16k 的 Agent，成本是单次 16k 的 10 倍以上，因为每轮都要把前面的历史重传一次。

三条实用措施：

1. 压缩历史：超过 N 轮的历史交给摘要模型或直接截断，只保留最近 k 条高价值 Observation。
2. 预算监控：在循环外层维护一个 token / 费用计数器，超过阈值即停止并返回当前结论。
3. 模型分层：简单步骤用轻量模型（Llama 3-8B、Qwen2.5-7B），复杂步骤才调用强模型（GPT-4、DeepSeek-V3、Claude）。按任务挑模型，成本可以差一个数量级。

十、可观测性：Agent 必须可调试

写了一个 Agent，跑起来 5% 的任务失败——这 5% 发生在哪一步？没有日志，你就只能猜。

可观测性的最低标准是：每一轮的完整状态都能回放。具体来说，每一轮都要记录：

• 输入给模型的完整 prompt（含系统提示、历史、工具 Schema）
• 模型返回的完整原文
• 解析后的结构化结果（Thought / Action / Observation）
• 工具调用的输入与输出（含耗时、错误栈）
• 本轮 token 消耗与累计 token

这些数据能让你像看单步调试一样，回看一个失败任务的每一步。真正做生产 Agent 的团队，一半的代码是干这个的。

十一、什么时候不该用 Loop

Loop 不是银弹。下面这些场景，用 Loop 反而更差：

• 简单问答：用户问"1+1 等于几"，一次返回就行。
• 低延迟交互：Chat 场景下用户能接受的延迟通常在 2-3 秒以内，多轮循环会让体验崩掉。
• 确定性任务：如果一个任务可以用规则引擎、SQL、脚本完成，就不要让 LLM 参与决策。LLM 应该用在"需要判断"的那一步，而不是替代整个流程。

一条判断标准：如果你能在一条 prompt 里把任务讲清楚、模型能一次输出对的结果——那它不值得一个 Loop。Loop 是为"一次做不好"的任务准备的。

十二、架构模式：从单循环到多 Agent

当单个 Agent 的职责开始膨胀时，自然会演化出多 Agent 结构。下面是三种常见的组织形态：

1. 线性编排（Pipe）

每一步是一个独立的 Agent / 模块。结构简单，适合流水线类任务。

2. 主管-工人（Supervisor-Worker）

主管负责拆解、分派、汇总；工人各自做自己擅长的事。这是最常见的多 Agent 形态。

3. 事件总线（Event Bus）

各 Agent 通过消息队列通信，松耦合，适合复杂协作场景。工程复杂度最高，不到万不得已不建议用。

十三、一个真实案例：代码修复 Agent

下面看一个最小但能跑的代码修复 Agent 的流程。这个案例可以帮你把前面讲的内容串起来。

任务：给定一段 Java 代码和一个编译错误，让 Agent 自行修复。

这个结构里，最值钱的不是"生成修复"那一步，而是"编译验证 → 错误回传 → 再生成"这个循环。没有这个循环，Agent 生成的补丁一半以上是编不过的。加上这个循环，修复率通常能从 40% 升到 80% 以上。

十四、评估：你的 Loop 到底好不好

做 Agent 不做评估，等于做产品不做监控。评估的三个层面：

1. 单步评估

对每一轮 LLM 的输出做规则校验：格式是否合法？工具是否存在？参数是否匹配 Schema？这是最低门槛。

2. 任务成功率

给一批代表性任务（golden set），统计最终成功率。注意：成功率不是"答对的比例"，而是"用户预期完成的比例"。一个 Agent 在 100 个任务上 80% 成功、20% 优雅失败，远好于 90% 成功、10% 胡说八道。

3. 成本-准确率曲线

同样的任务，跑 3 轮和跑 10 轮的准确率差多少？成本差多少？找到曲线上的甜点。大多数团队的甜点在 3-6 轮之间。

十五、写在最后：Loop Engineering 的几个判断

最后分享三条我自己在工程中反复确认的判断：

判断一：Loop 比模型更值钱。 在很多生产场景下，一个中等模型 + 精心设计的 5 轮循环，表现优于最强模型的单次输出，而且便宜。如果你还在追"最大模型"，建议同时追"最好循环"。

判断二：可观测性是 1，其他是 0。 没有回放能力的 Agent 系统是黑盒。黑盒坏了修不了，修不了就上不了线。先把日志、状态、回放做扎实，再谈效果。

判断三：简单优先。 能单轮解决的不要做两轮，能单 Agent 解决的不要做多个。每多一层循环、每多一个 Agent，状态空间翻倍、调试成本翻倍。简单的东西先跑起来，再按需复杂化。

Loop Engineering 还很年轻，没有统一标准，也没有"一本书写全"的最佳实践。它更像 2010 年前后的前端工程化——大家都在踩坑、抄作业、再踩坑。但它解决的问题是真实的：让 LLM 从"会说话"走向"会做事"。这件事值得花时间认真做。