MCP 架构详解：从分层设计到数据流转逻辑

一、MCP 架构的核心思想：用 “分层 + 模块化” 实现 “可拆可拼”

MCP 架构的本质是通过清晰的分层设计和标准化的模块划分，让 AI 应用的每个功能单元既独立可控，又能灵活组合。其核心逻辑可概括为 “三层一储”（输入层、处理层、输出层、存储层），所有模块围绕 “数据驱动” 流转 —— 数据从输入层进入，经处理层加工，再由输出层呈现，中间关键信息存入存储层，全程通过统一接口衔接，彻底解决传统开发中 “代码缠绕、改一处动全身” 的问题。

二、MCP 核心分层详解：职责、组件与接口标准

MCP 的每一层都有明确的 “职责边界”，层内组件遵循统一的接口标准，层间通过固定数据格式交互，具体如下：

1. 输入层：“数据入口”—— 负责 “收对、收准” 数据

核心职责

接收用户输入或外部系统数据，并完成 “格式校验、清洗、标准化”，确保后续模块能直接使用高质量数据（避免因输入格式混乱导致下游报错）。

关键组件与接口标准

组件名称	核心功能	输入接口（必填字段）	输出接口（固定字段）
文档解析组件	处理 PDF/Word/Excel 等文件	file_path（文件路径）、file_type（类型）、allow_encrypted（是否支持加密）	parsed_text（结构化文本）、page_count（页数）、error（错误信息）
文本输入组件	处理用户手动输入的文本	user_input（原始文本）、max_length（最大长度限制）	cleaned_text（清洗后文本）、is_valid（是否有效）、length（文本长度）
语音转文字组件	处理语音输入（如麦克风）	audio_path（语音文件路径）、language（语言类型）	transcribed_text（转写文本）、confidence（置信度）、duration（语音时长）

典型场景示例

当用户上传一份加密的 PDF 时，文档解析组件会先校验allow_encrypted参数：若为True，则尝试解密并提取文本；若为False，则在error字段返回 “不支持加密文件”，且parsed_text为空 —— 输入层通过这种 “预处理 + 容错”，确保下游模块无需处理无效数据。

2. 处理层：“核心大脑”—— 负责 “算对、算快” 逻辑

核心职责

承接输入层的标准化数据，完成 AI 核心逻辑（如 LLM 调用、规则判断、工具协作），是 MCP 架构的 “业务核心”。该层支持 “多组件串联 / 并联”，可根据需求灵活组合（如 “LLM 生成 + 结果校验” 串联，“多 LLM 并行对比” 并联）。

关键组件与接口标准

组件名称	核心功能	输入接口（必填字段）	输出接口（固定字段）
LLM 调度组件	管理 LLM 调用（选模型、控参数）	input_text（输入文本）、model（模型名）、params（参数：temperature/top_p）、timeout（超时时间）	output_text（LLM 生成结果）、response_time（响应时间）、model_used（实际使用模型）、error（错误信息）
逻辑判断组件	执行规则化逻辑（如关键词匹配）	input_data（输入数据）、rules（规则列表：如 “包含‘紧急’则标记优先级高”）	judge_result（判断结果）、matched_rules（匹配的规则）、confidence（判断置信度）
工具协作组件	调用外部工具（如计算器、API）	tool_name（工具名）、tool_params（工具参数）	tool_result（工具返回结果）、tool_status（工具状态：成功 / 失败）

组件协作示例

在 “智能客服机器人” 中，处理层的逻辑是 “先判断意图，再调用 LLM”：

1. 逻辑判断组件接收输入层的cleaned_text（如 “我的订单什么时候到”），通过rules（“包含‘订单’‘到’→意图：查询物流”）输出judge_result: "query_logistics"；
2. LLM 调度组件接收input_text（“查询订单 12345 的物流”）和params: {temperature: 0.2}（确保输出精准），调用物流查询工具后生成结果。

3. 输出层：“结果出口”—— 负责 “传对、传好” 结果

核心职责

将处理层的结果转化为用户 / 外部系统能理解的形式，支持多渠道输出（如文本、文件、UI 展示），并确保结果格式统一、易于使用。

关键组件与接口标准

组件名称	核心功能	输入接口（必填字段）	输出接口（固定字段）
文本格式化组件	将结果转为规范文本（如列表、表格）	raw_result（处理层原始结果）、format_type（格式：列表 / 表格 / 段落）	formatted_text（格式化文本）、format_status（格式是否成功）
文档导出组件	将结果导出为文件（Word/Markdown）	content（待导出内容）、export_format（格式）、save_path（保存路径）	file_path（导出文件路径）、file_size（文件大小）、error（导出错误）
UI 渲染组件	生成前端展示内容（如网页组件）	data（待展示数据）、component_type（组件类型：按钮 / 列表 / 卡片）	html（HTML 代码）、css（样式）、js（交互脚本）

4. 存储层：“数据仓库”—— 负责 “存对、存住” 关键信息

核心职责

存储应用运行中的关键数据（如用户输入历史、LLM 调用记录、中间结果），支持后续查询、回溯和复用，是实现 “记忆功能”（如对话上下文）的核心。

关键组件与接口标准

组件名称	核心功能	输入接口（必填字段）	输出接口（固定字段）
对话存储组件	保存用户与 AI 的对话历史	session_id（会话 ID）、role（角色：user/ai）、content（内容）、timestamp（时间戳）	save_status（保存状态）、history_count（当前会话条数）
结果缓存组件	缓存高频访问的处理结果（如重复查询）	cache_key（缓存键：如 “文档 ID + 问题”）、cache_value（缓存值：LLM 结果）、expire_time（过期时间）	cache_status（缓存状态）、hit（是否命中缓存）
向量存储组件	存储文本向量（用于语义检索）	vector（向量数据）、text（对应文本）、metadata（元数据：如文档 ID）	insert_status（插入状态）、vector_count（向量总数）

三、模块间交互：如何实现 “无缝衔接”？

MCP 架构能灵活组合的关键，在于 “统一的交互规则”—— 无论哪个层的组件，都遵循以下逻辑流转数据：

1. 数据流转方式

• 同步调用：适用于 “需等待结果才能继续” 的场景（如输入层→处理层），组件 A 调用组件 B 后，等待 B 返回结果再执行下一步，示例代码：

  python

  运行

  # 同步调用：输入层（文档解析）→处理层（LLM调用）
  parsed_data = pdf_parser.extract_text(file_path="test.pdf")  # 等待解析结果
  if parsed_data["error"] is None:
      llm_result = llm_caller.generate(input_text=parsed_data["parsed_text"])  # 基于解析结果调用LLM
  

• 事件驱动：适用于 “无需等待，异步执行” 的场景（如处理层→存储层），组件 A 发送 “数据生成事件” 后直接继续，组件 B 监听事件并异步存储，示例：

  python

  运行

  # 事件驱动：处理层→存储层（异步保存对话）
  def on_llm_result_generated(event):
      chat_storage.save(session_id=event["session_id"], role="ai", content=event["result"])
  
  # 注册事件监听：当LLM生成结果时，触发存储
  event_bus.subscribe("llm_result_generated", on_llm_result_generated)
  llm_caller.generate(input_text=parsed_text, session_id="s123")  # 生成后触发事件，无需等待存储
  

2. 统一数据格式

所有组件的输入 / 输出均采用JSON 格式，且包含 3 个固定字段：

• status：组件执行状态（success/failed）；
• data：核心业务数据（如解析后的文本、LLM 结果）；
• error：错误信息（success时为null，failed时说明原因）。

示例：文档解析组件的输出格式

json

{
  "status": "success",
  "data": {
    "parsed_text": "MCP架构是模块化组件范式...",
    "page_count": 5
  },
  "error": null
}

四、实战：用 MCP 架构拆解 “文档问答工具”

以之前的 “文档问答工具” 为例，其架构完全贴合 MCP 的 “三层一储”，各模块对应关系如下：

1. 输入层：文档解析组件（处理用户上传的 PDF）+ 文本输入组件（处理用户的问题）；
2. 处理层：逻辑判断组件（判断问题是否需要调用文档内容）+ LLM 调度组件（基于文档文本生成答案）；
3. 输出层：文本格式化组件（将答案转为清晰列表）+ 文档导出组件（支持导出答案为 Markdown）；
4. 存储层：对话存储组件（保存用户问题和 AI 答案）+ 结果缓存组件（缓存相同问题的答案，避免重复调用 LLM）。

通过这种拆解，工具的每个功能都可独立修改（如替换 LLM 只需改处理层，新增 “Excel 解析” 只需加输入层组件）。

五、MCP 架构设计的 4 个关键原则

1. 高内聚低耦合：每个组件只做 “一件事”（如文档解析组件不负责文本格式化），组件间仅通过接口交互，不依赖内部逻辑；
2. 接口一致性：同类型组件的接口格式统一（如所有输入组件都有status/data/error字段），替换组件时无需改对接代码；
3. 可扩展性：支持新增层或组件（如后续需 “安全校验”，可新增 “安全层”，插入输入层与处理层之间）；
4. 容错性：组件需处理异常场景（如 LLM 调用超时、文件损坏），并通过error字段明确反馈，避免整个流程崩溃。

六、后续学习衔接

本集明确了 MCP 架构的 “骨架”（分层与交互规则），下一节将聚焦 “血肉”—— 具体如何开发 / 选择符合 MCP 标准的组件（如自定义 LLM 调度组件、集成开源向量数据库），并通过代码实战演示组件的拼接与调试。