为什么你的 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-ExecuteLangChain 在 2023 年提出并实现了这个模式[2],灵感来自 Plan-and-Solve Prompting 和 BabyAGI 项目。先让 LLM 生成一个完整的多步骤计划,再逐步执行。优势:规划集中做一次,执行阶段不用每步都重新推理,Token 成本可控。但计划一旦不靠谱,后面全完——所以必须加Replan(重规划)机制,允许执行到某步发现不对时回头改计划。ReflexionShinn 等人 2023 年提出[3]。核心思路是:执行完一轮后,让 LLM 对结果做语言化的自我反思,把反思存进 Episodic Memory,下一轮试错时参考——不更新权重,靠反思笔记来积累经验。论文报告在 HumanEval 编码任务上 pass1 达到 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_size5): self.working deque(maxlenworking_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, k5) return assemble( factsrelated, episodesself.episodic[-10:], workinglist(self.working), queryquery, )核心逻辑:最近的原文留着,稍远的压缩成摘要,很久以前只保留关键事实。这样上下文长度大致可控,关键信息又不丢。几个容易踩的坑摘要丢骨架信息: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(backoffexponential, max3) elif error.is_recoverable(): # 可降级:切换备用模型/工具 return FallbackStrategy(alternativeself.find_alt(action)) else: # 致命:权限不足、参数非法、依赖缺失 return EscalateStrategy(targethuman)三类失败,三种处理:临时性→ 指数退避重试。别傻等,也别狂刷。可降级→ 换一条路走。搜索引擎 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 站内私信通知,书由出版社直接寄出。