Skill 不是越多越好：按需加载之后，还要决定什么时候不加载

2026 年秋天，Agent Skills 已经从「一个文件夹里放一份 SKILL.md」长成了完整生命周期：按需加载、选择性激活、评测验收，甚至签名与安装扫描。Microsoft Agent Framework、AgentScope 一类 Harness 也都把 skills 做成一等公民。

但生产里最先炸的，往往不是「技能太少」，而是「技能太多」。每个 skill 都往上下文里塞一段说明，模型反而更难选对；有的任务带上 skill 成功率还会掉，还多花 token。

一、渐进披露解决的是放得下

比较稳的加载节奏是三层：

1. 启动时只暴露 name 和 description
2. 模型判断相关后，再 load 完整 SKILL.md
3. references、scripts、assets 最后按需读取

这叫 progressive disclosure。它先回答「上下文装不装得下」，避免一上来把几十个技能全文灌进 prompt。

二、放进去有没有用，是另一道题

按需加载不等于应该加载。研究里反复出现的现象是：skill 经常没有收益，甚至拉低成功率。更靠谱的判断，不是看「带了 skill 的结果漂不漂亮」，而是做配对对比：同一任务，带与不带 skill 各跑一轮，估计增益。

实践上可以更粗一点：

• 新 skill 默认灰度，不进入全局常驻列表
• 连续若干任务无正增益，就降级为手动触发或下线
• description 写不清触发条件的，宁可不挂

Skill 是能力包，不是荣誉墙。挂上去就要付上下文税和选错税。

三、Harness 该卡住的几条红线

第一，工具可见性跟着 skill 走。只有当前激活 skill 需要的工具才注册给模型，避免「技能说明书很窄、工具面却全开」。

第二，脚本执行进沙箱。SKILL.md 可以读，scripts 要隔离跑；相对路径引用，不硬编码绝对路径。

第三，写风险必须带审批策略。一个 skill 如果声明能改生产、删资源、跨租户读，却没有 HITL 规则，就不该被 promote。

第四，变更要走草稿、回归、审核、灰度。Skill 一改，行为就变；没有版本和回滚，线上只能靠运气。

四、落地时的最小治理

1. 仓库里 skills 目录只放通过验收的包；草稿进 _draft
2. 启动上下文只注入名称与一句话描述
3. 每次 load_skill 记审计：谁加载、为了什么任务、事后是否成功
4. 每周看「加载次数高但成功率低」的 skill，优先治理它们

如果团队只有精力做一件事，先做第 4 条。最吵的 skill，往往也是最贵的噪声源。

结语

Skill 让经验可复用，也会让噪声可复用。Harness 的职责不只是把 skill 读进来，更是决定何时不读、读了之后工具面收多窄、失败了能否回滚。按需加载是起步，按收益激活才是生产。