Agent 系统哪个模块最不稳定?

这道题其实是在问，当大模型[[Agent]]落到真实业务里，到底哪个环节最容易崩。我觉得核心矛盾在于，LLM的开放生成特性和业务要求的确定性执行之间，天然有冲突。所以稳定性风险最高的，我首推规划模块。

规划模块说白了就是让模型自己决定下一步该干什么。但现实里经常出现两种极端：一种是[[幻觉]]规划，模型虚构一个不存在的工具或者凭空编出执行步骤；另一种是无限循环，典型的场景是“查一下，没结果，换个说法再查”，就这么死循环下去。我之前处理过一个客服退款场景，Agent要查退款状态，第一次说“查询退款单”，没查到，它不报错，反而觉得是查询词不对，换成“查询退款申请”，又没查到，再换“查询售后单”，结果越查越偏，最后直接跑飞了。这背后的根因就是模型在长链推理里容易遗忘原始目标，而且我们缺少对规划路径的形式化验证。

再一个容易出问题的是工具调用，说白了就是模型调用API时参数解析特别脆弱。最常见的失败模式是格式幻觉，比如该输出JSON，结果缺个括号或者字段名拼错。还有语义错配，比如工具要求传用户ID，模型填成了用户名。更头疼的是空值崩溃，工具返回null，模型没做处理，直接报错。还有超时雪崩，如果工具是同步等待的，一个慢调用能卡死整个执行流。所以我会特别关注工具文档和实现的一致性，上线前加一层运行时契约校验。

记忆模块的问题比较隐蔽，属于隐性污染。核心是检索噪声的复利效应，比如向量检索的相似度陷阱，[[Embedding]]可能把“退款政策”和“退货流程”混为一谈。而且早期的一个错误记忆会被反复检索强化，就像滚雪球。我的做法是[[混合检索]]，把关键词和向量两条路结合起来，再加置信度过滤，分太低的直接丢掉。说白了，向量检索的语义近似性不等于业务精确性，所以我会把记忆的有效期和置信度机制看成标配。

最后，这些单模块故障会通过重试机制级联放大。比如规划错误导致无效工具调用，工具报错，模型把错误信息当成新上下文，然后生成更离谱的规划，这就是级联失效。所以我的建议是模块间加熔断和降级，比如规划失败时直接切规则引擎，而不是简单重试。

不过说实话，这些方案都是事后补救。我更倾向从系统设计层面提前规避，比如引入 [[Self-RAG]] 让模型自己学会反思，或者用 [[Reflexion]] 机制让Agent在每步执行后自我校验。但这又会引入额外的延迟开销，所以怎么平衡可靠性和实时性，是个值得深挖的问题。