MCP 工具调用:从 demo 到生产还有多远

MCP 最吸引我的地方,不是它又提供了一套新协议,而是它把 Agent 和外部工具之间的边界说得更清楚。以前很多工具调用像临时胶水:能跑,但调用语义、参数约束和失败方式都藏在提示词或业务代码里。MCP 至少给了我一个可以讨论工程契约的入口。

在本地跑一个 MCP server 很快。stdio 接上客户端,暴露几个工具,Agent 能列出 schema 并完成一次调用,这个 demo 往往十几分钟就能看到效果。但生产环境不是让模型调到工具就结束,还要考虑谁能调、调了什么、失败怎么恢复、版本怎么升级,以及调用记录如何被排查。

传输方式会影响这套系统的边界。stdio 很适合本地开发、单机工具和编辑器旁边的辅助进程,它简单、隔离感强,也容易跟随用户会话启动。HTTP 或 SSE 更适合共享服务、跨进程部署和需要统一网关的场景,但它也会把认证、限流、连接稳定性和网络故障带进来。

我会把工具 schema 当成面向 Agent 的产品接口来设计。好的工具名应该表达动作和对象,参数应该少而明确,枚举值要可预期,返回结构要让模型能判断下一步。一个只把内部函数原样暴露出去的工具,通常不是 Agent-friendly,因为它把太多上下文推给了调用者。

错误处理也不能只返回一句失败。生产里的工具调用需要超时、重试、幂等和部分失败语义。比如读取类工具可以更积极地重试,写入类工具要先确认幂等键或业务状态;批量任务要能说明哪些成功、哪些失败、哪些需要人工处理,否则 Agent 只能在模糊结果上继续猜。

可观测性是我判断 MCP 是否真正工程化的关键。每次工具调用至少要留下工具名、参数摘要、结果状态、耗时和关联会话,敏感字段需要脱敏。这样当 Agent 给出一个奇怪结论时,我可以回到调用链路里看它到底读了什么、跳过了什么、在哪一步开始偏离。

最后我越来越觉得,MCP 降低的是接入门槛,不是工程纪律。它让 demo 更容易出现,也让生产问题更早暴露:权限边界、schema 演进、错误语义、审计和回滚。真正有价值的 MCP 集成,不是多暴露几个工具,而是让 Agent 在可控、可查、可演进的系统里工作。