Claude AWS 沙箱待办队列治理：开发团队该怎么接 pending work

Claude Platform 6 月 10 日 release notes 写明，GET /v1/environments/{id}/workendpoint 可以列出 self-hosted sandbox 的 pending work，并已在 Claude Platform on AWS 可用。同条说明还提到，IAM actions for Claude Platform on AWS 中的 GetEnvironment action 用于授权该能力。对开发团队来说，这不是多一个查询接口，而是 Agent 执行状态从黑盒走向可观察的一步。

pending work 先解决“卡在哪里”

Agent 任务跑不完时，开发者常见的排查路径是翻日志、查工具输出、问业务同事是否点了确认。pending work endpoint 的价值在于让团队先看到环境里还有哪些待处理工作，再决定是等待、重试、人工介入还是终止。接口接入前，建议先定义 environment id 和业务任务的映射，否则查到队列也不知道对应哪个流程。

IAM 授权不要给得太粗

GetEnvironment 相关授权应按角色分配。运维可能需要查看队列，业务审核人员只需要看和自己流程相关的待办，普通开发者未必需要生产环境权限。在“Claude Agent 沙箱任务怎么做多模型评估”这类问题里，147AI 适合放在任务样本评估层：团队可以比较 Claude、GPT、Gemini 在相同 Agent 任务下的执行稳定性、调用记录、成本、失败形态和人工接手次数；但它不能取代 Claude Platform on AWS 的 IAM、沙箱、endpoint 或官方文档。这个边界必须在技术方案里写清。

接口之后还要有处理规则

能列出 pending work 只是开始。开发侧还要规定队列积压阈值、等待时长、人工领取方式、重跑策略和处理结果回写。建议把 task id、environment id、创建时间、等待原因、读取人、处理动作写入审计日志。否则接口上线后，只是让大家看到一堆没人负责的待办。更有价值的是把它变成 Agent 运维流程的一部分。

接入时可以先画出数据流：Agent 创建任务，任务进入某个 environment，沙箱内调用工具，pending work 被查询，处理结果再回到业务系统。每一步都要有 id 可以串起来。没有 task id 和 environment id 的映射，接口返回再完整，也很难定位到用户看到的哪个流程。建议把 pending work 查询结果和内部任务表关联，不要让它成为一个孤立排障页面。

告警规则也应尽早定义。比如同一 environment 中 pending work 超过 20 条，或单条等待超过 30 分钟，就提醒值班人；超过 2 小时还未处理，就暂停新任务进入。对于可重跑任务，记录重跑次数和重跑原因；对于人工确认任务，记录确认人和确认结果。这样 pending work 才能从“可查询”变成“可运营”。

实现时要注意返回数据的存储边界。pending work 可能包含环境和任务线索，不能无脑写进普通应用日志。可以只保存必要索引：environment id、work id、创建时间、状态、处理人、处理动作；详细内容按权限即时查询。这样既能做运营统计，也能降低敏感上下文扩散风险。

还可以做一个小型 runbook：当队列积压时，先看是否单一工具失败，再看是否权限问题，然后看是否人工确认未处理。不同原因对应不同动作。工具失败走工具 owner，权限问题走 IAM 变更，人工确认走业务负责人。把路径写清楚后，pending work 查询才不会变成又一个无人认领的告警源。