多插件架构会放大 LLM 幻觉吗？——拆解三条放大路径与对策

[jinguanghai]

dsh 开源三天就 8.5 万星，插件生态也在飞速生长。这让我忍不住想聊一个生态层面的问题：插件越多，LLM 幻觉是不是越严重？ 我的初步判断：方向是，但归因要拆开。

一、三条放大路径（我观察到的机制）

1. 决策空间爆炸：工具从 1 个变 20 个，LLM 每次要"20 选 1"。而工具选择恰恰是 LLM 最弱的环节——读 description、区分相似能力、决定用哪个，这个环节的错误率随选项数非线性上升。选错工具 = 用错工具得出貌似合理的结果，这是一种"功能性幻觉"。

2. 信息源污染：社区插件质量参差，劣质插件可能返回过时数据、错误计算甚至编造的输出。而 agent 机制是把工具输出当事实吸收进上下文——垃圾进料口越多，模型越"自信地胡说"。

3. 注意力稀释：每个插件的定义/schema/说明都占上下文，插件多了，干活 token 占比下降，幻觉率随噪声上升。

二、但要澄清：多插件是放大镜，不是火源

幻觉的根因在模型层的统计拟合，没有工具、纯对话也会幻觉。而工具恰恰是抑制幻觉的手段——真计算走工具（编译执行/形式验证）就是确定性输出，零幻觉空间。所以正确归因是：多插件不增加幻觉，它增加的是幻觉的暴露面和传播路径——环节变多（选择/吸收/仲裁），出错概率面变大，但根子还是那个模型。

三、dsh 的三重特定风险

• 生态无审核机制，劣质插件 = 污染源直通上下文
• "一切皆插件" = 把编排决策权全交给 LLM，正撞在最弱环节
• 0.1.0 预览版无稳定契约，插件 API 破坏性变更 → 老插件悄悄坏掉 → 输出垃圾 → 用户还以为是模型问题

四、我的对策方向（抛砖引玉）

1. 确定性优先：数学/逻辑/代码/检索走确定性执行（编译/验证/查表），LLM 只翻译意图不算数
2. schema 强校验：减少 LLM 乱填参数的空间
3. description 写死边界：工具说明里给反例，降低选错率
4. 关键流程编排固化：少让 LLM 每次重新编排
5. 插件质量门禁：输出格式契约 + 测试，劣质插件别让 LLM 吃到它的输出

一句话：不是"少用插件"，是"让插件变确定"。 大家怎么看？有没有踩过类似坑，或者更好的实践？