ARTICLE · 1209842
Agentic Skill:从一份文档到一份资产
这个系列写到第八篇，前面聊的都是 Agent 怎么把活干起来：Harness 是骨架，Loop 是转起来的节奏，上下文决定它知道什么，记忆决定它记得什么，权限决定它能碰什么，多 Agent 决定怎么分工，版本管理决定干完的活往哪放。
但有个东西我们一直没正面聊——Skill。就是那些写给 AI 看的“做事手册”，比如一份 SKILL.md：教它怎么部署、怎么抓数据、怎么走完一套固定流程。
最近 Google 公开了两份东西：一份是自家的 Agent Skills 生产流程复盘，讲他们怎么生产、测试和维护 Skill；另一份是有 Google 团队参与的 Agentic Skill 系统综述，把 Skill 拆成六元组和九个生命周期阶段。一份来自工程线，一份来自研究线，但它们回答的是同一个问题——一份做事方法，怎样才算真正进入了 Agent 的运行时，而不是躺在目录里慢慢过期。
这个问题比听起来要疼得多。先把疼的地方说清楚。
一、文件还在，能力已经不可靠了
写过 SKILL.md 的团队，大概都经历过类似的落差：文件写完了，格式也对，交给 Agent 确实能跑。过几周再回头看，情况就复杂了——有的被误触发，明明不该用的时候它冲上去了；有的该用的时候翻不出来；有的跑到一半卡在中间状态；还有的因为依赖的 API 改了个参数名，就悄悄失效了。
最麻烦的是最后一种：文件还在那儿，看起来一切正常，能力已经不可靠了。你不会收到任何报错，直到某天发现 Agent 一直在走一条老路。
家里那台空气炸锅的纸质说明书还在抽屉里。但机器去年升级过固件，预约按键换了位置——你照着说明书按，第一次没反应，第二次开始怀疑自己笨。说明书没坏，是它描述的那个世界变了。写给 AI 的 Skill 也是一样，它过期的时候不会自己告诉你。
这四种失效方式看着是四个问题，其实指向同一个根源：Skill 被当成了一次性的文档，而不是一份活着的资产。文档写完就完了，资产要有人管、有检查、有淘汰。误触发和翻不出来，是“什么时候用”这件没说清或者变了；卡在中间状态，是“出错了怎么办”没写进去；悄悄失效，是因为没有人负责跟着外面的世界一起改它。
所以问题从来不是“这份 Skill 写得好不好”，而是“写完”和“一直可靠”之间，隔着一整套维护机制。Google 那两份材料，讲的正是这套机制。
二、先把边界划清：缺一块，就不叫 Skill
综述做的第一件事，是给 Skill 一个形式化定义——六元组：激活条件（什么时候用它）、过程指令（怎么做）、适用约束（什么情况下别用）、工具接口（要用哪些工具）、执行策略（出错怎么办、控制流怎么走）、预期效果（做完了该是什么样）。
你不用背这六样，它真正有用的是当自检清单：六样里缺了哪几样，你写的东西就退化成了别的东西。
家里厨房有三样东西都跟“做菜”有关：冰箱上贴的做菜心得（只有说明，没说什么时候用，像 Prompt）；一台空气炸锅（只有接口，不管过程，像 Tool）；一摞点过菜的存根（只有历史，像 Memory）。而一份真正的菜谱是：什么场合做它、先腌后炸的步骤、油温几成、用哪口锅、炸过头了怎么补救、成品长什么样——一样不缺。
这三条边界划清楚之后，很多以前争论不清的问题就有了答案。比如“Skill 和 MCP 什么关系”“和提示词什么区别”——先拿六元组过一遍，缺哪块补哪块，比争论名词有用。
三、三条硬标准，把模糊地带筛干净
六元组之外，综述还给了三条判定标准，这三条更实用：
- 封装模块化
：Skill 是独立的外部资产，可以单独编写、版本化、验证和更新，不需要改模型权重，也不用动 Harness 的代码。 - 晚绑定动态加载
：Skill 不常驻上下文，而是根据当前状态和目标按需加载。系统提示是会话一开始就全部注入的，Skill 只在被需要时才出现。 - 过程性状态转换
：Skill 编码的是“怎么做”的操作知识，包括错误处理和控制流，而不是记录事实、保存历史。
一条条看。封装模块化，对应的是“改一个 Skill 不用动全身”——就像家里换一个插座不用重装整个房子的电路。如果改一份 Skill 得同时改提示词、改代码、改测试，它就没做到模块化。晚绑定动态加载，对应的是上下文的稀缺——系统提示从会话第一秒就占着位置，而 Skill 是“被需要时才进场”，这一进一出，省的就是模型最贵的注意力。过程性状态转换最容易被忽略：Skill 里写的应该是带分支的“怎么走”，比如失败了重试几次、超时了怎么降级，而不是“我们公司成立于哪一年”这类事实——事实归记忆管，手法才归 Skill 管。
拿这三条去过滤，模糊地带立刻清楚了。一段全局 JSON 格式指令不是 Skill——它没有模块化，也没有按需加载；一个搜索 API 不是 Skill——它没有过程编排；但一个附带超时重试、缓存降级和解析逻辑的 API 封装，就是综述所说的“工具执行技能”；一段对话记录也不是——它不包含执行逻辑。
顺带一提，综述里还有一条形式化的安全约束：Skill 激活当且仅当它声明的工具集，是当前上下文允许工具集的子集——否则就算权限提升。这句话把“Skill 能不能用某个工具”从口头约定变成了可检查的条件，第五节还会回到它。
四、Google 的做法：Skill 是一份要养的资产
综述回答“是什么”，Google 的工程实践回答“怎么养”。他们内部的 Skill 不是谁写完谁提交的孤立文档：有统一目录，有自动检查，提交时要过评测，每周还有质量检查。责任也落到人头——Repo Maintainer 维护仓库的共同规则，Skill Owner 对某一份 Skill 长期负责，跟着产品、API 和评测结果一起改它、必要时淘汰它。
听起来像常规软件工程？对，就是常规软件工程。但对 Skill 来说这套东西格外重要，因为普通文档过期，顶多让人多查几页；过期的 Skill，会让 Agent 直接走错工具、漏掉前置条件，甚至执行一套已经不适用的流程——而且是以“很自信”的方式。代码有测试兜着，错了会报红；Skill 错了，Agent 照样一本正经地往下跑，你到看到结果那天才知道不对。
评测也是同样的道理。一个新 Skill 提交进来，不是“看起来写得挺全”就能合入——它要在真实的任务上跑一遍，看完成任务用了多少 Token、花了多长时间，还要看这种收益换个运行环境还成不成立。这套流程跟招人一样：简历写得再好，上岗前总得试试真活。
连锁餐厅的菜品手册不是总部发一本就完了。每道菜有负责人，总部试菜不达标就下架改版，供应链换了食材，手册同步更新。要是半年不管，新厨师照着旧手册做，客人吃到的是错的味道——还以为自己是按标准做的。Agent 拿着过期 Skill 干活，就是那位很敬业但手册过期的新厨师。
导出规则也值得一提：Skill 先在内部构建和验证，达标后才通过自动化规则发布到 GitHub，同时剥离内部资产、Owner 信息和评测套件。同一份 Skill 在内网和外网是两个形态，公开的只是经过脱敏的一个切面。这个细节反过来提醒我们：你在 GitHub 上看到的 Google Skills，是按公开标准重新筛过一遍的子集，别把它当成 Google 内部用法的完整镜像。
五、工具声明不只是功能，还是权限
Google 的架构里有一条核心原则：优先引用远程 MCP 工具，CLI 和 API 调用只作为兜底。原因不是远程的更快，而是远程 MCP 服务器更容易纳入统一鉴权和 IAM 级别的权限治理——比让每个 Skill 裸调命令行，更适合放进长期维护的运行环境。
这和上一节那条形式化安全约束是一体的：Skill 声明的工具清单，不只是“我会用到这些”的功能描述，同时也是它的权限边界。要什么、批什么，都写在明面上，运行时可以逐条核对。你要加一个新工具，等于在申请扩权——那就得走一遍“这个工具为什么需要、谁能批、出事算谁的”的流程，而不是悄悄在文档里补一行。
当然，CLI 兜底的位置也得说清楚：总有工具没有现成的 MCP 服务器，总有一锤子的临时活不值得为它搭服务。原则是长期维护的能力往远程收，一次性的活允许裸调——区别在于你明确知道自己在用哪种，并且知道裸调的那部分缺少统一治理。
新员工入职，工牌上写的不是“你大概能去这些地方”，而是一个精确的门禁范围：能刷开哪几扇门，一目了然。更重要的是，申请范围的人和管理门禁系统的人，最好不是同一个——声明权限的 Skill 和执行权限边界的 Harness，也是这个关系。
一句话：能碰什么，不靠 Skill 自己自觉，靠运行时按声明去卡。
六、评测不看答案对不对，先看两个轴
Google 怎么判断一个 Skill 有没有带来提升？不只看答案对不对。完成任务用了多少 Token、花了多长时间、这种收益在不同运行环境里是否成立，都在考察范围内。他们用准确率和效率两个维度打一张 2×2 矩阵。
这张矩阵最有用的是右下角和左下角。一个 Skill 如果让结果看起来更完整，却让调用成本和失败重试一起上升——右上角——未必是改进，得算账；如果两头都不占，那就是纯粹的技能技术债，该淘汰了。
七、九个阶段，压成运行时的五个问题
综述把 Skill 的完整生命分成九个阶段：自主发现、编写与表示、记忆存储、动态检索与路由、组合与编排、执行与修复、终身适应、经验评估、安全治理。九个看着头晕，压成运行时视角其实是一条链：发现与路由 → 按需加载 → 受限执行 → 状态更新 → 结果验证 → 版本治理。
这条链为什么重要？Harrison Chase 在讨论 Agent 架构时说过：harness 决定的不是模型能说什么，而是哪些信息在什么时候以什么方式进入模型，以及模型的输出怎样被校验和落地。Karpathy 谈 context engineering 也表达过类似意思：工业级应用的难点不是写一个 prompt，而是把任务、资料、工具、状态、历史恰当地装进下一步的上下文。Simon Willison 补的那句最点题：Skills 的意义不在于给模型更多文本，而在于把“什么时候需要什么”从临时判断变成可复用的配置。
五个问题各自对应链路上的一环。找得到——触发描述写得准不准，和库里其他 Skill 打不打架，这是路由的事；用得上——被选中后按需加载，需要的参考文件跟不跟着进来；跑得完——执行时权限够不够、出错有没有修复路径；证明有效——跑完了拿什么证据说明这次真的比不用强；敢交给它——版本怎么管、出问题能不能回滚、谁来背安全责任。九个阶段是学术地图，五个问题是工程考卷。
所以 Skill 是 Context Engineering 的一个可版本化载体——但它替代不了 Context System，更替代不了 Harness。这也是为什么你会同时看到两条看似相反的路线：一条强调 Markdown、文件和按需检索，另一条强调结构化状态、事件流和严格的执行协议。它们不是在争论“文本好还是结构好”，而是不同生命周期的信息需要不同的载体：经验要人能读能改能审查，当前状态要机器能校验能合并能恢复。
八、三个容易被忽略的细节
综述里还有几处容易被略过的内容，挑三个说。
第一，安全不是附加章节，而是贯穿全生命周期的问题。自然语言指令本身就是容易被注入的入口——恶意 Skill 可以携带后门、窃取凭证、绕过护栏，而且风险会穿过多个生命周期阶段。防御体系分三层：准入前的静态审计（检查声明、扫可疑模式）、运行时的护栏（按工具声明卡权限、拦异常动作）、市场层面的治理（加密溯源签名，让来源可追）。但现实是：Skill 在调用前无法被完全验证——它到底会怎么跑，只有真跑起来才知道。这正是安全问题难以一次解决的原因，也是“受限执行”永远是链路里必设一环的原因。
第二，Skill 库自己也会长技术债。综述提到了 SkillOps 的五维健康度治理：触发描述冲突、重复流程、过期链接、失效脚本、无人维护的 Owner、越来越长的参考目录——这些问题和代码仓库的技术债没有本质区别。数量增长本身不是能力增长，能不能找到、能不能执行、能不能证明有效，才是更接近真实的指标。
第三，Skill 的收益是有条件的。综述引用了一项负面结果：程序性技能在网络安全 CTF 任务上零增益。论文用“环境反馈带宽假说”来解释——当环境本身能提供丰富诊断信息时，外置技能的边际收益递减。Skill 更适合那些环境反馈稀疏、试错成本高、领域约束强的任务，而不是所有任务都值得写成 Skill。
老司机开一条完全陌生的山路，需要导航提前提示每个弯道——这就是“环境反馈稀疏”，经验必须外挂。但老司机在自家小区倒车，车里那些驾驶辅助基本帮不上忙，因为小区里每倒一米都有真实反馈，他自己就是传感器。反馈越多，外挂手册越不值钱。
九、两块新拼图：WikiSkill 和 SKILL.state
综述给出框架，同一天发表的两篇论文分别补了“终身适应”和“执行与修复”两个阶段。一生产、一消费，正好一对。
WikiSkill 管生产端。它在执行轨迹和可执行 Skill 之间插了一层持久的 Wiki。流程是四步：Agent 干完活留下执行轨迹；从轨迹里提炼出反复出现的经验模式；把模式写成一份 Skill 提案；提案过一道验证闸门，过了才成为新版本。以前这类沉淀靠人写——谁有空谁写，写完没人验；WikiSkill 把“从干过的活里长出手册”变成了自动流程，而验证闸门保证长出来的东西真的能跑。
其中最精妙的是一处不对称设计：Skill 可以回滚，Wiki 永不回滚。失败的提案连同拒绝理由也留在 Wiki 里，下次提案时能看到“这个方向试过、为什么不行”。逻辑是：Skill 是易错的假设，Wiki 是沉淀的知识——知识不该因为一次假设失败而清零。
后厨黑板：新菜试做失败，菜谱可以撤下来，但“三月试过一次低温慢煮，汤底发苦，原因是火候”这条必须留在黑板上。撤掉的是那道菜，不是那次教训。
WikiSkill 还发现了一个有意思的现象：进化后的 Skill 能让小模型在部分任务上反超裸跑的大模型——实验里的 9B 模型赢了 27B 模型。但跨模型迁移也可能失效：小模型沉淀的 Skill 里塞满了模型特有的绕坑补丁，交给更强的模型反而拖累成绩。通用的过程性知识可以跨模型迁移，模型特异的补丁可能造成负迁移——写 Skill 时要分清哪些是领域通用的，哪些只是针对某个模型的 workaround。
SKILL.state 管消费端。它把执行重构为显式的状态转移：每一步只把三样东西交给模型——不可变的 Skill 说明、结构化的当前状态、最新的环境观察；模型返回状态补丁和动作；运行时校验补丁、合并出新状态，然后丢弃这一步的推理历史。单步提示词长度不变，累计 token 从 O(T²) 降到 O(T)。
这两个记号翻译成人话：传统做法里，每一步都要把前面的历史再带一遍，跑一百步，上下文里堆的是一百步的全家福，成本按平方涨；SKILL.state 里，每一步只带“当前快照加新观察”，历史压进了结构化的状态字段里，成本按直线涨。任务越长，省得越狠。
# SKILL.state 的每一步，只喂给模型三样东西： 输入 = Skill说明(不可变) + 当前状态(结构化) + 最新观察 # 模型只返回两样： 输出 = 状态补丁 + 下一个动作 # 运行时收尾： 校验补丁 → 合并出新状态 → 丢弃本轮推理历史这条边界很重要，但也不能推得太远。论文的前提是结构化状态足以支持下一步决策。如果任务需要回看完整轨迹来审计，或者早期的一条观察直到很久以后才被发现重要，直接丢历史就会损失信息。状态机不是“历史都不重要”，而是逼系统提前说清楚：什么是未来执行真正需要的最小充分状态。
十、写之前，先过六个问题
比起先看一份 Skill 写了多少页，现在更值得问的是六个问题：
它在什么条件下被触发，误触发和漏触发分别会带来什么代价； 输入和输出是什么，哪些信息还要回到权威系统确认，而不是直接相信上下文里的记忆； 哪些动作可以交给脚本或工具确定性完成，哪些判断仍然需要模型参与； 中途失败以后系统怎样继续，哪些副作用可以重试，哪些重试前要先查询结果； “完成”由什么证据确认，谁有权覆盖模型的完成判断； 谁负责维护，怎样评测，什么时候降级、回滚或淘汰。
这不是一张写作清单，是把 Skill 放回软件系统以后，几个绕不过去的责任问题。你会发现它覆盖的正是前面几篇讲过的东西：触发条件连着上下文工程，工具边界连着权限治理，失败恢复连着 Harness 的执行协议，完成标准连着验证，维护评测连着版本管理。只要其中几项始终说不清，Skill 大概率还停留在“写给模型看的说明”这一步——看着挺全，出了事没人接。
那到底什么适合沉淀成 Skill？高重复、边界明确、结果可验证的流程，适合；一次性探索、事实变化很快、验收标准本身还没形成的任务，硬写成 Skill 反而会把临时判断固化成错误规则。Aaron Levie 有句话说得准：随着模型越来越能处理原先由工程脚手架承担的事情，架构需要持续删改，而不是只做叠加。
所以以后再画 Agent 架构图，Skill 大概不会再被画成一个孤立的文件图标。它更适合被画在那条不断查找、加载、执行、验证和更新的运行循环里。它能被加载，也能被替换；能带来经验复利，也能在验证失败时回滚；能帮模型做事，但不会把权限、事实和完成标准一起交给模型决定。
回到开头那个落差：文件还在、能力不可靠。现在可以说得更准了——不可靠的从来不是那份 Markdown，而是缺了让它保持可靠的那些环节：没人声明它什么时候该上场，没人验证它跑完是否有效，没人负责在 API 变了之后跟着改。把这几个环节补上，SKILL.md 才从一份文档变成一份资产；补不上，再漂亮的写法也只是把过期时间往后拖了拖。
