CE101 工具使用与MCP

AI Agent MCP
原文地址：https://ce101.ifuryst.com/core-tech/tool-use-n-mcp

一、这个内容真正解决的是什么问题？

当模型要把“语言理解”变成“真实动作”时，最容易在同一个判断点上摔跤：模型知道该做什么，但没有稳定、可复用的方式去调用外部能力并把结果纳入后续推理。 没有工具调用体系，模型的输出很容易停留在“建议、描述、假设”，而不是“查询、执行、验证、再行动”；更麻烦的是，一旦同时接入多家模型，工具定义与调用格式各自为政，工程侧会被兼容成本拖垮。

二、最容易产生误解的地方

误解 1：只要模型更强，就不需要工具调用

  • 诱因：模型在纯文本任务上越来越像“能独立完成”。
  • 代价：一遇到实时信息、外部系统写入、权限校验、长链路执行，纯生成会退化为“编得像真的”，可靠性不可控。

误解 2：Function Calling、Computer-Use、MCP 是三件完全不同的事

  • 诱因：名字不同、入口不同、产品包装不同。
  • 代价：抓不住本质——它们都在解决“让模型可控地触发外部能力，并把执行结果回灌给模型”。

误解 3：MCP 的价值是技术大跃迁

  • 诱因：协议、架构图、传输方式看起来“很新”。
  • 代价：把注意力放错地方；MCP 真正带来的主要增量是统一约定与生态复用，而不是“比以前更神秘的黑科技”。

误解 4：接了 MCP 就等于有了强 Agent

  • 诱因：MCP 常和 Agent 一起出现。
  • 代价：忽略 Agent 的关键难点仍在编排、状态与上下文管理，尤其是长时段运行时的结果膨胀与抽离。

三、支撑正确理解的核心机制

1）工具调用是“对外行动”的接口层，而不是模型能力本体

  • 直观理解：模型像大脑，工具像手脚；没有手脚，大脑只能“说”。
  • 专业表述：工具调用把外部能力封装为结构化可调用单元，让模型输出从自然语言对齐到可执行指令。
  • 在整体中的位置：它是“执行通道”，决定了可控性、可验证性与可集成性。

2）Function Calling 的关键在“把可用工具放进上下文，让模型选择是否触发”

  • 直观理解：你先把工具清单给模型看，模型再决定用不用、用哪个、参数是什么。
  • 专业表述：通过 JSON Schema 描述函数名、语义与参数类型，模型返回结构化调用意图；执行由应用侧完成，再把结果带回模型生成最终答复。
  • 在整体中的位置：它是早期“厂商自定义约定”的主形态，能快速落地，但跨模型兼容弱。

3）兼容性痛点来自“同一件事，不同厂商用不同字段与组织方式表达”

  • 直观理解：同样是“查天气”，OpenAI 与 Google 的工具声明长得不一样。
  • 专业表述：差异集中在工具声明结构（字段命名、嵌套层级、约束表达）与调用回传格式，导致多模型系统需要多套适配。
  • 在整体中的位置：这是促成开放标准出现的直接压力。

4）MCP 把“工具与资源”抽象成协议与服务，让客户端按统一方式发现与调用

  • 直观理解：工具不再散落在每次请求里“临时声明”，而是以 MCP Server 的形态对外提供能力。
  • 专业表述：Host 运行应用，Client 负责与 Server 通信，Server 暴露工具与资源；模型侧拿到工具清单后给出调用意图，应用侧执行并回灌结果。
  • 在整体中的位置：它更像互联网时代的 HTTP：底层传输不新，但一致的约定带来规模化复用与生态繁荣。

5）传输方式决定部署形态倾向：端侧偏 Stdio，远端偏 Streamable HTTP

  • 直观理解：Stdio 像“本机拉起子进程对话”，HTTP 像“远程服务接口”。
  • 专业表述：MCP 支持 Stdio 与 Streamable HTTP；早期出现过 SSE，但因连接长期保持、状态性更强，在不少场景不合适，后来演进到更通用的流式 HTTP。
  • 在整体中的位置：这是工程选型点，不是概念本体。

四、关键术语与概念对齐

  • 工具调用：模型输出结构化“调用意图”，由应用执行外部能力，并把结果回灌给模型继续生成。
  • Function Calling / Tool Use：厂商在 API 层提供的工具声明与回传约定，常用 JSON Schema 描述参数。
  • MCP（Model Context Protocol）：围绕“工具/资源发现与调用”的开放协议，核心价值在统一约定与生态复用。
  • MCP Host：运行 LLM 应用的环境或设备。
  • MCP Client：在应用内负责与 MCP Server 通信的中介模块。
  • MCP Server：对外提供工具与相关资源的服务端实现，是能力的承载体。
  • Stdio 传输：通过标准输入/输出与 Server 交互，常见于本机侧拉起。
  • Streamable HTTP：通过流式 HTTP 与 Server 交互，适合远端部署与企业场景。
  • mcp-session-id：在 Streamable HTTP 初始化时由响应头给出，用于后续会话关联。
  • Inspector：用于连接与调试 MCP Server 的工具（文中以官方 Inspector 举例）。
  • Claude Code（CC）：在 Agent 场景中集成 MCP Client，通过配置接入多个 MCP Server。

五、结构全景层：原文笔记

  • 工具调用被视为大模型现阶段与外界交互的关键窗口，相关形态包括 Function Calling、Computer-Use 与 MCP，作者认为它们在本质上指向同一类能力延伸。

    • 早期有人把希望更多放在模型能力单点提升，但实践中更迫切的需求落在“可调用外部工具”的交互能力上。
    • 作者把函数调用与 MCP 放在一起讨论，理由是它们解决同一类“工具接入与调用”的问题，只是标准化程度不同。

  • Function Calling 以“在请求中携带工具的结构化定义”来实现工具可用性暴露，各家通过 JSON Schema 描述工具但格式存在差异。

    • OpenAI 示例把工具定义放在 tools 字段下，用 type/name/description/parameters/strict 等信息描述可调用函数。
    • Google 示例通过 functionDeclarations 等字段表达同类信息，字段命名与组织方式与 OpenAI 不同，导致跨模型接入存在适配成本。

  • 函数调用的交互链条以“提供工具—模型产出调用意图—应用执行—结果回灌—模型生成最终输出”为主干。

    • 应用先把一组可用函数放入上下文，让模型基于用户输入判断是否触发调用。
    • 模型若触发调用会返回特定格式的调用意图（示例中类似 get_weather("paris")），真实执行由应用负责完成。
    • 应用把执行结果附带到后续上下文再次发给模型，模型再依据结果决定后续动作与最终回复。

  • 工具定义不统一带来“多模型系统需要多套调用方式”的兼容困难，作者据此引出 MCP 的出现。

    • 当系统同时接入多个模型时，不同的工具声明结构会放大工程维护成本。
    • 在这种背景下，MCP 作为统一协议被认为更利于复用与生态繁荣。

  • MCP 由 Anthropic 于 2024 年 11 月推出，并在后续时间里形成大量服务与讨论热度，作者称其在 2025 年上半年快速出圈并成为事实标准。

    • 文中提到 Google、OpenAI 等主流厂商宣布并支持 MCP 后，开放标准的共识进一步增强。
    • 文中引用架构图并强调可以把关注点聚焦到 MCP Server 这一“能力服务体”。

  • MCP 的架构以 Host、Client、Server 划分角色，Client 连接 Server 获取工具列表并把工具信息与用户问题一并交给模型。

    • Host 被描述为运行 LLM 应用的设备或环境，Client 负责模型与 Server 的通信中介。
    • Server 负责实际逻辑，也可能继续调用外部服务或命令，客户端通过协议调用并获取结果回传模型。

  • MCP 的交互链条包含“连接 Server—获取工具列表—模型决策—应用调用工具—结果回灌—模型输出—返回用户”等环节，作者指出实际产品中部分环节可按形态裁剪。

    • 链条中包含工具列表获取、模型判断是否调用、应用组装参数请求 Server、再把结果连同对话记录交回模型的往返。
    • 作者强调理解架构与链条后，需要进一步了解协议细节以支持真实选型。

  • MCP 协议中传输协议被认为是重点，文中以 2025-06-18 修订版为背景，列出 Stdio 与 Streamable HTTP 两类支持形态，并回顾从 SSE 到流式 HTTP 的演进。

    • 文中解释 SSE 需要长期保持连接且更偏有状态，因此在很多场景不适用，后来演进为 Streamable HTTP。
    • 文中给出经验倾向：Stdio 更适合端侧应用（如 ChatGPT、Cursor），HTTP 更适合远端与 B 端场景（示例提到高德地图 MCP 用官方 URL 连接）。

  • MCP 生态发展中出现“协议互转、反向代理存量 HTTP 接口、Server 聚合与工具激活选择”等衍生需求，文中以 Unla 作为互转与代理方向的开源例子。

    • 文中描述互转需求覆盖 Stdio、SSE、Streamable HTTP 之间的转换，从而催生多种开源实现。
    • 文中提出在接入过多 Server 时会引发上下文膨胀，从而出现聚合多个 Servers、甚至智能选择激活工具的方向。

  • 文中用 FastMCP 给出一个教学用 MCP Server 示例，展示以装饰器方式声明工具并支持多种传输形态，同时用 Inspector 演示连接与查看工具。

    • 示例服务器定义了 hello_world/ping_pong/add_numbers/get_server_info 四个工具，并提供 stdio/sse/http 三种运行模式。
    • 文中解释 Stdio 通过 STDIN/STDOUT 进行通信，并指向官方文档获取更细节内容。

  • 文中以 Streamable HTTP 的多次 curl 请求展示端到端调用细节，强调初始化响应头中的 mcp-session-id 用于后续会话关联，并展示 initialize/notifications/initialized/tools/list/tools/call 等请求。

    • initialize 被强调为关键入口，后续请求需要在请求头携带会话 id。
    • notifications/initialized 的返回状态码被描述为 202，且后续可继续拉取工具列表并发起工具调用。

  • 文中以 Claude Code 说明 Agent 产品如何集成 MCP，指出需要在 Agent 内具备 MCP Client 模块，并展示通过 .mcp.json 配置接入 stdio、sse、http 三类 Server 的方式。

    • 文中展示 Claude Code 的工具定义与请求中的工具结构，并以 Bash 工具的 schema 为例展示工具描述与输入约束。
    • .mcp.json 示例同时覆盖通过命令拉起的本地 Server 与通过 URL 连接的远端 Server，并展示可携带环境变量或请求头信息。

  • 文末总结把 MCP 的关注点落在“协议兼容与生态复用”，同时把 Function Calling 放在“单方工具快速集成与性能最大化”的语境下，并提到 Claude Skills 等扩展形态可拓宽模型可用能力边界。

    • 文中指出工具调用当前更多服务于 AI Agent，并把重点归纳到工具集成、工具定义与加载、执行与结果收集、以及长时段运行下的结果抽离。
    • 文中把“工具调用 + 记忆系统 + 持久化能力”视为推动应用从多轮对话生成走向可自主决策执行的重要组合。

六、如何把这个内容讲清楚给别人？

最值得慢下来讲的是：“工具调用不是模型直接去执行，而是模型给出结构化调用意图；执行与权限由应用负责；执行结果再回到模型里成为新的上下文。” 这是理解门槛，因为很多人会下意识把“模型输出了调用”误当成“模型已经完成了外部动作”，从而在可靠性、权限、安全与审计上踩坑。

可以快速带过的是：不同厂商的字段差异细节（比如 tools 里怎么嵌套、字段叫什么）。这些属于接入层面的工程差异，不影响把握“意图—执行—回灌”的主干。

最小示例（只保留核心机制）：

  • 用户：巴黎今天多少度？
  • 应用给模型：附上一个工具 get_weather(location: string) 的定义。
  • 模型返回（意图）：调用 get_weather，参数 location="Paris"。
  • 应用执行：真的去查天气服务，得到 12°C。
  • 应用把结果发回模型：get_weather 返回 12°C。
  • 模型最终回答：巴黎今天约 12°C，并可在此基础上补充穿衣建议或后续行动。

这个示例里，决定系统可靠性的不是“模型会不会编”，而是“工具是否真的执行、结果是否被正确回灌、以及应用是否对执行做了边界控制”。

七、实践与使用视角的结论

适合用在的场景：

  • 需要实时信息或外部查询的问答（天气、地图、库存、价格、工单状态）。
  • 需要对外部系统产生写入或操作的任务（创建文件、提交工单、触发流水线），且希望可审计可回放。
  • 多模型并存、希望工具生态可复用的应用体系（用统一协议降低适配成本）。
  • Agent 长链路执行任务，需要把“行动结果”纳入后续决策的系统。

不适合用在的场景：

  • 纯离线、无需外部依赖的文本生成任务，且工具接入只会增加复杂度与延迟。
  • 工具结果无法可信获取或缺少权限控制的环境，把调用暴露给模型会放大风险。
  • 目标极端低延迟且工具调用链路不可控的交互（需要谨慎评估引入调用往返的代价）。

最常见、也最危险的错误用法：

  • 把工具当成“装饰”，不做真实执行与回灌校验，导致系统看似能用但关键时刻全靠编造。
  • 让模型直接决定高风险写入操作而缺少应用侧的确认、鉴权与审计。
  • 接入过多 Server 与工具描述，把上下文塞爆却没有结果抽离机制，长时段运行后性能与稳定性显著下降。

最低使用原则：凡是对外部世界有依赖或有写入影响的结论，都让工具结果成为上下文证据，再让模型基于证据表达。

八、最终总结

  • 工具调用把模型从“会说”带到“能做”，关键在意图结构化、执行外置、结果回灌。
  • Function Calling 让工具能快速接入，但跨厂商格式差异会放大多模型系统的适配成本。
  • MCP 的主要价值是统一协议与生态复用，像 HTTP 一样用共识带来规模化繁荣。
  • 传输形态影响部署倾向：端侧常见 Stdio，远端场景更偏 Streamable HTTP。
  • 在 Agent 场景里，真正的难点会落到工具加载、执行编排、以及长时段运行下的结果抽离与上下文控制。

-- End --