12 月初 Google 把 Interactions API 推进了 GA。这个 API 比一般的版本更新分量大——它不是给 generateContent 加几个字段,而是 Google 给 Gemini 模型 + Agent 准备的统一新接口,标志着模型 API 设计从"请求-响应"范式正式转向"会话-长任务"范式。
下面从工程视角拆几个值得关注的变化,以及它们对实际开发(尤其是国内开发者)意味着什么。
一、Interactions API 的几个工程层面的关键变化
1. 从 outputs 数组到 steps 时间线
老的 generateContent 返回的是一个 outputs 数组,你要自己解析输出。Interactions API 把每次交互拆成了一个 steps 数组——每一步是一个 typed step:user_input、thought、function_call、function_result、model_output 各自独立。
工程意义:你可以直接拿到 agent 的中间推理过程、工具调用、调用结果,而不是只看最后的输出。对调试 agent、监控 agent 行为、做 observability 非常友好。以前要自己拼 logging 才能拿到的信息,现在 API 直接给。
2. previous_interaction_id 服务端管理上下文
老接口要求你每次调用把完整对话历史塞进去。Interactions API 让你用 previous_interaction_id 直接引用上次的交互,服务端保存上下文(付费 tier 保留 55 天)。
工程意义:显著减少每次请求的 payload 体积,长会话场景下尤其明显。但也带来新问题——上下文在服务端,你拉历史就是一次跨境数据请求。
3. background=True 异步长任务
这是这次最重要的能力。把请求标记为 background 后,API 立即返回一个 interaction id,任务在云端继续跑。你后续可以:
- 轮询 interactions.get 查状态
- 挂 SSE 流式连接收实时事件
- 配 webhook 让 Google 完成后回调
工程意义:Agent 跑小时级任务正式成为可行的工程模式。但这也是国内开发者面对的最大问题——见下文。
4. Antigravity:Managed Agent + 远程沙盒
Google 提供了 Antigravity 这个 managed agent,带一个隔离的远程 Linux 沙盒。agent 可以在沙盒里跑命令、写文件、执行代码。你只需要调 API,沙盒生命周期 Google 管。
工程意义:不用自己搭 agent runtime、不用维护沙盒、不用处理 isolation。代价是所有数据进出沙盒都是跨境流量。
5. Flex / Priority 两档定价
Flex 比标准便宜 50% 但有延迟波动,Priority 贵但更稳定低延迟。
工程意义:Google 第一次正式把"延迟"做进了定价模型——延迟不再是免费副产品,而是用户可以付钱购买的资源。这件事的工程影响很深远(后文展开)
6. 错误响应精确到字段
老接口报错经常是"InvalidArgument:something",你得猜哪个字段错了。新接口的错误响应直接告诉你哪个字段、哪个 step 出问题。
工程意义:小但实用的改进,调试时间能省一截。
二、国内开发者面对的真实工程问题
API 本身的设计相当不错。但对国内开发者,有几个非常具体的工程问题需要正视。
问题一:background 任务的"长链路稳定性"
background=True 这个能力是双刃剑。它让 agent 跑小时级任务变得可能,但也意味着你必须维持跟海外服务的长时间稳定通信:
方式一:轮询 interactions.get。 看似简单。但跨境每次 HTTP 请求的 RTT 通常 200~300ms,频繁轮询体验差、还浪费 quota。降低频率又会延迟感知到状态变化。
方式二:挂 SSE 流式连接。 体验更好,但跨境 SSE 长连接面对的挑战是——中间网络设备(运营商出口、骨干网中间节点)经常在 30 分钟左右悄悄回收空闲或半空闲连接,直接 TCP RST。你的 SSE 连接看起来活着,实际下一次事件就 reset 了。重连后你能否准确恢复到正确状态,取决于你 SSE event 的设计——但事实是大部分 agent 任务里中途 reset 就是丢事件。
方式三:webhook 回调。 看起来最优雅。但要求你国内服务暴露在公网、被 Google 的服务器主动回调。除了暴露面问题,还有一个微妙问题——Google 那边发来的 webhook 走的也是公网跨境链路,链路抖的时候 Google 会重试,但重试上限有限,丢了就是丢了。
这三种方式没有一个能完美避开"跨境公网链路不稳"这个根问题。
问题二:55 天历史 = 持续跨境数据流
服务端保留 55 天历史的设计很贴心,但它意味着每次需要历史上下文,数据都要从 Google 海外机房拉回国内。
对调用频次高的应用,这变成一条长期持续的跨境数据管道。Agent 任务越复杂、历史越长,这部分跨境流量越大。
一个隐性的成本陷阱:Google 不算这部分网络成本——但你的跨境带宽是有成本的。Agent 越用越深,你这块的隐性成本越高。
问题三:Priority tier 解决不了跨境网络问题
这是这次 GA 里最容易被误读的一点。
很多人会觉得"哦,Google 推了 Priority tier,买了就能解决延迟问题"。但 Priority tier 解决的是 Google 数据中心内部的处理延迟——你的请求到了 Google 之后,优先调度、优先 GPU 资源。
但你国内到 Google 的那段跨境网络链路,Google 完全管不到也优化不了。这段链路的延迟主要由公网状态决定,跟你付多少钱无关。
所以一个尴尬的现实:国内开发者用 Priority tier,实际只能享受到这个 tier 一部分的延迟优势。剩下的延迟卡在跨境链路上,白付贵价钱。这是工程师选型时要注意的。
问题四:MCP server 调用频次倍增
Interactions API 直接支持 MCP(Model Context Protocol)server——agent 主动去调外部 MCP server 做事情。
绝大部分有意思的 MCP server 部署在海外。Agent 思考越深、调用工具越多,跨境调用频次飙升。每次 MCP 调用都是一次完整的跨境 HTTP 请求 + 响应。
举个量化的例子:一个 agent 任务可能内部触发 30-50 次 MCP 调用,假设每次跨境延迟 300ms,光网络 RTT 就 9-15 秒——而这还是顺利情况下。任何一次跨境抖动会让单次调用 timeout,触发 retry,延迟成倍放大
问题五:Antigravity 沙盒的"双跨境"问题
Antigravity 沙盒本身在 Google 海外机房。你从国内连接沙盒、看输出、传文件,所有交互都跨境。
但还有个更微妙的问题:沙盒内的 agent 跑命令时,如果命令访问外部资源(下载文件、调 API),这些请求是从沙盒所在地发起的——也就是 Google 海外机房的 IP。这部分网络条件不归你管,Google 用什么链路就什么链路。
对你来说,这意味着两段跨境网络:国内→Google 沙盒→外部资源。任何一段不稳,体验都崩
三、应用层补救的局限
工程师对这些问题不是没想办法。应用层常见的几招:
Retry + 指数退避。 跨境 timeout 标配。但 agent 场景下 retry 有特殊代价:每 retry 一次,token 计费再算一遍——agent 的 token 消耗本来就比 chat 高几个数量级,retry 等于持续烧钱。而且 retry 解决不了 background 任务中途断流的状态恢复问题。
Connection Pool + Keep-Alive。 减少 TLS 握手开销。但跨境长连接遇到的真实问题是被中间网络设备悄悄回收——pool 里的连接可能已经死了,你不 send 不知道。
Cache 中间结果。 对读场景有用,对写、对实时状态查询、对 streaming 都没用。
协议层优化(HTTP/2 多路复用、HTTP/3 over QUIC)。 在弱网下表现确实比 TCP 好,QUIC 的 0-RTT 和连接迁移对跨境抖动有缓解。但这些优化是建在公网链路之上的,公网本身不稳的话,上层优化有天花板。
改用海外中转。 最常见的"兜底"方案——租一台新加坡或东京的 VPS 做反向代理,所有跨境流量先到这台 VPS 再出。问题是:引入单点、引入运维负担、合规存疑(消费级 VPS 跑企业业务)、长任务挂久了 VPS 自己也可能挂。
跨境专线。 最稳的方案,但成本极高,单条专线一年几十万起步。中小团队用不起。
这些方案的共同特点是:要么是补丁,要么贵到只有头部用得起。中间地带一直是空的——直到 SD-WAN 这类企业级跨境网络方案的成本下来。
四、SD-WAN 在 AI Agent 场景的工程价值
SD-WAN(软件定义广域网)原本是大企业连接多分支用的,这两年开始进入跨境 API 调用、跨境 agent 场景。它解决前面几个问题的思路有三层:
链路层路径优化。 服务商在全球部署 POP 节点,你的跨境请求不再走公网长链路,而是先就近接入服务商的 POP,再走预选过、监控过的骨干线路出海。RTT 通常能比公网降低 30%-60%,丢包率显著下降。对调用频次高的 agent 场景,这种基础链路改善是乘性收益——每一次 MCP 调用、每一次状态轮询、每一次 SSE 事件传输都受益。
多链路冗余 + 智能选路。 同时纳管多条底层链路,通过 BFD / 健康检查持续探测每条链路的实时质量(延迟、抖动、丢包)。任意一条质量劣化或中断,秒级切换。这对 background 长任务的连续性特别重要——一次抖动不再意味着任务白跑。
应用层加速与协议优化。 部分方案在加速节点上做 TCP 参数调优、协议复用、压缩传输。对 agent 场景里大量小请求的高频跨境调用、SSE 长连接的稳定性、大文件跨境传输都有明显改善。
五、什么时候该认真考虑这件事
不是所有跨境 AI 调用都需要这套基础设施。简单的 chat 应用,公网够用。
但只要符合下面任一条件,工程价值就显著:
- 跨境 AI 调用是业务核心链路,SLA 跟业务损失强挂钩
- 大量使用 background 长任务,中途断流损失大
- 频繁调用海外 MCP server,跨境调用频次高
- 需要稳定的跨境 streaming(SSE / WebSocket)
- 用 Antigravity 这类沙盒,沙盒交互高频
- 多地分布式部署,需要集中可观测的跨境网络
满足这些条件的工程团队,把跨境网络当成基础设施一部分来规划,长期回报远高于反复在应用层打补丁。
六、写在最后
Google 这次的 Interactions API GA,工程意义比表面看起来大。它不是给已有 API 加几个字段,而是为 AI 工程范式从"对话"切到"agent"做的基础设施重构。Microsoft、Anthropic、OpenAI 都在做类似的事,差别只是先后。
对国内开发者,这个时代有两道门:
第一道是工程认知——理解 agent 范式、理解 background 长任务、理解 MCP、理解多 agent 协作。这道门资料越来越多,大家都在过。
第二道门很多人还没意识到——底层网络。Agent 调用全在跨境公网上跑,这条线上抖一下、断一下、慢一下,上层做得再聪明也白搭。当业务规模真上来,这道门会从"可以忍"变成"必须解决"。
把底层基础设施备好,再上层做工程优化——这件事的回报比反过来大得多。
关于万联 WANFLOW
万联 WANFLOW 是浙江数位元流科技有限公司旗下品牌,专注企业级跨境网络服务。依托全球 200+ POP 节点(覆盖北美、欧洲、东南亚、拉美等核心市场)和 SD-WAN 智能路由技术,为有大量跨境 API 调用、跨境 Agent 任务、跨境数据同步需求的开发团队和企业,提供稳定低延迟的跨境网络加速。
核心能力包括:多链路冗余与自动切换、基于实时质量的智能选路、SSE/WebSocket 长连接保活、集中管理后台统一可视化全球节点状态。在跨境数据传输场景中,效率较公网链路最高可提升 10 倍以上。