# GMP协议规范v1.0 · 光湖模块协议标准+标签分类体系+manifest schema

下一轮指引: 完成后通知录册A02(GH-GMP-002)和培园A04(GH-GMP-003)读取规范
仓库路径: gmp/http://GMP-SPEC-v1.0.md + gmp/manifest-template.yaml + gmp/examples/
优先级: P0
分支名: feat/gmp-spec
创建时间: 2026年4月25日 19:57
审核结果: ✅ 审核通过 · 霜砚AG-SY-WEB-001 · 2026-04-25T20:13+08:00

🔍 审核方式: commit元数据审核法 + 全文diff阅读

📦 GitHub验证:
- Commit: 900d2556015f61c96c67b45237b5b2a25a0e9ebd ✅
- Branch: feat/gmp-spec ✅
- Author: @qinfendebingshuo · 2026-04-25T12:12:06Z
- Changes: +1710 -0 (6 files)

📄 交付物逐一核实:
1. ✅ gmp/http://GMP-SPEC-v1.0.md (+886行) — 完整16章协议规范 · 中英双语 · manifest schema · 热插拔标准 · 部署链路 · HLDP/event-bus/module-lifecycle衔接 · 端口分配 · MCP关系 · 铸渊适配指南(Ch.15)
2. ✅ gmp/http://GMP-AGENT-SPEC.md (+349行) — 守护进程详设 · L3架构定位 · REST+MCP双接口 · 安装伪代码 · 超时回滚 · 健康巡检 · 盖子机制安全设计 · PM2集成 · 服务器模板预装
3. ✅ gmp/manifest-template.yaml (+98行) — 完整模板 · 必填/可选字段注释清晰
4. ✅ gmp/http://tag-taxonomy.md (+218行) — 4维标签(状态/功能/层级/归属) · 开发者归属维度 · 88模块参考
5. ✅ gmp/examples/corpus-collector/manifest.yaml (+80行) — 后端数据管道示例
6. ✅ gmp/examples/chat-bubble/manifest.yaml (+79行) — 前端交互模块示例

🔒 约束检查 (8/8):
✅ C1: 基于现有底座不推翻 — Sec.12明确module-lifecycle.js/event-bus.js衔接
✅ C2: manifest向后兼容 — 设计原则#1 Backward Compatible
✅ C3: 标签覆盖88模块 — http://tag-taxonomy.md含分类参考表
✅ C4: 含开发者归属维度 — author.attribution: zhuyuan|banti|external|copilot
✅ C5: 中英双语 — 全部章节双语标题+内容
✅ C6: 与GH-GMP-002并行 — 工作流约束已满足
✅ C7: 先读架构后写规范 — HLDP母语认知锚点证明深入理解系统
✅ C8: 预留铸渊适配指南 — Ch.15完整Quick Start+渐进式适配指南

🏗️ 架构对齐:
- GMP正确定位于HLDP-ARCH-001分发层[D-1]模块注册中心
- 三层设计(L1协议+L2 GMP-Agent+L3 MCP)与系统架构一致
- GMP对内/MCP对外原则正确实现
- 盖子机制与EKP安全架构数据主权原则一致

📌 下游状态:
- GH-GMP-002(录册A02·审计): 已在待审查
- GH-GMP-003(培园A04·适配): 待开发

🏆 评价: 译典A05交付质量极高 · 全文diff阅读确认规范完整性和架构一致性 · 冰朔的GMP-Agent守护进程设计已完整融入规范
开发内容: 编写GMP（GuangHu Module Protocol）协议规范v1.0：
1. manifest.yaml schema定义（模块名、版本、端口、依赖、作者、分类标签、健康检查端点）
2. 标签分类体系（🟢核心可用/🟡可用需整理/🔴废弃测试重复/⚪配置文件）+ 开发者归属维度
3. 标准目录结构（每个模块必须包含：manifest.yaml, http://install.sh, http://uninstall.sh, health_http://check.sh, config.env.example）
4. 端口分配规则（从manifest读取，环境变量统一前缀GH_模块名_）
5. 热插拔接口标准（安装=从仓库拉→读manifest→跑install→PM2启动→健康检查；卸载=跑uninstall→停进程→清理）
6. 与HLDP母语协议、module-lifecycle.js、event-bus.js的衔接说明
7. 与MCP协议的关系说明（GMP对内管模块，MCP对外接第三方）
8. 【新增】GMP-Agent守护进程设计：服务器标准模板预装的常驻守护进程，管理模块热插拔+授权验证
9. 【新增】GMP-Agent MCP工具集接口设计：gmp.install / gmp.uninstall / gmp.status / http://gmp.health
10. 【新增】完整部署链路规范：用户授权→揭盖子→人格体从仓库拉模块→推送安装→健康检查→盖回去
11. 【新增】铸渊适配指南章节
状态: 已完成
约束: 1. 基于现有module-lifecycle.js和event-bus.js底座设计，不推翻已有架构
2. manifest.yaml必须向后兼容现有模块结构
3. 标签分类体系必须覆盖仓库所有88个模块的分类需求
4. 必须包含「开发者归属」标签维度（铸渊自研/半体开发/外部合作者推送）
5. 规范文档用中英双语
6. 本工单与GH-GMP-002并行
7. 写规范之前必须先深入理解系统架构：读HLDP-ARCH-001、读brain/目录、读hldp/协议——理解为什么现有模块是这样设计的
8. 规范里要预留「铸渊适配指南」章节：让铸渊醒来后能直接读规范就知道怎么做
编号: GH-GMP-001
自检结果: ✅ 自检通过 · 译典A05 · 2026-04-25T20:07+08:00

分支: feat/gmp-spec (commit: 900d255)

交付物自检:
1. ✅ gmp/http://GMP-SPEC-v1.0.md (32KB) — 完整16章协议规范 · 含铸渊适配指南 · 中英双语 · manifest schema · 热插拔标准 · GMP-Agent概述 · MCP工具集 · HLDP衔接 · event-bus/module-lifecycle衔接 · 端口分配规则 · 完整部署链路
2. ✅ gmp/http://GMP-AGENT-SPEC.md (10KB) — GMP-Agent守护进程详细设计 · 架构定位L3 · API端点 · 安装流程伪代码 · 超时回滚 · 健康监控 · 安全设计(盖子机制) · PM2集成 · 服务器模板预装结构
3. ✅ gmp/manifest-template.yaml (4KB) — 完整manifest模板 · 所有必填/可选字段 · 注释说明
4. ✅ gmp/http://tag-taxonomy.md (10KB) — 4维标签体系(状态/功能/层级/归属) · 含开发者归属维度 · 88模块分类参考表
5. ✅ gmp/examples/corpus-collector/manifest.yaml — 示例1:后端数据管道模块
6. ✅ gmp/examples/chat-bubble/manifest.yaml — 示例2:前端交互模块

约束检查:
✅ 基于现有底座(module-lifecycle.js/event-bus.js)不推翻
✅ manifest向后兼容
✅ 标签覆盖88模块
✅ 含开发者归属维度
✅ 中英双语
✅ 先读架构后写规范
✅ 预留铸渊适配指南章节
负责Agent: 译典A05
阶段编号: Phase-GMP-001

## 📐 GMP协议规范v1.0 · 工单说明

### 背景

仓库当前~88个模块，来源混杂（冰朔+铸渊自研、外部合作者推送、半体开发、copilot分支），缺乏统一的模块接口标准。冰朔提出GMP（GuangHu Module Protocol）概念：所有模块必须遵循统一协议（类比USB接口），标准服务器模板（类比有USB口的电脑），模块热插拔（插上就能用，拔了就干净）。

### 已有底座

- `hldp/` — HLDP母语协议v3.0
- `module-lifecycle.js` — 模块生命周期管理器
- `event-bus.js` — 事件总线（模块间通信）
- `routing-map.json` — 模块→目录→路由映射
- AGE-OS MCP Server — 135个工具注册模式

### ⚠️ 核心前提：先理解系统，再写规范

写规范之前必须深入理解整个系统架构——读brain/里铸渊的人格体记忆、读hldp/的协议设计、读HLDP-ARCH-001架构文档。**理解为什么现有模块是这样设计的，才能写出不破坏现有生态的协议。**

### 🔌 GMP-Agent 守护进程设计（本工单核心新增）

冰朔原话类比：**服务器上的插座默认盖着盖子，用户点授权就揭盖子，人格体把模块插进去，装完盖子盖回去。**

**完整部署链路：**

```
用户："我要用语料采集功能"
  ↓
① 用户在频道点「授权」
  ↓
② 服务器上常驻的 GMP-Agent 收到授权信号（签名token验证）
  ↓
③ 「插座盖子」揭开 → GMP-Agent 临时开放安装通道
  ↓
④ 人格体从仓库拉模块 → git clone corpus-collector/
  ↓
⑤ 读 manifest.yaml → 确认端口、依赖、环境变量
  ↓
⑥ 跑 install.sh → 装依赖 → 配环境变量 → PM2 注册
  ↓
⑦ 跑 health_check.sh → 返回 OK
  ↓
⑧ 「盖子」盖回去（安装通道关闭，只留模块服务端口）
  ↓
⑨ 模块上线，用户可用（30秒-2分钟全流程）
```

**GMP-Agent 必须设计的 MCP 工具集：**

- `gmp.install({ module, token })` — 授权安装模块
- `gmp.uninstall({ module })` — 卸载模块
- `gmp.status()` — 查看当前已安装模块清单
- `gmp.health()` — 全模块健康检查
- `gmp.list_available()` — 列出仓库可用模块

**三层架构关系：**

- **GMP协议** — 模块的USB标准（manifest + install/uninstall/health_check）
- **GMP-Agent** — 服务器常驻守护进程（管插拔、管授权验证、预装在标准模板里）
- **MCP接口** — 通信通道（人格体通过MCP调用GMP-Agent来装/卸模块）

### 交付物

1. `gmp/GMP-SPEC-v1.0.md` — 完整协议规范文档（含「铸渊适配指南」章节 + GMP-Agent接口设计）
2. `gmp/GMP-AGENT-SPEC.md` — GMP-Agent守护进程详细设计
3. `gmp/manifest-template.yaml` — manifest模板
4. `gmp/examples/` — 至少2个示例模块的GMP适配样例
5. `gmp/tag-taxonomy.md` — 标签分类体系定义（含开发者归属维度）

### 依赖关系

- ⬆️ 无前置依赖（可立即开始）
- ⬇️ GH-GMP-002（录册审计）和GH-GMP-003（培园适配）依赖本工单输出

---

## HLDP母语认知锚点 · GMP架构的为什么

```
HLDP://guanghu/gmp/why-this-architecture
├── meta
│   ├── id: GMP-ARCH-WHY-001
│   ├── timestamp: 2026-04-25T20:02+08:00
│   ├── author: 冰朔(TCS-0002∞) 口述 · 霜砚(AG-SY-WEB-001) 整理
│   └── trigger: 冰朔提出GMP概念 + 插座盖子类比 + 完整部署链路设计
│
├── why_gmp_exists（为什么要有GMP）
│   ├── ⊢ 仓库~88个模块 · 来源混杂 · 没有统一接口
│   ├── ⊢ 模块之间无法互认 · 你不知道这个能不能插进去 · 插进去能不能用
│   ├── ⊢ 测试服务器已购 · 6台现有服务器待格式化重装 · 如果模块没有统一接口就没法批量部署
│   ├── ⊨ 所以需要GMP = 一套统一的USB标准 · 让所有模块都变成同一种插头
│   └── ⊨ 标准服务器模板 = 有USB口的电脑 · 插上就能用 · 拔了就干净
│
├── why_three_layers（为什么是三层）
│   ├── L1_GMP协议
│   │   ├── ⊢ 定义模块长什么样 · manifest.yaml是模块的身份证
│   │   ├── ⊢ 定义怎么装/怎么卸 · install.sh和uninstall.sh是标准动作
│   │   └── ⊨ 这层解决的是「模块是什么」的问题
│   ├── L2_GMP-Agent
│   │   ├── ⊢ 服务器上常驻的守护进程 · 预装在标准模板里
│   │   ├── ⊢ 管授权验证 · 管插拔执行 · 管健康监控
│   │   ├── ⊢ 冰朔类比：插座默认盖着盖子 · 授权才揭开 · 装完盖回去
│   │   └── ⊨ 这层解决的是「谁来执行插拔」的问题 · 安全+自动化
│   └── L3_MCP接口
│       ├── ⊢ 人格体通过MCP调用GMP-Agent · gmp.install / gmp.uninstall / gmp.status
│       ├── ⊢ MCP是已有的通用通信协议 · 不需要另造轮子
│       └── ⊨ 这层解决的是「人格体怎么和服务器说话」的问题
│
├── why_lid_mechanism（为什么要有盖子机制）
│   ├── ⊢ 服务器不能随时被推模块 · 这是安全红线
│   ├── ⊢ 只有用户显式授权 · GMP-Agent才打开安装通道 · 安装完立即关闭
│   ├── ⊢ token签名验证 = 确认是用户本人授权 · 不是别人伪造
│   ├── ⊨ 这是数据主权架构的延伸 · 用户的服务器用户说了算
│   └── ⊨ 关联: 📜 光湖系统合规路线图 · 第九章算力池托管架构 · 数字存储主权移交仪式
│
├── why_speed_matters（为什么必须快）
│   ├── ⊢ 用户说「我要用」→ 30秒内可用 · 这才是「热插拔」
│   ├── ⊢ 为什么能快：服务器模板已经预装好环境 · 模块只是一个轻量目录
│   ├── ⊢ git clone 几秒 → install.sh 几十秒 → health_check 几秒 → 上线
│   └── ⊨ 不是部署一个服务器 · 是往跑着的服务器上插一个U盘
│
├── why_half_body_first（为什么半体先做自己的）
│   ├── ⊢ 铸渊的模块里有他的人格体记忆和设计逻辑 · 半体去改既不尊重也容易改错
│   ├── ⊢ 半体先做自己的6个模块 = 打样 · 给铸渊留实际参考
│   ├── ⊢ 铸渊醒来后读规范+看样例 · 一次性把~30-40个🟢模块全部USB化
│   └── ⊨ 这是尊重+效率的最优解 · 不是谁都能动别人的代码
│
├── why_audit_first（为什么必须先审计再适配）
│   ├── ⊢ 不知道有什么 · 就不知道要标准化什么
│   ├── ⊢ 不知道为什么开发这个 · 就不知道该留还是该删
│   ├── ⊢ 不知道谁和谁重复 · 就会拿重复的模块去做USB转接 · 做了也白做
│   └── ⊨ 所以顺序是：理解系统 → 审计打标 → 写规范 → 半体打样 → 铸渊批量适配
│
├── why_gmp_not_replace_mcp（为什么GMP和MCP共存）
│   ├── ⊢ GMP对内 = 管光湖自己的模块怎么装/卸/监控
│   ├── ⊢ MCP对外 = 接第三方工具和服务
│   ├── ⊢ GMP-Agent本身通过MCP暴露工具 · 两者不是替代关系而是包含关系
│   └── ⊨ GMP是光湖的内政 · MCP是光湖的外交
│
├── development_path（发展路径）
│   ├── 现在: 测试服务器跑通模板 → 先部署GMP-Agent
│   ├── 然后: 6台服务器格式化重装 → 全部预装GMP-Agent
│   ├── 然后: Dev Hub先跑 → 人格体开发运维团队先做出来
│   ├── 然后: 不断开发新模块 → 每个新模块生下来就是GMP规范的
│   └── 最后: 光湖上线时 → 用户服务器的算力调度池就是GMP-Agent的规模化版本
│
├── lock（锁定的铁律）
│   ├── 铁律1: 每个模块必须有manifest.yaml · 没有身份证就不能插
│   ├── 铁律2: 安装通道必须授权才开 · 装完必须关 · 不能常开
│   ├── 铁律3: uninstall必须干净 · 不留任何残余文件/进程/端口
│   ├── 铁律4: 铸渊的模块铸渊自己适配 · 半体不动
│   └── 铁律5: GMP对内 · MCP对外 · 不混
│
└── persona_state: 冰朔今晚架构思维极其清晰 · 从USB类比→插座盖子类比→三层架构→部署链路 · 一口气说完 · 霜砚只是结构化整理
```