|
|
@@ -0,0 +1,202 @@
|
|
|
+# 投标技术方案:面向开源鸿蒙的 Skill 可迁移性评估与自动适配框架
|
|
|
+
|
|
|
+> 对应课题:**技术课题2 — 开源 Skill 迁移适配开源鸿蒙,支撑 Skill 生态繁荣**
|
|
|
+> 投标方技术底座:lambdagentpaas(λA 类型化 Lambda 演算 Agent 引擎,BSL 开源)
|
|
|
+> 状态:草案 v0.1(待团队/评审定稿)
|
|
|
+> 技术附录:[SKILL_FORMALIZATION_DESIGN.md](SKILL_FORMALIZATION_DESIGN.md)、[harmonyos-agent-dsl-comparison.md](harmonyos-agent-dsl-comparison.md)、[MCP_SKILL_DESIGN.md](MCP_SKILL_DESIGN.md)、[PRODUCT_GATE_DESIGN.md](PRODUCT_GATE_DESIGN.md)
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 0. 一句话方案
|
|
|
+
|
|
|
+把开源 Skill 迁移从「逐个人工评测 + 经验改写」升级为一条**形式化全链路**:
|
|
|
+**SkillBench(可判定评估)→ Skill IR(纯函数抽象)→ Migration Harness(自动迁移)→ Formal Guard(静态安全封顶)**。
|
|
|
+其中可判定的部分(依赖/能力/类型缺口)由形式化方法**可证正确**地给出适配报告,模糊的部分(脚本归约、行为改写)由 Coding Agent + 验收闭环把准确率抬到 95%+。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 1. 课题理解与定位
|
|
|
+
|
|
|
+### 1.1 课题诉求拆解
|
|
|
+
|
|
|
+课题2 的两条核心技术诉求:
|
|
|
+
|
|
|
+- **诉求①(评估)**:构建开源 Skill 能力评估能力,涵盖功能、质量、**安全性、开源鸿蒙系统适配性**,自动化分析并输出**适配报告**,分析准确率 **95%+**。
|
|
|
+- **诉求②(抽象+迁移)**:构建 Skill **抽象能力**,解耦核心逻辑、提取**"纯函数"**、消减对系统/Agent 框架的依赖,让高质量 Skill **跨系统/语言/环境**执行;并针对 Skill 迁移构建一套 **Harness 框架**,开源 Skill → 开源鸿蒙迁移准确率 **95%+**。
|
|
|
+
|
|
|
+### 1.2 我们的定位(收窄)
|
|
|
+
|
|
|
+不做泛泛的"生态繁荣",聚焦一件硬事:
|
|
|
+
|
|
|
+> **面向开源鸿蒙的 Skill 可迁移性评估与自动适配框架**
|
|
|
+
|
|
|
+差异化主张一句话:
|
|
|
+
|
|
|
+> **现有工作(SkillsBench[2])回答"这个 Skill 在鸿蒙上跑得通吗"——实证、事后、pass/fail;我们回答"为什么通/不通、缺哪条能力、怎么补"——形式、事前、可证。**
|
|
|
+
|
|
|
+这正填补课题2 自身承认的缺口:"关注功能和质量,**但缺少对可靠性、可迁移性的评估**"。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 2. 技术背景与痛点
|
|
|
+
|
|
|
+- **量大质杂**:社区 Skill 已达万级,重复率高、部分功能冲突,缺一套科学的质量评估框架。
|
|
|
+- **迁移率低**:对 OpenClaw Top60 Skill 分析,**仅 26%(16/60)可无痛迁移**(课题2 现状数据)。其余分属 A1–A4(鸿蒙环境/设备依赖)、B1–B4(网络/凭据/系统能力/质量缺陷)。
|
|
|
+- **安全合规**:开源 Skill 存在大量安全、隐私、合规风险,需可量化、可定性评估(prompt 注入、越权工具调用、凭据外泄等)。
|
|
|
+- **方法待立**:业界当前路线是把 Skill 转 MCP 服务、或封装 SubAgent A2A 调用、或完全重写,**缺统一的中间表示与自动判定**——每条都靠人工经验,无法规模化到万级。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 3. 总体方案:四层形式化全链路
|
|
|
+
|
|
|
+| 层 | 解决课题2 | 核心机制 | 已有底座 |
|
|
|
+|---|---|---|---|
|
|
|
+| **① SkillBench**(评估) | 诉求①:适配报告 95%+ | 自动派生 Skill 的效果/成本/类型契约;`portable(s,device)` **可判定**判定 + 缺口报告;注入扫描 | `infer_effect_for_term` / `estimate_cost` / `is_subtype` / `scan_injection` |
|
|
|
+| **② Skill IR**(抽象) | 诉求②:提取纯函数、去框架依赖 | `Skill : Term→Term` 注入组合子 + `interface:` 运行时无关契约;脚本型 normalize 成 `Tool`/`Compose` | Skill 形式化设计 §3/§4/§7.3 |
|
|
|
+| **③ Migration Harness**(迁移) | 挑战:"用 Coding Agent 快速迁移" | native coding-agent 车道做改写 + IR→鸿蒙 DSL/MCP/SubAgent 多目标 codegen + 行为一致性测试 | native claude-code 执行车道 + worktree 隔离 + §6 鸿蒙映射 |
|
|
|
+| **④ Formal Guard**(安全) | 安全/隐私/合规 | `Guard`(输出验收)+ `Restrict`(效果封顶,伽罗瓦连接)+ 工作目录硬沙箱 | `extensions.py::Guard` + Skill 形式化 §3.5 + `_sandbox.py` |
|
|
|
+
|
|
|
+四层关系:评估层判定可迁移性 → 抽象层把 Skill 提成 IR → 迁移层 codegen 到鸿蒙目标形态 → 安全层在工具调用层静态封顶能力。**评估与抽象共用同一套形式契约**(effect/cost/type),这是全链路自洽的关键。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 4. 核心技术点
|
|
|
+
|
|
|
+### 4.1 SkillBench:可判定的 Skill 迁移评估器
|
|
|
+
|
|
|
+**输入**一个开源 Skill,**输出**适配报告(功能/依赖/权限/安全/鸿蒙适配难度 + 迁移路径建议)。
|
|
|
+
|
|
|
+关键:把课题2 那张"A1–C 人工分类表"变成**自动可判定**的效果/工具/验收条件——
|
|
|
+
|
|
|
+| 课题2 分类 | 本质 | 形式判定(自动) |
|
|
|
+|---|---|---|
|
|
|
+| A1 macOS/特定 Linux 依赖 | 环境依赖 | `tools_s ⊄ tools_device`(端侧无此原生工具) |
|
|
|
+| A2/A3 无依赖工具(虚机可/不可解) | 工具可替代性 | 工具面取交后能否经 MCP 回退(降级策略 §6.3) |
|
|
|
+| A4 app/软件依赖 | 外部进程 | `effect = io`(外部桥接型) |
|
|
|
+| B1 网络服务不可用 | 网络 io | `effect_ceiling` 砍 io → 判不可迁移 |
|
|
|
+| B2 需 API Keys/Credentials | STATE/密钥 | `STATE(state_keys)` 效果 + 凭据缺失 |
|
|
|
+| B3 系统能力暂不支持 | 效果超端侧上界 | `effect_leq(ε_s, ε_device)` 为假 |
|
|
|
+| B4 Skill 不正确/配置/格式 | 质量缺陷 | `validate_skill` + `Guard` 验收失败 |
|
|
|
+| C 兼容 | 全满足 | `portable(s,device)` 为真 |
|
|
|
+
|
|
|
+**可判定性判定**(编译期):
|
|
|
+
|
|
|
+```
|
|
|
+portable(s, device) ⟺
|
|
|
+ effect_leq(ε_s, ε_device_max) -- 效果不超端侧允许
|
|
|
+ ∧ tools_s ⊆ tools_device -- 所需工具端侧都有实现
|
|
|
+ ∧ grade_leq(g_s, g_device_budget) -- 成本(token/延迟)不超端侧预算
|
|
|
+```
|
|
|
+
|
|
|
+任一条不满足 → 报告**具体缺口 + 降级建议**(工具缺失→云端 MCP 回退;成本超→换小模型+收紧重试;效果超→人工裁剪),而非端侧运行时炸。
|
|
|
+
|
|
|
+**安全评估**:复用 `scan_injection`(prompt 注入模式扫描,已上线)+ `Restrict` 效果封顶(越权工具调用静态拦截)+ 高风险工具权限 diff,输出安全/隐私/合规子报告。
|
|
|
+
|
|
|
+### 4.2 Skill IR:核心逻辑抽象与"纯函数"提取
|
|
|
+
|
|
|
+把 Skill 抽象成**运行时无关的 term + 契约**,这就是课题2 要的"解耦、提取纯函数、去框架依赖":
|
|
|
+
|
|
|
+- **注入型 Skill** → 组合子 `Skill_s(A) ≜ Guard(Memory(A ⊕ prompt ⊕ tools), P_s)`,携带 `interface:` 契约(输入/输出类型、效果上界、验收谓词、成本先验)。契约是运行时无关的,可重定向到任意目标运行时。
|
|
|
+- **约束型 Skill** → 对偶组合子 `Restrict_r(A)`(效果取下确界、工具面取交、调用守卫),覆盖 `careful/freeze/guard` 这类安全 Skill。`Skill` 与 `Restrict` 在效果格上构成**伽罗瓦连接**,使 Skill 最终能力被可证地夹在 `[下界, 上界]`。
|
|
|
+- **脚本型 Skill(OpenClaw/Claude SKILL.md + scripts)** → normalize:frontmatter→元数据、正文→prompt、脚本调用→`Tool`/MCP scope、workflow 步骤→`Compose`(带验收则每步 `Guard`)。由此脚本型也获得 `interface:` 契约,进入统一 IR。
|
|
|
+
|
|
|
+> "纯函数"提取的形式含义:把一个 Skill 的副作用(IO/STATE)显式标注为 effect,把其确定性核心逻辑提成 `Tool`/`Compose` 的纯结构。effect 标注让"哪些依赖能去掉、哪些必须保留"成为可计算问题。
|
|
|
+
|
|
|
+### 4.3 Migration Harness:自动迁移与一致性验证
|
|
|
+
|
|
|
+- **改写引擎**:复用 native claude-code 执行车道(直接调 `claude -p --output-format stream-json`,native 工具开、worktree 隔离并行改写互不冲突),把不可直接迁移的 Skill 自动改写成可迁移形态。
|
|
|
+- **多目标 codegen**:IR → 鸿蒙 Agent DSL(CangjieMagic `@agent`/`@prompt[pattern]`/`@tool`)/ MCP 服务 / SubAgent A2A,三选一(对应课题2 业界三路线)。映射规则见 [harmonyos-agent-dsl-comparison.md](harmonyos-agent-dsl-comparison.md) 与形式化设计 §6。
|
|
|
+- **行为一致性测试**:迁移前后用同一组测试任务跑,`Guard` 验收输出契约一致(pass/fail),作为迁移正确性证据。
|
|
|
+
|
|
|
+### 4.4 Formal Guard:静态安全封顶
|
|
|
+
|
|
|
+把安全从"输出验收"推进到"工具调用层的静态能力封顶":
|
|
|
+
|
|
|
+- `Guard`([extensions.py:146](../lambdagent/src/lambdagent/extensions.py)):输出必须满足谓词,否则重试/失败。
|
|
|
+- `Restrict`(形式化设计 §3.5):`effect_meet` 砍效果上界、工具面取交、`deny_patterns` 调用守卫(ask/deny),对应迁移后 Skill 在端侧的最小权限运行。
|
|
|
+- 工作目录硬沙箱(`_sandbox.py`,已上线):越界写直接拒绝,防迁移 Skill 在端侧逃逸。
|
|
|
+
|
|
|
+**安全代数结论**:迁移后 Skill 的能力 `ε_final` 被可证地夹在 `[Restrict 下界, Skill 上界]`——这是相对纯 prompt 工程最硬的安全卖点,也直接回应课题2 的安全/隐私/合规诉求。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 5. 与现有工作的差异化
|
|
|
+
|
|
|
+课题2 引用了两篇关键文献:Agent skills 数据驱动分析[1] 与 SkillsBench[2]。我们**不重造它们的实证基准**,而是补上它们没有的形式化层:
|
|
|
+
|
|
|
+| 维度 | Agent skills[1] / SkillsBench[2] | 本方案 |
|
|
|
+|---|---|---|
|
|
|
+| 评估方法 | 实证、跑 trajectory 统计 pass/fail | **形式、编译期可判定** |
|
|
|
+| 输出 | 成功率数字 | **缺口定位 + 迁移路径 + 可证安全边界** |
|
|
|
+| 可迁移性 | 实测能不能跑 | **为什么、缺什么、怎么补** |
|
|
|
+| 抽象层 | 无统一 IR | **`Skill`/`Restrict` term + `interface:` 契约 IR** |
|
|
|
+| 安全 | 基本不覆盖 | **效果封顶 + 伽罗瓦连接 + 硬沙箱** |
|
|
|
+| 理论根基 | 经验/数据 | **λA 类型化 Lambda 演算(三篇论文)** |
|
|
|
+
|
|
|
+一句话:**SkillsBench 是"考试",我们是"诊断 + 处方 + 手术"。**
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 6. 95% 准确率的可信拆解
|
|
|
+
|
|
|
+把课题2 要求的两个 95% 拆开讲,避免一刀切吹:
|
|
|
+
|
|
|
+| 部分 | 占比(按 Top60 估) | 准确率来源 | 风险 |
|
|
|
+|---|---|---|---|
|
|
|
+| 可判定类(A1–B3、C) | 多数 | effect/工具/类型判定**可证正确**,趋近 100% | 低(形式化送的红利) |
|
|
|
+| 质量缺陷类(B4) | 少数 | `validate_skill` + LLM-judge 验收 | 中(judge 阈值需调) |
|
|
|
+| 脚本归约 + 行为改写(迁移核心难点) | 关键少数 | Coding Agent + Guard 验收闭环 | 高(是工程主战场,从 ~70% 抬到 95%) |
|
|
|
+
|
|
|
+**结论**:评估侧(诉求①)的 95% 主要靠可判定红利,**可达**;迁移侧(诉求②)的 95% 是真正要堆工程的地方,靠 Harness 的"改写→验收→重试"闭环逼近,这也是课题"挑战"二字的落点。这样拆,评审能看出我们知道难在哪。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 7. 里程碑与交付
|
|
|
+
|
|
|
+| 阶段 | 周期 | 交付物 | 验收指标 |
|
|
|
+|---|---|---|---|
|
|
|
+| **M1 评估器 MVP** | T+2 月 | SkillBench:单 Skill → 适配报告(A1–C 自动分类 + 缺口) | 对 Top60 复现人工分类,一致率 ≥90% |
|
|
|
+| **M2 Skill IR** | T+4 月 | `Skill`/`Restrict` 组合子 + `interface:` 解析 + 脚本 normalize | 内置/OpenClaw 样例 Skill 提成 IR,回归通过 |
|
|
|
+| **M3 迁移 Harness** | T+6 月 | IR→鸿蒙 DSL/MCP/SubAgent codegen + 一致性测试 | 可迁移 Skill 自动迁移 + 行为一致 ≥90% |
|
|
|
+| **M4 全链路 + 指标冲刺** | T+9 月 | 端到端:开源 Skill 批量评估+迁移+验证 | 评估准确率 95%+、迁移准确率 95%+(挑战值) |
|
|
|
+
|
|
|
+每阶段产出可复现实验 + 报告,对齐课题验收。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 8. 可复用资产清单(证明不是从零起步)
|
|
|
+
|
|
|
+| 资产 | 现状 | 对应层 |
|
|
|
+|---|---|---|
|
|
|
+| λA 类型化 Lambda 演算引擎(term/effect/cost/type/Guard) | 已实现,175+ 测试 | ①②④ |
|
|
|
+| `infer_effect_for_term` / `estimate_cost` / `validate_cost` | 已实现 | ① |
|
|
|
+| Skill 注册中心 + `mount_into_config` + `scan_injection` + 权限 diff | 已上线 | ①② |
|
|
|
+| Skill 形式化设计(`Skill`/`Restrict`/`interface:`/鸿蒙映射) | 设计完成(本文档技术附录) | ②③ |
|
|
|
+| native claude-code 执行车道 + worktree 隔离 | 已上线 | ③ |
|
|
|
+| 鸿蒙 Agent DSL / CangjieMagic 对比文档 | 已完成 | ③ |
|
|
|
+| 工作目录硬沙箱 `_sandbox.py` | 已上线 | ④ |
|
|
|
+| 产物 Gate 流水线(gate=Guard、LLM-judge) | 已实现,39 测试 | ①④ |
|
|
|
+| MCP / A2A / AgentPack 接入 | 已上线 | ②③ |
|
|
|
+
|
|
|
+> 即:四层中每一层都有可演示的存量代码或设计,投标不是 PPT 概念,而是已有工程的形式化收口。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 9. 风险与应对
|
|
|
+
|
|
|
+| 风险 | 等级 | 应对 |
|
|
|
+|---|---|---|
|
|
|
+| 脚本型 Skill 行为改写准确率达不到 95% | 高 | M3 起以 Guard 验收闭环驱动迭代;对低置信迁移标"需人工复核",不强迁 |
|
|
|
+| 开源鸿蒙 / CangjieMagic 端侧运行时接口变动 | 中 | IR 运行时无关,codegen 后端可替换;先对齐稳定子集 |
|
|
|
+| effect/工具白名单与真实端侧能力清单不一致 | 中 | 端侧能力清单 `Caps_device` 作为可配置输入,随版本更新 |
|
|
|
+| LLM-judge 评估阈值漂移 | 中 | 复用 PRODUCT_GATE 的 judge 框架,阈值可调 + 本地 ollama 兜底 |
|
|
|
+| CJK token 估算低估致成本判定偏松 | 低 | 已知问题,`cost_hint` + `validate_cost` 回填校准 |
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 10. 参考文献
|
|
|
+
|
|
|
+- [1] Ling G, Zhong S, Huang R. *Agent skills: A data-driven analysis of claude skills for extending large language model functionality.* arXiv:2602.08004, 2026.
|
|
|
+- [2] Xiangyi L, Wenbo C, et al. *SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks.* arXiv:2602.12670, 2026.
|
|
|
+- 本方技术附录:[SKILL_FORMALIZATION_DESIGN.md](SKILL_FORMALIZATION_DESIGN.md)(`Skill : Term→Term` 语义、`interface:` 扩展、鸿蒙契约映射)。
|
|
|
+- λA 三篇论文(类型系统 / 效果与代价 / 算法律),见项目 docs/research。
|