在 Cursor 里写代码，AI 可以帮你修改接口、生成代码、排查 Bug。

但如果你问它：

我们公司的 API 设计规范是什么？这个接口应该怎么改？

它可能给出一套看起来合理的方案，却不一定符合你们公司的实际规范。

原因很简单。

规范在企业知识库里，但 Cursor 默认访问不到。

你当然可以把相关文档复制进对话。但文档一多，就得反复查找、粘贴。规范更新以后，还可能继续引用旧内容。

这也是我们在做企业级 AI 知识库「有谷大脑」时，为什么要提供 MCP 接入能力。

让 AI 不只是依赖模型已有的知识，还能在需要时，直接检索企业自己的知识库。

一、MCP 到底解决什么问题？

MCP，全称 Model Context Protocol，是一种让 AI 应用连接外部工具和数据源的标准协议。

可以把它理解成：

给 AI 一个统一的工具接口，让它能够按需调用外部能力。

以前，如果想让 Cursor、Claude Desktop 等工具访问企业知识库，可能需要分别开发不同的集成方式。

现在，只要客户端支持 MCP，就可以通过 MCP Server 调用知识库检索工具。

比如在 Cursor 里输入：

根据我们公司的接口规范，检查一下这段代码有没有问题。

AI 就可以先调用知识库检索工具，找到相关规范，再结合检索结果分析代码。

这里最重要的变化是：

企业知识不再需要反复复制进 AI 对话，而是变成了 AI 可以主动调用的工具。

二、一次知识库检索，是怎么完成的？

MCP 的基本架构可以分成三层：

Host → MCP Client → MCP Server → 知识库检索

图 1：有谷大脑 MCP 知识库接入架构。外部 AI 应用通过 MCP Server 调用 RAG 检索能力。

在有谷大脑的接入场景中：

Host：Cursor、Claude Desktop 等 AI 应用

用户在这里提出问题，AI 判断是否需要调用外部工具。

MCP Client：负责通信

它负责与 MCP Server 建立连接、发送工具调用请求，并接收结果。

MCP Server：对外提供知识库能力

有谷 MCP Server 将知识库检索能力封装成标准工具，例如：

• list_knowledgebases：列出当前凭证有权访问的知识库。
• query_knowledge_base：检索指定知识库，返回相关文档片段。

真正的文档解析、向量检索和混合检索，仍然由有谷大脑的 RAG 系统完成。

MCP 不负责重新建设一套知识库，它负责让外部 AI 工具调用已有的知识库能力。

三、为什么不能只把检索结果返回给 AI？

假设开发者问：

我们的 OAuth refresh token 过期策略是什么？

知识库里有一份内部 API 设计规范。

如果只返回一句：

Refresh token 有效期为 30 天。

AI 虽然得到了答案，但开发者仍然不知道：

这句话来自哪份文档？是不是最新版本？有没有其他限制条件？

所以，知识库检索返回的不能只有一段孤立的文本。

在有谷大脑的 RAG 检索链路中，返回结果可以包含：

• Chunk 正文：与问题相关的文档片段。
• 文档信息：来源标题、文档 ID 等。
• 位置 metadata：页码、章节或其他格式相关信息。

外部 AI 可以基于这些内容组织回答，并在 Host 支持的情况下展示来源信息。

这里有个很容易混淆的地方：

MCP 负责把检索结果交给 AI，但不自动保证 AI 的回答一定正确，也不保证所有客户端都能展示可点击引用。

最终效果仍然取决于知识库的解析质量、检索准确性，以及客户端如何使用返回的信息。

四、企业知识库开放给 AI，权限怎么办？

把知识库接到外部 AI 工具，还有一个实际问题：

AI 能不能查到不该看的内容？

不能因为接入了 MCP，就绕过原有的企业权限。

在有谷大脑的接入设计中，MCP Server 通过 API Key 进行鉴权，并按照对应工作空间和知识库权限执行检索。

例如：开发团队的 Key 只能访问技术规范库，就不应该通过同一个 Key 查询财务或人事知识库。

需要注意，Host 是否要求用户确认工具调用，取决于具体客户端和配置。

而且，工具调用确认不能代替服务端鉴权。

真正的数据访问边界，仍然需要由知识库服务端控制。

对于涉及敏感资料的企业，还需要结合部署方式、密钥管理和审计机制，评估外部 AI 服务的数据处理风险。

五、MCP 和普通 API，有什么区别？

有谷大脑已经提供开放 API，为什么还需要 MCP？

因为它们面向的接入场景不同。

对比	Open API	MCP
主要使用者	开发者、自建业务系统	支持 MCP 的 AI 应用
调用方式	通过程序代码调用接口	AI 通过标准工具协议调用
典型场景	自建客服、业务系统、自动化流程	Cursor 查规范、Claude Desktop 查资料
主要价值	灵活集成业务能力	降低 AI 工具接入成本

比如，你要开发一个企业内部客服系统，把知识库检索嵌入自己的业务流程，Open API 更合适。

但如果员工已经习惯在 Cursor 里工作，只希望 AI 能随时查询公司规范，MCP 往往更直接。

两者不是替代关系。

Open API 面向业务系统集成，MCP 面向 AI 工具生态接入。

六、最后：企业知识库不应该只存在于知识库页面里

过去，企业知识库的典型使用方式是：

员工打开知识库 → 输入问题 → 查找资料 → 返回原来的工作工具。

但越来越多的工作已经发生在 Cursor、Claude Desktop 等 AI 应用中。

如果企业知识仍然只能在独立网页里查询，员工就需要不断切换工具。

MCP 提供了另一种方式：

让知识库成为 AI 随时可以调用的能力，而不是要求用户每次都主动打开知识库。

在有谷大脑里，无论通过网页问答还是外部 MCP 工具检索，底层都可以复用同一套文档解析、Chunking 和 RAG 检索能力。

当然，接入 MCP 只是第一步。

真正决定效果的，仍然是：知识库里的内容是否准确？检索能否找到正确片段？权限有没有控制好？回答能不能追溯到原始文档？

MCP 解决的是 AI 怎么连接企业知识，RAG 解决的是连接之后能不能找到正确的知识。

这两件事做好了，企业知识库才有机会真正进入员工的日常工作流程。

---

如果想进一步了解这些能力在产品里的实际应用，可以体验：

了解更多：https://brain.yogu.pro