Tool 是 AI Agent 可以调用的具体动作，Skill 是把一类任务的判断、步骤、模板和资源封装起来的可复用能力包。讨论智能体 Skills 和 Tool 的区别，先要看清它们各自解决什么问题。Tool 解决能不能做，Skill 解决这类任务怎样稳定做好。对正在建设企业级 AI Agent的团队来说，先分清这两个层级，后面的工具接入、技能编写和权限设计才不会混在一起。
Anthropic 在 2025 年 12 月 18 日的更新中说明，Agent Skills 已作为开放标准发布。Skill 是包含说明、脚本和资源的文件夹，模型只在任务相关时加载。工具调用也常被称为 function calling，指模型选择工具并生成参数，由外部执行后返回结果。两者经常同时出现，职责并不相同。
Tool 是动作，Skill 是做法
一个动词能说清的动作，优先做 Tool；需要一段流程才能说清的任务，优先做 Skill。
把 Agent 看成一个新同事。Tool 是给他开通的系统接口和操作按钮，Skill 是岗位作业手册，写清楚什么情况下按什么顺序操作、结果要达到什么标准。按钮越多，不代表新人就会处理业务；手册写得再细，没有系统权限也办不成事。
这个类比对应两个判断。查询订单、发送邮件、执行 SQL、创建工单，都是边界清楚的 Tool。处理退款、生成周报、完成一次活动复盘，往往需要多个动作、几次判断和统一交付，更适合封装成 Skill。
两者处在不同层级
比较 Skills 和 Tool，容易陷入功能对照，原因在于它们不在同一个抽象层级。Tool 是可执行能力，Skill 是任务方法。一个 Skill 可以调用多个 Tool，一个 Tool 也可以被多个 Skill 使用。
| 比较维度 | Tool | Skill |
|---|---|---|
| 解决的问题 | 能不能执行某个动作 | 这类任务怎样稳定完成 |
| 封装内容 | 名称、说明、输入参数、执行端点 | 触发说明、步骤、判断规则、模板、脚本与参考资料 |
| 触发方式 | 模型判断需要某动作，生成参数调用 | 任务与描述匹配，加载说明后按步骤执行 |
| 执行位置 | 应用、工具服务或模型平台执行，结果返回模型 | 模型按说明行动，可调用工具或运行脚本 |
| 上下文占用 | 需要让模型知道可用动作与参数 | 默认只加载名称和描述，正文按需加载 |
| 适用任务 | 边界清晰、输入输出稳定的单步动作 | 多步骤、有判断标准、需要一致交付的任务 |
| 主要风险 | 参数错误、权限过大、超时与重复执行 | 触发不准、步骤遗漏、说明冲突、脚本安全 |
Agent Skills 规范把技能加载分成发现、激活、执行三个阶段。启动时只读取每个 Skill 的名称和描述，任务匹配后才读完整的 SKILL.md，脚本和引用文件再按需加载。Anthropic 工程博客把这种机制称为渐进披露，目的是让大量技能可以共存，又不把上下文一次占满。
Tool 的设计重点不同。模型需要知道有哪些动作可用、每个动作接受什么参数。工具数量多时，名称、说明和参数结构会占用上下文，可以通过分组、按需发现和清晰命名控制成本。
任务封装到底封装了什么
Skill 的价值来自把隐性经验变成可检查的步骤。一个可用的 Skill 通常包含六部分。
- 触发说明，写清什么任务该用，什么任务不该用。名称和描述决定 Agent 能否在正确的时机发现它。
- 输入与前置条件，说明需要哪些数据、文件和权限，缺什么时必须先追问。
- 步骤与判断规则，规定先做什么、分支条件是什么、何时重试、何时转人工。
- 交付模板与验收标准，给出输出格式、必填字段和质量底线。
- 资源与脚本，放入参考文档、示例、模板和可执行代码。
- 边界与权限，列明可以调用哪些 Tool，哪些动作需要审批，哪些数据不能碰。
描述写得含糊，Skill 可能不触发；步骤写得过细，又会把模型限制在固定路径。比较稳妥的做法是把判断标准和验收条件写清，把具体表达留给模型。
Skill 可以附带脚本，模型在需要时执行。脚本让结果更确定，也带来代码审查和权限问题。Skill 不负责设定目标，也不等同于一个独立 Agent。目标、记忆和权限仍由 Agent 运行时管理。
工具调用需要设计哪些细节
Tool 的设计重点是让模型选得对、传得准、执行可控。
- 名称和说明，用动作命名，说明什么时候用，也说明不适用场景。
- 参数结构，标清必填和可选，使用枚举、格式和范围约束，减少歧义。
- 返回结构，同时给出状态、数据、错误码和简短摘要，方便模型判断下一步。
- 执行控制，设置超时、重试、幂等和限流，避免重复退款、重复发券这类事故。
- 权限与审计，按最小权限授权，敏感动作二次确认，保留调用日志。
一个 Tool 最好只做一件事。把查订单、改地址、退款塞进同一个 Tool，参数会膨胀，权限也会过大。拆成三个动作后，Skill 可以根据场景组合，权限也能分别控制。
模型负责决定调用哪个工具并生成参数，实际执行由应用、工具服务或模型平台完成，结果再回到模型。MCP 规范把 Tool 定义为可执行函数，包含名称、说明和输入 schema，通过 tools/call 执行。这个定义可以帮助理解工具调用的边界，具体协议并不影响 Tool 作为动作层的定位。
两者如何配合完成一个任务
一个完整任务通常这样走。
- 用户说出目标。
- Agent 根据任务匹配 Skill。
- 加载 `SKILL.md` 和必要资源。
- 按步骤调用 Tool。
- 检查结果，失败时重试或转人工。
- 交付结果并记录 Trace。
以售后处理为例。用户说订单一直没到。Agent 匹配售后处理 Skill，Skill 要求先查订单和物流，再判断是否满足补发条件，最后按模板回复。查订单、查物流、发起补发是三个 Tool；先查哪个、什么条件下补发、如何解释，是 Skill 的内容。
这种分工让变化发生在正确的位置。物流接口换了，只改 Tool；补发政策变了，只改 Skill；两者都不需要重写整个 Agent。
如果 Skill 里包含脚本，脚本可以在需要时执行。它仍然是 Skill 的资源，工具调用仍然由任务步骤决定。生产环境还要处理版本、权限和审计，这部分属于 Agent 管理，不应塞进 Skill 的说明里。
什么时候用 Tool，什么时候用 Skill
可以用四个问题判断。
- 能否用一个动词说清？ 能，优先做 Tool。
- 是否需要多步判断和统一交付？ 是，优先做 Skill。
- 是否需要访问外部系统？ 先接 Tool，再由 Skill 组织调用。
- 是否只出现一次？ 一次任务用提示词即可，反复出现再封装。
常见的组合有三种。单动作高频调用，做一个稳定的 Tool。多步骤且有标准，做 Skill 加若干 Tool。跨团队复用，做带版本、权限和评测的 Skill。
先做 Tool 还是先做 Skill，取决于当前瓶颈。 模型不知道能做什么，先补 Tool；模型知道动作但每次做法不同，先补 Skill。不要为了统一架构把所有任务都做成 Skill，也不要为了省事把所有流程塞进一个 Tool。
企业落地常见的四个问题
第一个问题，把 Skill 当成长提示词。 只有一段背景说明，没有步骤、输入条件、验收标准和版本记录。模型每次都能读，每次做法仍可能不同。改法是围绕一个真实任务写流程，用测试集验证触发和结果。
第二个问题，把流程塞进一个万能 Tool。 参数越来越多，权限越来越大，任何一个 Skill 都难以复用。改法是拆成原子动作，把顺序和判断交给 Skill。
第三个问题，只做能力，不做权限。 Skill 能执行代码，也能引导模型调用工具。来源不可信的 Skill 要先审查脚本、依赖和外部网络访问。退款、发券、删除数据等动作要有额度、审批和审计。
第四个问题，没有评测和观测。 只看一次演示，无法判断 Skill 是否在正确时机触发，也无法定位失败发生在意图理解、技能步骤还是工具执行。至少记录触发准确率、任务完成率、工具调用成功率、人工接管率、时延和成本。
ThinkingAI 的实践视角
在 ThinkingAI 的 Agentic Engine 中，企业可以把一次分析流程沉淀为可复用的 Skill，再通过 Agent 管理处理权限、调度和运行监控。Agent 观测平台可以在单次 Trace 中核对 Conversation、Model、Tool、Skill 的执行证据，团队可以判断问题出在意图理解、技能触发还是工具执行。
这类平台能力适合已经有多条 Agent 业务线、需要统一治理的团队。如果只是验证一个单点任务，先用最小 Tool 和 Skill 跑通更合适。目前 ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款。
常见问题
Skill 是不是一种 Tool？
不是。Tool 是可执行动作，Skill 是任务说明和资源包。Skill 可以调用 Tool，Tool 不包含任务流程。
一个 Skill 可以调用多个 Tool 吗？
可以。Skill 的步骤里可以安排多个 Tool 调用，并规定先后顺序、失败重试和人工接管条件。工具越多，越要把权限和异常处理写清楚。
Skill 越多越好吗？
不一定。每个 Skill 都会增加发现和维护成本。只有重复出现、步骤相对稳定、结果需要统一的任务，通常才值得封装。
小团队应该先做 Tool 还是 Skill？
看当前瓶颈。模型缺少动作，先接 Tool；模型有动作但每次做法不一致，先写 Skill。多数业务任务最后会同时需要两者。
参考资料
- Anthropic，Introducing Agent Skills，2025 年 12 月 18 日更新，https://www.anthropic.com/news/skills
- Anthropic Engineering，Equipping agents for the real world with Agent Skills，https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
- Anthropic，Skills explained，https://claude.com/blog/skills-explained
- Model Context Protocol，Architecture，https://modelcontextprotocol.io/docs/learn/architecture
