Bayer Crop Science 如何透過 Amazon Bedrock AgentCore 與 AWS Unified Operations 建構 Agentic Decision Engine(ADE)
How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations
Bayer Crop Science 基於 Amazon Bedrock AgentCore 建構 Agentic Decision Engine(ADE),作為 Connected Decision Engine(CDE)的多智能體自然語言介面,讓用戶查詢工作流程狀態、結果、模型行為及故障。
文章整理 ADE 從設計到投產的關鍵工程取捨,涵蓋狀態持久化、身份與工具權限、任務級監測及成本歸因,提供多智能體系統落地的具體參照。
植物育種決策依賴涵蓋基因組學、田間試驗、影像、環境條件及模型輸出的數據。Bayer Crop Science 會針對不同作物、地區及團隊,使用這些數據執行數百種機器學習(ML)模型配置,而每次執行都必須可重複,並符合管治要求。為滿足這項要求,Bayer 建立了 Connected Decision Engine(CDE),用於部署、編排、監察及重用 ML 工作流程。CDE 為育種人員、分析師、研究人員、數據科學家及數據工程師提供一致的分析執行方式,同時保留執行記錄及營運控制措施。
隨着採用日漸普及,瓶頸由執行工作流程轉為理解工作流程。要解釋結果,就得從 API、文件、元數據儲存庫、儀錶板及日誌中拼湊背景資訊。想了解工作流程為何失敗、模型執行了甚麼操作,或結果來源的用戶,仍須知道應該檢查哪個系統。為解決這個問題,Bayer 建立了 Agentic Decision Engine(ADE),一個建基於 CDE 的多代理自然語言介面。主管代理會將每個問題分派給專責代理,由專責代理從相關系統擷取背景資訊,用戶便可直接收到答案,無需在營運系統架構中逐一查找。ADE 在第一階段無需工程師介入,便能解答約 80% 的用戶問題。
ADE 在 Amazon Bedrock AgentCore 上運行。這項 AWS 服務可讓用戶使用任何框架或模型,大規模建置、連接及最佳化代理。AgentCore 讓團隊可以專注於代理的行為,而無需自行建置及營運代理託管、工作階段隔離及工具存取層。三項 AgentCore 功能促成了這項選擇:可隔離每個用戶工作階段的受管執行環境;透過 Amazon Bedrock AgentCore 的一項功能 AgentCore Gateway,提供由 AWS Identity and Access Management (IAM) 控制範圍的工具存取,讓驗證及授權流程不必寫入代理程式碼;以及不受框架限制的設計,讓團隊可以自行採用 LangGraph 編排方式及選用模型。
為了準備 ADE 上線及在上線後營運,Bayer 聯同 AWS Unified Operations 合作。合作安排提供了一名指定技術客戶經理(TAM)及一名生成式 AI 領域專家工程師(DSE),從設計階段到正式投入生產期間,兩人一直作為 ADE 團隊的延伸成員共同工作。TAM 作為 Bayer 的策略顧問,對 Bayer 的營運模式及業務優先事項已有深入瞭解;DSE 則帶來 AWS 上生成式 AI 領域的專業知識。團隊每週舉行三次技術例會,檢視設計並作出決策。DSE 逐步熟悉 ADE 工作負載及 Bayer 團隊的運作方式,讓技術指引兼顧 AWS 服務的運作方式和 Bayer 的實際情況。本文將介紹這段歷程:ADE 的架構、建置期間作出的五項設計決策、為平台投入生產所做的準備,以及上線後的營運方式。
架構概覽
ADE 分為四個層次:用戶體驗、Agent 編排、專責 Agent,以及這些 Agent 呼叫的工具和數據來源(圖 1)。用戶透過 React 網頁前端使用 ADE,請求會先經過 Microsoft Entra ID 身分識別代理伺服器,再送達 Agent。GitHub Actions 會建置 Agent 容器映像檔,推送至 Amazon Elastic Container Registry (Amazon ECR),再部署至 AgentCore runtime;這是 Amazon Bedrock AgentCore 的一項功能。
Amazon Bedrock AgentCore runtime 負責承載 Agent。由於該執行環境不受框架限制,團隊可直接在其上運行自行建置的 LangGraph 編排。團隊選用 LangGraph,因為它能明確控制圖狀流程,並為多步驟工作流程提供檢查點機制。LangGraph 負責編排工作流程,而 Supervisor Agent 是入口點,負責分類每項請求、選擇專責 Agent,並在問題涉及多個領域時整合結果。數據平面按職責劃分。Amazon DynamoDB 儲存 LangGraph 檢查點狀態。Amazon Aurora PostgreSQL 儲存工作階段記錄、用戶意見及分析數據。Amazon ElastiCache 會快取 Agent 回應,並設定存留時間(TTL)。Amazon Simple Storage Service (Amazon S3) 中的領域內容會使用 Amazon Titan Text Embeddings V2 建立向量嵌入,並在 Amazon OpenSearch Serverless 建立索引,以供檢索增強生成(RAG)使用。Amazon CloudWatch 會收集執行環境及應用程式的遙測數據。AgentCore Gateway 會將後端 API 以 Model Context Protocol (MCP) 工具的形式提供給 Agent,並將身分驗證及授權處理置於 Agent 程式碼之外。
圖 1:在 Amazon Bedrock AgentCore 上運行的 Agentic Decision Engine 架構
ADE 在正式環境中運行 22 個專責 Agent,各自負責一個領域,並使用專屬的工具和數據來源。例如,Domain Expert Agent 透過 RAG 回答概念性問題。Operational Agent 從 CDE 擷取即時工作流程狀態及結果。Troubleshooting Agent 分析營運遙測數據。Visualization Agent 會產生圖表,或提供現有的儀錶板。客戶專屬的 Models as Skill 模式會將模型程式碼及文件轉換為技能定義,並存放在中央登錄庫,讓 Agent 根據模型的實際實作回答特定模型問題,而非依據通用模型知識作答。
當育種人員詢問:「為甚麼我昨天的表型分析工作流程失敗了?」Supervisor 會分類意圖,並將請求轉交 Troubleshooting Agent。該 Agent 會透過 CloudWatch 讀取工作流程的遙測數據,並透過 AgentCore Gateway 從 CDE API 取得工作流程狀態,以找出故障點,再經由 Supervisor 返回診斷結果(圖 2)。育種人員毋須直接搜尋日誌。使用 Troubleshooting Agent 後,過去需要花超過一小時手動搜尋日誌並等待工程師支援的診斷工作,現在不到 10 分鐘便可完成。
圖 2:ADE 請求流程:意圖分類、快取查詢、專責 Agent 路由及回應
邁向正式環境的五項設計決策
Unified Operations TAM 和 DSE 以工作團隊成員身份參與以下決策,而非事後才作為升級處理的支援窗口介入。這讓 Bayer 能在作出承諾前,根據 AWS 服務的實際運作測試每項設計,同時保留對架構及最終決定的主導權。
1. 將編排狀態外置,不要把執行環境視為無狀態
AgentCore 執行環境提供隔離的工作階段,可在工作階段生命週期內的多次呼叫之間保留執行內容。這些內容並非多步驟工作流程的持久化儲存空間。ADE 將 LangGraph 檢查點寫入 DynamoDB,讓圖表在擴展、重新啟動或跨越工作階段邊界後,仍可繼續執行,而不必依賴某個執行環境持續可用。
原則:使用執行環境的工作階段進行目前的執行,並將繼續執行或重建工作流程所需的狀態,儲存在持久化服務中。
2. 區分企業身份、閘道存取及下游授權
Bayer 將 Microsoft Entra ID 標準化為用戶身份系統,而 ADE 的服務則使用 AWS 原生機制互相授權。團隊沒有強行在每個信任邊界使用同一個權杖,而是為每個邊界採用各自的機制。
Entra ID 仍是用戶身份的來源。AWS Identity and Access Management (IAM) 負責服務對服務呼叫的授權。AgentCore Gateway 的出站授權負責存取下游 CDE 服務。請求攔截器 AWS Lambda 函數會執行自訂驗證,並傳遞下游工具所需的授權屬性。團隊與 DSE 一同釐清每一跳的權杖要求。
原則:Agent 系統的身份驗證問題,往往集中在用戶身份、Agent 身份及工具身份之間的轉換。請為每一跳定義發行者、對象、聲明、範圍及憑證有效期,不要在下一個邊界重用只適用於當前邊界的權杖。
3. 將模型選擇視為介面合約
在開發期間,團隊評估了啟用推理模式的新版本模型。對於該版本,ADE 所依賴的工具使用與結構化輸出組合,與其 Agent 的實作方式並不相容。DSE 確認了這項限制,團隊因此在發佈版本中保留目前使用的模型。
原則:對於使用工具的 Agent,模型選擇受整個介面所限,包括工具呼叫、結構化輸出、串流行為、推理功能、延遲、配額可用性及模型特定的請求語義。較新的模型並不一定可以直接替換舊模型。
4. 先控制工具介面,避免它反過來控制提示詞
CDE 管理超過 500 種模型配置。為每個 API 設置專用 MCP 伺服器,會增加部署、驗證及版本管理的開支。ADE 改為向 AgentCore Gateway 登記 OpenAPI 規格,由 Gateway 將 REST 操作提供為 MCP 工具。新增或更改 API,只需更改結構描述和閘道配置,毋須部署新伺服器。
工具結構描述和説明也會佔用輸入 token,並與用戶的請求及檢索到的內容競爭。ADE 按專責 Agent 劃分工具範圍,而不是讓每個 Agent 使用完整目錄。對於較大的目錄,AgentCore Gateway 支援語義工具搜尋,讓 Agent 無須在每一輪載入整個目錄,也能找出相關工具。
原則:按 Agent 劃分工具目錄範圍。每項工具定義都會增加 token 數量,並擴大模型的決策空間。
5. 將複雜功能由工具提升為 Agent
視覺化功能最初是由其他 Agent 呼叫的工具。隨着功能擴展,它需要自行處理資料擷取、圖表選擇邏輯、重試、錯誤處理,以及決定應生成圖表還是傳回現有儀錶板。團隊後來將它改為專門的 Visualization Agent。這個 Agent 會在 AgentCore Code Interpreter 中使用 matplotlib 和 Plotly 按需生成圖表。AgentCore Code Interpreter 是 Amazon Bedrock AgentCore 的一項功能,提供沙盒式程式碼執行環境;Agent 會透過 Amazon S3 與其交換資料。當預先建立的儀錶板更合適時,Agent 會傳回現有的 Amazon Quick 或 Power BI 資產。
原則:工具負責執行範圍有限的操作。當某項能力開始負責狀態、重試、規劃、政策或呈現方式的決策時,應將其建模為 Agent。
為 ADE 作好正式環境部署準備
隨着建置工作逐步邁向推出,焦點由設計轉向可操作性:偵測 Agent 故障、歸因推理成本,以及強化部署。
可觀測性:衡量任務失敗,而不只是例外
監督者架構會將單一用戶請求轉化為一連串模型呼叫、工具呼叫及 Agent 交接。即使每個 HTTP 請求均成功,最終答案仍可能有誤。ADE 直接遇到這個問題:應用程式的例外處理程序捕捉到 Agent 錯誤後,傳回監察系統視為成功的回應。與 DSE 一同重現問題後,團隊在失敗處理路徑中加入自訂 CloudWatch 指標,並針對 Agent 特定情況設定警示:工具呼叫錯誤、節流、模型逾時,以及結構化輸出驗證失敗。追蹤記錄和呼叫記錄會追蹤每項請求如何經過監督者及各專門 Agent。
原則:區分傳輸成功與任務成功。Agent 可觀測性應顯示任務是否完成、哪個 Agent 或工具改變了結果,以及回應是否採用了預期來源。
成本歸因:結合帳單歸因與請求層級遙測資料
單一 ADE 請求可能會呼叫多個模型和工具,因此 Amazon Bedrock 帳戶層級的支出無法説明單位經濟效益。團隊與 DSE 一同設計歸因方案,採用三種分別回答不同問題的機制。Amazon Bedrock 應用程式推理設定檔會將已計費的模型用量歸因至某個應用程式或工作負載。請求中繼資料和模型呼叫記錄會將 Token 用量與特定 Agent、功能或請求連結。IAM 主體歸因則增加身分維度。這些機制結合後,團隊便可估算每次互動的成本、找出成本較高的 Agent,並判斷提示詞、檢索到的內容或工具定義是否推高 Token 用量。實際上,依賴 MCP 工具並會多次呼叫工具的 Visualization 和 Operational Agent,消耗的 Token 最多。
相同的遙測資料在準備推出期間,揭示一個輸入前綴大量重複但沒有使用提示詞快取的工作負載。對於支援的模型,將穩定的指示和工具定義放入可快取的提示詞前綴,可減少重複處理輸入,從而降低延遲和 Token 成本。對 ADE 而言,快取穩定的提示詞前綴令輸入 Token 成本降低 20–30%。
安全與推出準備
IAM 角色的權限範圍按各 Agent 的職責設定。Troubleshooting Agent 可以讀取診斷所需的營運數據,但不能修改工作流程。Domain Expert Agent 可以查詢其檢索索引,但不能呼叫無關的 CDE API。目前在正式環境中,ADE 的 Agent 回應受到多項控制措施規管:遵循最小權限原則、按各 Agent 的範圍設定唯讀工具存取權、驗證 Agent 回應的結構化輸出,以及確保答案建基於檢索所得的 CDE 數據和遙測資料,而非開放式生成。Bayer 亦計劃評估 Amazon Bedrock Guardrails,作為這些控制措施之外的額外防護層,並配合目前已用於 CDE 多輪工作流程的自訂安全檢查。
推出前,Unified Operations 與 ADE 團隊一同進行了 Critical Workload Review,以及採用 Generative AI Lens 的 Well-Architected 檢視。由於 DSE 已熟悉該工作負載,兩項檢視均針對 ADE 特有的失效模式、容量風險和部署缺口,而非一般最佳做法。檢視發現,主管 Agent 與專家 Agent 之間的故障可視度不足、容器映像標籤可變更、映像追蹤能力有限,以及缺少漏洞掃描。團隊其後加強警示、改用不可變更且附有版本號的映像、在 Amazon ECR 中設定推送時掃描,並為未使用的映像設定生命週期政策。
DSE 亦與團隊檢視了擴展和配額要求。負載測試驗證了應用程式及其服務配額,並揭示一種會傳回空白回應的網絡故障模式;團隊在正式活動前修正了這個問題。推出時,團隊已與 Unified Operations 一同追蹤並解決 35 項阻礙。
推出、營運及後續計劃
Bayer 先向受限制的用戶羣推出 ADE,沒有一次過向整個機構開放。推出至今,Bayer Crop Science 已有超過 100 名用戶使用 ADE,包括育種人員、分析師、研究人員、數據科學家和工程師。除了 22 個專家 Agent,ADE 亦提供約 20 個 API 工具,並可在擴展時託管第三方 Agent。透過 AgentCore Gateway 開放這些 API,而非為每個 API 設置專用伺服器,令每個 API 的整合開銷減少超過 99%。在第一階段,ADE 已在沒有工程師介入的情況下解答約 80% 的用戶問題。
CDE 仍是分析工作的受管執行層。ADE 在其上增加自然語言介面層,讓用戶無須瞭解每個底層系統的位置或介面,便可查詢工作流程狀態、結果、模型行為和故障。
合作重點其後由推出準備轉為持續營運。DSE 持續與團隊會面,因此問題分流和營運檢視可建基於對 ADE 的既有認識,而毋須重新熟習系統。ADE 的關鍵 CloudWatch 警示,包括前文所述的 Agent 專屬警示,已納入 AWS Incident Detection and Response。警示觸發時,AWS 事件管理工程師會在 5 分鐘內介入,並根據工作負載的背景開始處理,毋須從頭瞭解。在保安方面,AWS 安全事件回應工程師會在可能發生或正在發生保安事件時支援團隊,讓 ADE 在營運及保安問題上均獲得 AWS 監察和回應支援。
既已建立 Agent 之間的通訊,Bayer 下一步將聚焦混合雲環境下 Agent 的互通性。團隊正探索如何讓在不同環境中運行的 Agent 無需手動設定,便能互相發現及通訊。
結論
Bayer 並沒有以 ADE 取代其分析平台,而是讓 CDE 更易於查詢及操作。大部分正式環境部署工作都不在提示詞本身,而是涉及持久狀態、身份界線、工具範圍界定、任務層級可觀察性、成本歸因,以及上線準備工作。Bayer 負責架構,並主導上述每項決策。團隊透過 AWS Unified Operations 與指定的 DSE 和 TAM 合作,在設計階段根據 AWS 服務的實際行為測試這些決策,並將相同脈絡帶入正式環境。
如欲瞭解更多,請參閲 Amazon Bedrock AgentCore、Amazon Bedrock 成本歸因、AWS Well-Architected 生成式 AI 指引及 AWS Unified Operations。
作者謹此感謝 Sijie Shi、Jorge Gomes、Naveen Reddy、Iago Fonseca、Mateus Silva 及 Sushimitha Jarugula 對 ADE 的設計、開發及推出所作的貢獻。
關於作者
Subbu Dandamudi
Subbu 是 Bayer 研發部門的 MLOps 主管。他負責領導可擴展平台及 AI 能力的開發,並在建立 Connected Decision Engine (CDE) 及推動其演進為 Agentic Decision Engine (ADE) 的過程中發揮關鍵作用,以加快研發領域由 AI 推動的創新。
Dr. Leo de Melo
Leo 是 Bayer Crop Science 的資深機器學習工程師,透過可擴展平台、Agent 系統及進階分析,協助塑造 AI 驅動研發的未來。他具備電腦科學及計算數學背景,專門構建 AI 和數據平台,讓研究人員能將複雜數據轉化為可執行的洞察,並加快科學研究發現。
Mahnoor Hussain
Mahnoor 是專門研究生成式 AI 及雲端架構的資深解決方案架構師。她協助客戶將 GenAI 落實於實際運作,把新興能力轉化為可投入正式環境的解決方案,涵蓋 Agent 系統、治理、安全及雲端營運。她的工作重點是協助機構從實驗階段邁向企業級採用。工作以外,Mahnoor 喜歡與家人共度時光及旅行。
Ram Pamidimukkala
Ram 是 AWS 資深技術客戶經理,專門研究生成式 AI、Agent 工作負載、數據分析、多雲及雲端營運。他協助機構以高效而安全的方式設計、現代化及遷移工作負載至 AWS Cloud。作為 Unified Operations 的一員,他的工作重點是構建具韌性的架構,兼顧效能、成本最佳化及長期可持續性。
Sai Pavan Kasani
Sai 是 AWS 生成式 AI 領域專家工程師。作為技術顧問及客戶倡導者,他協助團隊將生成式 AI 概念驗證推進至正式環境,尤其專注於 Agentic AI 工作負載。他亦協助客戶最佳化推理及提升成本效益,以配合生成式 AI 應用程式的擴展。工作以外,Sai 喜歡探索新的咖啡店及與家人共度時光。
來源:AWS Machine Learning Blog · aws.amazon.com

