前言

在学习 Agent 开发时，很多人会先关注大模型、Prompt、框架或者工作流：

• 用什么大模型？
• Prompt 怎么写？
• 用 LangChain、Dify、AutoGen 还是 OpenAI Agents SDK？
• Agent 怎么规划任务？
• 多 Agent 怎么协作？

这些当然重要，但如果真正进入 Agent 工程开发，就会发现一个更核心的问题：

Agent 不是只靠“会说话”完成任务，而是要靠“会调用能力”完成任务。

这里的“能力”，通常就可以抽象成 Skills。

一个 Agent 能不能稳定工作，不只取决于大模型本身有多强，还取决于它能调用哪些 Skills、这些 Skills 是否设计清楚、边界是否明确、输入输出是否规范、异常是否可控。

所以，理解 Agent Skills，是学习 Agent 开发非常重要的一步。

---

1. 从普通大模型到 Agent

普通大模型主要擅长生成文本。

比如用户问：

帮我总结一下这段话。

模型可以直接根据上下文生成回答。

但是如果用户问：

帮我查一下今天北京天气，然后根据天气建议我穿什么。

这时模型本身并不知道“今天北京天气”的实时数据。它需要调用外部能力，比如天气查询接口。

再比如用户问：

帮我搜索最近一周关于某个技术的新闻，并整理成一份摘要。

这时模型需要：

1. 搜索网页；
2. 读取网页内容；
3. 筛选有效信息；
4. 总结内容；
5. 生成结构化结果。

这些能力都不是模型单靠内部参数就能稳定完成的，而是需要外部工具或能力模块支持。

这就是 Agent 和普通大模型应用的重要区别。

普通大模型更像是一个“回答者”，而 Agent 更像是一个“执行者”。
Agent 不仅要理解任务，还要判断应该调用哪些能力来完成任务。

这些可以被 Agent 调用的能力单元，就是我们要讨论的 Skills。

---

2. 什么是 Agent Skills？

可以先给出一个简单定义：

Agent Skill 是 Agent 可以调用的、面向具体任务封装好的能力单元。

它可以是一个函数，也可以是一个 API，也可以是一段工作流，还可以是一个外部服务。

常见的 Skills 包括：

• 搜索网页；
• 查询数据库；
• 读取文件；
• 解析 PDF；
• 调用天气 API；
• 调用地图 API；
• 执行代码；
• 发送邮件；
• 生成图片；
• 检索知识库；
• 调用企业内部系统；
• 生成结构化报告。

但是需要注意：

Skill 不等于随便写一个函数。

一个真正可用的 Skill，通常不只是执行逻辑本身，还应该包含：

• 这个 Skill 是做什么的；
• 什么时候应该调用；
• 什么时候不应该调用；
• 需要哪些输入参数；
• 返回什么格式的结果；
• 出错时怎么处理；
• 调用结果是否可信；
• 是否需要权限控制；
• 是否需要人工确认。

所以，Skill 更像是一个面向 Agent 的能力封装，而不是一个普通函数。

---

3. Skill 和 Tool 有什么区别？

在很多框架里，Tool 和 Skill 经常会被混用。

简单理解可以这样区分：

概念	侧重点	示例
Function	普通函数，强调代码执行	search(query)
Tool	可被模型调用的工具，强调调用接口	网页搜索工具
Skill	面向任务封装的能力，强调任务边界和使用规则	根据问题搜索资料，并返回摘要和来源
Workflow	多个步骤组成的固定流程	搜索 → 阅读 → 总结 → 输出报告
Agent	根据任务动态选择能力并执行	判断是否需要搜索、是否需要读取文件、是否需要生成结果

可以用一个例子理解。

如果我们有一个函数：

def search_api(query: str):
    ...

这是一个 Function。

如果把它注册给大模型，让模型可以调用它，这就是一个 Tool。

但如果我们进一步封装成：

Skill 名称：web_search_skill

功能：
根据用户问题搜索互联网信息，返回与问题相关的结果摘要、来源链接和发布时间。

适用场景：
用户询问最新信息、实时信息、新闻、价格、政策、产品版本等内容。

不适用场景：
用户只是要求改写、翻译、总结已提供文本时，不应调用该 Skill。

这就更接近一个 Skill。

因为它不只是一个底层调用接口，而是带有任务语义、使用边界和返回规范的能力模块。

---

4. 为什么 Agent 离不开 Skills？

4.1 Skills 扩展了 Agent 的能力边界

大模型本身有知识截止时间，也不能直接访问外部系统。

通过 Skills，Agent 可以获得更多能力：

• 通过搜索 Skill 获取实时信息；
• 通过数据库 Skill 查询业务数据；
• 通过文件解析 Skill 读取用户上传文档；
• 通过代码执行 Skill 进行计算和分析；
• 通过邮件 Skill 帮用户草拟或发送邮件；
• 通过 RAG Skill 检索企业知识库。

没有 Skills，Agent 很容易变成一个只能聊天的模型。
有了 Skills，Agent 才能真正进入“执行任务”的阶段。

---

4.2 Skills 让 Agent 的行为更可控

很多人以为 Agent 越自由越智能，但在实际工程里，Agent 不能完全自由发挥。

如果用户问：

帮我查一下这个订单状态。

Agent 不应该随便编一个订单状态，而应该调用订单查询 Skill。

如果用户问：

帮我删除这批数据。

Agent 不应该直接执行危险操作，而应该先进行权限检查和二次确认。

Skills 的存在，可以把 Agent 的能力限制在明确的边界内：

• 能做什么；
• 不能做什么；
• 需要什么参数；
• 哪些操作需要确认；
• 哪些操作必须拒绝；
• 哪些结果需要验证。

所以，Skills 不只是扩展能力，也是在约束能力。

---

4.3 Skills 让 Agent 更容易工程化

一个真正可上线的 Agent 系统，不能只看最终回答是否流畅，还要关注：

• 每次调用了什么 Skill；
• Skill 是否调用成功；
• 输入参数是否正确；
• 返回结果是否符合预期；
• 调用耗时是多少；
• 调用成本是多少；
• 错误原因是什么；
• 是否可以复现问题。

如果所有能力都写在一个大 Prompt 里，系统很难维护。

而如果把能力拆成一个个 Skills，就可以分别管理、测试、记录和优化。

例如：

用户问题
  ↓
Agent 判断任务类型
  ↓
选择合适的 Skill
  ↓
校验输入参数
  ↓
执行 Skill
  ↓
检查返回结果
  ↓
生成最终回答

这种结构比单纯依赖 Prompt 更稳定，也更适合工程落地。

---

5. 一个 Skill 应该包含哪些部分？

一个基础的 Skill 可以包含以下内容：

Skill
├── name：Skill 名称
├── description：功能描述
├── input_schema：输入参数结构
├── output_schema：输出结果结构
├── handler：实际执行逻辑
├── error_handler：异常处理逻辑
├── examples：调用示例
├── constraints：限制条件
└── metadata：版本、权限、分类等信息

下面是一个简单例子。

{
  "name": "weather_query",
  "description": "查询指定城市在指定日期的天气情况，适用于用户询问实时天气或天气预报的场景。",
  "input_schema": {
    "city": "string",
    "date": "string"
  },
  "output_schema": {
    "city": "string",
    "date": "string",
    "weather": "string",
    "temperature": "string",
    "suggestion": "string"
  }
}

这个 Skill 的关键不只是能查天气，而是它告诉 Agent：

• 它叫什么；
• 它能做什么；
• 它需要什么参数；
• 它会返回什么；
• 它适合什么场景。

这样 Agent 才更容易正确调用它。

---

6. 为什么不能把所有能力都写进 Prompt？

很多初学者会尝试用一个很长的 Prompt 解决所有问题。

比如在 Prompt 里写：

如果用户问天气，你就回答天气。
如果用户问新闻，你就搜索新闻。
如果用户问代码，你就写代码。
如果用户问文件，你就读取文件。

这种方式在 Demo 里可能看起来可行，但在真实系统中会有很多问题。

6.1 Prompt 难以管理复杂能力

当任务越来越复杂，Prompt 会变得越来越长。
规则越多，模型越容易混乱。

6.2 Prompt 不能真正访问外部系统

Prompt 只能告诉模型“应该做什么”，但不能让模型真正查询数据库、调用 API 或读取文件。

真正的执行能力还是要靠 Skills。

6.3 Prompt 缺少强约束

Prompt 是软约束，模型可能遵守，也可能不遵守。
而 Skill 的参数校验、权限控制、异常处理是硬约束，更适合工程系统。

6.4 Prompt 不方便测试和复用

一个 Skill 可以单独测试：

输入参数是否正确？
返回结果是否稳定？
异常情况是否能处理？
耗时是否可接受？

但一个大 Prompt 很难做到细粒度测试。

所以，Prompt 可以指导 Agent 思考，但 Skills 才是 Agent 真正执行任务的基础。

---

7. 一个简单的 Skill 调用流程

一个 Agent 调用 Skill 的过程通常可以抽象成：

用户提出任务
  ↓
Agent 理解意图
  ↓
判断是否需要调用 Skill
  ↓
选择合适的 Skill
  ↓
生成 Skill 输入参数
  ↓
参数校验
  ↓
执行 Skill
  ↓
返回结构化结果
  ↓
Agent 基于结果生成最终回答

例如用户问：

明天上海会下雨吗？我需要带伞吗？

Agent 的处理流程可以是：

1. 判断这是天气相关问题；
2. 选择 weather_query Skill；
3. 提取参数：city=上海，date=明天；
4. 调用天气查询接口；
5. 获取天气结果；
6. 判断是否需要带伞；
7. 用自然语言回答用户。

这里真正查询天气的是 Skill，而不是模型自己猜。

---

8. 常见的 Skill 设计错误

8.1 Skill 名称太模糊

错误示例：

do_task
process
helper
query

这些名称太抽象，Agent 很难判断什么时候应该调用。

更好的名称：

web_search
weather_query
database_lookup
pdf_parser
email_sender
knowledge_retrieval

---

8.2 Description 写得太简单

错误示例：

这个工具用于搜索。

更好的写法：

当用户询问最新信息、新闻、价格、政策、产品版本、实时数据等内容时，使用该 Skill 搜索互联网信息。若用户只是要求改写、翻译或总结已提供文本，不应调用该 Skill。

好的 description 应该同时说明：

• 这个 Skill 能做什么；
• 适合什么场景；
• 不适合什么场景；
• 输入参数有什么要求；
• 返回结果是什么。

---

8.3 输入参数没有约束

错误示例：

{
  "input": "string"
}

这会让所有信息都塞进一个字段里，后续很难校验。

更好的设计：

{
  "query": "string",
  "time_range": "string",
  "max_results": "number"
}

结构化参数能让 Skill 更稳定，也更容易调试。

---

8.4 返回结果不可解析

错误示例：

查到了，结果还不错。

这种返回对 Agent 没有太大帮助。

更好的返回：

{
  "status": "success",
  "results": [
    {
      "title": "示例标题",
      "summary": "示例摘要",
      "source": "来源",
      "published_at": "发布时间"
    }
  ]
}

结构化输出可以让 Agent 更容易继续处理结果。

---

8.5 没有异常处理

真实系统中，Skill 经常会失败：

• 参数缺失；
• 网络超时；
• API 报错；
• 查询结果为空；
• 权限不足；
• 返回格式异常。

如果 Skill 没有异常处理，Agent 就可能继续基于错误结果生成回答。

一个更好的 Skill 应该返回明确状态：

{
  "status": "failed",
  "error_type": "timeout",
  "message": "天气服务请求超时，请稍后重试。"
}

---

9. 学习 Agent Skills 应该关注什么？

如果是为了学习和面试，不建议一开始就陷入某个具体框架。

更建议先掌握这些通用能力：

1. Skill 抽象能力
   能不能把一个复杂任务拆成几个清晰的能力单元。

2. 输入输出设计能力
   能不能设计清楚参数、返回值和结构化结果。

3. 边界划分能力
   能不能说明一个 Skill 做什么、不做什么。

4. 异常处理能力
   能不能处理失败、空结果、超时和错误参数。

5. Agent 调用控制能力
   能不能降低乱调、漏调和误调工具的问题。

6. 工程化能力
   能不能做日志、监控、权限、评估和版本管理。

这些能力比单纯会用某个框架更重要。

框架会变，但这些设计思想不会很快过时。

---

10. 面试中怎么解释 Agent Skills？

如果面试官问：

你怎么理解 Agent Skills？

可以这样回答：

我理解的 Skill 是 Agent 可以调用的能力单元。它不是简单的函数，而是一个面向任务封装的模块，通常包括名称、描述、输入参数、输出格式、执行逻辑、异常处理和调用边界。

在 Agent 系统中，大模型主要负责理解用户意图、规划任务和选择能力；Skill 负责真正执行具体动作，比如搜索、查库、读文件、调用 API 等。

一个 Agent 是否稳定，很大程度上取决于 Skill 是否设计清楚。比如 description 是否明确、参数 schema 是否规范、返回结果是否结构化、失败时是否有兜底机制。这些都会影响 Agent 是否能正确调用工具，以及最终任务能不能完成。

如果想回答得更工程化，可以补充：

在工程实现中，我会把 Skills 注册到 Skill Registry 中，通过 Skill Router 根据任务类型选择候选 Skill。每个 Skill 都有输入校验、异常处理、调用日志和结果结构化返回。这样可以提升 Agent 的可控性、可观测性和可维护性。

---

11. 小结

Agent Skills 是 Agent 开发中非常核心的概念。

它解决的不是“模型会不会回答”的问题，而是“模型能不能调用合适的能力完成任务”的问题。

可以用一句话总结：

Prompt 决定 Agent 怎么思考，Skills 决定 Agent 能做什么。

一个优秀的 Agent 系统，不应该只依赖大模型自由发挥，而应该把外部能力拆成清晰、可控、可复用的 Skills。

学习 Agent Skills，重点不是记住某个框架的 API，而是理解这些问题：

• Skill 是什么？
• Skill 和 Tool 有什么区别？
• Skill 为什么能扩展 Agent 能力？
• Skill 应该怎么设计输入输出？
• Skill 怎么控制边界？
• Skill 调用失败怎么办？
• Skill 怎么工程化管理？

理解了这些，再去学习 LangChain、Dify、MCP、OpenAI Agents SDK 或其他 Agent 框架，就会更容易抓住本质。

---

下一篇预告

下一篇可以继续讨论：

Skill、Tool、Function、Workflow、Agent 有什么区别？

这一篇会重点解释 Agent 开发中最容易混淆的几个概念，并通过具体例子说明它们在工程系统中的不同定位。