MCP 解决“模型怎么做事”，RAG 解决“模型知道什么”。
一个偏执行能力，一个偏知识能力。

这篇就用项目实战讲透这件事。

---

先说结论

MCP（Model Context Protocol）：是模型调用外部工具的标准协议，让 Agent 能查搜索、调 API、查库、执行动作。

• RAG（Retrieval-Augmented Generation）：是“先检索再生成”的架构，让模型在回答前先从知识库找相关资料，减少幻觉。
• 两者不是替代关系，而是互补关系：
  • MCP 给你“手和脚”（执行）
  • RAG 给你“记忆和资料”（知识）

---

一、MCP 是什么：让 Agent 真正“能干活”

MCP 本质是一个协议层，负责统一模型和工具之间的通信方式。
在我的项目里，MCP 主要用于接入搜索工具。

配置大致长这样（简化）：

chat-model:

model: glm-4.6v-flashx

tool-mcp-list:

- local:

name: myToolCallbackProvider

- sse:

name: baidu-search

base-uri: http://appbuilder.baidu.com/v2/ai_search/mcp/

sse-endpoint: sse?api_key=xxx

在代码里怎么生效？

我在装配链路的 ChatModelNode 里做了这件事：

1. 读取 tool-mcp-list
2. 通过工厂创建 MCP client / callback
3. 把 ToolCallback 挂到 OpenAiChatOptions
4. 最终生成带工具能力的 ChatModel

也就是说，模型不仅能“说”，还能“调工具做”。

---

二、RAG 是什么：让 Agent 回答“有依据”

RAG 是典型的“检索增强生成”架构，核心是：

1. 文档切块（chunk）
2. 向量化（embedding）
3. 存到向量库
4. 用户提问时先检索 TopK 相关片段
5. 把片段拼进 Prompt
6. 再让 LLM 生成答案

它解决的是：

• 模型参数里没有这条知识
• 业务知识更新快
• 需要可追溯、可引用的信息回答

一句话：RAG 把“凭感觉回答”变成“基于资料回答”。

---

三、MCP vs RAG：到底差在哪？

维度	MCP	RAG
本质定位	协议/工具调用层	检索增强架构
解决问题	模型如何执行动作	模型如何获取知识
输入来源	外部服务/API/系统工具	向量知识库文档
时效性	高（可实时）	取决于知识库更新频率
典型场景	搜索、查库存、下单、执行任务	文档问答、企业知识助手、规范约束
常见风险	工具失败、超时、权限控制	召回噪声、切块不合理、上下文污染

记忆口诀：

• MCP：Call tool（调用工具）
• RAG：Retrieve context（检索上下文）

---

四、我在项目中的真实落地：目前“以 MCP 为主”

我的项目当前状态是：

• 已经有 MCP 工具调用能力（百度搜索 + 本地工具）
• 已有技能文档（如小红书文案技能 SKILL.md）
• ❌ 还没有把技能文档做成完整 RAG（向量库+检索+重排）

当前链路是怎么跑的？

整体是“装配责任链”模式：

Root -> AiApi -> ChatModel(MCP/Skills) -> Agent -> Workflow -> Runner

这样做的好处是每个节点职责清晰，后续要接 RAG，只需要新增一个类似 RetrieverNode 的装配节点或在 ChatModelNode 前注入检索上下文能力。

---

五、如果把这个项目升级成“RAG + MCP 双引擎”，我会这样做

1）离线构建知识库

• 把 skills/*.md、业务规范文档、FAQ 入库
• 做 chunk + embedding + 向量库存储（Milvus/pgvector/Chroma 均可）

2）在线检索增强

• 用户问题先 embedding
• 向量检索 TopK
• （可选）加 rerank
• 把检索片段拼进 system/user 上下文

3）保留 MCP 做实时能力

• 热点资讯、实时数据依然走 MCP 工具调用
• 最终回答融合“检索知识 + 实时工具结果”

4）输出结构约束

• 给模型加来源标注约束：哪些段落来自检索，哪些来自工具
• 便于审计与排错

---

六、可能踩的坑（很实用）

坑 1：把 MCP 当 RAG 用

搜索到的网页摘要不是结构化知识库，稳定性和可控性都不如 RAG。
解决：高频稳定知识进 RAG，实时动态信息走 MCP。

坑 2：技能文档太长，直接塞 Prompt

长 Prompt 不稳定且贵。
解决：文档分块 + 检索命中后再注入，减少无关上下文。

坑 3：工具调用没做超时/降级

MCP 外部依赖波动大。
解决：统一超时、重试、fallback（工具失败时给出可解释降级回答）。

坑 4：没有可观测性

回答不好时不知道是“没检索到”还是“模型没遵循”。
解决：记录检索命中片段、工具调用日志、最终 Prompt 摘要。

---

七、给新手的实践建议（按优先级）

1. 先上 MCP，再上 RAG：先让 Agent“能做事”，再让它“更懂业务”
2. RAG 先小范围试点：先喂高价值文档，不要一上来全库导入
3. 加评估集：10~30 条真实问题，持续回归评测
4. 把异常链路产品化：超时、空召回、低相关度都要有兜底话术
5. 坚持可观测：日志里至少有 tool 调用、检索片段、最终回答

---

结语

很多讨论把 MCP 和 RAG 对立起来，但在真实项目里，它们其实是“左右手”：

• MCP 让 Agent 能连接真实世界并执行动作
• RAG 让 Agent 在业务知识上回答得更稳、更准、更可控