Skills 的工程学：把经典软件工程搬进一个概率型运行时

引子:一个容易被讲浅的概念如果只把 Skills 理解成给 Agent 预置一些提示词模板,那就错过了它真正有意思的地方。Skills 和子智能体一样,是一个全新的概念;但它的核心本质,是将软件工程中历经验证的经典智慧,迁移并适配到 AI Agent 的知识架构之中。用一句更工程化的话说:Skill 是面向 LLM 运行时的函数/模块——你用名字调用它,不关心内部实现;它的description与输出契约是接口,body 是实现。但迁移这个词有陷阱。它不是把 C 语言的头文件复制到 Python 里那种平移。真正的关键洞察是:当这些经典原则迁移到 Skills 世界时,被优化的目标函数换了。要看懂 Skills,先得看懂这个目标函数换成了什么。这也是全文的主线。一、一条主线:软件工程管理的,始终是稀缺资源每一条软件工程原则,追问它到底为什么存在,最后都会落到某一种稀缺资源上。而在经典世界里,稀缺资源只有两种。其一,人的认知负荷。人脑工作记忆有限。绝大多数整洁代码原则,优化的根本不是机器,而是未来读代码那个人的脑子:起好变量名、拆分函数、写注释、单一职责、避免深层嵌套——这些机器全都不在乎。编译器会把你精心命名的变量压成寄存器编号,把你拆的函数内联回去。它们唯一的服务对象,是一个认知预算有限的人类读者。其二,机器资源(CPU / 内存 / 网络)。这是物理上真实有限的东西。优化它的是另一套原则:算法复杂度、缓存、分页、连接池、索引、压缩、惰性加载。几乎所有经典 SE 决策,都是在这两种资源之间做权衡——一个清晰的三重循环(照顾人脑)与一行看不懂的向量化写法(照顾 CPU),你必须取舍。而 Skills 引入了第三种、且是真正全新的稀缺资源:LLM 的注意力 / 上下文。为什么说它全新,而不是内存换个名字?因为它两头稀缺:硬上限:上下文窗口就那么多 token,装满就装不下——这一点像内存。软退化:更要命的是,就算没装满,你塞得越多,模型对每一条的注意力就越差(context rot / lost-in-the-middle)。信息会互相稀释。第二点在经典计算里根本不存在。打个比方:经典内存是你往 RAM 里多放东西,只是占了空间;而上下文是你每往里多放一个字节,CPU 的思考质量都会略微下降、略微变糊涂。天下没有这种内存。更进一步,承载这一切的执行器也变了:CPU 是确定性的(同样输入永远同样输出),而 LLM 是概率型执行器——同一段 body,换个上下文、换次采样,行为都可能不同。所以一句话概括 Skills 的处境:你正在用一套为确定性机器 人脑打磨了几十年的工程智慧,去经营一个概率型机器 全新的注意力资源的环境。记住这把尺子,再看下面五条原则的迁移,就能分清哪些是干净平移、哪些发生了变形。二、五条经典原则的迁移1. 关注点分离:严禁把一切塞进 CLAUDE.md核心理念是授人以鱼,不如授人以渔——Skills 把解决问题的方法、步骤与经验沉淀为可复用的结构化资产,而非一次性答案。这让 Agent 从依赖临时灵感转变为能稳定复现高质量工作流。由此形成三层职责划分:CLAUDE.md:全局规则(项目背景、通用规范)。Skills:专业工作流(特定领域的复杂逻辑封装)。子智能体:任务执行(动态规划与实时操作)。工程师警示:严禁把所有逻辑塞进 CLAUDE.md。这如同把所有代码写进main函数——上下文冗余、难以维护、无法扩展。而且在 Skills 语境下,后果更严重:CLAUDE.md 是常驻上下文,你往里塞的每一行都在持续消耗上面说的那种双重稀缺资源,不仅占空间,还稀释模型注意力。值得补一句:这三层不只是职责不同,更是上下文作用域与生命周期不同——CLAUDE.md 像全局配置常驻,Skills 像库按需载入,子智能体则拥有自己独立的上下文窗口(类似进程隔离)。分层的本质,是对稀缺注意力的分级管理。2. 依赖倒置:成立,但请认清它弱在哪核心机制是面向接口编程,而非面向实现编程。Claude 不直接依赖某个 Skill 的脚本或 Prompt 细节,而是依赖它的抽象接口(description 输出契约)。只要契约不变,开发者可以随时替换、重构、升级内部逻辑,而对调用方透明——耦合度因此大幅降低。这个映射是对的,但作为一篇诚实的技术文章,必须点出它与经典依赖倒置的本质差距:经典 DIP 的接口由编译器 / 类型系统强制——违约就编译不过。而 Skill 的契约是自然语言,没有任何东西强制 body 真的遵守 description。所以这是约定式依赖倒置(by convention),而非构造式(by construction)。后果很具体:可替换性是真的(你确实能重构 body 而调用方无感),但接口不变 ⇒ 行为不变这个不变式是弱的——因为行为是概率性的。解耦的价值在,解耦的保证却比代码低了一档。用它,但别误以为它和写代码一样稳。3. 惰性加载:渐进式披露,以及一处比 Web 更极端的地方“渐进式披露 按需加载”,这是典型的惰性加载(Lazy Loading)策略:系统不在启动时预载全部知识,而在首次需要某技能时才加载相关资源。这与 Web 的代码分割(Code Splitting)、数据库的延迟加载异曲同工——在正确的时间加载正确的资源,最小化初始开销。但要补两点,才算讲透:成本性质不同:Web 的代码分割省的是带宽和包体积,代价基本可逆;Skills 省的是上下文 token,而上下文过载不只是变慢,还会劣化推理质量。所以往惰性加载走的压力,比 Web更大,不是异曲同工而是更极端。它是三级披露,不是两级:description(常驻,便宜)→body(调用时载入)→ 引用文件 / 脚本(真用到才读)。这层结构本身就是一套精心设计的、面向注意力预算的取舍机制。4. 最小权限:allowed-tools不止是好习惯,更是安全边界仅授予 Skill 完成职责所恰好足够的权限,不多不少——如同 Linux 的chmod精确控制读写执行、AWS 的 IAM Policy 精细限定访问范围。明确不能做什么,往往比定义能做什么更能保障系统安全。在 AI 语境下,它还多防一层经典系统里没有的东西:混淆代理 / 提示注入(confused deputy / prompt injection)。当一个 Skill 处理不可信输入(网页、文件内容、他人消息)时,输入本身可能携带指令去劫持它。此时allowed-tools限制的是爆炸半径——即便被劫持,它也做不了越权的事。这让最小权限从卫生习惯升级为对抗注入的真正安全边界,精神上更接近能力安全(capability-based security),而不只是文件权限位。5. 开放标准:声明式、自包含、知识本位Anthropic 将 Skills 作为 Agent Skills 的开放标准推广,并在越来越多的 Agent 平台上获得原生支持。其成功建立在三个本质属性上:声明式(Declarative):纯 Markdown,任何大模型都能读懂,没有黑盒二进制。自包含(Self-contained):一个文件夹即包含全部所需,复制即安装,无需复杂依赖管理。知识本位(Knowledge-Centric):核心价值在内容本身而非特定格式,不绑定单一平台。正是这三点,让一次编写、到处运行从口号变为可能——你在 Claude Code 里精心设计的 Skill,理论上可无缝迁移到任何支持该标准的平台。这不再只是一个产品特性的故事,而是一个行业标准的故事:你学到的不是如何配置某项功能,而是如何为 AI Agent 生态构建标准化的知识包。(一处治学上的诚实:关于具体的发布日期、支持平台数量与名单等数字,建议以官方最新公开信息为准再行引用;本文只对上述设计哲学背书,它才是真正持久的洞察。)三、被忽略的下半场:Skill 的生命周期以上五条把 Skills 的静态架构讲透了。但从软件工程视角,还有一整个动态治理的下半场常被忽略:一个 Skill 怎么测试?怎么做回归?怎么观测它有没有被正确触发?其中有一个经典 SE 里没有干净对应物的新失效模式,尤其值得警惕:模型升级导致的行为漂移。Body 一字未改,底层模型换代,Skill 的行为就可能变。这相当于依赖版本 bump 把你搞崩了——但这次的依赖是解释器本身。你无法 pin 住它,也很难像 mock 一个函数那样把它隔离出来单测。这是概率型运行时带来的、最反直觉的治理难题。它的直接推论是:在这个世界里,行为测试不是可选项。没有编译器替你兜底,唯一能验证 Skill 是否仍然正确的方式,就是跑一遍看行为。Skill 越多、组合越深(比如一个 Skill 调用另一个),回归成本越高,这套测试与可观测性就越不能省。结语:一把判断迁移的尺子回到开头那句被讲浅的定位。Skills 的价值,从来不是又多了一种写提示词的方式,而是它把抽象、模块化、复用、组合、惰性加载、命名空间、最小权限这些经典软件工程原则,完整地带进了 Agent 领域。但迁移不是复制。因为运行时从确定性机器 人脑换成了概率型机器 全新的注意力资源,这些原则平移过来时会分成三类——而这正是本文想留给你的那把尺子:原则原本服务的资源迁移到 Skills 后的命运人的认知负荷部分平移:但读者从人换成了模型,衡量标准从人脑能装几行变成token 成本、在上下文中的位置机器资源(缓存、惰性加载)以类比平移:但成本函数变了——省的不再只是延迟,而是避免推理质量退化(经典世界没有的)必须新增:执行器是概率型的,你得补上经典 SE 不需要的东西——行为测试、对漂移的容忍、接缝处的冗余校验一句话收束:Skills 让软件工程的经典智慧在 AI 时代重新变得锋利;但要把它用好,你既要认得出哪些原则能平移、哪些会变形,也别忘了给这个概率型运行时补上软件工程的下半场——测试、版本与可观测性。抽象设计得再干净,少了回归保障,概率型运行时迟早会让你还债。因为归根结底,写一个 Skill,就是为一个会读自然语言的解释器写库。