别再说“复制 Skill 就是复制 Agent”了

题图摄于广州珠江

前段时间我踩了个坑：把一份已经跑通的 Skill （技能）复制到另一套 Agent 系统里。在原来的环境里，它能读 PDF、整理提纲、生成规范 Word，最后还会检查格式和字体。结果换到新环境后，模型明明看懂了流程，却只能输出 Markdown；表格丢了，中文字体错了，中间的检查步骤也直接跳过了。

那一刻我突然意识到：我只搬走了工作说明书，却没有搬走整个工厂。

这里先把两个词说清楚。Agent，是具备任务规划、工具调用、多轮执行能力的 AI 智能体；Skill，可以理解为写给 Agent 的“技能包”或“任务说明”，里面包含流程、规范和经验。问题在于，Agent 的能力不是一个 Skill 文件产生的，而是模型、工具、环境和编排方式共同撑起来的。

一、Skill 不是一键复制的插件

很多人把 Skill 想成软件插件：复制过去，功能就跟着过去。但传统插件内置确定的代码逻辑，执行结果相对可预期；Skill 更多是一组行为指引。它告诉模型先做什么、再做什么、遇到异常怎么处理，但最终如何理解、如何排序、什么时候调用工具，仍然由大模型判断。

所以，Skill 只能沉淀经验，无法自动复制能力。它是工作说明书，不是能力胶囊。

二、同一个 Skill 为何跨系统就失灵？

最根本一点，是底层大模型不同。同一段 Skill，给 GPT、Claude、Kimi、Qwen 或某个开源模型，执行习惯可能完全不同。有的模型擅长长上下文规划，有的擅长代码，有的严格遵守格式，有的容易自由发挥。模型的思维方式和执行习惯，从根本上决定了 Skill 的落地效果。

其次呢，是配套工具不同。一个 Agent 能生成高质量 Word，往往不是因为 Skill 神奇，而是背后有 python-docx、pandoc、LibreOffice、PDF 解析工具、字体库和文件权限。没有对应的工具链，Skill 就只是纸上谈兵。

然后，运行环境不同会影响结果。Skill 往往默认了一整套隐形条件：目录在哪里、Python 包有没有装、字体是否完整、沙箱能不能联网、命令行工具版本是否一致。PDF 转图片可能需要 poppler，中文排版需要字体，生成 Word 后还要确认在不同阅读器里不乱码。任何一个隐形依赖缺失，都会让结果变形。

最后，子任务的编排逻辑不同。比如一个写论文的 Skill 要求：先读题，查文献，写大纲，写正文，再排版。支持多轮编排的系统，会一步步执行、检查、重试；不支持编排的系统，可能把五件事一次塞给模型。结果看起来像论文，但逻辑松散，证据薄，格式也不稳定。编排模式直接决定任务的执行深度和最终质量。、

三、迁移失败从来不是“玄学”

来看一组真实场景里常见的对比。同一份 Skill，换一个系统后，失败通常不是模型“笨”，而是能力链条断了。

四、最难复制的是实战隐性经验

真正麻烦的地方，还不只是模型、工具和环境。很多有效的 Skill 背后，都有长期调试出来的隐性经验。

比如处理 PDF 时，我不会轻易相信 OCR 的结果。扫描版、双栏排版、脚注、表格、公式，都会让文本抽取出错。更稳的做法是先判断 PDF 类型，再决定直接提取或截图辅助，还是保留图片位置。生成 Word 后，也不能只看文字是否存在，还要渲染检查有没有乱码、表格错位、标题层级混乱。

再比如代码审查 Skill，成熟的写法会先识别语言和依赖版本，能运行测试就先跑单元测试，再读取错误日志，最后按漏洞、逻辑、边界、可维护性分类输出。很多新手写法只有一句“帮我看看代码有没有问题”，换个模型以后，审查质量自然天差地别。

这些经验如果没有显性写进 Skill，迁移时就会丢；即使写进去了，另一个模型也未必按同样方式执行。这和企业 SOP 很像：制度可以复制，但一线实操默契、专属工具链和团队习惯，很难复制。

五、Skill 的真实价值在哪里？

我并不是否定 Skill。相反，Skill 很有价值。它能把重复性经验沉淀下来，让 Agent 不必每次从零开始。

判断它是否容易迁移，可以看三个条件：任务是否足够稳定，工具依赖是否足够少，输入输出是否足够标准。越接近“固定流程、固定模板、低工具依赖”，Skill 越容易复用；越接近“长链条任务、外部数据、业务系统、反复校验”，就越不能只靠一个 Skill 文件。

所以，Skill 在复杂任务里是起点，不是终点。它能告诉 Agent 方向，但不能替代模型能力、工具接口、运行环境、知识库和失败重试机制。

六、如何写出高可迁移性的 Skill

既然 skill 有诸多的不确定性，我们怎样才能写成可复用且能够迁移的 skill呢？

首先，把复杂任务拆成低依赖子步骤，尽量使每一步骤的输出结果是确定的。不要只写“帮我生成一份正式文档”，而要拆成读取文件、识别结构、处理表格、生成初稿、渲染检查、和输出异常原因。

其次，把隐性经验显性化。比如明确写出：遇到扫描 PDF 不要直接概括；表格抽取失败要保留原图；生成 Word 后必须检查标题、表格、中文字体和页码。不要指望模型“自然懂”。说白了，就是凡事多交代几句，清晰一点。

然后，尽量工具解耦。不要把 Skill 写死在某个本地路径、某个私有工具名或某个单一模型习惯上。能用通用接口，就不要强绑定特殊环境。

如果是团队使用，至少要把模型版本、工具依赖和运行环境写清楚。否则今天能跑，明天换个模型或者换台机器，问题又会重新出现。

最后，一个好 Skill 和坏 Skill 的差别，不是写得有多长，而是有没有把执行条件、边界判断和失败处理写清楚。

七、Agent 与 Skill 的本质关系

我现在更愿意把 Skill 定义为经验载体，而非完整能力载体。它能降低 Agent 落地的重复成本，却无法抹平模型、工具、环境和编排方式带来的天然差异。

方法与经验可以自由迁移，但综合能力无法一键复制；流程与规范可以照搬，但整套运行系统无法简单移植。

真正具备可移植性的 Agent 能力，从来不会来自一个漂亮的提示词文件，而会来自一整套可验证、可运行、可调试、可标准化部署的工程体系。

这听起来没有“一键复制能力”那么浪漫，但这才是 AI 落地的真实世界。你遇到过“Skill 搬过去就不好用”的情况吗？是模型不听话、工具没装全，还是环境根本不支持？评论区聊聊你踩过的坑。