简介：在构建基于大语言模型的应用时，Function Call与Skills常被混为一谈。本文从能力调用机制与应用层能力封装两个层级切入，系统梳理二者在技术架构、状态管理、权限控制、适用场景及迁移成本上的核心差异，帮助开发者在工具调用与能力治理之间做出清晰选型。
在基于大语言模型构建应用系统的过程中，开发者经常面临一个困惑：模型已经具备Function Call能力，为什么还需要Skills这一层抽象？二者看起来都在“让模型调用外部工具”，但实际解决的问题并不相同。如果只是在做单次工具调用，Function Call已经足够；而一旦涉及多工具协同、权限分级、版本管理、跨团队复用，就需要引入更高层级的Skills抽象。理解二者差异，是设计可维护、可扩展的LLM应用架构的前提。
从技术分层视角看，Function Call属于模型侧的原生能力调用机制，它解决的是“模型如何输出符合特定结构的参数”这一问题；Skills则属于应用层或平台层的工具能力管理抽象，它解决的是“工具如何被统一封装、治理和编排”的问题。前者面向单次交互的准确性，后者面向系统级能力资产的长期运营。
Function Call并非模型真正学会了执行函数，而是模型在推理阶段生成一段符合JSON Schema的文本。工程落地上，这本质是一个结构化生成任务。模型输出的不是函数的执行结果，而是对函数名与参数的意图表达，真正的执行由外部系统完成。
这一机制的核心挑战在于：如何让模型稳定地输出合法JSON。早期实现依赖后处理解析，一旦模型生成多余逗号、缺失引号或字段名拼写错误，解析就会失败。现代主流做法是在解码阶段引入语法约束，提前构建JSON语法规则树，限制模型每一步只能生成合法token。例如当模型生成到unit字段值时，解码器强制其只能从celsius或fahrenheit对应的token序列中选择，从源头消除格式错误。
Function Call本身不携带会话状态。模型输出参数后，执行权转移给外部系统；执行结果如何回传、多轮对话中上下文如何延续，都需要开发者自行设计。实践中最大的痛点是执行失败后的重试策略与多轮对话的状态一致性。
例如用户输入“帮我订一张明天去北京的票”，模型调用book_ticket工具并输出参数{departure: "tomorrow", destination: "beijing"}。但此时缺少出发地信息，外部系统无法完成订票。系统需要决定：是立即返回追问、还是由模型再次发起补充参数的工具调用？如果采用重试，如何避免重复扣款等副作用？这些问题都指向Function Call的一个固有属性：它只负责“模型侧说了什么”，不负责“外部系统做了什么”。
Function Call适合单次、明确、无跨工具依赖的调用场景。它的优势在于协议简单、响应直接、与模型能力深度集成。但当工具数量增多、调用关系复杂化时，仅靠Function Call会让代码中散落大量工具定义与执行逻辑，难以维护。
Skills通常出现在应用层或平台层框架中，是对工具能力的二次封装。一个Skill可以包含多个Function Call、预置提示词、权限声明、版本信息以及调用策略。它不再是一个“模型能调用的函数”，而是一个“系统可管理的能力单元”。
这种抽象的动机来自真实工程需求：当团队拥有几十个甚至上百个工具时，直接暴露给模型不仅增加模型选择难度，也带来权限与安全的不可控。Skills通过分组、命名空间和调用策略，将底层Function Call组织成面向业务场景的能力集合。
Skills层引入两个关键能力：权限隔离与版本管理。权限方面，不同用户或不同会话可以被授予不同的Skill集合，底层工具调用因此受到边界约束。版本方面，Skill可以独立于模型更新，模型侧无需感知底层工具实现的变更。
举例而言，一个“订单查询”Skill可能内部封装了数据库查询、缓存读取、结果格式化三个Function Call。模型只需调用该Skill，而不需要知道底层用了哪些工具、查询了哪些数据表。当数据库迁移或缓存策略调整时，只需更新Skill内部实现，模型侧调用接口保持不变。
Skills的另一层价值在于工作流编排。单个Function Call无法表达“先查询订单，再根据订单状态决定是否发起退款”这类条件逻辑。Skills通过声明式或流程式定义，将多个工具调用组合成可复用的业务流程。这使得非模型层的业务逻辑可以被显式管理，而不是散落在提示词或模型推理的隐式行为中。
| 对比维度 | Function Call | Skills |
|---|---|---|
| 技术层级 | 模型侧原生能力 | 应用层/平台层封装 |
| 核心目标 | 生成合法结构化参数 | 统一管理工具能力 |
| 状态管理 | 无状态，需外部维护 | 可包含流程状态与上下文 |
| 权限控制 | 通常依赖外部实现 | 可在Skill层声明与管理 |
| 版本管理 | 与模型提示词耦合 | 可独立版本迭代 |
| 工具粒度 | 单个函数 | 多个函数与流程的组合 |
| 复用范围 | 单次对话内 | 跨会话、跨应用 |
| 失败处理 | 需外部自行设计重试 | 可在Skill内定义策略 |
优先使用Function Call的场景：工具数量少且固定；单次调用即可完成任务；需要最直接的模型集成方式；原型验证阶段。
优先使用Skills的场景：工具数量多且需要分组管理；存在跨工具的业务流程；需要权限分级或按用户开放不同能力；工具需要独立于模型迭代更新。
实际系统中二者往往是组合关系。模型通过Function Call输出调用意图，Skills层接收该意图并执行内部编排，最终将结果回传模型生成自然语言回复。Function Call是“模型如何表达”，Skills是“系统如何组织”。
从纯Function Call架构迁移到Skills架构时，需要关注以下问题：首先，现有工具的调用方式与返回格式需要被Skills层兼容，避免大规模重写；其次，权限模型需要重新设计，Function Call阶段通常没有细粒度权限概念，引入Skills后需明确不同角色的可用Skill范围；第三，调试链路变长，一次失败的调用可能涉及模型参数生成、Skills内部路由、底层工具执行三个环节，需要补充结构化日志与链路追踪能力。
同时要避免过度抽象。Skill并非越多越好，过细的粒度会增加维护成本，过粗的粒度则降低复用性。一般建议以业务能力边界为划分依据，而非以技术实现为划分依据。
Function Call解决的是“模型能否说清楚要调用什么”，Skills解决的是“系统能否管好可调用的能力”。前者是模型能力的基础接口，后者是工程治理的必然产物。理解二者不在同一层级，是避免将工具调用架构设计得过于扁平化或过于复杂化的关键。在系统从原型走向生产、从单一工具走向多工具协同的过程中，Function Call与Skills的分层设计会逐渐显现其长期价值。