当 Prompt Engineering 还在讨论如何写好一条提示时，Loop Engineering 已经在讨论如何让系统自己跑起来。Loop Engineering 不是一个新词，也不是某个巨头发布的框架，它是自 2023 年以来在 Agent 工程实践中逐步沉淀出来的一套方法论。本文试图把这件事讲透。
一、什么是 Loop Engineering
Loop Engineering 的核心命题只有一句话：把 LLM 从"单次问答机"改造为"持续决策循环" 。
具体而言：一个智能体拿到一个任务后，不是一次性输出答案，而是在一个结构化的循环中反复执行"观察—思考—决策—行动—再观察"的过程，直到满足终止条件。这个循环中，每一步都可能调用工具、查询外部知识、反思自己的判断，甚至把任务拆给另一个智能体。
它区别于 Prompt Engineering 的关键点在于：
- Prompt Engineering 优化的是"单次调用的输出质量"。
- Loop Engineering 优化的是"多次调用的整体成功率"。
前者关心一条 prompt 写得好不好，后者关心一条链路能不能闭环。
二、为什么 Loop 是必须的
任何做过 LLM 落地的人都会遇到三个瓶颈：
- 上下文窗口有限：长任务必须切片处理，切片就带来状态管理问题。
- 单次推理不可靠：一个模型在单步回答中的准确率可能只有 70%，但如果给它三次自检机会，准确率可以升到 95% 以上。
- 需要与外部系统交互：查数据库、调 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 "已达到最大步数，未能完成任务。"
这段代码里有三个工程要点：
- 结构化输出：要求模型用
<Thought>、<Action>、<FinalAnswer>包裹内容，然后用正则或 JSON 解析。让模型输出自由文本再去猜，是很多新手掉的第一个坑。 - 工具错误回传：工具调用失败时，一定要把错误信息写回 Observation，让模型自己修。
- 最大步数保护：任何循环都必须有硬上限，否则任务模糊时会无限烧 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 倍以上，因为每轮都要把前面的历史重传一次。
三条实用措施：
- 压缩历史：超过 N 轮的历史交给摘要模型或直接截断，只保留最近 k 条高价值 Observation。
- 预算监控：在循环外层维护一个 token / 费用计数器，超过阈值即停止并返回当前结论。
- 模型分层：简单步骤用轻量模型（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 从"会说话"走向"会做事"。这件事值得花时间认真做。
