大模型能力扩展：技能机制与工具调用对比

一、对比背景：为什么要把这两种机制放在一起看

随着大模型应用从“单轮问答”走向“任务执行”，如何让模型获得训练数据之外的能力，成为每个团队都要面对的工程问题。业界目前形成了两条比较主流的扩展路线：

• 工具调用路线：开发者把外部系统的操作封装成符合协议规范的工具，由模型按需调用，是当前各类大模型服务平台普遍支持的基础能力；
• 技能路线：近期由某头部大模型厂商提出，把完成某类任务所需的指令、脚本和资源组织成一个文件夹，由模型在任务相关时动态加载。

不少开发者的第一反应是：这两者本质上是不是一回事？本文的观点与业界普遍观察一致——两者的本质相同，都是让模型拥有外部能力，属于模型的“外挂”，但规范定义不同，导致使用方式与能力边界有明显区别。下面从定义、相同点、差异点、选型与迁移逐层展开。

二、对象定义

2.1 技能机制：文件夹形态的能力包

按照提出该机制的厂商的官方定义：技能是一组包含指令、脚本和资源的文件夹，模型可以动态加载这些内容，从而在特定任务上提升表现。这些技能教会模型如何以可重复的方式完成特定任务，例如按照企业品牌规范创建文档、按照组织内部流程分析数据，或者自动化某些个人任务。

也可以这样理解：技能是扩展模型功能的模块化能力单元。每个技能打包了指令、元数据以及可选的资源（如脚本、模板），当任务相关时，模型会自动调用这些内容来执行。

2.2 工具调用机制：协议化的操作外挂

工具调用是业界通用的能力扩展协议，百度智能云等国内外大模型服务平台的大模型服务普遍支持这一能力，并配套插件、知识库检索等扩展组件。其基本工作模式是：

1. 开发者按约定格式声明一组工具，包括名称、功能描述和参数结构；
2. 推理时，这些工具声明随提示词注入模型上下文；
3. 模型根据用户请求判断是否调用某个工具，由运行时实际执行外部操作；
4. 执行结果回传模型，模型继续推理或组织回答。

一句话概括两者的定位差异：工具调用解决“让模型能操作外部系统”，技能机制解决“让模型掌握完成某类任务的完整方法”。

三、相同点分析

虽然规范不同，但两种机制在底层逻辑上有四点高度一致：

• 目标一致：都是为了突破模型参数化知识的边界，把模型“不会做、做不好”的事情交给外部能力补齐；
• 匹配逻辑一致：都依赖“元数据”完成任务与能力的匹配——工具靠功能描述与参数说明，技能靠名称与描述，模型都是先“看说明”再决定用不用；
• 基本链路一致：声明 → 匹配 → 加载/调用 → 执行 → 结果回传，整体工作流同构；
• 工程化诉求一致：在的企业生产环境中，两者都需要考虑版本管理、权限控制、审计日志与安全准入，不能只当“配置文件”或“插件列表”来管理。

正因为本质相同，很多团队会纠结“该用哪个”。要回答这个问题，关键在于看清二者在以下几个维度上的结构性差异。

四、核心差异分析

4.1 能力封装形态：离散操作 vs 结构化流程

• 工具调用：一个工具通常对应一个具体的原子操作，如查询数据、写入记录、发送消息。输入输出由参数结构严格约束，复杂任务需要模型自行组合多次工具调用，组合逻辑存在于模型的“临场发挥”中。
• 技能机制：一个技能对应一类任务的完整方法论——包括工作流、最佳实践、使用指导、辅助脚本和模板。它更接近“把一位领域专家的操作手册交给模型”，模型不是在临场摸索步骤，而是按照沉淀好的流程执行。

这也是为什么说技能机制定义的是“更复杂的能力”：它封装的不只是“能调什么”，而是“该怎么做”。

4.2 上下文占用与加载策略：一次性注册 vs 渐进式披露

这是两者最具工程价值的差异点。

工具调用通常要求在请求时把所有工具的名称、描述与参数结构全量注入上下文。当工具数量较多时，提示词会明显膨胀，既推高token成本，也可能干扰模型对工具的选择准确率。

技能机制则采用典型的三层渐进式披露设计：

• 第一层（元数据）：启动时，Agent只把所有已安装技能的名称和描述预加载到系统提示词中。这种轻量化方式意味着可以安装大量技能而几乎不占用上下文空间，模型只需知道每个技能的存在以及何时该使用它；
• 第二层（指令主体）：当用户请求与某技能的描述匹配时，模型再通过shell命令从文件系统中读取技能说明文件的主体部分（Markdown格式的Instructions），其中详细给出了工作流、最佳实践与使用指导，此时才进入上下文；
• 第三层（关联文件）：如果技能复杂度很高、内容无法全部放入单个说明文件（毕竟上下文长度有限），可以在技能目录中捆绑额外文件，并在说明文件中按名称引用，模型只在需要时才读取。

以一个让模型具备PDF文档理解与编辑能力的技能为例，其说明文件结构大致如下（通用示意）：

---
name: pdf-assistant
description: 理解、生成与编辑PDF文档，适用于文档解析、内容提取、表单填写等任务
---
# 使用说明
## 工作流
1. 先检查输入文档的格式与页数
2. 按字段映射规范抽取关键信息
3. 按输出模板组织生成结果
## 关联文件
- 表单填写的详细指引见 forms.md
- 字段映射规范见 reference.md

通过把“填写表单”这类低频指令拆分到独立文件 forms.md，核心说明文件始终保持精简，模型仅在真正需要填表时才加载这部分内容。这种“按需加载”的设计，是技能机制在上下文经济性上的核心优势。

4.3 运行依赖与部署形态

• 工具调用：通常需要独立的服务端常驻运行，涉及进程管理、网络通信、身份鉴权与接口契约维护，部署和运维复杂度相对更高；
• 技能机制：本质是文件系统上的静态资源包，不需要额外的常驻服务。模型直接读取文件、执行随包携带的脚本即可，部署动作可以简化为“把文件夹放到约定位置”，接入门槛更低。

4.4 执行边界与安全模型

• 工具调用：能力边界由服务端显式定义，敏感操作天然收口在服务端，便于做细粒度权限控制、限流与操作审计，安全模型相对清晰；
• 技能机制：把指令与脚本交给模型自主读取和执行，灵活度高，但对运行环境提出了更高要求——需要沙箱隔离、文件系统权限管控，并对技能包内的脚本建立准入审核流程，否则存在越权读写、脚本滥用等风险。

4.5 开发与维护成本

• 开发一个工具：相当于实现一个符合协议的服务并定义参数契约，偏向传统接口开发，适合稳定、高复用的原子能力，契约测试与版本化管理手段成熟；
• 开发一个技能：主要是编写说明文档、整理脚本与模板，门槛更低、迭代更快，但质量高度依赖文档写作水平——指令写得含糊，模型执行就会漂移。它更适合沉淀组织内部的流程性知识。

4.6 确定性与灵活性

工具调用路径相对确定：结构化参数、显式返回，适合对结果确定性要求高的操作；技能机制给模型留了更大的自主空间，在文档撰写、数据分析等开放式任务上表现更好，但行为一致性更依赖指令质量与示例完备度。

五、关键差异对比表

对比维度	技能机制（方案A）	工具调用机制（方案B）
能力封装形态	工作流+脚本+模板的复杂能力包	原子化的离散外部操作
上下文占用	渐进式加载，初始仅注入名称与描述	工具声明通常一次性全量注入
运行依赖	文件系统即可，无需常驻服务	需要工具服务端/网关持续运行
接入方式	编写文件夹、说明文档与脚本	实现服务端、定义参数契约
安全治理	依赖沙箱隔离与脚本准入审核	服务端鉴权、限流、审计更易收口
适用任务	流程性、方法论型的复杂任务	边界清晰的操作型任务
维护重点	指令文档质量与脚本安全	接口契约稳定性与服务可用性

六、典型场景选择

结合上述差异，可以从任务性质出发做场景匹配：

• 让模型按企业品牌规范生成文档、按内部流程完成数据分析：属于流程性任务，技能机制更合适，规范与模板可直接沉淀为技能包；
• 查询订单、写入数据库、调用内部系统接口：属于明确的操作型任务，工具调用更合适，权限与审计更容易收口；
• 多步骤、有最佳实践的复杂任务（如批量处理PDF文档）：可用技能承载流程，技能内部再调用具体工具完成原子操作；
• 需要安装大量领域能力且担心上下文膨胀：技能机制的轻量注册与按需加载优势明显；
• 高并发生产系统的结构化操作：工具调用链路更确定，配合服务端治理能力更稳。

七、选型建议

不做绝对化推荐，给出条件化判断：

1. 扩展点是“外部系统操作”时，优先工具调用：凡是能抽象为稳定接口的能力，走工具协议可以获得更好的确定性与治理能力；
2. 扩展点是“任务方法论与组织流程”时，优先技能机制：凡是难以参数化、主要靠经验步骤和规范约束的任务，用技能沉淀更自然；
3. 两者不是互斥关系：成熟架构往往是“技能编排流程、工具执行动作”的分层组合——技能作为上层流程知识，工具作为底层执行接口；
4. 团队运维能力有限、希望能力边界强可控：可优先考虑工具调用为主、少量技能为辅；
5. 需要快速试错、持续沉淀内部知识：可优先引入技能机制，把已有文档资产转化为技能包。

选型前建议先盘点所用大模型平台的既有能力。以百度智能云等国内大模型服务平台为例，其普遍提供函数调用、知识库检索、插件与智能体编排等扩展组件，能复用平台能力就不必重复自建。

八、迁移与使用注意事项

如果涉及两种机制之间的切换或混用，需要提前评估：

• 从工具调用迁移到技能：需要把参数契约改写为指令文档，并接受模型执行的不确定性；重要操作建议在技能自带脚本中内置输入校验与失败回退逻辑；
• 从技能迁移到工具：需要把隐性流程显式化为接口，涉及任务拆分与状态管理改造，改造量与流程复杂度成正比；
• 混合使用时：技能脚本访问外部系统同样应走统一的鉴权通道，避免绕过工具层的安全审计形成旁路；
• 技能包治理：建议做版本管理；描述字段写清触发条件，避免误触发；关联文件遵循最小化原则，防止挤占上下文窗口；定期评审随包脚本的安全性；
• 兼容性风险：切换机制前，先在小流量环境验证模型对新能力说明的理解一致性，再逐步放量。

九、总结

技能机制与工具调用机制，本质都是大模型的外挂式能力扩展：前者以文件夹形态封装“方法论”，靠渐进式披露换取上下文经济性和复杂能力表达；后者以协议形态封装“原子操作”，靠服务端收口换取确定性和治理能力。二者的差异不来自目标不同，而来自封装形态与加载策略的技术取舍。决策时只需回答一个问题：你要扩展的是一次“操作”，还是一套“做法”——前者交给工具，后者交给技能，而最优解往往是两者的分层组合。