为什么你的 Agent 总是跑着跑着就废了?聊聊 Loop 设计里那些坑（文末赠书）
"我的 Agent Demo 跑得挺顺的,一上生产就各种出问题。"
这句话我在不同场合听过太多次了。包括我自己最早写 Agent 的时候也是这样——一个简单的 ReAct 循环,本地测得好好的,放到真实场景里不是上下文爆了就是死循环,偶尔还给你来个"无限重试把 API 额度刷光"的惊喜。
后来花了不少时间梳理 Agent Loop 设计这块的东西,从范式选择到上下文管理到失败处理,踩了一些坑也想明白了一些事。这篇把这些整理出来,希望能帮你少走点弯路。
文中涉及的代码和场景均为示意性示例,用于说明设计思路。
一、先说 Loop 范式:ReAct 不是万能的
ReAct(Yao et al., 2022)是最经典的 Agent Loop 范式[1],核心很简单:
Thought → Action → Observation → Thought → Action → ...入门写 Agent,基本都从 ReAct 开始。但当你真拿它去做稍微复杂一点的任务,很快就会发现几个问题:
1. 它是贪心的。每一步的决策只看上一步的 Observation,没有全局规划。任务一复杂,Agent 就容易在某个分支上越走越偏,撞墙了也不知道回头。
2. Token 烧得快。每一步都把完整的 Thought-Action-Observation 历史塞回 Prompt,跑到第 10 步上下文就快满了。
3. 出错后容易雪崩。中间某一步 Action 失败,Agent 拿到一个错误的 Observation,后面的推理就全歪了。
所以 ReAct 适合短链路、确定性高的简单任务。面对更复杂的场景,通常需要别的范式来补:
Plan-and-Execute
LangChain 在 2023 年提出并实现了这个模式[2],灵感来自 Plan-and-Solve Prompting 和 BabyAGI 项目。先让 LLM 生成一个完整的多步骤计划,再逐步执行。
优势:规划集中做一次,执行阶段不用每步都重新推理,Token 成本可控。但计划一旦不靠谱,后面全完——所以必须加Replan(重规划)机制,允许执行到某步发现不对时回头改计划。
Reflexion
Shinn 等人 2023 年提出[3]。核心思路是:执行完一轮后,让 LLM 对结果做语言化的自我反思,把反思存进 Episodic Memory,下一轮试错时参考——不更新权重,靠"反思笔记"来积累经验。
论文报告在 HumanEval 编码任务上 pass@1 达到 91%[3]。但有个前提:任务得有明确的成败信号(比如代码能不能跑通)。缺乏客观反馈的开放任务上,反思的可靠性就成了问题——你让一个犯错的人反思自己为什么犯错,他反思出来的东西未必靠谱。
多 Agent 分工
把规划和执行拆给不同的 Agent,上层做调度、下层做执行,Agent 之间通过消息协作。Wang 等人在综述中对这种模式有较系统的归纳[4]。
工程上的实际选择
说句实在话:没有哪个范式是银弹。真实项目里通常是混着用:
- 简单查询 → ReAct,够用
- 多步骤任务 → Plan-and-Execute + Replan
- 代码生成、数学推理等可验证场景 → 加 Reflexion 做自校验
- 复杂协同 → 多 Agent 分工
关键不是"选哪个范式",而是根据任务特征做取舍。
二、上下文管理:Agent 跑久了脑子会炸
Loop 跑得越久,上下文越容易膨胀。这是一个非常工程化的问题——直接截断会丢关键信息,不截断又超出窗口。
分层管理
一种在工程实践中被广泛参考的思路,概念上借鉴了认知心理学中工作记忆与长期记忆的区分[5]:
- 近期原文(Working Memory):最近几轮对话完整保留,确保 LLM 有足够的局部上下文
- 中期摘要(Episodic Memory):更早的对话压缩成事件级摘要,保留"做了什么、结果怎样、状态变了什么"
- 长期事实(Semantic Memory):从摘要中析出的稳定事实,存到向量库或 KV 存储,按需检索
需要说明的是,"Working/Episodic/Semantic"这个三层命名不是行业标准,不同框架有各自的术语。这里只是为了讨论方便做的一种抽象。
伪代码示意
class ContextManager: """示意性实现,仅用于说明分层管理的设计思路""" def __init__(self, working_size=5): self.working = deque(maxlen=working_size) # 近期原文 self.episodic = [] # 中期摘要 self.semantic_store = SemanticStore() # 长期事实 def add(self, turn): # 工作记忆满了,最老的一轮做摘要后降级 if len(self.working) == self.working.maxlen: evicted = self.working[0] episode = self.summarize(evicted) self.episodic.append(episode) self.extract_facts(episode) self.working.append(turn) def build_prompt(self, query): # 从长期事实库检索相关内容 related = self.semantic_store.search(query, k=5) return assemble( facts=related, episodes=self.episodic[-10:], working=list(self.working), query=query, )核心逻辑:最近的原文留着,稍远的压缩成摘要,很久以前只保留关键事实。这样上下文长度大致可控,关键信息又不丢。
几个容易踩的坑
- 摘要丢骨架信息:LLM 做摘要时倾向于保留叙事,丢掉数字、ID、时间戳这些"骨架"。可以在摘要前先把关键实体抽出来单独存,再让 LLM 处理叙事部分。
- 向量检索召回不稳:直接拿原始 Query 去向量库搜,经常搜不到想要的事实。常见做法是先让 LLM 做一次 Query 改写,生成几个不同角度的检索意图,并行搜索再合并去重。
- 工具返回值太大:一次工具调用可能返回几千 Token 的结果,全塞上下文就爆了。可以只保留"结果摘要 + 引用 ID",需要原文时按 ID 回查。
三、终止条件:别只靠 max_steps
很多教程里终止条件就是一行if step > max_steps: break。Demo 阶段够了,但生产环境这样做会漏掉大量本可以更优雅处理的信号。
一个相对完整的终止判断应该覆盖多个维度:
| 维度 | 触发条件 | 处理方式 |
|---|---|---|
| 任务完成 | LLM 输出"完成"标记 | 进入结果汇总 |
| 步数上限 | step ≥ max_steps | 强制中止 + 摘要返回 |
| 时间上限 | duration ≥ max_time | 强制中止 + 摘要返回 |
| 死循环检测 | 相同 Action 连续出现 N 次 | 触发 Replan 或上报 |
| Token 预算 | total_tokens ≥ budget | 压缩上下文或终止 |
| 不可恢复错误 | 关键 Action 抛出致命异常 | 停止并上报人工 |
尤其要注意最后一行——Agent 在遇到权限拒绝后反复尝试绕路是最灾难的情况之一。日志刷得又快又乱,关键是它还不会停。正确做法是:不可恢复的错误,早停,把决策权交回给人。
失败分类
class FailureHandler: """示意性分类,具体策略需结合业务""" def handle(self, action, error): if error.is_transient(): # 临时性:网络抖动、限流、超时 return RetryStrategy(backoff="exponential", max=3) elif error.is_recoverable(): # 可降级:切换备用模型/工具 return FallbackStrategy(alternative=self.find_alt(action)) else: # 致命:权限不足、参数非法、依赖缺失 return EscalateStrategy(target="human")三类失败,三种处理:
- 临时性→ 指数退避重试。别傻等,也别狂刷。
- 可降级→ 换一条路走。搜索引擎 A 不可用就用搜索引擎 B,主模型超载就切备用模型。
- 致命→ 别挣扎了,上报。让 Agent 在权限被拒后疯狂尝试绕路,是最浪费 API 额度的行为。
状态持久化
如果你的 Agent 需要跑超过几分钟的任务,必须支持从中断点恢复。否则一次网络抖动、一次进程重启,用户等了半小时的结果全没了。
最小可行方案:每完成一个 Action,把(step_id, state_snapshot, decision_log)写一次持久化存储。重启时按 step_id 倒序找最近的有效快照恢复。代价是每次 Action 后的 IO 开销,以及 State Snapshot 的序列化复杂度——LLM 返回的非结构化内容不太容易干净地序列化,这块需要单独设计。
四、一张 Checklist
把上面说的收成一张表,方便自查:
| 检查项 | 你的 Agent 做了吗 |
|---|---|
| Loop 范式按任务特征选择,而非一律 ReAct | |
| 有 Replan 或重规划机制 | |
| 上下文做了分层管理(不是一股脑全塞) | |
| 摘要前先提取关键实体,避免丢骨架信息 | |
| 终止条件覆盖多个维度,不只有 max_steps | |
| 有死循环检测(相同 Action 连续出现) | |
| 失败分三类:临时/可降级/致命,分别处理 | |
| 致命错误早停上报,不让 Agent 乱试 | |
| 长任务支持状态持久化与断点恢复 |
如果全打了勾,你的 Agent 至少在工程层面已经比大多数 Demo 级实现靠谱了。
五、参考
[1] Yao, S. et al. (2022).ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629. https://arxiv.org/abs/2210.03629
[2] LangChain Blog (2023).Plan-and-Execute Agents. https://www.langchain.com/blog/plan-and-execute-agents
[3] Shinn, N. et al. (2023).Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366. https://arxiv.org/abs/2303.11366
[4] Wang, L. et al. (2024).A Survey on Large Language Model based Autonomous Agents. arXiv:2308.11432. https://arxiv.org/abs/2308.11432
[5] Atkinson, R. C. & Shiffrin, R. M. (1968).Human memory: A proposed system and its control processes. Psychology of Learning and Motivation, 2, 89-195.
顺便提一句,最近翻了本《OpenClaw觉醒:基于AI智能体的超级生产力构建指南》(人民邮电出版社),作者是业界的艾长青（@acedar）和吴家迪。目录里第 3 章对 Agent 生命周期、上下文管理、多智能体路由有展开讨论,第 4 章涉及沙箱与安全模型,和本文的几个话题有交集。手边刚好有几本样书,抽一位送出去。
送书福利
抽 1 本《OpenClaw觉醒:基于AI智能体的超级生产力构建指南》。
参与方式:
- 关注我的 CSDN 账号
- 评论区聊聊你写 Agent 遇到过最头疼的问题是什么?
我会从评论里挑 1 位送出。
【活动截止日期】5月27日
中奖结果在截止后一周内公布,通过 CSDN 站内私信通知,书由出版社直接寄出。