把 Claude Code 编码任务放进 AWS 隔离会话

把 Claude Code 放到远程运行，难点不只是让它持续写代码，还包括凭证交给谁、代码在哪里执行、测试失败怎么办，以及谁来决定合并。AWS 这篇文章给出了一套基于 Amazon Bedrock AgentCore 的示例：每个任务独立运行，最后交回一个 GitHub pull request。

它的价值在于把任务委派、执行隔离和人工审查串成了一条流程。但这不是一套部署后就能放心托管所有开发工作的系统。可信仓库、明确的验证命令和受限的任务范围，都是它成立的前提。

远程代理交回的应该是可审查的改动

本地 Claude Code 通常需要开发者边看边调整。远程代理把交互变成了任务交接：提交需求后，开发者可以关掉电脑，多个任务也不必争用同一台机器。

代价同样明确。任务执行中更难及时纠偏，环境需要提前准备，费用也更难预测。因此，作者把适用范围限定为可信仓库里的小功能、缺陷修复和测试补充，不适合不可信代码，也不适合目标模糊的开放任务。

示例 sample-remote-coding-agent 给每个仓库创建一个 AgentCore runtime，每个任务再启动独立 session。容器包含 Claude Code CLI、Claude Agent SDK、git 和 make；session 运行在独立 microVM 中，隔离 CPU、内存和文件系统，结束时清理内存。

任务内部也有分工：Claude Opus 负责规划，Claude Sonnet 编码，随后执行仓库自己的安装和测试命令，再由 Claude Opus 审查。审查可以要求重新规划，但总共最多尝试 3 次。

每一步都会更新 DynamoDB 状态，并向 AgentCore memory 写入过程信息。后者会提取仓库经验，例如某个构建步骤依赖一个容易遗漏的前置操作，供后续任务使用。临时执行环境会销毁，经验则跨任务保留。

最终，代理推送 agent/<taskId> 分支并创建 PR，描述里记录验证命令、退出码和尝试次数。验证通过且模型审查通过，对应 SUCCEEDED；测试未通过则以草稿交付，对应 SUCCEEDED_UNVERIFIED。

任务执行结束，不代表改动可以合并。

代理永远不合并，默认分支还需要开启 branch protection，把人工审查落实到仓库规则里。

安全控制分了几层，每层都有边界

Amazon Bedrock 承担模型调用这一层。按原文描述，它不使用客户内容训练模型，也不向模型提供商共享这些内容；团队可以沿用 AWS 账单、CloudTrail 审计和 IAM 临时凭证，并通过地理推理配置控制数据驻留。

远程 session 只使用 Amazon Bedrock 作为模型提供方，通过私有端点调用，由 runtime 的 IAM execution role 签名。容器不持有其他 AWS 凭证，角色权限也被限制在 Anthropic 模型、本仓库任务记录和 memory 等资源内，并被显式禁止访问 AgentCore Identity 控制面。

数据保留还需要单独配置。原文提到 Mantle 的零运维访问设计（ZOA），以及可配置的零数据保留（ZDR）。但示例部署不等于已经开启 ZDR：上线前仍要确认部署 Region 和所用模型支持它。数据驻留有要求时，也要替换示例默认的 global inference profiles。

GitHub 权限由 AgentCore Identity 管理。GitHub App 获得 Contents 和 Pull requests 读写权限，只安装到获准修改的仓库；用户通过三方 OAuth（3LO）授权后，容器取得 8 小时过期、可自动刷新的 user-to-server token。可访问范围同时受 App 安装列表和授权用户权限约束。

提示词入口则经过 ApplyGuardrail API。示例使用 Amazon Bedrock Guardrails 的 Standard tier，低强度过滤越狱、提示注入、不当请求和密钥；拦截时返回 PromptBlockedByGuardrail，服务无法响应时也拒绝任务。

但它只检查用户提交的任务，不检查执行中读到的仓库文件和命令输出。恶意指令仍可能从这些位置进入上下文。作者解释，逐次检查模型调用会重复计费，还可能把 Claude Code 自身的系统提示词判成注入。

网络也并非完全封闭。AWS 服务通过 VPC endpoints 访问，GitHub 和包仓库通过 NAT gateway，安全组只允许出站 HTTPS。Route 53 Resolver DNS Firewall 会屏蔽 api.anthropic.com 等域名，但黑名单挡不住其他 HTTPS 目的地。原文建议生产环境考虑 AWS Network Firewall 域名白名单。

独立 microVM 能隔离执行资源，不能让不可信仓库里的命令自动变安全。

开跑之前，先准备验证契约和费用预算

提交任务有两条入口：网页由 CloudFront 提供，通过 Cognito 登录；本地 Claude Code 则使用 sample-rca 插件启动 MCP server，用 AWS 凭证签名请求。任务进入 API 后，由 Lambda 筛查、写入 DynamoDB、进入 SQS，再由 dispatcher 启动 session。

对前端团队更有参考价值的是任务描述。原文这个例子同时规定了功能、逻辑边界、测试范围和交付命令：

/sample-rca:remote Build a 2048 game as a Vue 3 single-page app. Keep the board and merge
logic in a plain module with Vitest tests covering spawn, merge, win and game over. Add
scripts.setup, scripts.test and scripts.dev to package.json, and a README whose first
section is the exact commands to install it, run it in a browser, and test it.
/sample-rca:remote status

要关注的是 scripts.setup、scripts.test 和 Vitest 覆盖要求：它们让代理知道怎样验证，也让人知道交付证据应该是什么。仓库需要根目录 Makefile 的 setup、test targets，或 package.json 的 scripts.setup、scripts.test。

部署需要运行中的 Docker、Python 3.11+、uv 和 Node.js 22.12+，本地会构建约 1.3 GB 的 ARM64 镜像。原文使用 us-west-2，支持列表还包括 us-east-1、us-east-2、ap-northeast-1、eu-west-1，要求 AgentCore runtime V2。

流程依次执行 make setup、make preflight 和 make deploy EMAIL=you@example.com。部分资源固定部署到 us-east-1，跨区部署也需在那里 bootstrap，文中指定 aws-cdk@2.1138.0。部署约 15–25 分钟，注册仓库还需 8–12 分钟；任务返回 ID 只需数秒，执行则可能持续数十分钟。

更容易漏掉的是闲置费用。NAT gateway、interface endpoints、AWS WAF 等仍会计费。默认每月 $200 的 Amazon Bedrock budget 只发送邮件，不限制支出；原文没有公布成本估算。

清理必须先逐个注销仓库，再断开 GitHub，最后销毁 stacks。仓库 runtime、IAM role、memory 和 Identity 授权不归 stacks 管，顺序错了会残留。stack 删除还会保留表、用户池、日志和镜像，需要另外处理。

我的判断

这套方案说得对的地方，是把远程开发的交付物定成带验证记录的 PR。模型负责推进任务，仓库命令提供执行证据，分支保护保留人的最终决定，责任比较清楚。

不过，作者没有给出任务成功率、平均费用，也没有提供 Opus 规划与审查、Sonnet 编码相较单模型方案的对照数据。这个分工目前应当视作示例设计，不能据此断言质量更高或成本更低。

对于已经使用 AWS、需要 IAM 和私有网络控制的团队，它有明确吸引力。对于只想异步补几个测试的小团队，现有 CI 临时执行器加人工审查也值得比较。原文没有证明 AgentCore 在成本或效果上更优，而它确实带来了更多服务和运维步骤。

此外，测试通过只能说明声明的检查通过了。UI 是否符合预期、测试是否覆盖需求、memory 提取的经验是否可靠，仍需要额外判断，原文也没有给出完整答案。

能拿来做什么

• 先挑一个可信的小型前端或 Node.js 仓库，把安装与测试命令固定下来，再提交只涉及测试文件的任务，观察代理交回的验证记录是否完整。
• 写任务时同时写清功能边界、允许修改的文件和验收方式。2048 示例里拆分纯逻辑模块、指定 Vitest 场景的方式，可以直接借鉴。
• 审查 PR 时，把 diff、测试命令、退出码和尝试次数一起看；遇到 SUCCEEDED_UNVERIFIED，应先补齐验证，再判断实现是否可用。
• 若要部署示例，先用独立 AWS 账户核对 GitHub App 范围、ZDR 和数据驻留设置，并按注销仓库、断开 GitHub、销毁 stacks 的顺序完成清理。