MCP 对财务来说还不够：为什么把 LLM 接入 ERP 之后算数依然会出错

一位财务总监把一个 Model Context Protocol 服务器接入 NetSuite,向 AI 询问按业务分部划分的过去十二个月毛利率，四秒内就得到了答案。这个数字偏差了 90 个基点。不是因为 AI 无法获取数据，它精确地取到了数据:正确的总账科目、正确的期间、正确的主体。然后它自己在 token 空间里做了除法运算，并悄悄在一个抵销收入科目的正负号上出了错。

这正是 MCP 把财务团队带入的陷阱。连接看起来是最难的部分，所以一旦管道打通，工作似乎就完成了。事实并非如此。检索问题已经解决，算术问题没有。

MCP 真正解决了什么

先给 MCP 应有的肯定。Anthropic 在 2024 年底推出这一协议，作为连接模型与外部工具、数据的开放标准，到 2025 年 11 月的规范版本时它已经具备了真正的能力:结构化的工具定义、并发工具执行、面向长时间任务的进度跟踪，以及浏览器中介的流程，使客户端无需持有原始凭证。微软为 Dynamics 365 Finance and Operations 提供了 MCP 服务器，市场数据、会计平台、数据仓库也都有相应的 MCP 服务器。

真正的价值在于治理。在 MCP 之前,“把 AI 接入我们的 ERP”通常意味着脆弱的自定义集成、权限过宽的 API 密钥，以及模型接触过什么完全没有记录。MCP 把这种访问标准化:统一协议、明确声明的能力、受限的权限、可审计的界面。如果你原来的替代方案是把 CSV 导出粘贴进聊天机器人，那么 MCP 在数据泄露和可解释性上就是一次实质性的升级。

所以，当供应商说“我们是 MCP 原生的”,可以相信他们解决了管道问题。但不要让这句话悄悄延伸为“因此数字是对的”。这是两句不同的话。

MCP 无法给你的两样东西

把差距讲清楚:MCP 是一个传输和访问层，它把上下文送到模型，并向模型暴露可调用的工具。但它对决定一个财务答案是否可信的两个问题，完全没有涉及。

它不做对账。 通过 MCP 连接返回的是原始账本数据:分录明细、科目余额、维度标签，多个各有自己会计科目表的主体，尚未抵销的公司间往来分录，总账里的收入数字与账单子账本里的数字对不上。MCP 把这团混乱原样交给模型。模型现在必须自己判断哪个“收入”才是真的、是否要抵销公司间往来分录、如何把四张主体科目表映射到同一个毛利率定义上。这不是检索，这是会计判断，而 LLM 星期二的判断方式和星期一并不一样。

它不做确定性计算。 即便输入数据是干净的，接入 MCP 的 LLM 仍然只能用它唯一会的方式做算术:预测下一个 token。基准测试对此毫不客气:顶尖模型在财务电子表格任务上停留在约 82%,在财务问答上约为 90%。90% 的正确率听起来还可以，直到你想起这意味着十个数字里有一个是错的，而且没有任何标记告诉你是哪一个。协议把正确的数据搬进了提示词，然后把计算留给了整个体系里最不可靠的那个环节。

即使通过 MCP 交给 LLM 一张干干净净的试算平衡表，你仍可能得到错误的毛利率，因为问题不在数据通路上，而在算术上。

“那就给它配个计算器工具”

一个显而易见的反驳:MCP 支持工具调用，那就暴露一个 calculate 工具，让 LLM 不再靠脑子做算术。这话对了一半，而对的这一半很重要。把实际运算交给代码而不是 token 预测，这个直觉本身完全正确。

但一个孤立的计算器工具会在上一层继承同样的问题。模型仍然要自己决定喂给它什么:哪些科目、哪些期间、哪些主体、这一行是否已经扣除了退货。垃圾的选择输入到一个完美的计算器里，输出的还是垃圾。而且临时拼凑的工具会漂移:这次调用里内置的毛利率定义，和模型下次对话里自己拼出来的定义未必一致，于是两个人问同一个问题得到两个答案，而且谁也无法证明哪个是对的。没有一个共享的、已对账的模型作为底座，计算器只会让不一致来得更快。

协议和答案之间应该放什么

解决办法不是拒绝 MCP,而是把它用在它擅长的地方，把缺失的层放在它该在的位置:连接与语言模型之间。

首先是一个已对账的模型。在这里，来自多个来源、混乱的输入被映射到统一约定的定义上，公司间往来被抵销，各主体被合并，每一个数字都能对回总账。这是唯一的事实来源，是财务总监真正愿意签字确认的东西。“毛利率”的语义定义只在这里定义一次，而不是每次提示词里重新推导。

其次是一个确定性引擎。计算作为代码在这个已对账的模型上运行，而不是作为预测在 LLM 内部发生。相同的输入，永远相同的输出，并且能追溯回源头。模型的职责收缩为它真正擅长的部分:理解问题、选择正确的预定义指标、用通俗语言解释结果。它负责检索和讲述，不负责凭空生成数字。

这正是 Rexfin 的分工方式。连接你的会计和金融数据平台，或者上传报表。我们构建一个能对回总账的、已对账的模型。之后 AI 负责检索数字、通过确定性引擎完成运算、对情景假设建模，并产出可追溯到源头的洞见。MCP 可以是数据进来的一扇门，但它不能替代那扇门背后的模型和引擎。

如果你还处于架构更早期的阶段,电子表格同样是承载这一切的错误地基,原因是一样的:把 AI 接到一个有缺陷的底座上，只会把缺陷自动化。而董事会真正会用来衡量你的标准比“它给出了答案”要苛刻得多，那就是这个数字是否可重放，是否像一个公式那样可被证明。把可靠的财务建模当作独立一层来对待的完整论证见主题页。

结论

MCP 回答的是“AI 能否触达我们的数字?”它不回答“这些数字对不对?”这才是首席财务官真正关心的两个问题，一家解决了第一个问题却暗示自己也解决了第二个问题的供应商，卖给你的是信心，不是准确性。追问第二个问题:对账在哪里发生，算术在哪里运行。如果答案是“LLM 自己搞定”,那你拥有的只是一条通向错误数字的快速管道。

在你自己那团混乱的数据上，亲眼看看“已对账模型加确定性引擎”这套架构,预约演示。