RAG 实战：驱动智能体的知识库
周五下午 4:55，一个内部智能体回答了一个“看似简单”的问题：“我们能把这份客户导出数据分享给合作伙伴吗？”它检索到一页过期的政策文档，自信地给出肯定答复，于是文件被发出。到了周一，法务指出政策在上个季度已更新，而审计链路显示：自动化流程很完整，问题出在证据一开始就选错了。
核心观点：当“检索”作为智能体运行时中的一项可治理能力来设计时，RAG 才真正达到企业级——可规划、可授权、可追溯，并能持续评估与改进。只把检索当作提示词层的小技巧来拼装，智能体就会以同样可预见的方式反复失败。
为什么 RAG 在 Demo 里好用，在真实智能体工作里容易失效
多数团队从经典 RAG 开始：切分文档、向量化、Top-k 检索，把内容塞进提示词，让模型生成答案。对于 FAQ 类问题，它往往很惊艳，引用也看起来“有根有据”。
但一旦工作负载变化，挑战会立刻出现。
智能体会被要求完成多步任务：调查、对比、决策，甚至更新记录或触发工作流。此时，“一次性检索”会变成瓶颈，因为智能体需要的不只是内容，还包括：检索决策、检索策略、检索证据，并且要贯穿多步骤流程。
这些变化也体现在企业架构师关心的市场信号里：
- 有头部分析机构预测：到 2026 年，最高可达 40% 的企业应用会内置面向特定任务的 AI 智能体。
- 一份大型企业 AI 采用报告指出：70% 的公司正在使用向量数据库与 RAG 来定制 LLM。
- 治理要求正在强化：ISO/IEC 42001:2023 被视为首个 AI 管理体系标准，并在 2023-12 发布。
当智能体与 RAG 都逐渐成为默认选项，设计问题就变得非常务实：所谓“深度融合”究竟意味着什么？
深度融合的主张：把检索当作生产系统能力来做
深度融合的想法很直白，但后果很锋利：
只要检索会影响业务决策，检索就需要具备契约（返回什么）、控制（谁能看到什么）、溯源（内容从哪里来）、反馈闭环（如何变好）。这些要素齐备后，智能体就能像依赖数据库那样依赖知识库：通过稳定接口与可审计行为获得可靠结果。
缺少这些要素时，团队通常会用更长的提示词、更大的上下文、更密集的“提示工程”来补。短期能缓解，长期很难把可靠性做成工程属性。
实战中的“融合形态”：六个能显著改变结果的机制
下面这些机制，反复出现在中英文高质量的 RAG+智能体架构文章，以及更近一年的“智能体检索（agentic retrieval）”文档里。
1) 检索成为带类型契约的工具能力
智能体通过结构化接口调用检索：查询、过滤条件、范围（scope）、top-k、时间窗口、以及“必须引用”的要求。检索从提示词模板的隐性副作用，变成可检查、可复盘的决策点。
2) 智能体会规划检索，而不是被动“接收上下文”
复杂问题通常需要拆解：子查询、同义改写、多源覆盖、迭代收敛。较新的智能体检索流水线会把这件事产品化：生成多条更聚焦的查询，再合并与去重结果。
3) 证据打包是显式的
系统不再直接倾倒 chunks，而是把证据封装为“主张（claims）+ 支撑摘录（excerpts）+ 元数据（metadata）”，并确保引用粒度在多步推理后依然有效。这对需要解释行动、通过复核、或交接给人工的场景非常关键。
4) 策略与权限在检索阶段就被强制执行
企业场景的失败常见原因来自访问错误。深度融合会在检索前执行 ACL/ABAC 过滤、租户边界、脱敏、基于用途（purpose）的访问控制，内容进入模型之前就已经合规。
5) 记忆层分离，并纳入治理
智能体会混用短期对话状态、任务状态、组织知识。深度融合会把它们拆成不同层：短暂工作记忆、可持久知识库、权威的系统记录（system of record）。如果这些层混在一起，智能体容易把应当重新核验的信息当成“记住了的事实”。
6) 闭环学习机制可用
系统会采集检索轨迹（查询、结果、实际使用的引用）、结果信号（用户纠正、升级处理、审批驳回），以及评估指标。质量提升从“出问题再排查”的仪式，变成产品级的持续迭代循环。
单独实现其中一项，会带来增量收益；实现大多数后，失败模式会改变：更容易监督，更容易定位问题根因。
可复用的参考架构：三大平面协作
一个好用的心智模型是“三平面”：
数据平面（Knowledge Base）
摄取流水线、切分策略、向量与混合检索、元数据、文档版本管理、生命周期策略。它回答：“有哪些知识？新鲜度怎样？”
控制平面（Governance）
访问控制、脱敏规则、范围边界、审计日志、评估策略、变更管理。它回答：“谁能检索什么？为了什么任务？如何证明？”
执行平面（Agent Runtime）
规划、工具调用、检索编排、推理步骤、行动提案、交接与回路。它回答：“智能体如何决定取什么证据，并安全使用？”
控制平面缺位时，团队往往会在提示词里写警告来补；执行平面薄弱时，团队可能会在 embeddings 与切分策略上投入很多，但多步任务表现依旧不稳定。
企业开发平台在这里的价值
深度融合之所以难，是因为你交付的是一整套产品能力：连接器、数据模型、权限、工作流、日志、评估，需要在同一套体系里对齐。
企业开发平台可以压缩成本：统一定义数据模型，连接现有数据库与内容源，权限一致挂载到数据与工具上，并用可观测的步骤交付智能体工作流。
如果你的产品方向包含“超越问答”的智能体，并且未来要提出可执行的业务动作，那么从第一天就把检索、审批与可审计性做成一等公民能力，会更顺畅。ISO/IEC 42001 的框架也强化了这个方向：它推动团队建立清晰角色、风险控制与持续改进机制，支撑 AI 系统走向可运营。
常见反对意见：更大的模型与更长的上下文会让 RAG 变得不重要
工程团队常见这种想法，因为看起来很线性：模型更强 + token 更多 = 检索问题更少。
但企业约束不会因为规模变大而消失：
- 知识每周变化，训练截止点仍然存在。
- 组织有访问边界，更长上下文会放大泄露风险。
- 需要可审计性时，靠大提示词进行隐式推理很难说明白。
- 成本与延迟敏感时，“每次都塞更多内容”会成为持续税负。
更准确的结论是：更长上下文会降低某些任务的检索频率，但治理、溯源、策略控制依然属于系统属性，绕不开。
行业演进：采用信号 → 瓶颈 → 未来 12–18 个月的产品形态变化
- **采用信号：**RAG 已成为主流基础设施，智能体正以更快速度嵌入企业应用。
- **瓶颈：**当智能体跨多源、多步骤工作时，可靠性问题集中爆发。典型根因包括：检索范围、权限、证据质量、内容过期、可观测性不足。
- **产品形态变化（未来 12–18 个月）：**更多系统会把“智能体检索”设为默认模式：查询拆解、多查询覆盖、结果融合成为检索栈内建能力，并以结构化方式开放给智能体调用。近期面向智能体的检索流水线文档已经把这个方向讲得更清楚。
如果趋势持续，“AI 知识库”会从文档容器演进为可治理的检索服务：具备契约、评估与安全控制，匹配企业期望。
可落地的实施清单（最小可交付版本）
- 定义检索契约
明确智能体可请求什么（过滤、范围、时间、来源），以及收到什么（带元数据的证据对象）。 - 把权限当作检索的一部分
将身份、角色与用途绑定到查询，保留完整审计：检索了什么、来自哪里、为什么要取。 - 为复杂问题加入智能体检索行为
对跨部门、跨政策、长文档任务，引入查询拆解、多查询覆盖与结果融合。 - 强制引用纪律
要求每个主张附上引用；证据不足时标注“未知”。这对信任提升常常比提示词润色更有效。 - 记录检索轨迹
记录查询变体、Top 结果、过滤条件、引用使用情况。出问题时优先调试检索计划。 - 用匹配风险的评估体系
衡量 groundedness（有据性）、引用覆盖、权限正确性、延迟与成本，并把关键指标与发布门禁绑定。 - 用纠错工作流闭环
让领域负责人标记过期文档、修复元数据、补充权威答案，把“内容新鲜度”变成可运营职责。
做到这七步，你得到的会是“RAG 支撑可治理的智能体行为”。
FAQ
经典 RAG 什么时候开始不够用？
当问题需要多步调查、跨文档综合，或会影响工作流决策时。只做单次 top-k 往往不稳定，智能体检索模式通常更占优。
如何防止知识库导致数据泄露？
在检索阶段执行权限与范围控制，按身份与用途限定来源，保留检索审计日志。RAG 安全实践越来越强调脱敏与受控摄取。
知识库与数据库查询工具怎么分工？
政策、流程、产品文档、Runbook、长说明放入知识库；实时运营事实用数据库查询获取。答案必须反映“当前状态”时，应从系统记录检索。
如何证明智能体可靠？
强制引用，记录检索轨迹，基于代表性测试集评估有据性与权限正确性。有轨迹与指标后，可靠性才能成为工程属性。
从 JitAI 开始
如果你正在设计需要知识库与可控执行的企业智能体，可以从“把检索做成可治理能力、让工作流可审计”的路径入手。最快的上手方式是阅读 JitAI 教程。
如果你希望快速验证完整闭环（知识 → 检索 → 智能体步骤 → 可观测结果），可以直接 试用 JitAI。