如果你最近在关注 Agent 相关技术，应该会发现一个现象：B站、知乎、公众号上“Agent Skills 开发”类的教程越来越多，甚至已经有“全 259 集”“零基础七天从小白到大神”这样的标题出现。坦白说，我不太建议你迷信“七天速成”的说法，但“Agent Skills”本身值得你花时间认真学，因为它很可能是 Agent 应用从“演示能用”走向“生产可用”的关键一块拼图。
为什么这么说？过去两年，大家讨论 Agent 时最常问的问题是“用哪个框架”“接哪个模型”“要不要 RAG”。但等真正把 Agent 放到业务里，你会发现最卡脖子的往往不是模型智商，而是模型面对具体任务时缺少一套可复用、可维护、可约束的“职业技能”。一个能写诗、能聊天的模型，和一个能帮你按公司规范生成 Git 提交信息、整理周报、巡检日志的模型，差别不在底座模型，而在外面挂了多少高质量的 Skills。
这篇文章我会从开发者的视角，把 Agent Skills 的本质、它与 Tool/Workflow 的区别、零基础学习路线、环境准备、一个完整的 Skill 手写示例、接入与验证方式、常见坑以及工程化建议一次讲透。读完你至少能自己写一个可以跑通的最小 Skill，并且知道后续该往哪个方向深入。
1. 为什么 Agent 会“聊得很好，但干不了活”
先看一个典型场景。你给大模型配了 API Key，让它帮你总结文档、生成代码，它通常表现不错。但如果你让它“帮我把这个仓库的改动整理成符合团队规范的提交信息”，它往往会直接开始编一段看起来很合理、实际无法落地的 commit message，因为它看不到你真正暂存了哪些文件，也不了解你团队的规范。
这就暴露出一个核心问题：大模型本身是一个“推理引擎”，而不是一个“执行引擎”。它知道 commit message 长什么样，但它不知道当前代码仓库发生了什么；它能告诉你“应该怎么做”，但无法直接读取你的 Git 暂存区、文件系统、数据库或内部系统。
于是社区里出现了几种解决方案：
- Function Calling / Tool Calling：让模型在推理时请求调用一个预先定义好的外部函数。
- Agent / Workflow：把多个模型调用和工具调用编排成一条复杂链路。
- MCP 这类协议：让模型能够通过标准接口连接外部数据源和工具。
这些方案都在解决“让模型能做事”的问题。但要做到“做得好、做得稳、可复用”，还需要一个更贴近业务能力表达的封装层。Agent Skills 正是在这个背景下受到关注。
你可以这样理解：Tool 是给 Agent 的“四肢”，解决能不能做到的问题；Skill 是给 Agent 的“岗位说明书 + 工具箱”，解决的是“接到一个任务时，知道该按什么流程、用哪些工具、遵守什么约束来完成”的问题。
所以，判断一个 Agent 能不能真正落地，不要只看它接了哪些模型、有没有 RAG，要看它为具体岗位沉淀了多少个高质量的 Skills。这也是我觉得 Agent Skills 值得单独立项学习的原因。
2. Agent Skills 是什么：它与 Tool、Workflow 的边界在哪里
在开始实践前，先把几个容易混淆的概念理清楚。很多教程讲到后面，会把 Skill、Tool、Prompt 混在一起，导致读者越学越乱。
2.1 Agent Skills 的直观定义
一个 Agent Skill 是一段 可描述、可复用、自包含 的“能力包”。它通常包含：
- 一个说明文件：告诉模型这个技能是干什么的、什么时候该用、该怎么用。
- 一段或多段实现逻辑：可以是 Python 脚本、Shell 命令、配置文件或文档模板。
- 必要的依赖与资源：例如一个 JSON Schema、一份术语表、一组校验规则。
当一个 Agent 遇到任务时，它会先从已注册的 Skills 列表里找到匹配项，读取该技能的说明，然后按照说明调用实现逻辑，最后把执行结果返回给用户。
2.2 与 Tool 的区别
Tool 通常是原子的，比如“获取天气”“计算两个日期差”“执行一条 SQL”。它输入明确、输出明确，几乎不需要模型做流程判断。
Skill 则是“完成一项任务所需的完整方法”。它内部可能包含多个步骤，也可能调用多个 Tool。比如“给客户生成一封天气预警邮件”是一个 Skill，它可能需要：
- 查询目标客户的联系方式和订阅偏好；
- 获取未来几小时天气预警；
- 按客户模板生成邮件正文；
- 调用发送接口或生成待发送草稿。
如果只给 Agent 一个“查天气”的 Tool，模型仍然不知道完整流程；只有把完整流程封装成 Skill，Agent 才能稳定复现这套行为。
2.3 与 Workflow / 智能体工作流 的区别
Workflow 更像一段预设好的、不可随意跳步的流程，比如“先查库存，再算价格，再生成订单”。其执行路径是预先定义好的。
Skill 则更偏向“能力组件”，可以被不同的 Workflow 复用。同一个“生成周报”的 Skill，既能在一个定时任务里被调用，也能在用户和机器人对话时被调用。
我把它们的关系画成一张简单对应表：
| 名称 | 解决问题的层次 | 典型粒度 | 是否可被多个场景复用 |
|---|---|---|---|
| Prompt | 告诉模型怎么思考 | 指令文本 | 较弱，通常绑定场景 |
| Function / Tool | 让模型能调用外部能力 | 原子动作 | 中等 |
| Workflow | 把多个步骤编排成固定流程 | 流程链路 | 较弱，常为特定业务定制 |
| Agent Skill | 把完成某类任务的知识、工具、规范和实现封装起来 | 能力包 | 强，可被多个 Agent 或场景复用 |
从这张表可以看到，Skill 不是比 Tool 更高级的替代品，而是位于 Tool 之上的组织层。你在实际项目里通常先有一批基础 Tool，再围绕具体业务场景把它们封装成 Skills。
3. 零基础学习 Agent Skills：先认清这条路线，再动手
很多人被“七天从小白到大神”吸引，但实际学习时容易踩两个坑：一是堆概念不写代码，二是直接去看复杂的多 Agent 系统，结果被调度、记忆、编排这些概念劝退。
从工程角度看，我更建议你按照下面这条“从下到上”的路线学习。
3.1 阶段一：先跑通一次“模型调用 Tool”
不要一上来就构建 Skill 平台。建议先在你的开发环境里，用任意一个大模型 API，实现一个最简单的 Function Calling 例子。
目标是搞清楚：当模型说“我想调用获取天气函数”时，API 返回的 tool_call 结构长什么样，你的代码如何根据它执行函数并把结果回传给模型。
这个阶段不需要写很复杂的代码，两三百行以内就够了，但能帮你建立“模型与外部世界通过工具交互”的基础认知。
3.2 阶段二：理解 Skill 是“Prompt + Tool + 流程”的封装
请记住一个公式：
Agent Skill = 清晰的触发描述 + 可执行的实现逻辑 + 必要的约束规范
如果你现在能写出一个可以正确运行的 Tool，下一步就是把它的使用说明写得更结构化、更可被发现。比如不要只给模型一个叫 g
416
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
