AI Gateway 正在升维：从模型路由到 Agent 会话路由

过去，你对 AI gateway 的核心决策很简单：调用哪个模型、在哪个 provider 上运行、使用什么 fallback 策略。现在这个决策正在扩展。AI 工程团队已经把 agent 部署在多个 runtime 上——Claude Managed Agents、Bedrock AgentCore、Vertex Agents 以及自托管的 harness——并且发现没有任何一个 runtime 能覆盖所有工作负载。

LiteLLM 工程团队上周发布的架构分析把这个演变说清楚了：AI gateway 正在升维。 路由的原语不再是模型调用，而是 agent 会话。

LiteLLM 架构文章的核心论点

核心观察是：企业不会把所有 agent 都集中在同一个 runtime 上。编码 agent 跑在 Bedrock AgentCore 或 Claude Managed Agents 上；数据 agent 在 Databricks 或 Snowflake 里运行；内部流程 agent 运行在自定义基础设施上。当 agent runtime 碎片化之后，团队需要一个能跨 runtime 注册、调用、观测和治理 agent 的统一层。

LiteLLM 的文章把这个逻辑直接对应到了我们熟悉的模型栈：

• 模型 → Agent harness。 调用的原语从模型变成了 harness（Claude Code、Codex、DeepAgents）。
• 推理 provider → Agent runtime。 你把 agent 工作路由到 Claude Managed Agents、Bedrock AgentCore、Vertex Agents 或自托管环境。
• 模型 gateway → Agent 控制平面。 Gateway 必须管理 agent 会话、调度、内存和多 runtime 调用——不只是转发 API 请求。
• 开放缺口。 目前还没有成熟的 agent harness 高速推理层，也没有占主导地位的 agent 控制平面。

对 AI 工程团队的三个路由影响

1. 会话状态成为一等路由关注点。 模型调用是无状态的：发请求，收 token。Agent 会话是有状态的：携带工具上下文、内存、中间输出和子 agent 委托。你的路由层必须知道是恢复现有会话还是创建新会话——以及在哪个 runtime 上。从一个 runtime fallback 到另一个不再是简单的 header 替换，可能需要会话迁移或冷启动开销。

2. 成本归因必须追踪会话工作，而不只是 token 用量。 当一个用户请求扩散到编码 harness、内存检索调用和三个工具调用时，billing 归因不能止步于输入/输出 token 数量。团队需要按会话汇总跨 runtime 的模型成本、计算成本、内存成本和工具调用成本的会话级账单。

3. Provider 依赖风险成倍放大。 模型级 fallback（Claude Fable 5 超时就切换到 Kimi K2.7 Code）已经相对成熟。Agent 级 fallback 还没有：如果 Claude Managed Agents 降级，你的团队能把同一个 agent 会话路由到 Bedrock AgentCore 吗？答案取决于 API 兼容性和会话可移植性——两者目前都还没有标准。

Router/Operator 视角

LiteLLM 的文章指出 gateway 是自然的统一层，因为它已经在管理模型凭据、限流、fallback 和消费追踪。扩展到 agent 会话是能力扩展，不是产品转型。

对路由团队来说，实际问题是：

• 你的 gateway 需要对接哪些 runtime？ Claude Managed Agents（api.anthropic.com/v1/agents/）、Bedrock AgentCore（AWS SigV4 流程）、Vertex Agents（GCP Auth）以及自托管 harness 都有不同的调用接口。你的 gateway 必须支持它们，或者依赖适配层。
• 会话状态放在哪里？ 如果 gateway 是控制平面，它必须要么持有会话存储，要么把会话引用干净地代理给各 runtime。跨 runtime 泄露 session ID 是数据边界故障。
• 你的 agent 级 SLA 是什么？ 大多数团队现在有模型级 SLA（p99 延迟、fallback 预算）。Agent 级 SLA 需要就"失败"对长期运行会话意味着什么达成共识——超时、错误率还是成本上限——并把每种情况映射到 runtime 级操作。

TheRouter 用户应该关注和尝试什么

从模型路由到 agent 会话路由的转变不需要立即重建你的 gateway，但需要更新你的架构规划：

1. 梳理你已经在使用的 agent runtime——哪怕是非正式使用的。团队经常发现自己同时通过 Claude Code 企业订阅跑在 Claude Managed Agents 上，又通过 AWS 栈用着 Bedrock AgentCore。
2. 在现有可观测性中添加会话级标签。 即使你的 gateway 今天只路由模型调用，为请求打上 agent session ID 和 harness 类型标签，也能为未来的控制平面迁移准备好日志管道。
3. 关注 Anthropic 和 AWS 的动态。 Claude Managed Agents 和 Bedrock AgentCore 是英语区工程团队最有可能率先落地的多 runtime agent 起点。它们的调用 API 有任何变化，都是重新审视路由策略的触发点。

对于今天已经在使用 TheRouter 做 provider 路由和 fallback 的团队，自然的延伸是评估你的路由规则是否应该感知 harness 类型，而不只是模型 ID。被标记为 Claude Code 会话的请求，可能需要与单轮推理调用完全不同的超时、重试和成本上限策略。

LiteLLM 描述的架构转变目前仍是方向性的，尚未全面落地。但现在就更新路由抽象——把模型策略和会话策略分开——的团队，将在 agent 控制平面成为标准基础设施时避免大规模返工。