北京
大语言模型的工具调用能力已经强了很多。但那些连接不同系统的胶水代码并没有消失——这才是很多人还没意识到的事。
MCP（模型上下文协议）确实有用。OpenAI加入远程MCP支持有用。Home Assistant开放/api/mcp也有用。但如果你真的动手试过把OpenClaw、Home Assistant、Claude Code、n8n、Make、Zapier或者自研的Agent栈串在一起，你就会知道一个残酷的真相：协议标准化的速度，远快于实际运维的标准化。而项目崩溃的地方，恰恰就在运维环节。
调研时我一直在回想Reddit上的一个帖子。有位用户说，他们花了3.5个月、1300个小时、将近700美元，最终放弃了一套脆弱的配置。极端吗？当然。但那种情绪曲线太熟悉了：演示的时候一切正常，架构图画得干净利落，然后你的实际系统就变成了认证Bug、代理异常、过期令牌、文件交接和权限边角的缝合怪。
如果你在做需要全天候运行、不用人盯着Token消耗的Agent，这些事就更重要了。模型成本只是痛苦的一部分，另一部分是来自太多活动部件的维护税。
演示很干净，生产环境全是胶水。
理想路径总是看起来很美：模型看到用户请求，选个工具，调用它，然后购物车更新了、灯变暗了、工单提交了。代码大概长这样：
response = client.responses.create(
model="gpt-4.1",
tools=[{
"type": "mcp",
"server_label": "shopify",
"server_url": "https://example.com/api/mcp",
}],
input="Add the toner pads to my cart"
)
这个API确实设计得不错。但试试真实版本：MCP服务器藏在认证后面、浏览器工具需要会话、托管环境需要令牌、一个工具返回的文件另一个工具读不了、Home Assistant支持HTTP但你的客户端只支持stdio、代理剥掉了某个Header、上周Schema变了而某个Agent还固守着旧假设。
到这一步，你不是在"加AI"了。你在做Agent运维。
所以我不认为"工具调用"杀死了胶水代码。我认为它把胶水代码搬到了更贵的地方。
MCP到底解决了什么
我支持MCP。核心思路是对的：定义共享协议，这样工具就不需要对每个模型客户端做定制集成。这很重要。
MCP给你的是：统一的消息格式、JSON-RPC 2.0语义、stdio和Streamable HTTP这类标准传输方式，以及比2024年各自为战更好的工具互操作路径。这是真正的进步。
但要精确地说清楚什么被标准化了。MCP标准化的是协议层，它没有标准化部署、认证、文件传输、密钥分发、代理行为或权限设计。而这些，才是决定真实系统成败的关键。
stdio看起来简单，直到你真的要支持它
很多MCP配置还在用stdio。这通常意味着：起一个本地子进程、通过stdin/stdout发送JSON-RPC、把凭证通过环境变量塞进去。本地开发很顺，生产环境就崩了：子进程挂了怎么办？日志去哪了？怎么在容器里横向扩展？凭证怎么轮转？
Streamable HTTP是更好的答案，但它也带来新问题：需要处理SSE（服务器推送事件）、连接生命周期、重连逻辑、以及stdio不需要考虑的CORS配置。
协议选对了，运维的坑才刚刚开始。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
