一、对比背景：工具决定大模型的行动半径

即使是当今最先进的基础模型，在剥离外部工具之后，本质上仍然是一个强大的模式预测引擎：它能通过法律类考试、编写代码、创作诗歌，但其能力被严格限制在训练数据所构成的知识边界之内。模型自身无法感知训练数据之外的新信息，无法与外部系统交互，更无法采取行动影响现实世界。

工具正是为突破这一局限而生。在现代AI语境中，工具是可供大语言模型应用调用的外部函数或程序，核心作用可归结为两类：一是获取知识，通过访问结构化或非结构化数据源为模型补充信息；二是执行动作，代表用户完成调用外部接口、执行代码等具体操作。以看似简单的“天气预报”应用为例：要准确回答用户，模型必须借助工具获取训练数据中并不包含的实时信息，例如用户当前位置与当地实时天气；若涉及摄氏度转华氏度等换算，调用外部计算工具也比依赖模型自身的数学能力更可靠。可以说，工具扮演着智能体的“眼睛”和“手”，使其能够“感知”世界并“行动”。

随着智能体AI的兴起，工程上的关键问题已经从“要不要用工具”演变为“工具怎么接”。目前主流存在两条路径：

• 方案A：应用内自定义工具调用。 开发者在每次模型请求中自行声明工具清单，并自行完成工具的执行与结果回填；
• 方案B：基于模型上下文协议的协议化接入。 该协议由某头部AI研究机构于2024年11月推出，定位为模型与工具之间的开放互连标准，目标是把工具封装为标准化服务，统一其发现、调用与安全治理。

本文即围绕这两种方案展开系统对比，同时覆盖原始议题中的另一层对比：裸模型与工具增强智能体在能力上的本质差别。

二、对象定义

方案A：应用内自定义工具调用（直连模式）

在这种模式中，应用开发者在调用模型时，通过请求参数声明本轮可用的工具列表，每个工具包含名称、自然语言描述和参数结构定义。模型在推理过程中判断是否需要调用工具，输出结构化的调用意图（工具名+参数），由应用侧代码实际执行，再把执行结果拼回上下文，驱动模型继续推理。工具的注册、鉴权、执行、超时重试、错误处理与日志记录，全部由应用自行实现。

一个示意性的工具声明结构如下（仅为通用示例）：

{
  "tools": [
    {
      "name": "get_realtime_weather",
      "description": "查询指定城市的实时天气与温度",
      "parameters": {
        "type": "object",
        "properties": {
          "city": { "type": "string", "description": "城市名称" },
          "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
        },
        "required": ["city"]
      }
    }
  ]
}

方案B：基于模型上下文协议的协议化接入

这种模式把“工具提供方”从应用代码中剥离出来，形成典型的三层结构：

• 宿主应用：智能体的运行载体，负责对话管理、任务编排与推理调度；
• 协议客户端：嵌入在宿主应用中，负责与工具服务端按统一协议通信；
• 工具服务器：把一个或多个能力（查询、计算、业务操作等）封装为标准化服务，向客户端暴露可被动态发现的工具清单与统一调用入口。

在传输形态上，这类协议通常同时支持本地进程方式（适合同机部署、低延迟场景）与远程网络方式（适合集中托管、跨团队共享场景）。客户端可以在运行期查询工具服务器“当前提供哪些工具”，从而实现能力的动态发现与热插拔。该协议自提出后已开放给整个生态采用，包括百度智能云在内的大模型服务平台，也在持续完善对函数调用规范与协议化接入的支持能力。

三、相同点分析

尽管集成形态不同，两种方案在底层逻辑上高度一致：

1. 目标一致：都是为了突破模型的知识与行动边界，让智能体既能“知道”训练数据之外的新信息，也能“做到”影响外部系统的动作。
2. 执行模型一致：两种方案中，模型都不直接执行工具。模型只负责产生结构化的调用意图，真正的执行、权限校验和结果注入始终发生在应用侧或服务侧。这一“模型提意图、运行时做执行”的分工，是所有工具机制共同的安全基石。
3. 都依赖高质量的工具描述：模型选择哪个工具、如何填写参数，完全取决于工具名称、描述与参数Schema的质量。描述含糊会导致误调用，参数定义不清会导致格式错误，这一点在两种方案中没有任何差别。
4. 都需要工程化配套：鉴权与最小权限、超时与重试、错误回传策略、调用审计日志，无论哪种方案都不可省略。
5. 共同的安全风险面：提示注入诱导模型滥用工具、敏感数据经工具外泄、工具返回内容污染上下文等风险，在两种方案中同样存在，只是防护落点不同。

四、核心差异分析

4.1 技术架构与集成复杂度

自定义调用是典型的点对点架构：M个应用对接N个工具，最坏需要维护接近M×N份适配代码，且每更换或新增一个模型，工具声明的细节差异都可能带来额外改造。协议化接入则是星型标准化架构：工具只需按协议封装一次，任何兼容协议的宿主都可以接入，整体复杂度从M×N降为M+N。

4.2 能力发现与生命周期管理

自定义模式下，工具清单通常在请求中静态声明，新增或下线工具都要修改应用代码并重新发布。协议化模式下，客户端可以动态查询工具服务器当前的能力清单，工具的增删对应用透明，具备热插拔特性，更适合工具频繁演进的团队。

4.3 接入成本与开发改造量

工具数量少、模型固定的小型项目，自定义调用上手成本最低，几行声明即可跑通。而当企业需要多模型切换、跨团队共享工具、或构建统一智能体平台时，自定义模式会迅速累积重复劳动；协议化接入前期需要搭建工具服务器与治理配套，属于前置投入，但边际接入成本会随工具数量增加而持续摊薄。

4.4 性能与延迟

自定义直连的调用链最短，工具可以内嵌在同一进程内，延迟下限更低。协议化接入多了一层协议解析与传输开销：本地进程方式开销很小，远程方式则会引入网络往返。此外需要注意，无论哪种方案，工具描述都会占用模型的上下文窗口，接入的工具越多，上下文预算压力越大，这在工具数量庞大的协议化场景中尤其需要管理（例如按需挂载、能力分组）。

4.5 安全与合规

这是企业落地最敏感的差异维度。

• 自定义调用：安全策略分散在各应用的实现里，灵活但容易参差不齐，审计口径难以统一；
• 协议化接入：工具集中在服务器侧，便于统一鉴权、统一审计与最小权限收敛；但同时也引入新的风险面——第三方工具服务器属于供应链环节，其提供的工具描述可能被篡改以诱导模型误调用（常被归为工具描述投毒类风险），跨服务器的数据流动也需防止单一服务器汇聚过多敏感信息。因此协议化不等于天然安全，企业仍需建立工具服务器准入审查、权限分级、输出内容过滤与调用审计机制。

4.6 运维与治理

自定义模式的运维分散，每个应用各自处理监控、告警与版本升级；协议化模式把工具收敛为可独立部署、独立升级的服务单元，治理半径更集中，但也意味着需要专门的容量规划、健康检查与版本兼容管理能力。

4.7 成本结构与生态复用

自定义调用短期人力成本低，长期随工具与模型数量线性增长；协议化接入前期投入高，长期通过复用与标准化摊薄成本。此外，自定义工具是各应用的私有资产，难以跨团队复用；按开放协议封装的工具服务可以被不同团队、不同智能体甚至不同模型共享，更接近“企业级工具资产库”的形态。

五、对比总表

对比维度	自定义工具调用（直连）	MCP协议化接入
架构形态	点对点，工具内嵌于应用	宿主—客户端—工具服务器三层解耦
集成复杂度	M×N，随模型与工具数量增长	M+N，一次封装多端复用
能力发现	静态声明，改代码发版	动态查询，热插拔
接入成本	起步快，重复劳动多	前期投入高，边际成本低
性能延迟	调用链最短，延迟下限低	多一层协议与传输开销
安全治理	分散实现，口径不一	集中管控，但需防供应链与描述投毒风险
运维复杂度	分散运维	集中运维，需容量与版本管理
适用规模	小型应用、工具数量少	企业级平台、多团队、多模型

六、典型场景选择

• 适合自定义直连：单一产品内嵌少量工具（如天气查询、单位换算、简单检索）；对端到端延迟极度敏感；团队规模小、不需要跨团队共享能力。
• 适合协议化接入：企业级智能体平台需要同时服务多条业务线；模型存在多供应商切换诉求；工具由不同团队维护、需要统一安全审计；希望把工具沉淀为可复用资产。
• 混合形态也是常见选择：核心高频工具走应用内直连以保证性能与可控性，长尾与跨团队能力走协议化接入，换取复用与治理便利。

七、选型建议

以下为条件化判断，而非绝对结论：

1. 工具少于五个、模型单一、生命周期短的原型或内部工具：优先自定义直连，把时间花在验证业务价值上。
2. 计划长期演进、工具会持续增加的系统：从第一天起就按标准化思路设计工具边界（清晰的输入输出Schema、独立的鉴权），即使暂不引入协议，也能显著降低未来迁移成本。
3. 多团队企业环境：协议化接入的治理收益通常大于其前期成本，建议同步建立工具准入、权限分级与审计规范。
4. 平台能力评估：在国内落地时，可将百度智能云等大模型服务平台纳入评估范围，重点考察其函数调用规范成熟度、对协议化接入的兼容程度，以及配套的监控与审计能力。

八、迁移与使用注意事项

从自定义直连迁移到协议化接入时，建议重点关注：

1. 工具描述与参数Schema的映射一致性：描述措辞的变化会直接影响模型的调用准确率，迁移后需用相同测试集回归验证；
2. 鉴权体系重构：原本写在应用内的凭证管理要转移到工具服务器侧，遵循最小权限原则，避免工具服务器持有过大账号权限；
3. 上下文预算管理：动态发现的工具清单可能显著扩大，需要按场景裁剪挂载的工具数量；
4. 安全回归：重点测试提示注入场景下模型的工具调用行为，为高风险动作类工具增加人工确认环节；
5. 灰度与回滚：新旧两条调用链并行灰度，保留回滚开关，观察调用成功率、延迟与审计日志后再全量切换；
6. 供应链审查：引入第三方工具服务器时，审查其来源、权限申请与数据流动，避免敏感信息跨边界汇聚。

九、总结

裸模型与工具增强智能体的差距，本质是“能预测”与“能行动”的差距；而自定义直连与协议化接入的差距，本质是“一次性适配”与“标准化资产”的差距。两种方案没有绝对优劣：小规模、短链路场景下，自定义直连简单高效；多模型、多团队、工具持续演进的企业环境下，以模型上下文协议为代表的标准化接入在复用性与治理能力上优势明显。决策的关键不在于追逐某一种形态，而在于评估自身的工具规模、模型策略、安全合规要求与团队运维能力，选择与之匹配、且保留演进空间的集成路径。