论文导读：让前沿模型做真正的会计工作——最强 56.4%，没有模型能稳定通关

论文：APEX-Accounting
作者：Benchek Julien, Bennett Austin, Kern Jasmin, Stevens Ryan, Sultan Rene 等
机构：Mercor × Ramp
arXiv：2607.27189
链接：https://arxiv.org/abs/2607.27189
代码：https://github.com/Mercor-Intelligence/archipelago

一个简单的问题：AI 能不能替我做账？

过去两年，我们看到了大量"AI 通过注册会计师考试""AI 通过法律职业资格考试"的新闻。这些成绩让人产生一种错觉：AI 已经能做专业工作了。

但"通过考试"和"做实际工作"之间有一道巨大的鸿沟。考试题目是干净的、边界清晰的、所有信息都在题面里。而真正的会计工作是这样的：

• 你要在一堆电子表格、PDF、邮件、银行对账单里找到相关的数据
• 你要判断这笔账应该记到哪个科目
• 你要多步推理：先对账，再调整分录，再过账，再生成报表
• 中间任何一步出错，后面全错

APEX-Accounting 这个 benchmark 就是来测这道鸿沟的。它由 Mercor 和 Ramp 合作构建，专门测试"前沿模型能不能做真正的会计工作"。

Benchmark 设计：10 个"世界"，160 道真活

10 个"世界"

APEX-Accounting 不是一堆孤立的题目，而是 10 个完整的"会计世界"。每个世界包含：

• 一套完整的会计系统（账本、科目表、历史交易）
• 一堆相关文件（电子表格、PDF、发票、银行对账单）
• 一系列互相关联的任务

这种设计的意义在于：任务之间是耦合的。第 3 题可能依赖第 1 题的结果，第 7 题可能需要先完成第 5 题。这和真实会计工作一样——月底结账是一个流程，不是 20 道独立题。

160 道任务

每个世界 16 道任务，共 160 道。任务类型覆盖会计的核心工作：

• 对账（reconciliation）：银行对账单和账本对不上，找出差异
• 应计（accrual）：本期发生但未付款的费用，要计提
• 过账（posting）：把分录从日记账转到分类账
• 生成报表（reports）：生成试算平衡表、利润表、资产负债表

专家级标注

每道题都由会计和簿记专家出题、解题、写评分标准。评分不是"对/错"二元，而是按多维度评分标准（rubric）给分——这允许部分正确，也允许"方法对但计算错"这类情况被区分出来。

主结果：最强 56.4%，没有模型能稳定通关

论文测了 9 个前沿模型，结果可以用三个数字概括：

数字 1：56.4%

Claude-Fable-5（Max）以 56.4% 的 Mean Criteria@3 排名第一。第二名是 Muse-Spark-1.1（xHigh）的 52.6%。

Mean Criteria@3 的意思是：给模型 3 次尝试机会，取每次按评分标准的平均得分。这是一个相对宽松的指标——3 次机会、按维度平均——但最好的模型也只到 56.4%。

数字 2：2.6%

Pass^8（8 次尝试中至少 1 次完全通过的比例）最高只有 2.6%，由 GPT-5.6-Sol（Max+Pro）取得。

这是一个非常苛刻的指标——8 次机会里至少 1 次完全通过——但 2.6% 意味着几乎没有任何任务能被模型稳定地完全做对。

数字 3：Pass@8 最高 21.5%

Muse-Spark-1.1（xHigh）的 Pass@8 是 21.5%——8 次尝试中至少 1 次通过的比例。这意味着即使是最好的模型，每 5 道题里还有 4 道在 8 次尝试中都做不对。

这三个数字合起来，讲了一个清晰的故事：前沿模型在真实会计工作上，远没有达到"可以替代人类"的水平。最强模型在宽松指标下勉强过半，在严格指标下几乎全败。

失败模式：不是找不到，是推不动

论文的失败分析特别有价值。作者把模型的失败按环节分类，发现一个反直觉的结果：

模型能找到对的输入

最强模型在"找到对的文件和数据"这一步做得相当好。它们能正确地从一堆 PDF 和电子表格里找到相关的发票、银行对账单、合同。这一步的失败率不高。

模型卡在多步推理

真正的失败发生在多步推理这一步：

• 替换了错误的基准或授权逻辑：比如把"按发票日期确认收入"替换成"按收款日期确认收入"
• 中间结果丢失：第 5 步算出来的数字，到第 7 步就忘了，用了错的数字继续推
• 矛盾检测失败：文档里前后矛盾的信息（比如发票金额和银行记录不一致），模型没有发现也没有处理

工具调用错误不普遍

一个有意思的发现：工具调用错误不是主要失败模式。模型能正确地调用 API、读取文件、执行计算。问题不在"会不会用工具"，而在"推理链能不能稳定地走完"。

这和很多人的直觉相反——我们以为"Agent 能力"的瓶颈在工具使用，但 APEX-Accounting 发现瓶颈在多步推理的稳定性。

Simpson 悖论：钱花得多反而做得差

论文还有一个特别有意思的发现——一个 Simpson 悖论实例。

作者把模型的 token 预算从 1 美元提高到 50 美元，观察到一个看似矛盾的现象：

• 整体来看：预算提高，分数提高
• 预算内来看：在同一个预算下，模型在"花更多 token 的任务"上得分更低

这是典型的 Simpson 悖论——聚合数据呈现的趋势和分组数据呈现的趋势相反。

怎么解释？合理的假说是：难的任务让模型花更多 token（反复尝试、查更多文件），但难的任务本来就更难做对。所以"花更多 token"和"得分低"都是"任务难"的结果，不是因果关系。

这对实际部署有直接含义：不能靠"给更多预算"来解决难任务——难任务的瓶颈不是预算，是推理能力。

为什么这个 benchmark 重要？

1. 测的是"真实工作"而不是"考试题"

APEX-Accounting 和大多数 LLM benchmark 的根本区别：它测的是一个职业的日常完整工作流，而不是孤立的知识点。这和 SWE-bench（测软件工程师的真实工作）是同一种设计哲学。

这种 benchmark 的价值在于：它把"模型能力"和"职业可替代性"直接挂钩。56.4% 不是"模型不及格"，而是"模型在这个职业上还做不了主，只能做助手"。

2. 评分标准是"专家级"的

不是简单的"对/错"，而是按会计工作的多维度评分标准。这允许"方法对但计算错""部分步骤对"这类中间状态被区分出来。这种颗粒度对诊断模型瓶颈特别有用。

3. 揭示了"多步推理稳定性"是真正的瓶颈

论文的失败分析指向一个清晰的结论：模型不是"不会做会计"，而是"不能稳定地把会计推理链走完"。这个发现对整个 Agent 方向都有含义——Agent 的瓶颈不在工具使用，在长程推理的稳定性。

4. Simpson 悖论的实际含义

"给更多预算解决不了难任务"这个发现，对 Agent 系统的设计有直接指导：不能靠"给更多 token/更多轮次"来兜底——难任务的瓶颈是推理能力，不是资源。

一个跨域同构：和 SWE-bench 的对照

APEX-Accounting 让我想到 SWE-bench——测软件工程师真实工作的 benchmark。两者有几个结构同构：

• 都是"完整工作流"而不是"孤立题"：SWE-bench 是修一个真实 GitHub issue，APEX 是做一次真实月底结账
• 都揭示了"多步推理稳定性"是瓶颈：SWE-bench 发现模型能找到代码位置但改不对，APEX 发现模型能找到数据但推不动
• 都揭示了"工具使用不是主要瓶颈"：SWE-bench 发现模型能调用工具但推理出错，APEX 也是

这两个 benchmark 合起来指向一个共同的 Agent 设计原则：下一步的突破不在"更强的工具使用"，而在"更稳定的长程推理"。

局限

论文也坦诚了几个局限：

1. 闭源 benchmark：160 道题是私有的，不能公开。这限制了社区对模型的细粒度调试。但作者提供 leaderboard eval，任何前沿模型都可以申请评测。
2. 10 个"世界"可能不够多样：10 个会计系统、10 种业务类型——覆盖范围有限。会计在不同行业（制造业、零售、金融）差异巨大。
3. 没有人类基线：论文没有给出人类会计专家在这些任务上的表现。56.4% 是高是低，需要一个人类参考线。
4. 9 个模型都是闭源大模型：没有测开源模型（如 Llama、Qwen），无法分析"模型规模"和"会计能力"的关系。

我的看法

这篇论文最打动我的，不是 56.4% 这个数字，而是它揭示的**"考试通过 ≠ 工作胜任"的结构性差距**。

过去两年，我们看到了太多"AI 通过 X 职业考试"的新闻。但这些考试都是"干净题面、边界清晰、单步作答"的——和真实工作差得很远。APEX-Accounting 用真实数据告诉我们：通过考试和做实际工作之间，至少还差一个数量级。

更深一层：论文的失败分析指向一个对整个 Agent 方向都有含义的结论——长程推理稳定性是下一个核心瓶颈。模型能找到对的文件、能调用对的工具、能做对单步推理，但把 10 步推理串起来稳定走完，还做不到。这不是"会计 AI"的问题，是所有 Agent 系统的问题。

最后，Simpson 悖论的发现值得记住：给更多预算解决不了难任务。这对所有"用更多算力兜底"的 Agent 设计都是一个警告——难任务的瓶颈是推理能力，不是资源。你不能靠"让模型多想几次"来解决它根本想不出来的问题。

论文链接：https://arxiv.org/abs/2607.27189
HTML 版本：https://arxiv.org/html/2607.27189v1
代码仓库：https://github.com/Mercor-Intelligence/archipelago