🤖 AI

LLM within MCP Matters: Measuring Inefficient Resource Utilization Driven by LLMs

这项研究表明，由于行为偏好，大语言模型经常忽略模型上下文协议（MCP）服务器指令中高效嵌入的参考数据，转而使用搜索工具，因此有必要建立显式的宿主级机制，以使指令上下文的优先级高于工具选择。

原作者： Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

发布于 2026-08-11

📖 1 分钟阅读☕ 轻松阅读

原作者： Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一个这样的世界：你的智能助手不仅仅能和你聊天，它还拥有一种超能力——它可以瞬间调用庞大的工具库和数据库来解决你的问题。这就是大语言模型（LLMs）与工具协同工作的激动人心的前沿领域。你可以把大语言模型想象成一个非常聪明、充满好奇心的学生，他虽然知识渊博，但有时需要查阅资料。为了帮助这位学生，我们有了一个新的标准叫做模型上下文协议（Model Context Protocol, MCP）。你可以把 MCP 想象成一个万能遥控器，让运行这个学生的“宿主”（即应用程序）能够递交给学生特定的工具、数据以及一套使用这些工具的方法说明。

研究人员提出的核心问题是：这个学生真的会听从指令吗？ 有时，指令会说：“嘿，我已经把你要的答案写在这一页上了，直接读就行！”但有时，指令也会说：“噢，顺便提一下，如果你愿意，这里还有一个搜索按钮可以按。”事实证明，即使是最聪明的学生也可能会被闪亮的搜索按钮分散注意力，从而忽略了就在眼前的答案。本论文深入探讨了这种场景，旨在观察“搜索习惯”是否比“阅读指令的能力”更强大，以及如果真是这样，我们该如何解决。

“看菜单”还是“叫服务员”的大实验

在这项研究中，研究人员搭建了一个名为 LexLink 的数字厨房，这是一个旨在帮助人们查找韩国法律的服务端。想象一下，这个服务端就是一份餐厅菜单。通常情况下，如果你想要一道特定的菜（一条法律），你必须要求服务员（搜索工具）去厨房寻找食谱并把它带回来。这既费时又费力。

然而，餐厅老板决定变得聪明一点。他们在桌子上印了一份“每日特选”清单（服务端指令），其中包含了最受欢迎的 20 道菜及其准确的订单编号。规则很简单：如果你想要的菜就在这张清单上，直接告诉服务员订单编号即可。不要麻烦他们去厨房搜索！ 这本应更快速且成本更低。

随后，研究人员邀请了 24 个不同的 AI 学生（来自 Claude、Gemini 和 GPT 等家族）来这份菜单点餐。他们进行了一场包含 54,000 次试验的大规模实验，以观察会发生什么。AI 学生是会阅读“每日特选”清单并直接下单呢？还是会忽略清单，依然按下“搜索”按钮呢？

令人震惊的发现：搜索按钮太诱人了

结果令人警醒。当研究人员完全移除搜索按钮，迫使学生必须使用桌面清单时，24 个 AI 模型中的 23 个表现得非常出色，它们能以 98% 到 100% 的成功率正确阅读清单并下单。这证明了这些学生能够阅读指令；他们只是在有搜索按钮可用时，并不想去读。

但当搜索按钮存在时，情况发生了戏剧性的变化。24 个模型中的 9 个成功率降到了 15% 以下。它们完全忽略了“每日特选”清单，即便答案就在桌子上，它们依然不停地点击搜索按钮。研究人员将此称为一种**“行为偏好（behavioral preference）”**。这并不是因为 AI 太笨而读不懂，而是因为它养成了一种习惯，倾向于使用它最熟悉的工具，即使那是效率最低的选择。这就像一个孩子明明知道答案在第 5 页，却还是不断要求老师帮他翻开书到第 5 页一样。

有趣的是，是否“更新”或“更聪明”并不能保证更好的行为。一些最新的模型在遵循这类特定规则方面，表现甚至比它们的旧型号还要差。研究发现，模型的“新旧程度（recency）”并不能预测谁会成为一名优秀的倾听者。

我们能训练它们倾听吗？（神奇配方）

研究人员随后尝试通过改变桌面上的指令来纠正这种坏习惯。他们测试了三种不同的技巧：

霸道标题 (B)： 一个醒目的大字警告，写着：“必须使用清单！严禁搜索！”
示例 (C)： 展示一张做得对和做得错的对比图。
提示 (D)： 修改搜索按钮的描述，改为：“在使用我之前，请先检查清单。”

他们在每种可能的组合中混合使用了这些技巧。结果显示，没有任何一种单一的技巧对所有模型都有效。事实上，对于某些 AI 模型来说，仅仅使用“霸道标题”反而会让它们的表现变差（在一种情况下降至 0%！）。这就像大声吼叫可能会吓退一个学生让他开始工作，却会让另一个学生陷入僵局。

然而，当他们将所有三种技巧结合在一起时，结果令人惊叹。24 个模型中的 20 个成功率回升到了 86% 或更高。这表明，虽然你不能仅仅通过对 AI 大喊大叫来纠正它的习惯，但一种结合了警告、示例和提示的全面方法可以让他们重回正轨。

这对未来意味着什么

主要的启示是，仅仅给 AI 一个工具和一套指令是不够的。AI 可能会有一种“搜索反射”，这种反射会覆盖掉指令，导致时间与资源的浪费。论文认为，运行这些 AI 的应用程序（即“宿主”）需要介入。与其寄希望于 AI 会阅读指令，不如由应用程序强制要求 AI 在被允许选择工具之前先检查指令。

在这种情况发生之前，开发者必须保持谨慎。他们不能只写一套指令就期望它适用于所有的 AI。他们需要针对他们预期使用的“最弱”模型来测试其指令，并且应该使用结合了示例和提示的综合方案，而不是仅仅使用霸道的命令。这项研究表明，虽然问题确实存在，但通过正确的指令“配方”是可以解决的。

技术摘要：LLM 在 MCP 中的重要性：衡量由 LLM 驱动的资源利用效率低下问题

问题陈述

模型上下文协议（Model Context Protocol, MCP）标准化了服务器向大语言模型（LLM）暴露数据和工具的方式。一种普遍的设计模式是将频繁使用的参考数据（例如，标识符查找表）直接嵌入到**服务器指令（Server Instructions）**中——即提供给客户端 LLM 的系统提示词文本。从理论上讲，这允许模型绕过工具调用（如搜索），直接使用已知条目，从而降低 Token 使用量和延迟。

然而，这种模式的有效性在规模化应用中尚未得到验证。虽然服务器提供了这些指令，但客户端 LLM 必须决定是否在可用的工具架构之上遵循这些指令。现有证据表明，模型对服务器指令的遵循度较低，且在指令层级结构中存在失效现象。本文研究了客户端 LLM 是否真的会消费指令中嵌入的数据，还是表现出一种行为偏好，即即使在提供必要数据的环境下，仍倾向于调用搜索工具。

研究方法

作者使用 LexLink（一个用于韩国法律信息检索的生产级 MCP 服务器）进行了大规模实证研究。

测试平台： 该服务器暴露了 26 个工具。对于 20 个请求最频繁的法律条文，服务器指令嵌入了一个将法律名称映射到 ID 的表格。高效的客户端应直接使用带有缓存 ID 的 eflaw_service，而不是先调用 eflaw_search 来解析 ID。
评估模型： 涵盖三个供应商（9 个 Anthropic Claude，6 个 Google Gemini，9 个 OpenAI GPT）的 24 个 LLM，跨越多个代际和能力等级。
规模： 54,000 次试验（24 个模型 × 9 种条件 × 5 个查询 × 50 轮）。
指标： 命中率 ( $\phi$ )：模型首次工具调用为正确的、带有缓存 ID 的 eflaw_service 的试验比例。任何其他首次调用（包括搜索或错误的 ID）均视为未命中。
实验条件：
- 基准（Baseline）： 标准服务器指令，包含嵌入的表格且搜索工具可用。
- 诊断（no_s）： 完全移除搜索工具。这旨在隔离能力（模型能否读取表格？）与偏好（模型是否选择表格而非工具？）。
- 因子实验干预 ( $2^3$ )： 测试了三种指令级修改，这些修改可以单独使用或组合使用：
  - B (指令性/Directive)： 一个带有“关键（CRITICAL）”标题的指令，强制要求直接使用缓存 ID。
  - C (少样本/Few-shot)： 对比正确与错误工具模式的示例。
  - D (工具提示/Tool Hint)： 修改搜索工具的描述，警告用户先检查指令表格。

关键结果

能力 vs. 偏好：
- 在 no_s 条件下（移除搜索工具），24 个模型中的 23 个实现了 $\ge$ 98% 的命中率，证明它们具备读取并利用指令中嵌入数据的能力。
- 在基准条件下（搜索工具存在），有 9 个模型跌破了 15%。
- 结论： 失效是由行为偏好驱动的，即模型倾向于调用搜索工具，而非缺乏解析指令的能力。对于许多模型而言，搜索工具的存在会覆盖掉嵌入的数据。
非单调性能表现：
- 效率与模型的时效性或代际并不相关。观察到了显著的退化现象：
  - GPT-4.1 (99%) $\to$ GPT-5 (1%)。
  - Gemini 2.5-pro (100%) $\to$ Gemini 3-pro (2%)。
  - Claude Opus 4.5 (100%) $\to$ Opus 4.6 (63%)。
- 这表明，针对智能体（agentic）基准测试的后训练过程可能会在无意中强化那些忽略上下文数据的工具调用策略。
因子干预分析：
- 单一干预（B、C 或 D）表现出高变异性，甚至可能产生反作用。例如，仅应用指令性干预（B）导致 GPT-5.2 的性能从 5% 降至 0%。
- 交互效应： 各因子之间存在强烈的交互作用。结合所有三个因子（BCD）使 24 个模型中的 20 个恢复到了 $\ge$ 86% 的性能。
- 单因子设计会忽略这些关键的交互作用，以及干预措施可能导致性能下降的可能性。

重要性与主张

本文认为，针对每个服务器进行提示词工程只是一种权宜之计，而非根本解决方案。由于单个干预措施的效果取决于模型家族，因此仅依赖指令微调是脆弱的。

作者提出了三点启示：

联合能力评估： MCP 服务器的能力不能孤立评估；它们高度依赖于客户端 LLM 的行为。
宿主侧机制： MCP 宿主应用程序（如 Claude Desktop, Cursor）应提供明确机制，以在客户端 LLM 的决策过程中优先考虑服务器指令（例如，将指令作为系统优先级指令预注入，或在工具选择前强制执行“先查指令”的检查）。
服务器开发者指南： 开发者应包含少样本示例（在所有模型中均显示出积极或中性的效果），并结合多种干预类型（B、C 和 D）以实现更广泛的覆盖，同时应针对最弱的预期客户端模型进行验证。

本研究局限于单一服务器领域（法律查询）和单轮交互。虽然正在对另外四个 MCP 服务器（地理、学术、数据库、消息传递）进行扩展研究，但作者明确指出，其初步结果仅作为展望，而非本文报告结果的证据。