第一个 Agent 要查几份产品文档，最省事的做法往往就是把文件传进它自己的知识库。项目能跑起来，效果也看得见。没有必要一开始就把事情做成一套服务。
可第二个 Agent 上来时，麻烦就露头了。它也得读那份产品文档，也得知道最新的报价规则。你可以再上传一遍，但很快会遇到几个很具体的问题：哪边先更新？谁负责把 PDF 里的表格解析好？检索到的一段话，到底来自哪个版本？
这时需要共享的不是“同一批附件”，而是文档变成可检索知识的那套过程。MCP 知识库说的就是这件事：让 Agent 通过一个统一协议调用检索能力，而不是各自保存一份被切碎过的文档。
MCP 放的是能力，不是一整个资料夹
不少人第一次接触 MCP，会把它理解成“让模型读文件”的通道。这个理解不算错，但太粗了。
一个有用的知识库 MCP 服务，至少要能回答几件事情：现在能搜到什么，结果来自哪里，导入是否完成，某个文档后来有没有更新。换句话说，Agent 拿到的应该是查询工具和证据，不是一大段永远常驻在上下文里的材料。
琅嬛把 knowledge_search、文档导入、状态查询和删除等能力通过 MCP over HTTP 提供出来。上层可以是 Claude、Cursor，也可以是你自己写的 Agent。它们不必知道底下是 PostgreSQL、SQLite 还是怎样切块；需要知道的是，给定一个 workspace 和查询，能拿到带来源锚点的结果。
这和把所有资料塞进项目上下文是两种架构。前者在问题发生时取需要的几段，后者让模型每轮对话都背着整个资料库。上下文窗口再大，也不该拿来当文件柜。项目知识库撞上上下文限制时，通常就是把这两件事混在了一起。
为什么第二个 Agent 往往是分界线
一个应用里自己处理文档，边界很清楚。业务团队、权限模型和检索逻辑都在同一个仓库，改起来也快。
两个应用共享资料时，边界开始变模糊。员工助手和销售助手都读产品资料，前者还要读内部制度；项目助手又多了一批按客户隔离的交付文档。每个应用分别建库当然能做，只是每次都会重新决定分块规则、索引参数、失败重试和访问控制。
我见过更难处理的一种情况：同一份制度在三个系统里各有一个索引。文档更新后，有人说答案不对，团队得先花半天确认他问的是哪个系统、那个系统用的是哪个版本，最后才轮到讨论模型。问题看上去在回答，实际上是知识状态已经分叉了。
把检索层抽出来，不会让上层 Agent 失去个性。反过来，它让它们把精力留给真正不同的地方：一个 Agent 负责审批流程，另一个负责生成交付计划，它们都可以用同一条知识证据。这也是我在多个企业 Agent 为什么不该各建知识库里想说的边界。
检索结果必须带得走出处
“搜到了”并不等于“可以拿去回答”。公司资料里常有新旧版本、例外条款和相同名称的文件。没有出处的片段，放进模型上下文后很容易被说得斩钉截铁；人却没法核对。
所以知识库服务应该返回足够的信息让上层处理：命中的内容、文档和版本，以及页码、行列或偏移等来源锚点。琅嬛把这些信息保留在检索链路里，也保留稳定的查询标识，方便管理员回放一次检索为什么会给出这些结果。它不替 Agent 组织最后一句话，也不把“没有检索到”伪装成答案。
这类分工看上去朴素，排障时差别很大。检索不对，先看检索证据；证据没问题但回答不对，再看提示词或 Agent 的流程。两件事不用搅在一起猜。
MCP 知识库该从哪里开始
如果你只是给一个内部助手试水，先用应用内的检索也没问题。等到出现下面任意一种情况，再考虑把它独立出来：
- 两个以上的 Agent 要读同一类文档；
- 文档版本和权限已经有人在维护；
- 团队需要解释某个回答的来源；
- 新接一个客户端时，不想再写一遍导入和索引。
先把服务跑起来，再接第一个 MCP 客户端，往往比在每个 Agent 里预埋一套“以后也许会共享”的代码轻得多。想了解协议本身，可以从 MCP 是什么 开始；如果检索里既有中文专有名词又有语义问题，再看混合检索的取舍。琅嬛实际的数据流和版本边界在架构文档里有完整说明。
MCP 不是把所有能力都包成工具的理由。它适合把已经稳定、可以独立判断输入输出的能力交给 Agent。对知识库来说，检索、导入和状态正好符合这个条件。