Google 发布多模态模型 Gemini 1.5 Pro 那天，我正卡在 n8n 的一个工作流里，试图让 Midjourney 的 Discord API 和我的客户 CRM 系统对话。发布会直播窗口在后台挂着，听到“原生多模态”和“100万上下文”时，我手一抖，把工作流里一个关键的 JSON 解析节点给删了。
操。
这感觉就像 2016 年我第一次看到 Google 的 BERT 论文，当时还在死磕 LSTM 做文本分类，觉得那玩意儿是学术玩具。结果两年后，它把整个 SEO 行业掀了个底朝天。现在，历史换了个皮肤又来了。Gemini 这次不是“理解”图片，是它“原生”就把图片、音频、视频、代码、文本都当成同一种东西处理。这意味着什么？意味着我之前花了三个月，用 OpenAI 的 Vision API + 自己写的图片预处理脚本 + LangChain 搭起来的那个“电商客服自动看图回复”系统，架构上可能从根上就落后了。
我赶紧停了手头的活儿，去申请 API 密钥。测试过程很直接，扔给它一张我昨晚画的、极其潦草的流程图照片，让它生成前端 React 代码。它不光读出了我鬼画符一样的方框和箭头，连旁边标注的“这里要异步请求”的扭曲字迹都识别了，生成的代码骨架居然能跑。我又试了更损的：把一个包含错误数据的 CSV 文件截图，和一段描述数据问题的语音备忘录（用 TTS 转的）一起喂给它，让它写一段 Python 脚本来清洗数据。它做到了，而且指出了我 CSV 里一个我自己都没注意到的类型不一致问题。
震撼不是来自“它能做”，而是来自“它如此平滑地就做了”。没有我之前架构里那种“先用这个模型识别图片文字，再用那个模型理解意图，最后用第三个模型生成代码”的管道拼接感。那种拼接，每一个接口都是潜在的故障点，要处理错误、要协调格式、要担心上下文丢失。现在，一个 API 调用，全扔进去，完事。
但这恰恰是最大的风险点。你把所有鸡蛋都放进一个篮子里，哪怕这个篮子叫 Google。API 服务不可用怎么办？突然调价怎么办？像当年 GPT-3 突然收紧政策怎么办？你的整个业务就僵在那里。2021年我做外包时吃过这种亏，当时重度依赖某个国内云厂商的特定服务，结果他们一次不兼容升级，我这边三个项目连夜救火。
所以“多云部署”不是技术偏好，是生存本能。我的策略开始清晰了：核心的、要求最高稳定性的生产流程，还是用 OpenAI 的 GPT-4，毕竟生态最熟。那些需要疯狂消耗上下文、处理复杂多模态输入的原型探索和内部工具，用 Gemini 1.5 Pro。同时，一定在架构层保留一个“降级通道”，比如用开源的 Llama 多模态版本或者 Claude 的 API 做备份，哪怕效果打点折。关键是把“模型调用”这一层抽象出来，做成可热插拔的组件。
这需要基础设施。n8n 的工作流里，每个 AI 模型节点都不能写死 endpoint 和 key，必须从环境变量或者我自己的一个小型模型路由服务里读。这个路由服务很简单，就是记录各个 API 的当前状态（响应延迟、错误率、成本），根据策略分发请求。听起来简单，但调试起来全是坑，比如不同模型输出的 JSON 格式怎么统一，token 计数方式不同怎么算成本。
搞到凌晨两点，初步的路由服务能跑了。我写了几个测试用例，模拟 Gemini API 返回 502 错误，流量自动切到了 OpenAI 的 gpt-4-vision-preview。看着日志里平滑切换的记录，我才稍微松了口气。这不是技术胜利，这是一种风险对冲带来的、脆弱的安心感。我知道 Google、OpenAI 他们下一轮更新可能又会把今天的部署方式变成古董，但至少，我的系统不会因为单一节点的崩溃而瞬间死亡。
窗外？没什么窗外。屏幕的光就是全部。现在要做的，是把这套多云逻辑，固化到我给学员准备的 AI 自动化实战案例里去。告诉他们，别迷恋任何一个神话，你要做的，是在神话们互相打架的缝隙里，把自己的小生意跑通。
