Agent 运行时的标准化趋势与选型考量

2026 年 4 月至 7 月，Agent 基础设施市场发生了一件值得关注的事：AWS、Google 和 Anthropic 都推出了托管式 Agent Runtime，而且它们几乎完全收敛到了同一组基础能力上。

如今，每个平台都提供：

• 按 session 隔离的沙箱执行环境（隔离的 Linux 环境）

• session 重启后依然保留的持久化 memory

• Agent 身份与凭证作用域管理

• gateway 层的工具授权

• 多 Agent 编排

• 完整的追踪能力与审计日志

这种能力收敛确实存在。但问题在于：它们的 API 完全不同。

AWS 将其称为 CreateHarness 和 InvokeHarness。Google 称之为采用 A2A protocol 的 Agent Runtime。Anthropic 称之为 Claude Managed Agents，并采用 wake(sessionId) 模式。Azure 也有自己的一套接口。它们彼此之间完全无法互通。

基础能力趋同，API 却各自分化，这就带来了一个新的基础设施问题。

Runtime 锁定陷阱

如果你在 2026 年 7 月基于 Claude Managed Agents 构建 Agent，你会得到：

• ✅ 出色的 session 管理

• ✅ 内置的 sandbox 和 memory

• ✅ 简单明了的定价（每 session-hour 0.08 美元）

• ❌ Agent 逻辑与 Anthropic 的 harness 紧密耦合

六个月后，当你的团队出于合规要求需要在 AWS 上运行 Agent，或者为了获得更好的多 Agent 协作能力而使用 Google 的 Agent Runtime，又或者为了满足数据驻留要求而部署自托管基础设施时，你的 Agent 代码无法直接迁移，只能重新构建。

这正是 LLM-only gateway 在 2023—2024 年通过 OpenAI-compatible API 解决过的陷阱。但现在，我们即将在更上一层再次陷入同样的问题。

为什么 Runtime 选择真的很重要

团队正在发现，不同 Runtime 并不是可以随意互换的：

• Claude Managed Agents 擅长长周期自主任务，并且拥有最简单的 memory 模型

• 如果你的 Agent 需要访问 200 多项 AWS 服务，而且团队已经深度采用 AWS，那么 AWS AgentCore 最合适

• Google 的 Agent Runtime 拥有最快的亚秒级冷启动速度，以及最强的多 Agent 编排能力

• 自托管的 Multica 或 LiteLLM 可以让数据留在本地，同时允许你切换云服务提供商

选择一个 Runtime，意味着你同时选择了未来 18 个月所要面对的整套运维体系。

但团队正在发现的是：Runtime 的基础能力已经解决了，Runtime API 的问题却还没有解决。

Control Plane 解决方案

答案与当初解决 LLM gateway 问题时一样：通过 Control Plane，将逻辑层与 Runtime 层分离。

位于 Runtime 之上的生产级 Control Plane 会处理：

• Runtime 抽象： Agent 只需注册一次，无须修改代码即可在任意 Runtime 上运行

• Session 可移植性： 如果某个 session 在 Anthropic Runtime 上崩溃，它可以携带相同状态，在 AWS Runtime 上继续运行

• Memory 统一： 持久化的 session memory 跟随 Agent，而不是绑定 Runtime

• 凭证作用域管理： Control Plane 负责管理凭证，并将其传递给当前运行 Agent 的 Runtime

• 审计轨迹： 所有 Runtime 共用一份不可篡改的记录，而不是每个平台各自保存独立日志

• 成本归因： 你可以查看每个 Agent、每个 Runtime、每个 session 的成本，而不是让成本数据割裂在各个平台中

当 Agent 运行在 Runtime A 上，随后需要迁移到 Runtime B 时，Control Plane 会负责转换：

Agent Logic (framework-agnostic)
    ↓
Control Plane (vendor-neutral orchestration)
    ↓
Runtime Adapter Layer (AWS / Google / Anthropic / Self-Hosted)
    ↓
Managed Runtime (AWS AgentCore / Google Agent Runtime / Claude Managed Agents / etc.)

Control Plane 就是让 Runtime 可以自由替换的转换层。

为什么现在就必须重视这件事

到了 2026 年 7 月，这已经不是理论问题。团队正在真实地撞上这堵墙：

• 先使用 Claude Managed Agents 进行试点（交付速度快，开发者体验出色）

• 第 3 个月：“为了满足 SOC 2 合规要求，我们需要把它部署到 AWS。”

• 第 4 个月：“为了满足数据驻留要求，我们需要把它部署到本地。”

• 现实：由于 Runtime 选择从一开始就被固化进架构，团队不得不把 Agent 重建三遍

真正占据优势的团队，会把 Runtime 视为部署选择，而不是架构选择。

LiteLLM Agent Platform 实现了这种模式：Agent 在平台上注册，只需定义一次逻辑，平台便会将执行任务路由到最适合当前工作负载的 Runtime。纯云端部署使用 AWS AgentCore；长周期自主任务使用 Claude Managed Agents；需要数据主权保障时，则使用自托管基础设施。

同一套 Agent 逻辑，不同的 Runtime，转换工作全部交给 Control Plane。

判断 Control Plane 成熟度的五个问题

评估 Agent 平台时，需要将不同关注点拆开来看：

我能否无须重写，就将同一个 Agent 定义部署到多个 Runtime？如果答案是“可以，我们已经帮你实现了”，而不是“可以，但你需要编写自定义代码”，那么你找到的就是基础设施层。

我能否无须重写，就将同一个 Agent 定义部署到多个 Runtime？如果答案是“可以，我们已经帮你实现了”，而不是“可以，但你需要编写自定义代码”，那么你找到的就是基础设施层。

平台是否将 Runtime adapter 作为一等能力提供？还是你必须自己编写转换逻辑？

平台是否将 Runtime adapter 作为一等能力提供？还是你必须自己编写转换逻辑？

我能否将一个正在运行的 session 从一个 Runtime 迁移到另一个 Runtime？这正是真正的 Control Plane 与简单 wrapper 之间的分界线。

我能否将一个正在运行的 session 从一个 Runtime 迁移到另一个 Runtime？这正是真正的 Control Plane 与简单 wrapper 之间的分界线。

我的审计轨迹是否跨 Runtime 统一管理？还是我必须调试散落在多个平台中的执行日志？

我的审计轨迹是否跨 Runtime 统一管理？还是我必须调试散落在多个平台中的执行日志？

我能否针对每个 Agent 单独更换 Runtime，而无须重新部署？还是说，每个 Agent 一旦选定 Runtime，就会被终身锁定？

我能否针对每个 Agent 单独更换 Runtime，而无须重新部署？还是说，每个 Agent 一旦选定 Runtime，就会被终身锁定？

如果你对其中大多数问题的回答都是“可以”，那么你看到的是真正的 Control Plane 基础设施。如果得到的回答是“这个功能需要你自己开发”，那么你找到的是一个能让 Runtime 选择成为运维决策、而非架构决策的平台。

你的技术栈会发生什么变化

如果你原本打算选定一个 Runtime 后长期绑定，那么在 2026 年 8 月，正确的做法是：

• 将 Agent 构建成可移植的定义，包括 prompts、tools 和 memory schemas

• 通过能够抽象 Runtime 细节的 Control Plane 来运行它们

• 根据工作负载选择最合适的 Runtime 进行部署

• 保留无须修改代码即可迁移 Runtime 的能力

重点不在于购买“最好”的 Runtime，而在于：既然你已经知道整个行业正在基础能力层面趋于一致，就不要让 Runtime 选择成为新的锁定点。

Runtime 会继续改进。在行业标准出现之前，各家的 API 很可能还会继续分化。在市场尘埃落定之前，Control Plane 就是你用来对冲锁定风险的保障。

2023—2024 年，LLM-only gateway 已经让我们认识到：模型提供商的选择很重要，但不应该被固化进应用逻辑。如今，同样的经验也完全适用于 Agent Runtime。

选择最适合工作负载的 Runtime，但要确保你的 Control Plane 允许你随时改变主意。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报其滥用行为。