Agent 为什么会循环？如何规划并避免无限执行
内容摘要：Agent 的"自主性"来自一个循环：决策→行动→观察→再决策。本章讲循环的结构与停止条件，对比 ReAct、Plan-and-Execute、反思、路由等规划模式，并给出带上限的可运行循环骨架。 难度：进阶 | 前置知识：06 工具调用
常见误区
给 Agent 加上 Reflection 或更复杂的规划器，就会自然得到更正确的结果，不需要额外停止条件。
先给结论
Agent 的自主性来自“决策 → 行动 → 观察”的循环，而可靠性来自循环之外的硬约束。ReAct、Plan-and-Execute、Reflection 和 Routing 只是不同决策模式，都必须受最大步数、预算、重复检测和终止状态控制。
带着这三个问题阅读：
- 每轮循环的输入、动作、观察和状态如何变化？
- ReAct、Plan-and-Execute、Reflection 与 Routing 分别适合什么任务？
- 哪些信号可以证明 Agent 已完成、卡住或应该转人工？
一、Agent Loop 的结构
停止条件（必须显式设计）：达成目标、达到最大步数、超出成本/时间预算、连续失败、需要人工介入。没有停止条件的循环会刷步数、烧钱、甚至死循环。
二、规划模式对比
| 模式 | 思路 | 适合 | 局限 |
|---|---|---|---|
| ReAct（Reason+Act） | 边想边做，每步产出"思考+动作" | 探索性、步骤不确定 | 可能兜圈，需步数上限 |
| Plan-and-Execute | 先出完整计划，再逐步执行 | 步骤较清晰、需可审查计划 | 计划可能过时，需重规划 |
| 反思（Reflection） | 对结果自评并改进 | 质量要求高的产出 | 增加成本与延迟 |
| 路由（Routing） | 先分类，再分派到子 Agent/工具 | 多领域、多工具 | 路由错误会连锁 |
不要迷信复杂模式：多数任务用"ReAct + 最大步数 + 好工具"就够。反思、多计划器会显著增加成本，仅在评测证明有收益时引入。
三、可运行的循环骨架（带停止条件与预算）
在 06 的 run_agent 基础上，补充预算与连续失败熔断：
from dataclasses import dataclass
@dataclass
class LoopBudget:
max_steps: int = 6
max_tool_errors: int = 3 # 连续失败上限（熔断）
max_tokens_total: int = 20000 # 粗略 Token 预算
def run_agent_with_budget(client, goal: str, budget: LoopBudget):
messages = [{"role": "system", "content": "只读排障助手，遵守停止条件。"},
{"role": "user", "content": goal}]
consecutive_errors = 0
tokens_used = 0
for step in range(1, budget.max_steps + 1):
decision = client.decide(messages)
tokens_used += 200 # 示例：真实应累计 usage（见 17）
if tokens_used > budget.max_tokens_total:
return {"status": "budget_exceeded", "step": step}
if decision.get("action") == "final":
return {"status": "ok", "answer": decision.get("answer", ""), "step": step}
# ...此处复用 06 的校验+执行逻辑...
ok = decision.get("_mock_ok", True) # 演示占位
if not ok:
consecutive_errors += 1
if consecutive_errors >= budget.max_tool_errors:
return {"status": "circuit_open", "step": step} # 熔断停止
else:
consecutive_errors = 0
return {"status": "max_steps"}停止条件覆盖：ok（完成）、max_steps、budget_exceeded、circuit_open。每条都返回明确状态，便于观测与告警。
四、任务分解与子任务
复杂目标可先分解为子任务（由模型产出结构化计划，03 的结构化输出），再逐个执行。分解结果应：可校验、可跟踪状态（09）、失败可局部重试（15）。
五、失败路径
- 无限循环/兜圈：缺停止条件或工具反馈不足。→ 步数上限 + 熔断。
- 计划僵化：Plan-and-Execute 不重规划，环境变化后仍按旧计划。→ 加"偏差检测→重规划"。
- 路由误判：分类错误把请求发错子系统。→ 路由也要测试与兜底（16）。
六、测试与验证
- 用脚本化模型（06 的
ScriptedModel）构造：正常收敛、兜圈、连续失败、超预算，断言最终status正确。 - 记录每次运行的步数分布，识别"经常打满步数"的坏 case。
七、安全与权限
八、性能与成本
- 循环步数 × 每步 Token ≈ 成本上界。步数上限、预算、缓存是主要控制手段（18）。
九、框架差异
- LangGraph（1.0）用图显式表达循环与条件边；LangChain
create_agent（1.0）内置标准 ReAct 式循环；OpenAI Agents SDK 有自己的 run loop。抽象不同，但"停止条件、校验、预算"都得你来把关。
十、关联章节
- 下一章：09 工作流与状态管理 相关：12 多 Agent、15 可靠性
面试复述
Agent Loop 让模型依据工具结果调整下一步，但每多一轮都增加成本和风险。规划模式应按任务结构选择，并用最大步数、预算、重复调用检测与明确终止状态防止失控。
复述时先给结论，再补机制、适用边界和一个可验证指标；不要只罗列框架名称或产品功能。
迁移练习
为一个排障 Agent 定义 success、failed、budget_exceeded、needs_human 四种终止状态，并设计一条重复调用检测规则。
检索关键词
Agent Loop 停止条件 ReAct Plan-and-Execute 反思 Reflection 路由 Routing 最大步数 熔断
官方来源
- ReAct、Reflexion 等论文原文；各框架 agent loop 文档（
verified_at: 2026-09-07）。