你以为是同一场对话？每次工具调用都是一次独立的 API 请求

你和大模型聊天感觉是连续对话，但每次工具调用背后都是一次全新的 API 请求。这个本质差异，正好可以解释推理模型为什么在 MCP 面前处境尴尬。

用 ChatGPT 的时候，你发一句它回一句，感觉像在跟人聊天——上下文连贯，有来有回。

用 Agent 的时候也一样。你问 "帮我查一下昨晚服务为什么变慢"，它先查监控，再翻日志，最后给你一个结论。看起来也是一次流畅的对话。

但底层完全不是这么回事。

每次 Agent 调用一个工具，背后都发生了一次完整的 API round-trip。模型不保存状态，每一轮对话都是独立的请求。你觉得的 "连续对话" 其实是一个幻觉——靠的是你把完整历史一字不差地塞回给模型。

接下来我们从 Agent 的无状态本质出发，先解释工具调用为什么不是一次对话，再分析推理模型为什么在 MCP 面前处境尴尬。

你看到的是一次对话，实际上是三轮 API 调用

用户发来一句话：

帮我查一下昨晚 user-service 为什么变慢。

Agent 后端收到后，把这句话加上工具描述，发给大模型 API。

调用 #1:
  用户消息 + 工具列表 → API
  API 返回: tool_call(query_monitor, args)

系统执行监控查询，拿到了 CPU、内存、慢查询的时序数据。然后把这些数据拼回上下文，再次调用 API。

调用 #2:
  [调用 #1 的完整对话] + 监控数据 → API
  API 返回: tool_call(query_slow_log, args)

系统再去翻慢查询日志，拿到结果，再拼回去，第三次调用 API。

调用 #3:
  [调用 #1 和 #2 的完整对话] + 慢查询日志 → API
  API 返回: "查到了，是全表扫描导致的问题"

每一轮，你都在把之前所有轮次的内容重新发给 API。模型不记得上一轮发生了什么——你把历史喂给它，它才能假装记得。

这不是 Agent 的设计缺陷，这是 LLM API 的无状态本质决定的。模型本身没有 "记忆"，每次调用都是独立推理。所谓的对话连续性，是靠客户端手动拼接上下文来维持的。

每次工具调用是一次 "上下文扩展"，而非 "从头重启"

看到上面那个流程，大多数人会本能地想：那模型岂不是每次都要从头读到尾，重复计算注意力？

如果你在 2023 年问这个问题，答案是 "是的"。但在当前工业级 API 里，情况完全不同。各大厂商普遍上线了 Context Caching 技术，也就是 KV Cache 的持久化缓存。

第一轮请求时，用户消息 + 系统提示词 + 工具列表产生的 Key-Value 缓存会被保留在服务器显存中。第二轮请求过来时，API 通过哈希匹配直接复用上一轮的 KV Cache，只需要对新追加的内容——比如工具返回的监控数据——计算注意力。

这意味着工程上，多轮工具调用的计算开销增量，大致等于每轮新内容的计算量，而非整段上下文的计算量。OpenAI、Anthropic、DeepSeek 也为此对缓存命中给出了 50% 到 90% 的巨大折扣。

所以 "每次工具调用都是一次昂贵的重启" 这个印象，对普通模型来说已经在很大程度上被 KV Cache 抹平了。

但推理模型的困境是另一回事

KV Cache 解决的是 "计算重复" 的问题，但推理模型的困境出在另一个维度。

困境一：TTFT 和人类感知的冲突

普通模型调用工具的过程很轻量：模型看到输入，快速推理，几毫秒内输出 tool_call token。用户几乎感知不到延迟。

推理模型不同。它在吐出第一个 tool_call token 之前，会先生成几千甚至上万个思考 token（Thinking Tokens）——反复验证、自我纠错、推演路径。这个过程不是几毫秒，而是几秒到十几秒。

如果一次 Agent 任务需要调用 5 次 MCP 工具，用户就要忍受 5 次 "每次卡顿好几秒" 的糟糕体验。对于线上故障排查等延迟敏感场景，这种高 TTFT（首字延迟）是灾难性的。

困境二：思考链不能被中途打断

想象你正在心无旁骛地写一篇复杂的推理论文。脑子里已经搭好了逻辑框架，各个论点之间的关系都串起来了。突然电话响了，你去接了 20 分钟电话再回来坐下——很多细节想不起来了，之前好不容易串起来的推理脉络断了，只能重新理。

推理模型的思考链就是这种东西。它是一个依赖完整上下文的连续生成过程，每一步推理都建立在前面所有推理内容的基础上。中途强行打断去调用工具，会带来两个致命问题：

显存持有与 I/O 换入换出的高昂代价：技术上如果要保持模型的思考状态不丢，这个巨大的 KV Cache 就得原封不动地占着一块 GPU 显存。而在等待工具执行的几秒或几十秒内，这会导致整个推理集群出现显存槽位饥饿（Slot Starvation）。如果将其交换到 CPU 内存，多轮工具调用带来的跨 PCIe 总线频繁拷贝延迟，更会彻底摧毁系统吞吐量。
认知失调：推理模型的思路是基于 "我还不知道工具结果" 建立的。如果想到一半突然涌入新的工具结果，且这个结果可能直接掀翻了模型前几步苦心孤诣建立的假设（例如：模型推测变慢是因为慢查询，而工具返回没有任何慢查询），模型前面的思考链就会发生严重的语义断裂与认知坍缩。在无状态的 API 下，如何让模型优雅地 "自我打脸" 并修正逻辑，没有简单的解法。

困境三：RL 训练和工具调用的 reward 信号不匹配

推理模型的训练目标是 "推理正确性"。你给一道数学题，它推理链越长越详细，最后答案对了，reward（奖励信号）就高。

工具调用引入了一套完全不同的 reward 体系：不仅要 "推理正确"，还要 "在正确的时机调用正确的工具"、"正确解读工具返回的结果"、"在结果异常时修正推理方向"。如果把两种训练数据强行混在一起喂，实际会出现几种典型的失败模式：

模型在思考到一半突然跳出来输出一段奇怪的 JSON，格式还错了，两边都没干好。
模型彻底偏向一边——要么为了迁就工具调用缩短思考链，变成浅层推理；要么彻底放弃工具调用，退化成纯文本模型。
工具结果回来之后，模型的后续推理和之前的思考链对不上，答非所问。

所以早期推理模型宁可先放弃工具调用，也要先把推理能力做扎实。o1-preview 在发布时明确不支持 Function Calling，就是上面这些结构性冲突导致的工程取舍。

后来是怎么解决的

目前行业为了兼顾 "推理质量" 与 "工具调用"，演进出了两种折中方案：

后置触发模式（o3 / early Reasoning Models）：让工具调用发生在思考阶段结束之后。模型先把整个推理链完整跑完，进入 "输出最终答案" 的阶段时，才触发 Function Calling 流程。代价是思考阶段完全感知不到工具结果，无法处理 "需要先查数据再基于数据做深度推理" 的任务。
交错思考模式（Interleaved Thinking，如 Claude 3.7 Sonnet）：允许模型在多次工具调用之间穿插独立的思考片段。每一段思考都是一个自包含的小闭环，通过将工具结果作为下一段思考的边界条件，在一定程度上缓解了认知失调。

那 MCP 呢？为什么 FC 不支持，MCP 就用不了？

MCP 协议（Model Context Protocol）在底层完全依赖大模型的 Function Calling (FC) 能力。

整个调用链是这样的：MCP Client 连上 Server，拉取工具定义，然后把这些定义转换成模型原生的 Function Calling 格式（JSON Schema）传给模型。接着等模型输出标准化的 tool_calls 结构化数据，Client 再把调用请求路由到对应的 Server 执行。

如果推理模型不支持原生 Function Calling，强行用纯文本 Hard-Prompt 去逼迫模型在思考链结束时吐出 JSON 格式，长链推理后的模型极易发生格式塌陷（输出错别字或夹带思维废话），导致 MCP 的翻译层彻底失效。所以，"推理模型原生 FC 能力缺失 → MCP 协议无法落地"是一个必然的传导关系。

结论

工具调用本质上是一连串独立的 API 请求拼接成的 "连续感"。KV Cache 抹平了多轮调用的计算成本，但解决不了推理模型在范式层面的困境。

真正阻碍推理模型和 MCP 融合的，是生成范式的根本冲突：推理模型被训练在完备输入下做一次性收敛推理，而 MCP 代表的 Agent 模式要求模型在不断变化的信息环境中边走边看。这种冲突短期内无法靠 Agent 框架打补丁解决，只有当模型的 RL 训练框架将 "工具动态交互" 与 "长链思考" 进行联合优化时，真正的 Agentic 推理时代才会真正到来。

搜索此博客

不如不追求