专注AIGC领域的专业社区，关注微软&OpenAI、百度文心一言、讯飞星火等大语言模型（LLM）的发展和应用落地，聚焦LLM的市场研究和AIGC开发者生态，欢迎关注！
AI Agent 能执行指令，但能不能自己编写指令？
Google Developers Blog 发表了一篇面向开发者的深度指南，介绍了 Agent Development Kit（ADK）中的 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 大约是1000（L1）加上2000（2项L2），总计约3000个，相比传统方式的10000个节省了70%。
ADK 通过 SkillToolset 类来实现这套机制。开发者把 Skill 列表传给 SkillToolset，它会自动生成三个工具：list_skills（对应 L1，在每次对话中自动注入）、load_skill（对应 L2，按需调用）和 load_skill_resource（对应 L3，按需调用）。
Agent 在运行过程中自主决定何时调用哪个工具，开发者不需要手动编写 if-else 逻辑来编排加载流程。Agent 本身就是决策者。
围绕这套渐进式披露架构，Google 的指南介绍了四种 Skill 构建模式，复杂度依次递增。前三种处理已经存在的 Skill，第四种让 Agent 自己生成新 Skill。
最简单的模式是内联 Skill（Inline Skill），Google 把它比作便利贴，小而直接。
开发者直接在 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.md（L3）提供每个步骤所需的详细领域知识。
Agent 在执行过程中根据指令需要，通过 load_skill_resource 工具加载参考文件。
文件型 Skill 的关键优势在于可复用性和可维护性。
Skill 目录是独立于 Agent 代码存在的，修改 Skill 只需要编辑 SKILL.md 文件，不需要改代码重新部署。
任何遵循 agentskills.io 规范的 Agent 都可以加载同一个目录。也就是说你为一个项目写的博客写作 Skill ，可以直接搬到另一个内容管理项目中复用，不需要额外适配。
团队协作时，不同成员可以各自维护不同 Skill 的目录，互不干扰。 Skill 目录还可以纳入 Git 版本管理，追踪每次修改的历史。
外部导入 Skill（External 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 以及为什么。
当用户提出一个已知的需求（比如审查博客的 SEO），Agent 会调用 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/
热门跟贴