Wood Mackenzie 在 Amazon Bedrock AgentCore 上打造共享代理平台

Wood Mackenzie 在 Amazon Bedrock AgentCore 上打造了一個名為 APEX 的共享式代理 AI 平台，讓團隊擁有一個共通基礎來部署生產環境中的代理，而不必為每個應用程式重新建立執行環境、身分控制、可觀測性與防護機制。

AWS 發布的該公司案例指出，APEX 支援三個應用程式：Woody、Lens AI 與 ST Trading App。此架構的設計目標，是讓產品團隊可選擇不同的代理框架與模型，同時依賴標準化的營運層。這正好解決企業級 AI 的核心問題：原型可以很快做出來，但要在使用者、工具與資料之間安全地營運非決定性系統，難度要高得多。

同一組 AWS 部落格文章也記錄了 Abnormal AI 在其電子郵件安全系統中使用 AgentCore Code Interpreter。這些例子合在一起顯示，AWS 不只是把 AgentCore 定位為開發服務，而是定位為一種基礎設施，供那些在即時工作流程中需要隔離、政策執行與受控運算存取的代理使用。

為 Wood Mackenzie 的代理提供共享基礎

Wood Mackenzie 表示，在 APEX 之前，Woody、Lens AI 與 ST Trading App 各自都在開發自己的代理堆疊。這種做法本來就需要分別實作驗證、擴展、追蹤、模型存取與防護機制，也會讓團隊之間更難共享工具、記憶與評估實務。

APEX 將這些能力集中化。其後端使用 Amazon Bedrock AgentCore Runtime、Identity、Gateway、Memory 與 Observability，並搭配協調器、檢索基礎設施、透過 Amazon Bedrock 模型目錄進行模型存取，以及 Amazon Bedrock Guardrails。前端軟體開發套件則把平台連接到面向使用者的應用程式。

這種設計並不要求每個團隊都使用相同的代理框架。Wood Mackenzie 表示，其環境可支援 Strands Agents、LangGraph、CrewAI、n8n、Vertex 與 OpenAI 的代理工具。AgentCore 也支援 Model Context Protocol，或 MCP，以及 Agent-to-Agent 協定，讓外部系統與代理可以透過標準化介面連接，而不是一次性的整合。

這種彈性是平台吸引力的重要部分。根據 Wood Mackenzie，團隊可以在不重寫應用程式邏輯的情況下更換模型，使用一個模型進行規劃、另一個模型進行執行，或比較不同供應商之間的價格與效能。公司列出 Claude、GPT-4.1、Amazon Nova、Mistral 與 Llama 可透過該平台存取，不過文章沒有提供模型品質或切換成本的獨立量測。

身分與營運進入平台層

APEX 將授權視為每次代理呼叫的屬性，而不是只有在使用者進入應用程式時才進行的檢查。Wood Mackenzie 表示，AgentCore Identity 會將使用者權限一路帶到下游工具與資料呼叫，使代理能代表使用者行事，或在另外定義的存取控制下運作。公司使用 Okta 作為其身分提供者的單一真實來源。

平台還包含 Woodmac Agent Registry，團隊可在其中根據治理與核准流程來發現並重複使用代理、工具與技能。這個登錄機制的目的，是避免在已有可共享能力時，團隊還要複製程式碼。

AWS 將 AgentCore Runtime 描述為一個無伺服器、依會話隔離的環境，可從零擴展到數千個並行呼叫，執行時間可長達八小時。AWS 還表示，AgentCore 服務在 2025 年 10 月正式上線後，支援 Amazon Virtual Private Cloud、AWS PrivateLink、CloudFormation 以及資源標籤等能力。

在成本管理方面，這項服務採用按使用量計費，沒有預先承諾或最低費用。AWS 表示，runtime 計費是依每秒實際使用的 CPU 與記憶體而定，而在等待輸入/輸出期間則不收取 CPU 費用。公司指出，代理工作流程有 30% 到 70% 的時間可能都在等待模型回應、工具或資料庫，因此這種計費方式對於原本會讓預置運算資源閒置的工作負載特別相關。

證據很詳細，但由供應商主導

這篇故事中最強的主張來自 AWS 與 Wood Mackenzie，而不是獨立稽核。Wood Mackenzie 內部表示，其 AI 概念驗證中有 88% 沒有走到大規模部署。文章也引用產業調查與 Forrester 研究，主張評估、可觀測性、治理與身分是代理擴展的主要障礙，但文中未提供足夠的來源細節，無法獨立評估這些更廣泛的統計。

文章對架構本身的描述很務實，包括從驗證、協調、runtime、模型存取到工具呼叫的請求路徑。不過，文章沒有揭露 APEX 的生產流量、代理數量、延遲、錯誤率、營運成本或可量化的商業成果。因此，買家應將這份內容視為實作參考與供應商背書的案例研究，而不是證明 AgentCore 在其他企業也會產生相同結果的證據。

Abnormal AI 的例子提供了另一項規模主張。AWS 表示，Abnormal AI 使用 AgentCore Code Interpreter 來支援在數十億則訊息中進行即時電子郵件威脅偵測的代理，而更廣泛的偵測系統只對較困難的案例施加逐步更昂貴的分析。AWS 也指出，Fortune 500 中超過 25% 的公司使用 Abnormal AI，而且該公司 80% 的程式碼變更在某種程度上都涉及代理。這些都是公司或供應商自行提供的數據，文章並未提供獨立驗證。

Code Interpreter 為 AgentCore 的故事加入了不同的能力。它提供短暫的 MicroVM 沙箱，讓代理可以執行 Python 或 Node.js 程式碼、處理檔案、進行計算、建立輸出並驗證生成的成果。AWS 表示，這些會話可持續 15 分鐘到八小時，支援公開網路或 VPC 模式，並可透過 CloudWatch 與 CloudTrail 提供日誌。Abnormal AI 的使用案例說明了為什麼代理可能需要受控的執行環境，而不能只依賴語言模型推理。

這個平台對建構者與企業代表什麼

對 AI 建構者而言，最大的改變是工程工作重心的轉移。團隊可以把精力放在領域工作流程、檢索品質、工具設計與評估上，而把重複性的基礎設施問題交給共享平台處理。這可以縮短從成功 demo 到支援多使用者與並行會話服務的路徑。

代價是架構上對中央平台團隊的依賴。共享登錄、共用政策層與標準化可觀測性可以減少重複，但如果導入、核准或框架支援速度太慢，也可能成為瓶頸。Wood Mackenzie 保留框架與模型選擇權的決定降低了這種風險，但並未消除對仔細介面設計與平台治理的需求。

對企業而言，身分傳遞與會話隔離比支援模型清單更重要。能呼叫內部工具的代理需要在整個工作流程中都保持可理解且可撤銷的權限。AgentCore Identity、Gateway 政策與基於 Cedar 的規則旨在滿足這項需求，但組織仍需在不尋常的提示、串接的工具呼叫與部分失敗情境下測試政策行為。

Abnormal AI 的部署也強化了代理系統的分層成本模式。輕量級規則與分類器可處理高流量案例，而較昂貴的代理與程式碼執行則保留給不確定或複雜的情況。這種模式可能比把每項任務都送進大型模型更務實，特別是在延遲與單次操作成本很重要的情境下。

接下來要觀察什麼

下一步有意義的訊號應該會是營運面的，而不是宣傳面的。如果 Wood Mackenzie 能公布 APEX 在各應用中的採用情況、代理失敗率、評估覆蓋率、延遲、政策違規與每個工作流程的成本，會更容易評估這個平台。

建構者也應觀察，當團隊從孤立實驗轉向共享工具與多代理工作流程時，AgentCore 的框架與模型無關性是否仍然實用。對 MCP 與 Agent-to-Agent 連線的支援或許能擴大重複使用，但也可能增加平台團隊必須監控的信任邊界數量。

對企業買家而言，重要的後續問題包括獨立客戶參考、在持續並行下更清楚的定價、事件回應控制，以及證明代理可以在不影響連接應用程式的情況下被停用或回滾。Code Interpreter 部署還需要額外檢視資料保留、網路存取、套件控制與生成程式碼隔離。

Creati.ai 觀點

Wood Mackenzie 的 APEX 值得注意的地方，與其說是它引入了另一個代理應用，不如說它把缺失的生產層視為可重複使用的產品。該公司的案例顯示，企業團隊正朝向內部代理平台前進，這些平台會標準化身分、執行行為、可觀測性與政策，同時讓業務團隊保有選擇自己模型與框架的空間。

證據仍然由供應商主導，且沒有揭露任何可證明 APEX 是成熟範本的效能或財務數據。不過，這個架構指出了 企業級 AI 的務實方向：代理採用的關鍵，可能不在於再做出另一個令人驚豔的原型，而在於讓權限、評估、隔離與成本足夠可見，才能每天穩定運作。