AWS 企业指南：Codex 接入 Bedrock 先走最简路径，配置边界比身份验证更关键

平台团队面临一个具体矛盾：开发者已经在用 Codex 探索代码、做修改、处理重复工程工作，但如果每个团队各自配置模型访问，就会在组织内形成第二套身份、路由和运维栈。AWS 机器学习博客给出的解法不是统一工具，而是统一接入路径的决策规则。

核心论点在文章结论中明确表述：从满足需求的最简访问路径起步，用小试点证明身份和模型通路，只在解决特定需要时才添加网关或客户端控制。文章将路径分为三层。第一层是 Native AWS Access，适用于 IAM 和身份控制已经足够的场景，开发者通过 IAM Identity Center 获得临时凭证，Codex 直接调用 Amazon Bedrock Runtime。第二层是 AgentCore Gateway，适用于需要 AWS 托管的路由基础设施或 Bedrock Guardrails 的团队。第三层是 LLM Gateway，适用于已经运行网关或需要在请求路径中强制执行控制的组织。自定义集成是第三层的高级变体，不是快速起步选项。

决策规则本身不复杂，但验证序列比路径选择更容易被跳过。文章要求试点包含三个检查：先用 AWS CLI 直接调用 Bedrock Runtime 确认 IAM 权限和区域可用，再配置 Codex 指向批准的模型，最后跑一个安全的只读任务。两个用户才能测试身份隔离——单人只能证明登录成功，第二人才验证归因是否保持独立。

最值得平台工程团队注意的是配置边界这一节。文章明确指出：模型提供者、凭证和区域设置属于用户级或托管配置，因为它们是端点和组织选择，不是仓库默认值。项目本地的 .codex/config.toml 是仓库范围配置，应当作为代码审查，但不能当作企业执行边界。AGENTS.md 适合承载持久性仓库指导，如测试命令和编码规范，但它同样不是执行边界。这个区分意味着：如果组织的安全策略依赖仓库文件来约束模型访问，那么任何开发者都可以通过修改仓库配置绕过它。真正的边界在用户级配置、IAM 策略和 requirements.toml 中。

治理层面，文章把遥测、计费和身份记录视为回答不同问题的证据源。Codex OpenTelemetry 描述客户端活动（token 用量、轮次、API 请求、工具调用），Amazon Bedrock 服务指标描述服务端活动（延迟、输入输出 token、错误率），AWS 身份记录和 Cost and Usage Report 提供归因和计费证据。文章特别警告不要把 token 量当作成本报告，也强调遥测不能建立正确性或安全性——它只记录发生了什么，不判断是否应该发生。