过去两年，RAG 和 Agent 被推成了「AI 应用的标配」。
几乎所有 AI 产品都在讲：

• 我们有 RAG（检索增强）

• 我们有 Agent（智能规划）

但真正把它们塞进 企业级系统 的工程师都会立刻遇到一个残酷现实：

同样输入，每次执行结果都不一样。
甚至同样的 Agent，每次走的路径都不同。

这不是“温度太高”、“模型随机性”那么简单。
而是 传统 RAG / Agent 的架构层面就带有“不稳定基因”。

这篇文章我尽量写得更工程、更底层、更落地，
把这个问题掰开讲透。

---

🔥 一、先说结论：传统 RAG / Agent = 结构不稳定

为什么不稳定？
原因有四个维度：

1. 检索本身就是“模糊匹配”（向量空间不保证确定性）

2. 上下文拼接顺序影响模型注意力（结构性不可控）

3. LLM 推理本身带概率采样（输出非完全确定）

4. Agent 的 Planner 是“模型临时推理”，不是“算法”

换句话讲：

整个系统流程中，超过一半关键步骤都是“概率行为”。

你当然稳定不了。

下面分解一下每个层面的“原罪”。

---

🧩 二、传统 RAG 为什么天生不稳定？（核心：检索 + 上下文构造）

1）向量检索本身不确定

RAG 的第一步就是：

query → embedding → 向量检索 → top_k chunks

但 embedding + ANN（近似最近邻）检索，天然就不稳定：

• embedding 模型本身有漂移

• top_k 改一个数字结果就变

• 不同 ANN 索引（HNSW、IVF）近似结果有随机性

• 增量更新 / 重建索引会改变结果

• 数据本身在变（知识库更新）

换句话说：

从最源头开始，你就没固定住输入。

上游不稳定，下游稳定不了。

---

2）上下文构造顺序直接决定模型的“注意力重心”

很多人以为：

“只要把检索出来的内容都塞给模型就行。”

但 LLM 是注意力分布模型，结构极其敏感：

• 前面的 chunk 权重高

• 后面的 chunk 可能被截断

• 同一内容不同拼接顺序会刺激不同语义路径

• 长上下文里的噪声会干扰真正要的信息

这就导致：

“拼接顺序变，回答就变。”

而大部分 RAG 根本没把“上下文结构”当工程对象。

---

3）模型输出带采样随机性

即便：

• embedding 锁定

• 检索稳定

• 上下文固定

LLM 本身依然存在：

• logit 层微漂移

• 硬件 / batch 不同带来的浮动

• temperature / top_p 采样导致的多样性

• 注意力分布的微变化

所以：

“抽象意义的一致” ≠ “工程意义的确定”。

这也是为什么企业完全不敢把 RAG 当成关键系统。

---

🤖 三、为什么传统 Agent 更不稳定？（核心：Planner 是概率推理）

传统 Agent 的工作流：

1. 把用户请求交给 LLM Planner

2. Planner 输出「推理链」

3. 执行步骤

4. 把中间结果再丢回 LLM（形成递归）

5. LLM 决定下一步要不要修改计划

问题非常清楚：

👉 Planner 本质就是“一次推理”，不是“算法”

同样输入，Planner 可能输出：

• 3 步

• 4 步

• 5 步

• 完全不同的结构

因为它不是算法，
而是“语言生成”。

👉 中间结果被写回上下文 → 形成“蝴蝶效应”

小小偏差 → 被 Planner 放大 → 路径完全不同。

这就是工程师经常看到的：

• 第一次：A→B→C

• 第二次：A→D→E

• 第三次：A→B→F→C

👉 没有显式状态机，只有对话堆叠

Agent 管理“状态”的方式是：

“把结果写回上下文，让模型自己记。”

对工程而言，这就是灾难：

• 没有确定的状态

• 没有明确的状态转移

• 没有可回放的执行图

• 出问题完全不可审计

这就是传统 Agent 的结构性缺陷。

---

🌐 四、为什么企业无法容忍这种不稳定？

工程师都懂：

“可以错，但不能不可复现地错。”

尤其是：

• 金融风控

• 审计

• 合规

• 医疗诊断

• 政府系统

• 安全生产

• 法律合同分析

这些行业关心的是：

• 可控性

• 可重复执行

• 可回放

• 可审计

• 路径一致性

不是“AI 有多聪明”。

传统 RAG / Agent 在结构上无法满足这些要求。

---

🛠 五、那有没有办法让 Agent 稳定下来？

答案是肯定的。
核心思路不是“微调模型”，
也不是“写更强 prompt”。

而是：

把“规划”从 LLM 推理 → 编译成“确定的执行结构”。

具体包括：

✔ 把 Planner 换成“可编译执行图”（Deterministic Execution Graph）

✔ 把中间步骤从“语言堆叠”改成“显式状态节点”

✔ 把检索从“相似度自由发挥”变成“结构化检索”

✔ 把输出统一成“可审计 JSON 工件”

✔ 把整个链路做成“严格模式（strict mode）”

这就是我做 AWS 场景 POC 的背景。

---

🧪 六、一个最小可行的确定性 Planner POC（基于 AWS Bedrock）

👉 项目地址：
https://github.com/yuer-dsl/bedrock-deterministic-planner-poc

这是一个非常小、非常克制、完全不暴露核心架构的 POC。

它只做三件事：

① 输入解析 → 固定结构节点

像：

• parse

• extract

• cluster

• summarize

• freeze

节点是编译时确定的，而不是推理时临时生成的。

② 固定的执行路线，而不是动态规划

类似流程：

parse → cluster → summarize → output

无论输入多少次，相同输入 → 相同路径。

③ 输出是“工件（artifact）”，不是“回答”

包含：

• 路径

• 节点执行顺序

• trace_id

• 状态快照

• 依赖数据版本信息

可回放、可追溯、可审计。

---

🎯 七、总结：RAG / Agent 的未来一定是“确定性优先”

行业会从现在的：

“LLM 自由发挥 + 即兴规划”

转向：

“结构驱动 + 确定性执行 + 可审计链路”

这是所有严肃业务场景的必答题。

传统 RAG/Agent 天生不稳定，
并不是工程师不够努力，
而是 结构本身就如此。

改变结构，才能改变稳定性。

---

如果你正在做：

• AI Agent

• 企业知识库

• 工作流自动化

• 辅助决策系统

• 金融/法律/医疗的生产级应用

欢迎看看这个 POC，
也可以一起讨论如何让 RAG/Agent 进入“真正可控”的时代。

👉 https://github.com/yuer-dsl/bedrock-deterministic-planner-poc