Agent平台选型指南：三层架构解析

在 2026 年 8 月，agent 平台市场正在分化为不同的类别，而且变得越来越令人困惑。

Agent 框架（LangGraph、CrewAI、Anthropic SDK）— 这些解决 agent 逻辑

Agent 平台（Claude Managed Agents、Bedrock AgentCore、Gemini Enterprise Agent Platform）— 这些提供托管运行时

Agent 基础设施（控制平面、编排、多运行时协调）— 这些解决运维控制

市场将这三者都作为"agent 平台"销售，团队们被迫尝试让纯框架处理基础设施问题，或者让托管平台解答它们根本没有被设计来解决的治理问题。

问题在此：你需要这三者，它们在不同的层级运作。

团队需要的三个层级（且容易混淆）

Layer 1：Agent 逻辑（框架） 你的 agent 的推理、工具调用、状态管理、规划。LangGraph、CrewAI、Pydantic AI 都解决这个。它们在这方面做得很好。

Layer 2：Agent 运行时（托管平台） 执行沙箱、会话隔离、中断/恢复、内置内存。Claude Managed Agents、Bedrock AgentCore、Gemini Enterprise Agent Platform 都提供这个。它们对于单运行时部署来说是生产就绪的。

Layer 3：Agent 控制平面（基础设施） 多运行时协调、凭证集中管理、跨运行时的会话耐久性、per-agent 身份、可观测性、调度、成本归属、评估驱动的决策制定。几乎没有人为 agent 构建过这个。大多数团队在他们的 agent 项目第 3 个月时自己构建它。

agent 平台营销中的沉默假设是：管理 agent 与管理 LLM 相同。它不是。

为什么这很重要

2026 年 6 月刚刚在一周内展示了三个主要的团队级 agent 平台发布：

Cognition 的 Devin Desktop（agent 协调控制台）

Microsoft 的 Rayfin（治理/部署层）

Augment Code 的 Cosmos（fleet 编排）

这表明市场正在从"单个 agent、单个运行时"转向"多个 agent、多个团队、多个运行时"。

在这个规模下，基础设施的缺口变得明显：

在 Claude Managed Agents、Cursor、Bedrock 和内部工具上的 agent 的团队没有统一的方式来跨运行时调用 agent

凭证分散（每个平台的密钥、每个控制台的访问）

成本不可见（每个运行时的支出，而不是每个 agent 的支出）

治理分散（策略变更需要重新部署 agent）

会话不可移植（在一个运行时上崩溃，在另一个上重新开始）

团队通过构建自定义基础设施来解决这个问题。聪明的团队在项目中期意识到这不是一个一周的 sprint。这是一个 6-8 周的架构承诺。

真实的评估框架

当你在 2026 年 8 月评估 agent 平台时，问这些问题。它们将运维基础设施与炒作分离开来。

1. 多运行时支持

问题：我能否在一天在 Claude Managed Agents 上运行相同的 agent 逻辑，第二天在 Bedrock AgentCore 上，而无需重写我的 agent？

要查找的内容：运行时适配器、与运行时选择无关的 agent 注册、带有状态的会话可移植性。

危险信号："选择一个平台并坚持使用它"、"我们与 AWS 集成"、"与 Claude 配合最好"、"你需要自定义代码来支持另一个运行时"。

为什么重要：你在试点时不知道你的生产约束。你需要 SOC2 合规性（6 月），所以你选择 AWS（第 3 个月）。然后你需要在欧盟的数据驻留（第 4 个月）。然后你需要为敏感工作流在本地部署。如果你的 agent 基础设施被锁定在一个运行时上，你每次都在重建。

2. 凭证集中管理

问题：我能否在一个地方管理提供商凭证（AWS 密钥、Anthropic 令牌、GitHub OAuth），而不是每个 agent 每个运行时？

要查找的内容：Vault 集成、凭证作用域限制到 agent（不是全局）、凭证使用的不可变审计日志。

危险信号："每个 agent 有自己的 API 密钥"、"凭证存在于运行时上的环境变量中"、"需要控制台访问来轮换凭证"。

为什么重要：到第 2 个月，你有 3 个 agent。到第 6 个月，你有 5 个 agent 跨 3 个运行时，有 10 个人需要访问。控制台访问变得运维上不可维护。离职团队成员的凭证轮换变成了一场混乱。per-agent 凭证作用域是唯一能规模化的方法。

3. 无需重新部署的 Per-Agent 配置

问题：我能否在不重新部署 agent 本身的情况下更改 agent 的模型、工具权限、速率限制或成本预算？

要查找的内容：配置与 agent 定义分离存储、能够在控制平面中改变策略而无需触碰 agent 代码/容器。

危险信号："配置被烘烤到 agent 中"、"策略变更需要重建容器"、"你需要重新部署来改变模型"。

为什么重要：到第 2 个月，你的 agent 与 GPT-4 一起工作。到第 3 个月，GPT-5 发布并且成本更低。你想在配置文件中交换模型，而不是重新部署。工具权限也是一样的：如果 agent 发现了一个新 API，你不想重建—你想在控制平面中禁用/启用它。

4. 会话耐久性和可移植性

问题：如果 agent 在工作流中途崩溃，我能否从它停止的地方恢复，可能在不同的运行时上？

要查找的内容：Postgres 支持的持久会话、包含状态/内存/执行历史的会话快照、能够重播会话以进行调试。

危险信号："会话在内存中"、"你需要自己实现恢复"、"会话绑定到特定的运行时 pod"。

为什么重要：长时间运行的 agent（24+ 小时、100+ 步）是你的组织的附加值。它们也很脆弱。耐久性是"丢失一天的工作"和"丢失 4 小时的工作"之间的区别。在 5+ 个 agent 同时运行时，会话耐久性变成了运维的基线。

5. 统一可观测性和成本归属

问题：我能否看到哪个 agent 导致了哪个支出？我能否查询跨运行时的所有调用？我能否看到每个 agent 的评估信号？

要查找的内容：per-agent 成本仪表板、可查询的执行历史、与 agent 身份关联的评估指标、精确到工具调用的成本归属。

危险信号："成本是按提供商/模型的"、"可观测性在平台级别，而不是 per-agent"、"你需要连接你自己的日志记录"。

为什么重要：到第 3 个月，你会发现一个 agent 在每个会话中调用昂贵的工具 500 次，而另一个用 3 次调用就达到了目标。你需要看到这个细节，而不是聚合成本。质量也是一样的：评估指标如果你不能将它们归属于特定的 agent，就毫无价值。

6. 确定性授权（不是基于 Prompt 的）

问题：如果 Agent A 试图调用它未授权的工具，该决定是由基础设施做出的（不可能被绕过）还是嵌入在 agent 的训练/prompt 中（可能被解决）？

要查找的内容：调用层工具授权、不可变审计日志显示谁授权了什么、在网关执行的 per-agent 工具作用域。

危险信号："授权在系统 prompt 中"、"护栏是 agent 逻辑的一部分"、"我们依赖模型来遵循指导方针"。

为什么重要：在 2026 年 7 月的事件之后（OpenClaw、Hugging Face、Langflow），审计人员在问："证明给我 Agent A 无法调用删除端点。"基于 prompt 的控制在对抗场景下会失败。基础设施强制执行的控制不会。

7. 多 Agent 协调原语

问题：我能否表达"Agent A 在 Agent B 成功后运行"而无需外部工具？agent 能否相互传递消息？我能否在整个 agent fleet 中设置预算？

要查找的内容：原生调度、agent 间通信、fleet 级资源管理、依赖图。

危险信号："你需要 n8n/Temporal/Prefect 来进行编排"、"agent 独立运行"、"你需要自己管理协调"。

为什么重要：到第 4 个月，单个 agent 就很无聊了。你想要 Agent A 找问题，Agent B 分析它们，Agent C 起草解决方案。没有原生协调原语，你在使用外部编排，这增加了延迟、复杂性和另一个要操作的工具。

行之有效的架构模式

这是我看到团队在从试点转向持续多 agent 操作时采用的：

Agent Logic Layer
    ↓ (defined once, runtime-agnostic)
Control Plane
    ├─ Agent Registry (who exists, what can they do)
    ├─ Credential Management (vault, scoped keys)
    ├─ Policy Enforcement (rate limits, budgets, authorization)
    ├─ Session Management (durable state, resumption)
    ├─ Observability (cost, evaluation, audit trails)
    └─ Scheduling (when agents run, dependencies)
    ↓
Data Plane (Fast Routing)
    ├─ Runtime Adapter Layer
    ├─ Provider Translation
    └─ Load Balancing
    ↓
Agent Runtimes
    ├─ Claude Managed Agents
    ├─ Bedrock AgentCore
    ├─ Gemini Enterprise Agent Platform
    └─ Self-Hosted (E2B, Daytona, etc.)

控制平面是所有决策所在的地方。数据平面是请求快速移动的地方。它们不能组合：治理是有状态的（需要 Postgres、审计日志、授权检查），路由是无状态的（需要 <1ms 的开销）。

如何识别真实的 Agent 平台

在根据上述七个问题评估之后，这些是将真正规模化的基础设施的特征：

它将控制平面与数据平面分离。该平台认识到治理和快速路由是不同的问题。

它将控制平面与数据平面分离。该平台认识到治理和快速路由是不同的问题。

它将 agent 视为一流基础设施。Agent 有持久身份、持久会话、可查询的历史—就像微服务一样，而不像聊天会话。

它将 agent 视为一流基础设施。Agent 有持久身份、持久会话、可查询的历史—就像微服务一样，而不像聊天会话。

它在设计上是运行时无关的。该平台不会将公司命运押在一个托管运行时上。它与运行时一起工作，而不是替代它们。

它在设计上是运行时无关的。该平台不会将公司命运押在一个托管运行时上。它与运行时一起工作，而不是替代它们。

成本、评估和可观测性是烘烤进去的。不是后来才加进去的。不是"你可以与 X 集成"。原生的一流原语。

成本、评估和可观测性是烘烤进去的。不是后来才加进去的。不是"你可以与 X 集成"。原生的一流原语。

它有一个 Rust 或原生编译的数据平面。Python 网关在并发下增加 7-8ms 的每个请求。在 100 个 agent 步骤每个会话时，那是 700-800ms 的纯基础设施税。对于 agent 工作负载，sub-1ms 的开销是基本条件。

它有一个 Rust 或原生编译的数据平面。Python 网关在并发下增加 7-8ms 的每个请求。在 100 个 agent 步骤每个会话时，那是 700-800ms 的纯基础设施税。对于 agent 工作负载，sub-1ms 的开销是基本条件。

多 agent 协调是显而易见的，不是隐藏的。如果你必须问"我如何让 agent 一起工作"，该平台是不完整的。

多 agent 协调是显而易见的，不是隐藏的。如果你必须问"我如何让 agent 一起工作"，该平台是不完整的。

LiteLLM Agent 平台带来了什么

我会直言不讳：我在 LiteLLM 基础设施上工作。完全透明。

LiteLLM Agent Platform (LAP) 完全根据上述模式构建：

多运行时（Claude Managed、Bedrock、通过适配器的自托管运行时）

凭证库（集中、per-agent 作用域、审计日志）

Per-agent 配置（无需重新部署就能改变模型/工具/预算）

持久会话（Postgres 支持、可恢复、可移植）

成本/评估归属（per-agent 仪表板、质量指标）

调用层授权（基础设施强制执行的工具授权）

原生调度（cron、依赖关系、多 agent 工作流）

LiteLLM-Rust 数据平面（0.66ms p99 开销、比 Python 少 11 倍内存、足够快以至于评估驱动的路由变得实用）

它是唯一回答所有七个问题的平台吗？不。但它是专门为需要跨运行时规模化 agent 的团队构建的，这是一个在 2026 年 6 月几乎不存在、现在是市场现实的类别。

真实决策点

在 2026 年 8 月，如果你在评估 agent 平台，你在想"我们的团队将永远在 Claude Managed Agents 上运行所有 agent"，那么你不需要控制平面基础设施。框架 + 托管运行时就足够了。

但如果你在想"我们可能需要 AWS 来进行合规性、可能需要本地部署用于敏感数据，以及肯定需要自托管来进行成本控制"，那么你需要不将你锁定在一个运行时上的基础设施。

那时你会问上面的七个问题。你会发现几乎没有什么能回答所有七个。能做到的那些将在 2026 年第四季度变成基本条件，当团队们艰难地发现"选择一个平台"在规模上不起作用时。

在 2026 年 8 月获胜的团队不是那些拥有最聪明的 agent 或最闪亮模型的团队。他们是那些构建或采用了单调乏味、可靠的 agent 协调基础设施的团队。问那七个问题。选择回答"是"给大多数问题的平台。其他一切都是锦上添花。

你在评估 agent 平台时的经验是什么？你在自己的部署中是否遇到了这七个缺口中的任何一个？在评论中留下来—我正在收集关于生产 agent 系统中实际重要的真实操作员信号。