在 Amazon ECS 上通过 LiteLLM 网关接入 OpenAI Codex 与 Amazon Bedrock

OpenAI Codex 是一款运行在开发者本地工作站的 AI 编码智能体，能够读取本地代码仓库、执行经批准的工具，并完成多步骤工程任务。其任务循环在本地沙箱内运行，但模型推理请求可以被路由至客户 AWS 账户内的基础设施。这一架构分离使企业得以在不改变开发者工作流的前提下，对每一次模型调用实施集中管控，而非依赖分散在各工作站的凭证配置。

本次方案的核心是将 LiteLLM 部署为 Codex 与 Amazon Bedrock 之间的共享控制节点。请求流程分为五个步骤：Codex 将任务上下文与工具定义发送至网关的 /v1/responses 端点；Application Load Balancer 与 AWS WAF 完成网络层与 Web 层防护后将请求转发至 Fargate 上的 LiteLLM；LiteLLM 验证调用方身份、检查模型别名与消费策略，再以 ECS 任务角色调用 Bedrock；Bedrock 返回文本或函数调用结果；若模型请求工具执行，Codex 在本地沙箱完成后将结果通过 LiteLLM 发回，循环继续。

LiteLLM 在此模式中承担多项企业级控制职责：仅允许经审批的模型别名通过、为用户或团队签发作用域受限的虚拟密钥、设置硬性预算上限及每分钟请求数或令牌数限制、集中管理路由与故障转移策略，并在上游模型共用同一 ECS 任务角色时保留网关层面的身份归因。配套基础设施包括 Amazon RDS for PostgreSQL 存储使用量与预算数据、Secrets Manager 与 KMS 管理密钥、CloudWatch 提供日志与告警、ECR 存储不可变网关镜像，以及可选的 WAF 托管规则与源 IP 速率限制。

部署流程从克隆官方参考仓库 guidance-codex 开始，通过环境变量文件配置 AWS Profile、区域、来源 CIDR、TLS 证书及 DNS 信息。生产环境建议启用 TLS、WAF、RDS 多可用区以及自动扩缩容（最小 2 个任务、最大 10 个任务）。网关别名 openai.gpt-5.5 在 LiteLLM 配置中映射至 bedrock_mantle/openai.gpt-5.5，模型可用性因账户和区域而异。部署完成后需验证语义续写、流式传输与函数调用三项核心能力是否正常工作。

在选型层面，AWS 提供了三条路径供团队参考。若原生 IAM 策略与 CloudTrail 日志已满足合规要求，直接访问 Amazon Bedrock 是复杂度最低的选择。当团队需要跨开发者、跨团队或跨模型提供商的一致性额外控制时，自托管 LiteLLM 网关更为合适，但团队须承担网关可用性、数据库生命周期、版本升级、事件响应与容量规划等全部运维责任。若希望降低运维负担，托管网关 Portkey 则是第三条路径。三种方案各有侧重，企业应结合自身运维能力与合规要求综合评估。

要点

• LiteLLM 部署于 Amazon ECS Fargate，作为 Codex 与 Amazon Bedrock 之间的统一控制平面，实现模型鉴权、预算、速率限制与路由的集中管理。
• Codex 的本地工具执行循环保持不变，仅将模型推理请求路由至客户 AWS 账户内的网关，两者职责边界清晰。
• 配套基础设施涵盖 RDS、Secrets Manager、KMS、CloudWatch 与 WAF，满足企业对状态存储、密钥安全与可观测性的要求。
• 自托管 LiteLLM 的主要代价是运维责任，团队须自行负责网关可用性、数据库维护与版本升级。
• AWS 同时提供直接 IAM Identity Center 访问和托管网关 Portkey 两种替代方案，适合不同运维能力与合规场景的团队选用。