News

Spreadsheet-RL: Advancing Large Language Model Agents on Realistic Spreadsheet Tasks via Reinforcement Learning

原文链接：https://arxiv.org/abs/2605.22642 数据集：https://huggingface.co/datasets/Spreadsheet-RL/Spreadsheet-RL 代码：https://github.com/Spreadsheet-RL/Spreadsheet-RL 作者：Banghao Chi, Yining Xie, Mingyuan Wu, Jingcheng Yang, Jize Jiang, Zhaoheng Li, Shengyi Qian, Minjia Zhang, Klara Nahrstedt, Rui Hou, Xiangjun Fan, Hanchao Yu 机构：University of Illinois Urbana-Champaign, Meta 发布日期：2026-05-22

速查卡

项目	内容
一句话总结	这篇论文把“电子表格 agent”从 prompt engineering 提升到真实 Excel 环境里的 outcome-based RL。
大白话版	以前 agent 做表格，多半是拿通用模型 + 一堆 prompt 凑；这篇工作直接造了 Excel 训练场、数据管道和评分器，把模型练成更像“会改表的人”。
核心数字	SpreadsheetBench Pass@1：12.0% → 23.4%；Domain-Spreadsheet：8.4% → 17.2%；训练集 5928 个高质量任务。
评级	A- — 不是新底座模型，但很可能是“生产力软件 agent RL”的代表性路线。
代码	已承诺/已给出公开地址：https://github.com/Spreadsheet-RL/Spreadsheet-RL
关键词	spreadsheet agent、Excel、RL、GRPO、Spreadsheet Gym、tool harness、Domain-Spreadsheet

核心 Insight

Spreadsheet-RL 的核心洞察很简单，但很硬：表格不是“另一个文本任务”，而是一个强状态、强语义、强执行约束的交互环境，所以不能只靠提示词把通用模型硬掰成 spreadsheet agent。

为什么现有方法容易卡住？因为真实表格任务不是“写个公式”那么简单。它经常要求多步操作：找工作表、定位区域、填公式、清空单元格、删行删列、触发重算、检查格式与引用关系。任何一步语义搞错，结果都可能全错。通用 code interface 虽然表达能力强，但对小中型模型来说太脆：行列偏移、公式引用平移、blank vs delete、recalc 语义、格式保留，这些都不是语言模型天然擅长的低层细节。

这篇论文的答案是三件套一起上：

用 Spreadsheet Data Agent 自动造出大规模“初始表格 → 目标表格”训练样本；
用真实 Microsoft Excel 搭一个 Spreadsheet Gym；
用 spreadsheet-native harness 把动作空间结构化，再用 outcome-based GRPO 做 post-training。

这套方法的关键不只是“加 RL”，而是先把环境、动作空间、奖励函数都做成适合 RL 的样子。没有这些前置工程，RL 本身根本跑不起来。

为什么这个想法 work？

因为表格任务的难点，本质上是“长期交互中的低层执行正确性”。

和代码 agent、网页 agent 很像，电子表格 agent 也需要多轮操作；但它比网页更讲究语义精确性：

一个公式填错引用，整列结果都错；
把 clear cell 当 delete row，会把表结构搞坏；
如果不用真实 Excel 重算，很多现代函数的行为都不可信。

因此，Spreadsheet-RL 并没有把功夫花在更花哨的 reasoning prompt 上，而是做了三层约束：

数据上：给 RL 足够多的真实初始-目标对；
环境上：用 Excel 而不是近似模拟器；
动作上：给模型一组 spreadsheet-native tools，让它少犯低层结构错误。

这正是它能 work 的根因。

方法详解

整体架构

真实论坛问题 → Spreadsheet Data Agent → (初始表格 Di, 指令 T, 目标表格 Do)
                                                ↓
                                      Spreadsheet Gym (真实 Excel)
                                                ↓
                                  Spreadsheet-native harness + tools
                                                ↓
                                    Qwen3 policy 多轮交互编辑表格
                                                ↓
                                Excel 重算 + 对比目标区域 → outcome reward
                                                ↓
                                            GRPO 更新策略

组件 1：任务定义

每个训练/评测样本由四部分组成：

初始表格 $D_i$
自然语言指令 $T$
oracle 最终表格 $D_O$
用于奖励比较的 manipulation region $M$

agent 的目标不是输出答案文本，而是经过一系列表格操作，把最终结果 $D_{pred}$ 变得尽量接近 $D_O$ 。

组件 2：Spreadsheet Data Agent

**做什么：**从真实世界自动构造 RL 需要的表格任务。

怎么做：

从公开 ExcelForum 收集 seed metadata；
选带附件、带问题描述、带多轮讨论的帖子；
这些帖子中往往已经包含初始工作簿、问题描述和潜在解法讨论；
再让强 coding agents（文中明确举例 Claude Code、Codex）在真实 Excel 环境里执行编辑步骤，生成候选 oracle 最终表格；
最后通过规则过滤和验证，去掉会触发 Excel 错误或不满足可计算要求的样本。

这一步是整篇论文里很容易被低估、但其实极关键的工程创新。因为 outcome-based RL 的前提不是“有问题”，而是“有可以自动验证的正确结果”。论文通过 coding agents 把论坛问答自动蒸馏成可训练的 start-goal pairs，等于把 spreadsheet RL 的数据难题先打穿了一半。

训练数据规模

论文给出的训练数据统计：

原始讨论串：18,855
电子表格附件：32,691
用户回复：144,694
过滤后高质量任务：5,928
其中 2,417 个任务含不止一个初始表格
平均每个讨论串 7.67 条回复

这说明它不是玩具级 synthetic benchmark，而是真想把 RL 喂到“像样能学东西”的规模。

组件 3：Spreadsheet Gym

**做什么：**把 agent 放进真实 Excel，而不是伪环境。

关键设计：

使用 Microsoft Excel 作为执行引擎。
支持现代 Excel 功能，例如 FILTER、UNIQUE、SORT、TAKE、MAP 等动态数组公式。
同时提供 code sandbox，让 agent 在需要时执行 Python。
每条 rollout 用独立 filesystem workspace 隔离，支持大规模并行 RL。

论文专门强调为什么不用 LibreOffice 之类替代品：很多现代函数与执行语义在替代引擎里并不完整，而训练一个面向真实办公场景的 spreadsheet agent，如果环境语义和实际办公软件不一致，学到的行为就会偏掉。

组件 4：Spreadsheet-native Tool Harness

这是这篇论文最“agent 味儿”的部分。

作者没有把一切都扔给 code interpreter，而是提供了一组结构化工具，并强制 agent 按 inspect → modify → verify 的流程工作。

关键工具

inspect_range：查看指定区域，可带公式/格式等细节
find_cells：找 header、anchor、文本线索
fill_formula：按矩形区域平移填充公式
clear_range：清空内容但不破坏结构
delete_rows / delete_columns：结构性删除
recalculate_and_read：在 Excel 里重算后再读回结果
code_interpreter：作为复杂逻辑或兜底工具

为什么要专门做这些工具？

因为通用 Python 编辑表格，虽然灵活，但对中小模型太难了。论文列出了几个典型 failure mode：

结构性修改导致索引漂移；
公式复制时引用平移出错；
搞不清“清空单元格”和“删除行列”的区别；
一边遍历一边删列导致错位。

结构化工具的作用，不是提高理论表达能力，而是把一类不该成为学习重点的低层错误从动作空间里剪掉。这跟 code agent 里专门提供 apply_patch、grep、run_tests 的逻辑一样：降低无谓错误，把学习压力留给真正的任务语义。

组件 5：Outcome-based GRPO

论文采用的奖励非常克制：

\mathcal{R}(o)= \begin{cases} 0, & \text{if no valid output} \\ \mathrm{allcellsmatch}(D_{pred}, D_O), & \text{otherwise} \end{cases}

其中：

$D_{pred}$ 是 agent 编辑后的最终表格
$D_O$ 是 oracle 表格
$\mathrm{allcellsmatch}(\cdot)$ 比较目标操作区域 $M$ 中的单元格是否匹配

这类奖励的好处是：

不需要人工标注中间步骤；
最终是否做对可以客观判断；
天然适合 RL。

训练目标

论文给出的优化目标是：

\max_{\pi_\theta} \; \mathbb{E}_{[D_i,T]\sim\mathcal{D},\,y\sim\pi_\theta(\cdot|D_i,T;G)}[\mathcal{R}(D_i,T,D_O)] - \beta \, D_{KL}(\pi_\theta \| \pi_{ref})

核心含义是：

提高最终表格和 oracle 的一致性；
同时用 KL 惩罚，避免策略一步跳太远；
用 GRPO 而非 critic-based 方法，降低训练复杂度。

异步奖励系统

论文还专门处理了一个现实问题：在 Excel 里打开文件、触发重算、再对比结果，本身就很慢，而且依赖 Windows + Excel。为了解决这个瓶颈，他们做了 submit-and-poll 异步 verifier，把 reward 计算从同步函数变成异步服务式流程。这一点非常关键，不然多轮 RL rollout 的吞吐量会被 Excel 直接卡死。

实验结果

主实验：SpreadsheetBench

方法	环境	Accuracy / Pass@1
GPT-4o	OSX, LibreOffice	16.8
GPT-4o	Windows, Excel	18.4
OpenAI o3	OSX, LibreOffice	23.3
ChatGPT agent	OSX, LibreOffice	35.3
Claude Files Opus 4.1	Windows, Excel	42.9
ChatGPT agent with .xlsx access	OSX, LibreOffice	45.5
Copilot Agent Mode	Windows, Excel	57.7
Qwen3-4B-Thinking-2507（raw）	Spreadsheet Gym	12.0
+ spreadsheet-native harness	Spreadsheet Gym	15.6
+ comprehensive spreadsheet tools	Spreadsheet Gym	19.3
+ Spreadsheet-RL post-training	Spreadsheet Gym	23.4

解读：

这组结果里最重要的不是“23.4 绝对值有多高”，而是 staged improvement 的形状。
单靠 harness：12.0 → 15.6
再加更完整工具：15.6 → 19.3
最后上 RL：19.3 → 23.4

这证明了三件事：

动作空间设计本身就能带来显著收益；
工具丰富度不是锦上添花，而是决定 agent 起始 policy 能不能站住的地基；
RL 有效，但它不是单兵突进，必须建立在“像样的环境 + 像样的 harness + 像样的数据”之上。

Domain-Spreadsheet 泛化实验

领域	样本数	平均 sheet 数	中位输入 KB	Base Pass@1	RL Pass@1
Finance-B	597	2.0	9.5	15.6	29.3
Finance-I	388	2.6	9.9	7.7	16.2
Finance-A	135	3.0	10.4	8.1	19.3
Supply Chain	180	3.4	16.0	1.1	5.0
HR	185	3.3	13.7	0.5	3.2
Sales	86	3.1	14.1	1.2	5.8
Real Estate	89	3.5	12.8	1.1	1.1
Overall	1,660	2.7	10.3	8.4	17.2

解读：

Finance 场景收益最明显，说明训练数据虽来自论坛操作任务，但学到的行为能迁移到较强专业分析工作流。
Supply Chain、HR、Sales 虽然绝对分不高，但都翻了数倍，说明 RL 不只是 overfit SpreadsheetBench。
Real Estate 完全没涨（1.1 → 1.1），这很有价值：它说明当前 4B 级别 spreadsheet agent 的泛化边界仍然很硬。

训练动态

论文记录了 step 0 到 step 60 的训练变化：

平滑训练奖励：约 0.21 → 0.33
SpreadsheetBench 准确率：19.3% → 23.4%
平均输出长度：约 16k → 11k
平均交互轮数：约 20 → 11

这组结果很漂亮，因为它说明 RL 不是靠“多想多写多试”提分，而是在变得更短、更稳、更像人类熟练操作者。

与现有方法的关键区别

维度	之前的方法	本文方法	为什么更好
训练方式	Prompting / inference-time engineering	Outcome-based RL + GRPO	直接优化长期交互结果
环境	近似表格接口、弱执行语义	真实 Microsoft Excel	语义更忠实，适合办公场景
数据	小规模、人手构造	自动化论坛采集 + coding agents 构造 oracle	更容易扩展到 RL 规模
动作空间	通用代码接口为主	Spreadsheet-native tools + workflow	减少低层执行错误
泛化评测	主要看 operation benchmark	增加 Domain-Spreadsheet	更接近真实行业工作流

复现评估

维度	评分(1-5)	详细说明
数据可得性	⭐⭐⭐⭐	数据集与代码地址已公开，任务来源与过滤逻辑写得比较清楚。
代码可得性	⭐⭐⭐⭐	代码可拿到，但真实复现要折腾 Excel、VeRL、异步 verifier、sandbox。
算力需求	⭐⭐	4B 模型 RL 不算最夸张，但环境成本重，尤其是 Excel 运行与 verifier 吞吐。
工程复杂度	⭐⭐⭐⭐⭐	这是一个典型“论文是一页，系统是半个平台”的项目。
预期收益	⭐⭐⭐⭐⭐	对所有想做 Excel / Office agent / productivity RL 的团队都很有参考价值。

复现建议： 最现实的复现路径，不是一步到位复现全部 RL，而是按顺序：

先复现 Spreadsheet-native tools；
再复现 Spreadsheet Gym 的真实 Excel 执行与对比器；
然后拿自家模型做 pre-RL harness ablation；
最后再接 RL。

如果一开始就冲 RL，很可能会被环境稳定性拖死。

批判性分析

论文承认的局限

目前主要聚焦相对轻量的开源模型，没有展示更大 dense 或 MoE 模型训练结果。
当前框架仍是研究基础设施，还不是可直接部署的生产决策系统。

我们额外发现的问题

绝对分数仍然不高。 23.4% 的 SpreadsheetBench Pass@1，说明这个问题非常难，也说明距离真正“办公级可靠”还有明显差距。论文的贡献更多是开路，而不是终局方案。
训练数据来自 ExcelForum，会有分布偏差。论坛问题天然偏“故障修理 / 操作求助 / 局部任务”，而企业真实工作流里还有大量隐含业务逻辑、跨表组织结构、脏数据治理问题。Domain-Spreadsheet 是一个补丁，但规模仍有限。
奖励函数很强依赖 target region 定义。如果一个任务有多种等价做法，而 reward 主要比对最终区域，某些“结构不同但业务上可接受”的做法可能仍被判失败。表格任务里这类问题不少。
对大模型与更强工具集的 scaling 还没展开。这篇论文已经证明方向成立，下一步真正关键的问题是：
- 更强 base model 能否把这个范式推得更远？
- RL 收益在 14B / 32B / MoE 上会不会更大？
- 能不能迁移到 Google Sheets、企业 BI、Office 全家桶？

对领域的影响

我认为 Spreadsheet-RL 最重要的意义，不是“Excel agent 终于破 20 分”，而是它明确了一条更通用的路径：

先把生产力软件变成真实交互环境；
再把动作空间结构化；
最后用可验证结果做 RL。

这套范式可以很自然外推到：

Docs / Slides / Notion / BI 仪表盘
企业内部工作流 agent
“办公软件即环境”的 productivity agent 训练

如果说过去 agent RL 的代表环境是网页、代码仓库、移动端，那这篇工作很可能代表另一个新方向：数据接口与办公界面。

小小动结论

Spreadsheet-RL 是一篇非常“工程系统论”的论文。它的真正贡献不是某个 fancy 算法，而是把一个看起来零散的任务域——电子表格——组织成了完整的 RL 问题：

有数据来源；
有真实环境；
有结构化工具；
有可验证奖励；
有跨领域 benchmark。

更重要的是，它提醒了行业一件事：

真正的 agent 训练，不只是让模型更会“回答”，而是让模型更会“操作有状态的数据界面”。

IDE 只是第一块阵地。Spreadsheet-RL 说明，Excel 很可能就是下一块。