跨平台技能语义与Harness映射

定义

跨平台技能语义与Harness映射，是指把 AI 编程 Agent 的能力描述拆成两层：

• 上层是 Skill 文本，尽量只描述“要做什么”和“按什么方法做”，例如派发子代理、读取指令文件、生成评审交接物、继续未完成任务。
• 下层是 harness、插件或 reference 文件，负责把这些动作语义映射成具体平台可执行的工具调用、资源注册、会话初始化和子代理调度。

在这种分层里，skill 不再是某个平台专属操作手册，而更像一套可迁移的 AI 工程纪律 与流程规范。

在本文档中的语境

在 Superpowers 6.0 的语境里，这个概念不是抽象的“兼容多平台”，而是服务于一个更具体目标：让同一套 brainstorm、TDD、SDD、finish branch 等工程流程，能够跑在不同 Agent 容器中，而不必为每个平台重写整套方法论。

原文明确指出，6.0 新增了 Kimi Code、Pi、Antigravity 三个 harness 支持，但这次变化的意义“不只是多几个入口”。真正重要的是：Superpowers 把跨平台能力放到映射层处理，让 skill 本身更像可复用的方法论。

为什么 6.0 要强调这件事

Superpowers 早期的 skill 文本中，曾直接夹带特定平台的方言和约定。原文给出的典型例子包括：

• 直接写 Claude Code 的 Task tool；
• 直接引用 CLAUDE.md 这类平台特定指令文件。

这种写法在单一平台上很顺手，但问题也很明显：

• skill 文本和平台能力耦合过深；
• 一旦切换 Agent 容器，就要大面积改写文本；
• 团队学到的是某个产品的“按钮说明书”，而不是稳定的工程动作；
• 同一个流程难以在不同平台保持一致。

因此 6.0 更强调用动作描述意图，而不是写死工具名。原文给出的新写法方向是：

• 不说某个专有工具名，而说 dispatch a subagent；
• 不说某个平台专属文件名，而说 your instructions file。

也就是说，skill 层优先表达“派出一个子代理去执行任务”“读取当前平台的指令文件”“完成后回交评审材料”这类动作语义；至于这些动作在 Claude Code、Codex、Kimi、Pi、OpenCode、Antigravity 中分别对应什么接口，由下层映射解决。

关键机制：语义层与平台层分离

1. Skill 层只保留方法论和动作意图

6.0 的核心做法，是让 skill 层尽量只保留流程和约束，例如：

• 何时派 implementer，何时派 reviewer；
• 交接材料应该文件化；
• reviewer 应只围绕当前任务 diff 做窄审；
• 长任务中断后如何恢复；
• 哪些信息必须来自计划、brief、diff package 和 progress ledger。

这些内容本质上属于方法论，不依赖某个平台的专有 API 名称。

2. Harness 层负责工具映射

具体执行时，平台层再决定：

• 子代理到底通过什么机制创建；
• 指令文件放在哪里；
• 启动会话时如何注入 bootstrap 信息；
• 需要注册哪些 resources；
• 平台支持哪些工具别名或调用约束。

原文把这一层明确概括为：harness 层负责工具名、资源注入、session bootstrap、subagent 调度。

3. Reference 或插件文件承接平台差异

6.0 并不是假装平台没有差异，而是承认差异存在，并把差异集中安置在 reference、插件清单或扩展代码中。这样 skill 本体不需要知道每个平台的细节，只需要知道“这里需要一个子代理”“这里需要读取指令来源”。

6.0 中的具体平台例子

原文明确提到，在查看 Codex、Kimi、Pi、OpenCode 相关实现时，可以看到同一个思路反复出现：skill 层说方法论，harness 层做落地。具体例子包括：

• Kimi Code：通过 .kimi-plugin/plugin.json 声明 sessionStart.skill。这说明 Kimi 平台会在会话启动阶段接入 skill 相关配置。
• Pi：通过 .pi/extensions/superpowers.ts 注册 resources，并注入 bootstrap。这里的平台职责很明确：把运行时资源和初始化信息接到 Agent 会话里。
• OpenCode：插件侧还做了 bootstrap 缓存，避免每个 agent step 都重复读文件。也就是说，平台层不仅做映射，还会根据自身运行模型做性能优化。

虽然文中没有展开 Antigravity 的实现细节，但它被列为 6.0 新增支持的平台之一，和 Kimi Code、Pi 一起构成这次跨平台扩展的代表。其意义同样不只是“多了可启动入口”，而是验证这套 skill 语义分层能够外推到更多 Agent 容器。

这和单纯“支持多个平台”有什么不同

表面上看，新增 Kimi Code、Pi、Antigravity 似乎只是兼容矩阵扩大。但 6.0 的重点不是“多维护几个适配器”，而是重新定义 skill 应该写到什么粒度。

如果只是简单新增入口，而 skill 里依旧大量写死 Claude Code 方言，那么：

• 每增加一个平台，都要复制和改写大量 skill 文本；
• 流程定义会越来越分叉；
• 团队无法确认哪些是方法论，哪些只是某个平台的操作习惯。

6.0 的做法则相反：

• 把平台差异从 skill 中剥离；
• 把稳定的工程流程沉淀为平台无关语义；
• 把执行细节收束到 harness 映射层。

因此，这是一种架构分层的变化，而不是简单的产品接入数增加。

对团队和流程的实际意义

降低迁移成本

原文直接指出，这会降低团队迁移成本。团队可以把“如何 brainstorm、如何 TDD、如何 SDD、如何 finish branch”看成一套协作流程，而不是某个单一 Agent 产品的私有操作手册。

这意味着：

• 更换主力 Agent 平台时，不必重写整套工程纪律；
• 同一团队可在多个平台之间切换而保持流程一致；
• 文档培训重点从“怎么点这个工具”转向“为什么此时需要这个动作”。

让方法论比工具寿命更长

具体平台工具名会变，插件机制会变，启动方式也会变；但像 任务颗粒化计划、文件化任务交接、任务级双结论代码评审 这样的工程动作，相对稳定得多。

把 skill 写成动作语义层，本质上是在保护这些方法论不被平台迭代频繁冲刷掉。

让工程纪律更容易复用

这与 AI编程Agent工程纪律文本分发机制 的思路一致：重点不是给模型增加魔法能力，而是把设计、拆解、调试、评审、收尾等规范写成可调用文本。6.0 进一步补上的，是这些文本不应过度绑定某一款 Agent 产品。

与 6.0 其他改动的关系

跨平台技能语义与Harness映射 并不是孤立设计，它和 6.0 的其他机制是互相配合的。

例如在 subagent-driven-development 重写中，系统把任务 brief、review package、progress ledger 都文件化。skill 只需要表达“生成交接物并交给下一环节”，不同平台再决定如何实际读取、传递和注入这些文件。

同样，任务实施、评审和恢复链路被拆得更清楚后，平台层只需保证以下能力能够被映射出来：

• 发起一个新的子代理执行当前任务；