Agent 系统哪个模块最不稳定?
规划、记忆、工具调用等模块的常见失败模式与原因分析
原题：在基于大模型的智能Agent系统落地到真实业务场景时，其各个模块（如规划、记忆、工具调用、执行反馈等）中，哪些最容易出现稳定性或可靠性问题？请结合常见失败模式说明原因。
Agent · 蚂蚁真题
回答与解析
各模块稳定性风险排序（从高到低）
1. 规划模块 — 最易失控
核心问题：意图漂移与无限循环
- 幻觉规划：模型生成不存在于工具集的动作，或虚构执行步骤
- 循环陷阱："查询→无结果→换个说法再查询"的死亡循环
- 目标遗忘：长链推理中偏离原始用户意图
根因：LLM的开放式生成特性与确定性执行需求的根本矛盾；缺乏对规划路径的形式化验证。
2. 工具调用 — 边界灾难
核心问题：参数解析脆弱
| 失败模式 | 典型案例 |
|---|---|
| 格式幻觉 | JSON缺括号、字段名拼写错误 |
| 语义错配 | 把"用户ID"填成"用户名" |
| 空值崩溃 | 工具返回null时Agent未处理 |
| 超时雪崩 | 同步等待阻塞整个执行流 |
根因：Schema约束弱；工具文档与实现不一致；缺乏运行时契约校验。
3. 记忆模块 — 隐性污染
核心问题：检索噪声的复利效应
- 相似度陷阱：Embedding将"退款政策"与"退货流程"混为一谈
- 历史包袱：早期错误记忆被反复检索强化
- 上下文膨胀：关键信息被淹没在冗余历史中
根因：向量检索的语义近似性≠业务精确性；缺乏记忆的有效期与置信度机制。
4. 执行反馈 — 状态黑洞
核心问题：观测延迟与解读偏差
- 工具异步执行时，Agent误判"未完成"为"失败"
- 错误信息被LLM过度解读，引发过度修正
- 部分成功状态（如"创建成功但通知失败"）难以被正确分类
系统性风险：级联失效
单模块故障会通过重试机制放大：
规划错误 → 生成无效工具调用 → 工具报错 →
LLM将错误信息作为新上下文 → 生成更离谱的规划...
加固建议：模块间增加熔断与降级（如规划失败时切换规则引擎），而非简单重试。
学习建议
建议系统学习该知识点
口语版讲法(约4分钟)
- 一句话定位：本质是LLM开放生成与确定性执行的矛盾
- 规划模块：意图漂移和无限循环是最大风险
- 工具调用：参数解析脆弱，JSON格式和语义错配常见
- 记忆模块：检索噪声复利，相似度陷阱需要混合检索和置信度过滤
- 级联失效：重试放大错误，需要熔断降级，最后抛可延伸点
这道题其实是在问，当大模型Agent落到真实业务里，到底哪个环节最容易崩。我觉得核心矛盾在于，LLM的开放生成特性和业务要求的确定性执行之间，天然有冲突。所以稳定性风险最高的，我首推规划模块。
规划模块说白了就是让模型自己决定下一步该干什么。但现实里经常出现两种极端：一种是幻觉规划，模型虚构一个不存在的工具或者凭空编出执行步骤；另一种是无限循环，典型的场景是“查一下，没结果，换个说法再查”，就这么死循环下去。我之前处理过一个客服退款场景，Agent要查退款状态，第一次说“查询退款单”，没查到，它不报错，反而觉得是查询词不对，换成“查询退款申请”，又没查到，再换“查询售后单”，结果越查越偏，最后直接跑飞了。这背后的根因就是模型在长链推理里容易遗忘原始目标，而且我们缺少对规划路径的形式化验证。
再一个容易出问题的是工具调用，说白了就是模型调用API时参数解析特别脆弱。最常见的失败模式是格式幻觉，比如该输出JSON，结果缺个括号或者字段名拼错。还有语义错配，比如工具要求传用户ID，模型填成了用户名。更头疼的是空值崩溃，工具返回null，模型没做处理，直接报错。还有超时雪崩，如果工具是同步等待的，一个慢调用能卡死整个执行流。所以我会特别关注工具文档和实现的一致性，上线前加一层运行时契约校验。
记忆模块的问题比较隐蔽，属于隐性污染。核心是检索噪声的复利效应，比如向量检索的相似度陷阱，Embedding可能把“退款政策”和“退货流程”混为一谈。而且早期的一个错误记忆会被反复检索强化，就像滚雪球。我的做法是混合检索，把关键词和向量两条路结合起来，再加置信度过滤，分太低的直接丢掉。说白了，向量检索的语义近似性不等于业务精确性，所以我会把记忆的有效期和置信度机制看成标配。
最后，这些单模块故障会通过重试机制级联放大。比如规划错误导致无效工具调用，工具报错，模型把错误信息当成新上下文，然后生成更离谱的规划，这就是级联失效。所以我的建议是模块间加熔断和降级，比如规划失败时直接切规则引擎，而不是简单重试。
不过说实话，这些方案都是事后补救。我更倾向从系统设计层面提前规避，比如引入 Self-RAG 让模型自己学会反思，或者用 Reflexion 机制让Agent在每步执行后自我校验。但这又会引入额外的延迟开销，所以怎么平衡可靠性和实时性，是个值得深挖的问题。
关键一句:从系统设计层面用Self-RAG或Reflexion提前规避，但会引入延迟开销
面试官还可能这样问
- 问法 1 · 场景切入
假设我们要做一个电商客服Agent，用户问‘帮我查一下退款进度’，Agent先去查订单，然后调用退款API，再回复用户。你在落地这种多步骤任务时，觉得哪个环节最容易出幺蛾子？比如规划跑偏、调接口报错这些，你排个序呗。
- 问法 2 · 层层追问
一个Agent系统分规划、记忆、工具调用、执行反馈几个模块，你觉得哪个最容易不稳定？……那规划模块具体会怎么出问题？……如果规划错了，后续模块会不会跟着崩？这种级联失效怎么避免？
- 问法 3 · 直球架构
直接说，在真实业务里，Agent的规划、工具调用、记忆、执行反馈这四个模块，按稳定性风险从高到低怎么排？每种给个典型失败模式，再分析一下根因。