ENVI Agent通过MCP把ENVI工具暴露给GitHub Copilot，工具清单在mcp.json里定义——这意味着Agent“能做什么”完全取决于NV5在清单里放了哪些工具、以及每个工具的参数schema写得多细。当用户想要的操作用了ENVI里有但mcp.json里没暴露的功能，Agent是会说“这个我做不了”，还是会用一个相近的工具凑合出一个看起来对但语义不对的结果？

一、问题的提出：当工具清单成为能力上限

把一个遥感处理软件包装成 Agent，最容易被忽略的一层不是模型，而是工具契约。ENVI Agent 通过 MCP 服务器把 ENVI 的部分功能以工具（tool）形式暴露给 GitHub Copilot，工具的名称、描述、参数 schema 全部写在 mcp.json 里。这个文件的地位被严重低估：它既是能力清单，也是能力上限。模型看不到 ENVI 的完整功能树，它只看到这份清单，以及清单里每个条目的文字描述。

于是问题变得具体：当用户提出一个 ENVI 原生支持、但清单里没有对应工具的操作时，Agent 会怎样？理论上存在两种极端行为。一种是显式拒答——明确告知“当前工具集不支持该操作”。另一种是近似替代——在清单里挑一个语义相近的工具，把参数凑成能跑通的形式，返回一个语法合法、看起来合理、但语义已经漂移的结果。后者对遥感工作流的破坏远大于前者，因为遥感处理链条长、中间产物多，一个错误的辐射定标或掩膜参数往往要到最终分类精度评估时才暴露。

本文的核心判断是：在 MCP 这类“清单驱动”的工具集成范式下，Agent 的失败模式主要由 schema 的可判别性决定，而不是由模型规模决定。schema 写得越模糊，模型越倾向于“凑合”；schema 写得越精确，模型越容易识别“我做不了”。这一判断贯穿全文。

需要先界定一个概念。本文所称能力缺口（capability gap），指用户意图所对应的操作集合与工具清单所能覆盖的操作集合之间的差集。它不是“模型不会”，而是“契约未声明”。这个区分很重要：前者靠换模型解决，后者只能靠改清单或改流程解决。工程上把两者混为一谈，就会陷入“不断换更大模型却始终解决不了业务问题”的循环。

延伸阅读方面，MCP 官方规范对工具定义有明确约束，可参考 Model Context Protocol Specification；GitHub Copilot 的 Agent 模式与工具调用说明见 GitHub Copilot 文档；ENVI 的 API 与工具能力可查阅 NV5 Geospatial 官方文档。

二、背景：MCP 的协议定位与 ENVI 的工具体系

2.1 MCP 解决的是“上下文与工具的标准化接入”

MCP 是 Anthropic 于 2024 年底提出并开源的协议，定位是让模型应用以统一方式连接外部数据源与工具。它采用客户端—服务器结构：Host（如 IDE、聊天客户端）内嵌 MCP Client，通过 JSON-RPC 与 MCP Server 通信；Server 对外声明 resources、prompts、tools 三类能力。工具部分的核心是 tools/list 与 tools/call 两个方法：前者返回工具清单及 JSON Schema 形式的输入参数定义，后者执行调用。

本文评述：MCP 的工程价值在于把“工具接入”从每家厂商的私有插件格式中解放出来，但它同时把“工具描述质量”的责任完全下放给了 Server 实现方。协议只规定 schema 必须是合法 JSON Schema，并不规定描述文字必须多精确、参数约束必须多严格。这意味着同一套 ENVI 功能，可以写出对模型极其友好、也可以写出对模型极其误导的两份 mcp.json。协议的中立性在这里转化为工程风险。

2.2 ENVI 的功能面远大于典型工具清单

ENVI 是成熟的遥感图像处理平台，功能覆盖辐射定标、大气校正、几何配准、正射纠正、光谱分析、分类、变化检测、SAR 处理等。其底层 IDL/ENVI API 提供了大量可编程入口。一个现实的 mcp.json 不可能把全部功能都暴露出来——工具数量过多会挤占模型上下文，也会显著提高选择错误率。因此清单必然是功能面的一个子集，这个子集的选择本身就是产品决策。

这就形成了一个结构性张力：用户按 ENVI 的完整功能面提需求，Agent 按清单的有限子集做响应。张力不会消失，只会以某种失败模式表现出来。理解这一点，比争论“模型够不够聪明”更有工程意义。

三、机制剖析：模型如何在清单内做工具选择

3.1 工具选择本质是一次受限检索与约束满足

从机制上看，模型在 Agent 循环中做的是三件事：把用户意图解析为若干子目标；在工具清单中检索与子目标语义最接近的条目；为选中条目填充参数并调用。第一步是意图理解，第二步是受限检索，第三步是约束满足。三者中任何一步出错都会导致结果偏差，但只有第二步的“无匹配”才真正对应能力缺口。

关键在于：检索是“最近邻”式的，不是“阈值判定”式的。模型倾向于返回清单中与意图最接近的工具，而不是在相似度低于某阈值时返回空。这一行为倾向在开放域问答里是优点（尽量给出有用回答），在工具调用里却是风险源——它把“无匹配”系统性地转化为“弱匹配”。本文评述：这不是模型的缺陷，而是训练目标与部署目标之间的错位。对话式训练奖励“有回应”，工程部署要求“无把握时不行动”，两者在工具调用场景下直接冲突。

3.2 上下文预算对清单规模形成硬约束

工具清单要占用上下文窗口。工具越多、描述越长，留给对话历史与中间结果的空间越小。工程上常见的做法是控制清单规模、精简描述。这与“把 ENVI 全部功能都暴露出来”的直觉相悖，但符合成本约束。由此产生一个可观测的权衡：清单越精简，选择准确率越高，但能力缺口越大；清单越完整，覆盖越广，但选择错误率与上下文压力同步上升。

关于工具数量与选择准确率的关系，学界已有系统研究。工具检索与选择的相关工作可参考 ToolLLM（Qin 等，2023）对大规模 API 检索的讨论，以及 Toolformer（Schick 等，2023）对自监督工具调用的探索。本文评述：这些工作多聚焦“如何从大清单中检索出正确工具”，而本文关心的是反向问题——当正确工具根本不在清单中时，系统如何表现。后者在工程落地中更常见，却讨论更少。

3.3 一个可复现的调用循环

下面给出一个简化的 MCP 工具声明与调用流程，便于后续讨论具体到字段级别。示例为示意性配置，非 NV5 官方发布内容。

{
  "tools": [
    {
      "name": "envi_radiometric_calibration",
      "description": "对多光谱影像执行辐射定标，将DN转换为辐亮度或表观反射率。仅支持已提供定标系数的传感器。",
      "inputSchema": {
        "type": "object",
        "properties": {
          "input_path": { "type": "string", "description": "输入影像绝对路径" },
          "output_path": { "type": "string" },
          "calibration_type": {
            "type": "string",
            "enum": ["radiance", "reflectance"],
            "description": "定标目标量；reflectance 需影像自带增益偏置与太阳几何参数"
          }
        },
        "required": ["input_path", "output_path", "calibration_type"]
      }
    }
  ]
}

注意 calibration_type 的枚举约束与描述里的前置条件。如果描述只写“执行辐射定标”，模型就无从知道 reflectance 需要太阳几何参数，用户提出“转反射率”时它可能直接选 radiance 再在后续步骤里“解释”结果。这就是语义漂移的雏形。

四、三种失效模式与“语义漂移”的成因

4.1 模式一：显式拒答

当用户意图与清单中所有工具的描述相似度都较低，且模型被明确指示“不确定时不要调用”，就会出现拒答。这是最安全的失败模式：用户立刻知道能力边界，可以改需求或换工具。工程上应把拒答视为可接受结果，而不是需要消除的缺陷。系统提示中应显式授权拒答，例如“若没有工具能准确完成该操作，请说明缺口，不要用近似工具替代”。

4.2 模式二：近似工具替代（最危险）

这是本文重点。典型场景：用户要求“对影像做地形校正”，清单里只有几何配准工具，模型调用配准工具，输出一份“已配准”的结果，并在回复中称“已完成几何处理”。从工具调用日志看一切正常，从遥感语义看完全错误——配准解决的是影像间对齐，地形校正解决的是地形引起的几何畸变，两者不可互换。

这类错误的隐蔽性来自三个叠加因素。其一，输出形态相似：都是生成一幅新的栅格影像，肉眼难以区分。其二，元数据不完整：替代工具写出的元数据只记录自身处理，不记录“未执行地形校正”。其三，语言层补偿：模型会在自然语言回复里用“几何处理”这类上位词模糊掉具体差异。三者叠加，错误被包装成成功。

笔者认为，评估 Agent 质量时不能只看“任务完成率”，必须同时看“语义一致率”。前者统计是否产出了文件，后者统计产出是否满足原始意图的语义约束。两个指标之间的差值，就是近似替代造成的隐性债务。

4.3 模式三：参数降级填充

工具选对了，但参数填错。常见于 schema 描述含糊的情形：单位未声明（米还是千米）、坐标系未声明（地理坐标还是投影坐标）、枚举未穷举（模型自造一个看似合理的取值）。参数降级填充往往不会报错，因为很多遥感工具对参数范围宽容，会“尽力执行”。结果是精度下降而非失败，这类问题最难在测试阶段捕获。

五、schema 精度：参数描述如何决定结果对错

5.1 可判别性是 schema 的第一目标

好的 schema 不只是“让调用能通过校验”，而是让模型能判断“这个工具是否真的适合当前意图”。这要求 schema 携带负向信息：明确写出不支持什么。例如在 description 中声明“不支持 SAR 数据”“仅适用于已做大气校正的反射率产品”。负向信息是模型识别能力缺口的主要依据。

本文评述：当前多数 MCP Server 的 description 只写正向功能，这与软件文档的写作惯性有关——文档习惯介绍“能做什么”，而工具契约需要同时声明“不能做什么”。这一转变需要工程团队在写作规范上专门约定，不能指望模型自行推断。

5.2 参数级约束清单

以下清单可作为 mcp.json 评审的检查项，按优先级排列：

1. 单位与量纲：所有数值参数在 description 中写明单位，避免“分辨率 30”这类歧义。
2. 枚举穷举：凡是有限取值的参数一律用 enum，禁止用自由字符串。
3. 范围约束：用 minimum/maximum 表达物理可行域，如 NDVI 阈值限定在 [-1,1]。
4. 前置条件：在 description 中写明数据前置要求（传感器、产品级别、坐标系）。
5. 互斥与依赖：用 oneOf/anyOf 表达参数组合约束，如“reflectance 模式必须同时提供太阳几何参数”。
6. 默认值语义：若提供 default，必须说明默认值对应的物理假设。

关于 JSON Schema 的表达能力边界，可参考 JSON Schema 官方站点；遥感数据产品级别与预处理约定可参考 USGS 的 Landsat Collection 2 Level-1 说明，其中对辐射定标与几何精度的定义可作为前置条件写作的参照。

5.3 用返回结构支撑自我校验

如果工具返回结构里包含“实际执行的操作类型”“使用的参数快照”“未满足的前置条件”，模型就有机会在调用后自检，并在回复中如实说明。反之，若返回只有“success: true”，模型只能假定成功。工程上建议在返回中固定携带 operation、params_echo、warnings 三个字段。这是低成本、高收益的改动。

六、工程路径：缺口探测、契约治理与评估闭环

6.1 第一步：建立意图—工具映射矩阵

把业务侧常见需求整理为意图清单，逐条标注“清单内是否有精确对应工具”“是否存在弱相似工具”。这一步不需要模型参与，纯人工梳理即可，产出是一张矩阵表。矩阵中“无精确对应但有弱相似”的格子，就是近似替代的高发区，应优先补充工具或强化拒答提示。

6.2 第二步：构造缺口测试集

针对矩阵中的缺口格子，构造测试用例。每个用例包含：用户原话、期望行为（拒答或指定工具）、判定标准（是否调用了错误工具、返回是否包含缺口说明）。测试集规模不必大，覆盖每个缺口类型各若干条即可。运行后统计两个指标：拒答率（缺口场景中正确拒答的比例）与误用率（缺口场景中调用了弱相似工具的比例）。

需要说明的是，本文不提供具体实验数值，因为不同 mcp.json 配置、不同模型版本下的结果差异很大，任何脱离具体配置的数字都不具备参考价值。读者应在自己的清单上复现该流程并记录基线。这一态度与可验证性原则一致：结论应来自可复现的本地测量，而非引用他人未公开的实验。

6.3 第三步：schema 迭代与回归

每次修改 mcp.json 后重跑测试集，观察拒答率与误用率的变化。经验上，补充负向描述与枚举约束会同时提升拒答率、降低误用率；单纯增加工具数量则可能提升覆盖率但抬高误用率。把这两个指标纳入版本发布门槛，可以防止 schema 在迭代中悄悄退化。

# 缺口测试的伪代码骨架（示意）
for case in gap_test_set:
    resp = agent.run(case.user_query, tools=load_mcp("mcp.json"))
    called = extract_tool_calls(resp)
    if case.expect == "refuse":
        record("refusal_ok" if not called else "misuse", case.id)
    else:
        record("hit" if case.expect_tool in called else "miss", case.id)
report(refusal_rate, misuse_rate)

6.4 第四步：在系统提示中固化行为准则

schema 之外，系统提示是第二道防线。建议写入三条准则：其一，调用前先核对工具描述中的前置条件与负向声明；其二，若仅存在弱相似工具，先向用户说明差异并征得确认；其三，调用后核对返回的 operation 字段与原始意图是否一致。这三条把“事后补救”前移为“事前判别”，能显著降低近似替代的发生率。

关于 Agent 行为约束的通用方法，可参考 Anthropic 的 Building Effective Agents 一文对工作流与自主 Agent 的区分；工具使用评估方面可参考 ToolLLM 论文 中的 API 检索设定。本文评述：这些资料提供了方法论框架，但遥感领域的特殊性——处理链条长、中间产物多、语义约束强——要求在此基础上增加领域专用的判定标准，不能直接套用通用 benchmark。

七、对比与局限：MCP 方案与其他工具集成范式

7.1 与函数调用、插件体系的对比

OpenAI 的函数调用、各家 IDE 的插件体系、以及 MCP，在“把外部能力交给模型”这件事上目标一致，差异在于契约的标准化程度与复用范围。函数调用把 schema 写在每次请求里，灵活但不可复用；插件体系绑定特定平台；MCP 把契约外置为独立 Server，可跨 Host 复用。本文评述：MCP 的复用优势同时放大了契约质量的外部性——一份写得差的 mcp.json 会被所有接入它的 Host 继承，问题不再是单点，而是面状扩散。

7.2 局限与边界条件

本文的讨论有三点局限。第一，未涉及具体模型版本的差异，不同模型对负向描述的敏感度不同，结论需在目标模型上复核。第二，未量化上下文预算对清单规模的具体约束，这依赖 Host 的窗口大小与压缩策略。第三，近似替代的判定依赖人工标注的语义等价类，标注一致性会影响指标可比性。读者在应用本文方法时，应把这三条作为前提条件写明。

此外，工具清单的治理还涉及版本管理问题：mcp.json 变更后，历史会话中模型形成的“工具印象”不会自动更新，跨会话的一致性需要额外的缓存失效机制。这一点在多人协作的 IDE 环境中尤为明显，值得在工程实践中单独设计。

八、结论与展望

回到开头的问题：Agent 会说“做不了”，还是凑合一个语义不对的结果？答案取决于清单与 schema 的可判别性。当工具描述包含明确的负向声明、参数 schema 携带单位与枚举约束、返回结构支持自检时，模型有足够依据识别缺口并拒答；反之，弱相似工具会被系统性选中，产出语法合法、语义漂移的结果。能力边界不是模型属性，而是契约属性。

工程上可落地的路径是四步：建立意图—工具映射矩阵定位缺口；构造缺口测试集量化拒答率与误用率；以指标为门槛迭代 schema；在系统提示中固化“先判别、后调用、再自检”的行为准则。这条路径不依赖更换模型，成本可控，且效果可验证。

展望来看，MCP 生态若要走向生产级，工具契约需要从“能调用”升级为“可判别”。可能的演进方向包括：在协议层引入能力声明与前置条件字段；在工具市场层建立 schema 质量评级；在评估层形成领域专用的语义一致率基准。遥感这类强语义约束的领域，很可能成为这套演进的先行试验场。