2026年6月22日，Google 官方账号在 X 上发布了一条看似普通的推文：「Today, the Interactions API is now generally available as our primary interface for Gemini models and agents.」
这不是一个版本号更新。这是一次基础设施层面的范式转向。
从此，你不再「调用模型」，而是「发起一次交互」。模型、Agent、工具链、状态管理——所有曾经需要开发者手动拼装的零件，全部被塞进了一个统一的 API 端点里。
一件被低估的发布
Interactions API 从 2025 年 12 月进入公开 Beta 测试，历时近 7 个月迭代后正式 GA。Google 在官方博客中明确将其定位为 Gemini 模型和 Agent 的首要接口（primary interface）——不是之一，是首要。
传统上，开发者构建 AI 应用需要同时维护至少两套接口：用 Gemini API（generateContent）调用模型做推理，再用 Agent Development Kit（ADK）创建和管理 Agent。一套是「问答」，一套是「编排」。
Interactions API 把这一切合并了。
在谷歌开发者博客的官方公告中，这个 API 的核心能力包括：传入 model ID 做标准推理或传入 agent ID 做长周期自主任务；在一次交互中混合调用 Google Search、Google Maps 等内置工具和自定义函数；设置 background=True 让耗时任务在服务端异步执行；为 Agent 分配完整的远程 Linux 沙箱环境，让它写代码、浏览网页、管理文件。Google 甚至给出了一个默认的沙箱 Agent 名称——Antigravity。
BuildrLab 在 6 月 22 日的分析文章中总结道：「Google 不是在添加一个新端点，而是在告诉开发者：Agent 形态的 API 是 Gemini 新项目的默认路径。」
从「对话」到「交互」：单一接口背后的架构重构
如果只看表面，Interactions API 似乎只是把几个 API 合并成了一个。但它的技术细节揭示了更深层的架构变革。
状态：从客户端搬到服务端
在旧模型中，每次调用都是无状态的。开发者需要手动将所有历史消息拼进 messages 数组、手动跟踪 tool call 和 tool result 的对应关系、手动管理 context window 防止溢出、手动处理超时和重试。Google AI 产品负责人 Shubham Saboo 在评价这一痛点时说：「你 90% 的时间花在管道上，10% 的时间花在真正的 AI 逻辑上。」
Interactions API 把状态管理从客户端搬到了服务端：每个交互由 interaction ID 唯一标识，Google 自动保存状态；付费用户的历史交互可留存 55 天；交互中的每个动作都是类型化的步骤（typed step）——用户输入、模型思考、函数调用、模型输出，各有清晰的数据结构。不再需要手动拼接数组，也不存在「消息格式上下文不符」的问题。
从 messages 到 steps：数据模型的质变
官方公告中提到的一个关键细节：Interactions API 废弃了基于角色（role-based）的消息格式，改用类型化步骤。在旧格式中你写的是 {role: "user", content: "..."} 和 {role: "model", content: "..."}。在新格式中，系统记录的是 user_input → thought → function_call → function_result → model_output 的完整链路。
这一变化本质上是将「对话」数据模型升级为「交互」数据模型——前者适合聊天机器人，后者适合 Agent 系统。对于构建多步骤 Agent 工作流的团队来说，这消除了大量 boilerplate 代码。
Flex 层的商业逻辑：50% 降价的潜台词
Interactions API GA 同时带来了新的定价模型——这或许是整个发布中最容易被忽视、但长期影响最大的部分。
Google 推出了两档定价：Priority 层面向聊天、实时问答等需要即时响应的场景，按常规定价；Flex 层面向后台分析、批量处理、Deep Research 等可以容忍延迟的任务，相比 Priority 降低 50% 的成本。
50% 的成本降幅意味着什么？以 Deep Research 为例，一次深度研究可能需要调用数十次模型推理、执行多次代码、搜索多个网页。在旧模式下，每一次推理都按实时定价计费，成本很快就会失控。Flex 层为这类「慢但深」的 Agent 任务提供了一条经济上可持续的路径。
与此同时，付费用户的交互状态保留 55 天——这意味着一个 Deep Research 任务的结果，开发者可以在近两个月内随时回溯，而无需自己实现持久化逻辑。对构建「长期记忆」型 Agent 的团队来说，这降低了一整轮的工程复杂度。
Google 的差异化棋局：不是框架，是 API 本身
Google 在这个时间点把 Interactions API 推上 GA，竞争意图不言自明。
2026 年上半年，AI Agent 框架之争已经白热化。OpenAI 发布了 Agents SDK，主打开发者易用性和 GPT 生态深度集成。Anthropic 的 Claude Agent SDK 走的是「计算机原生操作」路线。LangGraph 在企业级多 Agent 编排上积累了深厚势能。CrewAI 凭借简洁的多 Agent 协作模式吸引了 52,000+ GitHub Stars。
在这个拥挤的赛道上，Google 的策略不是再做一个 Agent 框架——而是把 Agent 能力直接嵌入 API 层。
这是一个根本性的差异。OpenAI 的策略是让 Agent SDK 成为 GPT 模型之上的一个框架层，框架与模型分离。Google 的策略是让 Agent 能力成为 API 的原生属性，模型和 Agent 通过同一个接口访问。
前者让开发者可以灵活选择框架，但需要额外的集成工作；后者降低了开发者的认知负担——「一个接口解决一切」——但也意味着更强的平台绑定。
Google 的赌注是：在 Agent 时代，降低认知复杂度比保持集成灵活性更重要。当大多数开发者还在纠结「该用哪个 Agent 框架」时，Google 直接说：你不需要选择。API 里已经有了。
BuildrLab 的报道提到，LiteLLM、Eigent、Agno 等第三方库已经在早期阶段实现了对 Interactions API 的支持。这一信号表明，社区对「API 原生 Agent」的接受度正在快速升温。
暗面：平台锁定的代价
Interactions API 的 GA 并非没有阴影。
第一个问题：数据控制权。 Managed Agents 意味着更多代码在 Google 侧运行。当你把 Agent 的沙箱环境交给 Google 管理时，数据隐私、合规审计、日志访问的控制权也随之转移。对于处理敏感数据或受监管行业（金融、医疗、政府）的团队来说，这需要审慎评估。
第二个问题：能力缺口。 Google 承认 Gemini Omni 支持仍在「coming soon」状态。这意味着多模态实时交互的关键能力还未完全就绪。对于需要视觉、语音和文本融合交互的 Agent 场景，开发者还需要等待。
第三个问题：平台锁定。 一旦团队围绕 Interactions API 构建了完整的 Agent 系统，迁移到 OpenAI、Anthropic 或 AWS Bedrock 的成本将显著上升。虽然 Google 不认为这是个问题——但对于坚持多云策略的企业，这是一个需要严肃评估的远期成本。
BuildrLab 给出的务实建议是：「新项目从此接口起步，旧项目不需要恐慌迁移，但需要审计哪些工作流适合迁移。」
三个隐藏信号
将 Interactions API 的 GA 放在 2026 年 6 月的行业背景下看，能揭示三个重要的趋势信号。
信号一：模型正在从「品牌」退化为「资源」
当同一个接口可以访问模型和 Agent 时，模型本身的品牌价值正在被稀释。用户不关心调用的是 Gemini 3 Pro 还是 Gemini 3.5 Flash——他们关心的是 Agent 能否在合理时间内完成一个深度研究任务。模型正在从「被调用的对象」变成「被编排的资源」。这是「模型即服务」转向「模型即基础设施」的标志性节点。
信号二：Agent 是比 API Key 更贵的「数字劳动力」
Flex 层 50% 的折扣实际上揭示了 Google 对 Agent 工作负载的价值判断：一个 Agent 执行一次深度研究，消耗的计算资源远高于一次简单的文本生成。但它的产出价值也远高于后者。Agent 不再是「AI 的一种调用方式」，它是 AI 商业化的核心产品形态。当 Google 愿意为 Agent 任务提供 50% 的折扣来吸引开发者，说明它把赌注压在了 Agent 工作负载的增长上。
信号三：API 战争的新战场——「开发范式」的锁定力
2023–2024 年，Google 和 OpenAI 在模型能力上正面交锋；2025 年，它们在 Agent 框架上各自布局；2026 年，战争的主战场已经转移到 API 设计本身——谁能定义「开发者与 AI 交互的标准方式」，谁就能在未来的生态中掌握定价权和分配权。
Interactions API 的设计逻辑——服务端状态管理、类型化交互步骤、统一的模型-Agent 接口——正在推高整个行业的 API 设计标准。当 Google 走出这一步，OpenAI 和 Anthropic 也会被倒逼着做出类似的选择。
开发者不用再为「如何管状态」「如何拼消息」「如何把手动管道变成自动化工具」这些本该由平台解决的问题而烦恼。
模型在退后，交互在向前。API 不再是你问它答的通道——它是一个可以独立行动的「数字员工」的起点。
快报