金融智能体的确定性边界

步骤 1把「确定性」常被用来指代的四件事分开。

当财务主管说流程必须是确定性的，这个要求通常捆绑了好几种性质，它们的责任方不同，成本也不同：

• 输出字节相同。同一请求返回完全一致的响应。没有任何主流托管 API 保证这一点（见 STEP 6），而且它也是四者中用处最小的。模型可以确定性地出错：如果它每次都返回同一个错误的合计，你得到的是一致性，不是正确性。
• 回放时运行相同。重新执行一个历史期间能精确复现当时发生的一切，因为模型的回复已被记录下来，回放时直接喂回去，而不是重新生成。这才是审计师所说的确定性，而它是一个今天就能解决的存储问题。
• 计算精确。每一个金额、合计、费率、分摊和舍入都由代码以十进制或整数运算完成。模型从不产出一个被当作数字使用的数字。
• 事实相同，决策相同。某件事是否被批准、过账、付款或升级，由规则、政策或一位具名的人来决定，因此相同的事实总是导向相同的结果。模型可以提供事实，并标记为提议，但它不做决定。

财务流程需要的是后三种，并且需要证明它们确实成立。把第一种当作目标，会让团队去折腾随机种子和温度设置，收效甚微。把另外三种当作目标，就把「我们能信任模型吗？」变成了「模型的哪些输出受到检查，由什么来检查？」——而这个问题有工程上的答案。

步骤 2按每一步的输出起什么作用来定位它，而不是按它有多聪明。

把流程拆成步骤，对每一步只问一个问题：如果这个输出是错的，在它产生作用之前由什么来检查？答案把步骤分为六类，规则也随之而来：

• 读取：从发票、对账单、合同或邮件中抽取字段。模型可以做，前提是其输出要与某个独立的东西挂钩：单据上的控制合计、对它所读原文精确片段的引用、另一个系统中的对应记录。模型读发票没问题，只要发票各行之和被核对等于其合计。
• 匹配与分类：配对记录、选择总账科目、给异常打标签。模型可以提议。由代码施加使提议有效的约束（金额相等、未清项、允许的科目），任何含糊的情况交给人。
• 计算：合计、利息、费用、汇兑、分摊、税费。只能用代码。不是「用代码，除非模型很有把握」。在 对账实验 中，有一次运行两个期末余额都错了，却仍然报告差额为 0.00。
• 决策：批准、过账、付款、拒绝、报送。由规则和人负责。制单-复核、限额和职责分离都在这里。模型可以充当提议的制单人，但永远不能充当复核人。
• 解释：评述、差异说明、客户摘要。由模型撰写，由代码核实文中每一个数字都是系统算出来的。
• 研究与起草：备忘录、初步分析、政策查询。这些天然是概率性的，保持原样也无妨，因为在结果变成别的任何东西之前，都有人先读过。

所以，边界并不是围着模型画的，而是围着每一个能动钱或改记录的输出画的：一边是在生效前受到检查的输出，另一边是本身就是作用的输出。检验你的边界实际在哪里，有个实用的办法：任取一个模型输出，追踪它在被代码或人看到之前，能经过哪些工具和记录、走多远。如果答案是「进入账簿」，那边界就画错了地方。

步骤 3在选定架构之前，先把累积误差算清楚。

每一步的准确率会沿着流水线相乘。如果每一步正确的概率是 p，且连续有 n 个未经检查的步骤，那么整次运行都正确的概率就是 pⁿ：

per-step accuracy    5 steps    10 steps    20 steps
99.5%                97.5%      95.1%       90.5%
99%                  95.1%      90.4%       81.8%
98%                  90.4%      81.7%       66.8%
95%                  77.4%      59.9%       35.8%

由此可得两点。第一，一个在单个循环里完成读取、匹配、计算和过账的端到端智能体是一条长链，即便每一步都很出色，整体也会被拖累。Vals AI 的 Finance Agent 基准（2.1 版，2026 年 10 月 19 日更新）给出了量级：其最佳智能体在分析师级任务上得分 67.85%，财务建模仅为 57%。第二，补救办法不是换更好的模型，而是缩短链条。步骤之间的一道确定性检查会让乘法重新归零起算，因为在第 2 步被拦下的错误不会带入第 3 步。代码篇中的对账只有一个概率性步骤（为 12 行提出配对），而每一个提议在任何东西依赖它之前都先经过代码检查。

除了错误率，量也很重要。每月 400 行、1% 的错误率，意味着单个账户每月就有四行出错。再乘以账户数和主体数，任何未经检查的步骤本身就会变成一个调节项。

步骤 4了解财务数据特有的错误，以及每一种对应的检查。

幻觉与事实锚定 解释了模型为什么会编造。在财务领域，编造呈现出可预测的形态，而每一种都有一项几乎零成本的检查：

• 声称的勾稽。对账之所以「平了」，是因为模型说它平了。在代码篇中，每一次返回了数字的朴素运行都报告差额为 0.00，错误的那些也不例外。检查：重新计算合计并与源对账单勾稽，绝不把差额当作输入接受。
• 构造出来的勾稽。把每一笔未匹配行都作为调节项挂在它自己那一侧，无论这些行是什么，总能平。检查：每个调节项都必须有一个由规则指定的类别，未分类的项目会阻止签核。
• 循环推导。一个合计是从另一个合计倒推出来的，于是两者按定义就一致。实验中有一次运行就是从银行合计倒推出账面余额的。检查：每一侧都从它自己的明细行独立计算。
• 编造的标识符。一个并不存在的分类账 ID（有一次运行就返回了一个）、一个发票号、一条引用。最广为人知的两起专业服务机构撤回事件，背后也是捏造的引用，见 这篇行业分析。检查：每个 ID 都对照记录系统解析，每条引用都对照其原文片段核实。
• 数字对了，框架错了。一个来自错误期间、主体、子公司或股份类别的数字；重述数与原报告数混用；季度数与年初至今数混用。检查：数字要与其期间、主体和口径一起作为类型化字段传递，绝不作为裸值传递。
• 数量级与符号。千读成百万，括号读成正数，借方读成贷方。检查：声明单位，在解析器中规范化带括号的负数，并按科目类型做符号检查。
• 币种。金额挂错了币种，或按模型提供的汇率折算。检查：币种是金额类型的一部分，汇率来自注明日期和来源的汇率表。
• 看似可信的精度。模型编造的舍入（一个精确到分、却没有任何东西算出过的余额）。检查：生成文本中的每一个数字都必须与一个计算出的数字相符。

步骤 5不要让第二个模型来裁决一个数字。

对一个可能出错的模型，诱人的修法是再用一个模型去检查它。对于财务数字，证据表明检查者有它自己的失效模式。在 FinVerBench（2026 年 5 月）中，语言模型被要求核验 43 家 S&P 500 公司的 XBRL 财务报表，其中被注入了错误。在引导式检查清单下，14 次模型运行中有 9 次把 95% 到 100% 的干净报表标记为有误。一个什么都拒绝的核验器，在复核时间上的代价和没有核验器一样大。

生成器–验证器差距 中的排序在这里格外适用。精确的判定器（重新计算、解析 ID、与源数据勾稽）排第一；可靠的检查器（策略引擎、对编码规则求解的 SMT 求解器）排第二；人排第三。模型评审在财务中有它的位置，但用于语气、完整性以及评述是否回答了问题，而不是用于判断 289,941.09 对不对。自洽性——采样多个答案并加以比较——值得用作触发器：如果样本之间不一致，就把该项目交给人。一致则什么也证明不了，因为多个样本完全可能在同一个错误合计上达成一致。

步骤 6从你自己的记录中获得可复现性，因为厂商并不出售它。

机制见 可复现性与非确定性：推理服务器会把你的请求与别人的请求合并成批，而内核的算术会随批大小改变，因此相同的贪心解码请求也会产生分歧。对财务设计而言，重要的是截至 2026 年 10 月 22 日各项参数的状态：

• Anthropic：根据其迁移指南，如果你设置 temperature、top_p 或 top_k，Claude Sonnet 5.5 会返回 400 错误，而且 API 没有种子参数。你甚至无法请求贪心解码。
• OpenAI：Chat Completions 上的 seed 被标注为 beta 且「尽力而为」。确定性「不受保证」，并提示你关注 system_fingerprint 以发现后端变更。Responses API 的参数中没有种子。
• Google：Gemini 的 seed 同样是「尽力而为」。
• 自托管：按位一致的输出可以做到，但有代价。vLLM 的 VLLM_BATCH_INVARIANT=1 处于 beta 阶段。SGLang 的 --enable-deterministic-inference 在其作者的测试中平均慢了 34%（24% 到 55%）。Thinking Machines 的参考内核在同一负载上耗时 42 秒，对照为 26 秒。你还必须固定权重、硬件、驱动和库版本，其中任何一项变动都会破坏按位一致性。

所以，在所有厂商上都行得通的设计是记录与回放。把每一条模型回复以模型版本和精确提示词为键存储起来，在重新执行某个期间时喂回去。持久化执行引擎（Temporal、DBOS、Restate）天然就对每一步这样做，这正是 持久化执行 应当进入财务智能体技术栈的原因。只有当你必须重新生成而不是回放时——例如要证明一个固定版本的模型在拿到去年的输入后，今天会产出相同的提议——自托管的确定性推理服务才值得它的成本。

步骤 7不要在确定性毫无收益的地方强求它。

过度套用边界也有代价。研究综述、信贷备忘录初稿、异常队列分诊、为员工解答政策问题，都是概率性任务，其输出在被据以行动之前都有人读过。把它们强行塞进规则引擎，只会造出一碰到陌生单据就失灵的脆弱系统。STEP 2 的检验仍然适用：如果输出在产生作用之前由人或代码检查过，这一步就可以是概率性的。把工程投入花在没有任何东西检查输出的那些步骤上。

还有基线的问题。你要替代的人工流程有它自己的错误率，它的四眼复核也会漏掉东西。这篇行业分析 讨论了「模型只需胜过这条基线」的论点，以及它为什么并不完整。简而言之：正是边界让你能诚实地比较错误率，因为它让模型的错误变得可见。

步骤 8审视任何财务智能体设计时要问的问题。

• 列出模型产出的每一个输出。对每一个而言，由什么来检查它？这项检查是否在输出产生作用之前执行？
• 是否存在模型产出、随后被当作数字使用的数字？如果有，为什么它不是由代码算出的？
• 未经检查的概率性步骤最长的链条有多长？按你实测的单步准确率，它的累积准确率是多少？
• 智能体能否对任何事项同时担任制单人和复核人，包括通过一个代它审批的工具？
• 如果审计师要求你重新执行上一季度，哪些已记录的产物能让这次回放完全一致？它们保存在哪里？
• 哪些调节项或异常类别是由规则指定的？没有任何规则认领的项目会怎样处理？