Loop Engineering 完全指南：从单次问答到持续决策循环

当 Prompt Engineering 仍在探索“如何写出更精准的提示”时，一种更为底层的工程范式已悄然成型。它并非由某家巨头发布，而是自 2023 年以来，在 Agent 工程实践中逐步沉淀形成的方法论。其核心议题是：如何让 LLM 从一个“单次问答机”进化成一个能够自主运行、持续迭代的“闭环决策系统”。本文将系统性地拆解这一范式的内涵、结构、实践与挑战，帮助你全面掌握这一前沿技术。

一、什么是 Loop Engineering

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

具体而言，一个智能体接收任务后，并非一次性输出答案，而是在一个结构化的循环中反复执行“观察 → 思考 → 决策 → 行动 → 再观察”的过程，直至满足终止条件。在这个循环中，每一步都可能调用工具、查询外部知识、反思自身判断，甚至将子任务委托给其他智能体。

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

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

前者关注一条 prompt 写得是否清晰，后者关注一条链路能否顺利闭环。

小提示： 你可以把 Prompt Engineering 想象成“如何写出更清晰的指令”，而 Loop Engineering 则是“如何设计一个能自动执行指令、并在遇到问题时自我修复的系统”。

二、为什么需要引入循环

任何从事 LLM 落地工作的人都会遇到三个瓶颈，这正是 Loop 成为必然选择的原因：

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

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

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

一个最小可用的循环由三个阶段组成，它并非新发明，而是源自控制论中的经典反馈环，与强化学习中的 Agent-Environment 交互结构一致。

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

在 LLM 的语境下，这个环被重新表述为：

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

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

下面是一个最简单的伪代码，它几乎是所有 Agent 框架的骨架：

def react_loop(task, tools, llm):
    state = {"task": task, "history": []}
    for step in range(max_steps):
        observation = observe(state)                  # 收集当前状态
        decision = think(observation)                  # LLM 推理并选择 Action
        if decision.is_final():                             # 是否给出最终答案
            return decision.result
        state = act(state, decision)                   # 执行 Action 并更新状态
    return "未完成"

四、经典循环范式比较

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

1. ReAct 范式（Reasoning + Acting）

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

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

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

2. Plan-and-Execute 范式

这个范式将循环拆成两层：外层规划器输出一个步骤清单（Plan），内层执行器按 Plan 逐项执行，失败时回传重新规划。它非常适合任务结构相对明确的场景，如代码生成、数据分析、文档整理。LangGraph 中的“Plan-and-Execute”就是典型实现。

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

3. Reflexion / Self-Reflection 范式

此范式的核心是在 Action 之后加入一个 Review 步骤，由同一个或另一个模型对产出进行打分和批评，然后将意见反馈回循环中重做。很多人低估了 Reflexion 的价值。在写作、代码修复、长文档摘要等任务上，一个 2-3 轮的反思循环，效果往往优于直接使用更强的模型单次输出，且成本更低。

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

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，它实现简单，是所有复杂范式的基础。
• 步骤多变、需要动态调整：选用 Plan-and-Execute，它能更好地处理任务中途变更的情况。
• 对输出质量要求极高：应使用 Reflexion，通过自我批判机制提升最终产物质量。
• 推理逻辑复杂、路径模糊：考虑 Tree/Graph of Thoughts，但需评估其高昂的工程成本。
• 任务角色分化明显：采用 Multi-Agent 协作，让每个 Agent 各司其职。

五、实践：手写一个最小 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. 结构化输出：要求模型使用 , , 等标签包裹内容，然后用正则或 JSON 解析。这是避免新手掉坑的有效手段。
2. 工具错误回传：工具调用失败时，务必将错误信息写回 Observation，让模型自己修正。
3. 最大步数保护：任何循环都必须有硬上限，否则任务模糊时会无限消耗 token。

常见问题：Agent 陷入了无限循环或重复操作怎么办？

除了设置max_steps外，还可以实施“异常收敛策略”。当 Agent 在多轮内重复调用同一工具或返回相同结果时，应主动标记“疑似卡死”。此时可采取以下措施：降低模型温度、切换备用模型，或向用户返回一个不完整结果，请求人工介入。

六、核心挑战：状态管理与循环可靠性

Loop 写起来不难，真正的难题在于状态管理。状态管理做不好，三轮之后 Agent 就会“失忆”。

状态管理：循环的脊梁

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

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

状态管理中有两条经验规则：

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

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

小提示： 状态管理的可观测性是 Agent 系统的核心。最低标准是：每一轮的完整状态都能回放。这意味着每一轮都要记录输入模型的完整 prompt、模型返回的原文、解析后的结构化结果、工具调用的输入与输出（含耗时与错误栈），以及本轮 token 消耗。

循环中的可靠性工程

可靠性是 Loop Engineering 和 Prompt Engineering 最大的分水岭。一个可靠的循环系统应包含以下检查清单：

1. 最大步数与超时：
   • 每个 Agent 必须有 max_steps（通常 8-20）。
   • 每个工具调用必须有超时（通常 10-30 秒）。
   • 每个 Agent 整体必须有超时（通常 3-10 分钟）。
2. 模型重试：对 LLM 调用的软失败（网络抖动、限流等）做指数退避重试。
3. 输出解析器容错：模型可能不按约定格式输出。解析失败时，不要直接抛错，而是将解析失败的信息作为 Observation 回传给模型，让其重新输出一次。
4. 异常收敛策略：当 Agent 多轮无进展时，应主动触发降级方案（如降低温度、切换模型或请求人工介入）。

七、成本控制与时机判断

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

一个被忽视的事实是：Agent 的成本大头往往不是推理本身，而是循环次数 × 上下文长度。一个 10 轮、每轮 16k 的 Agent，其成本远高于 10 次单独的 16k 调用，因为每轮都要将前面的历史重传一次。

三条实用措施：

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

什么时候不该用 Loop

Loop 并非万能。在以下场景中，使用 Loop 效果可能更差：

• 简单问答：用户问“1+1 等于几”，一次返回即可。
• 低延迟交互：Chat 场景下用户能接受的延迟通常在 2-3 秒以内，多轮循环会严重损害体验。
• 确定性任务：如果一个任务可以用规则引擎、SQL、脚本完成，就不要让 LLM 参与决策。

一条简单的判断标准是：如果你能用一条 prompt 把任务讲清楚，且模型能一次性输出正确结果，那它就不值得一个 Loop。Loop 是为那些“一次做不好”的任务准备的。

八、工具调用的工程要点

Loop Engineering 的另一半工作在“Act”阶段——工具调用。以下是几条经过反复验证的经验总结。

1. 工具描述要短、要准：工具的 description 是写给模型看的。它应在每一轮都被塞进上下文，因此要采用命令式、带约束的写法，避免散文。
2. 工具参数 Schema 要严格：参数能给 enum 就给定，能给正则就给正则，能给默认值就给。模型对结构化 Schema 的理解能力远强于自然语言。
3. 工具失败要分类型返回：工具调用失败至少分为三类：
   • 参数错：模型参数不合 Schema → 让模型重填。
   • 权限/网络错：工具本身不可用 → 让模型换工具或放弃。
   • 结果为空/无意义：工具返回信息不足 → 让模型换查询方式。
   将这三类失败用不同的 Observation 文本回传，模型的自修复能力会显著提升。
4. 同步工具优先，异步工具排队：除非有明确的性能要求，否则同步调用、一次一个工具，是最稳健的做法，可以避免状态管理的复杂度翻倍。

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

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

1. 线性编排（Pipe）

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

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

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

3. 事件总线（Event Bus）

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

十、如何评估你的 Loop

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

1. 单步评估：对每一轮 LLM 的输出做规则校验（格式、工具存在性、参数匹配等）。这是最低门槛。
2. 任务成功率：给一批代表性任务（golden set），统计最终成功率。注意，成功率不是“答对的比例”，而是“用户预期完成的比例”。一个 Agent 在 100 个任务上 80% 成功、20% 优雅失败，远好于 90% 成功、10% 胡说八道。
3. 成本-准确率曲线：对同一任务，测试不同轮数（如 3 轮、5 轮、10 轮）的准确率和成本，找到曲线上的甜点（通常为 3-6 轮）。

十一、结语与判断

最后，分享几条在工程实践中反复验证的判断：

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

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

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

Loop Engineering 还很年轻，没有统一的标准与最佳实践。它更类似于 2010 年前后的前端工程化——大家都在踩坑、抄作业、再踩坑。但它要解决的问题是真实且重要的：让 LLM 从“会说话”走向“会做事”。这件事值得花时间认真对待。