阿里一面问题:DSH中Skill和插件的区别

阿里一面，聊到一半，面试官问我对 skill 是怎么理解的，它的结构有哪些，自己写 skill 有什么经验。这个我熟，从渐进式加载讲起：SKILL.md 开头那段 description 每次都在上下文里，正文按需加载，代码放 scripts，文档放 references，正文要精简，起到目录和索引的作用。他还追问了什么时候该写脚本，我说调用路径足够确定的时候就固化成脚本，别让模型每一步重新判断，它毕竟是概率系统，文档写得再全也照样出错。这一问一答我自己觉得挺顺。

然后他换了个问法：DeepSeek 不是刚开源了那个 Harness 吗，你说说，它里面的插件和 skill 有什么区别。

我卡住了。当时答的是“插件更底层一些”。这句话不算错，但等于没说，它既没指出两者在哪一层分开，也没解释 DeepSeek Harness 的能力清单里为什么也列着 Skills。面完之后我把这道题重新捋了一遍。

图 01 · Agent = Model + Harness

很多人都是这么默认的，我一开始也是：它们被当成同类东西，都是给 Agent 加能力的手段，只是一个轻、一个重。

这个默认从起点就错了。插件和 skill 不是两个同类项比大小，它们是两种完全不同的东西被“能力”这个词包在了一起。把它们并排放着问哪个更好，相当于把发动机和说明书并排，问哪个更管用。

要拆开，得先看它们各自挂在哪一层。

社区里管它叫 dsh，后面我也这么写。它 8 月 13 日开源，不是新模型，是 Agent 的运行时框架。MIT 协议，开发者预览版，发布一周星数破万。它给的公式很短：Agent = Model + Harness。模型负责想，Harness 负责让“想”落进真实环境——工具调用闭环、任务调度、权限管控、会话追踪。

主流 Harness 里，这些能力大多写死在框架内。dsh 把它们一个个拆出来做成可插拔的，连 Agent Loop 本身都是插件。LangChain 给你零件，循环还是框架自己的；LangGraph 把循环建模成图，执行引擎固定；dsh 连发动机都能换。

撑住这件事的是 Cordis 内核的四个机制。Service 负责注册能力、声明依赖，装配阶段缺依赖直接报错，不是跑到一半才炸；Event 在生命周期节点上观察、变换、拦截，用 Waterfall 模式让每个监听器决定要不要把 next 传下去，事件因此从消息传递变成了流程控制。权限插件能拦工具调用，压缩插件能在上下文溢出前介入，而 Agent Loop 完全不知道这些事发生过。

Effect 保证每次变换都可追踪、可撤销，插件卸下来能回到装之前的状态；Scope 让插件隔离、按需加载，不必全挤在一个命名空间里。合起来的结果是Loop 特别轻，只负责跟模型说话、推进流程，其余全交给插件，靠事件协作完成。

这里有个容易滑过去的地方：插件能提供的东西不止一种。工具是它注册的，模型适配器、会话存储、沙箱、子 Agent 调度也一样，skill 只是其中一类。插件是那个能装东西的箱子，skill 是能装进去的东西之一，这两句话不能倒过来讲。

图 02 · Cordis 四机制

skill 的格式简单得让人误会，一个文件夹就够：

SKILL.md 开头两个字段，name 和 description。加载分三层：description 常驻在系统提示里，一个 skill 占几十个 token；模型判断当前任务用得着，才把正文读进来；正文里提到 references 或 scripts，再去读、去跑。这解决的是上下文装不下的问题，五十个 skill 的正文全塞进提示词，还没开始干活窗口就满了。渐进式加载等于给知识编了索书号，先看目录，要用再去取。

那里面装的到底是什么？程序性知识——不是“这件事是什么”，是“这件事怎么做”。

比如先登录再查表，改完代码必须跑哪三条测试，这个 PDF 每页先转成图再 OCR。这些是流程，是踩过坑之后沉淀下来的经验，写不进模型权重，但可以写进文件。所以 skill 干的活很具体：把同一类任务的做法固化下来，下次不用从零推理一遍。

这里必须把 skill 和 tool 分开，很多混淆就是从这儿起的。tool 是原子动作，读一个文件、跑一条 shell、发一次请求，调下去就执行，结果确定。skill 是编排这些动作的流程，它自己没有执行能力，只负责告诉模型先干什么后干什么。一个 skill 里写着先跑 ruff 再改代码最后跑单测，真正落地干活的还是那几个 tool。

这也正好连回我面试里被追问的那句：什么时候该写脚本。界线就在这儿——看这件事还留不留判断空间。CLI 调用足够确定，就固化成脚本，让它变成一个 tool，模型调它就完事，不用每步重新决策；中间要看情况、要判断、要反复试，那就还是写成 skill，让模型自己走。

Claude 那边有个细节挺说明问题，skill 的生成路径有三条：系统预置、用户自己装、还有 Agent 自己写。Hermes 那种自进化框架，差不多每十次工具调用就停下来复盘一次，觉得某套流程以后还用得上，就自己写一个 SKILL.md 存起来。Agent 在给自己写操作手册，这是 skill 这个形态最有意思的地方。

图 03 · skill 的三层加载

第一是载体。插件是跑在宿主进程里的代码，它注册 service、监听事件、改流程，运行时里确实多了一段逻辑在跑。skill 是文件，模型读它、用自然语言理解它，它不在任何地方“运行”，只影响模型下一步怎么想。

第二是生效时机。插件在装配期就位，缺依赖当场报错，装错了系统起不来。skill 在推理期按需加载，用不上就一直躺在提示里当一行描述，不加载等于不存在，也没有副作用要收拾。

第三是能力边界，这条最硬。插件能改 Agent Loop 本身，skill 不能。Cordis 的 Effect 让插件可以可逆地挂载和卸载，连循环怎么转都能换掉；skill 顶多告诉模型这类任务按五步走，听不听、听多少，仍然由模型自己决定。所以 dsh 敢说一切皆插件，但没人说一切皆 skill——前者是架构，后者是内容。

第四是可组合的方向。Cordis 那篇论文标题是 A Programming Paradigm for Spatiotemporal Composability，讲时空可组合性。空间维度管的是谁和谁能装在一起、依赖怎么解、缺了怎么办，靠 Service 和 Scope；时间维度管的是这次装上去的改动卸下来干不干净、反复装卸会不会越来越乱，靠 Effect。

而skill 天生站在时间这一边：这次学会的，下次还要能用，用旧了要能改，改错了要能退。它更像一份会累积、也会过期的记录。在 dsh 里，skill 由插件提供：有一类插件专门扫描和注册 skill 源，把一批文档挂进运行时。tool 走的是同一条路，也是被插件扫描、解析、挂进运行时的。两者的装法一样，东西不一样，所以不能因为 skill 也是插件装进来的，就说它是插件。提供它的插件和它本身，是两样东西——好比书架和书，书架决定书怎么摆，改不了书里写了什么。

图 04 · 插件装的，不止 skill

一种是把 skill 当成轻量插件，觉得它也能改运行时，只是写起来省事。这是把“怎么装进来”当成了“能干什么”，skill 写得再好，也动不了 Loop 一行。

另一种正好相反，觉得有插件就够了，skill 是重复的东西。这是没分清能力与方法——工具再多，也不代表模型知道该按什么顺序用。

还有一种是把 tool 和 skill 混着说。前者是动作，调下去就执行；后者是流程，走到哪一步由模型现场判断。这层一混，问 skill 是不是插件就会问偏方向，因为它压根不往运行时那边走。

现在再被问 skill 和 dsh 插件的区别，我会这么答：

它们不在一个维度，中间还隔着一层。插件是运行时组件，回答的是 Agent 由哪些零件组成；tool 是单个零件，比如读文件、跑命令这些原子动作；skill 是知识包，回答的是 Agent 遇到某类任务该怎么走。在 dsh 里，skill 确实由插件提供，但提供它的插件和 skill 本身是两回事。插件改的是引擎，skill 改的是驾驶员。

如果追问它为什么要把能力都拆成可插拔的，我会说：它想让 Agent 自己进化。要在运行中生成和修改自己的组件，前提是每个组件卸下来都能把痕迹擦干净，Effect 就是干这个的。而 skill 恰好是 Agent 最想自己生成的东西，它把摸索出来的做法写成文件，下次直接读档。