从能用到好用：AI Agent Skill 编写与调用完整思路

Skill 本质上是一个文件夹，里面通常包含三样东西：一份主控的 Skill Markdown（顶部 Front Matter 写名称和描述，下方是方法论）、一个 References 文件夹（存放非每次必载的参考资料）、一个 Scripts 文件夹（存放可直接执行的脚本）。这套结构搭配渐进式披露机制运作：模型启动时只载入每个 Skill 的 Name 和 Description（约 100 Token），对话触发后才载入完整 Skill 文件，References 和 Scripts 则按需加载，没用到的完全不占 Context Window。这就是为什么你可以挂很多 Skill 却不撑爆上下文。据 B 站 UP 主的实战分享，过去一年他为各类公司团队打造了上百个 Skill，真正难的不是“写出来”，而是写出不用主动要求、Agent 会自己触发、产出稳定且人类能长期维护的 Skill。

什么时候值得做一个 Skill

判断标准可以归纳为三个信号：高频触发（同类任务反复出现且流程固定）、领域知识（模型训练时无法获取的专案路径规范、公司文件格式等）、高出错成本（产出需对外交付、错误代价高）。不必纠结三个条件是否全中——现在制作 Skill 的成本极低，与其花时间权衡，不如直接开做，用不到再删。

一个上班族常见的例子：每周花一小时翻工作日志、会议记录和专案进展，汇整成老板要的格式。这类任务就是典型的 Skill 候选。

渐进式披露（Progressive Disclosure）借鉴自 UI 设计领域，指系统仅在用户需要时才逐步展示信息，避免一次性呈现全部内容造成认知过载。在 LLM 应用中，它被用来管理有限的 Context Window：Agent 启动时仅加载每个 Skill 的元数据（Name 与 Description），只有当对话内容与某个 Skill 的描述匹配时，才载入该 Skill 的完整正文；References 中的参考资料和 Scripts 中的脚本则进一步延迟到执行具体步骤时才读取。这种分层加载策略使得挂载大量 Skill 成为可能，而不会因预加载全部内容导致上下文膨胀、推理成本上升和召回精度下降。

两条制作路径：逆向工程与主动发起

逆向工程是新手友好的起点。以周报为例：周三早上开一个新 Session，让 Agent 连接 Google Drive 找日志、进 GitHub 查一周 Commit、汇整成 Markdown。过程中 AI 可能出错、遇权限问题，你与它协作一小时不断调整，最终产出满意结果。此时不要急着关掉 Session——这是最值钱的 Context。接着调用 Anthropic 官方的 Skill Creator（可从 Claude 官方 Marketplace 安装，或直接让 Claude 帮你装），把这段对话转成可重复使用的 Skill。不装插件也行：让 AI 先上网搜索 Skill 制作 Best Practice，再执行转换即可。

主动发起适用于脑中已有想法但还没试做过的情况。把自己的目的、想象中的执行流程、可能难点告诉 AI，请它整理成 Skill，并在开始前先与你厘清不清楚的地方。这里的核心心态是：不要问 AI 能为你做什么，而是反过来想——你有没有把上下文、约束、方法和目标准备到足够让 AI 成功交付。做 Skill 的过程，本质是在当 AI 的 PM。

还有一个进阶技巧叫 Evaluation Driven Development：做 Skill 前先让 AI 裸做一次任务，什么方法论都不给，看它卡在哪里。这些卡点才是你真正该人为填补的空白，而不是脑补出来的规则。优化时也别只说“再试一次”，而要追问：缺工具、缺规则、缺文件，还是缺验收标准？有效的迭代补的是系统缺口。

三大常见坑与解法

坑一：Agent 根本不触发 Skill

Skill 的 Name 和 Description 是 Agent 判断是否触发的唯一依据。命名用小写字母加连字号串联动名词或名词，如 weekly-report-drafting、pdf-processing，具体到人和 Agent 都能一眼看懂。Description 有三条规则：必须同时包含“做什么”与“何时用”；用第三人称（写 “I can help you” 会与系统视角冲突）；触发词要是使用者会自然说出的话，而非技术名词。参考写法：Drafts weekly status updates for managers, aggregating data from Google Drive and GitHub. Use when user mentions weekly reports, team updates, status summaries, or weekly reviews. 若仍不触发，检查描述是否过于技术导向，或反过来过于宽泛导致过度触发。

坑二：产出品质不稳

同样的 Skill，这周周报很棒，下周格式不对，再下周漏掉一个 Commit。根源往往是把 SOP 写得太窄——窄 SOP 假设模型不会判断，但现代推理模型的判断力已相当强。正确做法是给原则，不锁死步骤：写清楚为什么做、该抱什么心态、核心判断原则是什么。

判断标准很清晰：这件事的对错有没有客观标准？有（如表单栏位验证），就写严格步骤；没有（如周报取舍），就写原则框架。

SOP（Standard Operating Procedure，标准作业程序）是将重复性任务的执行步骤固化下来的书面规范，常见于制造业和客服领域。在 Skill 编写中，SOP 式写法会把每一步操作、每一个判断分支都详细列出，试图让模型像流水线工人一样严格执行。这种做法的局限在于：它假设执行者缺乏判断力，而现代推理模型已具备较强的情境理解和取舍能力。过度细化的 SOP 不仅增加维护负担，还会在遇到未覆盖的边界情况时让模型无所适从，反而导致产出僵化或遗漏。因此文章建议区分任务性质：有客观对错标准的环节写严格步骤，依赖判断的环节则写原则框架。

坑三：Skill 写得太长

LLM 存在 Context Rot 现象——载入 Token 越多，召回精度越低。官方建议超过 500 行就该拆，实战者更倾向控制在 200 行以内，因为人类自己都难以维护。拆分方式对应 Skill 的三层结构：大量参考资料、特定情境才用的扩充内容放 References（如百行的 Output Format、公司术语表、进度落后时的写法范例），在 Skill 中用“请参考 Reference 资料夹里的 XX”按需取用；确定性操作（排序、格式验证、API 呼叫、计算）写成 Scripts，Agent 的任务从“自己想怎么做”变成“跑脚本读结果”，既防模型自由发挥，脚本代码本身也不进 Context，只回传执行结果。

更专业的场景可引入 Subagent 做最后品控：基于 Separation of Concerns 原则，开一个独立 Subagent，给它干净的 Context 和 Checklist 当输入，让它自行验收后回传结果，既隔离 Context，也避免主 Agent 既当运动员又当裁判。

Context Rot（上下文腐化）指随着输入上下文长度增加，大语言模型对其中信息的召回与利用精度反而下降的现象。研究表明，当上下文填充大量无关或冗余内容时，模型容易忽略关键指令、混淆信息优先级，甚至产生与早期内容矛盾的输出。这并非简单的“记不住”，而是注意力机制在长序列上的分配效率衰减。对 Skill 编写而言，这意味着把所有参考资料、范例和边界情况都塞进主文件会适得其反。控制主 Skill 在 200 行以内、将非必要内容外挂到 References 或转为 Scripts，正是为了保持主上下文的“干净”，让模型把注意力集中在当前任务的核心指令上。

Subagent（子代理）是在主 Agent 之外独立启动的辅助智能体，拥有自己独立的上下文窗口和任务指令。在主从架构中，主 Agent 负责统筹流程，遇到需要专项检查或独立验证的环节时，将干净的任务描述和验收清单交给 Subagent，由其在隔离环境中完成判断后回传结论。这样做有两个好处：一是避免验收标准与执行过程混在同一上下文中相互干扰，二是实现职责分离——执行者不自我评分，品控由独立视角完成。Subagent 的结论通常以结构化摘要形式返回，不占用主上下文过多空间，适合用作 Skill 流程末端的质量门禁。

维护：Skill 的复利来自迭代

Skill 最有价值的地方是复利效应——今天做一版，明天用一次修一次，一个月后它往往已不是原来那份。但多数人做完就放着不管，随便检查自己的 Skill 就会发现：Reference 里堆着无用资料，200 行膨胀到 1000 行，重复信息遍地。不维护的 Skill 会表现越来越差，甚至成为账单爆掉的元凶。

维护时机有两个：新模型发布时，拿既有 Skill 跑一遍，重点删掉那些为补旧模型弱点而加的“补丁”；每次工作流跑完后，请 Agent 自行复盘——盘点错误、分析原因、判断能否融入 Skill。但要预防 Agent 把新信息插得到处都是、结构崩坏，或写出人类难维护的内容，写入前必须 Double Check。

每次维护固定做三件事：删除冗余信息（一个信息讲一次）、重整结构（自己快速读一遍，读不懂就重构）、把过多范例和 Corner Case 萃取到 References。

Skill 的真正意义

Skill 不只是提升个人生产力，它是个人知识转移给 Agent 的载体。过去要花很长时间教新员工的事，打包成 Skill 后 Agent 立刻学会；过去锁在脑中的方法论、判断标准、踩过的坑，现在可以一份份转移出来。它也是团队能力共享的新界面——新人进来，他的 Agent 已经会了。模型会越来越强，你写 Skill 不是把 AI 拉高到你的水准，而是把你的思考方式教给它。回扣 Harness Engineering 的概念：人类掌舵，Agent 执行。执行心法之所以重要，正因为它才是真正有独特价值的东西。