给模型接上工具不等于能干活：MCP 落地的三个硬约束

工具调用协议统一之后，接入一个外部服务变得非常便宜：写一个 MCP 服务器，注册几个工具，模型就能查库、发消息、开工单。演示效果通常很好，真正上线却开始出问题——不是模型不会调，而是工具太多、权限太松、失败处理太随意。

一、工具清单本身就在吃上下文
每个工具的 schema 包含名称、用途描述、参数定义和枚举值，通常要占几百 token。接上二十个工具，光工具定义就可能吃掉上万 token，系统提示和用户输入被挤压，模型对指令的遵循度随之下降。更麻烦的是选择准确率：工具数量增加后，名称和描述相近的工具之间开始互相干扰，模型会反复调用错误的那一个。

可行的收敛办法是按会话裁剪工具集——客服场景只挂订单与退款工具，不要把所有后台接口一次性暴露。工具描述也要写清"什么时候该用、什么时候不该用"，参数尽量用枚举而不是自由文本。

二、读工具和写工具必须分级
查询失败最多是一次重试，写操作失败则是真实副作用：重复下单、误删数据、给全量用户发错通知。把这两类工具放在同一个权限池里，是很多事故的共同起点。

比较稳的做法是三层：默认只读，写操作强制二次确认，高风险操作先在沙箱里 dry-run。关键在于把控制放在工具网关这一层，而不是依赖提示词里写一句"请谨慎操作"——提示词可以被绕过，网关的规则不会。

三、失败重试会放大副作用
Agent 的典型执行模式是"调用—超时—重试"。如果工具不是幂等的，一次请求可能变成三次。支付、下单、创建工单这类接口尤其危险，曾有团队在压测中看到一次退款请求被重放出三笔实际退款，原因仅仅是网关把超时当成失败。

工程上的解法并不复杂：工具侧接收客户端生成的幂等键，服务端对同一键只执行一次；网关在超时后先查询状态，确认未生效再重试，而不是直接重发。这一条不做，Agent 的自主性越强，事故放大倍数越高。

四、调用链必须可回放
上线之后最常被问的问题是"它为什么这么做"。只记录最终回答远远不够，需要留下每次工具调用的入参、返回值、耗时和决策依据，并能按会话回放。有了这条链路，定位问题从"猜模型"变成"看日志"，也能顺手统计哪些工具被误用最多，反向优化描述和分组。

结语
MCP 解决的是"能不能接上"，工程要解决的是"接上之后不出事"。工具集要克制，权限要分级，重试要幂等，链路要可回放。这四件事都不涉及模型能力，却直接决定 Agent 能否从演示走向生产——工具越多越要收着用，权限越大越要留后手。

标签：AI Agent、MCP、工具调用、工程实践