Agent系统开发的六个深坑从无限循环到工具调用失败的工程教训2025年以来Agent从概念验证进入生产落地阶段。但当Agent系统真正跑在线上时开发者发现Demo中流畅的多步推理到了生产环境变成了无限循环、状态丢失和成本爆炸。本文基于实战经验拆解Agent开发中最常见的六个陷阱。一、Agent系统的基本架构和故障面Agent系统通常由四个核心组件构成LLM推理引擎、工具调用层、记忆管理模块、任务编排器。故障可以发生在任一组件而最棘手的是跨组件的级联故障——一个工具调用超时触发LLM重新规划重新规划又触发更多工具调用形成恶性循环。二、六个深坑逐一拆解深坑一无限反思循环——Agent陷入思考→行动→思考→行动的死锁现象Agent执行任务时不断重复让我再想想...和我来检查一下...永远到达不了终点。一个简单的查询订单状态任务消耗了200轮LLM调用。根因Agent缺乏明确的终止条件判断。反思Reflection机制本意是提高输出质量但缺少退出策略时Agent会陷入过度优化的循环——对已经正确的中间结果反复修正。预防措施设置硬性步数上限如最多10轮推理超出后强制输出当前结果实现收益递减检测连续3轮反思后输出质量无显著提升自动终止使用专门的终止评估器在每轮推理后判断当前信息是否足以回答用户问题对简单查询类任务关闭反思机制仅对复杂推理任务启用修复示例class LoopDetector: def __init__(self, max_iterations10, stagnation_threshold3): self.max_iterations max_iterations self.stagnation_threshold stagnation_threshold self.recent_outputs [] def should_continue(self, iteration, current_output): if iteration self.max_iterations: return False, 达到最大迭代次数 self.recent_outputs.append(hash(current_output)) if len(self.recent_outputs) self.stagnation_threshold: self.recent_outputs.pop(0) if len(set(self.recent_outputs)) 1: return False, 连续多轮输出无变化 return True, None深坑二工具调用超时无处理——Agent挂起等待一个永不返回的API现象Agent调用外部API查询数据API响应超时但Agent没有超时处理机制整个任务卡住。根因Agent的工具调用层缺少超时和重试策略。LLM本身无法感知工具调用的阻塞状态——它只是等待工具返回结果。预防措施每个工具调用设置独立超时建议3-30秒根据工具特性调整实现优雅降级工具超时后返回结构化错误信息给LLM让LLM决策是重试还是跳过全局任务设置总超时如60秒超出后强制返回部分结果为关键工具准备降级方案主API超时→缓存→默认值深坑三状态丢失——多轮对话中Agent忘记了之前做了什么现象Agent在第3轮确认了用户的手机号第6轮又问了一遍。根因Agent的记忆管理存在两种常见问题一是上下文窗口有限导致早期信息被截断二是中间推理状态如已确认的信息、已排除的选项没有持久化。预防措施区分短期记忆当前任务上下文和结构化状态已确认的事实、任务进度将关键中间状态写入外部存储Redis/数据库而非依赖LLM的上下文窗口在每轮推理前注入任务摘要总结当前已完成的步骤、已确认的信息、待完成的事项实现记忆压缩当上下文接近窗口上限时对历史对话做摘要后替换原始文本深坑四Prompt膨胀——每次加一句注意三个月后Prompt变成论文现象Agent的System Prompt从最初的200字膨胀到3000字包含大量补丁式指令注意不要忘记确认用户身份如果用户说不需要就跳过……根因Agent系统的Prompt缺乏版本管理和精简机制。每次发现一个新问题就追加一条指令但从不清除冗余或冲突的旧指令。这种Prompt债务的利息就是推理质量下降和Token消耗增加。预防措施建立Prompt版本管理每次修改记录原因、预期效果、实际效果每月做Prompt精简日删除不起作用的指令、合并重复约束、重写混乱段落将Prompt分为核心指令区不可变和场景指令区按需注入对长Prompt做注意力测试将关键指令放在Prompt中间测试模型是否仍遵守深坑五多Agent死锁——你等我的输出我等你的确认现象两个Agent协同完成任务Agent A负责收集信息Agent B负责分析。结果Agent A等Agent B确认还需要什么信息Agent B等Agent A提供有哪些信息可用——双方陷入死锁。根因多Agent系统缺少明确的通信协议和超时机制。Agent之间的依赖关系形成了环形等待。预防措施设计明确的Agent通信协议定义消息类型请求、响应、确认、取消、超时和重试规则引入编排者Orchestrator模式由中心Agent协调子Agent避免点对点环形依赖为Agent间通信设置超时等待超时后执行预设的默认行为实现死锁检测监控Agent间消息传递图发现环路自动告警深坑六成本爆炸——一个简单查询消耗了50次LLM调用现象用户问今天天气怎么样Agent经过规划→反思→工具调用→再反思→总结共消耗了15次LLM调用其中12次与最终答案无关。根因Agent的推理开销与任务复杂度不成比例。简单任务也走完整推理链路导致大量Token浪费在无效的思考中。预防措施实现任务分级简单查询直接路由到基础模型复杂任务才启用Agent链路设置Token预算每个任务预设Token上限如10K达到上限时强制输出使用小模型做规划大模型做生成——规划阶段用小模型成本低生成阶段用大模型质量高监控每次Agent调用的Token消耗建立成本可观测性三、Agent系统的工程化检查清单在Agent上线前逐项检查检查项合格标准验证方法步数上限任何任务≤20轮推理对抗性测试100条Query工具超时所有工具调用≤30秒模拟工具故障注入状态持久化中断后可从中间状态恢复模拟进程重启Prompt版本有变更记录和回滚能力检查Git历史死锁检测Agent间通信有超时重试模拟网络延迟成本控制单任务Token消耗有上限统计P50/P99 Token用量四、Agent系统运维的三个关键指标任务完成率成功完成的任务 / 总任务数。低于90%需要排查。平均推理步数P50和P99。P99超过20步说明存在频繁的无限循环。单任务Token成本按模型定价折算为金额。如果简单查询均价超过0.01美元存在成本优化空间。五、总结Agent系统的六个深坑本质上都是**从Demo到生产的工程化问题**。Demo中Agent表现出色因为环境是受控的、输入是规范的、没有超时和异常、成本不在考虑范围。但在真实生产环境中Agent面对的是千奇百怪的输入、不可靠的网络、严格的成本约束。Agent开发的核心矛盾在于越智能的系统故障模式越难以预测。传统软件的bug是确定性的输入A必然触发错误B而Agent的故障是非确定性的同一输入可能这次正常、下次异常。对抗这种不确定性靠的不是消除所有bug而是建立全方位的防御体系——超时、重试、降级、监控、成本控制一个都不能少。