这篇论文解决的是一个非常实际的问题：Skill 写好了，换一个 Agent 框架就崩。
同一个 SKILL.md，在 Claude Code 上能跑通，放到 Kimi CLI 里格式错乱、工具调用失败、安全边界全丢——这不是模型能力问题，是「格式敏感」和「安全缺失」两个基础设施问题。
核心思路：把 Skill 当成代码来编译
SkCC 引入编译器的经典设计：
SkIR（强类型中间表示） — 把 Skill 的语义（做什么）和格式（怎么写）解耦。同一个 Skill 的语义只表达一次，编译到不同框架时自动适配格式。
四阶段流水线 — 语法解析 → IR 结构化转换 → 安全优化 → 多目标格式生成。复杂度从 O(m×n) 降到 O(m+n)。
Anti-Skill 安全模块 — 编译时自动注入防护规则，94.8% 的高危漏洞在部署前被拦截。非法 HTTP、死循环、危险删库四类操作强制加约束。
实测结果很有说服力
| 框架 | 原始通过率 | SkCC 编译后 | 提升 |
|---|---|---|---|
| Claude Code | 21.1% | 33.3% | +12.2pp |
| Kimi CLI | 35.1% | 48.7% | +13.5pp |
| Codex / Gemini | 同步提升 | — | — |
对社区的意义
当前 Skill 生态的一个隐形成本是：作者写了一个 Skill，想支持多个框架就得重写 n 次，每次还要补安全边界。SkCC 把这个成本几乎归零——写一次，编译到所有框架。
中山大学团队选择开源编译器代码，而不是闭源服务，这个决定很对。Skill 编译器需要成为基础设施，而不是某个平台的独占优势。
可以延伸的方向
- 动态路由: 当前是静态编译，未来能否根据运行时上下文动态选择最优格式？
- Skill 依赖管理: 复杂 Skill 可能依赖其他 Skill，编译器能否处理依赖图？
- 版本兼容性: 框架升级后，已编译 Skill 如何自动适配新版本？