企业财务的 AI 该怎么落地:别买平台,给「中间那个人」装个后台 agent

本文原题《AI for Enterprise Finance & How to Do It Right》,作者 Vasuman Moza(@vasuman)。据其公开资料:UC Berkeley 计算机系,在 Meta 做过三年软件工程师,现为 Varick Agents 创始人兼 CEO——这家公司专门帮企业财务团队,在他们已经在用的系统里部署 AI agent。这篇长文在海外 AI 工程与创业社区被反复转发讨论,因为它罕见地不谈模型、不谈框架,只谈「在真实企业里,agent 到底怎么才落得下去」。中文翻译、重排、5 张原创配图本地化:Yaqin Hei(非原创,已保留原文出处)。

译者的话:为什么翻这篇

国内很多团队把「上 AI」理解成两件事:要么给每个人发一个助手(Copilot、各种 chat),要么买一个号称 AI-native 的 SaaS。这篇把这两条路为什么都会失败讲透了,然后给出第三条——而且是拿真金白银的企业财务场景验证过的。

对我最大的改变,是它换掉了我评估任何一个「AI for X」方案的第一个问题。以前我看模型多强、demo 多惊艳;现在我先问两件事:① 交付物是一个在后台自己把活干完的 agent,还是一个只负责汇报的 dashboard / chatbot?② 这套东西里,多少是确定性代码、多少是模型调用?因为「85% 代码 / 15% 模型」这个比例,几乎直接决定了它能不能在真实生产里活下来——既扛得住 token 成本,又给得出审计追踪。

而全篇最扎心的一句是:你的工具各自自动化了「任务的一个切片」,却没有一个人去自动化中间那个人——那个把数字从一个屏幕抄到另一个屏幕、对不上就发催办邮件、没人回就往上升级的操作员。恰恰是这个人,是所有价值所在的胶水层。你下周做需求评审时,就能拿上面这两个问题,去筛桌上的每一个 AI 方案。

---

以下是正文

我接触的每一个营收十亿美元以上公司的 CFO,都在两条战线上被 AI 折磨着:

横向助手——给组织里每个人发一个 Microsoft Copilot 或 Claude Cowork。问题是:每个员工都会开出三个 agent,互相之间谁也不认识谁,三个月后你花掉了 300 万美元的 token,80% 的 agent 要么废弃、要么在生产里三天两头崩。你手里剩下的,是一张 300 万美元的 token 账单,加一座没人认领的技术债坟场。

点解决方案——为应付账款(AP)引进一个软件,为月末结账(close)引进另一个,为报销再引进第三个。这条路走不通,因为为所有人做的软件,不是为你做的。它不懂你的 AP 流程是 7 步而不是 4 步,不懂你的例外处理逻辑。结果就是:员工要么根本不用,要么用了但 ROI 不到 15%。更糟的是,大家抱怨这个新软件跟以前的干法不一样,一半人觉得这是降级。噩梦。

我的工作,是帮 CFO 想清楚这两类方案对他们来说的正确配比。横向助手绝对有存在的必要,但它服务的是另一个目的:员工手上还有活要干,这个助手是帮一个人干出十个人的活。但你漏掉了更大的图景:后台 agent——它根本不需要被谁 prompt、被谁使用,就自己把活干了。

想象一个 agent:每张发票一落地它就读,匹配到正确的采购订单(PO),干净的直接过账,那张唯一奇怪的踢给唯一需要拍板的人——这一切在你的团队打开笔记本之前就已经完成。想象一个 agent:每天早上把昨天的银行流水跟总账(ledger)对平,于是月末还没到,结账其实已经差不多做完了。想象一个 agent:自己去追每一个供应商要缺失的 W-9、要逾期的付款,于是你团队里再没有人需要写那种邮件。没有人 prompt 它们,它们就在后台跑着,你来上班时,活已经干完了。

交代一下背景:我经营着 Varick Agents(@varickagents)。我们嵌入企业财务团队,部署运行在他们已有工具内部的 AI agent。财务是我们见到成效最快、最可量化的地方——因为这里的活重复、流程定义清晰,而人工版本的成本又极其容易折算成一个数字。

这篇文章要讲的,是我们如何为多家公司规模化地做成了这件事、我们踩过并学会规避的坑、以及尘埃落定后我们如何衡量成败。附赠:我们如何做到不每年在 token 上烧掉几百万,以及如何把幻觉压到接近 0。举个参照,我们把一个客户的月末结账从 12 天压到 5 天,同时把错误率降低了 72%。价值捕获(value capture)高达每年 4500 万美元以上,是营收提升、成本节约、风险降低的组合。每一次都是同一套打法——哪怕最后长出来的 agent 千差万别(这也正是为什么点解决方案软件行不通)。

财务 AI 落地的失败率高得吓人

在讲「怎么做」之前,先快速看一眼数字。财务团队现状与本可达到的水平之间差距巨大,但目前为止 AI 的成绩相当难看。

• Gartner 调研了 183 位财务负责人,84% 已经或计划部署 AI,但只有 7% 报告了「高影响」。
• MIT 的 NANDA 小组看了 300 个部署案例,发现 95% 的企业生成式 AI 试点对 P&L(损益)没有任何可衡量的回报。
• Gartner 预计,到 2027 年底,40% 以上的 agentic AI 项目会因成本、价值不清、风险控制薄弱而被砍掉。

所以我说「大部分会失败」时,引用的就是这些数据。下面我会告诉你为什么。作为对比:Varick 财务部门的实施 100% 成功部署进了生产,且都有可衡量的正 ROI(平均 5.5 倍)。

再看活儿本身:

• 三分之二的发票仍然需要一个或多个人经手,只有三分之一能一路直通(Ardent Partners, 2025)。在我们服务过的客户里,一张发票在彻底处理完之前,常常有 3 个甚至更多人经手。
• 一张发票人工端到端处理的成本是 12.42 美元。
• 一半的财务团队结账要花一周以上(Ledge, 2025),其中 94% 的人在这个结账过程里的某个环节,还活在 Excel 里。
• 14% 的发票被标记为例外(exception),而例外是 AP 里被抱怨最多的头号痛点。这是我最想让你注意的一条数字。 你的例外跟隔壁公司的例外不一样——这意味着没有任何一款通用 SaaS 或产品,能以你需要的方式解决这个巨大的麻烦。财务部门对定制软件的需求从未如此之高,而幸运的是,AI 正是这里最完美的解锁点。

这些都不再是技术问题了。它是工作流问题,是人肉胶水问题——这个区别,我下面会更详细地展开。

两条死路,和第三条:横向助手和点解决方案都在解「别人的问题」,只有 agent 层解你的。

为什么横向助手(Claude Cowork、Microsoft Copilot)会失败

就算我们不算那张 token 账单(每季度几百万),更大的问题是:连前沿模型,做财务工作也多半会做错。 今年有人拿 900 多个真实的财务分析师任务去考前沿模型(Fable、Opus、GPT 5.5 等),最好的一个也只有 52% 的准确率(Vals AI)。另一项研究拿 19 个模型跑真实的会计科目表(chart of accounts),最高准确率 66%(DualEntry)。在财务职能里,这种准确率是灾难性的。连微软自己的文档都说:别拿 Excel Copilot 做数值计算或任何有合规含义的事——这话很好笑,毕竟是他们先把 AI 塞进你的电子表格的。

幻觉在这里不是邮件里打错一个字。如果你的 AI 幻觉出一个供应商、或搞砸一笔公司间抵销(intercompany elimination),那是真金白银流出了门,得有人去找回来、去回滚。可审计性的缺失同样是天大的问题:「AI 说的」这句话,在 SOX 审计师面前是不管用的。

你的 AI agent 必须被加护栏、加权限,让它永远只做你允许的那几个动作——这些动作由一次全面的 AI 审计来确定。每个任务进一步被拆解到它最确定性的形态,于是模型只决定那几个真正需要判断的步骤,而不是端到端地什么都由它决定。这才是准确率稳在 97% 以上、并且每一步的 agent 追踪都能摊给审计师和管理层看的原因。

为什么堆更多点解决方案只会更糟

于是你绕开通才,买一堆专才:AP agent 来自 Ramp、Brex、Bill,催收来自 HighRadius,结账 agent 来自 BlackLine、FloQast,全都塞进 SAP 和 Workday 的 ERP 里,外加一个新的 AI-native ERP。看出我要说什么了吗?AI 本该是你终于能摆脱 20 个各干各的软件供应商的理由。你需要的是一块跨越所有现有系统的单一玻璃面板(single pane of glass)。那些系统里已经有 agent 运行所需的一切,不需要任何新平台。可我看到的却是 CFO 们无奈地引进更多软件许可、更多要登录和记挂的界面,到头来几乎没有任何效率提升可以拿出手。

什么才真正有效

每一个真正跑通的财务部门部署,都遵循同一套哲学:一层东西,坐落在你已有软件的上面、以及它们之间——而不是又一个要你团队登录的工具。它从你的软件(如 NetSuite、Bill、Workday)里读数据,在它们之间搬运数据,像你团队会做的那样把活干了。碰到需要人协助的地方,它把要改的地方标出来,让你的团队去调整。

在这个过程里,你增强的是操作员,不是任务。眼下你的工具各自自动化了活儿的一个切片,却没有一个人去自动化中间那个人——那个把一个屏幕上的数字抄到另一个屏幕里、核对两个数字对不对得上、对不上就发催办邮件、没人回就往上升级的人。这个人就是胶水,而所有价值都在胶水里:周期时间(cycle time)缩短,意味着省下时间、更快地创造更多营收。

你增强的是操作员,不是任务。工具自动化「切片」,agent 层自动化那个把切片粘起来的人。

把这个例子拉回到例外上:想象一张落地时没有对应采购订单的发票。眼下,一个 AP 分析师得先弄清楚是谁下的单,再靠过滤收件箱找到正确的 PO,匹配上,最后才推过去。例外比你以为的常见得多——这种事一个月发生几百次。

而有了统一的 agent 层,AI 在发票一落地的瞬间就抓住这个例外,然后按供应商、金额、日期去 PO 系统里搜,把干净的匹配像你的分析师一样自己清掉。当 agent 拿不准时,它把最可能的两个 PO 发到分析师的 Slack 上,请他判断哪个才对。15 分钟的翻找,变成 30 秒的一个「是 / 否」,而且所有信息都提前摊在面前。同样的塑形也发生在银行对账、公司间抵销、W-9 催办、付款状态邮件,以及审计师的 PBC 清单上。

这套系统在实践中怎么落地

我们每一次都做 5 件事:

1 · 前置部署工程师(forward deployed engineer)嵌进你的部门,把每一个流程端到端地画出来。 成文的流程和 SOP,极少能捕捉到「现实」——也就是人们实际在做什么。比如:「出问题时我先查这张表」、「我直接给 Sarah 发邮件,因为那套告警坏了三年了」。一个真实的例子:「SOP 说发票要在系统里匹配到 PO」,但现实是——是在系统里匹配,除非 PO 压根没被创建过,这时 Brittany 会给部门负责人发邮件补一个;除非金额低于 500 美元,那她就把它记到部门的一般费用科目里,标记一下回头再说。如果你只照着 SOP 去建 agent,它在撞上 Brittany 的第一天——也就是上生产的第一天——就会崩。所以坐下来看着人干活,极其重要。这是「服务(咨询)」和「软件(开发)」之间的桥,也正是一次成功的 agent 落地,与一个上线即死的盲赌之间的分水岭。

2 · 在他们已经在用的工具里面建。 agent 像一个新员工那样操作 NetSuite、SAP 或 BlackLine:登录、点过同样的界面、调用同样的 API。你团队里没有人需要学一个新界面,大家唯一注意到的,就是堆积的活变少了、例外清得更快了、月末结账变短了。

3 · 建「干活」的 agent,不是「看板」。 大多数所谓「AI for finance」都是一个伪装成 agent 的分析工具。别掉进这个陷阱。监控和报表,应该是 agent 动作驱动出来的结果。是的,在开建前测一测 KPI 有帮助,能看你是否真的带来了改变。但如果你的产物是一个 dashboard 或 chatbot,而不是一个后台 agent,你就是在把效率留在桌上没捡。别花好几个月,去做一个高级版报表软件。

4 · 只在真正需要判断时才升级给人,前面加一道会随时间变好的置信度闸(confidence gate)。 目标是把那 70% 到 85% 纯属模式匹配的活从你团队盘子里拿走,让他们的时间只留给高杠杆、高判断的决策。同时,他们每一次对 agent 动作的回应(批准、修改、拒绝)都在训练这个 agent,让准确率每周往上爬,而不是原地不动、甚至倒退。这正是 AI 工程的关键所在:你的 harness(工程骨架),可能就是「一套会自我改进的系统」和「一套慢慢熄火的系统」之间的生死线。

5 · 第一天就为整个部门设计。 这是企业级 agent 落地里被忽视得最厉害的一点。想象每个操作员各自抄起一个 vibe-coding 工具,为自己那个角落建一个 agent,但它没法扩展到本人的活以外。这漏掉了更大的图景——很多时候,他们的瓶颈在上游。可上游团队又建了他们自己的 agent,跟下游那个不通话。很快你就有了几十个 agent,各自封闭在自己的活里,互不通信——满组织的技术债。正确的做法是:把整个组织画出来,搞清楚谁是谁的瓶颈,带着这张图去建。

如何避免 token 花销失控和 agent 幻觉

怎么做到不在 token 上烧掉几百万:一个好的 AI agent,大部分不是 AI。 我们交付的东西里,约 85% 是普通代码,约 15% 是模型调用。模型只用在真正需要判断的地方——比如从一张乱糟糟的发票上读出一个值、把一个例外归到你已知的某个桶里、或起草一段给人批准的说明。而绝大多数活是:比较(数学)、查找(过滤)、路由(if/then/else)、过账(API 调用)。对比一下 Claude Cowork,那里几乎每个动作都由 LLM 随机地决定。我们的 agent 反过来:更快、更便宜、更准。LLM 只是那个解锁点而已。

一个好 agent 大部分不是 AI。模型只花在真正需要判断的少数几步,其余都是能审计的代码。

怎么把错误率压到接近零:三层。

• 确定性代码——它天生就一致,而一致正是它可审计的原因。
• Evals(评测集)——一套手动创建、但自动更新的测试套件,同时检查「答案」和「agent 走过的路径」,让我们能抓住那些跑到了不该去的地方、或产出了与我们期望行为不符的 agent。
• 人类反馈——你团队做的每一次批准和纠正,都在训练系统,几个月内某条工作流的准确率就爬进 90 多。我们眼看着 GL 科目编码从大约 85% 爬到 97% 甚至更高,随着纠正一点点累积。而因为它是代码 + evals 而不是一个黑箱,任何时候当利益相关方或审计师问「这个 agent 为什么这么做」,你都真的答得上来。横向 agent 做不到这一点。

这一切怎么衡量

好在,当你的 agent 活在你的记录系统(system of record)之上、覆盖每一条工作流、每一片软件时,你就有了在最细粒度、实时地追踪数据的能力。「80% 的例外正在被 agent 处理」、「例外的对账时间从 4 天降到 2 小时」——这些会变得一目了然。一些真实结果:

• 结账从 12 天降到 5 天
• 例外处理从每月 130 小时降到 20 小时
• 单张发票处理平均从 20 分钟降到 1 分钟以内

把你衡量的一切都归进这三个桶,再据此度量价值捕获——agent 活在记录系统之上,数据能在最细粒度、实时地追踪。

对任何一次 AI 落地来说,真正重要的价值捕获只有 3 个桶:我在省时间 / 省钱吗?我在增加营收吗?我在降低风险吗?把你衡量的一切都归进这 3 类,再据此度量价值捕获和 KPI——会很有帮助。

从哪里开始

在你的组织里找到流程负责人(process owner),从他们开始。深入理解他们当前的流程是什么(要有心理准备去找他们的子流程负责人、分析师、一线执行者聊,拿更多信息)。把这些问清楚:

• 今天的活到底怎么跑——所谓这条流程的「工作流基因组」(workflow genome)是什么
• 每个任务的数据量和吞吐量是多少
• 错误率是多少,今天一个错误的成本是多少?
• 例外怎么处理、跨哪些格式?

从这里,拿着你的发现,开始画出下面这些:

• 每条工作流里,AI 做什么、不做什么?每个流程的「后 AI 世界」长什么样?
• 在这 3 个价值捕获桶上,每一个可量化的金额是多少?
• 每个 build 要花多少时间和精力?各自的风险是什么?

把价值捕获和投入一比,你就有了自己的优先级清单。

但一句话总结:别买平台,也别搭一个数据科学团队。 这整个过程甚至不需要一整年。你真正需要的,是找到愿意坐下来陪你团队、学会真实工作流、并在你已有系统内部把 agent 建起来的人——而且每一步都在度量它。

这正是我们在 Varick Agents 做的事。我们嵌入过从 10 亿美元营收、一路到年营收 500 亿美元以上的财富 500 强巨头的财务、销售、运营团队,构建在他们已有系统内部运行其工具的 agent。如果你的结账还是两周、你最好的人还在做数据录入,来 varickagents.com 找我们。

---

译者:Yaqin Hei。原文 AI for Enterprise Finance & How to Do It Right(Vasuman Moza / Varick Agents)。本文为翻译 + 重排 + 配图本地化,非原创,已保留原文出处与作者署名。文中一切数据与结果均为原作者所述,归其所有。