AWS 在 New York Summit 2026 把企業 AI 代理（AI agent） 的焦點往兩個缺口推進：一個是 agent 能不能讀懂公司資料與業務規則，另一個是 agent 找到漏洞後能不能安全地驗證與修補。這代表資料、權限、安全與上線流程要一起補齊，不能只追單一新工具。
如果你負責企業 AI、資料平台、雲端安全或開發平台，這次可以先做一個務實判斷：AWS Context 先放進資料治理觀察清單，AWS Continuum 先用來評估安全團隊的漏洞處理流程，Amazon Bedrock AgentCore 則回到既有 agent 專案，檢查身分、瀏覽邊界、知識來源與測試集是否跟得上。
先把三個名字分開看
AWS 這波公告容易混在一起看。比較清楚的方式，是把它們放在 agent 上線鏈路的不同位置：
| 名稱 | 主要處理什麼 | 目前狀態 | 企業先做什麼 |
|---|---|---|---|
| AWS Context | 把分散在資料湖、資料倉儲、資料庫與內部知識中的關係，整理成受治理的知識圖譜（knowledge graph） | 官方標示即將推出（Coming soon） | 盤點資料目錄、業務定義、權限與誰能審核系統推論出的資料關係 |
| AWS Glue Data Catalog Business Context | 讓 Glue tables、views、columns 加上商業描述、詞彙、metadata 與技能資產（skill assets） | 預覽（Preview） | 先找 1–2 個高價值資料域，補中文/英文定義、限制與使用規則 |
| Amazon S3 Annotations | 把可查詢的業務脈絡附在 S3 物件上，存成 S3 Iceberg table | 正式可用（Generally available） | 對常被 agent 讀取的檔案，加上可維護的來源、限制與用途說明 |
| AWS Continuum | 對程式碼漏洞做發現、排序、驗證、緩解與修補建議 | Continuum for code vulnerabilities 是受限預覽（gated preview） | 先定義哪些 repo、環境與弱點類型可以進試點，保留人工審批 |
| Amazon Bedrock AgentCore 更新 | 提供 agent harness、知識庫、網頁搜尋、護欄、推薦、A/B 測試、洞察與支付等能力 | 多項能力已正式可用（GA），Insights/Payments 等仍在預覽 | 回頭檢查 production agent 的身分、工具權限、評測與監控 |
這張表的重點是分流。資料團隊應該先問 agent 讀到的知識是否可信；安全團隊要問弱點修補是否有可重現證據與回滾；平台團隊則要問 agent 每一次動作是否能被權限、護欄與測試套件管住。
AWS Context 解決的是「agent 知道公司語境嗎？」
AWS 對 Context 的描述很直接：agent 的品質取決於它能推理的脈絡。企業資料常分散在資料湖、資料倉儲、資料庫、串流系統、文件和沒有寫下來的制度知識裡。agent 如果只靠技術欄位名稱，很容易把錯表、舊口徑或錯誤規則當成答案來源。
AWS Context 的方向，是自動把既有資料關係映射成組織級知識圖譜，讓 agent 在執行時查到受治理的資料關係、商業規則和領域知識。資料 steward 或 curator 可以審核系統推論出的關係，把可用的關係升到 production，並附上業務定義與使用規則。
對非工程主管來說，可以把它理解成「公司資料的地圖與使用說明」。agent 需要知道某張表叫什麼，也要知道這張表和客戶、合約、產品、地區、權限、報表口徑之間的關係。這會直接影響客服、財務、營運、法務或銷售 agent 的答案可信度。
先不要把 Context 想成魔法資料整理器。它會讓治理流程更重要：誰能確認商業定義、誰能批准資料關係、哪些資料不能被 agent 串起來、查詢結果要如何留下稽核紀錄，都要在試點前講清楚。
Continuum 解決的是「agent 找到漏洞後怎麼安全處理？」
AWS Continuum for code vulnerabilities 的切入點，是把程式碼漏洞生命週期接成一條可驗證流程：發現、排序、驗證、緩解與修補。AWS 官方說它會理解整體環境（reasoning over your environment），也就是把基礎設施、權限、網路拓撲、程式碼、文件、溝通內容與業務優先順序放進判斷，避免只套一套通用弱點規則。
這對安全團隊有兩個價值。第一，弱點排序可以從「掃描器說嚴重」推進到「這個元件是否真的部署、是否可達、是否在生產路徑（production path）、被利用後的業務影響是什麼」。第二，Continuum 會嘗試在沙盒環境建立可重現證據，幫團隊先排除一部分誤報（false positives），再提出網路、政策或程式碼層的緩解與修補建議。
官方也寫明，Continuum 從學習模式（learn mode）和人工把關（human in the loop）開始，建議會附上推理理由；等團隊建立信任後，才可能依風險類型逐步進到強制模式（enforce mode）。這句話很重要：企業不應把自動修補當成第一天目標。比較安全的第一步，是讓它整理證據、建議優先順序與回滾路徑，再由安全與工程負責人批准。
三種讀者應該採取不同下一步
| 你的角色 | 這週先做什麼 | 預期產出 | 怎麼驗證 | 先不要做的事 |
|---|---|---|---|---|
| 資料平台或 BI 負責人 | 選一個常被問錯的資料域，整理商業定義、欄位限制、資料 owner 與可被 agent 使用的查詢規則 | 一份資料脈絡清單，可對應到 Glue Data Catalog、S3 Annotations 或未來 AWS Context | 讓 agent 回答同一組業務問題，檢查是否引用正確口徑與權限 | 不要一次把所有資料湖都交給 agent 搜 |
| 資安或 AppSec 團隊 | 挑一個非核心 repo 或中低風險弱點類型，設計 Continuum preview 的試點邊界 | 弱點排序、可重現證據、建議修補、人工審批與回滾流程 | 抽查 false positive、sandbox 證據、PR diff、測試結果與 rollback plan | 不要在沒有審批與測試的情況下自動改 production code |
| AI 平台或雲端架構團隊 | 回頭檢查 AgentCore 專案的身分、工具權限、瀏覽白名單、知識來源與測試集 | 一張 agent readiness checklist，標出已補與缺口 | 用固定測試集跑資料查詢、工具呼叫、拒答、權限錯誤與成本上限 | 不要只追新功能，卻沒有 release gate 與稽核紀錄 |
如果你的公司還沒有 production agent，這篇不要求你立刻導入 AWS 新服務。比較好的起點，是先用 AI Agent 上線檢查 建立共同語言，再用這波 AWS 公告確認缺口：資料脈絡、身分與權限、安全驗證、測試集、監控與人工接手。
和現有 AgentCore 文章怎麼接起來？
Mason 站內已經有多篇 Amazon Bedrock AgentCore 的單點說明。這篇的位置比較像總整理：把 AWS Context、Continuum 和 AgentCore 更新放回企業代理上線鏈路。
- 如果 agent 要代表使用者讀 Google Drive、Slack、GitHub 或內部服務，先看 Amazon Bedrock AgentCore Identity；身分與憑證沒有整理好，Context 讀到再多知識也不安全。
- 如果 agent 會開瀏覽器或外部網站，先看 AgentCore Browser 與 Chrome enterprise policies；白名單與瀏覽邊界會影響資料外洩風險。
- 如果你已經在測 agent 能力，先看 AgentCore dataset management；沒有固定測試集，就很難判斷 Context 或 Continuum 讓系統變好還是變複雜。
- 如果你在看跨平台治理，可以搭配 ServiceNow＋AWS Bedrock AgentCore；那篇處理的是企業控制層和跨系統治理。
7 天內可以完成的檢查
- 列出最想交給 agent 的兩個任務：一個資料查詢任務，一個安全或程式碼任務。
- 對每個任務寫清楚資料來源、資料 owner、權限、不能外流的欄位與人工審核點。
- 選 10 個測試案例：正常問題、模糊問題、越權問題、資料過期、工具失敗、成本上限、需要人工批准的情境都要放進去。
- 對資料任務，確認 agent 能否同時說出資料口徑、限制與來源，不能只給答案。
- 對安全任務，確認修補建議是否有可重現證據、測試結果、爆炸半徑（blast radius）和回滾路徑。
- 先決定停止規則（stop rule）：哪一類任務必須停下來給人審，哪一類只能產生草稿或建議。
- 一週後只問一個問題：agent 是否讓團隊更快做出可查核決策？如果只是多了一層不透明自動化，先縮小試點。
FAQ
AWS Context 現在可以正式使用嗎？
AWS 官方在 6 月 17 日文章中把 AWS Context 標示為即將推出（Coming soon）。可以先讀官方方向並整理資料治理準備，但不要把它當成已能全面採購與正式部署的服務。
AWS Continuum 會自動幫我修掉所有漏洞嗎？
不應這樣理解。官方說 Continuum for code vulnerabilities 目前是受限預覽（gated preview），並且從學習模式與人工把關開始。企業試點時，應先把它當成證據整理、弱點排序與修補建議工具，再逐步評估哪些類型能更自動化。
這和一般 RAG 或知識庫有什麼差別？
一般檢索增強生成（retrieval-augmented generation，RAG）常從文件搜尋開始；AWS Context 的主張是把跨系統資料關係、商業規則、權限與使用脈絡整理成組織級知識圖譜。這會更接近資料治理問題，範圍超過文件切片與向量搜尋。
小團隊需要現在追這波 AWS 更新嗎？
如果你還沒有會讀公司資料、呼叫工具或改程式的 agent，可以先觀察。比較值得立刻做的是整理資料定義、權限、測試案例與人工審批流程；這些準備不依賴特定 AWS 服務，未來換平台也用得到。
參考來源
- AWS Security Blog：Introducing AWS Continuum: Security at machine speed
- AWS Artificial Intelligence Blog：Context intelligence for your data and AI agents at scale
- AWS Artificial Intelligence Blog：New in Amazon Bedrock AgentCore: Build agents with broader knowledge and continuous learning
- The Decoder：AWS says AI agents lack business context and security, launches two services to patch the gaps