北京
给交易Agent做记忆层，最常见的起手式是直接装一个向量数据库。但一个在Base上迭代了三版记忆层的实践者给出的结论相反：60–70%的召回来自词法搜索——ticker、合约地址、哈希、函数名，这些东西用向量反而搜不准。
他的判断很直白：一个systemctl restart之后就全忘光的Agent，算不上Agent，那只是一个token更贵的cron job。这句话把记忆层从"加分项"拉回了"及格线"的位置。
三版迭代的路径值得复盘。第一版最土：一个Python字典，每30秒dump成JSON落盘。第二版换成Pinecone，结果撞上两个问题——没有租户过滤，以及月度账单和实际查询量完全不成比例。第三版回到起点：从磁盘上的一个SQLite文件开始，只有当Agent需要多于一个worker时，才升到libSQL云端。
这个顺序是刻意的。先FTS5，后向量，而不是反过来。理由藏在Agent实际要检索的内容里：交易场景下高频出现的查询对象是代码化的、精确的字符串，不是模糊语义。合约地址差一个字符就是另一个合约，哈希和函数名同理，这类召回交给全文索引比交给embedding更可靠。
素材里还留了一个没写完的句子：text-embedding-3-small 不——后面断了。从上下文能确认的只有一点：这个模型被拿出来讨论过，且结论不是无条件采用。至于它具体在哪一环不够用，没有更多信息可依。
架构上的取舍也清晰：本地SQLite文件是默认形态，云端libSQL是扩容手段而非起点。多worker才上云，单worker就待在磁盘上。这个分界线把成本和复杂度都压在了真正需要的地方。
对做Agent记忆的人来说，这条路径的可迁移之处不在具体选型，而在顺序：先问清楚召回的是什么类型的数据，再决定用哪种索引。词法能覆盖大头的时候，向量库是第二层，不是第一层。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
