为什么我不再把所有规则都塞进一个提示词？

目录大而全的提示词很像一个不断膨胀的单体项目Skill 的关键不是文件夹而是按需加载Tool 给 Agent 一双手Skill 告诉它怎么做事从长提示词变成可以维护的能力模块拆成 Skill不代表问题自动解决了这几天写 AI Agent 系列文章时我一直在调用两个不同的 Skill。一个负责写作。里面放着文章类型、语言风格和事实边界。比如不能虚构亲身经历技术观点需要区分个人判断和外部资料文章要像开发者朋友之间聊天不要写成一篇四平八稳的行业报告。另一个负责生成封面。里面保存着品牌版式、参考图片、标题长度和视觉要求。它知道故事观点文章应该使用深蓝夜色和暖光书桌也知道生成以后还要检查中文有没有写错。模型没有变。变化的是它在不同任务中加载的那份操作手册。写文章时它不需要知道封面的安全区域生成封面时也不需要重新阅读整套写作规范。这正是 Agent Skills 让我觉得有意思的地方。它不只是把提示词拆成几个文件而是在改变 Agent 组织和使用专业知识的方式。大而全的提示词很像一个不断膨胀的单体项目做 Agent 时很容易把所有规则都写进系统提示词。一开始只有角色和任务说明。后来发现输出格式不稳定于是加上格式规范工具经常选错再补一段工具说明遇到新的业务规则继续往里面追加。写到最后一个提示词里可能同时放着代码规范、文档模板、排版要求、工具用法和异常处理。模型每次执行任务都要先读完这些内容。即使这次只需要生成一张封面它也得同时看到如何分析 Excel、检查代码和部署网站。这和软件开发中的单体项目很像。项目刚开始时把所有功能放在一起确实简单。随着业务增加不同模块开始互相影响改一个地方其他地方也可能跟着变化。系统提示词也是一样。规则越来越多以后它不但难以维护还会占用上下文让真正与当前任务相关的信息被淹没。Agent Skills 想解决的就是这个问题。Skill 的关键不是文件夹而是按需加载一个 Agent Skill 的基本结构并不复杂。它是一个文件夹里面至少包含一个SKILL.mdmy-skill/ ├── SKILL.md ├── scripts/ ├── references/ └── assets/SKILL.md负责说明这个 Skill 是什么、什么时候使用以及完成任务时应该遵循什么流程。其他目录可以按需存放脚本、参考资料、模板和图片。看起来它似乎只是把原来的提示词拆成了几个文件。真正的区别在于支持 Agent Skills 规范的运行时不需要一开始就把所有内容交给模型。它采用的是渐进式披露。按照规范Agent 通常先看到 Skill 的少量元数据例如name和description--- name: cover-generator description: 为公众号故事观点文章生成品牌横版封面。 ---这些信息更像一张能力目录。其中description不只是功能介绍还承担着路由作用。它要让 Agent 判断当前任务是否应该使用这个 Skill。当任务匹配时Agent 才继续读取SKILL.md中的完整操作流程。如果流程又引用了详细资料、脚本或者模板再根据任务需要加载references/、scripts/和assets/中的资源。也就是说Agent 先知道自己拥有哪些能力真正需要时再逐步加载细节。专业知识不必全部常驻在系统提示词里上下文也可以留给当前任务。Tool 给 Agent 一双手Skill 告诉它怎么做事Tool 和 Skill 经常放在一起讨论但它们解决的问题并不相同。Tool 提供行动能力。例如读取文件、调用 API、执行命令或者生成图片。它让模型的判断能够变成真实操作。Skill 提供的是完成某类任务的方法。它告诉 Agent 应该先做什么、什么时候调用哪个工具、结果如何检查以及遇到异常以后应该怎样处理。比如图片生成工具可以根据提示词生成一张图片。但「为 Shawn Liu 手记生成故事观点封面」并不只是调用一次图片生成工具。它还需要知道品牌标识放在哪里、标题最多写几行、应该使用什么颜色、哪张图片是参考模板以及生成以后需要检查哪些问题。Tool 解决「能不能生成图片」。Skill 解决「怎样生成一张符合要求的封面」。同一个 Tool 可以被不同 Skill 使用一个 Skill 也可以组合多个 Tool。所以Skill 更像一套可以被 Agent 执行的工作方法而不只是另一段 Prompt。从长提示词变成可以维护的能力模块整理这部分笔记时我最先想到的还是软件开发中的模块化。原来所有规则都塞在一个系统提示词里现在把不同领域的知识拆开每个 Skill 负责一种相对独立的能力。写作是一个 Skill生成封面是另一个 Skill处理表格还可以再做成一个 Skill。它们有各自的触发条件、操作流程和资源也可以单独修改、测试和进行版本控制。在支持 Agent Skills 格式的环境之间这些能力还有机会被复用而不必为每个 Agent 重新写一套提示词。当业务规则发生变化时只需要修改对应的 Skill。当某个流程效果不好时也可以单独检查它的触发条件、操作步骤和验证方式而不是继续向一个越来越长的系统提示词里追加规则。这才是 Skills 真正解决的问题提示词开始从一段难以维护的长文本变成可以独立管理的能力模块。拆成 Skill不代表问题自动解决了Skills 也不是把文件夹建好Agent 就会突然变得可靠。如果description写得太宽泛Agent 可能错误触发写得太模糊真正需要时又可能找不到。如果流程本身含糊加载以后仍然不知道下一步该做什么。如果多个 Skill 的职责重叠Agent 也可能不知道应该选择哪一个。所以Skills 解决的是能力组织问题不会替我们自动写出正确的业务规则。这和代码模块化一样。把一段混乱的代码拆成几个类不代表设计就一定变好了。真正重要的仍然是每个模块的职责是否清楚接口是否稳定边界是否合理。现在回头看这几篇文章的写作过程我觉得变化并不在于模型突然学会了我的写作风格和封面要求。它只是先看到了有哪些能力。需要写文章时打开写作手册需要生成封面时再打开封面模板。不必把所有规则都塞进一个提示词也不必让模型每次从头读一遍。这可能就是 Agent Skills 最朴素也最实用的价值。引入地址