谷歌动手了。
近日，谷歌正式发布 Interactions API——一个专为构建智能体应用设计的全新交互接口。这不是又一次小版本迭代，而是对现有 generateContent 端点的一次架构级补充，甚至可以说，是一次理念上的替代。
对于一直在用 Gemini API 搭 Agent 的开发者来说，这个消息的潜台词很明确：谷歌承认了，原来那套 API 扛不住 Agent 时代的需求了。
generateContent 的瓶颈，早就该摊开说了
先回顾一下背景。
generateContent 是 Gemini API 的核心端点，设计思路很经典：你发一段 prompt，模型返回一段 completion，无状态，一问一答。这在纯文本生成的时代完全够用，甚至称得上优雅。
但 2025 年下半年开始，事情变了。模型能力从「生成文本」快速膨胀到「思考 + 使用工具 + 多步执行」。你要让模型先搜索一下网页，再调用一个数据库查询，然后根据结果生成报告，最后还得把报告推送到某个系统里——这是一个典型的 Agent 工作流，涉及多轮交互、中间状态、工具调用和异步执行。
硬往 generateContent 里塞？能塞，但代价是什么？
谷歌自己的原话是：「会使 API 变得过于脆弱。」翻译成开发者能听懂的话就是——你得在客户端手动维护对话状态、自己编排工具调用链、处理各种中间态的序列化和反序列化，写出来的代码又臭又长，还一碰就碎。
这不是 Gemini 独有的问题。OpenAI 的 Chat Completions API 在面对复杂 function calling 链时也有类似的尴尬，所以后来才推出了 Assistants API 和 Responses API。Anthropic 的 Claude 则通过 tool_use 消息类型来处理，但多步编排依然需要开发者自己搭脚手架。
换句话说，整个行业都在面对同一个问题：为「对话」设计的 API，撑不起「做事」的需求。
谷歌选择的解法，是另起一个端点。
Interactions API 到底改了什么
从公开信息来看，Interactions API 的核心设计可以拆成几个关键点：
1. 统一的 RESTful 端点
不再区分「跟模型聊天」和「让智能体干活」。一个端点，通过参数指定你要交互的对象是裸模型还是已经配置好的智能体。这意味着开发者不需要在不同的 API 路径之间跳来跳去。
这个设计思路其实和 OpenAI 的 Responses API 有异曲同工之处——都在试图用一个统一入口收敛复杂度。但谷歌走得更远一步：它把智能体作为一等公民直接暴露在 API 层面，而不是藏在 Assistants 这样的抽象层后面。
2. 服务器端状态（可选）
这是最关键的变化。
generateContent 是无状态的，每次请求你都得把完整的对话历史塞进去。对话越长，token 消耗越大，延迟越高。而 Interactions API 支持服务器端状态管理——你可以选择让谷歌帮你维护交互上下文，也可以继续走无状态模式。
对于 Agent 场景，这几乎是刚需。想象一个需要执行 10 步操作的任务，每一步都可能涉及工具调用和等待结果。如果每次都要把前面所有步骤的完整上下文重新发送，不仅浪费资源，还容易因为 context window 溢出而丢失关键信息。
服务器端状态让这一切变得简单：发起一个交互会话，后续步骤自动继承上下文，开发者只需要关注当前步骤的输入输出。
3. 可解释且可组合的数据模型
谷歌在这里用了一个很有意思的词：「可解释」。意思是 API 返回的数据结构不再是一个黑盒的文本 blob，而是结构化的、可以被程序解析和组合的数据单元。
举个例子：模型在推理过程中调用了一个工具，工具返回了结果，模型基于结果继续推理——在 Interactions API 中，这整个过程的每一步都会以结构化的方式暴露出来。你可以精确地知道模型在哪一步做了什么决策、调用了什么工具、拿到了什么结果。
这对调试和可观测性来说是巨大的改进。用过 OpenAI function calling 的开发者应该深有体会：当工具调用链出了问题，排查起来有多痛苦。
4. 后台执行
这个特性直接对标的是长时间运行的任务。
不是所有 Agent 任务都能在几秒内完成。有些任务可能需要几分钟甚至更长——比如深度研究、复杂数据分析、多系统协调操作。Interactions API 支持将任务提交到后台执行，客户端不需要保持长连接等待结果。
这和谷歌同期升级的 Gemini Deep Research 能力是配套的。Deep Research 本身就是一个典型的长程任务：模型需要自主规划研究路径、多次搜索和阅读网页、整合信息、生成报告。这种任务如果走同步 API，体验会非常糟糕。
5. 远程 MCP 工具支持
这一点值得单独拿出来说。
MCP（Model Context Protocol）是 Anthropic 在 2024 年底提出的开放协议，定义了模型如何发现和调用外部工具。经过一年多的发展，MCP 已经成为事实上的工具调用标准，几乎所有主流模型提供商都在不同程度上支持它。
Interactions API 原生支持远程 MCP 工具，意味着你可以直接把符合 MCP 规范的工具服务接入 Gemini 智能体，不需要额外的适配层。这大大降低了工具生态的接入成本。
结合谷歌去年推出的 A2A（Agent2Agent）协议来看，谷歌的智能体基础设施布局正在成型：A2A 解决智能体之间的通信和协作，MCP 解决智能体与工具之间的交互，Interactions API 则是开发者与这一切交互的统一入口。
跟竞品比，谷歌这步棋走得怎样
坦率地说，Interactions API 不是一个「从零到一」的创新，更像是谷歌在看清行业方向后的一次快速跟进和系统整合。
OpenAI 的 Assistants API 早在 2023 年底就引入了服务器端状态和工具调用编排的概念，2025 年又推出了更轻量的 Responses API。Anthropic 虽然没有单独的 Agent API，但通过 extended thinking、tool_use 和 MCP 的组合，也在 Claude 上实现了类似的能力。
但谷歌的优势在于后发的系统性。它不是在旧 API 上打补丁，而是直接设计了一个新端点，从数据模型到执行模式都是为 Agent 场景量身定制的。这种「推倒重来」的魄力，在大厂里并不常见。
另一个值得关注的点是谷歌的生态整合能力。Interactions API 不是孤立存在的——它和 Vertex AI Agent Engine、A2A 协议、Google Workspace 集成（比如最近发布的 Agent2UI）形成了一套完整的智能体开发栈。如果你的应用深度依赖 Google Cloud 生态，这套组合拳的吸引力是相当大的。
不过，也有隐忧。谷歌的 API 产品历史上有一个让开发者头疼的毛病：版本迭代太快，废弃太狠。generateContent 现在还能用，但 Interactions API 出来之后，它的生命周期还有多长？如果你刚基于 generateContent 搭好了一套工具调用的脚手架，现在又要迁移到新 API，这个迁移成本谁来承担？
谷歌需要给开发者一个明确的信号：这两个 API 会长期共存，还是 Interactions API 最终会完全取代 generateContent？
对开发者意味着什么
如果你正在构建 Agent 应用，Interactions API 的发布释放了几个明确的信号：
第一，API 设计正在从「对话」范式转向「任务」范式。 不管是谷歌的 Interactions API、OpenAI 的 Responses API，还是 Anthropic 的工具调用体系，所有主流提供商都在把 Agent 工作流作为 API 设计的核心场景。如果你还在用最基础的 chat completion 接口手动编排多步任务，是时候考虑升级了。
第二，MCP 正在成为工具调用的通用语言。 谷歌原生支持远程 MCP 工具，加上 OpenAI、Anthropic 的支持，MCP 的生态地位已经非常稳固。如果你在开发供 AI 调用的工具服务，优先实现 MCP 接口是一个稳妥的选择。
第三，服务器端状态管理将成为标配。 无状态 API 在简单场景下依然好用，但对于复杂的 Agent 工作流，服务器端状态几乎是必需品。这也意味着你需要重新思考应用的架构——状态放在哪里、怎么管理、怎么恢复。
实际调用：通过 OpenAI Hub 兼容格式接入 Gemini
对于已经在用 OpenAI 格式 SDK 的开发者，好消息是 Gemini 模型可以通过 OpenAI 兼容接口调用，包括工具调用能力。如果你用 OpenAI Hub 这类聚合平台，一个 Key 就能同时调 GPT、Claude、Gemini、DeepSeek 等模型，切换模型只需要改一个参数。
下面是一个通过 OpenAI 兼容格式调用 Gemini 模型并使用工具调用的示例：
from openai import OpenAI
client = OpenAI(
api_key="your-openai-hub-key",
base_url="https://api.openai-hub.com/v1"
)
# 定义工具
tools = [
{
"type": "function",
"function": {
"name": "search_database",
"description": "搜索产品数据库，返回匹配的产品信息",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "搜索关键词"
},
"category": {
"type": "string",
"description": "产品类别",
"enum": ["electronics", "clothing", "books"]
}
},
"required": ["query"]
}
}
}
]
# 第一步：发送请求，模型决定是否调用工具
response = client.chat.completions.create(
model="gemini-2.5-pro", # 通过 OpenAI Hub 调用 Gemini
messages=[
{"role": "system", "content": "你是一个产品搜索助手，帮用户查找产品信息。"},
{"role": "user", "content": "帮我找一下最新的降噪耳机"}
],
tools=tools,
tool_choice="auto"
)
# 第二步：处理工具调用
message = response.choices[0].message
if message.tool_calls:
tool_call = message.tool_calls[0]
print(f"模型请求调用工具: {tool_call.function.name}")
print(f"参数: {tool_call.function.arguments}")
# 模拟工具执行结果
tool_result = '{"products": [{"name": "Sony WH-1000XM6", "price": 2499}]}'
# 第三步：将工具结果返回给模型，生成最终回复
final_response = client.chat.completions.create(
model="gemini-2.5-pro",
messages=[
{"role": "system", "content": "你是一个产品搜索助手。"},
{"role": "user", "content": "帮我找一下最新的降噪耳机"},
message, # 包含 tool_calls 的 assistant 消息
{
"role": "tool",
"tool_call_id": tool_call.id,
"content": tool_result
}
]
)
print(final_response.choices[0].message.content)
上面这段代码展示的还是基于 chat.completions 的工具调用模式——也就是 Interactions API 想要改进的那个范式。可以预见，当 Interactions API 的能力逐步开放并被兼容层支持后，多步推理和状态管理的体验会有质的提升。
如果你想同时对比不同模型在工具调用场景下的表现（比如 Gemini 2.5 Pro vs Claude Sonnet 4 vs GPT-4o），用聚合平台切换起来会方便很多，不用为每个模型单独管理 API Key 和 SDK。
更大的图景：Agent 基础设施的军备竞赛
把视角拉远一点看，Interactions API 的发布只是最近一周 AI Agent 领域密集动作中的一个。
同一时间窗口内：Anthropic 的 Claude Computer Use 正式落地 Mac，AI 可以直接操作桌面应用；JetBrains 发布 IntelliJ IDEA 2026.1，通过 ACP 协议内置支持多款 AI 智能体；谷歌内部的 Agent Smith 工具因为太受欢迎把服务器都搞崩了，布林亲自下场写代码修复。
这些事件指向同一个趋势：2026 年，Agent 正在从概念验证走向生产部署，而基础设施层的竞争才刚刚开始。
谷歌的策略很清晰——用 Interactions API 做开发者入口，用 A2A 协议做智能体间通信标准，用 Vertex AI Agent Engine 做托管运行时，用 MCP 兼容做工具生态接入。这是一套完整的、自上而下的智能体平台方案。
OpenAI 走的是另一条路：Responses API + Agents SDK + 内置工具（web search、code interpreter、file search），更强调开箱即用的体验。Anthropic 则相对克制，聚焦在模型能力本身（extended thinking、computer use），把编排层更多地交给社区和第三方框架。
三条路线，各有取舍。对开发者来说，最务实的策略可能是：核心业务逻辑保持模型无关，通过兼容层和标准协议（MCP、A2A）做抽象，避免被任何一家锁定。
毕竟，这场军备竞赛还远没有到终局。今天的最优解，半年后可能就需要重新评估。保持灵活性，比押注任何一家都重要。
参考来源
- 谷歌智能体发力：增强版 Gemini Deep Research 和专属 API 都来了 - 新浪科技 — Interactions API 发布详情及与 generateContent 的对比
- AI 情报：Claude 能控制 Mac，谷歌内部 Agent 把服务器搞崩 - 人人都是产品经理 — 近期 AI Agent 领域重要动态汇总
- Agent2Agent 协议 - 百度百科 — A2A 协议技术细节及发展历程
- 使用 Agent2UI 代理构建 Google Chat 应用 - Google Developers — 谷歌智能体与 Workspace 集成的实际案例