AWS发布基于AgentCore与OpenClaw的持久记忆个人助理教程
AWS机器学习博客发布一篇教程，演示如何用OpenClaw智能体框架配合Amazon Bedrock AgentCore运行时与记忆能力，搭建一个能跨会话积累上下文的个人助理。示例为一个名为Sprout的园艺助理，整套系统放在单个CloudFormation模板中。
AI解读：这篇教程解决的是一个具体问题：普通助理每次对话都从零开始，用户需要反复说明背景。AWS的方案是把每次对话作为事件写入AgentCore memory，再用USER_PREFERENCE、SEMANTIC、SUMMARIZATION三种抽取策略生成长期记录，下次对话时检索并注入系统提示。
记忆并非即时可用。来源明确说明抽取是异步的，本次会话提到的事实通常要到后续会话才能被检索到，因此教程把当前会话交给短期记忆、历史内容交给长期记录。
成本上，来源给出的是作者基于轻量个人使用的估算：截至 2026 年 7 月，按消费计费的AgentCore运行时约每月 1 到 2 美元，而一直开着的EC2实例约每月 35 美元。这是估算值，来源提示以AgentCore官方定价为准。
教程给出的一个具体经验是，视觉模型单凭照片可能出错——同一株植物此前被识别为牵牛花，接入用户已存的花园清单后才修正为墨西哥牵牛并诊断出萎蔫热应激。这说明记忆改善的是具体场景下的判断，而不只是一个演示。
来源提到的提示缓存收益为：受支持模型上成本最多降低 90%、延迟最多降低 85%。这是AWS给出的数字，适用于其支持缓存的模型和该教程的提示结构（稳定内容在前、易变内容在后）。
AWS机器学习博客发布一篇教程，题为《Building a context-aware AI assistant on AgentCore and OpenClaw》，作者Thiago Verney，演示如何搭建一个跨会话保留上下文的个人助理。示例应用Sprout是一个园艺助理，整套系统放在单个AWS CloudFormation模板中，通过一条命令部署。
教程的核心主张是：现成助理回答单个问题表现不错，但缺少连续性，用户需要反复解释背景。方案用OpenClaw作为智能体循环与技能层，运行在Amazon Bedrock AgentCore runtime上，并由AgentCore memory把一次性对话转成可检索的持久记录。
架构：Telegram入口、OpenClaw网关与两个模型
来源给出的请求流程是：Telegram消息经Amazon API Gateway和webhook Lambda进入，定时任务经Amazon EventBridge Scheduler和cronjob Lambda进入，两者都调用AgentCore runtime的InvokeAgentRuntime API。容器内的server.py协调OpenClaw网关、AgentCore memory与Amazon Bedrock Converse API。S3存工作区，KMS负责加密，Secrets Manager保存bot token，CloudWatch收集日志与指标。
模型按任务分流：文字对话走OpenClaw网关并调用Claude Haiku 4.5，图像理解绕过网关、由server.py直接调用Bedrock上的Claude Sonnet 4.5。来源解释绕过网关的原因：容器内OpenClaw构建会在内容到达Bedrock前丢掉image_url部分。模型ID放在环境变量MODEL_ID与VISION_MODEL_ID中，可在部署时更换而不重建镜像。
- 运行时要遵循的容器约定：监听 8080 端口，暴露GET /ping健康检查和POST /invocations入口。
- 来源提示AgentCore可能唤醒子进程已退出的冻结容器，所以调用路径用ensure_openclaw_ready() 在转发前重新检查并按需重启网关。
- Telegram回复被渲染为HTML，因为来源称其旧版markdown对未转义字符很敏感，一个多余的下划线就可能导致整条消息发送失败。
记忆的两层结构与检索条件
AgentCore memory分两层。短期记忆用CreateEvent保存每一轮对话，以actorId（即Telegram聊天ID）和sessionId为键，是原始记录。长期记忆由托管抽取策略异步生成结构化记录，本教程配置了三种策略：USER_PREFERENCE保存用户明确说过的选择，SEMANTIC保存推断出的事实，SUMMARIZATION保存会话摘要。
记录按用户分命名空间：sprout/{chat_id}/long_term放偏好和语义事实，sprout/{chat_id}/episodic/{session_id} 放会话摘要。聊天ID是唯一可变的片段。
检索时以用户消息为查询，针对long_term命名空间取最多 50 条结果，预算 3 秒；超时或出错则不带记忆作答，而不是让回复失败。组装函数把显式偏好排在推断事实之前，类别内顺序稳定，最后按上限截断。
- 命名空间回答“这是谁的记忆”，元数据回答“这是关于什么的”。来源强调：只有声明为索引键的元数据键才能在服务端过滤。
- Sprout声明了三个索引键：type（记录种类）、section（描述的苗床或区域）、plants（种了什么），三者都是STRING或STRINGLIST类型。
- 对推断出的键可把取值限制在固定列表内，教程这样做的理由是两个写入路径会产生同一套词汇，过滤条件含义一致。
- 每轮回复后server.py用CreateEvent写入用户与助理两轮内容，供抽取策略异步补充长期记忆；写入错误只记录日志，不视为致命错误。
示例中的效果与成本数字
教程给出一个端到端例子：用户此前逐株用自然语言描述过花园，抽取策略把植株、位置和光照写入长期记录。某天用户问“还记得我花园里的其他植物吗”，检索与组装把记录注入系统提示，助理答出位置、光照、苗床结构、土壤特性和植物清单，而这些都没有出现在当前消息中。
来源还描述了一次视觉识别修正：在还没有清单上下文的早前对话中，同一株植物被自信地识别为牵牛花（花朵形状相似）；把用户已存的植物清单作为上下文后，助理把它匹配为墨西哥牵牛并诊断为蔫萎热应激。
成本方面，来源称按消费计费的AgentCore runtime只对代理实际消耗的计算计费，等待模型响应等I/O时间不计费，轻量个人使用约为每月 1 到 2 美元基线，而一直开机的EC2实例约每月 35 美元，并注明这些是截至 2026 年 7 月的估算，当前费率以AgentCore定价页为准。
提示缓存部分，来源称把稳定前缀（人设与组装好的记忆块）放在前面、易变用户消息放在最后，Bedrock会跨请求缓存已处理前缀；受支持模型上成本最多降低 90%、延迟最多降低 85%。来源强调这一结构习惯比任何单项设置都重要，并要求记忆块内部顺序确定，以便前缀能在请求间匹配。
- 前置条件包括：AgentCore runtime与memory访问权限，Claude Haiku 4.5（文本）和Claude Sonnet 4.5（视觉）的模型访问，支持linux/arm64的Docker与已配置的AWS CLI（仅自建镜像时需要），以及BotFather签发的Telegram bot token。
- 来源列出的设计准则包括：用薄HTTP包装层适配AgentCore容器契约而不改框架；先设计命名空间；把记忆当作增强而非依赖，允许其失败；按任务路由模型；为缓存安排提示顺序；考虑抽取延迟；从第一天就设置预算告警。