省 90% token！谷歌重磅指南教你用Skill构建ADK智能体

AI Agent 能执行指令但能不能自己编写指令Google Developers Blog 发表了一篇面向开发者的深度指南介绍了 Agent Development KitADK中的 SkillToolset 能力。核心亮点在于渐进式披露Progressive Disclosure架构让 AI Agent 按需加载领域专业知识最多可将基础上下文消耗降低90%。通过一种被称为 Skill 工厂Skill Factory的设计模式Agent 甚至可以在运行时动态生成全新的 Skill 定义实现自我扩展。AI Agent 的知识膨胀难题做 AI Agent 开发的人大多遇到过同一个问题。刚开始做 demo系统提示词System Prompt里写几条规则就够了。Agent 能帮忙查个天气、做个翻译、写段文案表现得像模像样。但随着要接入的业务场景越来越多提示词就开始不受控制地膨胀。SEO 规则、代码审查规范、API 接口文档、合规审计流程、数据处理规范所有这些领域的知识被一股脑地塞进一个巨大的指令字符串里。问题的严重程度可能超出很多开发者的预期。假设一个 Agent 有10项能力每项能力的完整指令大约需要1000个 token把它们全部拼进系统提示词每次调用 LLM 就要消耗大约10000个 token 的基础上下文。实际上用户可能只是想让它帮忙写一段营销文案跟其中8项能力完全无关。这10000个 token 中有大约8000个是白白浪费的。当 Agent 的能力扩展到20项甚至更多浪费的比例更加惊人。token 浪费意味着成本增加。计费方式按输入和输出的 token 数量收费每次调用都在为用户根本用不到的知识买单。对于高频使用的生产环境 Agent这笔开销累积下来相当可观。更深层的问题在于响应质量。上下文窗口是有限的资源塞进太多无关信息会稀释模型对关键指令的关注度好比在嘈杂的会议室里找人说话背景噪音越大沟通效率越低。当 Agent 需要在多个能力维度之间切换时过长的系统提示词会降低它对当前任务相关指令的执行精度。这个问题在能力维度超过10个之后尤为明显开发者被迫在功能丰富度和响应准确性之间做艰难取舍。Google 在 ADK 中给出的解决方案是渐进式披露Progressive Disclosure。Agent Skills 规范把知识加载拆分成三个层级只在需要的时候才加载需要的知识像查字典一样按需翻阅而不是把整本百科全书一次性全部翻开。渐进式披露三层知识加载渐进式披露的核心思想是把 Skill 知识分成三个递进的层级每一层只在被需要时才被激活。该设计借鉴了软件工程中延迟加载Lazy Loading的理念把上下文消耗从一次性全量加载变成按需逐步深入。L1 元数据层每个 Skill 大约消耗100个 token。这层只包含 Skill 的名称和描述没有任何具体的执行指令。Agent 启动时会加载所有 Skill 的 L1 元数据相当于拿到一份餐厅菜单。菜单上只列出菜名和简短介绍Agent 浏览这份菜单来判断当前用户需求跟哪些 Skill 相关然后决定是否要点某道菜加载更详细的指令。L2 指令层每个 Skill 通常不超过5000个 token。这是 Skill 的完整指令体详细描述了执行某项任务所需遵循的每一个步骤。只有当 Agent 通过 L1 判断某个 Skill 确实跟当前任务相关时才会通过 API 调用显式加载该 Skill 的 L2 内容。就像客人看完菜单点了菜后厨才开始准备具体的菜品。L3 资源层完全按需加载。这是外部参考文件比如写作风格指南、API 接口规范文档、代码模板等。 Skill 的 L2 指令中会引用这些资源Agent 在执行过程中根据指令的具体需要才去加载对应的参考文件。好比厨师在烹调过程中发现需要查阅某个配方细节才翻开对应的参考书页。用一个具体数字说明效果。一个拥有10项 Skill 的 Agent采用传统方式每次调用消耗约10000个 token 的基础上下文。采用渐进式披露后L1 元数据总共只有约1000个 token基础上下文消耗直接降低了约90%。只有当 Agent 真正需要某项具体 Skill 时才会额外加载对应的 L2 和 L3 内容。一个只触发了2项 Skill 的任务实际消耗的 token 大约是1000L1加上20002项L2总计约3000个相比传统方式的10000个节省了70%。ADK 通过 SkillToolset 类来实现这套机制。开发者把 Skill 列表传给 SkillToolset它会自动生成三个工具list_skills对应 L1在每次对话中自动注入、load_skill对应 L2按需调用和 load_skill_resource对应 L3按需调用。Agent 在运行过程中自主决定何时调用哪个工具开发者不需要手动编写 if-else 逻辑来编排加载流程。Agent 本身就是决策者。四种 Skill 构建模式围绕这套渐进式披露架构Google 的指南介绍了四种 Skill 构建模式复杂度依次递增。前三种处理已经存在的 Skill第四种让 Agent 自己生成新 Skill。最简单的模式是内联 SkillInline SkillGoogle 把它比作便利贴小而直接。开发者直接在 Agent 代码中定义一个 Python 对象包含名称、描述和指令三个字段全部用代码字符串写死。该方式适合小型、稳定、很少变动的规则集比如检查清单类任务。一个典型的例子是 SEO 检查 Skill 。开发者定义一个名为 seo-checklist 的 Skill 描述写成博客文章 SEO 优化检查清单涵盖标题标签、元描述、标题结构和可读性。这段描述会被 Agent 在每次调用时看到用于判断是否需要激活这个 Skill 。指令部分列出5个具体的检查项标题控制在50到60个字符之间且主关键词靠前元描述控制在150到160个字符且包含行动号召H2/H3 层级结构合理且2到3个标题包含关键词第一段在前100个词中出现主关键词图片需要包含关键词的 alt 文本并经过压缩处理。指令末尾要求 Agent 对照每个检查项审查内容并给出改进建议。在这个定义中frontmatter 字段自动成为 L1 元数据LLM 在每次调用时都能看到这段简短描述。instructions 字段成为 L2 内容只有当 Agent 判断用户请求跟 SEO 优化相关时才会触发加载。用户问帮我的博客做 SEO 优化审查Agent 浏览 L1 菜单后识别出 seo-checklist 相关加载完整指令逐条对照检查内容并给出改进建议。内联 Skill 的优点是简单直接零配置适合快速原型开发。几行代码就能给 Agent 加一项新能力。它的局限也很明显如果 Skill 需要引用外部文档比如一份完整的写作风格指南或者 API 接口规范纯靠代码中的字符串就很难承载这些内容。而且内联 Skill 跟代码耦合在一起修改 Skill 需要改代码重新部署。当 Skill 复杂度上升或者需要在多个 Agent 之间复用时就需要升级到文件型 Skill 。文件型 Skill File-based Skill把 Skill 从代码中剥离出来放到独立的目录结构中。Google 把该模式比作参考活页夹按主题分门别类地存放专业知识。每个 Skill 拥有自己的文件夹包含一个 SKILL.md 文件作为指令入口以及可选的子目录存放参考资料、素材和脚本。该目录结构本身就是 Skill 的完整载体可以独立于代码进行版本管理、编辑和分发。一个典型的文件型 Skill 目录结构如下SKILL.md 文件以 YAML frontmatter 开头包含 Skill 名称和描述后面跟 Markdown 格式的指令正文。该设计把知识拆分到两个层级SKILL.md 中的指令L2告诉 Agent 应该遵循哪些步骤references/style-guide.mdL3提供每个步骤所需的详细领域知识。Agent 在执行过程中根据指令需要通过 load_skill_resource 工具加载参考文件。文件型 Skill 的关键优势在于可复用性和可维护性。Skill 目录是独立于 Agent 代码存在的修改 Skill 只需要编辑 SKILL.md 文件不需要改代码重新部署。任何遵循 agentskills.io 规范的 Agent 都可以加载同一个目录。也就是说你为一个项目写的博客写作 Skill 可以直接搬到另一个内容管理项目中复用不需要额外适配。团队协作时不同成员可以各自维护不同 Skill 的目录互不干扰。 Skill 目录还可以纳入 Git 版本管理追踪每次修改的历史。外部导入 SkillExternal Skill的代码实现和文件型 Skill 完全一样唯一区别在于 Skill 目录的来源。文件型 Skill 是开发者自己从零编写的外部导入 Skill 是从社区仓库中找到并下载的现成 Skill 。这就像你需要一本参考书既可以自己手写一本也可以直接去图书馆借一本别人已经写好的。比如开发者可以从 awesome-claude-skills 这样的社区 Skill 仓库中下载一个名为 content-research-writer 的 Skill 目录然后用和文件型 Skill 完全相同的 load_skill_from_dir 方法加载。代码层面的 API 调用没有任何变化因为 agentskills.io 规范定义了一套通用的目录格式加载器不关心 SKILL.md 是你自己写的还是从网上下载的。Google 自身也发布了一些官方 ADK 开发 Skill 采用同样的格式开发者可以通过 npx skills add google/adk-docs -y -g 命令一行安装。目前已经有40多个产品支持 agentskills.io 规范包括 Gemini CLI、Claude Code、Cursor 等。一份 Skill 定义可以在不同厂商的 Agent 平台之间通用降低了开发者的迁移成本。外部导入 Skill 解决了 Skill 共享和复用的问题。但不管 Skill 是自研的还是社区提供的它都是预先存在的。如果 Agent 遇到一个全新场景没有现成 Skill 可用怎么办第四种模式是整篇文章最有趣的部分被称为 Skill 工厂Skill Factory或者元 Skill Meta Skill。元 Skill 是一种特殊的 Skill 它的用途不是执行某项具体任务它专门用来生成新的 SKILL.md 文件。配备元 Skill 的 Agent 变成了自我扩展的系统它可以在运行时编写新的 Skill 定义并立即使用整个过程不需要人工干预。元 Skill 的内部实现并不神秘。本质上它也是一个内联 Skill 只是用途从执行具体任务变成了编写 Skill 定义文件。它的指令部分详细告诉 Agent 如何编写符合规范的 SKILL.md 文件包括命名规则必须使用短横线命名最长64个字符、描述要求不超过1024个字符、指令编写原则清晰的步骤化表述和结构规范SKILL.md 控制在500行以内详细内容放到 references 子目录中。实现元 Skill 的关键在于它的 resources 字段。这个字段内嵌了两份 L3 参考文档一份是 agentskills.io 完整规范skill-spec.md另一份是一个可运行的代码审查 Skill 示例example-skill.md。当 Agent 被要求创建新 Skill 时它会通过 load_skill_resource 工具读取这两份参考文档理解规范的格式要求和最佳实践然后根据用户的具体需求生成一份符合规范的 SKILL.md。整个过程就像一个程序员在写新代码之前先翻阅编程规范文档和示例代码一样自然。来看一个实际运作的完整流程。用户对 Agent 说我需要一个新 Skill 用来审查 Python 代码中的安全漏洞。Agent 收到这个请求后首先调用 list_skills 浏览已有的 Skill 列表发现没有匹配的安全审查 Skill 。它随即激活 skill-creator 元 Skill 调用 load_skill_resource 读取 agentskills.io 规范了解 SKILL.md 的格式要求和命名规则再读取 example-skill.md 学习一份成熟 Skill 的结构和写法。有了这些参考资料Agent 开始根据用户需求生成 Skill 定义。生成的 Skill 包含合规的短横线命名kebab-case、结构化指令涵盖输入验证、认证机制、密码学安全等方面的检查流程、以及基于严重程度的报告格式。整个过程完全自动化用户不需要了解 agentskills.io 规范的任何细节。生成的 Skill 遵循同样的 agentskills.io 规范所以它不仅能在 ADK 中使用在 Gemini CLI、Claude Code、Cursor 等任何兼容平台上都能直接加载。开发者可以把生成的 SKILL.md 保存到本地目录下次会话直接用 load_skill_from_dir 加载。Google 也给出了一个务实提醒自动生成的 Skill 建议保留人工审核环节。元 Skill 的输出直接决定了 Agent 的行为方式和能力边界生成的 SKILL.md 应该像代码审查一样认真过一遍再部署上线。审查重点包括指令是否准确覆盖了需求范围、是否存在遗漏或冗余的步骤、引用的外部资源是否可访问且内容正确。Google 建议使用 ADK 内置的评估Evaluation功能来测试 Skill 的有效性确保它按预期工作不会在特定场景下产生错误输出。把四种模式组装在一起理解了四种模式之后组装成完整的 Agent 其实只需要几行代码。开发者创建一个 SkillToolset 实例把所有 Skill 按顺序放进去内联的 SEO Skill、文件型的博客写作 Skill、外部导入的内容研究 Skill以及 Skill 工厂元 Skill。然后把这个 SkillToolset 作为工具列表传入 Agent 的构造函数中。Agent 的模型可以使用 Gemini 2.5 Flash 等大语言模型SkillToolset 会自动注册三个工具函数供 Agent 调用。Agent 的系统指令非常简洁只需要告诉它你是一个博客写作助手拥有专业 Skill 加载相关 Skill 获取详细指令用 load_skill_resource 访问参考资料遵循每个 Skill 的步骤指令并始终解释正在使用哪个 Skill 以及为什么。当用户提出一个已知的需求比如审查博客的 SEOAgent 会调用 list_skills 浏览 L1 菜单识别出 seo-checklist Skill 相关调用 load_skill 加载 L2 指令然后逐条执行检查。当用户提出一个全新的需求比如创建一个技术博客引言写作 Skill Agent 会激活 skill-creator 元 Skill 读取规范文档生成新的 SKILL.md保存后即可在后续会话中复用。该架构有几个值得注意的设计原则。Skill 的描述字段description是 Agent 决策的核心依据。好的描述应该精准地告诉 Agent 什么时候应该激活这个 Skill 比如SEO 优化检查清单用于博客文章涵盖标题标签、元描述、标题结构和可读性而模糊的描述如一个有用的 Skill 对 Agent 的判断没有任何帮助。在 Skill 的选择上Google 建议从内联模式开始只有当 Skill 需要引用外部文档或跨 Agent 复用时才升级到文件型。过早优化是常见陷阱如果一个 Skill 的指令不超过10行直接内联写就好。对于生成的 Skill 应该像管理代码依赖一样认真对待上线前必须审核和测试。ADK 的 Skill 系统建立在 agentskills.io 这个开放标准之上这是整个技术体系能够跨平台运转的基石。这个标准最初由 Anthropic 提出作为开放规范发布已被越来越多的 Agent 产品所采纳。目前 Google 的 ADK 已支持 Python 和 Go 语言Java 版本也在2026年3月底发布了1.0正式版。Python 社区还出现了 adk-skills-agent 这样的第三方库发布在 PyPI 上专门用来把 Agent Skills 格式的 Skill 集成到 Google ADK Agent 中。开发者可以通过克隆 GitHub 仓库快速运行所有四种 Skill 模式的示例代码也可以通过 Google Cloud Skills 平台上的学习路径来系统掌握完整的 ADK 开发流程。AI Agent 的能力边界正在从被动执行人类编写的指令拓展到主动为自己编写新指令。渐进式披露架构解决了知识膨胀的效率问题让 Agent 既能拥有丰富的能力储备又不会因为上下文过载而影响响应质量。Skill 工厂模式打开了自我扩展的可能性Agent 遇到未知场景时不再只能报错说做不到它可以现场编写一份新 Skill 来补齐能力缺口。参考资料https://developers.googleblog.com/developers-guide-to-building-adk-agents-with-skills/