企业 AI Agent 只靠知识库难以满足业务需求该选用哪些云上数据服务搭建数据层、记忆层AWS 分层数据架构选型指南绝大多数企业搭建 AI Agent 的起步方式都是接入文档知识库依靠产品手册、公司制度、操作教程和历史资料实现问答功能。 但知识库只能检索已经写好的静态资料。一旦企业想要让 Agent 查询实时业务数据、跟进任务进度、操作系统完成业务动作、记住用户喜好甚至自动更新数据只依靠知识库就会出现明显短板。能够正式投产使用的企业 AI Agent必须打通七大类型数据源 企业知识与非结构化文档、客户订单库存等业务数据、数据湖分析平台、实时数据流、工具外部 API、当前任务状态、短期与长期记忆。所以企业不该搭建孤立的 RAG 知识库而是打造一套云上数据底座让 Agent 具备查数据、用数据、写数据、存记忆的完整能力。基于 AWS 全系服务企业可以组合 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搭建分层的数据 记忆架构。一、只部署知识库AI Agent 很快会碰到能力天花板传统 RAG 知识库适合存放长期不变的内容比如员工守则、售后规则、技术文档、产品介绍、过往案例。 但企业日常很多业务问题单凭文档根本回答不了。 举几个真实场景客户问订单为什么没发货Agent 不能只查物流规则还要读取订单状态、库存、物流信息销售想找出本月容易流失的客户Agent 需要分析客户活跃度、合同、工单、使用行为不能只翻客户手册运营要查明某个区域销量下跌的原因Agent 必须访问数据湖、数仓拆解指标做对比分析。不难看出知识库仅仅是 Agent 数据体系的一部分。2026 亚马逊云科技中国峰会《Agentic AI 的数据之道Agent 自己找数据、记数据、管数据你准备好了吗》提出Agent 对接数据分为七条路径知识库 RAG、分析引擎、业务数据库、流式实时数据、湖仓、外部 API、记忆管理。我们可以把 Agent 用到的数据划分成 5 大类知识数据文档、网页、制度、产品资料业务数据客户、订单、库存、账户、交易记录分析数据运营指标、报表、历史明细、跨系统汇总数据实时数据设备遥测、用户点击行为、系统日志、事件消息状态记忆数据会话状态、任务进度、工具返回结果、用户长期偏好。不同数据更新快慢、查询方式、权限都不一样不能全部塞进同一个知识库或者向量数据库。二、第一层业务数据层让 Agent 读写真实业务状态AI Agent 想要从只会回答问题升级成能干活执行任务第一步就要对接真实的业务系统。 业务数据包含客户资料、订单合同、产品库存、账户状态、售后工单、审批进度、系统配置、Agent 执行结果。 这类数据都是结构化的不停更新很多场景还需要 Agent 写入新数据例如新建工单、修改预约、更新任务状态、提交审批。Amazon Aurora处理存在关联关系的核心业务数据 如果业务数据相互关联需要事务能力、条件查询、多表联查就选用 Amazon Aurora。 客服 Agent 可以先查客户身份再关联订单、付款、工单销售 Agent 把客户资料和合同、产品、跟进记录放在一起分析。 Amazon Aurora 支持向量和结构化字段混合查询如果企业希望把客户信息、业务字段、语义内容整合在一套数据模型里Aurora PostgreSQL 十分合适。Amazon DynamoDB承载高并发任务状态与键值数据 会话状态、任务节点、Agent 断点、用户个性化配置、高并发键值读写场景优先用 Amazon DynamoDB。 这类数据不需要复杂联表但要求读取速度快、弹性扩容可通过用户、会话、任务 ID 精准定位。 多步骤运行的 Agent 每完成一步就更新任务状态就算中途断掉读取检查点就能接着运行不用从头再来。Amazon ElastiCache存放高频访问的临时状态数据 经常反复调取的会话信息、热门查询结果、临时计算内容可以用 Amazon ElastiCache 搭建高速缓存层。 它适合需要极速响应、不需要永久保存的数据。比如 Agent 反复查询同一款产品信息直接读取缓存即可减少反复访问后端数据库。总而言之业务数据层不能只用一款数据库结构化业务数据、高并发状态、临时缓存要分开选用对应服务。三、第二层数据湖仓层实现 Agent 跨系统全域取数业务数据库一般跟着单个业务系统搭建企业系统变多之后客户、产品、供应链、财务、运营数据散落各处。 如果 Agent 只能访问某一个业务库就做不了跨部门数据分析。这时就需要搭建统一湖仓集中管理、查询、治理所有来源的数据。在 AWS 架构中用 Amazon S3、Amazon S3 Tables 承载原始数据搭配 AWS Glue、Amazon Athena、Amazon Redshift 完成数据加工与分析。Amazon S3搭建企业统一大容量数据底座 Amazon S3 能够存放结构化、半结构化、非结构化所有类型数据业务明细、日志、文件、文档、归档资料全都可以存入。 它最大的作用不是单纯存文件而是让计算、分析各类组件共用同一份原始数据。 针对企业 AI AgentAmazon S3 数据湖作为跨系统数据统一载体知识库、分析引擎、机器学习、Agent 工具都能按需调取湖内数据。 峰会演讲《高性能存储加速生成式 AI》把数据底座、长期记忆、知识库、实时数据流、短期工作记忆统一归入 AI Agent 存储架构点明存储就是 Agent 的外部大脑。Amazon S3 Tables Apache Iceberg管理会持续变更的湖内表格 数据湖里面的数据并非一成不变订单状态、产品信息、测试数据、业务指标都会持续更新。 借助 Amazon S3 Tables 搭配 Apache Iceberg可以以数据表形式管理湖内数据适配数据分析场景的数据组织模式。 当 Agent 需要查看数据历史变化、读取最新业务数据或是多个分析平台共用一套数据表时这种湖上表架构远比零散文件存储更适合正式生产环境。AWS Glue负责数据接入、清洗加工与元数据目录 各类数据汇入数据湖之后还要完成抽取、清洗、转换、元数据管理工作。 AWS Glue 负责 ETL 数据处理依靠 AWS Glue Data Catalog 统一管理数据表、字段含义、数据存储位置。Agent 和分析工具无需反复查找数据位置、辨认字段含义。 在 Agent 架构里元数据尤为关键Agent 先要发现有哪些数据、看懂表结构和业务含义再选择正确方式执行查询。四、第三层分析查询层支撑 Agent 解答复杂数据分析类问题知识库检索只会返回几段相关文本而企业数据分析需要做计算、筛选、聚合、对比。 当用户提出下面这类问题Agent 必须调用专业分析引擎 本月销售额为何下滑、哪些产品故障率大幅上涨、各区域客户流失率差异、各类工单平均耗时多久、某项指标半年走势变化。Amazon Athena直接在数据湖上做即时 SQL 查询 Amazon Athena 支持使用 SQL 查询 Amazon S3 中的湖数据企业不用每做一次分析就新建一套数据库。 数据湖临时探查、自然语言转数据分析、日志排查、跨数据集探索场景Amazon Athena 灵活易用。 Agent 可以把自然语言问题拆解成查询任务通过受控工具调用 Athena 拿到结果。对比把整张数据表塞进大模型上下文该方案适配海量数据模型仅接收最终查询结果。Amazon Redshift企业级数仓承载大规模稳定分析业务 企业拥有成熟指标体系需要海量数据分析、复杂报表、高频业务查询时部署 Amazon Redshift。 它用来汇总各部门数据形成统一分析平台向上游 Agent 输出经过治理的标准数据。 企业还可以预设查询语句、数据 API、语义指标层让 Agent 调取标准业务指标避免模型随意拼接运算逻辑造成错误。Amazon Athena 结合 Apache Iceberg 组合方案 企业以 Amazon S3 为底层底座采用 Apache Iceberg 管理湖内数据表后可通过 Amazon Athena 查询湖表。 这套架构既能支撑传统 BI、机器学习也能对接 AI Agent底层数据源完全统一上层各类应用按需选用计算模式即可。五、HP Nova 实战案例优先搭建统一数据底座再迭代 Agent 上层应用2026 亚马逊云科技中国峰会《Athena IcebergAI Agent 的数据底座实战》分享了 HP Nova 团队的数据架构三次迭代过程。 初期团队的数据分散在多套本地系统数据处理脚本零散传统报表仅供人工查看无法对接 AI Agent。 之后团队完成系统上云基于 Amazon S3、Apache Iceberg、AWS Glue Data Catalog、Amazon Athena 搭建统一数据底座。原有 BI 系统、机器学习任务、大模型自然语言查询均可复用这套底层数据。 统一底座落地后架构升级为中心化数据平台结合 IaC、工作流编排优化新数据源接入与运维效率。该案例给到的核心经验不要每新增一个 Agent就单独搭建一套数据体系。 正确做法是先把散落的数据收拢到统一开放的数据底座再让 BI、机器学习、知识库、各类 Agent 共同复用底座资源。后续上层 Agent 不断更新迭代底层数据架构不需要反复重构。六、第四层实时数据层让 Agent 实时捕捉正在发生的业务变动数据湖、数仓主要用来复盘历史数据可是不少生产场景里的 Agent必须实时感知业务当下的动态变化。 常见需要实时监控的场景包含 设备温度突然升高、库存低于安全水位、用户最新操作行为、交易触发风控规则、物流状态更新、系统爆出异常日志。这类实时数据会经由 Amazon Kinesis 或者 Amazon Managed Streaming for Apache KafkaAmazon MSK搭建实时数据流通道再利用 AWS Glue、Apache Spark、Apache Flink 做流式处理。不需要把所有实时原始数据全部发给 Agent更高效的做法是先用流处理程序做好过滤、聚合、事件识别只把和当前任务相关的结果传给 Agent。 举个例子系统提前监测设备数值只有出现异常事件时才唤醒运维 Agent。既能避免无效数据塞满模型上下文也不会让 Agent 被源源不断的数据流占用算力。七、第五层知识与语义检索层知识库有用但不能单独运行知识库并不是没用而是必须和其他几层数据架构配合使用。 Amazon Bedrock 知识库能够对接各类数据源与向量存储搭建企业 RAG 检索链路。根据不同场景底层可以搭配这些组件 Amazon OpenSearch Service、Amazon Aurora PostgreSQL、Amazon Neptune Analytics、Amazon DocumentDB、Amazon Redshift、Amazon ElastiCache for Valkey、Amazon S3 Vectors。各个服务分工不同 Amazon OpenSearch Service适合语义 关键词混合检索多用于线上问答场景 Amazon Aurora PostgreSQL可以将向量和客户、订单、权限、产品等结构化字段联合查询 Amazon Neptune Analytics主打 GraphRAG适合分析实体关系、推导逻辑路径 Amazon S3 Vectors存放量大、很少访问、看重成本的向量数据和线上向量库组成冷热分层架构。落地逻辑可以分工知识库回答规则类问题业务数据库给出实时业务状态分析引擎解释数据变化原因最后由 Agent 整合全部信息制定执行方案。八、第六层短期状态 长期记忆层确保连续任务下 Agent 不会丢失上下文数据层解决企业有什么数据记忆层管控 Agent 在会话、连续任务里该留存哪些信息。1.短期状态短期状态包含当前对话内容、任务做到哪一步、工具返回的结果、阶段性分析数据、多步骤任务执行状态、出错后用来恢复的检查点。 这类数据按照读写特点存储在 Amazon DynamoDB、Amazon ElastiCache、Amazon S3 Files 等状态存储中即可。2.长期记忆长期记忆包含用户长久的使用偏好、已经核实的事实、过往任务结果、历史操作经验、跨会话需要重复使用的信息。 Amazon Bedrock AgentCore Memory 统一管理短期状态和长期记忆完成记忆存储、检索、跨会话复用整套流程。 大量低频访问的历史记忆、语义数据可以放在 Amazon S3 Vectors 做长期存储近期经常调取的记忆则搭配 Amazon OpenSearch Service、Amazon Aurora PostgreSQL、缓存组件做成线上快速召回层。3.缓存机制2026 亚马逊云科技中国峰会的演讲将 Agent 缓存划分成查询缓存、语义缓存、状态缓存三类。 缓存能够降低响应速度、减少反复调用大模型的次数减轻后端系统压力。 比如多名用户问相似问题Agent 可以直接复用已经生成并验证完毕的答案同一个任务反复查询相同业务数据优先读取缓存即可。九、数据治理一定要前置不要等 Agent 上线之后再补救Agent 能够访问的数据越多越要明确数据访问边界。 企业必须落实这些治理事项 限定 Agent 可以探查的数据范围、区分不同用户可查看的字段、敏感信息脱敏、规范查询身份、全程追溯数据来源与处理过程、管控 Agent 修改原始业务数据的权限、记录结论引用的数据来源、审计并回滚错误操作。在 AWS 架构里依靠 AWS Glue Data Catalog 管理元数据和数据位置依靠 AWS Lake Formation 在数据湖实现精细化权限管控。 《Agentic AI 的数据之道》演讲提到使用数据的一方关心数据质量、能不能找到数据、访问权限、安全性、访问速度产出数据的一方依靠数据流、ETL、数据质检、数据目录、治理服务把原始数据加工成 Agent 可以直接使用的数据产品。这也就说明不能随便给 Agent 分配数据库账号任由它随意查表。更安全的做法是给 Agent 开放受控的数据工具、预设查询语句或者专用 API把身份校验、权限控制、审计环节嵌入整条调用链路。十、企业如何挑选 AWS 的数据层与记忆层组件通过下面 6 个问题就能完成初步选型Agent 只用来回答知识问题还是需要读取实时业务状态 只解答制度、产品、文档问题只用 Amazon Bedrock 知识库加向量检索就能起步 需要读取客户、订单、库存、实时任务状态就要接入 Amazon Aurora、Amazon DynamoDB 这类业务数据库。Agent 需要做跨系统数据分析吗 数据分散在多个业务系统的情况下先搭建以 Amazon S3、Amazon S3 Tables、AWS Glue、数据目录为核心的统一数据底座。Agent 是否要做复杂数据分析 在数据湖上灵活临时查询用 Amazon Athena稳定高频的企业级分析场景选用 Amazon Redshift。Agent 需要处理实时事件流吗 需要解析日志、设备数据、消息流时部署 Amazon Kinesis 或 Amazon MSK搭配流处理组件识别事件。Agent 需要跨会话记住用户、历史任务吗 使用 Amazon Bedrock AgentCore Memory 管理长短记忆再根据数据规模组合 Amazon S3 Vectors、Amazon OpenSearch Service、Amazon Aurora PostgreSQL、Amazon DynamoDB、Amazon ElastiCache。Agent 是否具备改写业务数据的权限 如果 Agent 要新建订单、提交工单、发起审批只能通过受控 API、工具调用执行写入动作绝对不能直接开放底层数据库的写入权限。十一、AWS 核心优势打造知识、数据、动作、记忆完整闭环企业 AI Agent 落地投产的完整流程分为四步从知识库与企业全域数据内检索所需信息依靠分析引擎读懂业务数据的变化通过工具、外部 API 执行对应的业务操作将任务状态、关键结果存入记忆体系。在这个闭环当中AWS 并非单独售卖一款知识库产品而是一套可自由组合的数据服务体系Amazon S3、Amazon S3 Tables搭建统一企业数据底座AWS Glue负责数据加工、集成与元数据目录Amazon Athena、Amazon Redshift提供多样化分析查询能力Amazon Aurora、Amazon DynamoDB、Amazon ElastiCache承载业务数据与实时状态Amazon OpenSearch Service、Amazon Neptune Analytics、Amazon S3 Vectors支撑各类语义检索场景Amazon Bedrock 知识库搭建标准 RAG 链路Amazon Bedrock AgentCore Memory统一管理短期状态与长期记忆Amazon Kinesis、Amazon MSK接入实时数据流。所以企业遇到「只靠知识库撑不起 AI Agent」的困境时不必不停地往知识库塞入更多数据。正确思路是把知识、业务数据、分析数据、实时事件、记忆分别部署到对应的分层架构依靠受控工具与统一架构串联起来。想要深入学习企业 AI Agent 对接业务数据库、湖仓、实时数据流、长期记忆的落地方案可以前往亚马逊云科技官网首页横幅或是搜索「2026 亚马逊云科技中国峰会」进入回放页面的分论坛 3观看《Agentic AI 的数据之道Agent 自己找数据、记数据、管数据你准备好了吗》《Athena IcebergAI Agent 的数据底座实战》《高性能存储加速生成式 AI》三场演讲回放并获取详细资料。