13. Skill 是什么？

👔面试官：A2A 协议里有个 Skill 的概念，说说它是什么？

🙋‍♂️我：Skill 就是工具嘛，跟 Function Calling 里定义的函数差不多，就是 Agent 能调用的一个个具体操作。

👔面试官：Skill 和 Function Calling 的工具是一回事？那 A2A 为什么不直接复用 Function Calling 的 schema，非要再搞一个 Skill 出来？

🙋‍♂️我：嗯……可能是因为 Skill 的描述更丰富一些？比如加了 tags 和 examples 字段，但本质上应该还是一个函数吧，只是包装不同？

👔面试官：你把 Skill 的粒度搞错了。Function 是原子操作，调一次做一件明确的事；Skill 是一类能力声明，描述的是 Agent 能承接什么样的任务，粒度比函数粗得多，内部实现对外完全黑盒。你连「能力声明」和「函数调用」的区别都没分清，Skill 在多 Agent 系统里怎么做任务路由、为什么不能用 Function 替代，这些都得好好理清楚。

好，这段对话踩的雷很典型，很多人一上来就把 Skill 等同于 Function Calling 里的工具。下面我把 Skill 的定位和作用拆开讲清楚。

💡 简要回答

Skill 是 A2A 协议里 Agent 对外声明「我能做什么类型的任务」的机制。它和 Function Calling 里的工具不是一回事，工具是一个具体函数，调一次做一件明确的事；Skill 是一类能力声明，比如「竞品分析」「代码审查」，描述的是 Agent 能承接什么样的任务，内部怎么实现对外是黑盒。在多 Agent 系统里，调度 Agent 拿到任务后，就是根据各个 Agent 的 Skill 来决定把任务路由给谁，粒度比函数粗，比整个 Agent 细，正好处于任务匹配和委托需要的那个层次。

📝 详细解析

Skill 的由来：Agent 需要对外描述自己能做什么

你可能会想，有了 Function Calling 不就够了吗？模型需要什么工具，定义好 schema 就行了，为什么还要再搞一个 Skill 出来？

在单 Agent 时代，Function Calling 确实够用。你定义好函数的名字、参数、描述，模型就知道有哪些工具可以调、怎么调，整个流程很清晰。

但到了多 Agent 时代，情况就完全不一样了。想象一下，一个「调度 Agent」要把任务分发给好几个专业 Agent，它怎么知道每个 Agent 擅长什么、能不能接这个任务？你总不能让调度 Agent 去翻对方所有的底层函数列表，然后自己推断「哦，这个 Agent 有搜索函数、有汇总函数、有写作函数，所以它应该能做竞品分析」吧？这样太细太碎了，而且还把人家的内部实现全暴露了。

所以就需要一种更高层次的「能力摘要」机制，粒度比单个函数粗，但又比 Agent 整体描述细，正好处于一个适合任务匹配和委托的层次。Skill 就是专门干这件事的。

Skill 的结构

理解了 Skill 的由来，再来看它在协议里具体长什么样子。在 A2A 协议里，每个 Agent 对外公开一张「名片」叫 Agent Card，里面有一个 skills 列表，记录着这个 Agent 能承接哪些类型的任务。每条 Skill 的结构其实很直观：

{
  "id": "code-review",           // Skill 的唯一标识，调用时用这个 ID 指定
  "name": "代码审查",             // 可读名称
  "description": "对给定代码进行全面审查，识别 bug、安全漏洞、性能问题，并给出改进建议",
  "tags": ["coding", "review", "security"],  // 标签，方便调度 Agent 搜索匹配
  "examples": [
    "审查这段 Python 代码有没有 SQL 注入风险",
    "帮我看看这个函数的时间复杂度是否有优化空间"
  ],                              // 示例输入，帮助调度 Agent 判断任务是否匹配这个 Skill
  "inputModes": ["text", "file"], // 接受的输入类型
  "outputModes": ["text"]         // 输出类型
}

这里面的 examples 字段值得多说两句，它的作用有点像简历里的「项目经验」。你想，光看一个 Skill 的名字和描述，调度 Agent 可能还不太确定某个任务该不该交给它。但如果有了几个具体的示例输入，调度 Agent（或者一个路由模型）就可以把用户的任务描述和各个 Skill 的 examples 做语义相似度匹配，快速判断「这个任务跟哪个 Skill 最对口」。就好像你看一个候选人的简历，光看「擅长后端开发」这个标签还不够，看到他做过的具体项目，才能判断他适不适合你这个岗位。

Skill 和 Function 在概念上的区别

两者经常被混淆，但其实它们处于完全不同的抽象层次，用一个类比就能讲清楚。

你可以把 Function 想象成一个员工的「单项技能」，比如「会用 Excel」「会写 SQL」，每一项都很具体，调一次做一件明确的事，执行时间短，结果立刻返回。get_weather(city) 就是一个典型的 Function，你告诉它城市名，它马上给你天气数据，调用方完全清楚它接受什么参数、返回什么格式。

而 Skill 更像是这个员工的「岗位能力」，比如「能做竞品分析」「能做代码审查」。这种能力描述的是他能承接什么类型的工作，至于他内部是怎么完成的，用了多少个工具、查了多少次资料、跑了多少次模型，外面根本不需要知道，也不应该知道。比如「做一份竞品分析报告」这个 Skill 背后可能涉及搜索、汇总、写作好几个步骤，执行时间可能是分钟级甚至更长，但对调用方来说，整个过程就是一个黑盒，只管交任务、等结果就行。

一个具体的例子：调度 Agent 怎么用 Skill 路由任务

假设有三个专业 Agent 注册在系统里，各自声明了自己的 Skill：

研究 Agent:  skills = ["行业调研", "竞品分析", "数据收集"]
写作 Agent:  skills = ["报告撰写", "文案润色", "内容摘要"]
代码 Agent:  skills = ["代码生成", "代码审查", "单元测试编写"]

用户对调度 Agent 说「帮我做一份 AI 编程工具的竞品分析报告」，调度 Agent 首先要理解这个任务需要什么能力，拆解下来就是「竞品分析」和「报告撰写」两类。接着它去查各个 Agent 的 Skill 列表，发现研究 Agent 声明了「竞品分析」，写作 Agent 声明了「报告撰写」，正好对口。于是调度 Agent 先通过 A2A 向研究 Agent 发任务：「分析 GitHub Copilot、Cursor、Codeium 的产品定位和差异」，拿到研究结果之后，再通过 A2A 向写作 Agent 发任务：「基于以下分析数据，撰写一份结构化的竞品报告」，最后把写作 Agent 的产出汇总返回给用户。

在整个流程里，调度 Agent 只看 Skill 做路由决策，完全不需要知道研究 Agent 内部用了哪些工具、调了多少次 API、花了多长时间。这就是 Skill 作为「能力声明」的价值所在，它让多 Agent 系统的分工协作变得非常干净。

🎯 面试总结

回到开头对话踩的雷，最常见的误区就是把 Skill 等同于 Function Calling 里的工具函数。面试回答这道题，第一个必须说清楚的点是 Skill 和 Function 的粒度差异：Function 是原子操作，一次调用做一件明确的事，比如 get_weather(city)；Skill 是任务类别的能力声明，比如「竞品分析」「代码审查」，描述的是 Agent 能承接哪类工作，内部怎么实现对调用方完全黑盒。

第二个关键点是 Skill 在多 Agent 系统里的角色。Skill 写在 Agent Card 里，调度 Agent 拿到用户任务后，就是靠各专业 Agent 声明的 Skill 列表来做路由决策的，所以 Skill 本质上是一个「简历」机制，解决的是「哪个 Agent 接哪类任务」的匹配问题。面试的时候如果能举出调度 Agent 根据 Skill 路由任务的完整例子，会比干巴巴讲概念有说服力得多。

要避免的误区：不要把 Skill 说成「更丰富的函数定义」，两者的抽象层次完全不同，Skill 是 Agent 之间的协作接口，Function 是 Agent 内部的工具调用机制。

---

对了，AI 工具调用的面试题会在「公众号@小林面试笔记题」持续更新，林友们赶紧关注起来，别错过最新干货哦！