AI 科技新聞

Spring AI 搭配 Amazon Bedrock：Java 團隊如何從聊天走到可執行任務的代理？

Java 團隊可以沿用熟悉的應用架構，但工具權限與失敗處理仍要一起設計。本文整理Spring AI的更新、適用情境、關鍵數據與限制，並附官方來源及延伸閱讀。

Spring AI 與 Amazon Bedrock 代理架構官方主視覺。來源：官方／原作者頁面。

企業已經有 Java 服務、部署流程和維運人員，導入 AI 代理不一定需要重建整套技術。更實際的問題是：如何讓模型在既有系統裡可靠地使用工具？

AWS 官方公告 11 月 11 日公開 Spring AI 與 Amazon Bedrock 的實作，從旅行助理走到多代理文件處理。

Spring AI 是讓 Java 應用整合模型與工具的框架；Bedrock 提供模型服務，AgentCore 則負責代理執行等基礎能力。

這份方案的價值在於把熟悉的開發方式接到代理工作，而不是只示範一個會聊天的視窗。

但接上模型後，外部工具權限、對話記憶與失敗時如何交回人，仍要一起驗證。

Spring AI 與 Bedrock 各自負責什麼

Spring AI 讓開發者沿用 Spring 的組裝方式，把模型呼叫、工具和應用邏輯放進同一個專案。對既有 Java 團隊，這能降低整合陌生環境的負擔。

官方範例透過 Bedrock 呼叫模型，並使用 AgentCore 的執行與記憶能力。記憶指的是保存對話脈絡，讓後續問題可以接著先前內容處理。

文章列出 JDK 21、Spring Boot 4.1 等版本前提。實際導入應依範例與相依套件一起核對，不宜只更新其中一個套件。

旅行助理是較容易理解的起點：模型依問題選擇天氣或行程工具，應用程式執行工具，再把結果交回模型繼續整理。

這個流程讓回答能使用外部資料，但每個工具仍需要明確的輸入與錯誤處理。查詢失敗時，助理應能交代缺少什麼，而不是自行補出結果。

本文建議先使用查詢型工具，核對對話延續、參數與回覆。等讀取流程穩定，再評估是否加入會修改業務資料的操作。

官方的進階方案依文件類型分派專長代理，再接規則引擎、警示與人工複核。規則引擎是用明確條件作判斷的程式，能補足模型自由文字的限制。

多代理可以分工，但也會增加交接點。團隊需要知道誰完成分類、誰擷取資料，以及哪一項結果觸發人工確認。

這份公開架構可以作為起點，沒有保證套用後就符合特定產業要求。應以實際文件與錯誤案例驗證整段流程。

它是整合 AI 能力的框架，通常加入既有應用架構。資料存取、商業規則與使用者權限仍由應用設計。

官方建議從單一旅行助理入手。先弄清楚一次工具呼叫與記憶的行為，再增加角色，會比較容易定位問題。

對 Java 團隊，最有用的第一步是把一個可核對的小任務接通，保留每次工具呼叫的證據，再逐步擴大代理可處理的範圍。

免費訂閱 AI 郵報，持續掌握 AI 工具與科技更新。