这个词不该被翻译成提示词模板

Agent Skills 这个词最近又热起来，最省事的写法是把它归进「高级提示词合集」。这会把问题写小。

一个 skill 如果只是几段提示词，当然有用，但价值有限。更值得追的是另一件事：agent 生态正在出现一层类似软件包的东西。它把做某类工作的步骤、工具、脚本、文件、上下文读取方式和检查规则放在一起，让 agent 在需要时按包调用，而不是每次从零靠聊天上下文临时拼。

这和过去的 prompt library 不同。Prompt library 更像话术库，skills 更像能力包。前者告诉模型「你应该怎么说」，后者告诉模型「这类工作应该按什么流程做，必要时调用哪些资源，结果怎么检查」。

在 agent 开始替人做事之后，这个差别会变得更重要。模型能力还会变，但企业和开发者留下来的流程、工具和领域知识，不可能每次都重新塞进一段对话里。

为什么 skills 会从个人技巧变成资产层

一个开发者早期用 agent，常见做法是自己写一份项目说明：代码风格、测试命令、发布步骤、常见坑、不要碰的目录、review 偏好。用得久一点，又会加上脚本、检查清单、命令别名、工具说明。

这些东西只留在个人笔记里，作用很有限。换一个工具，重新复制一遍；换一个项目，重新改一遍；团队里其他人用，还是要靠口口相传。

Skills 把这些零散经验往一个可分发单元里收。一个 skill 可以有说明文件，可以有脚本，可以有示例，可以要求 agent 按需读取，而不是一开始就把所有内容塞进上下文窗口。它解决的问题是「怎么让一套工作方法可以被安装、复用和维护」。

开源社区已经在试这件事。addyosmani/agent-skills 把前端、性能、安全、测试、工程实践等工作方法拆成可安装 skills；openai/skills 则把可复用能力放进独立仓库。它们未必会成为最后的标准，但已经说明方向：agent 能力开始有了类似包生态的形态。

软件包的类比成立，但不能照搬

把 skills 类比成 npm 包，能帮助理解，但也有边界。

相似的地方在于，它们都在解决复用和分发。没人愿意每次写 Web 服务都从 socket 开始，也没人愿意每次让 agent 做财报分析、代码迁移、性能审计、投行 pitch 或安全检查时，都重新讲完整流程。

差别也很明显。传统软件包主要交付确定性代码；skills 交付的是一组会被模型解释和执行的工作约定。它可能包含自然语言、脚本、工具说明、输入输出格式、检查步骤和边界提醒。它是在被 agent 读取、选择、解释、调用。

这让治理难度更高。一个 npm 包有依赖版本、许可证、漏洞扫描和 lockfile；一个 skill 也会需要类似东西，但对象更复杂。

  • 这个 skill 来自哪里，谁维护。
  • 它会让 agent 调用哪些工具。
  • 它读写哪些文件或外部系统。
  • 它有没有过期的流程和坏掉的命令。
  • 它的建议和企业内部规范冲突时听谁的。
  • 它能不能被审计，能不能回滚到旧版本。

这些问题一旦出现，skills 就不再是「好用提示词」。它们会变成企业软件资产。

OpenAI 把 plugins 和 skills 放在一起，是一个信号

OpenAI Academy 讲 Codex plugins and skills，值得注意的重点是它把 plugins 和 skills 放在同一个扩展框架里讨论。

Plugin 更像连接能力：接工具、接服务、接外部系统。Skill 更像过程能力：告诉 agent 某类任务应该怎么做。两者放在一起，agent 才不只是「能调用工具」，而是「知道什么时候、按什么流程、用哪些工具完成一类工作」。

这也是 skills 比 prompt 更重的地方。Prompt 通常只改变一次对话的行为；skill 会影响一类任务的执行方式。它可能让 agent 学会怎么写迁移脚本、怎么做可访问性审计、怎么整理设计文档、怎么跑一套端到端测试，甚至怎么准备行业报告。

从平台角度看，这层会自然走向市场和目录。模型是底座，运行时负责执行，MCP 和插件负责连接，skills 负责把人类流程打包。谁能让这些包更容易安装、发现、权限化和更新，谁就更接近 agent 平台的控制面。

论文里的 Agent Skills 说明研究侧也在靠近

arXiv 上的《Agent Skills for Large Language Models》把技能看成让模型通过可组合能力完成更复杂任务的一层抽象。无论最后具体方法怎么演化，它至少说明研究侧也在关注同一个问题：不要只把能力压在一次性 prompt 和模型参数里。

这和工程社区的需求能对上。真实工作一组可复用的过程。写代码要读仓库、理解约束、改文件、跑测试、解释 diff；做金融分析要读表、建模、核对假设、产出材料；做内容审稿要查来源、改结构、检查文风、发布校验。

这些过程有稳定部分，也有变化部分。稳定部分适合变成 skill，变化部分交给 agent 在当次任务里处理。

这层抽象做好以后，agent 的学习方式会更像团队积累工程资产。今天一个人把性能审计流程整理成 skill，明天另一个人就不用重新摸索；今天一个团队把投研材料流程整理成 skill，下次换模型也可以继续用这套工作方法。

金融 Agent 是一个垂直工作包样本

Anthropic 的金融服务 agent 和配套 GitHub repo，也可以放进这个趋势里看。它是在把金融分析里的连接器、数据源、工作流程、子 agent 和任务模板组织起来。

这类垂直 agent 最后很可能不会只以聊天窗口存在。它们会被拆成更细的工作包：KYC、pitch deck、估值复核、市场简报、Excel 建模、财报问答、会议准备。每个包都有输入、工具、检查点和输出格式。

对企业来说，这比「买一个万能 agent」更实际。业务部门不需要先理解 agent 架构，只需要知道某个工作包能不能安全地跑完一类任务。平台团队则需要在背后管理版本、权限、数据来源和审计。

这也是 skills 和垂直 agent 会汇合的地方。垂直 agent 负责面向业务的入口，skills 负责把里面可复用的流程拆成能力单元。前者像产品，后者像依赖。

门槛会从会写变成会管

如果 skills 继续增加，早期最热闹的阶段一定是安装和分享：这个 skill 让 agent 更会写测试，那个 skill 让 agent 更会做报告，另一个 skill 能帮你迁移框架。

但企业会卡在治理上。

一个团队可以随手安装十几个 skills，很快就会遇到问题：两个 skill 的规则冲突，旧 skill 里的命令过期，第三方 skill 要求调用外部服务，某个 skill 把内部路径写进输出，另一个 skill 的许可证不清楚。到这时，能力包越多，风险和维护成本也越高。

Skills 生态成熟的标志，不会只是数量。更重要的是这些能力能不能被管理。

  • 是否有来源签名和版本记录。
  • 是否能限制每个 skill 可调用的工具和数据。
  • 是否能在团队内审批、下架和回滚。
  • 是否能自动检测过期命令、坏链接和不合规流程。
  • 是否能把一次失败反馈回 skill 本身，而不是只修当次输出。

这会把 skills 从个人效率工具推向企业平台能力。好用只是第一步，可治理才决定能不能进组织。

下一层竞争会围绕「流程包」展开

过去大家谈 agent 平台，容易先看模型、上下文长度、工具调用、MCP、沙箱和权限。这些仍然重要，但它们更像底座。底座成熟以后，差异会往上移：谁拥有更好的流程包，谁就更容易留住用户。

开发者会积累自己的 coding skills。公司会积累内部交付 skills。咨询公司会把行业方法打包成客户可用的 agent workflows。开源社区会继续整理通用能力包。模型公司也会把官方最佳实践包装成可安装 assets。

这不是小功能。它关系到 agent 的长期复用方式。模型换代很快，工具接口也会变，但一家公司怎么做风控、怎么做代码评审、怎么写销售提案、怎么跑发布门禁，这些流程知识不会每天重写。

Agent Skills 的关键就在这里：它把这部分知识从一次性对话里拿出来，变成可以被安装、升级、审计和复用的软件资产。

以后评价一个 agent 平台，不能只问它接了几个模型、支持多少工具。还要问它能不能管理 skills，能不能让团队把工作方法留下来，能不能让这些方法跨模型、跨项目、跨工具继续有效。

到那一步，skills 就不再是提示词边角料，而是 agent 时代新的软件依赖。