Agent记忆系统工程实战：金融场景下长期记忆如何落地

LLM本身是无状态的，每一次调用都是失忆的重新开始。即使上下文窗口再大，也装不下一个用户三个月的对话历史。9月3日腾讯WorkBuddy金融版上线后，券商投研、保险续保率追踪等场景仍因缺乏长期记忆而反复出错，暴露了通用Agent的根本限制。

腾讯WorkBuddy金融版于9月3日正式上线，针对券商、银行、保险机构提供开箱即用的专家技能矩阵和金融数据源。它覆盖投研、合规、客户经营、信贷尽调、财富配置等核心业务，却在实际落地中反复暴露同一个问题：Agent缺少长期记忆。

金融业务逻辑复杂。一个客户经理需要同时查企业背景、翻阅历史财报、核对工商信息、搜索公告风险点，这些动作跨越数月甚至数年。保险团队长则要持续跟踪续保率、渠道表现、座席绩效和客户历史互动。单一对话轮次无法承载这些跨时间线的上下文，通用Agent每次调用都像第一次接触业务，导致重复查询、遗漏历史风险、决策不一致。WorkBuddy金融版正是通过叠加业务视图、行业Skill、专家团、MCP应用、数据连接器、流程规则和组织治理能力，试图让智能体真正进入这些现场，但长期记忆仍是绕不开的基础工程。

这不是简单扩容上下文窗口就能解决的。三个月的历史对话可能轻松超过百万token，超出任何当前大模型的实用极限。更关键的是，LLM本质上无状态，每次推理都是从零开始。金融场景对连续性要求极高，遗忘一次就可能错过关键风险点或重复劳动。这直接暴露了当前Agent在真实业务中的能力天花板，也让记忆系统成为必须补齐的工程模块。

金融业务视图直接暴露Agent无状态缺陷

金融行业的日常工作高度依赖历史累积信息。客户经理在投研时，需要把企业多年财报、工商变更记录、公告披露的风险事件、历史交易行为串成一条完整链路。缺少长期记忆的Agent每次只能看到当前输入的片段，无法自动关联三个月前发现的同一企业的股权穿透信息，导致重复劳动或遗漏关键关联方。

保险团队长的典型场景是盯续保率。他们要同时查看历史续保数据、渠道表现趋势、座席服务记录、客户投诉历史。这些数据分散在不同系统，时间跨度长。如果Agent没有持久化记忆，就无法自动生成“本月续保率环比下降的原因分析”，只能每次人工重新拉取数据、重新解释上下文。

WorkBuddy金融版明确指出，这些场景需要业务视图、数据工具、流程规则、专家经验共同协作。一个通用的Agent很难直接完成，因为它缺少对历史状态的持续感知。腾讯云副总裁胡利表示，WorkBuddy金融版的核心是在智能体框架上叠加金融业务视图、行业Skill、专家团、MCP应用、数据连接器、流程规则和组织治理能力，目的就是让Agent能真正进入这些复杂业务现场。

没有长期记忆，Agent在信贷尽调中可能忽略借款人两年前的违约记录；在财富配置建议中无法记住客户上季度的风险偏好变化。这些错误在金融环境中代价高昂，不仅降低效率，还可能引发合规风险。业务视图把Agent的无状态缺陷直接放大到无法忽视的地步，推动记忆系统从可选功能变成必备基础设施。

当前多数金融智能体仍停留在单次任务执行层面，难以形成“记住-关联-演进”的闭环。WorkBuddy金融版的发布，实质上是把这个工程问题摆到了台面上：要让Agent真正可用，必须先解决记忆的长期化问题。

短期记忆与长期记忆的分层架构对比

Agent记忆系统通常采用分层设计。短期记忆对应当前对话上下文，直接放入大模型的输入窗口。它实现简单，响应速度快，但受限于上下文长度，无法保存长期历史。

LLM本身无状态，每次调用都是全新开始。即使把上下文窗口做到128k甚至更长，也装不下用户三个月的完整对话历史。短期记忆适合处理当前会话内的即时信息，比如本次投研查询的最新财报数据或当前座席绩效指标。一旦对话结束或窗口溢出，这些信息就彻底丢失。

长期记忆则把历史交互、业务事实、用户偏好持久化存储在外部系统。常见做法是把文本片段向量化后存入向量数据库，需要时通过相似性检索拉回相关记忆，再注入当前上下文。这种架构突破了窗口限制，能让Agent“回忆”几个月甚至几年前的关键事件。

工程取舍明显。短期记忆延迟低、成本低，但容量小、易丢失；长期记忆容量大、可持久，但引入检索延迟和向量计算开销。在金融场景中，短期记忆用来处理实时行情查询，长期记忆则负责关联历史风险事件和客户全生命周期画像。两者必须配合使用，不能互相替代。

分层架构的另一个关键是更新机制。短期记忆随对话实时变化，长期记忆需要定期总结、去重、更新权重，避免向量库膨胀和检索噪声。Juejin的工程方案强调，LLM的无状态特性决定了长期记忆必须在模型外部实现，通过检索-注入的方式间接赋予Agent记忆能力。

实际项目中，团队通常把短期记忆控制在4k-8k token，长期记忆则根据业务量设定向量维度和召回阈值。金融业务对准确性要求高，错误召回的代价远高于普通对话，因此分层设计必须在容量、速度、准确率三者间反复权衡。

向量数据库选型决定金融级记忆检索性能

向量数据库是长期记忆落地的核心基础设施。在金融数据量级下，选型直接影响检索延迟、召回准确率和运维成本。

Milvus作为开源向量数据库，在自建场景中具备高吞吐优势。它支持亿级向量规模，适合金融机构已有私有化部署需求。金融历史数据往往包含大量结构化报表和非结构化公告，Milvus的混合检索能力能同时处理向量相似度和标量过滤，比如按时间范围或业务条线过滤记忆。

Pinecone则提供全托管服务，免去运维负担。其Pod架构在小规模金融团队中部署快，但在大规模历史记忆下成本会显著上升。金融场景每天产生的记忆条目可能达到数万条，Pinecone的按量计费模式需要仔细评估。

工程方案中，选型需考虑三个维度：数据规模、查询并发、合规要求。Milvus支持本地部署，数据不出域，符合金融强监管需求；Pinecone托管模式虽便利，但数据可能位于境外，需要额外评估跨境合规。

性能权衡重点在召回率与延迟。金融投研场景要求Top-5记忆的召回准确率高于85%，否则Agent可能引用错误的历史风险点。Milvus通过HNSW或IVF索引可将毫秒级查询控制在50ms以内，但需要合理设置向量维度（通常768或1024）和索引参数。Pinecone的服务器less模式在低频查询时表现好，但在高并发续保率分析场景下可能出现冷启动延迟。

实际测试显示，当记忆库超过500万条向量时，Milvus的集群扩展性优于Pinecone，但运维团队需要具备向量数据库调优经验。金融业务还常需结合时间衰减权重，最近三个月的记忆应赋予更高检索优先级，这要求数据库支持动态元数据过滤。

选型最终取决于机构IT战略。自建能力强的银行倾向Milvus，追求快速落地的券商可能先用Pinecone。无论哪种，都必须把向量数据库当作记忆系统的核心引擎，而非简单存储工具。

金融数据连接器与记忆系统的集成路径

WorkBuddy金融版强调全链路安全可信底座和数据连接器，这为记忆系统提供了明确的集成路径。

数据连接器负责把券商内部的投研数据库、保险核心系统、监管公告平台等异构数据源接入记忆层。它将结构化财报、半结构化公告、非结构化客户沟通记录统一转换为文本片段，再向量化后写入长期记忆库。

集成时，MCP应用（可能是Multi-Chain Prompt或类似多链路应用）作为桥梁，把业务流程规则映射到记忆更新事件。例如，当客户经理完成一次信贷尽调后，MCP触发记忆写入，把关键风险点、决策依据、时间戳一起存入向量数据库。同时，组织治理能力定义了不同角色对记忆的访问权限，客户经理只能看到自己经手的客户记忆，合规部门则拥有全局检索权。

安全可信底座确保整个过程可审计。所有记忆条目都带数字签名和访问日志，防止篡改。数据连接器还需实现增量同步，避免全量重跑导致的性能冲击。WorkBuddy金融版提到的丰富金融数据源，正是通过这些连接器源源不断为记忆系统供血。

集成路径通常分三步：首先定义记忆粒度，把一次完整业务视图拆成多个可检索单元；其次建立映射规则，把业务字段映射到向量元数据；最后接入治理层，实现基于角色的访问控制。整个过程必须与现有金融IT系统打通，不能形成新的数据孤岛。

在保险续保场景中，数据连接器每天拉取续保率、座席绩效、客户历史保单，形成时间序列记忆。Agent在下次分析时，通过检索这些记忆自动生成趋势报告，显著降低人工重复工作。

记忆检索与更新的代码级实现细节

长期记忆的核心代码通常包含三个部分：向量化、存储、检索更新。

以下是典型实现片段（基于Juejin工程方案的实战思路）:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# 记忆写入
async def store_memory(text: str, metadata: dict):
    embedding = embedding_model.encode(text)  # 768维向量
    memory_id = vector_db.insert(
        vectors=[embedding.tolist()],
        metadata=[{
            "timestamp": datetime.now().isoformat(),
            "user_id": metadata["user_id"],
            "scene": "credit_review",
            **metadata
        }]
    )
    return memory_id

# 记忆检索
async def retrieve_memory(query: str, top_k: int = 5, filters: dict = None):
    query_vec = embedding_model.encode(query)
    results = vector_db.search(
        query_vectors=[query_vec.tolist()],
        top_k=top_k,
        filter=filters  # 如 {"user_id": "xxx", "timestamp": ">2024-01-01"}
    )
    # 时间衰减加权
    for res in results:
        age_days = (datetime.now() - datetime.fromisoformat(res.metadata["timestamp"])).days
        res.score = res.score * math.exp(-age_days / 180)  # 半年半衰
    return sorted(results, key=lambda x: x.score, reverse=True)

更新机制更关键。不能简单追加，否则向量库会迅速膨胀。实战中采用总结式更新：每30天对同一客户的记忆做一次LLM总结，生成浓缩版本，删除旧条目，保留核心事实。这能将存储量压缩60%以上。

性能优化重点在批量处理和缓存。金融高峰期可能同时有数百个Agent并发检索，需引入Redis缓存最近10分钟的高频记忆，减少向量数据库压力。索引选择上，HNSW在召回率和速度间取得较好平衡，但构建时间较长，适合离线夜间重建。

代码中还需加入失败重试和幂等设计，确保金融数据不因网络抖动丢失。实际运行数据显示，优化后的检索延迟可稳定在80ms以内，满足投研实时性要求。

安全合规要求重塑记忆存储访问控制

金融行业对数据安全和合规的要求彻底改变了记忆系统的设计。WorkBuddy金融版强调的全链路安全可信底座和组织治理能力，成为记忆存储访问控制的核心约束。

所有记忆条目必须实现字段级加密，敏感客户信息在向量数据库中以密文形式存在，仅在检索后由可信执行环境解密。访问控制采用RBAC模型，结合业务视图定义权限：投研分析师只能检索自己负责企业的记忆，合规部门可跨部门审计但不能修改。

组织治理能力还要求记忆具备完整审计日志。每次检索、更新、删除操作都要记录操作人、时间、理由，并与监管要求对接。记忆系统不能独立存在，必须嵌入机构统一身份认证和权限管理系统。

数据连接器在接入时需进行脱敏处理，个人身份信息替换为脱敏ID。向量本身虽不直接包含明文，但相似性检索仍可能通过侧信道推断敏感信息，因此需增加噪声机制或采用隐私保护向量检索技术。

在保险场景中，续保率记忆涉及大量客户历史保单，存储时必须满足《个人信息保护法》和金融监管的数据留存期限要求。超过保留期的记忆需自动归档或删除，不能永久留存。

这些合规约束显著增加了工程复杂度，但也迫使记忆系统从一开始就按金融级标准设计。WorkBuddy金融版通过把这些能力内置到平台，降低了单个机构重复建设的成本，同时确保Agent在合规边界内发挥长期记忆的价值。

最终，安全合规不是记忆系统的限制，而是其在金融领域落地的前提。只有满足这些要求，长期记忆才能真正从技术概念变成可信赖的业务生产力。

参考来源

• WorkBuddy金融版正式发布，让Agent真正进入金融业务现场
• Agent 记忆系统设计实战：让 AI 拥有长期记忆的工程方案