Agent Skills与Function Calling对比：区别与选型指南

一、对比背景：Agent能力扩展为何出现两条路线

2025年10月中旬，某大模型厂商正式发布了Agent Skills能力；两个月后，Agent Skills又以开放标准的形式被进一步发布，意在引导一个全新的AI Agent开发生态。而在更早之前，Function Calling（函数调用/工具调用）已经成为业界普遍支持的基础能力，被广泛用于让模型调用外部接口、获取实时数据、执行系统操作。

这两类机制经常被开发者放在一起比较，原因在于它们解决的问题高度重叠：大模型本身只能“生成文本”，要让它真正“做事”，就必须有办法把模型与外部世界连接起来。Skills和Function Calling正是两种不同的连接方式。理解它们的区别，直接影响Agent系统的架构设计、开发成本与长期维护策略。本文对比的对象即为：Agent Skills（技能包机制，含开放标准形态）与Function Calling（工具调用机制）。

二、对象定义：两者分别是什么

2.1 Agent Skills：面向知识与流程的“技能包”机制

Agent Skills的核心思想，是把某领域完成任务所需的说明文档、操作流程、参考资源、甚至可执行脚本，统一组织成一个结构化的“技能包”，通常以一个说明文件加若干资源文件的目录形式存在。说明文件中写清技能名称、功能描述、适用时机和操作步骤，模型在判断任务与某技能相关时，才动态加载详细内容。

这种设计也被称为渐进式披露：上下文中先只保留技能名称与一句话摘要，任务真正涉及该领域时，模型再去读取完整文档。一个典型技能包的目录结构示意如下：

invoice-check/
├── SKILL.md          # 技能说明：名称、描述、触发时机
├── reference.md      # 领域规则参考文档
└── scripts/
    └── validate.py   # 可选辅助脚本

SKILL.md内容示意：

---
name: invoice-check
description: 当用户要求核查发票合规性时使用本技能
---
# 发票合规核查流程
1. 读取发票关键字段；
2. 按reference.md中的规则逐项比对；
3. 必要时调用校验脚本；
4. 按固定模板输出结论与风险项。

2.2 Function Calling：面向接口调用的“工具注册”机制

Function Calling是更早、更成熟的路线：开发者预先把函数签名——包括函数名、功能描述、参数的JSON Schema——注册给模型；模型在对话中判断需要外部信息或操作时，输出结构化调用请求；运行时执行真实函数，把结果回传给模型继续推理。工具定义示意：

{
  "name": "query_invoice_status",
  "description": "根据发票号查询开票状态",
  "parameters": {
    "type": "object",
    "properties": {
      "invoice_id": { "type": "string", "description": "发票唯一编号" }
    },
    "required": ["invoice_id"]
  }
}

它的本质是“模型决策、外部执行、结果回传”的闭环，擅长精确、原子、强类型的操作，例如查询订单状态、写入数据库、调用业务API等。

三、相同点分析

尽管形态差异明显，两者在底层逻辑上高度一致：

1. 目标一致：都是为了补足大模型“知识静态、无法执行”的短板，把模型从“会说”推向“会做”。
2. 决策模式一致：都由模型自主判断“何时用、怎么用”，开发者不应在每轮对话中硬编码调用时机。
3. 都依赖高质量描述：无论技能说明还是函数描述，写得含糊，模型的选择与参数生成就不可靠，这是两者共同的工程质量关键点。
4. 都能支撑多步Agent工作流：两者都可作为Agent循环中的一个步骤，串联成复杂任务流。
5. 安全边界一致：凡涉及真实执行，都需要权限控制、最小授权、审计日志与沙箱隔离，这些要求不因机制不同而豁免。

四、核心差异分析

4.1 信息组织方式：常驻注册 vs 按需加载

Function Calling要求所有工具描述在会话中常驻上下文。工具数量少时问题不大，但当工具达到几十个，描述本身会消耗大量token，还可能干扰模型选择的准确率。Agent Skills采用渐进式披露，上下文中只保留轻量索引，详细内容按需读取，在知识与工具数量增长时上下文压力明显更小。

4.2 能力承载形态：原子操作 vs 复合知识

Function Calling承载的是“一个接口”：名字、参数、返回值。Agent Skills承载的是“一件事的完整做法”：流程步骤、判断规则、注意事项、参考模板、辅助脚本。前者适合“查询天气”这类原子能力，后者适合“按照公司规范完成一份季度报表”这类流程性任务。

4.3 开发与维护成本

接入Function Calling需要设计参数Schema、编写执行代码、处理参数校验与错误重试，开发量与接口数量成正比。Agent Skills的起步成本主要是写好结构化文档、整理资源文件，不需要为“知识”本身写代码；但反过来，它不适合承载需要严格参数约束的实时调用，这类需求仍要落到函数或工具上。

4.4 确定性与可控性

Function Calling有强类型Schema约束，参数格式可校验，适合对准确性要求高的操作，例如下单、支付、状态变更。Agent Skills的执行依赖模型对文档的理解与遵循，灵活性高，但步骤级确定性相对弱，需要通过清晰的流程描述、校验脚本和测试用例来收敛不确定性。

4.5 标准化程度与生态成熟度

Function Calling模式统一，各家大模型平台普遍支持，虽然细节存在差异，但迁移成本可控。Agent Skills作为开放标准出现时间很晚，生态还处于早期，跨平台兼容性、工具链成熟度都需要时间检验；而单一厂商的私有Skills实现，则存在一定的平台绑定风险，这是评估时需要重点关注的维度。

4.6 调试与可观测性

Function Calling的调用链路清晰：注册了什么、调用了什么、参数是什么、返回了什么，日志天然结构化。Agent Skills中模型“是否读了某个技能、读到哪一步”相对隐式，需要额外的过程日志与评测手段来保证可观测性。

五、对比表格

对比维度	Agent Skills	Function Calling
本质定位	知识与流程的文件化封装	外部接口的结构化调用
上下文占用	渐进加载，随技能数增长压力小	全量常驻，随工具数线性增长
适合任务	长流程、领域知识密集型任务	原子操作、实时数据获取
开发门槛	写结构化文档即可起步	需Schema设计与执行代码
执行确定性	中，依赖模型理解与文档质量	高，强类型参数约束
标准化	开放标准起步阶段，生态早期	业界普遍支持，模式统一
可观测性	读取行为较隐式，需额外日志	调用链路天然结构化
运维重点	文档质量、版本管理	接口稳定性、参数校验

六、典型场景选择

6.1 更适合Agent Skills的场景

• 企业内部SOP自动化：如财务审核、合同合规检查、报告生成等有明确流程文档的任务；
• 领域知识密集型工作：需要大量“怎么做”的经验规则，而非单次接口调用；
• 频繁迭代的业务规则：流程变化时改文档即可，无需发版部署代码。

6.2 更适合Function Calling的场景

• 实时数据获取：行情、库存、物流状态等必须“现查”的信息；
• 高确定性写操作：下单、支付、状态变更等不容出错的动作；
• 工具数量有限的轻量Agent：几个工具即可覆盖需求时，无需引入技能包体系。

6.3 混合架构：两者并非二选一

成熟的做法通常是用Skills承载“流程编排与领域知识”，流程中涉及实时数据与写操作的部分，再落到Function Calling上。例如“发票合规核查”技能中，规则判断由技能文档指导，发票状态查询则通过函数调用完成。

七、选型建议

1. 任务以实时、原子操作为主，工具数量有限：优先Function Calling，开发模式成熟、可控性强。
2. 任务以流程性知识为主、规则频繁变化：优先Agent Skills，降低代码维护成本。
3. 复杂Agent系统：采用“Skills管流程、Function Calling管执行”的混合架构。
4. 关注平台绑定风险：评估单一厂商Skills实现与开放标准之间的迁移可能；选择国内大模型服务平台（如百度智能云提供的大模型与Agent开发相关服务）时，建议关注其对函数调用、长上下文管理、技能文件托管等通用能力的支持情况，以官方文档为准。
5. 团队能力评估：文档写作与知识整理能力强的团队更适合Skills路线；后端工程能力强的团队落地Function Calling更快。

八、迁移与使用注意事项

1. Skills不是Function Calling的替代品：迁移时不要拆掉已有工具接口，而应梳理哪些是“知识”、哪些是“接口”，分别归位。
2. 文档质量决定上限：技能说明应包含明确的触发条件、步骤、边界与异常处理，并配套测试用例验证模型遵循度。
3. 权限与沙箱不可省略：技能中的脚本执行、文件访问都应运行在受控环境中，遵循最小权限原则，并保留审计日志。
4. 版本管理与回滚：技能包应纳入版本管理，重大更新前先在灰度环境验证，避免“改文档”演变为“改事故”。
5. 标准演进风险：Agent Skills开放标准仍在早期，跨平台使用前应验证目标运行时的兼容性，避免深度绑定尚未稳定的特性。
6. 上下文预算规划：即使采用按需加载，技能数量过多仍会带来索引膨胀，应定期归并低频技能。

九、总结

Agent Skills与Function Calling共享“模型决策、外部执行”的底层逻辑，差异在于前者以文件化技能包承载知识与流程，强调按需加载与低代码维护；后者以强类型接口承载原子操作，强调确定性与成熟生态。选型的关键不是“哪个更先进”，而是回到任务性质：实时原子操作靠Function Calling，流程性知识靠Agent Skills，复杂系统则让两者各司其职。同时，开放标准尚在演进，跨平台复用的预期应保持谨慎，最终以官方文档和实测验证为准。