亞馬遜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個版本才確認不是自己的配置錯誤。