做金融方向的 Agent 架构设计是一件特别容易想当然的事。我所在团队从去年开始陆续落地了好几个金融智能体项目从投顾问答、财报结构化提取到客服工单自动化踩过的坑比写过的代码还多。最开始我们也以为把通用 Agent 框架拿过来改一改就行真正进入开发第三周就发现完全不是那么回事——金融场景对 Agent 的约束几乎每一个环节都比通用场景苛刻一个量级。这篇博文不打算泛泛讲概念而是把我沉淀下来的一套金融智能体 Agent 架构参考方案完整拆开重点讲清楚为什么金融 Agent 不能照搬通用架构核心模块怎么设计以及落地过程中那些文档里不会写但你一定会遇到的问题。整套方案的核心思路可以概括为一句话金融 Agent 架构的第一优先级不是聪明而是可控。模型可以换、流程可以调但权限、审计、风控、可解释性这条底线动不得。下面我按架构设计的关键维度逐个展开。1. 泛化 Agent 架构放在金融场景为何容易翻车1.1 三个金融行业的残酷现实先讲三个我做项目时真实碰到的场景你感受一下差别。第一个是零容错。普通办公场景里问答助手答错了用户刷新重来就行最多吐槽一句。但金融场景里一个包含错误计算结果的回答可能直接影响用户资金决策。我们做过一个测算工具模型某次把复利公式里的指数算错了一位结果收益率差了将近 30 倍。这种错误在通用场景顶多是个 bug在金融场景就是事故。第二个是强合规。金融行业的每一个用户交互、每一次数据读取、每一个业务操作原则上都必须留痕要能回答谁在什么时间通过什么链路做了什么事。合规审计不是系统上线后补的而是要在架构设计阶段就把审计能力埋进去。第三个是数据极度敏感。客户的账户信息、交易记录、持仓明细、征信数据任何一环泄露都是严重事件。这里有个很实际的约束很多金融机构的数据根本不允许出私有化环境这意味着你不能随便把数据丢给某个云端大模型 API 去处理选型和部署方式在架构早期就要定死。1.2 通用 Agent 和金融 Agent 的本质差异我整理了一个对比表能比较直观地看出两者的差别对比维度通用 Agent金融 Agent核心目标完成任务、追求效率安全、合规、可追溯优先工具调用直接调用、结果至上鉴权、幂等、审计、风控四重检查记忆方式简单的会话向量检索分层记忆 权限隔离 动态脱敏错误容忍度可重试、可接受不可接受必须有兜底可解释性不强求每个关键决策必须有依据链并发模型尽力而为限流、熔断、降级是标配你会发现能做和能上线之间隔着一整套工程机制。金融 Agent 的核心挑战不在于让模型更聪明而在于把聪明关进笼子里——既要让 Agent 有足够的自主性去完成任务又要在每个可能出问题的节点设置刹车。2. 参考架构总览金融 Agent 六层模型经过几个项目的迭代我习惯把金融 Agent 架构拆成六个层次每一层职责单一通过标准接口串联关键位置全部埋点。2.1 交互接入层不止是聊天窗口这一层是所有用户请求的入口覆盖 APP、小程序、Web 端、企业微信等渠道。通道本身不复杂复杂的是会话管理和身份绑定。金融场景里一个会话必须能追溯到一个明确的用户主体。同样是帮我看看我的理财持仓没有身份信息的请求和经过实名认证的请求能拿到的数据完全是两回事。所以交互接入层要统一做三件事渠道接入转换、会话 token 生成、用户身份映射。身份映射做完之后后续所有层才能拿到一把统一的用户钥匙。建议的做法是接一个统一的 API 网关所有渠道的请求都转成内部标准的会话上下文对象再传给下一层。这样不管新增渠道还是变更渠道上层架构都不受影响。2.2 编排决策层Agent 的核心大脑这一层是整个架构最关键的编排中心。它收到用户意图之后决定走哪条处理链路是简单的规则匹配直接回答还是调用大模型做复杂推理或者需要多步工具访问才能完成。金融场景我推荐以 Plan-and-Execute 模式为主体ReAct 模式作为补充。Plan-and-Execute 的好处是Agent 先把任务拆成一个可审计的计划步骤列表然后逐步执行。每一步都可以记录为什么做、调了什么工具、拿到什么结果万一出问题回溯的时候一眼就能定位。这里面要非常克制地使用全自主循环。模型自己决定一路调用十几个工具的场景在金融生产环境里风险极高不仅因为不可控还因为每一步都可能产生真实的数据访问或业务影响。我们的做法是默认执行计划需要经过规则引擎校验凡是涉及资金操作、客户敏感信息变更的步骤直接插入人工审批节点。2.3 工具执行层金融系统的连接器工具层把内部系统包装成 Agent 可以调用的标准化工具包括账户查询、行情获取、理财产品信息检索、订单状态查询、知识库检索等等。这一层要解决的三大问题是权限控制、幂等控制和稳定性控制我后面专门有一节细讲这里先列出核心设计原则所有工具必须注册到统一工具中心有唯一的工具编号、出入参 Schema 和调用鉴权策略禁止 Agent 直接拼接内部 API 地址。2.4 记忆管理层短期上下文与长期知识金融 Agent 的记忆不能是单一向量库。我设计的记忆分三层会话级短期记忆、用户级长期记忆、知识库记忆。会话记忆回答这次对话聊了什么用户记忆回答这个客户是什么情况、以前办理过什么业务知识库记忆回答某个业务规则是什么。三层记忆的存储和检索策略各不相同而且金融场景对记忆隔离有硬性要求——A 客户的历史对话和画像绝对不能被 B 客户的会话检索到。这个隔离要在检索之前就通过用户身份索引卡死不能靠模型自己自觉。2.5 安全合规层写在骨子里的红线安全合规不是某个独立模块而是贯穿所有层的横切能力。我习惯把它拆成四道拦截机制请求入口的内容过滤、任务规划的规则校验、工具调用的权限鉴权、返回结果的合规审查。每一道拦截都独立部署、独立告警任何一道不过请求就进不了下一环。这一层还承担审计日志的采集工作。不要在生产环境里通过日志打印靠自觉来搞审计一定要在框架层强制埋点凡是关键节点的入参、出参、耗时、操作人、结果状态全部结构化落库。2.6 评测监控层金融 Agent 的体检中心Agent 系统最大的特点是不确定性。同样的输入今天可能答对明天答错换了模型版本整体效果可能提升但某个场景突然退化。所以必须建立两层评测机制。离线层维护一个覆盖典型场景的指标体系包括准确性、拒绝率、工具调用成功率、Token 成本等每次模型或提示词变更都跑一遍回归。在线层线上实时监控响应时延、错误率、兜底触发率和敏感操作次数超出阈值立刻告警。我见过不少团队跳过评测层直接上线最后的效果就是系统像一个黑盒只知道能用完全不知道好到什么程度、坏在哪个维度、改完提示词之后是变好了还是变差了。评测层是金融 Agent 持续迭代的地基省不掉。3. 关键组件选型模型、框架与工具封装的取舍架构定完之后最耗决策精力的是技术选型。我选了三个坑最深的部分重点讲。3.1 大模型选型的三个维度金融 Agent 的模型选型我建议从三个维度打分数据安全边界、推理能力、金融领域适配度。数据安全边界是硬约束。上面提到金融数据敏感很多机构要求模型必须私有化部署数据不能出内网。这就把选型范围基本限定在开源模型或者可私有化部署的商业模型。如果实在要用云端 API 能力就必须在接入层做好完整脱敏确保任何敏感字段都不进入模型请求。推理能力维度上金融场景经常涉及长文档理解、数值计算、条件判断逻辑连贯性比知识广度更重要。实际测试下来7B 级别模型做简单意图分类还能顶住但做财务指标抽取和多轮投顾问答就明显吃力72B 级别效果显著提升但部署成本也跟着上来了。建议从业务复杂度反推模型规模不要盲目追大。金融领域适配度也值得重视。同一个问题通用模型和经过金融语料微调的模型回答质量差距是肉眼可见的。我个人建议优先选在金融中文语料上有过针对性训练的基座其次通过 RAG 补充金融知识。3.2 Agent 框架自研编排器还是二次开发开源框架这是团队内经常争论的问题。开源生态里 LangChain、LangGraph、CrewAI、AutoGen 这些框架各有优势直接拿来用确实能快速跑通 demo但金融场景有三个绕不开的定制需求第一人工审批流必须无缝嵌入到 Agent 执行链路里比如生成计划 → 暂停等待审批 → 审批通过后继续执行这个状态机在通用框架里要么不支持要么实现得很别扭。第二审计埋点必须是强制执行而非约定执行通用框架默认让你自己加 callback但团队一大prompt 里写满了记得调用日志这种补丁式方案是不可维护的。第三权限模型必须能精确到某个 Agent 实例能否调用某个具体工具通用框架通常只有全局启停。所以我们的结论是不排斥用开源框架但只把它当作状态机基础和模型调用封装编排策略、审批机制、审计埋点、权限控制都要自研。说白了框架决定下限自研的上层策略决定能否过金融合规这道关。3.3 金融工具接入的标准化封装套路工具接入是最不起眼但最容易出问题的环节。金融系统的接口五花八门有的是 HTTP 服务有的是内部 RPC有的要走消息队列异步返回。如果不做统一封装Agent 的编排逻辑会越写越乱。我的标准化套路是每个工具暴露统一的 Schema包含工具 ID、描述、参数声明、返回声明、错误码规范。下面是一个简要的 JSON 示例后续接工具都按这个模板走{ tool_id: account.query_balance, name: 查询账户余额, description: 根据客户账号查询当前可用余额, auth_required: true, parameters: { account_no: {type: string, required: true, rule: regex:^\\d{12}$}, currency: {type: string, enum: [CNY, USD, HKD]} }, response: { account_no: string, usable_balance: number, frozen_balance: number }, error_codes: [ACCOUNT_NOT_FOUND, PERMISSION_DENIED, SYSTEM_BUSY] }封装时有几个细节容易被忽略参数校验让 Agent 自由生成参数是灾难。比如查询余额里的账号必须校验格式金额类参数必须校验范围日期参数必须校验格式不通过就直接返回校验错误。幂等控制涉及交易、状态变更类的工具必须有幂等键。方案是每次请求生成唯一 request_id服务端基于这个 ID 做去重防止模型重试时重复下单。超时与熔断金融接口偶发抖动很正常。工具层必须给每个下游调用设置超时时间并支持按错误率自动熔断。没有熔断机制的话一次下游抖动就能拖死整个 Agent 入口。4. 记忆系统改造从通用向量库到金融专用记忆4.1 短期记忆多轮对话中的上下文管理会话级短期记忆我直接用 Redis 存结构化上下文而不是把全部历史消息堆进 Token。每轮对话结束把关键信息抽取出来形成本轮用户意图 关键实体 系统执行动作 结果摘要只保留最近 N 轮的压缩摘要。金融场景里这个压缩动作有讲究不能只按时间截断还要按业务场景截断。比如用户前一分钟查了余额现在问那我的定期呢这里定期依赖上一轮提到的账户概念。如果摘要压缩把上一轮搞丢了模型就答非所问。另外还有反过来的情况用户在投诉流程里聊了五分钟后突然问理财推荐这时候就应该把投诉上下文的情绪信息降权专注于理财意图。4.2 长期记忆客户 KYC 画像与结构化存储长期记忆中客户画像数据我强烈建议用结构化存储加向量库混合方案。纯向量库适合语义检索但金融画像有大量的枚举和数值字段比如风险等级、投资偏好、身份认证状态、历史产品持仓情况。这些字段用 SQL 存、用结构化查询比向量检索靠谱得多。举个例子用户问我适合买高风险产品吗Agent 要先从画像库里查出这个客户的风险测评等级再从产品库里查目标产品的风险等级然后做规则匹配判断——这个过程全是精确查询不是语义相似度能解决的。长期记忆的更新时机也要特别设计。客户画像不是靠一次对话就定死的每次会话结束后由专门的记忆更新器判断哪些信息值得沉淀比如用户在对话中明确提到我退休了想把投资风格改稳健一点这类信息要经过确认规则生成待确认的记忆项而不是直接覆盖原画像。4.3 记忆隔离与动态脱敏金融不可妥协的底线多租户隔离在记忆层是硬性要求。所有记忆条目必须带上 user_id 作为第一索引键检索时强制拼接用户归属条件从数据访问层面保证隔离。数据脱敏我采用的是读取即脱敏策略Agent 拿到的永远是脱敏视图而不是原始敏感数据。比如手机号中间四位打码、身份证号只保留前后几位、账户号部分隐藏。如果某个业务链路确实需要完整信息必须走专门的权限通道且该访问行为强制记录审计日志。5. 安全合规设计金融 Agent 的履约保证5.1 四道拦截链路的编排顺序安全机制越靠前拦截成本越低。我设计的四道拦截按顺序执行第一道输入内容过滤。关键词匹配加语义分类识别 prompt injection、恶意指令、涉赌涉诈等违禁内容。第二道任务规划校验。Agent 生成的执行计划先过规则引擎看是否有违规动作比如查询他人账户绕过权限获取敏感字段这样明确的违规步骤会直接终止计划。第三道工具调用鉴权。每步实际调用工具前都会校验当前用户是否有权限执行该操作并把完整的入参快照记录到审计系统。第四道输出合规审查。对最终生成回答做敏感信息扫描和合规审查比如是否泄露他人隐私、是否包含违规承诺收益的表述。四道全过才能输出给用户。前两道拦截基本能在毫秒级完成后两道会消耗一点时间但换来的是系统性风险的大幅下降这笔账很划算。5.2 全链路审计日志出问题能查到根因审计日志设计的关键是端到端可追踪。我给每个会话生成一个全局 trace_id贯穿从接入层到编排层到工具层再到输出层。所有日志都带这个 trace_id 和当前节点标识排查问题的时候沿着 trace_id 就能把一次完整请求的链路拼出来。审计日志至少包含五类记录用户请求原文、模型推理中间结果含规划步骤、工具调用入参与出参、权限校验结果、最终输出内容。中间结果尤其重要因为 Agent 出问题很多时候不是模型最终答错而是中间某个规划步骤走偏了。日志的存储要防篡改。金融场景下审计记录不能只放普通数据库建议落一份到对象存储加日志平台关键交易类操作单独走防篡改链路避免被覆盖或删除。5.3 幻觉兜底策略宁可不说不可乱说金融场景对模型幻觉的容忍度极低。我的兜底策略分三层第一层引用溯源。凡是基于知识库的回答必须返回引用来源用户点击可以看到出处。没有找到足够可信依据的问题模型必须明确说这个问题我需要查阅资料后确认不能编造。第二层置信度阈值。通过模型自评估和规则校验双重判断回答的置信度低置信度一律转人工或走预设话术。第三层敏感替代。凡是涉及收益承诺、市场预测、违规操作指导的话题不依赖模型自由发挥直接命中预设的合规话术模板不讨论、不解释、不引导。这套兜底策略在实际运行中拦截了大量潜在风险回答。刚开始我们担心过度干预会影响体验后来看数据发现用户对无法提供该建议的接受度远比想象的高但用户对AI 给了我一个错误承诺的容忍度几乎是零。6. 高并发与多 Agent 协作的扩容思路6.1 有状态编排器的瓶颈在哪Agent 系统的高并发设计和传统 Web 服务不一样。传统服务无状态、横向扩容简单但 Agent 编排器天然有状态一次任务要跨多次模型调用、多步工具访问状态必须存在某个地方。最省事的做法是状态留在进程内存里每个实例处理一组会话。但这样没法水平扩容实例一多会话路由就成问题。我建议的状态方案是会话状态外置到 Redis编排器实例本身保持无状态任何实例都能继续任意会话。任务执行所需的临时数据、当前执行的计划进度、已经完成步骤的结果全部存 Redis并且设置合理的过期时间。6.2 异步化改造与任务队列长耗时任务必须从请求链路里剥离。金融 Agent 很多任务不是秒级能完成的比如一份几十页的企业财报解析模型调用可能要好几分钟。同步阻塞会让用户长时间等待也浪费后端线程资源。我采用的模式是同步接口只负责受理请求 返回任务 ID后台通过任务队列异步执行。任务状态推进到哪一步、是否完成、结果如何用户通过轮询或回调查询。这个改造对底层 Agent 编排逻辑影响不大但对并发能力和用户体感的提升是立竿见影的。对于高价值或高耗时的工具调用还可以把预校验和实际执行拆开。预校验快速判断能不能做实际执行提交异步任务完成后通过回调把结果带给编排器。两步分离之后系统的峰值吞吐能力会宽松很多。6.3 多 Agent 分工协作的并发模型一个大型金融平台往往要同时支持多个 Agent 场景投顾问答、智能客服、财务分析、合规审查。我的建议是按照业务域拆分成多个独立 Agent 服务而不是做一个万能 Agent 什么都接。拆分的好处有三个每个 Agent 的提示词和知识库可以独立优化互不干扰错误和故障的影响面被控制在一个业务域内不会全站崩溃并发控制和扩容策略也可以按场景差异化配置——高并发的客服 Agent 多放实例低频高算力的研报分析 Agent 少放实例。多 Agent 之间的协作我尽量用事件驱动而不是互相直接调用。某个 Agent 需要另一个 Agent 的结果时通过消息队列传递任务和结果避免形成复杂的同步调用网。7. 从 0 到 1 落地金融 Agent 的实战路径7.1 第一个场景怎么选如果你所在团队准备开始做金融 Agent第一个场景的选择几乎决定项目生死。我强烈建议从文档问答 / 知识检索增强类场景切入不要一上来就做交易执行或自动决策。理由很简单文档问答类任务出错的影响可控、数据准备相对充足、评测标准清晰答得对不对能直接看出来。比较合适的方向包括内部产品手册问答、监管政策解读、财报内容提炼、研报摘要等。这类场景先把架构骨架跑通、把工程化能力建好后边再做高阶场景就有底气了。7.2 MVP 闭环怎么跑通第一个版本不要贪大跑通一个最小闭环就够了。数据准备上挑选一个垂直领域的知识库清洗出高质量文本做好分块和向量化。不建议一上来就接十几个数据源知识库质量参差会让问题定位变得极其困难。评测集建设从第一周就要开始至少整理一百条真实业务黄金问答对覆盖正常问题、模糊问题、敏感问题、越权问题这是后续迭代的标尺。技术上先实现用户提问 → 检索 → 拼装提示词 → 模型回答 → 合规审查的直线链路先不加复杂的多步 Agent 规划。直线链路跑通后再逐步增加工具调用、记忆管理和人工审批节点。每一步增加都跑一遍评测集保证没有明显倒退。7.3 上线后最值得投入的三类优化第一类评测集持续扩充。每一条线上暴露的错误都应该沉淀成一条评测样本别人说这个答错了的时候先问能不能进评测集再谈改法。第二类检索质量优化。金融知识库场景里答案不准很多时候不是模型不行而是没检索到正确的资料。投入精力调分块策略、embedding 模型、重排序环节性价比往往高于换更大参数的模型。第三类成本和延迟优化。模型推理的 Token 消耗是持续成本延迟是本系统能不能被业务接受的关键。缓存相似问题、合并长下文、用轻量模型处理简单分类、把复杂任务拆到异步链路这些手段组合起来能节省可观的资源和费用。根据我个人这段时间的体会金融 Agent 架构真正难的不是某个算法的精度而是能不能把安全、审计、权限、可观测这些非功能性需求完整地焊进系统骨架上。如果你是从零开始做先别急着上最强模型把工具执行层的幂等控制、风控拦截链路和审计日志这三块骨架搭扎实后边每一步都会轻松很多。另外所有 Agent 相关的变更包括提示词调整、模型切换、工具新增都走一遍离线评测再上线这个习惯能帮你避开绝大多数线上事故。 
长河君 · 2026/10/29 7:21:08 · 阅读 1.2k 金融智能体架构设计：从可控性到安全合规的六层模型
做金融方向的 Agent 架构设计是一件特别容易想当然的事。我所在团队从去年开始陆续落地了好几个金融智能体项目从投顾问答、财报结构化提取到客服工单自动化踩过的坑比写过的代码还多。最开始我们也以为把通用 Agent 框架拿过来改一改就行真正进入开发第三周就发现完全不是那么回事——金融场景对 Agent 的约束几乎每一个环节都比通用场景苛刻一个量级。这篇博文不打算泛泛讲概念而是把我沉淀下来的一套金融智能体 Agent 架构参考方案完整拆开重点讲清楚为什么金融 Agent 不能照搬通用架构核心模块怎么设计以及落地过程中那些文档里不会写但你一定会遇到的问题。整套方案的核心思路可以概括为一句话金融 Agent 架构的第一优先级不是聪明而是可控。模型可以换、流程可以调但权限、审计、风控、可解释性这条底线动不得。下面我按架构设计的关键维度逐个展开。1. 泛化 Agent 架构放在金融场景为何容易翻车1.1 三个金融行业的残酷现实先讲三个我做项目时真实碰到的场景你感受一下差别。第一个是零容错。普通办公场景里问答助手答错了用户刷新重来就行最多吐槽一句。但金融场景里一个包含错误计算结果的回答可能直接影响用户资金决策。我们做过一个测算工具模型某次把复利公式里的指数算错了一位结果收益率差了将近 30 倍。这种错误在通用场景顶多是个 bug在金融场景就是事故。第二个是强合规。金融行业的每一个用户交互、每一次数据读取、每一个业务操作原则上都必须留痕要能回答谁在什么时间通过什么链路做了什么事。合规审计不是系统上线后补的而是要在架构设计阶段就把审计能力埋进去。第三个是数据极度敏感。客户的账户信息、交易记录、持仓明细、征信数据任何一环泄露都是严重事件。这里有个很实际的约束很多金融机构的数据根本不允许出私有化环境这意味着你不能随便把数据丢给某个云端大模型 API 去处理选型和部署方式在架构早期就要定死。1.2 通用 Agent 和金融 Agent 的本质差异我整理了一个对比表能比较直观地看出两者的差别对比维度通用 Agent金融 Agent核心目标完成任务、追求效率安全、合规、可追溯优先工具调用直接调用、结果至上鉴权、幂等、审计、风控四重检查记忆方式简单的会话向量检索分层记忆 权限隔离 动态脱敏错误容忍度可重试、可接受不可接受必须有兜底可解释性不强求每个关键决策必须有依据链并发模型尽力而为限流、熔断、降级是标配你会发现能做和能上线之间隔着一整套工程机制。金融 Agent 的核心挑战不在于让模型更聪明而在于把聪明关进笼子里——既要让 Agent 有足够的自主性去完成任务又要在每个可能出问题的节点设置刹车。2. 参考架构总览金融 Agent 六层模型经过几个项目的迭代我习惯把金融 Agent 架构拆成六个层次每一层职责单一通过标准接口串联关键位置全部埋点。2.1 交互接入层不止是聊天窗口这一层是所有用户请求的入口覆盖 APP、小程序、Web 端、企业微信等渠道。通道本身不复杂复杂的是会话管理和身份绑定。金融场景里一个会话必须能追溯到一个明确的用户主体。同样是帮我看看我的理财持仓没有身份信息的请求和经过实名认证的请求能拿到的数据完全是两回事。所以交互接入层要统一做三件事渠道接入转换、会话 token 生成、用户身份映射。身份映射做完之后后续所有层才能拿到一把统一的用户钥匙。建议的做法是接一个统一的 API 网关所有渠道的请求都转成内部标准的会话上下文对象再传给下一层。这样不管新增渠道还是变更渠道上层架构都不受影响。2.2 编排决策层Agent 的核心大脑这一层是整个架构最关键的编排中心。它收到用户意图之后决定走哪条处理链路是简单的规则匹配直接回答还是调用大模型做复杂推理或者需要多步工具访问才能完成。金融场景我推荐以 Plan-and-Execute 模式为主体ReAct 模式作为补充。Plan-and-Execute 的好处是Agent 先把任务拆成一个可审计的计划步骤列表然后逐步执行。每一步都可以记录为什么做、调了什么工具、拿到什么结果万一出问题回溯的时候一眼就能定位。这里面要非常克制地使用全自主循环。模型自己决定一路调用十几个工具的场景在金融生产环境里风险极高不仅因为不可控还因为每一步都可能产生真实的数据访问或业务影响。我们的做法是默认执行计划需要经过规则引擎校验凡是涉及资金操作、客户敏感信息变更的步骤直接插入人工审批节点。2.3 工具执行层金融系统的连接器工具层把内部系统包装成 Agent 可以调用的标准化工具包括账户查询、行情获取、理财产品信息检索、订单状态查询、知识库检索等等。这一层要解决的三大问题是权限控制、幂等控制和稳定性控制我后面专门有一节细讲这里先列出核心设计原则所有工具必须注册到统一工具中心有唯一的工具编号、出入参 Schema 和调用鉴权策略禁止 Agent 直接拼接内部 API 地址。2.4 记忆管理层短期上下文与长期知识金融 Agent 的记忆不能是单一向量库。我设计的记忆分三层会话级短期记忆、用户级长期记忆、知识库记忆。会话记忆回答这次对话聊了什么用户记忆回答这个客户是什么情况、以前办理过什么业务知识库记忆回答某个业务规则是什么。三层记忆的存储和检索策略各不相同而且金融场景对记忆隔离有硬性要求——A 客户的历史对话和画像绝对不能被 B 客户的会话检索到。这个隔离要在检索之前就通过用户身份索引卡死不能靠模型自己自觉。2.5 安全合规层写在骨子里的红线安全合规不是某个独立模块而是贯穿所有层的横切能力。我习惯把它拆成四道拦截机制请求入口的内容过滤、任务规划的规则校验、工具调用的权限鉴权、返回结果的合规审查。每一道拦截都独立部署、独立告警任何一道不过请求就进不了下一环。这一层还承担审计日志的采集工作。不要在生产环境里通过日志打印靠自觉来搞审计一定要在框架层强制埋点凡是关键节点的入参、出参、耗时、操作人、结果状态全部结构化落库。2.6 评测监控层金融 Agent 的体检中心Agent 系统最大的特点是不确定性。同样的输入今天可能答对明天答错换了模型版本整体效果可能提升但某个场景突然退化。所以必须建立两层评测机制。离线层维护一个覆盖典型场景的指标体系包括准确性、拒绝率、工具调用成功率、Token 成本等每次模型或提示词变更都跑一遍回归。在线层线上实时监控响应时延、错误率、兜底触发率和敏感操作次数超出阈值立刻告警。我见过不少团队跳过评测层直接上线最后的效果就是系统像一个黑盒只知道能用完全不知道好到什么程度、坏在哪个维度、改完提示词之后是变好了还是变差了。评测层是金融 Agent 持续迭代的地基省不掉。3. 关键组件选型模型、框架与工具封装的取舍架构定完之后最耗决策精力的是技术选型。我选了三个坑最深的部分重点讲。3.1 大模型选型的三个维度金融 Agent 的模型选型我建议从三个维度打分数据安全边界、推理能力、金融领域适配度。数据安全边界是硬约束。上面提到金融数据敏感很多机构要求模型必须私有化部署数据不能出内网。这就把选型范围基本限定在开源模型或者可私有化部署的商业模型。如果实在要用云端 API 能力就必须在接入层做好完整脱敏确保任何敏感字段都不进入模型请求。推理能力维度上金融场景经常涉及长文档理解、数值计算、条件判断逻辑连贯性比知识广度更重要。实际测试下来7B 级别模型做简单意图分类还能顶住但做财务指标抽取和多轮投顾问答就明显吃力72B 级别效果显著提升但部署成本也跟着上来了。建议从业务复杂度反推模型规模不要盲目追大。金融领域适配度也值得重视。同一个问题通用模型和经过金融语料微调的模型回答质量差距是肉眼可见的。我个人建议优先选在金融中文语料上有过针对性训练的基座其次通过 RAG 补充金融知识。3.2 Agent 框架自研编排器还是二次开发开源框架这是团队内经常争论的问题。开源生态里 LangChain、LangGraph、CrewAI、AutoGen 这些框架各有优势直接拿来用确实能快速跑通 demo但金融场景有三个绕不开的定制需求第一人工审批流必须无缝嵌入到 Agent 执行链路里比如生成计划 → 暂停等待审批 → 审批通过后继续执行这个状态机在通用框架里要么不支持要么实现得很别扭。第二审计埋点必须是强制执行而非约定执行通用框架默认让你自己加 callback但团队一大prompt 里写满了记得调用日志这种补丁式方案是不可维护的。第三权限模型必须能精确到某个 Agent 实例能否调用某个具体工具通用框架通常只有全局启停。所以我们的结论是不排斥用开源框架但只把它当作状态机基础和模型调用封装编排策略、审批机制、审计埋点、权限控制都要自研。说白了框架决定下限自研的上层策略决定能否过金融合规这道关。3.3 金融工具接入的标准化封装套路工具接入是最不起眼但最容易出问题的环节。金融系统的接口五花八门有的是 HTTP 服务有的是内部 RPC有的要走消息队列异步返回。如果不做统一封装Agent 的编排逻辑会越写越乱。我的标准化套路是每个工具暴露统一的 Schema包含工具 ID、描述、参数声明、返回声明、错误码规范。下面是一个简要的 JSON 示例后续接工具都按这个模板走{ tool_id: account.query_balance, name: 查询账户余额, description: 根据客户账号查询当前可用余额, auth_required: true, parameters: { account_no: {type: string, required: true, rule: regex:^\\d{12}$}, currency: {type: string, enum: [CNY, USD, HKD]} }, response: { account_no: string, usable_balance: number, frozen_balance: number }, error_codes: [ACCOUNT_NOT_FOUND, PERMISSION_DENIED, SYSTEM_BUSY] }封装时有几个细节容易被忽略参数校验让 Agent 自由生成参数是灾难。比如查询余额里的账号必须校验格式金额类参数必须校验范围日期参数必须校验格式不通过就直接返回校验错误。幂等控制涉及交易、状态变更类的工具必须有幂等键。方案是每次请求生成唯一 request_id服务端基于这个 ID 做去重防止模型重试时重复下单。超时与熔断金融接口偶发抖动很正常。工具层必须给每个下游调用设置超时时间并支持按错误率自动熔断。没有熔断机制的话一次下游抖动就能拖死整个 Agent 入口。4. 记忆系统改造从通用向量库到金融专用记忆4.1 短期记忆多轮对话中的上下文管理会话级短期记忆我直接用 Redis 存结构化上下文而不是把全部历史消息堆进 Token。每轮对话结束把关键信息抽取出来形成本轮用户意图 关键实体 系统执行动作 结果摘要只保留最近 N 轮的压缩摘要。金融场景里这个压缩动作有讲究不能只按时间截断还要按业务场景截断。比如用户前一分钟查了余额现在问那我的定期呢这里定期依赖上一轮提到的账户概念。如果摘要压缩把上一轮搞丢了模型就答非所问。另外还有反过来的情况用户在投诉流程里聊了五分钟后突然问理财推荐这时候就应该把投诉上下文的情绪信息降权专注于理财意图。4.2 长期记忆客户 KYC 画像与结构化存储长期记忆中客户画像数据我强烈建议用结构化存储加向量库混合方案。纯向量库适合语义检索但金融画像有大量的枚举和数值字段比如风险等级、投资偏好、身份认证状态、历史产品持仓情况。这些字段用 SQL 存、用结构化查询比向量检索靠谱得多。举个例子用户问我适合买高风险产品吗Agent 要先从画像库里查出这个客户的风险测评等级再从产品库里查目标产品的风险等级然后做规则匹配判断——这个过程全是精确查询不是语义相似度能解决的。长期记忆的更新时机也要特别设计。客户画像不是靠一次对话就定死的每次会话结束后由专门的记忆更新器判断哪些信息值得沉淀比如用户在对话中明确提到我退休了想把投资风格改稳健一点这类信息要经过确认规则生成待确认的记忆项而不是直接覆盖原画像。4.3 记忆隔离与动态脱敏金融不可妥协的底线多租户隔离在记忆层是硬性要求。所有记忆条目必须带上 user_id 作为第一索引键检索时强制拼接用户归属条件从数据访问层面保证隔离。数据脱敏我采用的是读取即脱敏策略Agent 拿到的永远是脱敏视图而不是原始敏感数据。比如手机号中间四位打码、身份证号只保留前后几位、账户号部分隐藏。如果某个业务链路确实需要完整信息必须走专门的权限通道且该访问行为强制记录审计日志。5. 安全合规设计金融 Agent 的履约保证5.1 四道拦截链路的编排顺序安全机制越靠前拦截成本越低。我设计的四道拦截按顺序执行第一道输入内容过滤。关键词匹配加语义分类识别 prompt injection、恶意指令、涉赌涉诈等违禁内容。第二道任务规划校验。Agent 生成的执行计划先过规则引擎看是否有违规动作比如查询他人账户绕过权限获取敏感字段这样明确的违规步骤会直接终止计划。第三道工具调用鉴权。每步实际调用工具前都会校验当前用户是否有权限执行该操作并把完整的入参快照记录到审计系统。第四道输出合规审查。对最终生成回答做敏感信息扫描和合规审查比如是否泄露他人隐私、是否包含违规承诺收益的表述。四道全过才能输出给用户。前两道拦截基本能在毫秒级完成后两道会消耗一点时间但换来的是系统性风险的大幅下降这笔账很划算。5.2 全链路审计日志出问题能查到根因审计日志设计的关键是端到端可追踪。我给每个会话生成一个全局 trace_id贯穿从接入层到编排层到工具层再到输出层。所有日志都带这个 trace_id 和当前节点标识排查问题的时候沿着 trace_id 就能把一次完整请求的链路拼出来。审计日志至少包含五类记录用户请求原文、模型推理中间结果含规划步骤、工具调用入参与出参、权限校验结果、最终输出内容。中间结果尤其重要因为 Agent 出问题很多时候不是模型最终答错而是中间某个规划步骤走偏了。日志的存储要防篡改。金融场景下审计记录不能只放普通数据库建议落一份到对象存储加日志平台关键交易类操作单独走防篡改链路避免被覆盖或删除。5.3 幻觉兜底策略宁可不说不可乱说金融场景对模型幻觉的容忍度极低。我的兜底策略分三层第一层引用溯源。凡是基于知识库的回答必须返回引用来源用户点击可以看到出处。没有找到足够可信依据的问题模型必须明确说这个问题我需要查阅资料后确认不能编造。第二层置信度阈值。通过模型自评估和规则校验双重判断回答的置信度低置信度一律转人工或走预设话术。第三层敏感替代。凡是涉及收益承诺、市场预测、违规操作指导的话题不依赖模型自由发挥直接命中预设的合规话术模板不讨论、不解释、不引导。这套兜底策略在实际运行中拦截了大量潜在风险回答。刚开始我们担心过度干预会影响体验后来看数据发现用户对无法提供该建议的接受度远比想象的高但用户对AI 给了我一个错误承诺的容忍度几乎是零。6. 高并发与多 Agent 协作的扩容思路6.1 有状态编排器的瓶颈在哪Agent 系统的高并发设计和传统 Web 服务不一样。传统服务无状态、横向扩容简单但 Agent 编排器天然有状态一次任务要跨多次模型调用、多步工具访问状态必须存在某个地方。最省事的做法是状态留在进程内存里每个实例处理一组会话。但这样没法水平扩容实例一多会话路由就成问题。我建议的状态方案是会话状态外置到 Redis编排器实例本身保持无状态任何实例都能继续任意会话。任务执行所需的临时数据、当前执行的计划进度、已经完成步骤的结果全部存 Redis并且设置合理的过期时间。6.2 异步化改造与任务队列长耗时任务必须从请求链路里剥离。金融 Agent 很多任务不是秒级能完成的比如一份几十页的企业财报解析模型调用可能要好几分钟。同步阻塞会让用户长时间等待也浪费后端线程资源。我采用的模式是同步接口只负责受理请求 返回任务 ID后台通过任务队列异步执行。任务状态推进到哪一步、是否完成、结果如何用户通过轮询或回调查询。这个改造对底层 Agent 编排逻辑影响不大但对并发能力和用户体感的提升是立竿见影的。对于高价值或高耗时的工具调用还可以把预校验和实际执行拆开。预校验快速判断能不能做实际执行提交异步任务完成后通过回调把结果带给编排器。两步分离之后系统的峰值吞吐能力会宽松很多。6.3 多 Agent 分工协作的并发模型一个大型金融平台往往要同时支持多个 Agent 场景投顾问答、智能客服、财务分析、合规审查。我的建议是按照业务域拆分成多个独立 Agent 服务而不是做一个万能 Agent 什么都接。拆分的好处有三个每个 Agent 的提示词和知识库可以独立优化互不干扰错误和故障的影响面被控制在一个业务域内不会全站崩溃并发控制和扩容策略也可以按场景差异化配置——高并发的客服 Agent 多放实例低频高算力的研报分析 Agent 少放实例。多 Agent 之间的协作我尽量用事件驱动而不是互相直接调用。某个 Agent 需要另一个 Agent 的结果时通过消息队列传递任务和结果避免形成复杂的同步调用网。7. 从 0 到 1 落地金融 Agent 的实战路径7.1 第一个场景怎么选如果你所在团队准备开始做金融 Agent第一个场景的选择几乎决定项目生死。我强烈建议从文档问答 / 知识检索增强类场景切入不要一上来就做交易执行或自动决策。理由很简单文档问答类任务出错的影响可控、数据准备相对充足、评测标准清晰答得对不对能直接看出来。比较合适的方向包括内部产品手册问答、监管政策解读、财报内容提炼、研报摘要等。这类场景先把架构骨架跑通、把工程化能力建好后边再做高阶场景就有底气了。7.2 MVP 闭环怎么跑通第一个版本不要贪大跑通一个最小闭环就够了。数据准备上挑选一个垂直领域的知识库清洗出高质量文本做好分块和向量化。不建议一上来就接十几个数据源知识库质量参差会让问题定位变得极其困难。评测集建设从第一周就要开始至少整理一百条真实业务黄金问答对覆盖正常问题、模糊问题、敏感问题、越权问题这是后续迭代的标尺。技术上先实现用户提问 → 检索 → 拼装提示词 → 模型回答 → 合规审查的直线链路先不加复杂的多步 Agent 规划。直线链路跑通后再逐步增加工具调用、记忆管理和人工审批节点。每一步增加都跑一遍评测集保证没有明显倒退。7.3 上线后最值得投入的三类优化第一类评测集持续扩充。每一条线上暴露的错误都应该沉淀成一条评测样本别人说这个答错了的时候先问能不能进评测集再谈改法。第二类检索质量优化。金融知识库场景里答案不准很多时候不是模型不行而是没检索到正确的资料。投入精力调分块策略、embedding 模型、重排序环节性价比往往高于换更大参数的模型。第三类成本和延迟优化。模型推理的 Token 消耗是持续成本延迟是本系统能不能被业务接受的关键。缓存相似问题、合并长下文、用轻量模型处理简单分类、把复杂任务拆到异步链路这些手段组合起来能节省可观的资源和费用。根据我个人这段时间的体会金融 Agent 架构真正难的不是某个算法的精度而是能不能把安全、审计、权限、可观测这些非功能性需求完整地焊进系统骨架上。如果你是从零开始做先别急着上最强模型把工具执行层的幂等控制、风控拦截链路和审计日志这三块骨架搭扎实后边每一步都会轻松很多。另外所有 Agent 相关的变更包括提示词调整、模型切换、工具新增都走一遍离线评测再上线这个习惯能帮你避开绝大多数线上事故。