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