AWS在2026年9月8日宣布，Amazon Bedrock AgentCore Memory支持把内容直接送入长期记忆提取流程。新的IngestData API不要求开发者先创建短期记忆事件，适合只想保留结构化记忆、原始交互已经存放在其他系统的AI应用。
过去，内容必须先通过短期事件进入AgentCore Memory，再由配置好的策略提取长期记录。现在短期事件和长期记忆可以独立使用，开发者能够减少重复保存原始对话的开销，但也需要理解直写后无法通过事件接口找回原文。
长期记忆不再依赖短期事件
IngestData接收内容后，会把它发送给这项Memory资源已经配置的长期记忆策略。策略从对话或事件中提炼偏好、事实和其他可复用信息，并生成与普通长期记忆相同的记录。
这条路径不会创建可检索的短期事件，因此提交内容不能再通过GetEvent、ListEvents或ListSessions读取，也不能使用分支功能重新组织。
直写长期记忆不是把原始记录换一个存储位置，而是主动放弃AgentCore中的短期原文。需要保留完整交互时仍应使用CreateEvent。
对话和JSON事件都能直接提交
新API支持两类负载。第一类是带有USER或ASSISTANT角色的对话消息，第二类是JSON格式的行为事件、活动日志或系统事件。
开发者还可以附加结构化元数据，为后续提取和筛选提供更多上下文。已经在业务数据库、数据湖或日志平台保存原始交互的系统，可以只把需要提炼的副本交给长期记忆服务。
内容会分发给Memory中配置的长期策略，但自主管理策略有自己的处理流程，不走这条自动分发路径。迁移前需要确认当前使用的策略类型。
Actor、Session和Namespace决定上下文边界
每次提交都需要通过actorId标识用户或智能体，通过sessionId归类一次会话。长期记忆记录还受到namespace约束，用于组织不同类型或业务范围的数据。
具有相同actorId、sessionId和namespace的内容会在提取时被视为相关上下文。标识设计不清可能把不同用户的信息混在一起，或让同一个用户的连续行为被错误拆开。
在接入API之前，应先固定租户、用户、会话和记忆类型的映射规则。这比调用接口本身更影响多租户应用的数据隔离。
成功响应不代表记忆已经生成
IngestData采用异步处理。请求成功只表示内容已被服务接受，长期记录通常会在数秒至数分钟后出现，具体时间取决于内容大小和策略配置。
应用可以使用ListMemoryRecords或RetrieveMemoryRecords确认提取结果，也能配置Kinesis流，在新记忆记录生成时接收实时通知。
业务流程不应在API返回后立刻假定记忆可用。需要马上依赖结果的对话，最好加入状态检查、合理等待和没有命中时的降级逻辑。
失败任务可以进入队列后重新处理
提取失败后，AgentCore会把任务放入该Memory资源的专用失败队列。管理员可以通过ListMemoryExtractionJobs查看任务，在修复根因后使用StartMemoryExtractionJob重新驱动。
AWS还提供FailedExtraction CloudWatch指标，并支持为AgentCore运行时、Memory和其他组件启用日志与追踪。生产环境应监控接受成功但迟迟没有生成记录的情况。
新API已在所有支持AgentCore Memory的AWS区域提供。上线前除了验证记忆质量，还应检查原始交互的留存责任、敏感信息处理和删除流程，因为不保存短期事件并不等于上游系统没有保存数据。
