企業(yè) AI Agent 僅依靠知識庫無法滿足業(yè)務(wù)需求時(shí)該選用哪些云上數(shù)據(jù)服務(wù)搭建數(shù)據(jù)層與記憶層AWS 分層數(shù)據(jù)架構(gòu)選型方案企業(yè)落地 AI Agent 項(xiàng)目時(shí)普遍會(huì)以接入文檔知識庫作為起步方案依托產(chǎn)品手冊、管理制度、操作指引以及歷史歸檔資料實(shí)現(xiàn)智能問答能力。 但知識庫的核心能力局限于從存量靜態(tài)資料內(nèi)檢索匹配信息。當(dāng)企業(yè)要求 AI Agent 調(diào)取實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)、持續(xù)追蹤任務(wù)進(jìn)度、調(diào)用業(yè)務(wù)系統(tǒng)執(zhí)行操作、記憶用戶行為偏好乃至主動(dòng)更新業(yè)務(wù)數(shù)據(jù)時(shí)單純接入知識庫的模式便會(huì)顯現(xiàn)能力短板?？赏懂a(chǎn)落地的企業(yè)級 AI Agent必須打通多類數(shù)據(jù)源涵蓋企業(yè)知識文檔與各類非結(jié)構(gòu)化資料客戶、訂單、庫存等結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)數(shù)據(jù)湖與全域分析平臺實(shí)時(shí)流式數(shù)據(jù)流業(yè)務(wù)工具以及外部 API 接口實(shí)時(shí)運(yùn)行的任務(wù)狀態(tài)短期會(huì)話記憶與長期跨會(huì)話記憶。由此可見企業(yè)需要搭建的并非孤立運(yùn)行的 RAG 知識庫而是一套支撐 AI Agent 檢索數(shù)據(jù)、使用數(shù)據(jù)、寫入數(shù)據(jù)、留存記憶的云上全域數(shù)據(jù)底座。 依托 AWS 服務(wù)生態(tài)企業(yè)可整合 Amazon S3、Amazon S3 Tables、AWS Glue、Amazon Athena、Amazon Redshift、Amazon Aurora、Amazon DynamoDB、Amazon ElastiCache、Amazon OpenSearch Service、Amazon S3 Vectors、Amazon Bedrock AgentCore Memory 等組件搭建分層式數(shù)據(jù)架構(gòu)與記憶架構(gòu)。一、僅部署知識庫AI Agent 為何很快觸及能力上限傳統(tǒng) RAG 知識庫適配內(nèi)容長期穩(wěn)定的場景例如員工規(guī)章制度、售后政策規(guī)范、技術(shù)白皮書、產(chǎn)品介紹文案、歷史服務(wù)案例等。 但企業(yè)經(jīng)營中的大量業(yè)務(wù)問題無法依靠靜態(tài)文檔完成解答。 舉例而言客戶咨詢訂單遲遲未發(fā)貨的緣由Agent 不能只調(diào)取物流規(guī)章制度還需要讀取訂單狀態(tài)、庫存余量、物流運(yùn)輸明細(xì) 銷售人員想要識別本月具備流失風(fēng)險(xiǎn)的客戶群體Agent 需要整合客戶活躍度、簽約合同、服務(wù)工單、產(chǎn)品使用行為做綜合分析不能僅檢索客戶管理手冊 運(yùn)營人員需要定位昨日某區(qū)域銷量下滑的誘因Agent 必須對接數(shù)據(jù)倉庫、數(shù)據(jù)湖完成指標(biāo)拆解、多維度查詢與橫向?qū)Ρ取＿@足以說明知識庫僅僅是 Agent 整體數(shù)據(jù)體系的組成部分。2026 亞馬遜云科技中國峰會(huì)《Agentic AI 的數(shù)據(jù)之道Agent 自己找數(shù)據(jù)、記數(shù)據(jù)、管數(shù)據(jù)你準(zhǔn)備好了嗎》一文將 Agent 對接數(shù)據(jù)的路徑劃分為七大類型知識庫 RAG、分析引擎、業(yè)務(wù)數(shù)據(jù)庫、流式實(shí)時(shí)數(shù)據(jù)、湖倉體系、外部 API、記憶管理模塊。企業(yè)可將 Agent 所需數(shù)據(jù)劃分為五大類別知識數(shù)據(jù)各類文檔、網(wǎng)頁資料、管理制度、產(chǎn)品素材業(yè)務(wù)數(shù)據(jù)客戶檔案、訂單合同、庫存信息、賬戶狀態(tài)、交易流水分析數(shù)據(jù)運(yùn)營指標(biāo)、統(tǒng)計(jì)報(bào)表、歷史明細(xì)、跨系統(tǒng)匯總數(shù)據(jù)實(shí)時(shí)數(shù)據(jù)設(shè)備采集遙測數(shù)據(jù)、用戶點(diǎn)擊流、系統(tǒng)日志、事件消息狀態(tài)與記憶數(shù)據(jù)會(huì)話狀態(tài)、任務(wù)推進(jìn)進(jìn)度、工具返回結(jié)果、用戶長期偏好。不同類型數(shù)據(jù)的更新頻率、檢索模式、權(quán)限體系均存在差異不可全部集中存入同一知識庫或向量數(shù)據(jù)庫。二、第一層業(yè)務(wù)數(shù)據(jù)層賦能 Agent 讀寫真實(shí)業(yè)務(wù)狀態(tài)企業(yè) AI Agent 想要從被動(dòng)問答升級為主動(dòng)執(zhí)行業(yè)務(wù)動(dòng)作首要環(huán)節(jié)便是對接真實(shí)業(yè)務(wù)系統(tǒng)。 典型業(yè)務(wù)數(shù)據(jù)范疇包含 客戶檔案、訂單及合同資料、產(chǎn)品庫存數(shù)據(jù)、賬戶狀態(tài)、售后工單記錄、審批任務(wù)進(jìn)度、系統(tǒng)配置信息、Agent 任務(wù)執(zhí)行結(jié)果。 該類數(shù)據(jù)具備結(jié)構(gòu)化特征處于持續(xù)更新狀態(tài)部分業(yè)務(wù)場景還要求 Agent 回寫數(shù)據(jù)諸如新建工單、修改預(yù)約信息、更新任務(wù)狀態(tài)、提交審批單據(jù)等。Amazon Aurora適配關(guān)聯(lián)性核心業(yè)務(wù)數(shù)據(jù) 若企業(yè)業(yè)務(wù)數(shù)據(jù)具備明確關(guān)聯(lián)關(guān)系并且需要事務(wù)處理、條件篩選、多表關(guān)聯(lián)查詢可選用 Amazon Aurora。 例如客服 Agent 先核驗(yàn)客戶身份再關(guān)聯(lián)調(diào)取訂單、付款記錄、售后工單銷售 Agent 聯(lián)動(dòng)客戶資料、簽約合同、產(chǎn)品臺賬、跟進(jìn)記錄開展整合分析。 Amazon Aurora 同時(shí)支持向量字段與結(jié)構(gòu)化字段混合查詢因此企業(yè)想要將客戶資料、業(yè)務(wù)字段、語義信息收納至統(tǒng)一數(shù)據(jù)模型時(shí)Aurora PostgreSQL 是優(yōu)選方案。Amazon DynamoDB適配高并發(fā)狀態(tài)數(shù)據(jù)與鍵值存儲(chǔ)場景 會(huì)話狀態(tài)、任務(wù)推進(jìn)節(jié)點(diǎn)、Agent 故障檢查點(diǎn)、用戶個(gè)性化配置、高并發(fā)鍵值讀寫場景適配 Amazon DynamoDB。 這類數(shù)據(jù)無需復(fù)雜多表關(guān)聯(lián)邏輯但要求毫秒級讀取、彈性擴(kuò)容并且能夠依托用戶 ID、會(huì)話 ID、任務(wù) ID 精準(zhǔn)定位。 例如多步驟執(zhí)行的 Agent每完成一段動(dòng)作即可更新任務(wù)狀態(tài)即便進(jìn)程中斷重啟系統(tǒng)讀取檢查點(diǎn)即可接續(xù)執(zhí)行無需從頭運(yùn)行全部任務(wù)。Amazon ElastiCache承載高頻訪問數(shù)據(jù)與臨時(shí)狀態(tài) 頻繁讀取的會(huì)話上下文、熱門檢索結(jié)果、臨時(shí)運(yùn)算結(jié)果可借助 Amazon ElastiCache 搭建高速緩存層。 該服務(wù)適合需要極速響應(yīng)、無需長期持久化保存的數(shù)據(jù)。比如 Agent 單次任務(wù)內(nèi)反復(fù)調(diào)取同款產(chǎn)品資料系統(tǒng)優(yōu)先讀取緩存內(nèi)容減少后端數(shù)據(jù)庫重復(fù)訪問壓力。綜上業(yè)務(wù)數(shù)據(jù)層不能只采用單一數(shù)據(jù)庫結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)、高并發(fā)狀態(tài)數(shù)據(jù)、臨時(shí)緩存數(shù)據(jù)應(yīng)當(dāng)分別匹配對應(yīng)的存儲(chǔ)服務(wù)。三、第二層數(shù)據(jù)湖倉層讓 Agent 全域調(diào)取跨系統(tǒng)數(shù)據(jù)業(yè)務(wù)數(shù)據(jù)庫一般依附單一應(yīng)用搭建隨著企業(yè)業(yè)務(wù)系統(tǒng)持續(xù)增多客戶、產(chǎn)品、供應(yīng)鏈、財(cái)務(wù)、運(yùn)營數(shù)據(jù)分散在各個(gè)平臺。 倘若 Agent 僅能訪問單一業(yè)務(wù)數(shù)據(jù)庫便無法開展跨部門聯(lián)合分析。在此背景下企業(yè)需要搭建統(tǒng)一湖倉架構(gòu)集中治理、查詢、整合多來源數(shù)據(jù)。 在 AWS 架構(gòu)體系中依托 Amazon S3、Amazon S3 Tables 承載原始數(shù)據(jù)搭配 AWS Glue、Amazon Athena、Amazon Redshift 補(bǔ)齊數(shù)據(jù)處理與分析能力。Amazon S3構(gòu)筑企業(yè)全域規(guī)?；瘮?shù)據(jù)底座 Amazon S3 可兼容結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化全類型數(shù)據(jù)涵蓋業(yè)務(wù)明細(xì)、系統(tǒng)日志、圖片文件、文檔資料、歷史歸檔數(shù)據(jù)。 其核心價(jià)值不只是存儲(chǔ)文件而是支撐各類計(jì)算、分析組件共用一份原始數(shù)據(jù)源。 針對企業(yè) AI Agent 場景Amazon S3 數(shù)據(jù)湖作為跨系統(tǒng)數(shù)據(jù)統(tǒng)一載體知識庫、分析引擎、機(jī)器學(xué)習(xí)鏈路、Agent 工具均可按需調(diào)用湖內(nèi)數(shù)據(jù)。 峰會(huì)演講《高性能存儲(chǔ)加速生成式 AI》將數(shù)據(jù)底座、長期記憶、知識庫、實(shí)時(shí)數(shù)據(jù)流、短期工作記憶統(tǒng)一納入 AI Agent 整體存儲(chǔ)架構(gòu)明確存儲(chǔ)體系是 Agent 的外部大腦。Amazon S3 Tables 搭配 Apache Iceberg適配動(dòng)態(tài)更新的湖上表數(shù)據(jù) 企業(yè)數(shù)據(jù)湖內(nèi)的數(shù)據(jù)并非靜態(tài)只讀訂單狀態(tài)、產(chǎn)品信息、測試結(jié)果、運(yùn)營指標(biāo)都會(huì)動(dòng)態(tài)變更。 Amazon S3 Tables 結(jié)合 Apache Iceberg能夠以數(shù)據(jù)表模式管理湖內(nèi)數(shù)據(jù)適配數(shù)據(jù)分析負(fù)載的數(shù)據(jù)組織形式。 當(dāng) Agent 需要追溯數(shù)據(jù)歷史變更、讀取最新業(yè)務(wù)數(shù)據(jù)或是多套分析組件共享統(tǒng)一數(shù)據(jù)表時(shí)湖上表架構(gòu)相比零散文件存儲(chǔ)更適配生產(chǎn)環(huán)境落地。AWS Glue負(fù)責(zé)數(shù)據(jù)集成、元數(shù)據(jù)目錄與加工處理 各類業(yè)務(wù)數(shù)據(jù)匯入數(shù)據(jù)湖之后還需要完成抽取、清洗、轉(zhuǎn)換、元數(shù)據(jù)管控流程。 AWS Glue 承擔(dān) ETL 數(shù)據(jù)加工工作依靠 AWS Glue Data Catalog 統(tǒng)一管理數(shù)據(jù)表、字段、數(shù)據(jù)存儲(chǔ)位置。如此一來Agent 與分析工具無需反復(fù)識別數(shù)據(jù)存放位置與字段釋義。 在 Agentic AI 架構(gòu)中元數(shù)據(jù)至關(guān)重要Agent 需要先探查可用數(shù)據(jù)源、讀懂?dāng)?shù)據(jù)表結(jié)構(gòu)與業(yè)務(wù)含義再選用合理方式執(zhí)行查詢。四、第三層分析查詢層支撐 Agent 完成復(fù)雜數(shù)據(jù)推理問答知識庫檢索只會(huì)返回片段式關(guān)聯(lián)文本而企業(yè)數(shù)據(jù)分析需要完成計(jì)算、篩選、聚合、對比運(yùn)算。 當(dāng)用戶提出下述問題時(shí)Agent 必須調(diào)用專業(yè)分析引擎 本月銷售額下滑的深層誘因、故障率異常攀升的產(chǎn)品清單、不同區(qū)域客戶流失率差異、各類工單平均辦結(jié)時(shí)長、某業(yè)務(wù)指標(biāo)近半年波動(dòng)趨勢。Amazon Athena直接基于數(shù)據(jù)湖開展即時(shí)查詢 Amazon Athena 支持使用 SQL 語句查詢 Amazon S3 湖內(nèi)數(shù)據(jù)企業(yè)不必為每一次分析需求單獨(dú)新建數(shù)據(jù)庫。 面向數(shù)據(jù)湖臨時(shí)探查、自然語言轉(zhuǎn)數(shù)據(jù)分析、日志排查、跨數(shù)據(jù)集探索場景Amazon Athena 具備極高靈活性。 Agent 可將自然語言問題拆解為數(shù)據(jù)查詢?nèi)蝿?wù)通過受控工具調(diào)用 Athena 獲取運(yùn)算結(jié)果。對比把整張數(shù)據(jù)表灌入大模型上下文的模式該方案適配海量數(shù)據(jù)場景模型僅接收查詢結(jié)果而非完整原始數(shù)據(jù)。Amazon Redshift面向企業(yè)級數(shù)倉與規(guī)?；治鰣鼍?若企業(yè)已搭建成熟指標(biāo)體系需要處理海量數(shù)據(jù)分析、復(fù)雜報(bào)表、高頻業(yè)務(wù)查詢可部署 Amazon Redshift。 該服務(wù)適合歸集跨部門數(shù)據(jù)至統(tǒng)一分析平臺向上游 Agent 輸出經(jīng)過治理的標(biāo)準(zhǔn)數(shù)據(jù)服務(wù)。 企業(yè)還可通過預(yù)設(shè)查詢語句、數(shù)據(jù) API、語義指標(biāo)層讓 Agent 調(diào)取標(biāo)準(zhǔn)化業(yè)務(wù)指標(biāo)規(guī)避模型自由拼接未經(jīng)校驗(yàn)的計(jì)算邏輯引發(fā)錯(cuò)誤。Amazon Athena Apache Iceberg 組合方案 企業(yè)以 Amazon S3 為底層底座采用 Apache Iceberg 管理湖內(nèi)數(shù)據(jù)表時(shí)可借助 Amazon Athena 實(shí)現(xiàn)湖表查詢。 這套組合方案能夠同時(shí)兼容傳統(tǒng) BI 分析、機(jī)器學(xué)習(xí)訓(xùn)練、AI Agent 三類業(yè)務(wù)底層數(shù)據(jù)源完全統(tǒng)一上層各類應(yīng)用按需選取計(jì)算模式。五、HP Nova 落地實(shí)踐啟示先搭建統(tǒng)一數(shù)據(jù)底座再迭代 Agent 上層能力在 2026 亞馬遜云科技中國峰會(huì)《Athena IcebergAI Agent 的數(shù)據(jù)底座實(shí)戰(zhàn)》分享環(huán)節(jié)HP Nova 團(tuán)隊(duì)介紹了自身數(shù)據(jù)架構(gòu)三次迭代歷程。 初期團(tuán)隊(duì)數(shù)據(jù)分散部署在多套本地系統(tǒng)與獨(dú)立管理平臺數(shù)據(jù)處理腳本零散碎片化傳統(tǒng)報(bào)表僅面向人工查看無法支撐 AI 應(yīng)用調(diào)用。 后續(xù)團(tuán)隊(duì)率先完成業(yè)務(wù)系統(tǒng)上云依托 Amazon S3、Apache Iceberg、AWS Glue Data Catalog、Amazon Athena 搭建統(tǒng)一數(shù)據(jù)底座。原有傳統(tǒng) BI 組件可沿用這套數(shù)據(jù)源機(jī)器學(xué)習(xí)任務(wù)、大模型自然語言查詢同樣能夠復(fù)用底層數(shù)據(jù)。統(tǒng)一數(shù)據(jù)底座建成之后架構(gòu)升級為中心化數(shù)據(jù)平臺結(jié)合基礎(chǔ)設(shè)施即代碼、工作流編排機(jī)制優(yōu)化新數(shù)據(jù)源接入流程與平臺運(yùn)維效率。該實(shí)踐帶來核心啟示企業(yè)切勿為每一款新增 Agent 單獨(dú)搭建一套獨(dú)立數(shù)據(jù)體系。 正確思路為先匯聚全域分散數(shù)據(jù)打造開放統(tǒng)一的數(shù)據(jù)底座再將 BI、機(jī)器學(xué)習(xí)、知識庫、各類 Agent 接入共享底座。即便上層 Agent 應(yīng)用快速迭代更新底層數(shù)據(jù)架構(gòu)無需反復(fù)重構(gòu)改造。六、第四層實(shí)時(shí)數(shù)據(jù)層賦能 Agent 捕捉動(dòng)態(tài)業(yè)務(wù)變化數(shù)據(jù)湖與數(shù)據(jù)倉庫多用于歷史數(shù)據(jù)分析場景但不少業(yè)務(wù)場景下的 Agent必須實(shí)時(shí)感知正在發(fā)生的業(yè)務(wù)動(dòng)態(tài)。 典型實(shí)時(shí)監(jiān)測場景包含設(shè)備溫度驟然攀升現(xiàn)有庫存數(shù)值跌破安全庫存閾值用戶最新操作行為記錄交易行為觸發(fā)風(fēng)控規(guī)則物流運(yùn)輸節(jié)點(diǎn)狀態(tài)變更系統(tǒng)新增異常日志信息。此類實(shí)時(shí)數(shù)據(jù)經(jīng)由 Amazon Kinesis 或是 Amazon Managed Streaming for Apache KafkaAmazon MSK接入實(shí)時(shí)數(shù)據(jù)流鏈路后續(xù)依托 AWS Glue、Apache Spark、Apache Flink 等組件開展流式加工處理。無需將全部原始實(shí)時(shí)數(shù)據(jù)流直接推送至 Agent行業(yè)最優(yōu)方案為先借助流計(jì)算完成數(shù)據(jù)過濾、聚合運(yùn)算、事件識別動(dòng)作僅將和當(dāng)前業(yè)務(wù)任務(wù)相關(guān)的處理結(jié)果下發(fā)至 Agent。 舉例說明系統(tǒng)預(yù)先判定設(shè)備指標(biāo)是否觸碰異常閾值唯有異常事件產(chǎn)生時(shí)才喚醒運(yùn)維類 Agent。該模式既能避免海量無效數(shù)據(jù)涌入大模型上下文也能防止 Agent 被不間斷的流式數(shù)據(jù)占用算力。七、第五層知識語義檢索層知識庫具備實(shí)用價(jià)值但不可獨(dú)立部署知識庫并非失去作用而是必須和其余各層數(shù)據(jù)架構(gòu)協(xié)同聯(lián)動(dòng)。 Amazon Bedrock 知識庫能夠?qū)痈黝悢?shù)據(jù)源與向量存儲(chǔ)組件搭建企業(yè)專屬 RAG 檢索鏈路。結(jié)合落地場景差異底層可搭配下述存儲(chǔ)服務(wù)Amazon OpenSearch ServiceAmazon Aurora PostgreSQLAmazon Neptune AnalyticsAmazon DocumentDBAmazon RedshiftAmazon ElastiCache for ValkeyAmazon S3 Vectors各服務(wù)分工各不相同 Amazon OpenSearch Service適配語義檢索 關(guān)鍵詞檢索的混合檢索模式多用于線上知識問答場景 Amazon Aurora PostgreSQL支持向量數(shù)據(jù)與客戶、訂單、權(quán)限、產(chǎn)品結(jié)構(gòu)化字段聯(lián)合檢索 Amazon Neptune Analytics適配 GraphRAG 場景可完成實(shí)體關(guān)聯(lián)分析、推理路徑推演 Amazon S3 Vectors面向海量低頻訪問、成本敏感型向量數(shù)據(jù)存儲(chǔ)可與在線向量數(shù)據(jù)庫搭建冷熱分層存儲(chǔ)架構(gòu)?；诜謱蛹軜?gòu)各司其職的邏輯由知識庫解答業(yè)務(wù)規(guī)則類問題業(yè)務(wù)數(shù)據(jù)庫反饋業(yè)務(wù)實(shí)時(shí)狀態(tài)分析引擎解析數(shù)據(jù)波動(dòng)成因最終由 Agent 整合多方信息生成執(zhí)行方案。八、第六層短期狀態(tài)層與長期記憶層保障 Agent 連貫執(zhí)行多階段任務(wù)數(shù)據(jù)層決定 Agent 可訪問的企業(yè)全域數(shù)據(jù)源記憶層則管控 Agent 在會(huì)話、連續(xù)任務(wù)中留存的有效信息。1.短期狀態(tài)數(shù)據(jù)短期狀態(tài)覆蓋內(nèi)容 當(dāng)前對話上下文、任務(wù)推進(jìn)進(jìn)度、工具調(diào)用返回結(jié)果、階段性分析數(shù)據(jù)、多步驟任務(wù)執(zhí)行狀態(tài)、異常中斷后的恢復(fù)檢查點(diǎn)。 依據(jù)讀寫特征該類數(shù)據(jù)可存儲(chǔ)至 Amazon DynamoDB、Amazon ElastiCache、Amazon S3 Files 及其他狀態(tài)存儲(chǔ)組件。2.長期記憶數(shù)據(jù)長期記憶涵蓋范疇 用戶長期行為偏好、已經(jīng)核驗(yàn)確認(rèn)的事實(shí)信息、歷史任務(wù)執(zhí)行結(jié)果、過往操作沉淀的經(jīng)驗(yàn)、跨會(huì)話場景需要復(fù)用的數(shù)據(jù)。 Amazon Bedrock AgentCore Memory 負(fù)責(zé)統(tǒng)一管控短期狀態(tài)與長期記憶完成記憶存儲(chǔ)、檢索調(diào)取、跨會(huì)話復(fù)用全流程管理。 海量低頻歷史語義記憶可存入 Amazon S3 Vectors 構(gòu)建離線長效存儲(chǔ)層近期高頻調(diào)取的記憶數(shù)據(jù)則搭配 Amazon OpenSearch Service、Amazon Aurora PostgreSQL、緩存服務(wù)搭建在線快速召回層。3.緩存體系2026 亞馬遜云科技中國峰會(huì)專題演講將 Agent 緩存劃分為查詢緩存、語義緩存、狀態(tài)緩存三大類別。 緩存機(jī)制能夠降低接口響應(yīng)時(shí)延、減少大模型重復(fù)調(diào)用頻次、緩解后端數(shù)據(jù)庫整體負(fù)載。 應(yīng)用場景多名用戶提出高度近似的業(yè)務(wù)問題時(shí)Agent 可復(fù)用已生成并校驗(yàn)完畢的回答結(jié)果同一任務(wù)反復(fù)調(diào)取相同業(yè)務(wù)數(shù)據(jù)時(shí)優(yōu)先讀取緩存內(nèi)容。九、數(shù)據(jù)治理工作需前置布局不可在 Agent 上線后補(bǔ)充建設(shè)Agent 可訪問的數(shù)據(jù)范圍越廣越需要清晰劃定數(shù)據(jù)訪問邊界。 企業(yè)務(wù)必落地以下治理要點(diǎn)限定 Agent 能夠檢索探查的數(shù)據(jù)源范圍劃分不同人員的數(shù)據(jù)字段訪問權(quán)限對敏感數(shù)據(jù)執(zhí)行脫敏處理規(guī)范數(shù)據(jù)查詢所使用的身份憑證實(shí)現(xiàn)數(shù)據(jù)來源、加工流程全程可追溯管控 Agent 修改原始業(yè)務(wù)數(shù)據(jù)庫的權(quán)限留存 Agent 生成結(jié)論所引用的數(shù)據(jù)來源針對誤操作行為完成審計(jì)追蹤與回滾操作。在 AWS 整套數(shù)據(jù)架構(gòu)體系內(nèi)依靠 AWS Glue Data Catalog 統(tǒng)一管理元數(shù)據(jù)與數(shù)據(jù)存放位置借助 AWS Lake Formation 在數(shù)據(jù)湖層面實(shí)現(xiàn)精細(xì)化權(quán)限管控。 峰會(huì)分享《Agentic AI 的數(shù)據(jù)之道》提及數(shù)據(jù)消費(fèi)端聚焦數(shù)據(jù)質(zhì)量、數(shù)據(jù)可發(fā)現(xiàn)能力、訪問權(quán)限、安全管控、低延遲訪問五大維度數(shù)據(jù)生產(chǎn)端依靠數(shù)據(jù)流、ETL 加工、數(shù)據(jù)質(zhì)量校驗(yàn)、數(shù)據(jù)目錄、治理組件把原始數(shù)據(jù)加工成可供 Agent 調(diào)用的數(shù)據(jù)產(chǎn)品。由此可見企業(yè)不能簡單分配數(shù)據(jù)庫賬號任由 Agent 自由查詢數(shù)據(jù)表。安全穩(wěn)妥的實(shí)施方案為為 Agent 配置受控?cái)?shù)據(jù)工具、預(yù)設(shè)查詢語句、專用 API 接口將身份認(rèn)證、權(quán)限校驗(yàn)、審計(jì)流程內(nèi)嵌至整體調(diào)用鏈路之中。十、企業(yè)選型 AWS 數(shù)據(jù)層、記憶層服務(wù)的六步判斷法則企業(yè)可通過六大核心問題完成服務(wù)選型匹配Agent 僅需解答知識性問題還是需要調(diào)取實(shí)時(shí)業(yè)務(wù)狀態(tài) 僅解答制度、產(chǎn)品、文檔類問題以 Amazon Bedrock 知識庫搭配向量檢索組件作為起步方案 如需讀取客戶、訂單、庫存、任務(wù)實(shí)時(shí)狀態(tài)接入 Amazon Aurora、Amazon DynamoDB 等業(yè)務(wù)數(shù)據(jù)庫服務(wù)。Agent 是否存在跨系統(tǒng)數(shù)據(jù)分析需求 企業(yè)業(yè)務(wù)數(shù)據(jù)分散在多套應(yīng)用系統(tǒng)時(shí)優(yōu)先依托 Amazon S3、Amazon S3 Tables、AWS Glue、數(shù)據(jù)目錄搭建統(tǒng)一全域數(shù)據(jù)底座。Agent 是否要開展深度復(fù)雜數(shù)據(jù)分析 數(shù)據(jù)湖臨時(shí)靈活查詢選用 Amazon Athena成熟穩(wěn)定、高頻運(yùn)行的企業(yè)級數(shù)據(jù)分析場景推薦 Amazon Redshift。Agent 是否需要對接并處理實(shí)時(shí)事件流 涉及日志解析、設(shè)備時(shí)序數(shù)據(jù)、消息流處理場景部署 Amazon Kinesis 或 Amazon MSK搭配流式處理組件完成事件識別。Agent 是否需要跨會(huì)話記住用戶特征與歷史任務(wù) 采用 Amazon Bedrock AgentCore Memory 統(tǒng)一管理長短記憶再結(jié)合數(shù)據(jù)體量搭配 Amazon S3 Vectors、Amazon OpenSearch Service、Amazon Aurora PostgreSQL、Amazon DynamoDB、Amazon ElastiCache 組合部署。Agent 是否擁有修改業(yè)務(wù)數(shù)據(jù)的權(quán)限 若 Agent 需要?jiǎng)?chuàng)建訂單、新增工單、提交審批單據(jù)必須經(jīng)由受控 API、工具調(diào)用模式執(zhí)行寫入操作嚴(yán)禁直接開放底層數(shù)據(jù)庫寫入權(quán)限。十一、AWS 核心優(yōu)勢打通知識、數(shù)據(jù)、動(dòng)作、記憶的完整業(yè)務(wù)閉環(huán)企業(yè) AI Agent 實(shí)現(xiàn)規(guī)?；涞氐耐暾溌贩譃樗拇蟓h(huán)節(jié)依托知識庫與企業(yè)全域數(shù)據(jù)源檢索所需信息借助分析引擎解析業(yè)務(wù)數(shù)據(jù)的變化規(guī)律通過工具接口、外部 API 執(zhí)行業(yè)務(wù)操作動(dòng)作將任務(wù)狀態(tài)、關(guān)鍵執(zhí)行結(jié)果持久化寫入記憶體系。在這套閉環(huán)架構(gòu)中AWS 并非提供單一獨(dú)立的知識庫產(chǎn)品而是一套可靈活拼裝組合的數(shù)據(jù)服務(wù)矩陣Amazon S3、Amazon S3 Tables承載企業(yè)統(tǒng)一數(shù)據(jù)底座AWS Glue負(fù)責(zé)數(shù)據(jù)集成加工、元數(shù)據(jù)目錄管理Amazon Athena、Amazon Redshift提供多場景分析查詢能力Amazon Aurora、Amazon DynamoDB、Amazon ElastiCache支撐業(yè)務(wù)數(shù)據(jù)存儲(chǔ)與實(shí)時(shí)狀態(tài)讀寫Amazon OpenSearch Service、Amazon Neptune Analytics、Amazon S3 Vectors適配各類語義檢索場景Amazon Bedrock 知識庫搭建標(biāo)準(zhǔn)化 RAG 檢索鏈路Amazon Bedrock AgentCore Memory統(tǒng)籌短期狀態(tài)與長期記憶Amazon Kinesis、Amazon MSK接入實(shí)時(shí)流式數(shù)據(jù)。綜上當(dāng)企業(yè)發(fā)現(xiàn)僅依靠知識庫無法支撐 AI Agent 業(yè)務(wù)運(yùn)行時(shí)無需持續(xù)往知識庫內(nèi)堆砌海量數(shù)據(jù)。正確建設(shè)思路是把知識數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、分析數(shù)據(jù)、實(shí)時(shí)事件、記憶數(shù)據(jù)分別歸入對應(yīng)分層架構(gòu)依托受控工具與統(tǒng)一架構(gòu)實(shí)現(xiàn)互聯(lián)互通。如需深入了解企業(yè) AI Agent 對接業(yè)務(wù)數(shù)據(jù)庫、湖倉體系、實(shí)時(shí)數(shù)據(jù)流、長期記憶的實(shí)施方案可前往亞馬遜云科技官網(wǎng)首頁 Banner或是檢索「2026 亞馬遜云科技中國峰會(huì)」在回放專區(qū)進(jìn)入分論壇 3回看《Agentic AI 的數(shù)據(jù)之道Agent 自己找數(shù)據(jù)、記數(shù)據(jù)、管數(shù)據(jù)你準(zhǔn)備好了嗎》《Athena IcebergAI Agent 的數(shù)據(jù)底座實(shí)戰(zhàn)》《高性能存儲(chǔ)加速生成式 AI》三場演講回放并獲取配套資料。