2.5倍写入提速：给AI智能体装上语义记忆，不用向量库

给一个无服务器AI智能体加上持久、基于含义的记忆，可以用DynamoDB原生的向量搜索配合Amazon Bedrock的嵌入模型，不需要专门的向量数据库，也不需要同步管道。在这套演示里，嵌入向量就存在条目旁边，一次 PutItem 同时写入两者，按含义检索只需要一次 SearchVectors 调用。在us-east-1实测对比，这条原生路径的写入速度约为S3 Vectors的 2.5倍 ，搜索（p50）约为 1.4倍 ——这是针对智能体热路径记忆的测量结果。 智能体为什么会"失忆" 问题出在会话之间。你问一个刚创建的智能体，上一个智能体被告知过的某个信息，它从没见过那段对话，自然无从回答。它会去调用工具，找不到东西，最后请你再说一遍。这是一次真实运行的结果：用户询问生产集群的名称和区域，工具返回的是"能否提供保存生产集群详情的引用或上下文键"。任何在AWS Lambda上跑智能体的人都会撞上这个问题——容器在两次调用之间就没了，每一轮实际上都是一个全新的智能体。 要修好"遗忘"，先得意识到这是三个不同的问题，各有各的生命周期。把它们混在一起，就会出现"记住了不该记的、忘了该记的"这种bug。 用助理来打比方：state是桌上的便利贴，session是今天这场会的笔记本，长期记忆则是助理真的记得你偏好早上部署，哪怕过了几周、哪怕你换了说法。Strands Harness（已经组装好的智能体构造器create_harness）正好暴露了两个开关：一个用来恢复当前这段对话，一个用来在所有运行之间携带数据。两者是正交的——session能扛过Lambda的销毁，记忆则能扛过一切，包括那些没有任何共同词汇的对话。 向量和条目住在一起 DynamoDB向量搜索的关键在于，向量就存在条目旁边。一张表既是你的业务存储，也是你的向量索引，不需要第二个服务。 第一步是建表时就声明向量索引，而不是事后添加。往已有条目的表上加索引会触发回填，这个回填是要按真实时间付费的。声明索引时有两个字段必须对齐，否则搜索会静默地返回无用结果： Dimensions 必须等于嵌入模型的输出维度（Titan V2为1024）， DistanceFunction 必须和你生成向量的方式一致（单位长度嵌入用COSINE）。另外，按需计费模式对向量索引是强制的。 建表脚本跑完后，DescribeTable报告ACTIVE是必要但不充分的——搜索端点可能还在滞后。脚本的做法是在重试循环里发一次真实的SearchVectors调用，所以当它打印出"searchable on attempt N"时，索引是真的能服务查询了。 第二步是把文本转成向量。DynamoDB负责存储和搜索向量，但不负责生成向量，这部分由你的代码调用Bedrock完成。嵌入辅助函数调用Titan V2模型，传入文本、维度和归一化开关，返回一个浮点数列表。归一化会产出单位长度的向量，这正是前面选择COSINE距离函数的前提。 把这两步接起来，智能体的记忆就不再依赖一张单独的向量库表，也不需要额外的同步管道。写入时向量随条目一起落库，检索时按含义一次调用取回。对于跑在Lambda上、每轮都可能是新实例的智能体来说，这条路径把"记忆"从一件需要额外基础设施的事，变成了表结构里的一列。 特别