本文不是 Google ADK 功能转述。它是一篇 WeHub founder note：我关心的是，Google 把 Agent Skill 放进 ADK 之后，Agent 系统构建的重心会怎样从 prompt / tool 进入 capability architecture。
核心判断：Agent 构建正在从 prompt engineering 走向 capability engineering。
我为什么觉得这件事值得写#
我看到 Google ADK 的 Skills / SkillToolset 后，第一反应不是“Google 又出了一个 Agent 功能”。
我的反应更直接：这件事说明 Agent 构建开始进入一个更稳的阶段了。
过去一年，很多 Agent 系统都在堆三件东西：更长的 system prompt，更多 tools，更复杂的 routing。它们当然有用。但真正做过系统的人会知道，Agent 最脆弱的地方通常不是“没有工具”，而是：
它不知道什么时候该用什么能力，也不知道怎样才算把这件事做对。
Tool calling 解决的是“能不能调用”。Skill 解决的是“会不会正确地做”。
这个区别很小，但一旦想明白，Agent runtime 的竞争就会变味。它不再只是模型、上下文窗口、tool schema 的竞争，而是 capability architecture 的竞争。
Google ADK 这次真正有意思的地方#
Google ADK 官方文档现在有了 Skills 入口。文档里的定义很清楚：一个 agent Skill 是一个自包含的功能单元，封装完成某类任务所需的 instructions、resources 和 tools。ADK 通过 SkillToolset 把一个或多个 skills 暴露给 agent；skill 可以在代码里定义，也可以从文件系统加载。
文档也明确标注 Skills 还是 experimental。所以我不把它当成“已经成熟的行业标准”。我更在意的是方向：Google 正在把 Agent 能力封装这件事放进 runtime 的正式语汇里。
更关键的是，它不是一次性把所有内容塞进主 prompt。
ADK 文档把 skill 拆成三层：
L1 Metadata 用于发现：名字、描述、触发条件
L2 Instructions 用于执行：SKILL.md 正文里的操作原则
L3 Resources 用于补充：references / assets / scripts 等资源这就是 progressive disclosure。平时只暴露少量 metadata；需要时再加载 instruction；还不够，再加载 references、assets 或 scripts。
这件事重要在哪里？
因为 Agent 的上下文窗口不是垃圾场。不能把所有流程、偏好、教程、API 文档、checklist、历史经验都塞进一个无限膨胀的 system prompt。那样不是增强智能，而是在制造噪音。
Skill 的意义，是给 Agent 一个可发现、可加载、可维护的能力组织单位。
Tool 不是 Skill#
我觉得这篇文章最应该讲清楚的是这句话：Tool 不是 Skill。
Tool 是一个动作接口。比如：
search_web(query)
read_file(path)
send_message(target, message)
run_sql(query)
call_github_api(endpoint)这些工具告诉 Agent “你能做什么”。
但 skill 说的是另一件事：
什么时候应该用这个工具？
调用前要检查什么？
失败时如何 fallback？
输出应该满足什么标准？
哪些信息不能泄漏？
做完以后如何验证？
这件事如果重复发生，应该沉淀成什么资产？所以 skill 不是 prompt snippet。skill 更像一个小型操作规程，也像组织能力的肌肉记忆。
比如“发邮件”这个 tool 很简单。但“代表团队发一封对外商务邮件”的 skill 会复杂很多：语气、身份、收件人确认、附件检查、敏感信息边界、发送前确认、发送后归档，都必须写进去。
再比如“跑测试”是 tool 级动作；“在一个陌生代码仓库里安全修改并提交 PR”是 skill。后者包含分支策略、测试顺序、review checklist、CI 判断、失败回滚和最终汇报。
Agent 做不好复杂任务，很多时候不是模型不够聪明，而是它没有这层 procedural memory。
五种 Skill 设计模式#
围绕 ADK 的实践文章把 SKILL.md 的写法整理成五类模式，我觉得很有启发：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline。
我不把它们当成“官方唯一分类”。但它们确实抓住了 Agent skill 的几个常见形态。
1. Tool Wrapper：把工具背后的正确用法封起来#
最简单的 skill，是把某个工具、库或内部系统的最佳实践包住。
重点不是告诉 Agent “有 FastAPI 这个库”，而是告诉它：这个团队怎样写 FastAPI，目录结构怎么放，错误处理怎么做，哪些反模式不要用，怎样验证。
这类 skill 对 WeHub 很重要。因为我们会接入越来越多外部工具：Codex、Claude Code、GitHub、Discord、飞书、Tailscale、静态站部署、MCP、浏览器自动化。每个工具都有坑。坑不能每次重新踩。
2. Generator：稳定地产生某种结构化产物#
有些任务本质是生成固定形态的东西：技术报告、会议纪要、项目卡片、研究导读、PR 描述、发布说明。
如果只靠 prompt，每次格式都会飘。Generator skill 的价值，是把模板、字段、例子、风格边界一起固化下来。
这对数字分身尤其重要。因为数字分身不是聊天机器人，它要长期代表一个人的表达方式、判断结构和输出标准。格式稳定，才有可积累性。
3. Reviewer：让 Agent 学会审查，而不是只会生成#
Reviewer skill 把 checklist、严重程度、通过标准和失败案例写进去。
这类 skill 很容易被低估。很多人把 Agent 当生成器用，但真正可靠的系统必须有 review layer。
代码 review、论文 review、系统设计 review、内容安全 review、事实核查 review，本质上都需要 Reviewer skill。它不是让 Agent “挑刺”，而是让 Agent 拥有稳定的判断尺度。
4. Inversion：不是先行动，而是先把人问清楚#
有些任务不能一上来就执行。
比如做项目规划、设计产品、写商业文案、发公开邮件、改系统配置。Agent 如果缺少关键信息，最安全的能力不是“猜”，而是先 interview 用户。
Inversion skill 的价值，是把提问也变成能力：问哪些问题、最多问几轮、哪些问题必须问、哪些可以默认、什么时候停止提问进入执行。
这和 WeHub 的高带宽通信很相关。高带宽不是 Agent 多说话，而是用最少的人类注意力拿到最关键的约束。
5. Pipeline：把复杂任务变成带 gate 的流程#
Pipeline skill 用于多步骤任务：先收集事实，再生成方案，再审查，再执行，再验证，再汇报。
这听起来像 workflow，但和传统 workflow 不同。传统 workflow 常常是死流程；Agent pipeline skill 应该允许中途根据证据调整，但关键 gate 不能丢。
比如发布一篇 WeHub blog，不是“写完 HTML 就行”。它至少包括：事实核验、写作、生成页面、更新索引、部署、公开验证、回报 URL。少一步，系统就会产生“我以为发了，其实没人能看到”的幻觉。
这和 WeHub 正在做的事高度同频#
我最关心的不是 Google ADK 本身。我关心的是：这件事证明了一个方向正在变成行业共识。
WeHub 一直不是在做“很多 bot”。我们在做一个 opinionated AI collaboration system：人、个人数字分身、团队分身、数字员工一起工作，而且这个系统要可记忆、可审计、可进化。
在这个系统里，skill 是非常核心的资产单位。
Hermes skills 其实已经在做类似的事。一个好的 Hermes skill 不是几句提示词，而是包含：
触发条件
操作步骤
常用命令
失败模式
验证方式
相关 reference / template / script
什么时候该更新这个 skill这和 ADK 的 SKILL.md + references/assets/scripts 非常接近。
OpenClaw seed、MSP、memory、workflow 则是相邻层。它们回答的是另外几个问题：
seed 一个问题怎样开始生长
memory 一个 agent 怎样保留长期上下文
workflow 多个 agent 怎样协作推进
skill 一类能力怎样被封装、复用和演化
MSP 一个开放问题怎样从最小 seed 长成真实项目这些东西合在一起，才像一个真正的 Agent Harness。
如果只有 tool，没有 skill，Agent 会变成“会按按钮但没有手艺的人”。
如果只有 skill，没有 memory，Agent 每次都像新员工入职。
如果只有 memory，没有 workflow，系统会知道很多事，但推进不了复杂任务。
如果只有 workflow，没有 seed，系统会过早工程化，把不成熟的问题硬做成项目。
WeHub 要做的是把这些层连起来。
Agent runtime 的竞争，会从 tool calling 进入 capability architecture#
我越来越相信，下一阶段 Agent runtime 的关键问题不是“能不能调工具”。这已经是基础能力了。
真正的问题会变成：
能力能否被发现？
能否按需加载？
能否组合？
能否版本化？
能否被评测？
能否知道自己过期了？
能否从一次真实任务中更新？
能否在多个 agent 之间迁移？这就是 capability architecture。
很多团队现在会犯一个错误：把所有经验都塞进 prompt，把所有外部动作都叫 tool，把所有长期状态都叫 memory。这样短期能跑，长期一定乱。
一个稳健的 Agent 系统，应该把这些层分开：
Model 推理与生成
Tool 可调用动作
Skill 正确使用动作的操作知识
Memory 长期上下文和偏好
Workflow 多步骤协作结构
Seed 开放问题的生长锚点
Eval 反馈、验证和因果判断这也是 WeHub 应该继续坚持 infra-first 的原因。入口可以是 Discord、飞书、网页、终端，甚至未来任何新的 surface。但真正沉淀下来的，不是入口本身，而是这些能力结构。
Skill 也会变成负债#
当然，skill 不是银弹。
如果 skill 不更新，它会变成过期操作手册。
如果 skill 太多但没有检索和优先级，它会变成另一个 prompt 噪音源。
如果 skill 只有步骤没有验证，它会制造一种“看起来专业”的幻觉。
如果 skill 不能从真实任务反馈中演化，它只是静态文档，不是系统能力。
所以我认为 WeHub 不能只是“多写 skill”。更重要的是建立 skill 的生命周期：创建、触发、使用、失败、修订、评测、淘汰。
一个好的 skill 必须接受现实任务的压力测试。它应该回答：上次哪里错了？这次要不要改？改完如何验证？哪个 agent 已经学会？哪个 agent 还没同步？
这就把 skill 从文档变成了组织学习机制。
对 WeHub 的下一步判断#
这篇文章写到这里，我自己的判断更清楚了。
Google ADK Skills 值得关注，不是因为 Google 给了一个新名词，而是因为它把 Agent 系统里一个长期存在但一直模糊的问题，命名成了工程对象。
这个对象就是：能力。
不是工具，不是 prompt，不是一次对话里的技巧，而是可以被封装、调用、检查、迁移、更新的能力。
对 WeHub 来说，这件事是一个外部确认：我们做 Hermes skills、OpenClaw seeds、MSP、memory、workflow，不是在堆概念，而是在搭一个 Agent 社会真正需要的能力沉淀层。
未来真正有价值的 Agent 系统，不会只是模型更强、工具更多。它会有一套持续沉淀能力的结构。
人的注意力给出方向。
数字分身理解人。
团队分身协调系统。
数字员工执行任务。
而 skills，是这些 agent 把一次次真实工作变成可复用能力的地方。
这就是我觉得 Google ADK 这次值得写的原因。
它提醒我们：Agent 构建正在从 prompt engineering 走向 capability engineering。
而 WeHub 要做的，就是把这条路继续走深。
参考#
- Google ADK Skills 文档：https://adk.dev/skills/
- Google ADK 示例仓库：https://github.com/lavinigam-gcp/build-with-adk
- ADK Skill Design Patterns 示例目录：https://github.com/lavinigam-gcp/build-with-adk/tree/main/adk-skill-design-patterns
- Lavi Nigam: 5 Agent Skill Design Patterns Every ADK Developer Should Know：https://lavinigam.com/posts/adk-skill-design-patterns/