Skills 解析-从智能体动物园到技能资产

Info

核心观点为什么 Anthropic 在 2025 年建议你不要再对 Agent，而要去做 Cloud Skills？

• •过去范式：缺财务能力 → 造财务 Agent，缺法务能力 → 造法务 Agent

• •结果：能力增长靠复制粘贴，维护成本直线爆炸

• •新范式：保留一个通用 Agent 内核，把专业经验做成可复用的 Skills

一、行业痛点：智能体动物园

Info

什么是"智能体动物园"？

为每个业务场景创建专门的 Agent（财务、法务、运营...），每个都有独立的 Prompt、工具链、权限。就像动物园养着各种动物，组织里"养"着一群各自为政的 Agent。

核心问题：

• • 知识碎片化（同一条规则在多处重复）

• • 维护地狱（改一次要改 N 个 Agent）

• • 管理爆炸（不是多了机器人，而是多了几套系统）

多 Agent 的问题不是 Agent 不够聪明，而是系统不够像软件

1.1 管理成本转移

OpenAI 的说法（Sam Altman）：

很多团队现在的工作方式已经像在带一群初级员工

• • 你给任务 → Agent 产出

• • 你做质检 → 打回去返工

• • 再拼装

现实是：管理成本会迅速转移到你身上

1.2 Google 的路径：深度集成

Google 把能力往产品里深度集成，把规划和执行变成工作流的核心组件。这意味着：

• • Agent 会越来越多地进入默认工作方式

• • 而不是一个玩具 Demo

1.3 困境：Agent 越像员工，越需要组织级流程

需要的规范：

• • ✅ 流程

• • ✅ 质检标准

• • ✅ 规范

否则：你得到的不是自动化，是更大规模的返工自动化

二、三大核心痛点

痛点 1：模型很聪明，但不专业

Barry John 的观点：

今天的 Agents 缺少专业知识，还经常遗漏上下文

工程语言翻译：

• • 你以为它在理解业务？

• • 其实，它在补全文本

为什么会这样？

• • 通用模型解决的是通用推理

• • 不解决你公司的口径、规则、暗坑

举例：

• • 财务报表：模型能写出一份像样的报表

• • 但字段定义、审批流程、合规口径、内部约束往往全错

悖论：

• • 智商越高，胡说八道的自信感也越强

真实业务：

• • 最值钱的不是灵感，是一致性

• • 你不需要一个 300 IQ 的天才从零推导税法

• • 你需要一个被专业流程训练过的执行者

痛点 2：维护成本爆炸

一开始的想法：

• • 给财务做一个 Agent

• • 给法务做一个 Agent

• • 给运营再做一个

很快发现：

• • 这不是多了几个机器人

• • 而是多了几套软件系统

每个 Agent 都有：

• • Prompt

• • 工具链

• • 权限

• • 评测集

• • 失败兜底

一旦你有十几个：

• • 组织里就出现了典型的知识碎片化

• • 同一条业务规则在五个 Agent 里各写一遍，版本还不一致

痛点 3：上下文窗口天然有限

问题：

• • 想把所有规则塞进一个系统提示词可以

• • 但代价是：

• • • ✗ 长期 Token 占用

  • • ✗ 成本上升

  • • ✗ 调试困难

智能体动物园：

• • 不是夸张，它描述的是一种工程必然

• • 当你用复制粘贴去扩展能力

• • 系统就会用维护地狱来还债

业内吐槽：

有的所谓 Agent 只是给 LLM 套个聊天壳溢价营销
真正难的，不是起一个 Agent
而是把它做成一个可迭代、可治理、可复用的产品

三、Anthropic 的反思：工程化范式转换

3.1 核心洞察

别再造一堆不同的 Agent 了：

• • 保留一个通用 Agent 内核

• • 把专业经验做成可复用的技能

3.2 关键的心智切换

竞争焦点从：

• • ❌ 谁的 Prompt 更长

• • ✅ 谁能把流程知识模块化、版本化、可组合

3.3 类比软件行业

你不会为每个业务需求重写一个操作系统：

• • ❌ 旧方式：为每个业务需求重写操作系统

• • ✅ 新方式：做一个 OS，然后用应用和插件去扩展能力

记忆点：

当 Agent 开始进入真实工作流
真正的护城河不在 Agent 的数量
而在技能资产的沉淀速度

四、Cloud Skills 是什么？

4.1 定义

Skill 不是更长的提示词

Skill 是一组为 Agent 打包的可组合的流程性知识

4.2 三个关键字

1️⃣ 流程性（Process）

• • 强调怎么做，不是是什么

• • 例如：财务报表

• • • 先拉数

  • • 再校验

  • • 再汇总

  • • 再套模板

  • • 再出具

2️⃣ 可组合（Composable）

• • 可以像搭积木一样叠加

• • 同一条链路里可以：

• • • 数据分析 Skill

  • • 合规审查 Skill

  • • 报表格式化 Skill

3️⃣ 可执行（Executable）

• • 允许把确定性的部分丢给脚本去跑

• • 模型负责：规划、选择、解释

• • 脚本负责：计算、转换、生成文件

4.3 一句话总结

Skills 是把组织经验从对话里的隐性知识
变成可版本化、可复用、可执行的显性资产

五、Skill 的文件结构

5.1 核心入口：skill.md

不是随便写一段话，而是可被 Agent 发现和加载的说明书

三件套：

1️⃣ 元信息

• • 名字

• • 描述

这部分会在启动时被预加载，让 Agent 知道有哪些技能可用

2️⃣ 执行指南

• • 步骤

• • 边界条件

• • 输入输出

这部分在技能被触发时才读进来

3️⃣ 配套资源

• • 脚本

• • 参考文档

• • 模板文件

真正重的东西放在文件夹里，Agent 按需读取或直接执行

5.2 对团队的好处

Skill 天然适配：

• • ✅ Git

• • ✅ 评审

• • ✅ 版本管理

• • ✅ 回滚

你终于可以像管代码一样管业务流程了

六、Anthropic 的隐喻：新员工入职手册

把通用 Agent 想象成一个新员工：

• • 模型智商很高

• • 工具也会用

• • 但不了解你公司的流程、口径、禁区、旧做法

6.1 旧做法：每来一个需求就重新招一个专岗机器人

结果：岗位越多，维护越炸

6.2 新做法：更像现代组织

不重复造人，给同一个新人发不同的入职手册：

• • 财务一本

• • 法务一本

• • 招聘一本

哪天流程改了？改手册，所有人同步更新

6.3 对 AI 产品团队来说

最值钱的资产：

你沉淀了多少本高质量的入职手册
也就是你的Skill Library

6.4 内部开会建议

• • ❌ 少问：还要不要再做一个新 Agent？

• • ✅ 多问：我们要把哪个流程写成 Skill？

让它可以被：

• • ✅ 复用

• • ✅ 治理

• • ✅ 规模化

七、工程架构拆解

7.1 核心洞察：多 Agent 的问题

多 Agent 的问题不是 Agent 不够聪明
而是系统不够像软件

问题：

• • 你越做越多，最后一定变成动物园

• • 每个 Agent 一套 Prompt、一套工具、一套评测和权限

• • 更关键的是：知识被复制粘贴在不同 Agent 里

• • 一条口径改了，你要改 N 次还不一定改对

7.2 单一通用内核 + Skills 的核心

把智能和专业经验解耦：

• •通用 Agent：负责理解、规划、调用

• •Skills：负责流程、规范、脚本和资料

扩展能力的单位：

• • ❌ 新增一个 Agent

• • ✅ 新增一个 Skill 包

从造系统切换到做插件生态：

• • 从工程管理角度，这是降维打击

7.3 上下文不是容量问题，是加载策略问题

渐进式披露（Progressive Disclosure）：

第一层：元数据

• • 只放：技能名和描述

• • 这让 Agent 在启动时能知道有哪些技能

• • 但不把细节塞进上下文

第二层：触发时再读 skill.md

• • 这一步才把具体流程和指令读进来

第三层：按需加载额外文件

• • Skill 目录里可以挂很多额外文件

• • Agent 在需要的时候再打开

• • 例如：reference.md、forms.md 这类更细的材料

结果：

• • 技能库可以无限扩展

• • 模型上下文却不会被一次性撑爆

• • 你得到的是一种很像软件的：

• • • ✅ 目录索引

  • • ✅ 按需加载

为什么天然适合企业：

• • 企业知识就是海量分散，还经常更新

• • 有了渐进式披露，问题变成：

• • • 谁来决定何时加载哪个技能？

八、动态执行的调度逻辑

8.1 流程

1. 1.初始状态：上下文中只有系统提示 + 所有技能的元数据

2. 2.用户提需求：Agent 先做匹配

• • 我该不该触发某个技能？

• 3.决定触发：不是把整个技能库都读进来

• • • 而是先通过工具去读取对应目录下的 skill.md

• 4.递归加载：如果 skill.md 里引用了 forms.md 之类的文件

• • • Agent 再决定要不要继续往下读

  8.2 最重要的工程点

  你终于有了：

  • • ✅ 技能选择的显示过程

  • • ✅ 技能加载的显示过程

  这意味着：

  • • ✅ 可观测

  • • ✅ 可调参

  • • ✅ 可评测

  你可以定位错误：

  • • 是没选对技能？

  • • 还是技能写的不清楚？

  • • 还是执行阶段跑偏？

  对企业落地来说：

  这比模型玄学重要太多了

  ---

  九、代码执行：最工程化的一刀

  9.1 问题

  很多团队做 Agent 的时候喜欢让模型用自然语言把每一步都说出来

  但只要涉及：

  • • 计算

  • • 排序

  • • 抽取

  • • 格式化

  这条路一定：

  • • ✗ 又贵

  • • ✗ 又不稳

  9.2 Skills 的解决方案

  允许把脚本放在技能目录里：

  • • Agent 需要的时候直接运行

  • • 脚本本身不用塞进上下文

  • • 输出结果再回流给模型

  9.3 两个硬收益

  1️⃣ 成本和速度

  让模型逐 Token 生成一个排序结果

  • • 天然比跑一段排序代码贵

  2️⃣ 确定性

  企业要的是可重复的执行，不是灵感

  9.4 建议定位

  把 Skills 的定位再提纯一次：

  • •模型：负责理解、决策、编排、解释

  • •Runtime：负责确定性执行

  只要你把重活丢给 Runtime：

  • • Agent 才真的像可交付的系统

  • • 而不是能聊两句的助手

  ---

  十、MCP 和 Skills 的关系

  10.1 一句话总结

  MCP 解决能连什么，Skills 解决怎么把事做对

  10.2 分层架构

  MCP（工具和数据源层）

  • • 让 Agent 能够去连：

  • • • CRM

    • • 网盘

    • • 数据库搜索

    • • 内部系统

  Skills（工作流和规范层）

  告诉 Agent：

  • • 在这个业务里，步骤怎么走？

  • • 边界是什么？

  • • 检查点在哪？

  • • 输出格式怎么写？

  10.3 典型企业任务示例

  做一个客户流失报告：

  1. 1. 通过MCP拉数据

  2. 2. 再用分析 Skill做指标口径和建模流程

  3. 3. 再用报表 Skill输出到指定模板

  4. 4. 最后再通过MCP写回到知识库或者发到协作工具

  10.4 架构体检建议

  如果你在搭平台，用这个分层做架构体检：

  • •连接能力→ 归 MCP

  • •业务方法→ 归 Skills

  别把流程写死在 Agent 本体里：

  • • 你会少掉一大半越做越乱的债

  ---

  十一、组织分工变化

  11.1 AI 产品经理（PM）

  最致命的一点：

  • • 你不再是在排功能列表

  • • 你是在规划技能资产组合

  过去做需求：

  • • 这个部门要一个法务 Agent

  • • 那个部门要一个财务 Agent

  现在更像：

  • • 我们要把公司的关键流程拆成可组合的 Skills

  11.2 产品化的口径

  1️⃣ Skills 的覆盖面

  • • ❌ 不是覆盖多少页面

  • • ✅ 而是覆盖多少关键 SOP

  2️⃣ Skills 的复用率

  • • 能不能跨部门用？

  • • 能不能被多个工作流复用？

  复用率越高：

  • • 这个 Skill 越像平台能力

  • • 越值得优先做

  3️⃣ Skills 的质量标准

  企业最怕的是同一个流程，十个人写出十个版本

  所以 PM 要定的不是文案风格，而是：

  • • ✅ 可执行的验收口径

  • • ✅ 输入是什么？

  • • ✅ 输出是什么？

  • • ✅ 关键检查点是什么？

  • • ✅ 失败怎么兜底？

  记忆点：

  产品的护城河正在从模型能力
  切换到技能资产密度

  11.3 架构师

  最容易被低估的：

  • • 不是怎么加载文件

  • • 而是四个字：企业治理

  11.4 企业治理三问

  因为技能一旦可插拔，企业就会立刻问你：

  1. 1.谁能装？谁能用？

  2. 2.谁能改？改完怎么审？怎么回滚？

  3. 3.怎么证明它没有带风险？

  尤其是 Skill 里还能跑代码！

  11.5 平台侧要补齐的四类能力

  1️⃣ Skill Registry

  • • 技能目录

  • • 版本

  • • 依赖

  • • 描述

  • • 元数据

  2️⃣ 权限模型

  • • 按团队

  • • 按角色

  • • 按环境分级

  3️⃣ 发布流水线

  • • 评审

  • • 测试

  • • 灰度

  • • 回滚

  4️⃣ 可观测性

  • • 技能触发率

  • • 失败率

  • • 成本

  • • 风险事件

  你把这些补齐，Skills 才是资产
  补不齐，它就只是另一种 Prompt 乱飞

  11.6 开发者

  Skills 的冲击：

  • • 不是又学一个新格式

  • • 而是你工作的重心变了

  以前我们谈 AI 工程：

  • • 要么调模型

  • • 要么堆 Prompt

  现在第三条路放大了：知识工程

  你现在更像在做三类东西：

  1️⃣ 写 skill.md

  它不是说明书，而是：

  • • ✅ 可执行的 SOP

  • • ✅ 步骤

  • • ✅ 边界

  • • ✅ 输入输出

  • • ✅ 检查点

  2️⃣ 写脚本

  把确定性的部分交给 Runtime：

  • • 抽取

  • • 校验

  • • 更新

  • • 格式化

  • • 生成文件

  模型负责决策，脚本负责稳定交付

  3️⃣ 上下文编排

  也就是把：

  • • 该常驻的元数据

  • • 该按需加载的细节

  分层设计

  这直接决定：

  • • 成本

  • • 速度

  • • 以及能不能规模化

  11.7 现实变化

  你会更频繁跟领域专家共创：

  • • 你不是在闭门写代码

  • • 你是在把专家的口头经验

  • • 翻译成可版本化的技能资产

  ---

  十二、被低估但影响最大的部分

  Skills 把开发的门槛往业务侧推了一大步

  12.1 Murag 提到的现象

  会计、法务、招聘这些非技术角色也在写 Skills

  12.2 这意味着什么

  企业知识不再只能靠工程团队慢慢挖
  懂流程的人可以直接把流程沉淀成 Skill

  12.3 工程团队的重要性

  这不是说工程团队不重要，相反：

  • • ✅ 工程团队的价值会上升

  因为一旦业务能写，平台就必须给：

  • • ✅ 模板

  • • ✅ 规范

  • • ✅ 评审机制

  否则你会得到一个更可怕的东西：

  技能库里的野生 SOP

  12.4 正确的组织打法

  共创：

  • •业务专家：提供流程与规则

  • •工程团队：提供结构、工具、评测、治理

  两边合在一起，Skill 才能：

  • • ✅ 既快又稳

  • • ✅ 还可审计

  12.5 Skills 的历史意义

  Skills 很可能是 AI 的 App Store 时刻
  不是因为酷
  而是因为它把供给侧打开了

  ---

  十三、风险与挑战

  13.1 标准化卡在哪？

  Skills 最性感的承诺：

  一次构建，跨平台通用

  但现实更残酷：
  只要格式没统一，技能就会变成新一代 Prompt 方言

  你在 A 平台写的技能包到 B 平台：

  • • ✗ 元数据字段不认

  • • ✗ 触发策略不一样

  • • ✗ 工具权限模型也不兼容

  结果：

  你以为你在沉淀资产
  最后沉淀的是平台锁定

  13.2 工程化的判断标准

  当你准备投入 Skills 体系时，先问两句：

  1. 1.你的 Skill 格式能不能被别人的 Agent 读懂？

  2. 2.你的 Skill 能不能被你的下一代模型继续用？

  如果答案都不确定：

  你要做的不是多写技能
  而是先把 Skill当成产品规格来治理

  • • 字段规范

  • • 目录规范

  • • 版本兼容策略

  这也是为什么 Anthropic 后面把 Agent Skills 推成开放标准：

  • • ✅ 它不是 PR

  • • ✅ 它是为了解决生态不互通这个系统性瓶颈

  13.3 安全怎么做才算企业级？

  Skills 一旦能带脚本：

  • • 它就不只是知识

  • • 它是可执行能力

  这意味着风险从：

  • • ❌ 内容风险

  • • ✅执行风险

  官方安全提醒的核心：

  只从可信来源安装

  这背后对应的是企业级三件套：

  1️⃣ 审核

  Skill 上线前，像代码一样做 Review
  重点看两类东西：

  • • 依赖外部资源

  • • 引用

  2️⃣ 权限

  • • ✗ 不是所有人都能装

  • • ✗ 也不是所有都能跑

  你至少要按环境分级：

  • • 开发环境能跑的

  • • 生产环境不一定能跑

  3️⃣ 审计

  要能回答：

  • • 谁在什么时候

  • • 触发了哪个

  • • 做了什么动作

  没有审计，企业不会让你进核心系统

  别把 Skills 当成内容资产
  它更像一个内部插件系统

  插件系统第一原则永远是：可控

  13.4 Skills 的能力边界

  Skills 很强，但它不是万能钥匙

  边界 1：跨任务迁移

  Skill 本质是流程知识的封装

  • • 流程是很情境化的

  • • 一个财务 Skill，换到另一家公司

  • • • 口径、系统、审批链路都可能全变

  别指望一个能吃遍所有组织

  边界 2：技能选择与误用

  库一旦变大，Agent 选错技能：

  • • 后果比回答错一句话更严重

  • • 因为它会把错误流程执行到底

  边界 3：底座模型推理局限

  Skills 给你的是：

  • • ✅ 指南

  • • ✅ 工具

  但执行链路的：

  • • 规划

  • • 异常

  • • 分支处理

  还是吃模型能力

  模型不够强，Skill 也救不了复杂任务

  13.5 实操建议

  Skill 设计阶段：

  • • ✅ 把适用范围写死

  • • ✅ 把不适用场景写出来

  • • ✅ 用评测任务去压

  不只测能不能做，还要测：

  • • ✅ 会不会误触发

  你要追的不是技能数量
  你要追的是技能的边界清晰度

  ---

  十四、未来生态趋势

  14.1 标准化带来市场化

  Linux 基金会最近刚刚成立 LAIF
  推动 Agent 互操作标准

  这件事的信号非常强：

  大家都意识到继续各造各的闭环生态
  最后一定是重复劳动

  14.2 分发

  一旦标准开始收敛，下一步自然就是分发：

  • • ✅ 技能目录

  • • ✅ 技能市场

  • • ✅ 技能应用商店

  14.3 两类 Skill 分化

  1️⃣ 通用 Skill

  • • 通用报表

  • • 通用文档处理

  2️⃣ 组织私有 Skill

  • • 沉淀企业内部 SOP

  • • 合规规则

  14.4 从业者的机会点

  未来你的竞争力可能不只是：

  • • ❌ 会写 Agent

  而是：

  • • ✅ 你能不能把领域经验做成

  • • •可迁移

    • •可审计

    • •可组合

  的 Skill 包

  这就是新的分发单元

  ---

  十五、总结

  15.1 全篇收束

  未来真正拉开差距的
  不是你有多少 Agent
  而是你把多少组织经验
  沉淀成了可复用、可治理、可分发的 Skills

  15.2 核心洞察

  当模型越来越通用：

  • •知识的组织方式就是新的核心竞争力

  ---

  十六、深入思考

  16.1 为什么这个转变很重要？

  这个范式转换标志着 AI 应用开发从探索阶段进入工程化阶段：

  1. 1.从粗放到精细：不再是一个 Prompt 打天下，而是精细化分工

  2. 2.从个人到组织：从个人 Prompt 工程师到组织级技能资产管理

  3. 3.从玩具到工具：从 Demo 展示到真实业务流程集成

  16.2 对实践的启示

  对企业

  • • ✅停止：为每个业务场景创建新 Agent

  • • ✅开始：沉淀可复用的 Skill Library

  • • ✅建立：Skill 治理体系（权限、审核、审计）

  • • ✅投资：领域专家与工程团队的协作机制

  对开发者

  • • ✅重心转移：从 Prompt Engineering 到 Knowledge Engineering

  • • ✅新技能：学会与领域专家协作，将隐性知识显性化

  • • ✅思维转变：从"我能写多聪明的 Prompt"到"我能设计多可复用的 Skill"

  对产品经理

  • • ✅重新定位：从功能列表规划者到技能资产架构师

  • • ✅关注复用：Skills 的覆盖面和复用率比功能数量更重要

  • • ✅质量标准：建立可执行的验收口径，而不是文案风格

  16.3 批判性思考

  潜在风险

  1. 1.Skill 通胀：可能从 Agent 动物园变成 Skill 动物园

  • •应对：建立 Skill 评审和淘汰机制

• 2.标准化困境：不同平台的 Skill 格式不兼容

• • •应对：关注开放标准（如 Anthropic Agent Skills），避免平台锁定

• 3.质量失控：业务专家写的 Skill 可能质量参差

• • •应对：工程团队必须提供模板、规范和评审机制

  成功关键

  1. 1.治理先行：在大量 Skills 产生前先建立治理体系

  2. 2.渐进式：从高频场景开始，逐步沉淀，而非一次性大爆发

  3. 3.可观测：建立完整的监控和审计体系

  16.4 结论

  Anthropic 的 Cloud Skills 范式不是技术炫技，而是对 AI 落地深层次问题的工程化回应：

  真正的规模化不在于你有多少个 Agent
  而在于你能将多少组织经验转化为可复用、可治理的技能资产

  当模型能力越来越通用，知识的组织方式就是新的核心竞争力。

  ---

  十七、从代码实现角度理解 Skills

  17.1 实际案例：我的 Skill Middleware 实现

  为了更好地理解 Skills 的工程实现，我参考 LangChain 的官方文档，实现了一个渐进式披露中间件（Progressive Disclosure Middleware）。

  参考文档：

  • • LangChain: Build a SQL assistant with on-demand skills

  我的实现：
  src/agents/middleware/skillMiddleware.js

  17.2 核心原理：三层渐进式披露

  第一层：系统提示（轻量级元数据）

  在 Agent 启动时，只向系统提示注入技能的名称和简短描述：

  // 构建技能描述列表（用于系统提示） const skillsPrompt = skills .map((skill) => `- **${skill.name}**: ${skill.description}`) .join('\n'); // 追加到系统提示 const skillsAddendum = `\n\n## Available Skills\n\n${skillsPrompt}\n\n` + `Use the load_* tools when you need detailed information ` + `about handling a specific type of request.`; const newSystemPrompt = request.systemPrompt + skillsAddendum;

  结果：Agent 知道有哪些技能可用，但不知道具体实现细节。

  第二层：工具调用（按需加载）

  为每个技能创建一个独立的加载工具：

  // 为每个技能创建加载工具 const loadSkillTools = skills.map((skill) => { return createLoadSkillTool({ skillName: skill.name }); });

  当 Agent 识别到需要某个技能时，会主动调用对应的load_skill_*工具。

  第三层：文件系统读取（完整内容）

  工具被调用时，从文件系统读取完整的技能内容：

  // createLoadSkillTool 会读取对应的 skill.md 文件 // 例如：src/agents/skills/mermaid/skill.md // 这才是包含完整流程、示例、注意事项的地方

  17.3 核心代码解析

  17.3.1 Middleware 结构

  return { name: 'skillMiddleware', tools: loadSkillTools, // 🔑 注册工具，让 Agent 可以调用 wrapModelCall: async (request, handler) => { // 🔑 拦截模型调用，修改系统提示 const newSystemPrompt = request.systemPrompt + skillsAddendum; return handler({ ...request, systemPrompt: newSystemPrompt, }); }, };

  关键点：

  1. 1.tools：注册的工具有会被 Agent 自动发现并调用

  2. 2.wrapModelCall：拦截每次模型调用，动态修改系统提示

  17.3.2 自动扫描机制

  export async function createAutoSkillMiddleware(options = {}) { const { skillNames } = options; let skills = await listAllSkills(); // 🔑 自动扫描目录 // 支持过滤：只加载指定的技能 if (skillNames && skillNames.length > 0) { const nameSet = new Set(skillNames); skills = skills.filter((skill) => nameSet.has(skill.name)); } return createSkillMiddleware({ skills, useFileSystem: true, // 🔑 使用文件系统模式 }); }

  优势：

  • • ✅ 添加新技能不需要修改代码

  • • ✅ 可以按需加载部分技能（降低启动成本）

  • • ✅ 技能内容独立维护（支持 Git 版本管理）

  17.4 实际工作流程示例

  场景：用户要求"生成一个 Mermaid 流程图"

  Step 1: Agent 启动

  系统提示被自动追加：

  ## Available Skills - **mermaid**: Mermaid 图表生成技能 - **drawio**: Draw.io 图表编辑技能 - **sql-assistant**: SQL 查询辅助技能 Use the load_* tools when you need detailed information about handling a specific type of request.

  Step 2: Agent 推理

  Agent 分析用户需求，判断需要 Mermaid 技能

  Step 3: 工具调用

  Agent: 调用 load_skill_mermaid 工具

  Step 4: 读取完整内容

  Tool: 从 src/agents/skills/mermaid/skill.md 读取内容 返回：完整的 Mermaid 语法指南、示例、注意事项

  Step 5: Agent 执行

  Agent 基于加载的技能内容，生成正确的 Mermaid 图表代码

  17.5 设计亮点

  1. 双模式支持

  if (useFileSystem) { // 文件系统模式：适合生产环境，内容可独立维护 return createLoadSkillTool({ skillName: skill.name }); } else { // 内存模式：适合小型技能，快速原型 return tool(async () => { return `Loaded skill: ${skill.name}\n\n${skill.content}`; }, {...}); }

  2. 灵活的过滤机制

  // 方式1：加载所有可用技能 const middleware = await createAutoSkillMiddleware(); // 方式2：只加载指定的多个技能（数组） const middleware = await createAutoSkillMiddleware({ skillNames: ['env-issue-resolver', 'mermaid', 'drawio-diagrams-enhanced'], }); // 方式3：只加载单个技能 const middleware = await createAutoSkillMiddleware({ skillNames: ['sql-assistant'], });

  关键特性：

  • •skillNames是一个数组：可以同时加载多个技能

  • •按需组合：根据场景灵活选择需要的技能组合

  • •减少开销：只加载当前场景需要的技能，降低系统提示消耗

  应用场景：

  • •团队隔离：不同团队只加载自己的技能（如运维团队只加载env-issue-resolver）

  • •功能精简：简化版 Agent 只加载核心技能（如只加载mermaid图表能力）

  • •性能优化：降低 Token 消耗，加快响应速度

  • •A/B 测试：对比不同技能组合的效果

  3. 可观测性

  console.log(`[SkillMiddleware] Loading ${skills.length} specified skills:`, skills.map((s) => s.name).join(', '));

  便于调试和监控技能加载状态。

  17.6 与理论概念的对应关系

  理论概念	代码实现
  元数据	skills.map(s => - ${s.name}: ${s.description} )`
  渐进式披露	先注入描述，再通过工具加载完整内容
  可组合性	每个 Skill 独立，可以同时加载多个
  可执行性	Skill 中包含可执行的脚本和示例
  文件系统结构	src/agents/skills/{skillName}/skill.md
  版本管理	Skill 文件可以直接用 Git 管理

  17.7 实践建议

  1. 技能目录结构

  src/agents/skills/ ├── mermaid/ │ ├── skill.md # 技能说明（必选） │ ├── examples.mmd # 示例文件 │ └── schema.json # 配置文件 ├── drawio/ │ ├── skill.md │ └── templates/ └── sql-assistant/ ├── skill.md └── schemas/

  2. skill.md 模板

  # {技能名称} ## 概述 {1-2 句话描述技能功能} ## 使用场景 {何时使用这个技能} ## 步骤 1. {步骤 1} 2. {步骤 2} 3. {步骤 3} ## 输入格式 {期望的输入格式} ## 输出格式 {输出的格式规范} ## 注意事项 > [!warning] > {重要提醒} ## 示例 {具体的使用示例}

  3. 性能优化

  • • 小型技能（<1K tokens）：直接加载到系统提示

  • • 中型技能（1-10K tokens）：按需加载

  • • 大型技能（>10K tokens）：分块加载 + 搜索

  17.8 总结

  从代码实现角度看，Skills 本质上是一种上下文管理策略：

  1. 1.不一次性加载所有知识→ 避免 Context Overflow

  2. 2.分层披露→ 元数据 → 工具调用 → 完整内容

  3. 3.按需加载→ 只加载当前任务需要的技能

  4. 4.独立维护→ 每个技能是一个独立的文件/目录