← 返回 PaperDaily
大模型与智能体
中科大新框架:跨表推理成功率暴涨6.9%,表格Agent告别"摊大饼"
表格处理向来是大模型的"老大难":好好的二维表格,硬被拍扁成Markdown字符串,跨表联动全靠蒙。中科大这篇最新研究提出SheetCompass,用层次关系图还原表格的空间结构,配合多智能体协作推理,三大基准全面超车——这波操作,属实有点东西。
龙哥读论文
发布于 2026-08-19 00:20:13
阅读 4
查看原文
原论文信息如下:
打工人应该都有过这种体验:面对一个塞满了销售数据、成本明细、折扣规则、跨表引用的Excel工作簿,光是搞清楚哪张表和哪张表有关联,就得花上半天。好不容易理清楚了,还得写一堆VLOOKUP、SUMIFS公式,稍不留神就引用错单元格,留下一堆#REF!和#VALUE!在表格里对你微笑。
这种活,能不能交给AI干?
理论上当然能。大语言模型的语义理解能力摆在那儿,让它读一读表格、写一写公式,听起来并不比让它写代码难多少。可真到了实际场景,问题就来了:模型读到的表格,和人类看到的表格,根本不是一回事儿。
人类看表格,看到的是二维空间——行和列交叉出一个个单元格,表头定义语义,相邻列构成逻辑分组,不同Sheet之间通过关键字段建立联系。这种空间结构,是Excel作为"可视化"工具的立身之本。
但大模型看到的表格是什么样?是被拍扁的一长串Markdown文本或JSON字符串。二维网格被强行拉成一维序列,原本相邻的列、被合并的表头、行分组的边界全部失去空间临近性;跨表的语义关联也被拆成孤立的文本碎片,模型根本无从重建数据流。这种"信息拍扁"策略,虽然保住了文本内容,却把表格的拓扑结构彻底打碎。人类专家扫一眼就能还原的空间布局,模型在Token流里却要靠猜。
这种损失是双层的。表内层面,二维网格的坐标系统被压成一维序列后,原本相邻的列、被合并的表头、行分组的边界全部失去空间临近性;表间层面,成本表和价格表之间的隐含映射被拆成孤立文本碎片,模型根本无从重建跨表数据流。一句话总结:模型的"迷路",本质上是因为喂给它的表格地形图从一开始就被揉成了一团线。
更麻烦的是,电子表格的复杂性远不止"二维"这么简单。一个真实的工作簿里,往往有多个Sheet,每个Sheet里又可能包含多个独立的表格区域;表头可能是多级合并的,行分组有明确的层级关系;不同Sheet之间通过"客户ID""产品编号"这类关键字段建立隐式关联。这些结构信息,恰恰是电子表格区别于普通文本的核心特征。如果模型在输入端就丢失了这些信息,后续无论怎么优化推理策略,都是在残缺的地图上做文章。
正是看到了这一根本痛点,中科大认知智能全国重点实验室的研究团队提出了SheetCompass框架。它的核心思路非常直接:既然人眼靠空间扫描理解表格,那就把空间结构还给模型。框架先把原始表格转换成统一的层级关系图,再让智能体在这张"结构地图"上做推理。这种"先结构化、再推理"的范式,与直接在大段文本上硬啃的传统方法形成了鲜明对比。
从更宏观的视角看,SheetCompass的提出也反映了AI Agent领域的一个趋势:处理结构化数据时,输入表示的质量往往比模型容量更关键。无论是数据库查询、JSON表格抽取,还是电子表格操作,结构信息的忠实度直接决定了推理的上限。SheetCompass正是沿着这一方向,给出了一个系统性的解决方案。
电子表格推理的困境:扁平化序列丢失了什么?
打工人应该都懂这种崩溃瞬间:领导丢来一个塞满十几个Sheet的工作簿,销售表、成本表、折扣规则、客户信息各据一方,表与表之间靠"客户ID""产品编号"这种暗号互相勾连。想让大模型帮忙理一理,结果它盯着拍扁后的Markdown字符串,愣是看不出"成本表"和"价格表"是一对生死相依的兄弟。
问题出在哪?出在输入表示上。电子表格天生是二维的——行与列交叉出网格,表头定义语义层级,相邻列构成逻辑分组。可现有主流方法在把表格喂给大模型时,普遍采用一种"信息拍扁"策略:把多维结构线性化成Markdown、JSON或CSV。文本内容固然保住了,但表内的拓扑结构碎了,跨表的语义关联也断了。人类专家扫一眼就能还原的空间布局,模型在Token流里却要靠猜。
这种损失是双层的。表内层面,二维网格的坐标系统被压成一维序列后,原本相邻的列、被合并的表头、行分组的边界全部失去空间临近性;表间层面,成本表和价格表之间的隐含映射被拆成孤立文本碎片,模型根本无从重建跨表数据流。一句话总结:模型的"迷路",本质上是因为喂给它的表格地形图从一开始就被揉成了一团线。
更具体地说,扁平化带来的问题至少有三类。第一,列与列的物理相邻关系丢失——在原始表格中,"产品名称"和"产品编号"是紧挨着的两列,模型很容易理解它们的关联;但拍扁成文本后,这两列之间可能隔着几十个单元格的内容,模型需要额外的注意力才能重新建立联系。第二,表头的层级结构被压平——多级表头在原始表格中通过合并单元格体现层级,拍扁后这种层级关系完全消失,模型无法区分"一级表头"和"二级表头"。第三,跨表的隐式关联被切断——不同Sheet之间通过关键字段建立的映射关系,在扁平化后变成两段互不相干的文本,模型只能靠"猜"来还原。
这些问题的本质,是输入表示对物理拓扑和空间语义的忠实度不足。大模型虽然拥有强大的语义理解能力,但如果输入信息本身就残缺不全,再强的推理能力也无济于事。SheetCompass的出发点,正是要解决这一"输入表示"层面的根本缺陷。
SheetCompass核心机制:层次关系图如何重建空间结构?
中科大认知智能全国重点实验室提出的SheetCompass,思路一句话就能说清:既然人眼靠空间扫描理解表格,那就把空间结构还给模型。 框架先把原始表格转换成统一的层级关系图,再让智能体在这张"结构地图"上做推理。
图的构造分两层。顶点集V分为表节点和列节点:一个工作表里可能有多个独立表格,每个表节点对应一个表格;列节点则由"表头名称+若干代表性数据行"共同描述。这种设计刻意绕开逐单元格级别的密集建模,既保留列的语义身份,又塞进了足够的事实上下文。边则分成两大类——结构边(E_str) 描述物理布局,直接由版面解析规则生成,包括"表包含列"的包含边和按水平顺序串联相邻列的邻接边;语义边(E_sem) 描述逻辑关联,专门连接那些在业务上相关、但物理位置上相隔万里的列。
语义对齐是这套方案真正的升级点。对于任意两个列节点,先把表头和数据行拼成特征向量,用预训练的Transformer编码器映射到表示空间,再算余弦相似度。光靠向量相似度还不够稳,论文又请LLM从业务逻辑角度给两列的关系打分(比如判断是否存在主外键关联),两个分数按β加权求和,超过阈值α才建边。这套"向量感知+逻辑校验"双重保险,把误连边的概率压到了很低。
公式1:语义边判定逻辑。当两列特征向量的余弦相似度与LLM逻辑判断分数的加权和超过阈值α时,就在这两列之间建立逻辑连接(ε_ij=1),否则忽略。
图2:SheetCompass框架总览——从原始表格到层级关系图,再到双级记忆与多智能体协作的完整流程。
形式上,SheetCompass把整个电子表格任务建模为:给定表格集合T和用户指令q,求最可能的目标表格序列。公式化的目标函数如下:
公式2:电子表格自动化推理的目标函数。核心是求解在输入表格集合T和用户查询q条件下,最可能生成的目标表格序列A′。
这里需要特别强调的是,层次关系图的设计并非简单的"图表示",而是经过深思熟虑的抽象。顶点集刻意绕开逐单元格级别的密集建模,选择以"列"为基本单位,原因有二:一是列是电子表格中语义最稳定的粒度,表头名称本身就携带了丰富的语义信息;二是列级别的图规模可控,不会因为单元格数量庞大而导致图爆炸。这种"粗粒度"设计,既保留了关键的结构信息,又保证了计算效率。
结构边和语义边的分工也很有讲究。结构边是"确定性"的,直接由版面解析规则生成,不需要任何学习或推理,因此非常可靠;语义边则是"概率性"的,需要结合向量相似度和LLM逻辑判断,虽然存在一定的不确定性,但正是这种边承担了跨表关联的重任。两者互补,共同构成了完整的"结构地图"。
双级记忆与多智能体协作:如何实现闭环推理?
光有一张"结构地图"还不够,智能体还得知道怎么在这张图上干活。SheetCompass引入了双级记忆 系统。第一级叫专家知识记忆,相当于给智能体配了一本"Excel高手操作手册"——里面沉淀了常用公式、常见图表逻辑、历史代码执行中总结出的修复经验。这些知识永久有效,不随任务变化。第二级叫推理经验记忆,对应的是当前任务的"工作日志":智能体在图上走过哪些节点、沙箱代码报了哪些错、校验器发现了哪些不一致,全部动态记录并喂回下一轮Prompt,让每一步新动作都建立在之前的真实反馈之上。
更重要的是,当前任务积累的高质量轨迹并不会被丢弃——成功路径和高价值推理经验会被提取出来,转入长期存储,持续扩充专家知识记忆。这等于让系统在每次任务之后都能"长记性"。
在这个结构化空间和记忆体系的支撑下,三个专职智能体各司其职。探索者(Navigational Explorer) 负责感知和定位:先把用户指令拆解成逻辑依赖的原子步骤,再在层级图上按语义相似度筛选种子节点,通过BFS扩散提取相关子图。这个子图压缩机制很关键——它既锁定了任务相关区域,又避免了整个工作簿的Token爆炸。
公式3:种子节点集合S_i的筛选机制。子任务t_i的向量与图中各节点表示计算余弦相似度,超过过滤阈值λ的节点被选入种子节点集,用于后续的子图扩展。
程序员(Logical Programmer) 则是执行主力,负责把每个原子步骤翻译成Python代码,在带Python解释器和Excel引擎的沙箱环境里运行。它最特别的约束是"实体对齐"——生成代码里的每一个变量,都必须严格锚定在图谱中已验证的节点集上,不能凭空捏造列名或单元格引用。这一步把代码生成的搜索空间牢牢限制在已验证的物理布局里,从根源上减少了幻觉。
最后一个反思者(Critical Reflector) 扮演质检员:把用户指令里的显式约束转成检查清单,逐项核对代码运行后表格的元数据状态。一旦发现实际执行状态与清单不符,就把逻辑矛盾转成诊断笔记,打回给探索者和程序员重新对齐,进入下一轮迭代,直到全部通过或达到最大修正轮次。这套"探索—编程—反思"的闭环,本质上是用多角色分工把长链条推理的风险分散掉——单智能体容易在漫长推理中"自说自话",而这里每一步都有独立的质检信号兜底。
这三个智能体的分工设计,其实暗合了软件工程中的"关注点分离"原则。探索者只负责"找",不负责"做";程序员只负责"做",不负责"查";反思者只负责"查",不负责"改"。每个智能体的职责边界清晰,避免了单一大模型在长链条推理中常见的"角色混淆"问题。更重要的是,反思者的存在为整个系统提供了一个"外部校验信号"——它不参与推理过程,只核对最终结果,因此能有效避免"自洽的幻觉"。
双级记忆的设计同样值得关注。专家知识记忆相当于"长期记忆",沉淀了跨任务的通用经验;推理经验记忆相当于"工作记忆",记录了当前任务的实时状态。两者的结合,让系统既能利用历史经验加速推理,又能根据当前任务的反馈动态调整策略。这种"长期+短期"的记忆架构,在智能体设计中并不常见,但效果显著。
实验验证:三大基准上的全面性能提升
论文在三个公开基准上做了验证:SCB(SheetCopilot Benchmark)覆盖各类电子表格操作任务;SB(SpreadsheetBench)延续TableQA风格,每个任务带三个独立测试用例;SheetRM则聚焦真实场景的表格操作评估。评估指标分两套——SCB和SheetRM用exec@1 (运行时成功率)和pass@1 (输出与标准答案功能等价率);SB用soft/hard两个口径,soft是全部测试用例的平均通过率,hard要求所有用例全部通过才给分。基线选取也很有代表性,从静态生成的Binder、VBA脚本,到动态交互的OS-Copilot、SheetCopilot、SheetAgent全覆盖,Backbone同时用了GPT-4和GPT-5两档。
表1:SheetCompass与多类基线方法在SCB、SB、SheetRM三大基准上的性能对比(%)。↑表示数值越高越好,最优结果加粗,次优加下划线。
结果相当亮眼。GPT-5作为Backbone时,SheetCompass在SCB上pass@1达71.3%,SB的hard限制达22.0%,SheetRM的pass@1达52.3%。其中SB hard限制相比最强基线SheetAgent(15.1%)实现了6.9个百分点的绝对提升,soft限制也提升了6.4个百分点。不止在GPT-5上有优势,换成成本更低的GPT-4时,SheetCompass在三个数据集上的成绩同样是全线领先。这说明框架带来的增益不是"大力出奇迹",而是结构设计本身在起作用。
表2:SheetCompass在三大数据集上的消融实验结果(%)。分别量化层级图、双级记忆、多智能体工作流及其内部组件的贡献。
消融实验的信息量非常大。整体去掉层级图,SCB的pass@1从71.3%跌到56.4%,掉了近15个百分点——这说明层次图不是锦上添花的装饰,而是整个框架的地基。具体到图内部,去掉语义边会让SB hard从22.0%跌到17.1%,印证了复杂跨表任务对隐式逻辑依赖的强需求;去掉结构边则让SheetRM的exec@1明显下滑,说明物理布局信息在真实表格操作中同样不可或缺。多智能体协作的价值也很有说服力,整体移除后SCB pass@1跌了12个百分点以上,单独去掉探索者或反思者都会造成明显下降。记忆模块的贡献相对温和但稳定,其中专家知识对SB hard的影响尤其突出,说明复杂业务约束确实需要显式的规则指导。
图3:单表与多表场景下的性能对比。SheetCompass在多表任务上的优势明显大于单表任务,直击跨表推理这一核心痛点。
单表与多表场景的对比进一步揭示了框架的发力点——SheetCompass在多表任务上的领先幅度远大于单表任务,这正好对应了它在跨表语义建模上的设计优势。研究团队还做了超参数敏感性分析,发现推理轮数阈值、置信度阈值和种子筛选系数这三个关键超参在较宽区间内都保持稳定,说明框架并不依赖于精调参数,鲁棒性有保障。
图4:超参数敏感性分析。从左到右依次为SCB、SheetRM、SB数据集上,推理轮数、置信度阈值、种子筛选系数变化时的准确率表现。
图5:SCB与SB数据集上结构边和语义边的分布统计。SB等复杂数据集上语义边占比更高,印证了跨表语义建模的必要性。
从实验设计来看,论文的评测体系相当完整。三大基准覆盖了从简单操作到复杂跨表推理的不同难度层级;基线方法涵盖了静态生成和动态交互两大类主流范式;Backbone同时使用了GPT-4和GPT-5两档模型,验证了框架的模型无关性。这种"多基准、多基线、多Backbone"的评测设计,使得结论具有较强的说服力。
特别值得注意的是,SheetCompass在SB基准上的hard指标提升最为显著。SB的hard要求三个测试用例全部通过才算成功,这是非常严格的评估口径。能在这种严苛条件下实现6.9个百分点的绝对提升,说明框架不仅提高了"平均正确率",更显著提升了"完全正确"的概率。这背后反映的,正是层次关系图带来的"结构确定性"——模型不再靠猜,而是真正理解了表格的布局和关联。
案例分析与关键启示:从错误检测到逻辑自修复
论文中的案例分析直观展示了这套机制如何落地。一个跨表查询任务,从原始工作簿出发,先构建层级关系图;探索者根据用户指令在图里定位到销售表和折扣表的相关区域;程序员生成查询代码并执行;反思者核对结果时发现某个跨表键值没有对应上,立刻返回诊断信息;下一轮迭代中,探索者重新锚定到正确的列节点,程序员修正代码,最终得到正确结果。
图6:SheetCompass求解跨表任务的完整案例。从电子表格到层次关系图构建,再到多智能体的迭代推理与验证闭环。
这个案例最有价值的启示是:模型处理结构化数据时的障碍,很多时候不是语义理解不够,而是输入表示把关键的空间信息丢掉了。把数据结构完完整整地还给模型,再配合记忆与反馈机制,推理能力的释放往往水到渠成。
更值得关注的是案例中展示的"错误检测—逻辑自修复"闭环。当反思者发现跨表键值不匹配时,它并没有简单地报错终止,而是将诊断信息反馈给探索者和程序员,驱动下一轮迭代。这种"发现问题—定位原因—修正动作"的闭环机制,正是智能体系统区别于传统自动化脚本的核心特征。传统脚本遇到异常只能报错退出,而SheetCompass能够自主诊断并修复,这在实际办公场景中具有极高的实用价值。
从更广的视角看,这个案例揭示了一个重要规律:在结构化数据推理任务中,"表示"往往比"推理"更关键。模型在语义理解上的能力已经足够强大,真正的瓶颈在于如何把结构信息完整地传递给模型。SheetCompass通过层次关系图解决了这一瓶颈,使得后续的推理能力得以充分释放。这一启示,对于其他结构化数据场景(如数据库查询、JSON处理)同样具有参考价值。
龙迷三问
这篇论文到底在解决什么问题? 中科大认知智能全国重点实验室提出SheetCompass框架,将电子表格从扁平字符串转为层次化关系图,保留表内空间布局与表间语义关联,配合双级记忆与三智能体协作循环,在SCB、SB、SheetRM三大基准上全面超过现有方法,显著提
这篇工作最值得看的点是什么? SheetCompass在所有基准数据集上均取得最优性能。在GPT-5骨干下,SCB Pass@1达71.3%,SB Hard Restriction达22.0%,SheetRM Pass@1达52.3%,显著超越最强基线SheetAgent。
这篇工作的边界或风险在哪里? 优点:(1) 创新性地将电子表格建模为层次图,有效保留表内空间布局和表间语义关联;(2) 双级记忆机制结合静态专家知识与动态推理经验,提升推理稳定性;(3) 多智能体协作框架实现感知-执行-验证的闭环。缺点:(1) 依赖LLM进行语义边构建,可能引入额外推理开销;(2) 层次图构建的阈值参数需要针对不同数据集调整;(3) 在SB数据集上的Hard Restriction指标仍偏低(22.0%),说明复杂跨表推理仍有提升空间。
如果你还有哪些想要了解的,欢迎在评论区留言或者讨论~
龙哥点评 论文创新性分数: ★★★★☆
提出SheetCompass框架,通过构建层次关系图将电子表格从扁平序列转化为结构化证据空间,并配合双级记忆机制与多智能体协作流程,实现高保真的电子表格自动化推理。
实验合理度: ★★★★☆
Exec@1、Pass@1、Soft Restriction、Hard Restriction
学术研究价值: ★★★★☆
提出SheetCompass框架,通过构建层次关系图将电子表格从扁平序列转化为结构化证据空间,并配合双级记忆机制与多智能体协作流程,实现高保真的电子表格自动化推理;更关键的是问题定义是否可复用到同类任务。
稳定性: ★★★☆☆
现有材料未提供充分的极端条件、重复运行或扰动测试,稳定性暂按中性评价。
适应性以及泛化能力: ★★★☆☆
现有材料未完整展示跨数据集、跨场景或分布外实验,泛化能力仍需进一步验证。
硬件需求及成本: ★★★☆☆
未明确给出具体计算量,但提到使用GPT-5和GPT-4o-mini作为backbone,温度设为0.2,最大token数4096
复现难度: ★★★☆☆
https://anonymous.4open.science/r/sheetcompass-411C
产品化成熟度: ★★★☆☆
论文验证以研究实验为主,真实部署中的时延、成本、维护和异常场景仍需补充验证。
可能的问题: (1) 依赖LLM进行语义边构建,可能引入额外推理开销;(2) 层次图构建的阈值参数需要针对不同数据集调整;
[1] Panjing He, Mingyue Cheng, et al. SheetCompass: Hierarchical Relation Graphs for Agentic Spreadsheet Reasoning. arXiv:2608.14452, 2026.
[2] SheetCompass开源代码: https://anonymous.4open.science/r/sheetcompass-411C
[3] Zhang et al. SheetCopilot: Bringing software productivity to the next level through large language models. arXiv:2305.02317.
[4] SheetAgent: A Generalist Agent for Spreadsheet Manipulation. arXiv:2403.03686.
[5] Su et al. SpreadsheetLLM: Encoding Spreadsheets for Large Language Models. arXiv:2407.09025.
融会贯通
结合PaperDaily已收录论文可观察到,SheetCompass在表格推理基准上呈现出的增益模式,与同方向上强调"结构化表示+智能体协作"的优秀工作基本一致——尤其是在多表任务上优势更明显。但这里要提醒各位读者:不同工作的数据划分、评测口径和Prompt设置存在差异,现有对比只能作为辅助定位,不宜直接上升为全领域的绝对结论。
从更长远的视角看,SheetCompass踩中的方向很可能是对的:大模型理解结构化数据,瓶颈未必是模型容量,而是输入表示对物理拓扑和空间语义的忠实度。把数据结构原样保留、把推理拆给专职智能体,这套组合拳对AI Agent真正进入办公自动化场景,是一个值得关注的信号。
展望未来,SheetCompass还有几个值得探索的延伸方向。一是将层次关系图扩展到更复杂的表格结构,如数据透视表、命名区域、公式依赖关系等;二是探索更高效的语义边构建方法,减少对LLM逻辑判断的依赖;三是将框架迁移到其他结构化数据场景,如数据库查询、JSON处理、知识图谱推理等。这些方向都有望在"结构感知+智能体推理"的范式下产生新的突破。
*本文仅代表个人理解及观点,不构成任何论文审核或者项目落地推荐意见,具体以相关组织评审结果为准。欢迎就论文内容交流探讨,理性发言哦~ 想了解更多原文细节的小伙伴,可以点击 "阅读原文", 查看更多原论文细节哦!
*本文仅代表个人理解及观点,不构成任何论文审核或者项目落地推荐意见,具体以相关组织评审结果为准。欢迎就论文内容交流探讨,理性发言哦~ 想了解更多原文细节的小伙伴,可以点击 "阅读原文", 查看更多原论文细节哦!