当一个智能体变成八个:多智能体财务系统中的准确性与风险

一家中型 SaaS 公司的财务负责人描述了她恍然大悟的那一刻。他们搭建了一个智能体“团队”来生成月度董事会材料:一个从计费系统抓取收入，一个从总账拉取成本，一个计算毛利率，一个撰写解读文字，一个负责组装成幻灯片。演示效果非常好。然后财务总监核对数字，发现图表里的毛利率与文字叙述里的毛利率对不上。同一个指标，同一个月份，却有两个答案。单独看，没有哪个智能体是“错”的。它们只是各自基于略有不同的数据切片进行了计算，而没有人把这些切片核对一致。

这正是多智能体财务系统悄无声息的失败模式。演示效果很好，但数字对不上账。而且由于错误出现在智能体之间，而不是某一个智能体内部，任何单个智能体的日志都无法解释它。

为什么增加智能体带来的风险快于带来的能力

多智能体编排的吸引力显而易见:把一个复杂的工作流拆解成多个专精环节，部分并行运行，再在顶层放一个监督者进行路由和整合。近期针对财务文档处理的基准测试表明，如果做得好，这种方式能带来实实在在的收益，包括一些路由策略在保持准确性的同时把成本削减了约一半，原因是简单字段交给便宜的模型处理，难字段交给强模型处理。

但同一批研究对其弊端也直言不讳。生产环境中的多智能体大语言模型系统失败率高得令人不安，而这些失败中很大一部分并非源于单个智能体的推理错误，而是协作失败:智能体误解自己的角色、重复劳动、丢失历史记录，或者把上游智能体的猜测当成既定事实。加州大学伯克利分校的研究人员在 2025 年将其归纳为一套失败模式分类,“错误叠加”正处于其中的核心位置。

对 CFO 而言，这里有一个尤其值得担心的机制。当你把多个智能体串联起来时，错误不会相互抵消，而是原封不动地传递到下游。研究智能体产出一个略有偏差的数字，执行智能体把它当作既定事实，后续每一步都建立在这个错误的基础上。有一项分析发现，带有对抗性核验的闭环架构消除了超过 40% 本会叠加的错误。反过来理解这句话:如果没有这种核验，这些错误就会一路传导到你最终签字确认的输出结果中。

还有一种更微妙的情形。2025 年一篇关于自我条件化(self-conditioning)的论文观察到，当模型的上下文中包含它自己之前的错误时，它出错的概率会明显上升。一个曾经算错收入的智能体，现在正基于自己那个错误数字进行推理。错误不仅会持续存在，还会自我繁殖。

真正的问题不在智能体本身，而在它们读取的内容

大多数团队的应对方式是增加更多编排层:更多监督者、更多评审智能体、更多重试机制。这对某些类型的失败确实有帮助，但它误诊了财务场景特有的问题，那几乎从来不是智能体之间协作不良，而是每个智能体各自搭建了自己与源数据的连接、维护着自己的一套真相。

再次想象那个董事会材料团队。收入智能体调用计费 API,并套用自己的一套收入确认逻辑;毛利率智能体调用总账，轧差方式略有不同;文字解读智能体读取的是上周二的一份缓存导出。三个智能体，三条数据路径，同一组数字却有三种定义。再高明的监督者也无法解决这个问题，因为监督者协调的是那些从一开始就不是基于同一套底层数据计算出来的输出。你完全可以做到完美的编排，却依然产出一份对不上账的报告。

这就是“八个智能体”这个说法值得警惕的地方。八个智能体配八个连接器，意味着有八次机会对收入下不同的定义，有八个刷新时可能出现偏差的节点，有八条审计人员必须追踪的计算路径。这种复杂度不是线性增长的:每一个读写自己那一版数字的新智能体，都会在“可能悄悄产生分歧”的关系网中增加一条新的边。

一个已核对的模型，多个智能体

真正站得住脚的架构并不炫目:每个智能体都从同一个已核对的财务模型中读取数据，并将结果写回其中。这不是一个共享文件夹，也不是一个共享缓存，而是一个能与账本对平的模型，收入在其中只有一种含义，每个数字都能追溯到源头的血缘关系，而运算则通过一个确定性引擎完成，而不是由碰巧接到该子任务的大语言模型重新推导一遍。

当数字层是共享且已核对的，编排问题会大大简化。毛利率智能体和文字解读智能体不可能对毛利率产生分歧，因为它们都不计算毛利率，而是都从同一个模型中检索毛利率，而生成该数字的计算只需确定性地运行一次，基于已核对的输入。智能体重新回到它们真正擅长的事情:拆解请求、决定要抓取什么、安排工作顺序、撰写文字草稿;而它们不擅长的事情，也就是算术，则完全交由大语言模型之外的部分处理。我们在为什么财务智能体必须调用工具而不是自己计算一文中，把这种分离作为整个设计的核心。

这也解决了多智能体系统本会加剧的审计难题。在各自私有数据路径的情况下,“这个数字是谁算出来的、基于什么数据”没有一个干净的答案，因为该数字是跨越多个智能体和连接器拼凑出来的，没有单一的记录。而有了共享的已核对模型，无论是哪个智能体呈现出来的数字，都能追溯到源头。这种可追溯性正是审计人员或董事会真正需要的东西，也是记录决策而不仅仅是操作的审计轨迹贯穿的同一原则。

在扩展你的智能体群之前，这意味着什么

有几点需要坦诚承认。多智能体编排是真实且有用的。监督者与工作者的模式对受监管的工作流来说是较为安全的一种，因为路由、重试和审批都留在一个受控的层级内。并行处理确实能缩短实际完成时间，以上都不是问题所在。

问题在于顺序。在八个私有数据连接之上搭建八个智能体，并不能给你一个财务团队，而是给了你八种彼此独立、可能自信地犯错的方式，并把它们连在一起，让错误相互叠加。行之有效的顺序恰恰相反:先核对数字，建成一个与账本对平、以确定性方式计算的模型，然后再根据工作流需要，把尽可能多的智能体指向它。让编排值得信赖的是这个共享层，而不是反过来。

如果你的智能体目前各自维护自己的收入定义，那么风险并不在于智能体的数量，而在于真相的版本数量。把它们收敛为一个，编排就会从错误放大器变成准确性放大器。

看看 Rexfin 如何让每个智能体读取并基于同一个已核对的模型进行计算:预约演示,带上那份对不上账的报告来聊聊。