![]()
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個版本才確認不是自己的配置錯誤。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.