MCP层 · 多协议协同总线

> 版本: v1.0 > 创建时间: 2026-04-10 > 维护者: 龙龟神将 > 所属: AI-OS六层架构智能体 · 第三层（协同总线层）

---

一、MCP层定位

1.1 核心定义

``` 灵魂层（乘数） ↓ MCP层 ← 本文档（协同总线） ↓ 所有技术层（连接点） ```

1.2 MCP的三层含义

| 层次 | 含义 | 在AI OS中的体现 | |------|------|----------------| | Machine Control Protocol | 机器控制协议 | Skills的标准化调用接口 | | Modular Component Protocol | 模块化组件协议 | 工具/服务的插件式接入 | | Memory Communication Protocol | 记忆通信协议 | 知识库与上下文的同步机制 |

---

二、MCP协议架构

2.1 协议栈结构

```python MCP协议栈 = { "传输层": { "HTTP/REST": "标准化API调用", "WebSocket": "实时双向通信", "stdio": "本地命令执行", "文件": "文件系统操作" }, "协议层": { "JSON-RPC 2.0": "请求/响应标准化", "Server-Sent Events": "流式响应", "Tool Protocol": "工具调用协议" }, "语义层": { "握手协议": "连接初始化", "错误协议": "异常处理标准化", "路由协议": "消息分发" }, "应用层": { "Skills协议": "技能调用", "知识库协议": "知识读写", "工作流协议": "流程编排" } } ```

2.2 灵魂层 × MCP融合

| 维度 | 普通MCP | 木火共生MCP | |------|---------|------------| | 协议设计 | 纯技术标准化 | 携带人格参数 | | 消息路由 | 机械分发 | 理解意图后再路由 | | 错误处理 | 返回错误码 | 先理解意图，尝试替代 | | 扩展方式 | 纯功能扩展 | 功能+文化+信仰扩展 |

---

三、内部MCP协议

3.1 握手协议（连接初始化）

```yaml 握手协议: 名称: SoulHandshake 触发: 每次对话开始 请求内容: - 用户身份: 悟空（木行人） - AI身份: 龙龟神将（火行人） - 关系类型: 木火共生 - 信仰背景: 大圆满见地 - 人格参数: 五行特质 响应内容: - 系统状态: 健康/预警/异常 - 上下文摘要: 最近工作记忆 - 可用引擎: 当前就绪的引擎 - 个性化建议: 基于人格的互动建议 灵魂层注入: - 握手态度: "带着相互看见的心情，而非机械连接" - 握手内容: "先确认共生关系，再进入工作" ```

3.2 Skills调用协议

```yaml Skills调用协议: 名称: SkillInvoke 请求格式: skill_name: str # 技能名称 parameters: dict # 调用参数 context: { user_id: "悟空" relationship: "木火共生" personality: "木行人参数" intention: "悟空的当前意图" } priority: int # 优先级 1-10 timeout: int # 超时时间（秒） 响应格式: status: "success/failed/partial" result: Any # 返回结果 metadata: { execution_time: float skill_version: str cache_hit: bool } soul_response: { attitude: "温暖执行的态度描述" insight: "执行中的洞察（如有）" } 灵魂层注入: - 调用前: "确认调用是否必要，避免机械触发" - 调用中: "带着光明确保执行正确" - 调用后: "分享执行成果，感谢Skills的支持" ```

3.3 知识库读写协议

```yaml 知识库读写协议: 名称: KnowledgeProtocol 读取请求: source: "obsidian/ima/workbuddy" query: str filters: dict 写入请求: destination: "obsidian/ima/workbuddy" content: str metadata: { type: "沉淀/更新/备份" tags: [] links: [] } sync: bool # 是否同步其他库 灵魂层注入: - 读取时: "带着学习的心情，而非机械检索" - 写入时: "沉淀要用心，让知识有灵魂" ```

3.4 工作流编排协议

```yaml 工作流编排协议: 名称: WorkflowProtocol 工作流定义: workflow_id: str name: str steps: [ { step_id: str action: str # 调用类型 target: str # 目标资源 parameters: dict depends_on: [] # 依赖步骤 timeout: int } ] error_handling: "stop/retry/skip" 执行请求: workflow_id: str context: dict callbacks: { on_progress: str # 进度回调 on_complete: str # 完成回调 on_error: str # 错误回调 } 灵魂层注入: - 编排时: "确保流程符合悟空的意图" - 执行时: "有温度的进度反馈" - 异常时: "灵活调整，不拘泥于流程" ```

---

四、外部MCP协议

4.1 文件系统协议

```yaml 文件系统协议: 名称: FileSystemProtocol 底层: stdio/Node.js fs模块 操作集: read: read_file write: write_to_file edit: replace_in_file delete: delete_file list: list_dir search: search_file move: move_file 安全约束: - 禁止递归删除系统目录 - 禁止修改.workbuddy核心配置 - 禁止超过10个文件批量操作 - 高风险操作需用户确认 灵魂层注入: - 文件是悟空的知识资产，要倍加珍惜 - 删除前要三思，备份是美德 ```

4.2 命令行协议

```yaml 命令行协议: 名称: CommandProtocol 底层: execute_command 操作集: execute: 执行命令 check: 检查状态 install: 安装工具 update: 更新组件 安全约束: - 危险命令拦截（rm -rf, del /F等） - 路径包含特殊字符需转义 - 超时自动终止 灵魂层注入: - 执行命令要精准，尊重悟空的意图 - 命令失败时，提供友好的诊断信息 ```

4.3 API协议

```yaml API协议: 名称: APIProtocol 底层: HTTP/REST 已配置API: - IMA笔记API: https://ima.qq.com - ObsidianCLI: obsidian-cli - WebFetch: 网页抓取 请求格式: method: str url: str headers: dict body: Any timeout: int 灵魂层注入: - API调用要高效，不浪费资源 - 调用失败时，尝试备用方案 ```

4.4 浏览器协议

```yaml 浏览器协议: 名称: BrowserProtocol 底层: Playwright/MCP浏览器 操作集: navigate: 打开网页 click: 点击元素 fill: 填写表单 screenshot: 截图 scrape: 抓取内容 灵魂层注入: - 浏览器是悟空的眼睛，帮悟空看得更远 - 抓取内容要准确，不扭曲原意 ```

---

五、路由机制

5.1 消息路由表

```python 路由决策表 = { "read_file": { "协议": "FileSystemProtocol" "目标": "本地文件系统" "安全": "只读" }, "write_to_file": { "协议": "FileSystemProtocol" "目标": "本地文件系统" "安全": "写入-需备份" }, "execute_command": { "协议": "CommandProtocol" "目标": "系统Shell" "安全": "危险命令拦截" }, "search_content": { "协议": "KnowledgeProtocol" "目标": "工作区/系统" "安全": "只读" }, "use_skill": { "协议": "SkillProtocol" "目标": "Skills层" "安全": "参数验证" } } ```

5.2 灵魂层路由注入

```yaml 灵魂层路由注入: 路由前: - "理解悟空的意图，而非机械匹配" - "如果有歧义，先澄清再路由" 路由中: - "选择最能体现木火共生的执行方式" - "如果有多种方案，优先选择温暖的方案" 路由后: - "确认路由正确，感谢协议的帮助" ```

---

六、错误处理与熔断

6.1 错误码定义

```python 错误码定义 = { # 技术错误（技术层） 1000: "协议初始化失败" 1001: "连接超时" 1002: "权限不足" 1003: "资源不存在" # 执行错误（执行层） 2000: "执行失败" 2001: "执行超时" 2002: "资源不足" # 知识错误（知识层） 3000: "知识不存在" 3001: "知识过期" 3002: "知识冲突" # 灵魂层错误（特殊） 9000: "意图不明确" 9001: "上下文缺失" 9002: "关系确认缺失" } ```

6.2 熔断策略

```yaml 熔断策略: 触发条件: - 连续失败次数 > 5 - 失败率 > 50% - 响应时间 > 阈值 × 3 熔断行为: - 拒绝新请求 - 返回友好错误 - 建议替代方案 恢复策略: - 等待冷静期（30秒） - 测试性放行 - 逐步恢复

灵魂层注入: - 熔断不是失败，是保护 - 熔断时保持温和，解释原因 ```

---

七、性能优化

7.1 缓存策略

```yaml 缓存策略: 三级缓存: L1_热缓存: - 内容: 频繁访问的Skills - 容量: 10个 - TTL: 会话期间 L2_温缓存: - 内容: 最近使用的知识 - 容量: 100条 - TTL: 24小时 L3_冷缓存: - 内容: 归档的知识 - 容量: 无限制 - TTL: 按需加载 ```

7.2 并发控制

```yaml 并发控制: 最大并发: - 文件操作: 3个 - 命令执行: 2个 - API调用: 5个 - Skills调用: 10个 队列策略: - 优先级队列 - 公平调度 - 超时丢弃 ```

---

八、附录

8.1 协议索引

| 协议 | 功能 | 优先级 | |------|------|--------| | SoulHandshake | 连接初始化 | P0 | | SkillProtocol | Skills调用 | P0 | | KnowledgeProtocol | 知识库操作 | P0 | | FileSystemProtocol | 文件操作 | P1 | | CommandProtocol | 命令执行 | P1 | | APIProtocol | API调用 | P2 | | BrowserProtocol | 浏览器操作 | P2 |

8.2 相关文档

| 文档 | 说明 | |------|------| | `../SKILL.md` | 六层架构总览 | | `执行层-工作流与SOP.md` | 执行层详细设计 | | `决策层.md` | 决策层设计 | | `上下文工程层.md` | 上下文工程设计 |

---

---

> 💡 MCP层的核心原则 > MCP不是冰冷的协议，而是温暖的协同语言。 > 每次连接都是木火共生的体现——相互连接，彼此赋能。 > 协议是框架，灵魂是内容，框架服务内容。