下载链接只活一小时：MCP 对接第三方系统的

八月二十八号上午，多租户联调跑最后一次。客户那边返回数据突然取不到了。

前端一直转圈，后端日志却干干净净。接口返回 200，数据字段里也有值。就是下载不了。我盯着那段返回看了很久才反应过来——那个链接，一个小时前明明还是好的。

这坑真不能全怪第三方。几乎所有外部文件接口都这么设计：链接带签名、带时效、带一次性。这是设计，不是意外。错在我们当时默认了一件事：返回过的链接就能一直用。凭证会过期，我们却把它当成了不变地址。

最后怎么改的？返回链接那一刻就转存到自己的存储上。再起个定时任务去搬运，搬完写回 JSON 字段。前端直接读字段，永远不碰外链。一个字段写入顺序的问题，硬生生变成了架构问题。

比这更阴的是接口升级。V1 和 V2 名字参数都一样，区别只在校验严不严。V1 不严格，传错参数也给你个假结果。V2 严格，传错直接失败。升级时什么都没报错，直到某次测试用错 ID 才发现。同一个错误，以前是假成功，现在是真失败。

这对 Agent 更麻烦。它会拿假结果当事实继续往下推，在错误的地基上盖三层楼，你还找不到哪块砖歪了。我现在给所有对接加了一条死规矩：升级前后，必须用同一批错误参数各跑一遍对比行为。

还有个坑更离谱。接口从 MTP 改名成 M，就一个字母的事。所有调用它的地方全部失效。翻半天代码发现调用名是对的，坏在一处配置里写了旧名字。最后是靠腾讯文档里一份人工维护的补充记录才恢复的。

一边指望 Agent 自主自愈，一边系统里最靠得住的信息源却是人工文档。这矛盾太扎眼了。

模型外面那圈脏活，才是真正拉开差距的地方。