很多人做 AI 知识库，第一阶段目标都很明确：

这一步很重要。因为没有知识库，AI 就不知道你的公司制度、项目资料、产品手册、会议纪要和业务规则。

但如果只做到这里，AI 知识库还是一个“会回答问题的系统”。

它能告诉你：制度怎么写，流程怎么走，资料在哪里，某个项目是什么情况，某个问题可能怎么处理。

但它不能继续往下做。

比如你问：

一个普通 AI 知识库最多只能回答：“根据资料，可能存在以下风险……”

但真正的工作不是到这里结束。

真正的工作还包括：查项目进度，查会议纪要，查未关闭问题，查负责人，生成风险清单，发送给负责人确认，跟踪是否回复，必要时提醒你。

这就不是单纯 RAG 能解决的问题了。

一、RAG 解决的是“查资料”，不是“办流程”

RAG 的价值很清楚：让 AI 在回答前先检索资料，再基于资料生成答案。

所以 RAG 很适合回答这类问题：请假流程是什么？这个产品参数是多少？某份合同里付款条款怎么写？这个项目有哪些会议记录？某个设备操作步骤是什么？

但企业里的真实工作，很多不是“知道答案”就结束。

知道流程后，要发起流程；知道风险后，要通知负责人；知道资料缺失后，要补资料；知道合同快到期后，要提醒续签；知道项目延期后，要更新项目状态；知道库存异常后，要生成处理建议。

这时候，AI 需要的不只是知识库。它还需要连接系统，调用工具，触发动作。

公开资料里，AWS 对 AI Agent 的定义也强调，AI Agent 是能够与环境交互、收集数据，并为了既定目标执行自我导向任务的软件程序；在客户服务例子中，Agent 会查内部文档、根据客户回答判断是否能解决，或转交给人工。

二、MCP 是什么？一句话：给 AI 接系统的标准接口

MCP，全称 Model Context Protocol。不用记英文。

你可以把它理解成：一种让 AI 应用连接外部数据源、工具和工作流的标准方式。

MCP 官方文档说，它是一个开源标准，可以让 Claude、ChatGPT 这类 AI 应用连接本地文件、数据库等数据源，连接搜索、计算器等工具，也可以连接专业提示词这样的工作流。官方还把 MCP 类比成 AI 应用的 USB-C 接口。

以前每个 AI 应用要接系统，都要单独开发：接 OA 写一套，接 ERP 写一套，接数据库写一套，接文档系统写一套，接项目系统又写一套。

MCP 想解决的是：能不能用一种统一方式，把外部数据、工具和流程暴露给 AI 使用？

这个“手柄”可以连接文件、数据库、搜索工具、业务 API、项目系统、日历、消息系统、审批流程和专业工作流。

但注意，不是说有了 MCP，AI 就可以随便操作系统。恰恰相反，越能接系统，越要设计好权限、审批和安全边界。

三、MCP 里最关键的三个东西：Resources、Tools、Prompts

MCP 里有几个核心概念，普通人只需要先理解三个：

1. Resources：给 AI 看什么

Resources 可以理解成 AI 可以读取的上下文资料。

企业里可以把这些做成 Resources：制度文件、项目文档、会议纪要、产品手册、数据库表结构、接口说明、客户资料摘要、设备操作手册。

Resources 更偏“给 AI 看”。它不一定让 AI 执行动作。

2. Tools：让 AI 能做什么

Tools 是 MCP 里更关键的部分。工具可以让模型与外部系统交互，比如查询数据库、调用 API 或执行计算。

企业里可以把这些做成 Tools：查询 ERP 订单状态、查询 OA 流程状态、查询项目延期任务、查询库存数量、生成周报草稿、创建待办事项、发送企业微信提醒、发起审批草稿、更新项目进度。

这也是 AI 从知识库走向 Agent 的关键一步。

3. Prompts：把经验固化成流程

Prompts 可以理解成标准化的任务模板。

比如：生成项目周报模板、分析客户投诉模板、设备故障排查模板、合同风险检查模板、会议纪要整理模板、知识库入库审核模板。

它的价值是把人的经验固化下来。不是每次都让 AI 自由发挥，而是让 AI 按固定结构完成任务。

四、AI 知识库接 MCP 后，会发生什么变化？

没有 MCP 或工具调用时，AI 知识库大多是这样：用户提问，知识库检索文档，大模型生成答案，用户自己去执行。

接入 MCP / 工具调用后，流程会变成：用户提出目标，AI 判断需要哪些资料，读取文档和系统数据，调用工具查询业务状态，生成建议或草稿，需要时请求人工确认，执行动作或发起流程，记录结果和审计日志。

这就是从“问答系统”到“工作助手”的变化。

这时 AI 不再只是“总结资料”。它开始参与工作流程。

五、最现实的落地方式：先从“只读工具”开始

听到这里，很多人会兴奋：那是不是可以让 AI 直接操作 ERP、OA、项目系统？

先从只读开始。也就是让 AI 能查，但不能改。

MCP 工具规范也强调，工具调用虽然可以由模型根据上下文自动发现和调用，但出于信任、安全和安保考虑，应该始终有人能够拒绝工具调用，应用也应该清楚展示暴露给 AI 的工具、在工具调用时给出视觉提示，并在操作前呈现确认提示。

六、企业里最适合先接的 5 类 MCP 工具

如果你要从企业内部场景开始，我建议先接这 5 类。

消息和提醒这一类要特别注意确认机制。AI 可以生成消息，但最好先让人确认再发。

七、不要把 MCP 做成“万能超级接口”

这是一个大坑。

很多人一开始会想：既然 AI 要接系统，那我给它一个万能接口，让它想查什么就查什么。

比如：一个接口能查全部数据库，一个工具能改全部业务数据，一个 token 能访问所有系统，AI 可以绕过原有权限体系，工具调用没有日志，操作前没有人工确认。

MCP 官方安全最佳实践文档列出了多类实现风险和攻击面，包括 confused deputy、token passthrough、SSRF、session hijacking、本地 MCP server compromise、OAuth 授权 URL 校验和 scope minimization 等。

普通人不用记这些专业名词。你只需要理解一句话：

企业里做 MCP 工具，应该遵守几个原则：最小权限，只读优先，按用户身份鉴权，工具调用留日志，高风险动作必须确认，敏感数据脱敏，禁止万能数据库查询，禁止绕过原系统权限。

八、AI Agent 不是替代员工，而是接住“下一步”

我觉得企业 AI Agent 最好的定位，不是“替代员工”。

比如：你查完制度，它帮你生成材料清单；你看完项目风险，它帮你生成确认消息；你问完设备故障，它帮你生成工单草稿；你查完库存异常，它帮你整理处理建议；你问完会议纪要，它帮你生成待办列表。

这比“完全自动化”更现实。因为企业场景里，很多事情不能让 AI 直接拍板。

但 AI 可以把人从大量重复查找、整理、复制、提醒中解放出来。

它不一定直接替你做决定，但它可以把决策前的资料准备好，把决策后的执行动作半自动化。

九、企业 AI 知识库可以分 4 个阶段升级

第一阶段目标是能检索文档，能引用来源，能回答制度、产品、项目、流程问题。

第二阶段目标是能查 OA、ERP、项目系统、数据库、日历和任务。

第三阶段目标是生成周报草稿、审批说明、客户回复、风险清单、会议纪要和待办事项。

第四阶段目标是经确认后发消息、建任务、发起流程、更新状态，低风险动作可自动执行。

十、做企业 MCP / Agent，要先设计一张“工具清单”

不要直接开发。先设计一张表。

十一、最适合公众号读者理解的一句话

但这并不意味着 AI 可以随便操作系统。

真正成熟的方向应该是：先读资料，再查系统；先生成草稿，再人工确认；最后受控执行。

这才是企业 AI 最现实的路径。

十二、最后总结

AI 知识库的第一阶段，是解决“问什么能答什么”。

但真正有价值的下一阶段，是解决：

用户问项目风险，不只是想看一段总结，而是想知道谁负责、怎么处理、是否提醒。

用户问报销制度，不只是想看条款，而是想知道自己能不能报、材料怎么准备、流程怎么发起。

用户问设备故障，不只是想看操作手册，而是想快速定位原因、生成工单、通知负责人。

这就是 AI 知识库从 RAG 走向 Agent 的原因。

但越往后走，越不能只看智能程度。还要看权限、审批、审计、安全、可控、可追溯。

AI 能不能办事，是能力问题。

AI 该不该直接办事，是治理问题。

下一代企业 AI 知识库，不会只是一个聊天框。它更像一个连接文档、数据、系统和流程的智能工作台。