鱼卖卖是闲鱼面向卖家的 AI 经营助理。在闲鱼卖家经营场景中，随着 AI Agent 从"回答一次问题"逐步走向"持续参与经营"，如何从长期对话和经营反馈中准确找回卖家的偏好与约束，成为影响建议质量和执行效果的关键问题。
卖家今天问的可能是"主图怎么改"，明天关心"要不要降价"，几天后又回来讨论"怎么发货"。问题看似分散，背后却是同一段经营过程。如果 AI 每次都从零开始，卖家就要反复说明自己的底价、物流偏好，以及哪些建议已经尝试过。
面对这一需求，闲鱼鱼卖卖团队以 Mem0 作为记忆层接口，使用阿里云 Milvus 承载语义记忆，构建了一套面向卖家经营场景的长期记忆方案。Agent 可以在需要时召回真正相关的历史信息，把每一次对话接回同一段经营过程。
一、客户业务背景：从"回答问题"走向"持续经营"
鱼卖卖是闲鱼面向卖家打造的 AI 经营助理，目标是帮助商品"卖得更快"。围绕卖家的自主经营程度，产品提供两类服务：
-
诊断·提升曝光： 结合商品和经营数据定位问题，说明曝光或转化不佳的原因，给出调价、修改描述、调整主图、改善履约等建议；卖家确认后，还可以继续执行相关操作。
-
托管·无忧卖： 在卖家授权范围内持续观察商品状态，自动执行经营优化，反馈进展，并根据结果调整后续策略。
这类服务往往持续数天甚至更久。比如卖家说过"最低 300 元才卖"，下次讨论调价时，这条底线仍然有效；如果卖家多次拒绝某种履约方式，Agent 也不该继续推荐。长期记忆的价值就在这里：减少重复沟通，让后续建议接得上前面的经营过程。
二、客户核心挑战：不是把所有历史都塞给模型
把完整对话塞进大模型，并不能解决记忆问题。对话里有一次性表达、工具调用轨迹和已经失效的信息。经营周期越长，上下文越臃肿，真正相关的内容反而越难找到。
在长期对话和持续经营场景中，记忆系统主要面对四类问题。
1. 分清会话记录和长期记忆
完整会话适合恢复现场和追溯过程，但不适合每轮全部注入模型；长期记忆需要从大量历史中提炼稳定、可行动的信息，例如价格约束、物流偏好、经营习惯，以及卖家对历史建议的采纳或拒绝，并在相关场景中按需召回。
2. 为不同数据选择合适的存储
原始消息、LangGraph Checkpoint、商品生命周期事件、结构化画像和语义记忆的读写方式不同。把它们放在同一个系统里，会让查询效率、时效性和治理边界都变得含糊。
3. 同时处理语义和关键词
"最低 300 才卖"和"300 以下不考虑"意思相近，适合向量召回；品牌、型号、快递公司和数字约束则更依赖词法匹配。中文经营记忆需要两种检索方式配合。
4. 把记忆安全地放进在线链路
记忆召回位于 Agent 的在线请求链路中，既要按卖家隔离数据、过滤失效记忆，也要支持私网访问、容量扩展、监控和故障排查。同时，团队不应为此承担自建向量数据库的全部运维工作。
三、整体技术方案
鱼卖卖的长期记忆方案并没有将所有数据统一塞进向量数据库，而是根据数据类型选择不同的存储：PG 与 LangGraph Checkpoint 保存原始消息、压缩摘要、会话状态和工具轨迹；OTS 保存确定性用户画像、商品生命周期事件与在线业务状态；ODPS 与 DataWorks 承载离线明细、实验数据和评测结果；阿里云 Milvus 则专门保存需要按语义相关性召回的长期记忆。
整体链路可以分为三个阶段：记忆准备阶段、检索阶段和应用阶段。
在记忆准备阶段，系统从卖家对话、工具执行结果和经营反馈中识别值得长期保存的信息，过滤一次性表达、内部工具轨迹和不应长期保存的内容。随后，记忆被归纳为简洁、可行动的文本，并标记卖家身份、记忆类型、适用范围、状态和更新时间。文本经过 Embedding 模型生成 1024 维稠密向量，同时建立稀疏向量与 BM25 索引，最终写入 Milvus。
在检索阶段，记忆编排层根据当前任务构造 Query。Query 一路进入 Embedding 模型生成稠密向量，一路通过中文分词形成关键词检索条件。Milvus 并行完成向量检索和 BM25 检索，并利用标量字段限定卖家、商品、记忆类型和有效状态。两路召回结果经过融合与业务规则筛选，得到与当前问题最相关的少量记忆。
在应用阶段，召回结果作为长期上下文输入 Agent，与当前会话、实时商品状态和经营数据共同参与推理。Agent 据此生成建议，或在卖家授权范围内决定下一步工具动作。执行结果和卖家反馈又会回到记忆准备链路，形成"召回---决策---执行---反馈---更新"的闭环。
场景一：诊断与提升曝光
当卖家发现商品曝光或转化不佳时，鱼卖卖会结合商品信息与经营数据定位问题，并给出调价、修改描述、调整主图或改善履约等建议。
在没有长期记忆的情况下，Agent 每次只能根据当前商品数据给出通用判断。卖家可能刚刚拒绝过某种调价方案，下一次对话中却再次收到同样的建议；也可能已经明确表达价格底线，但系统仍然推荐低于底价的方案。
加入长期记忆后，系统会在诊断前按当前任务召回相关偏好与约束。例如，当卖家询问"这个商品还能怎么优化"时，稠密向量可以召回"卖家希望尽快成交，但不接受大幅降价"等语义相关记忆，BM25 则补充具体的商品型号、价格数字和物流关键词。Agent 再将这些记忆与实时曝光、点击和市场价格信息结合，生成更符合卖家经营边界的建议。
卖家确认后，鱼卖卖还可以继续执行相应操作。长期记忆在这里不仅影响"怎么回答"，也为后续工具动作提供决策依据，减少卖家重复说明和 Agent 重复试错。
场景二：托管与持续经营
在"托管·无忧卖"场景中，卖家在授权范围内将部分经营工作交给鱼卖卖。Agent 会持续观察商品状态，执行经营优化，反馈进展，并根据结果调整后续策略。与单次问答相比，这类任务持续时间更长，也更依赖跨会话信息。
例如，某位卖家允许系统优化标题和主图，但价格调整必须再次确认；或者卖家多次拒绝某种履约方式，希望后续不再推荐。此类信息如果只保存在某一轮对话中，很容易随着会话结束而丢失。
在鱼卖卖的分层方案中，商品当前状态、任务进度和授权开关由结构化系统负责精确查询；卖家的稳定偏好、历史反馈和策略经验则写入 Milvus。Agent 每次制定新策略前，先读取当前状态，再召回相关长期记忆，从而判断哪些动作可以自动执行、哪些需要卖家确认、哪些方案已经尝试过。
当一次优化完成后，执行结果与卖家反馈还可以形成新的候选记忆。例如，某种标题优化曾带来积极反馈，或者卖家再次拒绝同一类发货建议。经过抽取、去重和更新后，这些信息会成为后续经营决策的参考，让 Agent 不只是"记得卖家说过什么"，还能够接着过去的经营结果继续工作。
未来展望
随着鱼卖卖覆盖更多经营任务，长期记忆还将从"保存偏好"进一步走向"沉淀经营经验"。
在业务层面，可以逐步扩展记忆的作用范围：从价格、物流和文案偏好，延伸到跨商品的经营习惯、历史策略效果和阶段性经营目标，让 Agent 在更多任务之间复用经验。同时，需要持续明确用户级、品类级和商品级记忆的适用边界，避免局部经验被错误泛化。
在检索层面，可以继续优化稠密向量、BM25 和业务排序的融合策略，并通过离线评测与线上实验，观察不同类型记忆的召回率、准确率和实际使用效果。对于新旧偏好冲突、长期未使用信息和阶段性约束，还需要进一步完善更新、合并、衰减与失效机制。
在工程层面，可以结合阿里云 Milvus 持续演进的 AI Function、混合检索和重排序能力，进一步缩短从文本处理、向量化到召回精排的链路；同时继续完善私网访问、监控告警、容量规划和故障降级，使长期记忆稳定服务于更大规模的在线 Agent 请求。
综上，鱼卖卖的实践表明，Agent 长期记忆并不是把所有历史对话交给大模型，而是建立一套分层、可检索、可更新的记忆系统。阿里云 Milvus 凭借语义向量、BM25 全文检索、标量过滤和云上托管能力，在其中承担了长期语义记忆底座的角色。
当卖家再次讨论价格、物流或托管策略时，Agent 可以从过去的经营过程继续往下走。每一次对话不再是孤立问答，而是同一段经营旅程的下一步。