两篇论文看完，一个工程师视角的观察：
SKILL0和Skill1其实对应了两种不同的"产品形态"。
SKILL0更像"出厂设置"——模型训练好了，skill已经融进参数，用户拿到的是一个"会干活"的模型，不需要关心背后有什么library。这跟现在手机厂商预装AI功能的思路一致：功能在，但看不见。
Skill1更像"插件生态"——模型本身只是底座，skill library是不断生长的应用商店。开发者可以往里面加skill，用户可以选择加载哪些。这跟Claude Code的Skills体系、OpenClaw的skill生态是一个路子。
从工程落地角度，Skill1当前更实用。理由很简单：
1. 可解释性：skill是文本，人类可以读、可以审、可以改。内化的参数？黑盒。 2. 可更新性：业务规则变了，改个skill文件就行，不用重新训练模型。 3. 可共享性：一个skill文件可以在团队、项目、甚至公司之间传递。
SKILL0的长板在推理效率。0.38k vs 2.21k的token差距，在终端设备上就是生死线。如果美团真的打算把Agent塞进外卖骑手的App里，SKILL0路线几乎是唯一选择——骑手不可能每次接单都等模型检索一遍skill library。
但这里有个隐藏前提：SKILL0能内化的skill必须是"稳定的"。如果今天规则是A明天规则是B，内化的参数怎么更新？重新走一遍ICRL的成本可能比直接改skill文件高得多。
所以未来的架构可能是分层的：
- 底层：高频、稳定、安全的操作 → SKILL0内化到参数
- 上层：低频、多变、需要人类审阅的规则 → Skill1式library动态管理
另外注意到一个细节：两篇论文都基于Qwen2.5-7B，而不是GPT-4o或Claude。7B能在ALFWorld上跑到97.5%，说明skill框架的增益空间远大于模型规模本身的边际增益。对小模型+好skill vs 大模型+烂skill的权衡，这两篇论文给出了强有力的证据。
最后提一嘴跟微软SkillOpt的关联：SkillOpt训练出的best_skill.md，恰好可以被这两篇论文的框架消费——SkillOpt负责"练出好skill"，SKILL0负责"把skill消化掉"，Skill1负责"让skill库持续进化"。三者的组合，可能才是Agent skill体系的完整图景。