前几天一场分享里，有位朋友问了我一个问题。他们公司想做一个“企业大脑”：老板平时有很多会议纪要、内部资料，不方便丢给公开的大模型，所以想自己做一个智能体，帮老板和部门负责人做决策。
他们的方案是：用本体（ontology）把公司的知识做成语义层，让智能体基于语义层来回答。
他问我，这是不是正确的方向。
我的回答是：不一定，而且我觉得大概率不对。
这一篇就把这件事讲清楚。因为这不是他一个人的困惑——过去两三年，太多企业的 AI 第一步都走成了这样。
先说结论
为了搭知识库而搭知识库，都是扯淡，一点用都没有。
过去几年很多公司落地 AI 的标准姿势是：把公司所有文档汇聚到一起，做成知识库，知识库可以问答，好，我们公司拥抱 AI 了。
这条路走下来，绝大多数都没产生什么价值。原因很简单——简单的问答，解决不了任何一件真正重要的事。
你建一个这样的知识库，它能帮你写一份专业的环评报告吗？不能。真正专业的环评报告，每一段都有一整套逻辑：这一段要做运算，那一段要去查另一个系统，再一段要根据卫星图确定方位并截图。这种东西，知识库是解不了的。
知识库最多是你诸多基建里的一环。在今天的 Agent 面前，它远远不是重点。
本体论为什么是上一代的东西
回到那位朋友的问题。他们做的是关务，觉得报关这个领域有很多专有词汇和业务概念，所以想建语义层，让智能体“天然地”理解公司的业务。
这个想法在几年前是对的。今天不对了。
**Palantir 当年做 ontology、做知识图谱，背景是上一个时代的 AI。**那是机器学习的年代，那时的模型根本不可能系统性地理解税务、理解海关、理解金融。你不给它建一层语义骨架，它就是睁眼瞎。
但今天的大模型，对税务、海关、金融这些看起来很专业的领域，本身已经具备相当程度的系统性认知了。
你缺的不是知识图谱。你只是没有在正确的任务上把它这个能力激发出来。
同样的道理，RAG 在我这里也不是先进技术，是落后技术。
很多人发现自己的知识库问答准确率怎么都上不去、智能客服怎么都做不好，然后归咎于“知识提炼没做好”。不是的。是这条技术路线本身就过时了。向量检索、向量知识库，在今天都不是知识萃取的正解。
真正的解法在 Agent 这一端：让 agent 自己去系统里抓数据、自己整理、自己分门别类，把知识转成它最好读的形态（很多时候就是干净的 markdown），然后再让 agent 去使用这些知识。
我最近给一家客户做知识体系，就完全没走传统 RAG 那一套——用 agent 来整理知识，再让 agent 来使用知识，准确率完全是另一个量级。
正确的顺序是反过来的
那到底该怎么做？
不要盲目地去建知识库。先想清楚你最终要在哪个场景下解决什么任务，然后顺着这个任务，去把相应的知识做提炼。
而且往往不需要做得很细。你可能只要一个 agent 加一个 skill，skill 里写清楚常见问题怎么处理，具体的东西请它自己去 markdown 文件里查——就够了。
你的重心应该在解决任务上，不是在建设知识库上。
我们要从结果出发倒推：我要写这份报告 → 为了写它我需要哪些数据 → 这些数据转成什么格式最方便 AI 读 → 那我就去做这一步。
而不是先做一个知识中台，然后想象着有一天它能赋能到某个环节去写报告。那都是想象。
所以我给那位朋友的建议是：按任务去做知识库，而不是做一个叫“知识中台”的项目。
**集团级的知识问答，本质上是一个没有方向的做法。**知识很杂、任务不明，最后 agent 不知道该在什么场景下用它。
有方向的做法长什么样？
我是制造业，我就去研究排产、去研究 CAD 图纸和工艺； 我是物流，我就去研究供应链报价； 我是环保，我就去写报告、去做政府平台填报； 我是财务，我就去做业财一体化的智能问数。
这些才是有方向的。
举个财务的例子
我给财务方向做的系统，也要梳理很多业务、也要整理大量数据——但它自始至终是有目标的。
目标是：给 CFO 一套能看明白公司核心指标怎么运转的体系。让他能用一句话问出来：
“我们公司 A 产品线和 B 产品线，为什么 B 产品线的利润率最近下降了？ 是上游供应链哪个环节涨价了吗？ 还是因为我们最近竞标失败？具体是什么原因？”
这是一个非常具体的、带着财务视角和专业诉求的问题。为了回答它，我会把企业的数据做一遍梳理和整理，最后确实也会形成一个知识库——这个知识库甚至可能很全。
但它和“集团知识中台”的区别在于：它是从一个真正重要的人、一个真正重要的问题倒推出来的。
我要让 CFO 用、要让 CEO 用，要让他们觉得这个东西能为公司贡献重大价值——我才会去做。
而不是在集团里，让一些没有真正重要事情要办的人，去问一些无关痛痒的问题。
一句话总结
如果你只带走一句话，我希望是这句：
知识库不是为人建的，是为 AI 建的。
所以第一个问题永远不是“我们有哪些知识”，而是“AI 要替我们做哪件事“。
先有任务，才有知识。任务价值越高，围绕它的知识萃取、检索和调用才越值得设计。
顺序反了，投入再多也是空转。