简介：在模型调用外部工具、数据源与业务流程时，Function Calling、MCP与Agent Skill常被误认为并列方案，实际上它们分属不同架构层级。本文从选型视角拆解三者的定位、层级依赖与适配条件，帮助读者判断在什么阶段引入哪一层能力，以及如何评估、验证和落地整套外部调用体系。
在构建基于大模型的应用系统时，很多人都会遇到一个共性问题：模型需要调用外部函数、访问数据源、执行工具链，但面对Function Calling、MCP、Agent Skill等概念，往往容易把它们理解为不同厂商或不同时期推出的平行方案。这种理解会导致架构设计时出现误判，例如认为只要选择其中一种即可，或者在系统演进时无法判断何时该引入更上层的抽象能力。
本文要解决的核心选型问题是：在一个需要让模型与外部工具、数据、流程协作的系统中，如何理解Function Calling、MCP与Agent Skill的层级关系，以及在不同业务阶段和技术条件下，应该如何评估、引入和验证这些能力。这不是简单的“哪个更好”的比较，而是判断“当前系统处于哪一层问题、需要哪一类抽象、应该优先建设什么能力”。
从时间线来看，Function Calling出现得最早。当时需要解决的核心问题是模型只会生成文本，无法触发外部调用。Function Calling解决的是调用协议问题：模型输出结构化信息，告诉程序应该调用哪个函数、传什么参数。它回答的是“模型怎么表达一次调用”。
随着工具数量增多，新的问题出现了。不同系统、不同服务的接口定义各不相同，每接入一个工具都要重新适配。MCP要解决的是工具标准化问题：把数据库、API、文件系统等外部能力封装成统一的服务描述方式，让模型和程序可以用一致的方式发现和调用这些能力。它回答的是“工具怎么被模型和系统发现、描述和调用”。
再往上，当工具已经可用，但完成一项任务需要多个步骤、多类工具、特定顺序和判断条件时，仅仅有调用能力和标准化工具还不够。Agent Skill要解决的是流程封装问题：把使用工具完成任务的知识、执行步骤、判断规则、脚本和模板打包成一个可复用模块。它回答的是“用这些工具按什么流程完成任务”。
三者解决的是不同层次的问题，因此不是竞争关系，而是逐层依赖的架构关系。
选型的第一步不是比较技术本身，而是拆解当前系统处在什么阶段、面临什么核心矛盾。
如果目标是让模型能触发一次明确的函数调用，例如查询订单状态、读取一条记录，那么当前处于调用协议层问题。此时需要关注的是模型输出结构化调用的稳定性、参数提取的准确性、调用失败时的重试与纠错能力。
如果目标是让模型能访问多个异构工具，并且希望这些工具可以被多个应用复用，那么当前处于工具标准化层问题。此时需要关注的是工具描述的一致性、发现机制、权限控制、版本管理以及跨系统复用能力。
如果目标是让模型能完成一个包含多个步骤的复杂任务，例如一次数据处理流程、一次故障诊断流程、一次多系统协同操作，那么当前处于流程封装层问题。此时需要关注的是步骤编排、条件分支、失败补偿、人工介入节点以及模块的可复用性和可维护性。
工具数量是判断是否需要引入标准化层的关键指标。如果系统中只有一到三个工具，直接基于Function Calling进行适配的开发成本是可以接受的。但当工具数量增长到几十个甚至更多，并且工具由不同团队维护时，没有统一的标准化描述会导致每次接入都需要定制适配，开发成本和维护成本会快速上升。此时应优先考虑引入MCP这类工具标准化层。
如果模型调用工具后，业务逻辑主要由程序自身控制，模型只负责发起调用，那么流程封装层的价值有限。但如果存在多个任务都需要按照相似步骤执行，例如不同场景下的数据查询后处理、不同告警类型的分级处理流程，那么将这些步骤封装成可复用的Skill可以显著降低重复开发成本，并保证执行标准的一致性。
Function Calling的接入和调试相对直接，对团队要求集中在模型输出解析和异常处理上。MCP要求团队具备服务化设计能力，能够抽象工具描述、处理服务注册与发现、管理权限边界。Agent Skill则进一步要求团队具备流程设计和知识工程能力，需要把专家经验转化为可执行的步骤和规则。团队的技术栈和人员配置会直接影响引入某一层能力的可行性和推进速度。
Function Calling是模型与外部函数之间的通信约定。程序向模型声明可用的函数列表，包括函数名、参数结构和描述；模型根据用户输入判断是否需要调用函数，并输出一个结构化的调用请求，包含函数名和参数值；程序执行对应函数后，把结果返回给模型，由模型生成最终回复。
这一层解决的核心问题是“模型如何表达一次调用意图”。它不关心函数内部逻辑，也不关心函数运行在哪个系统，只关心调用的表达格式和参数传递方式。
MCP建立在调用协议之上，解决“工具如何被发现、描述和复用”。它把外部能力封装成标准化的服务接口，统一描述工具的输入、输出、调用方式和权限要求。模型端和程序端只需要对接这一套标准，就可以访问所有接入的工具，而不需要为每个工具单独适配。
这一层的核心价值在于降低多工具接入的适配成本，提高工具的可发现性和可管理性。它解决的不是“能不能调”，而是“能不能以统一方式调”。
Agent Skill建立在工具标准化和调用协议之上，解决“用工具完成任务时应该遵循什么流程”。一个Skill通常包含任务目标、执行步骤、需要调用的工具、每步的判断条件、异常处理逻辑以及必要的脚本或模板。模型加载一个Skill后，不再只是知道有哪些工具可用，而是知道面对某类任务时应该按什么路径使用这些工具。
这一层的核心价值在于把专家知识、操作标准和执行流程沉淀为可复用模块，降低复杂任务对模型即时推理能力的依赖，提升执行的一致性和可控性。
评估Function Calling能力时，需要关注模型输出结构化调用请求的准确性、是否支持一次调用多个函数、参数类型支持是否完整、调用失败时能否基于错误信息进行修正。这些能力直接影响调用成功率。
评估MCP能力时，需要关注工具描述规范的完整程度、是否支持工具的动态注册与发现、工具元信息的表达能力、调用权限的细粒度控制等。工具描述越完整，模型越能准确判断该调用哪个工具以及如何传参。
评估Agent Skill能力时，需要关注流程定义的表达能力、步骤间是否支持条件分支和循环、是否支持失败重试和人工介入、Skill之间的依赖管理、版本的更新与回滚机制等。这些决定了复杂流程能否被准确描述和可靠执行。
调用协议层的性能关注点是模型生成调用请求的延迟和解析失败的频率。工具标准化层需要额外关注服务发现和路由的延迟、工具描述加载的稳定性。流程封装层则需要关注整个流程的执行时长、步骤间状态传递的可靠性、失败后的恢复能力。
对于高频、低延迟要求的场景，每一层引入的额外开销都需要评估。流程封装层如果设计不当，可能引入不必要的步骤等待或重复调用，影响整体响应速度。
三层都需要关注权限控制，但侧重点不同。Function Calling层面需要确保模型不能触发未授权的函数调用，参数不能被注入非法内容。MCP层面需要确保工具只能被经过认证的调用方访问，工具之间的数据不能串通，敏感操作的调用需要审计日志。Agent Skill层面需要确保流程中嵌入的脚本和模板不会引入安全漏洞，人工介入节点不能被绕过，流程执行中的敏感数据需要脱敏和加密。
Function Calling的运维工作主要集中在监控调用成功率、解析失败率、参数错误类型，以及模型升级后对调用稳定性的回归测试。
MCP的运维复杂度显著提升，需要管理工具服务的生命周期、版本兼容性、服务降级策略，以及工具描述变更后的影响范围评估。工具数量越多，治理难度越大。
Agent Skill的运维焦点在于流程版本管理、执行状态监控、异常节点定位和回滚。当一个Skill包含多个步骤并依赖多个工具时，定位问题需要跨越多个层次进行排查，对日志关联和链路追踪能力要求较高。
Function Calling的成本主要来自模型生成调用请求的token消耗和调用失败后的重试消耗。MCP的成本包含服务化改造的开发成本、服务运行的基础资源成本、治理平台的运维成本。Agent Skill的成本则更多地体现在流程设计、专家知识转化、脚本维护和长期迭代的人力成本上。
在选型时需要特别关注长期成本而非一次性接入成本。工具标准化层和流程封装层的前期投入较高，但会随着工具数量和任务复用频次的增加而摊薄。
Function Calling层面需要评估模型版本升级后调用格式是否有变化，是否需要对解析逻辑做适配。MCP层面需要评估新增工具时是否需要修改调用端逻辑，工具描述变更后已有调用是否受影响。Agent Skill层面需要评估新流程能否复用已有Skill，不同Skill之间能否组合使用。
如果业务处于早期验证阶段，工具数量在三到五个以内，任务以单次调用为主，团队希望快速跑通端到端链路，那么优先选择基于Function Calling直接适配。此阶段引入MCP和Agent Skill会带来不必要的抽象成本和开发工作量。
关键判断指标：接入一个工具的开发时间是否显著小于搭建标准化层的时间；工具数量在可预见的短期内是否会快速增长；调用失败的主要瓶颈是否集中在协议层。
当系统已经积累了较多工具，或者多个团队都在独立接入模型工具时，标准化层的价值就变得突出。此时应优先建设MCP层，统一工具描述和接入规范。否则会出现每个团队各自适配、接口风格不一致、工具无法跨团队复用的问题。
关键判断指标：工具数量是否达到两位数；不同团队是否需要使用同一批工具；工具提供方和调用方是否属于不同系统边界；是否有独立演进工具接口的需求。
如果系统中存在一类任务需要多步执行，且这些任务会重复出现，例如定期报表生成流程、告警分诊流程、多系统数据同步流程，那么将这类任务的执行知识封装成Agent Skill是合理选择。模型加载Skill后，可以按照预设流程调用工具，减少每次任务都从零推理的不确定性。
关键判断指标：是否存在高频重复的复杂任务；执行步骤是否有明确的标准和顺序；是否需要对执行结果进行一致性管控；是否希望降低对模型即时规划能力的依赖。
如果系统已经明确会向多工具、多流程、多团队的方向演进，即使当前工具数量不多，也建议在早期就预留标准化层和流程封装层的设计空间。例如先在调用协议层与工具标准化层之间建立适配边界，避免后续大规模重构。
| 评估维度 | Function Calling | MCP | Agent Skill |
|---|---|---|---|
| 核心解决问题 | 模型如何表达一次函数调用 | 工具如何被统一描述和发现 | 复杂任务按什么流程执行 |
| 架构层级 | 底层调用协议 | 中间工具标准化 | 顶层流程封装 |
| 适用工具数量 | 少量即可 | 中等到大量 | 与工具数量不直接相关，取决于任务复杂度 |
| 主要受益场景 | 快速接入、单次调用 | 多工具治理、跨系统复用 | 复杂任务、重复执行、流程标准化 |
| 前期投入 | 较低 | 中等到高 | 中等到高 |
| 长期维护重点 | 模型输出解析与异常处理 | 工具服务治理与版本管理 | 流程版本与执行监控 |
| 主要风险 | 工具增多后适配成本高 | 前期抽象过度、服务治理复杂 | 流程设计不合理导致执行不可控 |
| 依赖关系 | 无 | 依赖Function Calling | 依赖MCP和Function Calling |
建议按照以下路径逐步判断：
第一步：明确当前最痛的层次问题是什么。 是模型调不通，还是工具太多管理不过来，还是复杂任务执行不稳定。不要跳过当前层次去建设上层能力。
第二步：评估工具数量和增长预期。 如果工具数量少且增长平缓，可以暂缓标准化层建设；如果工具已经很多或增长很快，标准化层的优先级应提高。
第三步：评估任务复杂度和复用频率。 如果存在高频重复的复杂任务，且执行步骤可以被标准化，流程封装层的价值会逐步显现。
第四步：结合团队能力和运维资源判断推进节奏。 不要同时建设三层，优先解决最痛的层次，但要在架构上为上层预留演进空间。
第五步：小范围验证。 每引入一层新能力，先选择一个有代表性的场景做试点，评估接入成本、实际收益和潜在问题，再决定是否全面推广。
选择两到三个有代表性的函数进行接入测试。验证指标包括：模型生成调用请求的成功率、参数提取准确率、无效调用比例、错误信息驱动重试的成功率。需要特别关注模型版本升级前后的调用稳定性对比。
先选取风格差异较大的几个工具进行标准化封装，验证统一描述是否能覆盖这些工具的调用需求。测试新增一个工具时调用端是否需要改动。评估工具描述的维护成本和版本变更的影响范围。同时验证权限控制和审计日志是否满足安全要求。
选择一个执行步骤明确、有标准操作流程的任务进行Skill封装。验证模型加载该Skill后是否能按照预期步骤执行，步骤跳转是否符合条件判断，异常情况下是否能正确触发重试或人工介入。记录整个流程的执行时长和失败节点分布。
三层之间要有清晰的接口边界，避免把流程封装逻辑写入工具描述中，也避免把工具标准化逻辑分散到各个调用代码中。边界不清会导致后续任何一层的变更都会牵连其他层，增加维护成本。
不是所有系统都需要三层齐全。对于工具少、任务简单的场景，直接基于Function Calling开发是合理选择。过早引入标准化层和流程封装层会拖慢开发速度，且前期抽象可能与实际需求脱节。
无论当前引入到哪一层，权限控制和审计日志都应从一开始就纳入设计。尤其是流程封装层中嵌入的脚本如果拥有较高权限，需要特别关注脚本的来源、版本和变更记录。
三层叠加后，一次完整调用可能跨越模型、标准化服务层、多个工具和流程节点。需要建立统一的日志关联和链路追踪机制，否则故障排查会变得困难。建议在每层都输出结构化的调用上下文信息。
即使当前只使用Function Calling，在代码结构上也建议把函数声明、调用解析和执行逻辑分层组织，方便后续引入工具标准化层时平滑迁移。
Function Calling、MCP与Agent Skill不是三个并列的竞争方案，而是从底到顶的三层架构。Function Calling解决模型怎么表达调用，MCP解决工具怎么被统一管理，Agent Skill解决复杂任务怎么按流程执行。选型的核心不是比较三者优劣，而是判断当前系统最痛的层次问题是什么，并在此基础上评估工具数量、任务复杂度、团队能力和长期演进需求。
如果业务处于早期验证阶段，优先做好调用协议层；如果工具开始增多并涉及跨团队复用，及时引入工具标准化层；如果出现高频重复的复杂任务，再考虑用流程封装层沉淀执行知识。每一层的引入都应遵循“先解决当前最痛问题、小范围验证、再逐步推广”的原则，避免过度设计和盲目跟风。