知识库Agent落地判断
从 RAG 到 Agent：知识库要能「照章办事」
阅读约 3 分钟零七零六科技
先说结论
大模型负责推理，知识库负责提供「经验外挂」，Agent 负责按 SOP 把事做完——三者位置不同，缺一个都不成立（来源：腾讯乐享《从 RAG 到 Agent，打造更聪明的企业智能知识库》，2026）。
所以「上 RAG 还是上 Agent」这个问题问错了。正确的问题是：这件事有没有一份能写下来的 SOP？
- 有 SOP，但只做检索不做执行 → 人还要重复搬运，价值有限；
- 没有 SOP，却想让它自主执行 → 会把「流程没定义」的问题放大成事故。
RAG 解决的是「找得到」
RAG 的链路很短：解析文档 → 切分 → 检索 → 把相关片段塞给模型 → 生成答案。
它擅长的是问答型任务：这个零件的扭矩是多少、这个客户的历史投诉是什么、这份规程第几版做过修改。
它的边界也很清楚：只回答，不改变任何状态。检索错了，用户看一眼就能发现；答错了，最多是「不准」。
Agent 多出来的是什么
Agent 在检索之上多三层能力：调用工具、维护任务状态、按流程推进。
于是它可以做的事变成了：查完库存 → 判断低于安全线 → 生成补货单草稿 → 提交给人确认 → 记录结果。
代价是失败模式也升级了：
| 维度 | RAG | Agentic 知识库 |
|---|---|---|
| 输入 | 一个问题 | 一个任务与上下文 |
| 输出 | 一段答案 + 出处 | 一组动作 + 结果状态 |
| 失败长什么样 | 答偏了、答旧了 | 做错了、做到一半停了、重复做了 |
| 关键能力 | 解析与检索质量 | 流程编排、权限、幂等与回滚 |
| 验收方式 | 抽样看答得对不对 | 跑完整流程，看异常能不能兜住 |
| 对人的要求 | 会提问 | 能把 SOP 写清楚 |
表格右下角那一栏最容易被忽略：Agent 的上限由 SOP 的质量决定，不由模型决定。
三个落地前提
如果打算从 RAG 走到 Agent，先确认这三件事：
- 流程已经写下来了。 不是「大家知道怎么做」，而是有一份能交给新人的步骤说明，包含判断条件与例外情况。
- 动作可以被拆成「建议 + 确认」。 凡是不可逆的动作（对外发送、扣款、下采购单），前期一律留人工确认点。
- 知识是动态的。 设备台账、价格表、库存这些每天都在变的数据，必须有更新链路；静态快照做 Agent，等于让它拿着过期地图开车。
第 3 条在制造与能源企业里尤其关键——知识库往往建成静态的，而现实是每天都在变（来源：腾讯乐享《Agentic 知识库在制造与能源企业的新实践》，2026）。
顺序建议：先 RAG，再 Agent
我们在实际项目里通常这样排：
- 阶段一（2–4 周）：把知识层修好。解析、切分、权限、出处、拒答——五个动作做到位，先让人愿意用。
- 阶段二：在知识层之上加「查询类工具」，让问答能读实时数据（库存、交期、价格），但仍然只输出答案。
- 阶段三：选一个流程清晰、动作可逆、频次高的场景做 Agent，并且强制「建议 + 人确认」。
跳过前两个阶段直接做阶段三，最常见的结局是：Demo 很惊艳，上线后没人敢用——因为一旦做错，没人能解释它为什么这么做。
一个判断练习
拿你手边正在考虑的那件事，回答三个问题：
- 这件事有 SOP 吗？如果没有，先写 SOP，不要先买工具。
- 它做错了，损失可逆吗？不可逆就先只做「建议」。
- 它需要读实时数据吗？如果需要，先解决数据更新，再谈自主执行。
三个问题都能答「是」，才轮到讨论用哪个模型。
延伸阅读：
- 上传了文档，不叫建好知识库：知识层的三个验收动作
- 服务与产品 · 虚拟员工 / 数字人：知识层之上的应用形态
- 案例与成果 · 通用职能：知识库、报表、合同初审等场景的条件与坑
具体投入与交付范围以诊断后双方确认的 SOW 为准。