第三方组件技能化集成方法论
触发（何时用）
- 官方或客户发现优秀开源组件（GitHub / npm / PyPI），想纳入技能市场时；
- 评审"某组件要不要做成技能"的决策场景；
- 技能市场新增"执行面技能"类目前的准入评审。
步骤
⓪ 业务准入审查（前置闸门——技术再安全，业务没价值也不收）
先过这道门，再谈技术评估。四项全过才进入①；任何一项不过 → 登记观察项或直接拒收。
| 审查项 | 过关线 | 拒收线 |
|---|---|---|
| 场景价值 | 能说清"哪个行业/岗位、什么场景、多高频次"会用它；有真实客户诉求或清晰可预见的场景 | 只有"这个组件很火/很酷"，说不出谁会用来干嘛 → 拒收 |
| 生态位去重 | 与现有技能（官方 skills/ + registry/）职责不重叠，或重叠但差异化场景成立（性能/合规/场景特异三者居一） | 功能与现有技能重叠 ≥70% 且无差异化场景 → 登记观察项不上架；同一生态位只保留一个主力技能，新候选必须论证"为什么换掉/并存" |
| 质量证据 | 有外部可信信号：GitHub stars/下载量/生产使用案例/权威推荐，至少一项；代码可读、文档可用 | 无使用证据的玩具项目、示例项目、个人练手项目 → 拒收（除非填补空白生态位且通过技术评估，此时降级为"实验标记"上架并加强监控） |
| 垃圾特征排除 | 无右列任一特征 | 出现即拒收：①README 与代码货不对板；②核心能力依赖另一个未声明的付费服务；③捆绑推广（推广链接多于功能文档）；④抄来的项目（fork 无实质改动且声明原创）；⑤高频改名/转移仓库的投机项目 |
去重检查方法（入库前必做）：
pnpm skill:forge check会自动扫描 registry 与官方技能库，按类别/出站域/工具面/描述关键词提示生态位重叠；- 机器提示重叠时，评审人必须书面回答："现有技能为什么不够用？"——答不出来就是重复；
- 官方自带能力（computer-use / publish-rpa / 围栏等）也纳入对照——与基座自带能力重叠 ≥70% 的组件不做成技能，直接写进基座演进路线图。
① 五维技术评估（先判要不要，再判怎么装）
| 维度 | 过关线 | 否决项 |
|---|---|---|
| 许可证 | MIT / Apache-2.0 直接过 | AGPL 仅"独立进程调用"形态；SSPL/商业限制不收录 |
| 云依赖 | 纯本地最优；云依赖必须可拆（客户自配账号、API Key 本机存放） | 强制云中转客户经营数据且不可关 → 否决（数据主权红线） |
| 架构契合 | 能经"工具白名单 + 围栏参数"纳入治理面 | 要求跳过围栏/审批才能用 → 否决 |
| 供应链 | 无投毒史、无未修 KEV；登记 oss-components.json 进 oss-watch 周期监控 | 有投毒史未出安全处置方案 → 暂缓 |
| 活跃度 | 近 3 个月有提交；issue 有响应 | 停更超 6 个月且无 fork 计划 → 观察项不入运行时 |
② 定级预判（决定静默还是审批）
- 纯知识/方法论 → knowledge（L0/L1，可静默）；
- 带依赖、工具、出站域、围栏绑定扩张 → tool-execution（L2，永不静默，走审批）；
- 拿不准就按 L2 处理（宁严勿宽）。
③ 适配四件套（不裸转录上游文档）
- 场景知识：何时用它、何时用基座自带能力（computer-use）——写清分工；
- 调用契约：toolWhitelist（可执行命令/端点前缀清单），越界即围栏拦截；
- 围栏参数：账号日上限、拟人节奏、风控降速、异常挂起转人工；
- 出站域清单：egressDomains 全量声明，出站内容过三段瀑布审计。
④ 登记与打包
- 登记
oss-components.json（名称/仓库/渠道/gate/scope/备注），进 oss-watch 监控； - 技能资产 = SKILL.md（frontmatter + 正文）+ dist.json（DistMeta：类别/来源/依赖/工具白名单/出站域/围栏参数/License/来源仓）；
credentials字段永不出现——API Key 由客户侧本机配置；- 官方签名（HMAC-SHA256）后进分发 registry。
配套工具链（每个项目自带，pnpm skill:forge）：
| 命令 | 作用 |
|---|---|
pnpm skill:forge evaluate <github-url> [--license X] [--cloud none|optional|required] | 五维评估 + dist.json 草稿（网络受限时手工补全不阻塞） |
pnpm skill:forge check <dir> | 资产校验 + staging 同款预检③④⑤ + 生态位重叠扫描（对照现有技能库提示重复） |
pnpm skill:forge package <dir> | 官方签名 → dist.package.json |
pnpm skill:forge register <dir> --name <名> --repo <url> | 登记 oss-components.json |
pnpm skill:forge publish <dir> | 签名并加入本地 registry manifest（客户端拉取即生效） |
签名密钥取 SKILL_DIST_SIGNING_KEY 或 --key。流程铁律不变：check 不过不打包，未签名不分发。
⑤ 灰度与上架
- 白名单实例先行 → 观察健康指标（装载成功率/误熔断率/审批驳回率）→ 全量；
- L2 技能首装必走审批卡；审批驳回原因进反馈枚举表（editKind 分流）。
⑥ 上架后监控与退出
- oss-watch 周检上游版本；上游更新 → 技能版本升级 → 按分级模型再分发；
- 上游变质/失联/投毒告警 → kill switch 全局吊销（分发端下架 + 运行时装配双点排除）；
- 低分退出：使用信号（采用率/通过率/返工率）进技能积分卡——
- 连续 4 周零采用 → 降级为观察项（停止分发推送，已装实例保留）；
- 通过率/返工率持续劣于同类技能 → 标记"不推荐"，新实例不再默认装配；
- 被同生态位更优技能替代 → 走"退役流程"：先停分发、通知在用客户迁移、再下架留档；
- 市场纪律：技能市场不追求数量。宁可 20 个高分技能，不要 200 个凑数技能——客户对市场的信任一旦被垃圾技能消耗，恢复成本远高于少上几个。
边界（什么不做）
- 不裸转录上游 README/SKILL.md 直接上架——必须有官方适配层；
- 不在技能正文夹带任何账号访问信息、内网地址、客户数据；
- 不为集成而集成——⓪业务准入不过（无场景/生态位重复/无质量证据/垃圾特征）的组件，技术评估做得再好也不上架；
- 不绕过三级静默分级——任何"先跑起来再说"的执行面直装都是对红线的破坏。