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 从“会说话”走向“会做事”。这件事值得花时间认真对待。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：循环工程：从提示工程到迭代式智能体工程要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题