數據多到冇用，人同數據之間隔咗五個系統
智能鏈（supply chain）最常見嘅痛點唔係冇數據，係數據散得幾遠。AWS 喺 2026 年 10 月 20 日嘅 ML 博客示範咗一個「對話式供應鏈智能」示範：一個供應鏈 manager 嘅朝會，傳統上要打開 ERP（庫存例外）、monitoring 工具（警報）、procurement（替代供應商）、email（RFQ 報價）加一個 tracker，跨五個系統做十幾次 context switch，總共四五十分鐘。
同一個朝會，喺佢哋嘅示範入面變成喺一個 Amazon Quick 對話入面打三句 prompt，幾分鐘搞掂。
AgentCore 做乜？做一個「有治理」嘅工具層
技術上，Amazon Bedrock AgentCore 做嘅係一個 intelligence layer，將企業內部嘅 Model Context Protocol（MCP，一類讓 AI 代理以結構化方式調用外部工具嘅協定）servers 暴露成一個可組合嘅 tool layer。
具體講：Amazon Quick 係用户端對話入口，AgentCore 係中層調度，底層係喺 AWS Agent Registry 發佈嘅業務 MCP servers。喺佢哋嘅示範入面，有四個業務 MCP servers 已經被 admin 預先註冊，喺 Quick 入面直接顯示成 connector cards，唔使用户手敲任何 URL。
個示範情景：TechComp 中斷
佢哋嘅 demo 跟住一個中斷事件從發覺到批准緊急 RFQ，五個步驟全部喺同一個 Amazon Quick 對話入面完成：
- Discovery：用户問「我有咩供應鏈工具？」，Quick 列出 Registry 入面嘅四個 MCP servers。
- Querying：用户問「有冇活躍中斷？」，Quick 經 AgentCore 調用 Disruption Alerts MCP 嘅
assess_disruption_impact，回傳三個中斷，各帶 severity、地區、受影響 SKU 數。 - Drill-down：用户揀 TechComp 停產事件（DISR-002），同一個 MCP tool call 橫跨多套 record system 拉數，回傳風險 $750,000、涉及 23 單訂單、供應只夠三日。
- Action：用户要求緩解建議，
recommend_mitigation接埋 governance 流程。 - 最後一步喺原文入面被截斷，冇完整顯示。
兩個值得留意嘅設計細節
答案唔靠模型記憶，靠 live 系統回傳。 原文明確講：answers come from live systems of record and grounded documents, not model recall。呢句對用 LLM 入企業流程嘅讀者嚟話係核心保證：唔係模型「記到」或「猜」，係實時調用後端。
任何變更都要有明名嘅人批核。 every change waits for a named human。呢句寫喺原文開頭，唔係細字。喺企業 AI 部署成日俾人問「出事邊個負責」，呢句係佢哋嘅答法。
阿調搞兩下
呢篇文係 AWS 自己寫喺自己嘅 ML 博客，佢哋嘅示範數字（45–60 分鐘變幾分鐘、$750K 風險）都係佢哋自己擺嘅 scenario，我哋冇獨立試過 Amazon Quick 喺生產環境嘅表現。
但係呢個架構本身值得拆：MCP 做 tool layer、AgentCore 做調度、Quick 做入口，三層分開，admin 預設嘅 connector 唔使用户搞 URL。呢個模式如果真係喺生產行得通，對打嘅供應鏈團隊嚟話，最實際嘅影響係佢哋唔使再記住「邊個數據喺邊個系統」。
最實際嘅一個問題留喺度：四個 MCP servers 仲有冇埋其他企業系統嘅接入標準，同埋 Amazon Quick 呢個入口係咪限於 AWS 生態，定係任何 LLM 都接得埋。原文冇講。
