简介：让智能体真正“会做事”，离不开外部能力注入，但工具调用、协议化接入与技能包三类机制的定位常被混淆。本文从注入内容、上下文成本、输出确定性、接入与运维成本、安全治理等维度系统对比三者异同，详解技能包的标准目录结构与编写要点，并给出典型场景选型建议与迁移注意事项，帮助开发者做出贴合自身业务的方案选择。
大模型本身擅长理解与生成文本，但它并不会“动手”：查数据库、调内部接口、按企业规范产出文档，这些动作都必须通过外部能力注入来实现。随着智能体技术演进，业界形成了三类主流的能力扩展机制：
三者经常被混为一谈，导致团队在实践中出现一系列典型问题：工具列表越注册越多，上下文被塞满后模型选择准确率下降；本该沉淀为流程规范的“隐性知识”被硬写成一个个零散工具；接入方式随意，权限边界模糊。要解决这些问题，前提是把三类机制的定位、差异和适用边界讲清楚。本文即围绕这一目标展开。
工具调用是最基础的能力扩展方式。开发者在应用侧预先定义一组函数，包括名称、功能描述和参数结构，模型在对话过程中根据用户意图判断是否调用、调用哪个、传什么参数；应用执行函数后把结果回传给模型继续推理。它解决的核心问题是：让模型从“只能说”变成“能做事”。
当需要接入的外部系统越来越多时，逐个开发工具的重复劳动和接口不一致问题开始凸显。为此，业界出现了标准化的接入协议思路：外部系统按统一协议暴露自己的能力清单与调用方式，宿主应用实现协议客户端，双方通过统一的消息格式完成能力发现、调用与结果回传。它相当于在“模型—应用—外部系统”之间建立了标准插座，一次接入即可复用一批能力。
技能包代表另一种思路：不新增调用通道，而是向模型注入“程序性知识”。一个技能包通常是一个结构化目录，包含入口说明文件、参考文档、可执行脚本和静态资源。模型平时只看到极简的技能摘要，判断当前任务命中后再展开读取具体内容。它解决的核心问题是：复杂任务中“怎么一步步做、按什么规范做、有哪些坑”这类知识，无法用单个函数定义表达清楚。
在展开差异之前，先明确三者的共性，避免非此即彼的误解。
这是三者最本质的分野。工具注入的是“动作通道”——查询、创建、发送这类原子操作；协议化接入注入的是“标准化能力集合”——一批可被发现的外部系统能力；技能包注入的是“程序性知识”——完成某类任务的流程、规范、约束和经验。可以用一个类比：工具是给模型一件工具，协议接入是给模型一间工具房，技能包是给模型一本岗位操作手册。
工具定义通常常驻上下文。注册十个工具问题不大，注册上百个后，仅描述文本就会占据大量空间，还会干扰模型的选择判断。协议化接入支持能力的动态发现，缓解了注册管理压力，但被列出的能力清单依然要占上下文。技能包采用分层渐进的加载策略：常驻的只有“名称+触发描述”这类极轻量元信息，命中后才展开正文，正文放不下的细节再放到参考文档中二次按需读取。在上下文预算紧张、能力数量庞大的场景下，这种按需加载模式的优势非常明显。
工具与协议能力的执行路径由模型现场决定，灵活但结果不完全确定。技能包可以内置脚本，把高频、格式敏感、容易出错的环节固化成代码——例如格式转换、字段校验、脚手架生成——模型只负责判断与调用，执行结果由代码保证，确定性显著提升。凡是对输出格式一致性要求高的任务，这一差异都值得重点考量。
工具的开发门槛最低，写一个带清晰描述的函数即可；但能力数量增长后，逐个开发与维护的边际成本会持续上升。协议化接入需要一次性实现协议客户端并治理协议服务，前期投入更高，之后接入新系统主要是服务侧的适配工作，规模化复用性好。技能包的开发本质上是文档与资源的组织工作，几乎不需要改代码，但效果与写作质量强相关，隐性的“写作与评审成本”不应低估。
工具的权限粒度容易做到函数级，按工具授予权限即可。协议化接入需要重点治理暴露面：一次接入可能带来一整批能力，鉴权、审计、数据隔离必须在协议服务层统一规划，避免“一次接入、全量暴露”。技能包的主要风险点是脚本执行权限与参考资料的可靠性——脚本应有明确的安全边界与白名单机制，文档内容则需要评审，避免错误规范被模型不加甄别地执行。
工具随应用代码一起发版，演进节奏与主程序绑定。协议服务可以独立升级，宿主应用无需频繁变更。技能包更像一个文档仓库，可以独立迭代、评审、回滚，甚至由领域专家而非工程师主导维护，这让业务知识的更新周期大幅缩短。
| 对比维度 | 工具调用 | 协议化外部接入 | 技能包（Skill） |
|---|---|---|---|
| 注入内容 | 原子动作通道 | 标准化能力集合 | 程序性知识+脚本+资源 |
| 上下文成本 | 常驻，随数量线性增长 | 可动态发现，清单仍占空间 | 元信息常驻，内容按需加载 |
| 开发成本 | 单个低，规模化后上升 | 前期高，后期复用性好 | 门槛低，依赖写作质量 |
| 输出确定性 | 中 | 中 | 高（可内置脚本固化） |
| 安全重点 | 函数级授权 | 服务暴露面与统一鉴权 | 脚本权限与内容评审 |
| 运维演进 | 随应用发版 | 协议服务独立升级 | 独立迭代，业务可主导 |
| 适用规模 | 少量高频定制动作 | 大量异构外部系统 | 复杂流程与领域规范 |
| 典型局限 | 工具膨胀、选择干扰 | 治理复杂度 | 触发准确率依赖描述 |
技能包针对的是一类长期被忽视的问题：很多任务的关键不在“调用某个接口”，而在“按什么顺序做、遵循什么规范、避开哪些坑”。这类知识散落在文档、老员工经验和历史代码里，写成工具表达不了，全塞进提示词又会撑爆上下文。技能包用“目录+分层加载”的方式，把这些知识结构化地组织起来，平时不占资源，用时随取随读。
业界常见的一种组织形式如下：
my-skill/├── SKILL.md # 入口说明文件：元信息 + 操作指引├── references/ # 参考文档：按需加载的深度资料├── scripts/ # 可执行脚本：确定性操作的代码└── assets/ # 静态资源：模板、样例文件等
SKILL.md 是整个技能包的入口，通常由两部分组成。头部是元信息区，用键值对声明技能名称与触发描述；正文是操作指引区，说明适用场景、前置条件、分步流程、约束禁忌和输出规范。一个通用示例：
---name: weekly-reportdescription: 当用户需要生成周度数据汇总或周报时使用，触发场景包括"周报""数据汇总""本周数据"。---# 周报生成技能## 适用场景需要基于业务数据生成结构化周报的场合。## 操作流程1. 先读取 references/fields.md，确认各字段统计口径；2. 运行 scripts/validate_data.py 校验输入数据完整性；3. 按 assets/template.md 的结构组织输出。## 约束- 缺失字段必须明确标注，禁止估算填充；- 输出前必须运行校验脚本，校验不通过不得生成报告。
写作上有三条经验值得遵循：其一，元信息中的 description 是模型判断“是否使用该技能”的主要依据，要写清触发场景与关键词，这是整个文件最重要的一段；其二，正文要像给新同事写交接文档，动词开头、步骤编号、把易错点写成显式禁令；其三，正文超过一定篇幅就应拆分到 references/，入口文件只保留主干流程，避免单次加载过重。
工具调用、协议化外部接入与技能包，分别对应“给模型通道”“给模型连接”“给模型知识”三个层次，核心差异在于注入内容的性质、上下文占用模式与确定性保障方式。选型的第一步不是比较谁更强，而是判断能力的性质：原子动作用工具、系统互联靠协议、流程规范沉淀为技能。三者组合使用、分层治理，才是复杂智能体应用走向稳定可维护的现实路径。