反洗钱智能体实战：优化记忆比换大模型更有效

在金融领域，反洗钱（AML）一直是人力密集、规则繁杂的难题。当大模型热潮涌来，许多团队的第一反应是“换更大的模型”。但在近期一场技术分享中，AI开发倡导者Nacho Martinez给出了不同答案：智能体的表现瓶颈往往不在模型本身，而在记忆层与上下文工程的设计。 本文基于该分享及配套工作坊，拆解如何用智能体架构构建一个可自主运行的反洗钱分析系统。

为什么金融场景需要“智能体系统”而非聊天机器人

Nacho将AI应用分为四种形态：LLM聊天机器人、RAG应用、LLM驱动的工作流、AI智能体。真正在生产环境中创造价值的是后两者的结合——自动化与自主性的叠加。

他以中型银行为例：当一笔100万美元入账后，三天内通过ATM分批取现5万美元，这类可疑交易需要被自动标记，而不是让分析师逐条人工核查。聊天机器人无法胜任，因为它缺少持续运行、调用工具、维护记忆的能力。智能体系统则可以在后台7×24小时运转，把可疑活动报告（SAR）自动生成，交由人类复核。

这里的关键认知是：推理核心由前沿模型提供，开发者控制力有限；而记忆、工具使用、感知（脚手架） 才是可以深度定制的部分。Nacho强调，同一个前沿模型，仅改变脚手架配置，在特定任务上的表现就会显著变好或变差。

智能体架构的七块拼图：记忆层是主战场

一个完整的智能体框架包含模型、存储、检索组件、记忆层、羽翼层（implicit context）、智能体循环、上下文工程等七到八个组件。Nacho把重点放在数据层，因为这是他口中“我们真正能操作的部分”。

短期记忆的天花板：上下文越大，准确率越低

短期记忆即上下文窗口。多份研究表明，上下文窗口从零token扩展到256K token时，模型解决问题的准确率反而下降。即便厂商宣传100万token上限，继续填充只会让性能恶化。这解释了为什么把所有信息塞进上下文是错误策略。

应对方式有两种：上下文摘要（让模型总结后开启新对话）和压缩（把对话片段存入数据库并分配ID，需要时按ID回取）。两者都属于上下文工程的核心手段。

上下文窗口（Context Window） 指模型单次推理能处理的最大token数，包含输入提示与生成内容。它本质上是模型的“工作记忆”，容量固定且成本随长度线性增长。业界常误以为窗口越大越好，但研究显示，当无关信息填充窗口时，模型对关键信息的注意力会被稀释，导致“迷失在中间”（Lost in the Middle）现象——位于上下文中部的信息最易被忽略。因此，有效上下文管理不是追求最大窗口，而是确保高信噪比。摘要与压缩正是为了在有限窗口内保留最相关信号，而非简单扩容。

长期记忆的三分类：情景、程序、语意

Nacho将长期记忆划分为三类：情景记忆（历史对话、工具日志、交互摘要）、程序性记忆（技能与工作流序列）、语意记忆（用户偏好、身份设定）。这种分类不是为了学术优雅，而是为了让智能体循环在组装上下文时有明确的检索路径。

他给工程师的建议很直接：保持简单。先只做短期记忆加长期记忆两个结构，当短期记忆中的内容值得保留时，提升为长期记忆的原始文本，再对其做向量化，供智能体按需回想。

工具箱与技能箱：别让工具吃掉你的上下文

一个容易被忽视的陷阱是工具和技能占用的上下文空间。Nacho透露自己安装了100多个技能，每个技能约占3000到5000 token，全部塞入上下文会瞬间撑爆限制。他的方案是工具箱模式与技能箱模式：对工具和技能做向量嵌入，智能体循环根据任务做向量相似性搜索，只提取最相关的三个（K=3），必要时再加一个重排序器精选出一个，用完即卸载。

在调用对话补全API时，工具与技能往往占据整个请求80%的token量（约3.5万到10万token）。之所以成本没有翻五倍，是因为KV缓存对重复前缀做了复用。这也从经济角度说明：精简脚手架不只是性能问题，也是成本问题。

KV缓存（Key-Value Cache） 是Transformer推理中的一种优化机制：模型在生成每个token时，会缓存先前token的键值对，避免重复计算。当多次API请求共享相同的前缀（如固定的系统提示、工具定义）时，缓存可复用这部分计算，从而降低延迟与成本。但缓存仅对完全一致的前缀生效，一旦工具列表或技能描述变动，缓存即失效。这解释了为何精简且稳定的脚手架不仅能提升性能，还能通过提高缓存命中率来显著压缩token开销。

文件还是数据库：一场被重新发明的旧争论

分享中一个尖锐观点是：多个智能体同时写入同一个文件时，当前主流变通方案是加工作数（work queue），而这恰恰是数据库三十年前就解决了的ACID一致性问题。Nacho的立场是不必二选一——文件擅长存储大量非结构化数据，数据库擅长事务性写入，智能体架构应当按场景混用。

对于SQL生成，他建议通过模型上下文协议（MCP）使用预验证的查询模板，而不是让智能体每次动态编造SQL，后者是当前智能体处理数据库时的主要故障源。

ACID 是数据库事务的四个核心特性：原子性（Atomicity，事务要么全部完成要么全部回滚）、一致性（Consistency，事务前后数据满足约束）、隔离性（Isolation，并发事务互不干扰）、持久性（Durability，提交后数据永久保存）。多智能体同时写入同一文件时，缺乏这些保证，容易产生脏写、丢失更新等问题。传统数据库通过锁、日志和MVCC等机制原生解决并发一致性，因此智能体架构中涉及事务性写入的场景，复用数据库能力比在文件层自建队列更可靠。

实战工作坊：一个跑在Codespace上的反洗钱智能体

工作坊通过GitHub账号注册后自动获得Codespace权限，环境内包含部署在Oracle Cloud上的Llama 3模型、数据库连接和若干Jupyter笔记本。智能体循环设有最大8次迭代、每次60秒推理时间的限制，可配置。

学员将看到一个自主运行的反洗钱智能体：生成模拟交易、识别可疑模式、调用工具箱中的工具、在向量知识库中检索证据，最终自动产出可疑活动报告。界面提供智能体上下文窗口的可视化，帮助理解每一轮组装了哪些内容。

Nacho特别提到混合检索（RRF）的价值：语义搜索加关键词搜索的组合，在计算成本略增的前提下，检索质量随时间推移明显更好。这对于需要精准匹配交易特征的金融场景尤为关键。

RRF（Reciprocal Rank Fusion，倒数排名融合） 是一种无监督的混合检索融合算法。它不依赖不同检索器返回的原始分数（这些分数尺度不一、不可直接比较），而是根据每个文档在各检索结果中的排名计算融合分：score = Σ 1/(k + rank)，其中k为平滑常数（通常取60）。排名越靠前，贡献越大。RRF能有效结合语义搜索（向量相似度）与关键词搜索（如BM25）的优势，在金融场景中既能捕捉概念相似性，又能精准匹配交易代码、金额等字面特征，且无需训练即可部署。

对开发者的启示

这场分享的核心论点可以浓缩为一句话：不要执着于更换前沿模型，去优化你能控制的那90%——记忆结构、上下文组装、工具调度。 对于金融领域的构建者，这意味着从具体问题出发裁减框架，而不是照搬通用智能体方案。Nacho建议咨询顾问从零构建定制框架，剔除90%不需要的组件，因为“所有东西都是围绕对话补全API构建的”，越精简，效果越好。

持续学习的路径有三条：参数化记忆（微调权重）、表征记忆（嵌入模型）、非参数化记忆（本文讨论的架构层）。Nacho的工作坊聚焦第三条，因为它是冻结模型下最可控、迭代最快的方向。