dsh-nacos-bridge：Nacos AI Registry 到 dsh harness 的薄桥接层

dsh-nacos-bridge：Nacos AI Registry 到 dsh harness 的薄桥接层

一句话结论

dsh-nacos-bridge 是一个 deliberately thin 的 bridge：它从 Nacos 3.2+ AI Registry 发现 MCP servers 与 A2A Agent Cards，再把它们挂载到 deepseek-harness（dsh）runtime 中，MCP 变成 mcp__<name>__* tools，A2A Agent Card 变成 a2a__<name>__chat 多轮能力。它的价值不在于又造一个 agent framework，而在于展示 registry/control-plane 如何成为 Harness-Engineering 的能力装配层。

命中的知识点轴

• MCP Gateway / federation control plane：Nacos 充当 AI resource control plane，统一登记 MCP server 与 A2A agent。
• A2A / Agent Card / Agent Discovery：README 明确把 A2A Agent Cards 从 registry 发现后挂入 runtime。
• harness-runtime：dsh 负责模型、memory、sessions、skills；bridge 只做发现、diff、mount/unmount 与健康检查。
• context management：工具/agent 可见能力不再靠 prompt 静态声明，而是由 registry diff 动态进入 runtime。
• benchmark-evaluation：薄桥接层本身未给出完整 benchmark，但它提供了可评测点：发现延迟、mount/unmount 正确性、health check、call/audit log、stale artifact 拒绝。

为什么对用户重要

对 Hermes / llm-wiki 来说，这个项目补上了 A2A-Agent2Agent-Protocol 与 MCP-Gateway-Runtime 之间的“能力注册到 harness 装配”步骤：前几天入库的 A2A Samples 说明 Agent Card 如何被 host 读取，AgentMesh 说明 task envelope 如何做 runtime planning；dsh-nacos-bridge 则说明能力提供方可以只向 registry 注册，agent runtime 通过 bridge 动态获得可用能力，新增 capability 不需要改 agent 代码。

这对用户未来管理多个 Hermes tools、MCP servers、A2A specialists 或外部 skills 有直接启发：registry 不应只是人看的目录，而应成为 runtime 的可执行输入；但 bridge 必须保持“薄”，不要把 policy、memory、session、业务逻辑都塞进同一层，否则控制面边界会混乱。

机制 / 一阶原理

核心机制是 registry diff → runtime mount。能力提供方启动时注册到 Nacos；bridge 轮询/发现 registry，把 MCP server 通过 MCP SDK client 映射为 dsh tools，把 Agent Card 映射为 A2A chat capability；随后由 dsh 原生插件处理 skill、memory、session、多模型等行为。

第二个机制是 thin bridge boundary。README 特意强调核心 glue 约 540 行：lifecycle.ts 做 poll/diff/mount/unmount/health check，nacos-client.ts 读 registry，mcp-client.ts 与 a2a-client.ts 做协议映射。这种薄边界值得借鉴：registry bridge 应该让能力可发现、可挂载、可卸载，而不应该成为 opaque mega-agent。

第三个机制是 ops state as files。项目把 runtime state、metrics、call/audit、governance rules 等放在文件/IPC 层，降低部署复杂度。对个人/小团队 Hermes 来说，文件化 registry/receipt 比重型数据库更容易先落地；但生产环境仍要补 auth、完整审计、漂移检测和并发控制。

和已有 wiki 概念的关系

• 和 MCP-Gateway-Runtime 相比，本页强调 registry-to-harness bridge，而不是 gateway 自身的 policy/credential/audit。
• 和 Context-Engineering 相比，本页说明 capability list / Agent Card / MCP tool schema 是动态上下文，需要版本、hash、健康状态和风险 tier。

对 Hermes / llm-wiki 的可执行启发

1. 把关注名单也视为 registry。 AI 雷达的 sources/keywords/projects 可以维护成轻量 registry，周期性 diff，而不是把搜索词散落在 cron prompt。
2. 为工具接入定义 bridge 合同。 新工具/MCP/A2A agent 进入 Hermes 前至少记录 source、capability id、schema/card hash、owner、last_seen、health、risk tier、allowed jobs。
3. 保持 bridge 薄而可替换。 discovery/mount 与 policy/planning/audit 分层：bridge 不替代 AI-Knowledge-Point-Radar 的晋升 gate，也不替代 task envelope 或 action policy。
4. 把 mount/unmount 当作可验证事件。 每次能力新增、删除、schema 漂移都应留下 diff receipt，并进入 Agent-Benchmarks 的 runtime health 指标。

失败模式 / 边界条件

• README 证据显示这是低星、薄桥接项目；未在本轮本地运行 dsh/Nacos，因此 confidence: medium。
• Registry 发现不等于信任。若 Nacos registry 被污染，bridge 可能把恶意 Agent Card 或 MCP tool 描述挂入模型上下文。
• bridge 只负责 re-expose，权限、凭据、审批、预算、trace 仍需由 dsh/runtime/gateway 另行承担。
• 动态 mount 会带来上下文漂移：同一个 agent run 在不同时间看到的工具面可能不同，因此需要 versioned capability snapshot。

候选评分

写入记录

• 2026-09-07 09:00 CST：基于 dsh-nacos-bridge README 新建 source 页，提炼 Nacos AI Registry 到 dsh runtime 的薄桥接、动态能力装配、Agent Card/MCP tool registry 与 Hermes registry 设计启发。