🚨 本文不讨论“AI 讲故事”，而是以工程师视角直接拆解：
为什么 RAG / Agent 的不稳定，是结构层面的“先天缺陷”。
过去两年，RAG 和 Agent 被吹得神乎其神：
“让模型读文档”“让 AI 自己规划任务”“让自动化更智能”。
但大量工程师在真正把它们塞进生产环境后会发现一个硬伤：
同样输入，同样数据，同样 prompt——
问十次能给十种不同的路线和答案。
这不是开发者不努力，也不是 Prompt 不够优秀，
而是传统 RAG / Agent 的“底层架构本身”就埋了不稳定因子。
🔥 一、RAG 为什么天生跑不稳？
① 向量检索本身不 deterministic
RAG 的第一步就是 embedding → ANN 检索。
但 ANN（HNSW / IVF）是近似检索：
- top_k 改一下 → 结果变
- 数据增量更新 → 结果变
- 重新建索引 → 结果变
- embedding 漂移 → 结果变
- 内部随机性 → 也会变
检索集合一变，回答稳定性直接归零。
② 上下文构造顺序决定模型最终注意力
LLM 的注意力对“拼接位置”极其敏感：
- 前面的 chunk 权重大
- 后面的 chunk 容易被截断
- 噪声块会冲掉关键信息
- 模型在长上下文里注意力随时漂移
也就是说：
拼接顺序不同 → 语义重心不同 → 最终答案不同。
这不是模型幻觉，是结构问题。
③ LLM 本身的概率采样不可避免
即使 temperature=0，也会因为：
- logit 极小差异放大
- batch/硬件差异
- 内部采样流程
- 上下文微扰动
导致结果不同。
LLM 是概率模型，不可能单靠参数做到绝对稳定。
🤖 二、那 Agent 为什么更容易“跑飞”？
因为 Agent 引入了一个更可怕的东西：
Planner = 让 LLM 临时现场推理“执行路线” 。
问题来了：
① Planner 本质上不是算法，而是一次性语言生成
同样的输入，Planner 可能生成：
- 3 步
- 5 步
- 7 步
- 完全不同的工具顺序
它不是：
固定流程 → 固定状态机
而是：
你怎么可能跑得稳？
② 中间结果塞进上下文 = “蝴蝶效应放大器”
流程是这样的：
- 第一步结果 → 写进上下文
- 第二步规划 → 受到第一步结果影响
- 第三步规划 → 再受前两步影响
只要中间结果有一点点差异，
Planner 路线就会整体偏移。
这就是你看到的：
- 第一次：A → B → C
- 第二次：A → D → F
- 第三次：A → B → E → C
而你根本不知道为什么。
③ Agent 没有显式状态机，全靠“对话堆叠”
传统 Agent 的状态管理方式：
把所有输出都塞到上下文，让模型自己“记”。
对工程而言，这等于：
- 没有确定状态
- 没有明确状态转移
- 没有错误分支
- 没有回滚点
- 没有执行图
- 更没有可审计性
你这样设计，不跑飞才怪。
🎯 三、企业为什么不能接受这种不稳定？
因为企业有“三硬指标”：
- 可复现：相同输入 → 必须相同结果
- 可回放：监管要能看路径
- 可审计：出错能归因到具体步骤
传统 RAG / Agent 全都做不到。
🛠 四、那怎么解决？核心不是 prompt，而是架构
一个根本性思路是：
把“不确定规划” → 替换成“可编译执行图（Deterministic Execution Graph）”。
也就是：
- Planner 不是“让 LLM 想”，而是“编译成固定节点”
- Agent 有显式状态机，而不是上下文乱堆
- 检索有结构约束，而不是向量自由漂移
- 输出是工件（artifact），不是自由回答
- 整个执行路径必须可追踪、可复现、可审计
这也是越来越多工程师开始探索“确定性 Agent（Deterministic Agent）”的原因。
🔧 五、我基于 AWS Bedrock 做了一个极简 POC（开源）
👉 GitHub：
github.com/yuer-dsl/be…
它做了三件事：
① 用户请求先被结构化成固定“任务节点”
而不是丢给模型让它临时切步骤。
② 执行路径是固定的（Deterministic Graph）
类似：
parse → cluster → summarize → freeze
不会每次乱跳。
③ 输出是可审计 JSON 工件
包含：
- 执行顺序
- trace_id
- 状态快照
- 数据版本依赖
适合企业场景。
⚠️ POC 是严格“表层演示”，
不会涉及任何深层架构（遵守你的架构冻结声明）。
📌 六、总结一句话
传统 RAG / Agent 不稳定不是“调参问题”，
是 架构天生如此。
想要稳定：
必须从“概率推理”走向“结构执行”。
这也是未来企业级 AI 的必然方向。
