亚马逊16次迭代后掀桌：Nova Pro+Bedrock Age

16个版本。从v1到v16，团队把Bedrock Agents的每个参数都摸了个遍，最后得出一个结论：这套东西在关键场景下会假装工作。

这是一个医疗预授权平台的真实踩坑记录。他们的AI助手需要帮临床人员审核拒赔案例、核查患者资格、生成申诉信——每个环节都涉及工具调用，容错率极低。

选Nova Pro的理由很务实：它是AWS亲儿子，没有调用频次限制，不用担心周二下午两点突然限流。第三方模型在Bedrock上动不动就要申请配额提升或预置专属容量，Nova Pro开箱即用。

团队并非AWS黑。他们明确说：Claude 3 Sonnet仍在处理拒赔信分析，文档解析用另一套模型。不同任务配不同模型，这是常识。但对话式代理需要大规模稳定调用工具，Nova Pro看起来是正确选择。

Bedrock Agents配Action Groups，AWS官方为代理工作流设计的方案。宣传材料给人的感觉是：15分钟就能上生产环境。

实际距离：远不止15分钟。

v1到v16：一场漫长的幻觉

团队最初用Claude 3 Sonnet跑Bedrock Agents，配置了6个工具。16个迭代版本里，他们调过提示词、改过Action Group结构、试过各种显式指令。

结果始终如一：代理热衷于"聊天式回应"，而非实际调用工具。

用户问"帮我查一下这个案例"，代理回复："我很乐意帮您查一下这个案例！"然后——没有然后。工具没被调用，就像那个每条Slack都回"好问题，我去看看"然后永远没下文的同事。

提示词再明确、Action Group结构再清晰，代理依然选择表演性忙碌。

团队决定换Nova Pro试试。然后遇到了这个：

dependencyFailedException: Dependency resource: received model timeout/error exception from Bedrock

错误信息极具误导性，听起来像是配置问题。团队 triple-check，然后 quadruple-check，最后开始怀疑人生。

真相是：当Action Groups介入时，Nova Pro的响应速度赶不上Bedrock Agents内部超时窗口。代理框架对模型响应有独立的超时限制，与Bedrock本身无关。

换句话说，AWS自己的模型配AWS自己的代理框架，在AWS设计的场景里，因为AWS设定的时间限制而崩溃。

被迫造轮子：自定义编排器的诞生

团队最终抛弃了Bedrock Agents，用Nova Pro直接对接自定义编排器。

方案变成：Nova Pro负责意图识别和对话管理，工具调用走独立逻辑层，超时控制完全自主。没有框架黑箱，每个环节的延迟和失败模式都可见。

代价是前期开发量增加，收益是系统终于按设计运行。代理不再假装工作，工具调用从"表演"变成"执行"。

这个案例的讽刺之处在于：AWS同时提供了问题（Bedrock Agents的刚性超时）和解决方案（Nova Pro的无限制调用），但两者组合在一起反而失效。

团队的选择也揭示了当前AI基础设施的一个现状——模型能力与应用框架的匹配，没有通用答案。Claude在文本分析场景稳定，Nova Pro在 unconstrained 调用场景有成本优势，但把它们塞进同一个编排框架，可能两头不讨好。

一个待解的问题

AWS文档至今没有明确标注Nova Pro在Bedrock Agents中的这一限制。团队花了16个版本才确认不是自己的配置错误。