Marico's space
线上 AI 代理突然不响应了，日志里全是 503。代码没动过，配置没动过——但三个月前部署在 Cloud Run 上的那个 MCP 服务器已经不存在了。不是被废弃，是被迁移了、改名了，或者被新版本替代了，而新版本恰好不兼容。
这不是假设场景。这是我从一位日本开发者 ryoji9702 的详细博客里学到的，他记录了自己在一年内把 MCP（Model Context Protocol，模型上下文协议）托管架构改了三次的经历。咱们这边还在讨论 AI 代理到底能不能上生产，人家已经在记录基础设施技术债了。
MCP 是 Anthropic 搞出来的一套标准，用来规范 AI 模型如何连接外部工具和数据源。可以理解为 AI 集成的 USB-C——一个通用接口，让大模型能插上自己需要的工具。问题在于，这套生态还年轻，托管模式根本没定型。
根据那篇博客的分析，迁移经历了三个明显阶段：
每次迁移大概消耗 40-60 个工程小时：配置更新、测试、部署流水线改造，以及生产环境必然出现的小问题。一年三次迁移，光是维持基础设施现状就花了 120-180 小时——这还没算开发新功能的时间。
基础设施钟摆：当你的 AI 中间件变化速度超过业务逻辑时，你不是在跑生产系统，你是在跑一个挂着产品外壳的永续迁移项目。
根本原因不是规划失误。MCP 确实在快速发展——Anthropic、OpenAI，还有更广泛的开源社区都在快速迭代。你站在移动靶子上建基础设施，继承的就是那个速度。
成本分三类：
直接成本：工程师花在做迁移上的时间，本该用来做功能开发。按照一个工程师全部成本 150 美元/小时算，150 小时就是 22,500 美元的纯维护开销——这还没算机会成本。
认知负担：每次迁移都要重新学习一部分技术栈。年初建立的心智模型，到四月就部分过时了。这就是"规格萎缩"——你能在脑子里装下完整系统架构的能力，随着每个变更周期递减。
生产风险：迁移制造了事故窗口。即便用了蓝绿部署，总有一段时间是新旧配置共存，会产生只有真实流量下才会暴露的边界情况。
从研究这个模式里，我总结出五条原则，给正在构建 AI 代理基础设施的同行参考：
1. 从第一天就把 MCP 客户端层抽象出来。不要硬编码 MCP 服务器端点。用环境变量或配置文件，这样换地址不用改代码。这一条决策就能把下次迁移从 40 小时压缩到 8 小时。
2. 锁定 MCP SDK 版本，但盯着废弃通知。博客里记录了，大部分破坏性变更来自 SDK 更新，不是协议本身。锁死依赖版本，但要设个日历提醒，在安全补丁过期前 30 天开始关注。
3. 把 MCP 基础设施当临时脚手架，不要当永久架构。核心逻辑要写成 MCP 无关的。如果你的业务价值在于代理的决策能力，而不是 MCP 传输层，下次动荡来临时你才能换托管商。
4. 在需要之前就把监控埋好。那位日本开发者记录了在迁移期间花大量时间做可观测性。别等出问题再加日志。MCP 请求默认是不透明的——从一开始就把关联 ID 和请求追踪加上。
5. AI 基础设施时间预算留 20% 给维护。如果评估一个 MCP 新功能，乘以 1.2 来估算基础设施更新的必然成本。这不是悲观，是跟现实对齐。
对那些"抽象掉就好了"的建议，我得怼一下：抽象层有自己的维护成本。你加的每个抽象层都是潜在的 bug 来源、需要测试的层级、未来开发者必须理解的组件。抽象过度就变成"骨架实现"——架构图上抽象层画得满满当当，下面却没有足以支撑的实际业务逻辑。
更好的做法是精准抽象：抽象传输层，别抽象协议。你要能换掉 Cloud Run 改用阿里云函数计算或者 K8s 部署，而不用重写代理逻辑。但你别把"我在用 MCP"这件事完全藏起来，因为这个信息对调试至关重要。
说实话，我要是面对两周 deadline 产品经理催 AI 功能，也会犯同样的错误——硬编码 MCP 端点，以后再处理迁移。技术债是真实存在的，而且会复利增长——但上线压力也是。
MCP 生态会继续演进。Anthropic 明确会持续投入，开源社区也在积极贡献协议规范。如果那篇博客的模式会重演，托管不稳定至少会持续到 2026 年 Q4。
我的预测：到 2027 年初，会有一个主导托管模式胜出——大概率会围绕某个大厂云的托管 MCP 服务。在那之前，用跟对待任何 Beta 版生产软件一样的审慎态度对待你的 AI 代理基础设施。
现在记录自己迁移经历的人，正在为所有人积累宝贵的经验。这才是那篇博客真正有价值的地方——不是那个具体的 Cloud Run 配置，而是对 AI 中间件不稳定的代价的模式识别。