基座纳管状态
各家族基座/产品的开放平台接入真实进度——身份互通与能力纳管的当前状态，诚实标注未连通项。
当前真实状态（2026-08 核实）
开放平台作为「统一能力适配网关」，接入分两层，进度不同：
| 层 | 含义 | 当前状态 |
|---|---|---|
| 身份互通层（维度 1↔2） | 各基座已对接 UM，用户用一个身份跨站登录 | ✅ 四大基座（UM / MF / AC / GL）及全部存量产品均已完成 |
| 能力纳管层（能力总线） | 各基座把 MCP/REST 端点登记进 open，被 Agent 统一调用 | ⚠️ 目前仅 SEE 真实连通，其余基座端点待提供 |
能力总线尚未全量打通
截至核实日，能力总线（mcp_capabilities）中仅 SEE 一个基座完成了真实端点登记与连通性验证。其余 21 个基座/产品的 upstream_url 仍为 TODO——即它们尚未暴露对外 MCP/REST 端点，因此未汇入总线。
这是诚实状态，并非遗漏：我们刻意为未提供端点的基座保留 TODO，不登记假端点，避免网关返回虚假能力。
已连通基座
| member | 端点 | 能力 | 验证 |
|---|---|---|---|
see | https://see.yunjii.cn/outapi/mcp | CRMEB 电商 6 项工具（分类/商品/订单/用户） | ✅ HTTP 200，tools/list 正常 |
另有一条
demo_rest（GitHub API）仅用于 REST 适配分支的冒烟测试，非真实基座。
待提供端点的基座（TODO，未连通）
以下基座身份侧已互通（可跨站登录），但能力端点尚未暴露，故未进入总线：
- 四大基座：
um·mf·ac·gl（规划为 Full 互通，端点待各产品提供） - 存量产品：
vip·pay·up·sc·dl·win·vi·ai·work·music·if·mp·zhi·quan·tui·film
这些产品不是不能接，是还没提供端点。提供端点只需参照 如何把你的能力挂上总线——三选一（已有 MCP / 有 REST 用 OpenAPI 自动摄取 / 先用 /in 占位），几分钟，open 网关负责剩下的适配与分发。
探测结论（2026-08 实测）
为确认这些 TODO 是否真有对外端点，跑了一次只读探测（scripts/discover-openapi.mjs，扫描 9 种常见 OpenAPI/Swagger 路径：/openapi.json、/swagger/v1/swagger.json、/swagger.json、/v3/api-docs、/api-docs 等，超时 5s）：
- 20 个 TODO 基座全部未暴露标准 OpenAPI 端点（0/20 命中）。
- 说明这些存量产品当前没有提供对外 REST/MCP 文档——可能无对外 API，或端点路径非标、仅内部调用。
- 结论：现阶段无法将这 20 个基座自动汇入能力总线（无真实端点可登记），维持 TODO 状态，不灌假端点。
不是漏做，是确实没有端点
探测为只读、零写库。若未来某基座暴露了 OpenAPI（或主动在 能力登记 提供），重跑 node --experimental-strip-types scripts/discover-openapi.mjs --write-result 即可重新扫描，命中即进入「可登记清单」。
如何把某基座真正打通
- 该基座对外暴露 MCP（
/outapi/mcp或等价）或 REST 端点； - 在 能力自助登记 填写
member+upstream_url，或在capabilities-to-onboard.json补全真实地址后跑seed-capabilities.mjs； - 网关
tools/list自动聚合，客户端无需改动。
按 产品矩阵 的维度：开放平台（总公司）的能力出口层，目前只连上了 SEE 一个基座。其余基座的能力汇入，取决于各产品何时提供对外端点——这是「加入即互通」的最后一公里。