空 200：AgentCore 上线初期的静默失败

圈内内参｜这篇记一个问题：一个上线一个月的新服务，怎么把“失败”包装成“成功”。服务是 AgentCore，AWS 6 月刚推的 agent 托管运行时，管容器部署、扩展、内存、调用那一层。7 月一位开发者在上面用 CrewAI 和 Bedrock 搭了个简历定制 agent，撞上一串坑。先放结论：这串坑几乎都不报错——该返回 200 就返回 200，该说成功就说成功，然后什么都没发生。（确认）

最典型的是这个。invoke-agent-runtime 调用返回 200，响应体是空的，CloudWatch 里既没有日志也没有错误。查了半天，原因就一句话：IAM 角色缺了 bedrock:GetAgentRuntime 权限。权限不足没有给 403，没有给 AccessDenied，给的是一个干干净净的 200。再配上没有日志，你连排查的起点都找不到。这条在他的记录里有完整的复现过程（确认）——对需要事后追溯的系统，空 200 比明晃晃的 500 可怕得多。

另外几个坑我就不逐个展开了，都指向同一个模式（分析）。PyPI 上有个叫 bedrock-agentcore-client 的包，装得上、导不进、不报错——真正的 SDK 不在 PyPI，在 AWS 自己的 CodeArtifact 私有仓库里。这个包的作用我到现在也没想明白——防抢注也好占坑也好，对按文档操作的用户来说就是一个干净利落的暗桩。容器要求以 UID 1000 运行，这个约束官方文档没写，只出现在 AWS 的 GitHub 示例 Dockerfile 里，不满足的话容器通过健康检查、约 30 秒后死亡，控制台只显示一个 Failed 字样、没有日志。资源名只允许字母数字和下划线，不允许连字符——但通过控制台创建时名字不合法，按钮直接无响应，连个错误提示都省了。（未证实，单信源）

把这些坑摆在一起，能看见一个共同的设计倾向：系统接受错误输入，返回成功状态，不执行操作，且不产生任何错误信号。（分析）这个倾向对 agent 生态尤其危险——agent 调用链是自动化的，没有人在每一层用肉眼看响应体、看日志。空的 200 会被当成成功一路传下去，直到最终产物出现偏差。如果这个 agent 在生产里用，你拿到的是一个“分析过但实际什么都没做”的结果，而且你大概率不会知道。（分析）

坦白信源边界：这条记录主要来自他 7 月贴出的技术记录，单信源，未做交叉验证。他自己也提了一句，这些错误发生在 AgentCore 刚 GA 的版本上，后续可能已修复。所以这里记的是“当月实况”，不是“现在的状态”。单信源的东西我一般标着放，这次放出来是因为几个坑的一致性比单条指认更能说明问题——它们全指向同一个倾向。

权限、审计、可观测性，这是最近记录 agent 运行时绕不开的三个词。AgentCore 这一版在这三个词上的表现都值得记一笔：权限错了给 200，容器死了没日志，验证失败不提示。文档和示例还没对齐，错误信号设计还没到位，这个状态本身就是成本——任何人踩进去，都得先付一笔排查时长的学费。这个平台撑不撑得住生产负载，工程团队会用脚投票，这个我不下判断，记到这儿。

几个值得盯的信号：

一、官方文档仓库什么时候补上 UID 1000 和资源命名的说明——文档修正速度是服务成熟度最直接的指示器。

二、PyPI 上那个占位包是下架还是换成可用的真包——挂的时间越长，说明发布管道越没把用户当回事。

三、后续 changelog 里有没有出现“空响应加日志”“权限校验前移”这一类的条目——有，说明错误信号设计在被补全；没有，说明这个坑还会继续埋新用户。

本期到这，有更早踩过同一个坑的同学欢迎匿名补充。