★ FEATURED ARTICLE 做金融领域的AI落地时间久了你会发现一种很拧巴的状态闭源千亿大模型的推理能力确实强但没人敢真把核心决策链路交给它开源小模型够轻、够省、够透明却总被质疑“本事不够”。Mint-Agent这个项目给出的答案很有意思——用9B/27B量级的开源模型在不牺牲可控性的前提下硬刚千亿级前沿系统而且胜率还不低。这篇文章我就聊聊Mint-Agent里“可审计金融智能”的设计逻辑、为什么小模型在这里反而能赢以及怎么把同一套思路搬到你自己的智能体落地里顺便结合最近很火的扣子金融智能体案例做一个可复现的实战拆解。1. Mint-Agent到底在解决什么问题1.1 金融场景用大模型卡在“不敢信”上先别急着聊模型选型金融行业用AI最大的问题从来不是“效果不够惊艳”而是“错了怎么办”。投研助理写错一段摘要最多是面试被拒但一个金融智能体现在敢碰的是财报比对、监管字段提取、信贷初审、资金流水分析这些东西一旦数值错一位那就是实打实的合规风险和经济损失。我见过太多团队兴冲冲引入千亿级对话模型做金融任务最后都卡死在两个地方。第一是幻觉问题模型看起来很自信地告诉你“某上市公司Q3毛利率为43.2%”你去翻原始财报发现那是同行业另一家公司的数据。第二是流程不可审计追问它“这个数字是怎么算出来的”模型只会给你一段看似合理但无法验证的中间推理。这种感觉就像面试了一个资历光鲜的分析师真把投资权限交给他却完全不知道他的决策依据是什么。Mint-Agent这个名字里的“Mint”非常直白就是可信铸造的意思。项目的核心不是造一个什么都会的超级金融助手而是造一个每一步决策都能翻旧账、能复核、能断言的金融任务执行体。它把“可审计”当作第一类需求来设计模型只是其中一个被约束的推理内核。1.2 9B/27B叫板千亿系统的底气在哪里如果只看参数数量9B模型挑战千亿系统听起来像以卵击石。但金融智能体的核心能力其实分为两条线一条是“知识储备”另一条是“任务执行”。千亿级模型的知识储备确实碾压小模型可金融场景里我们真正需要的恰恰不是知识储备而是任务执行——查数、计算、比较、校验、生成结构化结论。任务执行讲究的是“使用工具的能力”和“按流程走完的能力”而不是“背诵知识的能力”。9B/27B模型的优势在于指令遵从更稳定、函数调用更干净、推理链路更短不会像千亿模型那样动不动就给你一顿自由发挥。再加上现代的Agent架构允许模型去检索数据库、调用计算器、访问知识库小模型的“知识短板”根本不需要靠参数去补靠的是外部工具和检索管线。这就是Mint-Agent能超车的底层逻辑把复杂任务拆成标准操作流程让每个环节都由小模型执行高确定性动作再用审计机制兜底。好比一家投行里合伙人级别的千亿模型负责宏观判断但真正把穿行测试、底稿复核干得又快又准的是几个执行力超强的分析员。Mint-Agent就是把这些分析员的作业流程工程化了。2. 可审计金融智能的四层架构设计2.1 数据接入层先把土壤搞干净所有金融智能体的第一步都不是模型而是数据。Mint-Agent在数据接入层做了一个很关键的事情——强制结构化。不管上游来的是财报PDF、银行流水CSV还是交易所公告文本进入Agent之前必须经过统一的字段抽取和标准化映射形成一张带schema的“金融操作数据表”。这一步的价值在于给后面的模型提供了一个不会说谎的“事实底座”。模型只在这些结构化字段上做推理而不是在原始文本上自由联想。实操时我建议这块必须做到三个约定数值字段必须保留原始单位和原始精度比如“1.2亿元”不能偷偷变成“12000万元”再变成“120000千元”否则后续所有审计会跟着错每条数据记录必须携带来源标识和采集时间戳表结构必须经过业务方确认严禁模型自行扩展字段。数据接入层做的虽然是最脏最累的活却是后面模型能稳定输出的一切前提。没有这层所谓可审计就是空中楼阁。2.2 规划编排层把任务拆到原子级Mint-Agent拿到的任务不会直接丢给模型去“想一想”而是先经过一个规划模块把任务拆成语义原子。举个例子“根据2023年报和2024半年报分析应收账款周转率的同比变化趋势”这句话规划模块会拆成六个原子任务定位两份报告、抽取应收账款科目期初期末值、抽取营业收入科目值、按公式计算周转率、对齐两个期间的统计口径、输出同比变化结论。这层设计背后的核心原则是能拆成确定性步骤的绝不依赖模型自由发挥。模型只在每个原子任务里扮演执行者的角色步骤和步骤之间的衔接由编排层控制所有参数和中间结果都是显式传递的。扣子金融智能体案例里那个效果不错的报表解读Agent也是走了同样的路子。它把“用户提问到生成回复”这个过程从一次大模型生成拆成了“识别意图、抽取指标、检索数据库、执行计算、编写结论”五个插件节点每个节点输出都结构化成JSON。这样即使单个环节出错定位和修复成本也非常低。如果你用扣子或者其他低代码平台搭金融Agent第一步就该学会改掉“写一大段提示词让模型一次生成结果”的习惯改成节点化编排。2.3 审计追踪层让每一步都有据可查Mint-Agent最值得借鉴的是审计追踪层。它不会等到最终输出才检查而是从任务开始就把每一步的执行记录写成一个“推理账本”。包括模型收到什么输入、调用了哪个工具、检索了哪条知识、给出了什么中间结论、计算过程的公式和操作数是什么全部落盘保存。更关键的是账号链路的日志是双写双重的。模型原始输出存一份经过规范化之后的执行结果存一份。复核时可以直接把原始输出和最终结果做对照避免模型在中间过程偷偷改了口径。比如模型先说“该比率上升了”后面看到计算数值又改成“实际上是下降的”人类复核员能非常轻易地发现问题所在。在实现上建议每一个原子任务都生成一个task_id然后把这个id串成一条调用链整条链固定写入审计库中。最后为用户输出结论时顺带附上这条链路的信息摘要。这不只是为了合规更是一种极强的信任信号。你想想当你的Agent拉出一条完整的“从原始数据到最终结论”路径客户拿到的就不只是一个答案而是答案的全套证明过程。2.4 验证器层数字问题交给规则去把关金融任务和通用对话最大的区别在于正确性是可以用规则验证的。Mint-Agent里专门设计了一个验证器层每一种金融计算任务都挂载一套独立的规则校验器。比如计算同比增速验证器会后台重新读取两个基期的数值独立执行一遍计算公式把结果和模型给出的增速做对照误差超过设定阈值就直接打回重算。这里有个容易忽略的细节验证器里的公式必须和模型生成公式的代码路径分开。模型负责写SQL表达式验证器是一个独立的解释器它不消耗任何模型参数就是一个普通程序在跑。这种“模型生成、规则校验”的组合在实际运行中能把数值类错误压到极低水平。我见过好多团队把验证逻辑也写在提示词里让模型“自己检查自己”效果约等于让醉汉给自己测酒精含量必须坚决避免。规则校验器永远要独立于模型存在每一个验证器都要有对应的单元测试用例通过测试后才允许挂载到Agent上。3. 实操落库用扣子搭一个可审计金融Agent的完整流程3.1 准备知识库和结构化数据源现在很多金融团队会用扣子这类低代码Agent平台做验证比较快。我们以Mint-Agent的思路在扣子上做一个简化版的“可审计报表分析Agent”麻雀虽小五脏俱全。第一步是准备数据源强烈建议不要直接把PDF丢给模型让它读而是先用一个独立的抽数插件把PDF转成结构化的科目数据表。操作上可以先用正则加规则抽数做一个轻量抽取脚本把财报里的关键科目货币资金、应收账款、存货、营业总收入、净利润等全部抽出来映射成一张标准表。每列包含科目名、数值、单位、期间、来源文件名这几个属性。数据入库后再把这部分数据挂到扣子的知识库或者数据库插件上后面Agent的所有检索都以这个结构表为准。这一步是很多案例翻车的高危区。我看到过太多人直接把年报PDF传上去期待模型自己“读懂”结果模型面对几十页报表不是漏科目就是看错行。记住投喂给金融Agent的数据必须已经结构化结构化程度越高后面出错概率越低。3.2 节点编排把“计算”和“解释”拆开接下来是Agent编排。在扣子工作流里你应该拆出五个核心节点指标识别节点、数据检索节点、计算执行节点、校验复核节点、结果生成节点。指标识别节点负责把用户问题中的财务指标映射到标准科目组合上。比如用户问“应收账款周转率”这个节点需要输出两张子表一张是营业收入科目取值口径一张是应收账款期初期末平均值口径。这个节点本身由模型完成但输出结果一定是受控的枚举值而不是自由文本。数据检索节点则从知识库表里取出具体数字输出固定格式比如“科目应收账款-期末期间2024-06-30值182.3亿元单位人民币”。计算执行节点直接写一个表达式计算器模型提供公式计算器执行算式。校验复核节点会重复造轮子再次重算并把两次结果做一致性比对。最后结果生成节点才由模型用口语化语言把计算结论包装成给用户看的回复。你会发现真正让这个Agent可审计的关键不是某个节点多聪明而是数据从“检索”到“计算”到“生成”全部是显式传递的结构化对象。每一个节点收到的参数、抛出的结果都有固定schema审计时只要把schema里的值顺序打出来整条推理链一目了然。3.3 用提示词控制模型不要越权尽管编排层已经把任务拆得很细模型的提示词仍然需要设计一道护栏。一个很简单但非常有效的写法是在提示词开头用一段“固定行为声明”告诉模型它只是一个节点执行器没有资格自行改变口径。下面给出我实测效果好的一段提示词模板你可以直接抄走稍微改一下就能用你正在参与一个财务分析流水线你的身份是“节点执行器”。 你只负责根据输入数据完成本节点任务不得修改上游参数不得自行引用外部数据不得替用户做任何未要求的口径假设。 输入字段{输入数据} 任务定义{节点任务} 输出要求 1. 输出严格符合给定 JSON Schema。 2. 数值结果保留两位小数必须附带计算过程。 3. 如果输入数据不足以完成任务请输出包含 error_code 的 JSON不要编造结果。这段提示词的核心是“禁止增加信息”。金融任务里模型跑偏的根源往往不是理解能力不够而是它自以为懂得太多喜欢补上下文。当你的Agent定位是流水线节点时切断自由发挥是最重要的。3.4 审计日志落盘与人工复核界面扣子这类低代码平台本身有日志系统但默认日志主要记录对话消息远远达不到审计要求。我的做法是在工作流里加一个“审计记录节点”每当运行一个业务流程就把所有中间数据包汇总成一个JSON快照写入独立的日志表字段包括流程实例ID、用户ID、任务类型、每个节点的入参出参、计算表达式、校验结果、最终输出摘要。这个快照要做到什么程度算合格一个原则是如果这是一个非法交易调查调查人员光凭这份审计日志不需要看任何模型原始对话就能完整还原Agent的整个决策过程。达到这个标准你的审计体系才算合格。事后复核界面也很重要不要指望业务人员去翻原始日志。我建议做一个简单的审计面板按流程实例展示每一个节点的数据流转。你知道最常见的复核场景是什么吗业务方会说“这个增速大得离谱我要看它是怎么算的。”这时你只需要把计算节点的完整过程展示出来把“期初值、期末值、平均值、公式、结果”一行行亮出来信任危机立刻解除。4. 小模型用出千亿效果的技术细节和踩坑记录4.1 上下文窗口与工具调用抖动用9B/27B模型做Agent踩得最多的坑就是工具调用不稳定。同一个函数定义今天输出规范的JSON参数明天可能多出一个没定义过的键名后天可能在参数里直接写了一句话。Mint-Agent的解决办法是约束模型不要自己“构造”工具调用语义而是提供一个工具选择器组件让模型只输出一个工具名称的枚举值参数全部由上游节点填好传进来。这个改动实战效果非常显著。它把小模型的负担从“既要决定用哪个工具又要组织参数”降到了“只要选一个预定义工具”结构化输出成功率大幅提升。另外一个实用做法是把上下文窗口尽量缩短。金融业务数据虽然量大但单次任务的必要字段往往只有几个用检索先把窄表取出来不要整库塞进上下文。小模型在长上下文下的注意力衰减比大模型明显得多喂太多无关内容它不仅算不对还容易漏掉关键条件。4.2 数值计算的精度守恒金融场景里数字的“鞋子不能变小”。小模型在做多步计算时很容易丢失单位或者隐式做了四舍五入。直接让模型输出“毛利率为42%”其实损失了对齐精度。Mint-Agent的验证器会把模型输出的每个中间计算数值和上游源的原始数值重新比对一遍验证时使用统一内部精度——中间计算保留六位小数仅最后展示时才四舍五入到两位。实操时我强烈建议所有金融Agent的数值统一采用Decimal而不是Float进行中间运算。Java里用BigDecimalPython里用decimal模块。Float在二进制浮点运算中会有精度损失平时开发无所谓但在金融计算里0.10.2都算不利索。这块如果基础打不牢后面任何审计都会被质疑。另外还有一个很容易被忽略的点单位一致性。财务报表里经常同时出现“元”“万元”“亿元”跨期比较时单位不同模型直接相减必然大错。必须在数据接入层就把单位统一全部换算成“元”再入库换算过程也写入字段映射记录避免源头埋雷。4.3 RAG检索的金融域改造通用场景的RAG检索讲究的是语义相关性但在金融场景语义相近不等于数值可用。Mint-Agent的做法是双通道检索一路走向量相似度召回可能相关的段落另一路走字段映射关系精确匹配到结构化科目。最终只把两路结果一致命中的数据送入推理上下文凡是向量命中但字段映射对不上的数据一律丢弃。这个机制解决的是一个很典型的金融问题比如用户问“去年营收”向量检索可能召回三份年报里的同一个“营业收入”科目但年份各不相同。单纯按相似度排序模型不知道应该取哪一个。加了字段映射作为硬过滤之后检索结果就锁定到指定年度、指定期间的那一条记录。对金融Agent来说宁可少召回一些数据也不要召回一批不确定数据让模型自己选。我在测试金融Agent时常用一组“数字拷问”来验活随便抽三个跨期的指标问它同比增长率然后人工复核每个原始数。第一次跑基本能暴露出数据错位、口径混用、计算错误这三类问题。用双通道检索修正后准确率提升非常明显。4.4 模型蒸馏之外的终局优化Mint-Agent能在9B/27B级别的模型上达到千亿系统的水平其实还做了很多你看不见的细节。比如它对金融术语做了专门的词表约束模型在生成财务结论时只能使用白名单内的动词和评价词。比如结论只能写“上升”“下降”“持平”“无法判断”不能随意写“显著改善”“略有波动”这类模糊表达。这看起来限制了模型的语言丰富度却让结论变得极其可比较、可追踪。还有一点是对模型输出长度的限制。金融任务不需要长篇大论Mint-Agent规定每个节点输出上限是256个token强制模型把价值压缩在最精炼的表达上。这个设定很反直觉但实际跑下来限制token反而提升了事实准确性——模型没有空间“编故事”了。5. 金融Agent实战中常见的几个要命问题5.1 看似正确实则张冠李戴金融AI最容易翻车的方式不是算错而是算对了科目却记错了对象。比如用户要分析的是公司A的报表结果模型检索出来的是公司B的数据但只要数值本身是“真实的”常规校验器很可能直接放行。遇到这种情况我建议在每个结构化数据记录上强制附加“实体标识字段”校验节点在生成结论前必须把实体标识与用户提问中的公司名称做一次硬匹配不匹配就直接终止流程。这正好呼应了Mint-Agent的一个核心理念不要先相信模型的语义理解反而去相信数据自带的硬标签。数据说什么比模型觉得是什么更重要。5.2 审计日志被“清洗”得只剩最终答案很多团队做审计日志抓了一大堆日志却全部是模型最终生成的话术。这种日志没有任何审计价值。审计的核心不是记录“模型说了什么”而是记录“模型依据什么说的”。所以日志里必须包含检索命中的数据源ID、计算公式、上游参数甚至包含被验证器否决的候选结果。被否决的候选结果其实是宝藏它证明了系统并不是一条道走到黑而是有自检纠错能力的。把这类信息也写入审计库对可信度是一种额外加分。5.3 面对模糊问题时的激进回答金融用户的问题经常是模糊的比如“最近表现怎么样”。如果Agent直接开答九成要翻车。正确做法是先反问收紧条件明确指标口径和时间窗口然后再执行。Mint-Agent在规划层有一个“问题澄清节点”一旦识别到问题中的指标、期间、实体三者任一缺失就先输出澄清需求而不是尝试猜测。这只是工程上的一个小习惯但在金融行业宁可多问一句也坚决不能猜这是底线。6. 这套架构在真实环境里的表现和我的体会我自己在几台家用级GPU和云服务器上复现过Mint-Agent的简化版用的是9B的量化模型加一套结算校验器。在“财报科目抽取、比率计算、趋势判断”这类任务上效果确实出乎我意料地稳。最直观的感受是这种任务根本不需要那个“什么都懂”的大模型它更像是一个只要遵循规则就会做得很好的员工而Agent工程要做的正是把这些规则焊死在架构里。其中一个比较深的体会是让金融智能体走向生产环境比拼的不是谁的底座模型更聪明而是谁的错误回滚机制更健全、谁的流程透明度更高、谁能在最短时间里向非技术人员解释清楚一个结论是怎么来的。Mint-Agent选择把大精力放在可审计框架上而不是一味堆模型规模这个取舍我觉得是非常明智的。最后说一个落地细节方面的建议先在纯离线环境里搭整套流水线用历史财报数据把所有校验器跑通确认日志完整、结论可复现再考虑对接实时行情和生产数据。和金融打交道稳永远比快重要。这套“小模型加审计机制”的组合可能是当前阶段平衡成本、效率和信任问题的一个相当务实的解。
阅读完成 · 觉得有帮助？
