企业第一次做 AI，应该先建知识库还是先做智能体？

先建知识库还是先做智能体：一条判断方法

企业立项时最常纠结的一个选择题：

是先把知识库建好，还是直接上智能体？

大部分公开讨论没什么用，因为讲的人往往站在自己产品那一边。这篇给一条中立的判断方法。

---

先把两个词的边界说清

这两个词在市场上被用得很乱，先定义清楚本文的口径：

最关键的差别在最后三行。知识库答错了，用户看一眼就过去了；智能体做错了，系统里已经产生了一条错误记录。

---

一条分界判据

这个任务的目标，是让人知道点什么，还是让系统变点什么？

• 让人知道 → 知识库
• 让系统变 → 智能体

用这条判据过一遍你的候选任务，答案通常很清楚：

---

混合型任务怎么办

最后一类是最常见的：既要答，又要做。

处理方式：拆开，先做"答"那一半。

理由有三个：

一、"答"那一半是"做"那一半的前提。

系统连"该怎么处理"都答不准，让它去执行只会更快地做错。

二、"答"的失败是可恢复的，"做"的不一定。

先在可恢复的部分把质量做到位，再谈不可恢复的。

三、"答"的阶段会产生你需要的数据。

用户实际问什么、什么答案容易错、边界在哪——这些数据是设计动作逻辑的依据，而它们只能从真实使用中来。

所以推荐的顺序是：知识问答跑 4–8 周 → 拿到真实使用数据 → 再设计动作 → 动作先做成"生成待确认的操作，由人点确认" → 观察一段时间 → 再考虑放开自动执行。

---

但是：不要为了建知识库而建知识库

上面说"先做知识库"，容易被误解成"先花三个月整理全公司资料"。那是另一个错误。

正确的做法是围绕一个任务建，不是建一个全公司的知识库。

判据：如果你的知识库项目没有一个具体的问题清单作为验收标准，那它大概率会变成资料坟场。

---

什么情况下可以直接做智能体

有两种情况可以跳过知识库那一步：

一、动作逻辑本来就是确定的规则。

比如"到期未响应的工单自动升级给主管"——这根本不需要任何知识，就是规则加定时任务。

这类任务连模型都不需要，直接写规则就行。用大模型去做一个 if-else 能做的事，是最常见的资源浪费。

二、已经有成熟的人工 SOP，且执行不需要判断。

比如"收到某类申请，按固定字段映射生成系统单据"。人在做这件事时也不需要思考，那自动化它就是纯工程问题。

判据：问一句"现在做这件事的人，需不需要动脑子？"

不需要 → 直接自动化，不用知识库，可能也不用模型。

需要 → 那个"脑子"里的东西就是知识，得先把它变成可检索的资料。

---

智能体的三条硬要求

如果确实要做智能体，有三条不能省：

一、每个动作都要能回滚，或者有明确的人工确认环节。

不可回滚且无人确认的自动动作，不该出现在第一个项目里。

二、动作前的判断依据要可见。

系统要执行某个动作时，必须能说清"因为看到了什么所以要这么做"。黑盒执行是审计和排错的噩梦。

三、有明确的失败处理路径。

动作执行失败了怎么办、部分成功怎么办、下游系统超时怎么办。这些在设计阶段就要写清楚，不能等出了问题再补。

---

怎么验收

知识库：口径沿用开源评测框架 RAGAS（docs.ragas.io）——上下文召回率、上下文精确率、答案忠实度、答案相关性，四项分开量。

智能体：另外一套，不能套用上面那四项。

"误动作率"比"动作正确率"重要得多。一个不确定就不动的系统，比一个大部分时候对但偶尔乱动的系统安全得多。设计上应该倾向于"拿不准就交给人"。

测试集建议：动作类至少 100–200 条，且必须包含边界和异常情况（数据不全、状态冲突、下游不可用）。只测正常路径的智能体测试，等于没测——正常路径本来就不容易错。

---

一句话总结

让人知道点什么 → 知识库；让系统变点什么 → 智能体。

两者都要 → 先做知识库那一半，用它产生的数据去设计动作。

都不需要判断 → 可能连模型都不用，写规则就行。

---

相关阅读

• 企业知识库怎么做，才不会变成资料坟场
• 企业第一次做 AI，怎样选对项目并设计可退出的试点
• 企业 AI 项目怎么验收：七层验收标准与证据要求
• 企业 AI 的数据治理：治什么、治到什么程度、谁来治

---

*本文说明的是方法与判断标准，不代表任何未公开项目的实施细节。文中引用的开源评测框架，出处已在正文标明，读者可自行核验。*