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 查询才不会变成又一个无人认领的告警源。