> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/agentic_ai_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/agentic_ai_guide/di-san-bu-fen-gong-cheng-shi-jian-yu-luo-di/08_frameworks/8.6_platforms.md).

# 8.6 平台级产品：接口原语与托管运行时

除了开源框架，主流模型平台也在提供“平台级智能体能力”。但这里有两个常被混淆的维度：

* **接口原语（API primitive）**：你直接调用一个统一 API，让模型自己完成多轮、工具调用和部分状态管理。
* **托管运行时 / 平台套件**：平台不仅给模型接口，还给执行环境、权限、会话、观测、连接器和部署面。

本节只讨论这两个维度。**低代码平台（如 Dify、LangFlow、Flowise）已经在** [**8.1 节**](/agentic_ai_guide/di-san-bu-fen-gong-cheng-shi-jian-yu-luo-di/08_frameworks/8.1_ecosystem.md) **的“形态 F”中讨论，这里不再和 API / runtime 混成同一张表。**

## 8.6.1 统一交互 API：把“多轮 + 工具 + 状态”压进一个接口

这类产品的核心价值是：你不必自己手工维护完整的消息回放逻辑，而是围绕一个更高层的“响应 / 交互”对象工作。

### OpenAI Responses API

OpenAI 当前把 **Responses API** 作为统一原语：它支持内置工具、多轮交互、远程 MCP、以及服务端状态管理。工程上最重要的不是“有没有线程对象”这个名字，而是它已经提供了多种状态托管方式：

* `previous_response_id`：基于上一次响应继续多轮。
* `store: true`：让平台保留响应状态。
* **Conversations API**：把会话状态持久化为更长期的对象。

这意味着它不是“只能应用侧自己拼接上下文”的薄封装接口，而是 **API 原语 + 可选状态托管** 的组合。

### Google Interactions API

Google 的 **Interactions API** 也在走相似路线：以 `Interaction` 为中心资源，支持 `previous_interaction_id` 续接上下文，并允许 `store` 控制是否服务端保留交互记录。

但它仍明确处于 **beta / preview** 阶段，官方也直接提示 schema 和 SDK 仍可能发生 breaking changes。因此在选型上，更适合把它看成“值得关注的下一代统一交互原语”，而不是已经完全稳定的默认主路径。

### 统一交互 API 的典型写法

两家的统一交互 API 形态接近：一次调用同时承载输入、工具与状态，再用上一次的响应 ID 续接下一轮。

```python
client = UnifiedAPIClient()
response = client.create(
    model="...",
    input="分析上传的数据，并在需要时调用工具",
    tools=[...],
    store=True,
)

next_response = client.create(
    model="...",
    previous_response_id=response.id,
    input="继续，顺便给我结论摘要",
)
```

## 8.6.2 托管运行时 / 平台套件：平台直接负责执行边界

另一类产品不只是“统一 API”，而是直接提供一个带工具链和权限系统的运行时，或者一整套部署 / 治理平台。

### Claude Agent SDK（原 Claude Code SDK）

Anthropic 当前把它定位为 **Claude Agent SDK**。它的特点不是“多一个聊天接口”，而是把 Claude Code 背后的 agent loop 暴露成可编程运行时：

* 内置文件读取、代码编辑、命令执行、Web 等工具。
* 通过 `allowed_tools` 等参数控制工具边界。
* 原生支持 MCP、会话续跑和多 agent / subagent 能力。

```python
from claude_agent_sdk import query, ClaudeAgentOptions

async for message in query(
    prompt="Review this repository for security issues",
    options=ClaudeAgentOptions(allowed_tools=["Read", "Glob", "Grep"]),
):
    print(message)
```

这更像“托管 agent runtime”，而不是单纯的模型调用 API。

> **同期产品**：2026-04-09 Anthropic 还发布了 **Claude Managed Agents**（公开测试中，Anthropic 云端托管的 Agent harness，含沙盒、工具内置与按 session 计费，定位为 SDK 之上的“全托管运行时”）；同日 **Claude Cowork** 转为 GA（面向非开发者的桌面 Agent 体验）；2026-04-14 发布 **Routines**（Claude Code 自动化任务，研究预览）；2026-04 还发布 **Claude Mythos Preview**（仅邀请制，Project Glasswing 防御性网络安全研究）。这些与 Claude Agent SDK 共同构成 Anthropic 当前的智能体产品矩阵；具体可用特性、计费与 ZDR 覆盖应以 [Anthropic 官方文档](https://platform.claude.com/docs/en/managed-agents/overview) 为准。

### Gemini Enterprise Agent Platform（原 Vertex AI Agent Builder）

Google Cloud 的 **Gemini Enterprise Agent Platform**（[平台概览](https://docs.cloud.google.com/gemini-enterprise-agent-platform/overview)）则是更完整的平台套件。它于 2026-04-22 发布，官方定位是 **as an evolution of Vertex AI** 的统一平台，用来 **build, deploy, govern, and optimize** 企业级 agent；下面再细分为 Agent Development Kit、Agent Studio、Agent Garden、Model Garden，以及运行侧的 Agent Runtime（原 Agent Engine）、Agent Platform Sessions 与 Memory Bank 等组件。

它的关注点不只是单次调用，而是：

* 部署与托管运行
* 企业连接器与治理
* 生产级可观测、评测与安全
* 与 Google Cloud 体系的身份和基础设施打通

因此它和 Gemini Interactions API 并不是同一层：前者更像平台套件，后者更像统一交互原语。

## 8.6.3 平台能力矩阵

以下矩阵只比较 **接口原语 / 托管运行时 / 平台套件** 三种层次，不再把低代码产品混进来。

| 名称                                            | 类别                       | 服务端状态                                                 | 工具与执行边界                         | 适用场景                                 |
| --------------------------------------------- | ------------------------ | ----------------------------------------------------- | ------------------------------- | ------------------------------------ |
| OpenAI Responses API                          | 统一交互 API                 | `store`、`previous_response_id`，并可配合 Conversations API | 内置工具、远程 MCP、自定义函数；执行边界主要由请求参数定义 | 需要 API 级灵活编排，又希望平台代管部分状态             |
| Google Interactions API                       | 统一交互 API（beta / preview） | `store`、`previous_interaction_id`                     | 每次交互需重新声明工具和生成配置；适合 Gemini 原生生态 | 想用统一 interaction 资源承载多轮与工具调用         |
| Claude Agent SDK                              | 托管运行时                    | 会话 / resume 由 SDK 管理                                  | 内置工具、MCP、权限控制、subagents         | 代码执行、自动化、需要细粒度工具权限的 agentic workflow |
| Gemini Enterprise Agent Platform（原 Vertex AI） | 平台套件                     | 平台级 session / memory / deployment 能力                  | 连接器、托管运行、评测与治理一体化               | 企业级部署、平台治理、Google Cloud 集成           |

## 8.6.4 选型建议

**优先统一交互 API 的场景**：

* 你主要想要一个“更高级的模型接口”，而不是整套托管运行时。
* 你希望自己掌控业务编排，但不想完全手写状态拼接。
* 你的工具主要还是应用侧自管，只是想用平台提供的一些 hosted tools。

**优先托管运行时 / 平台套件的场景**：

* 你需要平台直接提供执行环境、权限系统、会话续跑和治理能力。
* 你希望把工具调用、安全边界和观测体系一起标准化。
* 你面对的是企业内自动化或生产部署，而不只是一个 API demo。

**回到开源框架的场景**：

* 你需要更高的可移植性，或者必须私有化部署。
* 你希望跨模型、跨云、跨运行时保持最大控制权。
* 你要比较的是“编排框架本身”，而不是“平台 + 托管工具 + 执行环境”的组合能力。

## 8.6.5 小结

平台能力最好按层次来理解，而不是按品牌名堆在一起：

| 层次       | 典型问题                    | 代表能力         |
| -------- | ----------------------- | ------------ |
| 统一交互 API | “我想少写状态管理代码”            | 多轮、工具、服务端续接  |
| 托管运行时    | “我想直接运行 agent，并限制它能做什么” | 工具权限、会话、执行环境 |
| 平台套件     | “我想把 agent 放进企业生产体系”    | 部署、治理、连接器、观测 |

这也是为什么低代码平台不应与上述三者放进同一维度重复分类：它们讨论的是**开发方式**，而本节讨论的是**平台抽象层级**。

***

**下一节**: [8.7 框架性能基准评测](/agentic_ai_guide/di-san-bu-fen-gong-cheng-shi-jian-yu-luo-di/08_frameworks/8.7_performance.md)