MCP、RAG 与 AI Agent：知识、工具与执行的分工

MCP、RAG 与 AI Agent 经常同时出现在一套 AI 系统中，三者分别处理知识获取、系统连接和任务执行。

可以把它们分别看作知识层、工具层和执行层。这套分层用于解释职责，不规定部署顺序。每套 AI 应用可以按任务选择其中一项或多项。

RAG：为回答找到外部证据

RAG 是 Retrieval-Augmented Generation 的缩写。应用先检索与问题相关的内容，再把检索结果加入 Prompt 或 context，最后由 LLM 生成回答。

问题 -> 检索 -> 选择相关内容 -> 组装 context -> LLM 生成回答

它适合处理企业文档问答、产品手册查询、知识库搜索，以及需要展示来源的回答。知识发生变化时，应用可以更新数据和索引，不必仅靠重新训练模型来写入新事实。

RAG 改善的是模型在当前请求中可用的信息。修改工单、发送消息和创建记录等外部操作仍由应用工具执行。数据过期、切分不合理、检索遗漏和模型没有忠实使用证据，都会产生错误。

因此，RAG 系统至少要分别评估两件事：检索是否找到了正确材料，生成是否遵守了材料。只看最终答案，很难判断问题出在检索还是生成。

MCP 是 Model Context Protocol 的缩写。它定义 AI 应用与外部系统之间的通信方式，使 MCP Server 可以向 Client 暴露 Tools、Resources 和 Prompts 等能力。

AI 应用（Host）-> MCP Client -> MCP Server -> API、数据库或应用

没有 MCP 时，团队也可以为每个服务编写专用 SDK、函数调用或 HTTP 集成。MCP 的价值在于提供统一协议，让同一个 Server 能被不同的兼容 Client 使用，并减少每个 AI 应用都重新设计连接约定的成本。

MCP 规定能力如何被描述、发现和调用。具体调用哪个工具、按什么顺序调用、失败后是否重试，仍由 Host 中的应用逻辑、Workflow 或 Agent 决定。认证、授权、用户确认和审计也需要在实际实现中配置，协议本身不会替应用划定安全边界。

MCP 与 RAG 可以组合，但职责不同。一个 MCP Server 可以提供文档资源或搜索工具，成为 RAG 的数据入口；它也可以提供创建工单、发送消息等操作工具，完全不经过向量检索。

AI Agent 接收目标和上下文，判断下一步行动，调用工具观察或改变环境，再根据结果继续执行。常见过程可以概括为：

观察 -> 规划 -> 行动 -> 验证 -> 继续或停止

Agent 适合步骤难以预先完全写死的任务。例如排查一次线上故障时，它可能先读取告警，再查询日志，根据错误类型决定是否查看最近发布记录，最后运行只读检查并整理证据。每一步都依赖上一步返回的真实结果。

工具、Memory 和 RAG 都可以进入这个循环。Agent 可以通过 MCP 调用外部系统，通过 RAG 找到相关文档，并用 Memory 保存任务状态或已经确认的决定。工具越多，可变更的范围通常越大；可靠性仍依赖执行上限、最小权限、失败处理、验证标准和人工确认点。

假设任务是：「找出上季度存在续费风险的客户，并为负责人创建跟进任务。」

一套组合系统可以这样运行：

这个例子将职责分开：RAG 提供风险规则的证据，MCP 连接业务系统，Agent 安排筛选、核对和写入顺序，原有权限系统继续约束数据访问与外部操作。

只需要回答内部文档问题时，可以先实现检索、引用和评估，不必增加 Agent。固定的跨系统同步任务可以使用普通 Workflow，通过 MCP 复用连接能力，也不一定需要模型动态规划。

当任务需要根据中间结果改变步骤，并且最终结果可以验证时，再考虑 Agent。此时若任务依赖大量私有或持续更新的知识，可以加入 RAG；若多个 AI 应用需要复用同一批工具，可以加入 MCP。

直接调用 API 仍然是有效方案。只有一个应用、少量稳定接口时，专用集成往往更容易理解和维护。MCP 适合解决连接复用与互操作问题，不应为了使用协议而增加一层没有实际收益的抽象。

设计时可以依次检查三个条件：

答案可能是其中一个、两个或全部。系统结构应由任务、权限和验收方式决定。