TECH NOTE
2386 字 12 分钟 系列 6 / 2206 Skills 技能:一个 Agent + 一柜子按需翻的说明书
ON THIS PAGE / 目录12 节
一句话讲透:不拆 Agent,改拆知识。把”专业提示词 + 领域知识”打包成一个个”技能”,Agent 平时只知道技能目录(有哪几本手册),真需要时才用
load_skill把它翻出来读——这就是渐进式披露(progressive disclosure),省的是上下文窗口。
它到底是什么
原文定义:
在 skills 架构里,专门能力被打包成可调用的”技能”,用来增强 Agent 的行为。技能主要是提示词驱动的专长,Agent 可以按需调用它们。
📎 想要内置实现:Deep Agents 自带 skills 支持,见 Deep Agents / Skills。
💡 提示(原文):这个模式在概念上和 Agent Skills、以及 Jeremy Howard 提出的 llms.txt 完全一致——都是”用工具调用实现文档的渐进式披露”。区别在于:skills 模式把这套做法用在专业提示词与领域知识上,而不只是文档页。
想要现成的、能提升 Agent 在 LangChain 生态任务上表现的技能,可以看 LangChain Skills 仓库。
graph LR A[用户] --> B[Agent] B --> C[技能 A] B --> D[技能 B] B --> E[技能 C] B --> A这张图在说什么:① 只有一个 Agent(跟 04 Subagents 的”多个人”完全不同);② Agent 身边挂着一排技能,用到哪个才去读哪个;③ 回答直接由这个 Agent 给用户(B --> A 这条回边),没有”主管转述”这一层。
五个关键特征
| 特征 | 原文 | 说人话 |
|---|---|---|
| 提示词驱动的专长 | Prompt-driven specialization:技能主要由专门的提示词定义 | 技能本质是”一段很懂行的提示词”,不一定有代码 |
| 渐进式披露 | Progressive disclosure:技能按上下文或用户需要才变得可用 | 不用就不加载,省 token |
| 团队分布式 | Team distribution:不同团队可独立开发和维护技能 | 一个技能一个文件/目录,天然适合分包 |
| 轻量组合 | Lightweight composition:技能比完整的子智能体简单 | 不用建 Agent、不用管状态,写个提示词就能加能力 |
| 引用感知 | Reference awareness:技能可以引用脚本、模板、其它资源 | 手册里能写”需要时去读 references/xxx.md、跑 scripts/yyy.py” |
🧭 补充解读(非原文):技能 ≠ 工具。工具是”能执行的动作”(查订单、发邮件),技能是”该怎么干这件事的知识”(业务规则、表结构、话术、SOP)。技能往往告诉 Agent 什么时候该用哪个工具、怎么写参数。
什么时候用它
原文给的三条:
- 你想要一个 Agent 拥有很多可能的专长;
- 你不需要在技能之间强制约束(技能之间是并列的,不分先后);
- 不同团队需要独立开发各自的能力。
原文点的三个典型场景:
| 场景 | 技能是什么 |
|---|---|
| 编码助手 | 不同语言、不同任务(写测试、重构、review)的技能 |
| 知识库 | 不同领域(产品、法务、财务)的技能 |
| 创作助手 | 不同体裁/格式(小红书文案、周报、邮件)的技能 |
⚠️ 反向判据:如果你需要技能之间有顺序约束(“必须先做 A 才能做 B”),那应该用
05Handoffs;如果每个领域大到需要独立上下文和独立工具,那应该用04Subagents。
最小可用实现:一个 load_skill 工具
from langchain.tools import toolfrom langchain.agents import create_agent
@tooldef load_skill(skill_name: str) -> str: """Load a specialized skill prompt.
Available skills: - write_sql: SQL query writing expert - review_legal_doc: Legal document reviewer
Returns the skill's prompt and context. """ # 从文件/数据库里把技能内容读出来 ...
agent = create_agent( model="gpt-5.5", tools=[load_skill], system_prompt=( "You are a helpful assistant. " "You have access to two skills: " "write_sql and review_legal_doc. " "Use load_skill to access them." ),)这段代码在说什么:① 全部实现就一个工具 load_skill;② 系统提示里只放”技能目录”(有哪两个技能、各自干什么)——这就是全部的常驻成本;③ 技能正文(可能几千 token)躺在文件或数据库里,只有真被调用时才进上下文;④ 工具的 docstring 里必须写清可用技能清单,否则模型不知道该请求哪个。
跟 Subagents 比,差在哪
| 维度 | Skills(本篇) | Subagents(04) |
|---|---|---|
| 有几个 Agent | 1 个 | 1 个主管 + N 个子智能体 |
| 上下文隔离 | 没有,技能加载后就在主上下文里 | 强隔离,子智能体各跑各的窗口 |
| 谁能跟用户对话 | 这个唯一的 Agent | 只有主管 |
| 要写多少代码 | 一个 load_skill 工具 | 每个子智能体一个 create_agent + 一个 @tool |
| token 账单形状 | 加载后每轮都要重读(03 里的 15K) | 每次调用独立、总量更省 |
| 适合 | 知识多但流程简单 | 领域多、工具多、要隔离 |
用 token 账看”渐进式披露”到底省了什么
方案 A:全部塞进系统提示(图省事) 第 1 轮: 系统提示 200 + 技能A 2000 + 技能B 2000 + 技能C 2000 = 6200 token 第 2 轮: 再读一遍 6200 token ← 每轮都在为"用不到的知识"付钱
方案 B:渐进式披露(Skills 模式) 第 1 轮: 系统提示 200 + 技能目录 100 = 300 token ──▶ 模型决定加载"技能A" 第 2 轮: + 技能A 正文 2000 = 2300 token ──▶ 模型据手册干活 技能B、技能C: 0 token ← 省的就是这部分🧭 补充解读(非原文):注意这套账的代价:① 加载技能多花一次模型调用(模型得先决定加载什么);② 加载过的技能会留在上下文里,后面每一轮都要重读(
03篇多领域场景里 Skills 的 15K token 就是这么来的);③ 模型可能加载错技能或忘记加载——所以技能目录的描述质量决定了这个模式成败。
📎 官方实战教程:Build a SQL assistant with on-demand skills(本笔记的精讲版见
11)
三种进阶玩法(原文「Extending the pattern」)
写自定义实现时,可以从三个方向扩展基础技能模式:
1. 动态注册工具(Dynamic tool registration)
把渐进式披露和状态管理结合:技能加载时顺便注册新工具。
原文的例子:加载一个 database_admin 技能,既注入专门上下文,又注册数据库相关工具(backup、restore、migrate)。机制和其它多 Agent 模式一样——工具改状态,从而动态改变 Agent 的能力。
🧭 补充解读(非原文):这条最实用的场景是权限收敛——平时 Agent 手里只有少数安全工具,加载”管理员技能”后才挂上危险工具。危险能力不是常驻的,而是被”技能加载”这个动作显式解锁的。
2. 层级技能(Hierarchical skills)
技能可以定义其它技能,形成树状结构,产生嵌套专长。
原文的例子:加载 data_science 技能后,可以让 pandas_expert、visualization、statistical_analysis 这些子技能变得可用;每个子技能又能被独立按需加载。这种层级做法把庞大的知识库组织成逻辑分组,可以按需发现、按需加载。
🧭 补充解读(非原文):层级技能本质上就是知识库的目录结构——先加载”章”,再按需加载”节”。它解决的是”技能太多、目录本身就很长”的问题。
3. 引用感知(Reference awareness)
原文说得很精炼:每个技能虽然只有一段提示词,但这段提示词可以引用其它资源的位置,并说明什么时候该去用它们。当这些资源变得相关时,Agent 会知道”这些文件存在”,并按需把它们读进内存来完成任务。这同样遵循渐进式披露,限制上下文窗口里的信息量。
🧭 补充解读(非原文,结合 Deep Agents 的实现):这就是”技能 = 一个目录 + 一份
SKILL.md+ 若干参考文件/脚本”的由来。SKILL.md里写”遇到复杂查询时读references/query-cookbook.md、需要批量导入时跑scripts/import.py”——手册里夹着书签,Agent 自己决定什么时候翻到那一页。
小结
- 一句话:Skills = 单 Agent + 一个
load_skill工具 + 一堆躺在外部、按需加载的提示词/知识。 - 五个特征:提示词驱动、渐进式披露、团队分布式、轻量组合、引用感知。
- 核心收益:常驻上下文里只放”技能目录”,正文按需付费;加能力不用加 Agent。
- 核心代价:加载多一次调用;加载后每轮重复读;可能加载错——技能描述就是你的”检索质量”。
- 三种进阶:动态注册工具(技能解锁工具/权限)、层级技能(技能树)、引用感知(手册里带书签,二级资源再按需读)。
- 和 Subagents 的关键区别:Skills 不隔离上下文,它省的是”没用到就别读”;Subagents 隔离上下文,它省的是”总量别累积”。
一句话选型
- 选它:一个 Agent 要覆盖很多并列专长(多语言、多领域、多文体);不想为每个领域建 Agent;团队要各自贡献能力。
- 别选它:技能之间有强制顺序(用
05Handoffs);每个领域上下文极大或工具极多、需要隔离(用04Subagents);需要先分诊再并行(用07Router)。
上一篇:05 Handoffs 交接 | 下一篇:07 Router 路由 | 实战:11 用 Skills 搭 SQL 助手