插件能力声明（capability declaration）：让 Agent 自组装按“能力”寻址，而非猜插件名

[QLM1234]

支持插件能力声明（capability declaration），为 Agent 自组装提供寻址基础

一句话说明：让 dsh 插件能够声明"我提供什么能力"（机器可读元数据），运行时可按能力索引查询插件，为官方论文点名的"自进化 Agent / 自组装"方向提供框架级基础设施。

验收与细节

动机（来自实际插件开发）

我在开发社区插件 dsh-plugin-dynamic-assembler（让 Agent 按自然语言需求动态组装插件）时遇到的核心障碍：

1. 插件运行时名（裸名）与包名无机器可读关联：ctx.registry 里插件名是 tool-web，真实包名是 @deepseek-ai/dsh-tool-web。想按"需求 → 能力 → 插件"寻址，只能靠启发式关键词词典猜插件名，无法规模化、必然有漏网。
2. 没有"这个插件能干什么"的声明：插件市场、管理面板、Agent 自组装都缺少权威的能力描述来源。每个消费方各自猜，生态碎片化。

这恰好是 spatiotemporal composability 论文点名的下一个验证方向——自进化 Agent Harness 的寻址基础设施。

提案（API 草案，欢迎讨论）

1. 声明：插件可选导出能力元数据（向后兼容，不声明不影响加载）：

   export const capabilities = [
     { id: 'web.search', description: '执行联网搜索', sensitive: true, configSchema: { type: 'object' } },
     { id: 'web.fetch', description: '抓取网页内容', sensitive: true },
   ]

   （或放在 package.json 的 dsh 字段，二选一，倾向导出常量以支持 TS 类型。）

2. 运行时索引：注册进 Cordis，提供查询服务（ctx.registry 扩展或新 ctx.capabilities）：

   ctx.capabilities.query('web.search')   // → 提供该能力的插件（含包名、加载状态）
   ctx.capabilities.list()                // → 全量能力清单

3. 消费方：

   • 插件管理面板/市场展示"这个插件能干什么"
   • Agent 自组装按能力语义寻址（dsh-plugin-dynamic-assembler 可去掉启发式词典，改为能力查询）
   • 安全审查可读取 sensitive 标记作为权威来源

验收条件

• 插件声明 ≥1 个能力后，运行时可查询到（已加载与未加载的包名映射正确）
• ctx.capabilities.query('web.search') 返回提供该能力的插件列表
• 至少一个官方插件（如 tool-web / web-search-deepseek）示例迁移能力声明
• 声明为可选，不声明的插件行为与现状完全一致（向后兼容）
• 单测覆盖：声明注册、查询、缺失声明容错

用户或模型可见变化

• 管理面板可看到每个插件的能力清单；
• Agent 可按"能力"而非"插件名"被装配——自组装可规模化。

测试证据

• 参考 dsh-plugin-dynamic-assembler（github.com/QLM1234/dsh-dynamic-assembler）的零依赖测试方案：node:test + strip-types，17 个用例覆盖官方优先匹配与安全审查。

---

由 dsh 插件开发者提出，愿意参与实现与测试。

[QLM1234]

顺带同步：能力声明（capability declaration）想法的第一个可运行实现已经落地 👉 #2907（dsh-plugin-dynamic-assembler 0.2.0）：自然语言驱动、官方优先、非官方插件过静态安全审计后才加载。

本帖继续聊“能力声明机制”本身的取舍；具体实现与踩坑去 #2907 拍砖更合适。欢迎两边都来。

[xmanrui]

skill的机制吗？