工具调用与 MCP：接口、权限和执行可靠性
区分模型提出调用、MCP 连接工具与业务系统真正执行操作的责任。
Foxmu · 更新日期: 2026-10-19
先拆清三个不同层次
工具调用让模型提出一个操作名称和结构化参数，由应用决定是否执行。MCP 则为宿主、客户端与提供工具等能力的服务端建立协议连接。模型决定、连接协议和业务执行属于不同层，不能用一个“支持 MCP”概括所有能力。
网关能够接收 tools 字段，并不能证明完整 MCP 工作流已经可用。接入图中应标明模型端点、Agent 宿主、MCP 客户端、服务端和授权方式，并说明每一层由谁维护、失败时如何退出。
验证一次完整的工具往返
先定义一个只读查询工具，使用较小的参数结构和可预测的测试数据。核对模型提出的名称、参数类型、调用标识、返回结果以及最终回答，再覆盖流式模式与同轮多个工具调用。
反向用例包括错误参数、未知工具、缺失结果标识和重复结果。执行前应拒绝无效输入，不能依靠模型自行纠正来代替校验。记录客户端及服务端版本，因为普通文本请求通过，并没有验证工具协议链路。
由执行系统独立完成授权
模型参数、检索材料和工具输出均应视为不可信输入。实际执行服务必须检查用户、租户、资源归属和允许的操作；每个集成使用范围明确的凭据，不转发上游主密钥。
删除、发布或财务操作应经过可信业务流程中的审批。文档里出现的指令不能扩大权限，模型声称“已经获得许可”也不能作为授权依据。建议先从只读工具验证，再为会改变业务状态的动作设计独立控制。
限制执行成本和重复副作用
为每个任务设置工具调用次数、总耗时、响应大小和费用上限。超时不一定意味着执行失败，应记录操作是否可能已经完成。查询重试与创建订单重试具有不同风险，后者需要幂等设计和执行记录。
取消状态应贯穿宿主、网关和工具服务。结果不完整时返回明确错误，不让模型假设成功。备用模型或路由必须维持工具约定、访问权限和数据政策，不能因重试而自动扩大可用工具范围。
用场景确认兼容性
验收覆盖允许与拒绝操作、权限不足、凭据过期、流式中断以及上游切换。外部工具对收到的数据有自己的保存规则，应纳入生命周期检查。把模型生成工具调用、MCP 连接和业务执行分别记录结果，才容易定位具体问题。
上线时保存测试版本、配置和剩余限制，避免把局部通过描述为全部兼容。可结合 PROBE 论文导读，在功能测试之外增加规则覆盖与完整行动轨迹检查。