从50%到92%：让AI智能体精通电子表格的实战方法论

文章正文

在AI Engineer大会上，工程师Nunu分享了团队历时四个月的技术攻坚：如何让编码智能体（Coding Agent）像操作Python、JavaScript一样熟练地处理电子表格。他们将一个金融分析基准测试的准确率从50%提升至92%。这套方法论，对所有构建垂直领域AI智能体的开发者都有重要参考价值。

编码智能体（Coding Agent）是当前AI工程领域最活跃的研究方向之一，其核心是赋予大语言模型调用外部工具、执行代码并根据反馈迭代的能力。垂直领域AI智能体则是在此基础上，针对特定行业（如金融、医疗、法律）的数据格式、业务规则和专业术语进行深度定制的系统——它们不追求通用能力，而是在特定领域内达到接近或超越人类专家的操作水准。从50%到92%的准确率跃迁，正是垂直领域AI工程化典型挑战与突破路径的缩影。

为什么电子表格对AI异常困难

电子表格看似简单，但对大语言模型（LLM）而言却是一项被严重低估的任务。人类打开Excel时，凭直觉就能识别出结构——这里是营收表、那里是假设条件、旁边是图表。这是一种高度视觉化的理解方式。

LLM完全看不到这些。当你问它"营收是多少"时，它必须先搞清楚：你指的是净营收还是毛营收？是哪个季度、哪一年的？这个数字是直接输入的还是公式计算出来的？这些对人类来说理所当然的判断，对模型而言都需要显式推理。

这一困难有其深层的技术根源：LLM以token序列的形式感知世界，而电子表格本质上是一个二维甚至多维的关系型结构——单元格之间通过坐标引用相互依赖，同一数值可能同时扮演输入变量、中间计算结果和最终输出的角色。人类通过视觉皮层的并行处理，可以瞬间识别表格的区域边界和数据流向；而LLM必须将这种二维结构「展平」为线性序列才能处理，这个展平过程本身就会丢失大量空间关系信息。

更深层的挑战来自Excel公式体系的复杂性。Excel公式语言（如VLOOKUP、INDIRECT、数组公式、动态数组函数SPILL等）构成了一套独立的领域特定语言（Domain-Specific Language，DSL），其语义规则与LLM训练语料中的自然语言和通用编程语言存在显著差异。DSL是一种针对特定应用领域设计的计算机语言，与Python、Java等通用编程语言不同，DSL牺牲了通用性来换取领域内的表达简洁性和精确性——SQL是最广为人知的DSL之一，而Excel公式语言则是全球用户量最大但学术关注最少的DSL之一。例如，Excel中的隐式交叉运算符（Implicit Intersection Operator）、1900年日期系统的历史遗留Bug（将1900年2月29日错误认定为闰日）、以及跨工作表的三维引用语法，都是高度领域特化的知识，在通用代码语料库中出现频率极低，导致模型理解和生成这类公式的能力远弱于处理Python或JavaScript的能力。

正是这种"结构隐性化"的特性，让团队在早期尝试中屡屡碰壁。

走不通的那些死胡同

团队的第一次尝试是将工作拆分给三个智能体，核心是一个"编辑智能体"，遵循"定义终态—制定计划—执行—验证"的五步流程。这种架构确实改变了错误的性质：原本智能体会在构建财务模型时犯错，现在错误更多发生在规划阶段，相对容易纠正。但这套架构最终过于僵化——发现（Discovery）环节只在开头运行一次，无法回溯，不同智能体之间的上下文也无法流通。

这一困境折射出多智能体（Multi-Agent）系统的普遍挑战。多智能体架构的理论基础来源于分布式系统和微服务思想：将复杂任务分解给专职智能体，通过协调层整合结果。然而每个子智能体在独立的上下文窗口中运行，智能体之间的信息传递需要显式序列化，而人类认知中大量隐性的「工作记忆」（Working Memory）在这个传递过程中会丢失。认知心理学中的工作记忆理论指出，人类在执行复杂任务时依赖一个容量有限但高度灵活的临时存储系统——它不仅保存数据，还维护数据之间的关联关系和任务的进行状态。当多智能体系统通过消息传递来模拟这一机制时，只有被显式编码进消息的信息才能传递，而大量隐性的上下文关联则会在「翻译」过程中悄然消失。

「发现环节无法回溯」的问题，本质上是有向无环图（DAG）式工作流在面对动态、探索性任务时的固有缺陷——真实世界的电子表格分析往往是非线性的，需要频繁根据新发现修正假设。有向无环图（Directed Acyclic Graph，DAG）是一种图论结构，其节点代表计算步骤，有向边代表依赖关系，无环意味着不存在循环依赖。DAG式工作流在Airflow、Prefect等数据工程工具中广泛应用，擅长处理步骤明确、依赖清晰的批处理任务；但当任务需要根据中间结果动态调整路径时，其固定的拓扑结构就成为了瓶颈。这也促使业界开始重新审视「单一强大智能体+丰富工具」vs「多个专职智能体」的取舍边界。

随后，团队对"如何把电子表格呈现给LLM"进行了漫长探索，几乎尝试了所有能想到的表示方式：

• SQL：训练数据丰富，智能体本应擅长处理结构化数据，但实践中并不奏效；
• XML：这正是Excel文件本身的存储格式（.xlsx文件本质上是一组XML文件的ZIP压缩包），看似天然合适，同样宣告失败；
• CSV/TSV视图：作为唯一交互方式效果不佳，但作为整体方案中的辅助组件却被频繁采用；
• HTML：引入了布局和格式的概念，方向正确，最终促使团队构建了一个渲染引擎，让智能体能"看到"渲染后的表格图像。

这些表示方式的探索，本质上是在寻找一种「信息密度与模型可理解性」之间的最优平衡点。XML虽然忠实保留了Excel的原始结构，但其冗长的标签语法会消耗大量token配额，且层层嵌套的语法树与电子表格的二维直觉相去甚远。HTML的成功方向则揭示了一个重要洞见：当文字表示无法充分传达空间关系时，将内容渲染为图像让模型通过视觉编码器感知，有时比任何文本序列化方案都更为有效。这些看似失败的尝试并非毫无价值——每一个都有其理论合理性，其中两种表示方式最终成为了REPL方案中的有效组件。

核心突破：单一REPL工具架构

真正的转折点，是用单个Node.js REPL工具替换掉此前累积的约15个工具。原来那15个工具，全都变成了智能体可以在同一次REPL调用中自由组合的JavaScript函数。

为什么这样设计

REPL（Read-Eval-Print Loop，读取-求值-输出循环）是一种交互式编程环境，最早可追溯至1960年代Lisp语言的交互式解释器——当时MIT的John McCarthy为了便于调试Lisp程序，设计了这种"输入一行、立即执行、立即看到结果"的交互方式，此后被Python、Node.js、Ruby等几乎所有现代动态语言所继承。其核心特征是「持久化状态」：每次执行的结果会保留在内存中，后续调用可以直接引用前序结果，形成连续的推理链条——这与无状态的函数调用（如REST API每次调用都从零开始）形成根本区别。

在AI智能体领域，REPL架构之所以对LLM友好，原因是多维度的。首先，现代大模型在代码生成方面接受了GitHub、Stack Overflow等平台的海量训练数据，能够熟练地通过编写脚本来表达复杂的操作意图——代码天然是一种精确、可组合、无歧义的「工具调用语言」。其次，Node.js的V8引擎通过vm模块提供了天然的沙箱隔离能力，可安全执行模型生成的代码而不污染宿主环境，同时通过JavaScript的异步特性（Promise、async/await）支持并发操作。最后，这种「用代码表达工具调用」的范式，本质上是将工具接口的设计从「名词（工具列表）」转向「动词（可组合的函数）」，极大降低了工具组合的认知负担。值得注意的是，工具数量的膨胀本身就是一个危险信号：当工具schema超过约10个时，研究表明LLM在工具选择上的准确率会显著下降，因为模型需要在更大的决策空间中进行选择，而有限的注意力机制使其难以同时关注所有工具的细微差别。

为什么选JavaScript？团队需要一门在沙箱中易于运行、且LLM高度熟悉的脚本语言，Python同样可行，只是选了JavaScript。而真正处理电子表格的底层逻辑，则用完全不同的C#实现。这正是该架构的精妙之处：用脚本语言承担智能体交互职责，用合适的语言处理实际文件。

改造前后的对比极为鲜明。改造前，智能体探索一份表格往往需要10到15次工具调用，且经常超时——因为是顺序执行的，即便并行调用也无济于事，因为无法合并结果。改造后，智能体可以在单次调用中组合多个操作，同时获得所有结果。

REPL与Code Mode的关键差异

"Code Mode"的概念并不陌生——Anthropic的API和Cloudflare都讨论过，核心思想是把多个工具调用合并为一次。但REPL更进一步，关键区别在于持久化状态：智能体调用一次REPL、定义几个变量、查看结果、进行推理，下次调用时这些变量依然存在，可以在已有工作基础上继续构建。

团队观察到一个有趣现象：纯Code Mode下，智能体常常写出约50行的长脚本；而有了REPL语义后，它们倾向于写更短的脚本，从而在每步操作之间穿插更多推理。这种"交错式"工作方式，往往能让智能体更快得到更好的答案。这与认知科学中的「分块学习」（Chunked Learning）现象类似——将复杂任务分解为小步骤、在每步之间进行反思和调整，比一次性执行长流程更容易产出高质量结果。分块学习理论由认知心理学家George Miller在1956年提出，后被Anders Ericsson在刻意练习（Deliberate Practice）研究中进一步发展：专家与新手的核心区别不在于记忆容量，而在于更高效的分块方式和更密集的反馈循环。REPL的交错式工作方式，实质上是在人工智能系统层面复现了这一认知优化机制。

扩展能力也因此变得极为简单：新增一个方法（比如探索公式依赖关系），只需在JavaScript REPL中暴露该方法，并在TypeScript类型定义文件中声明并放入prompt即可，无需再向工具schema堆砌更多工具。

反馈验证循环：智能体质量的底层保障

编写代码时，允许智能体运行编译器、linter和测试用例并基于结果迭代，其表现会显著优于无反馈状态。电子表格与编程高度相似——不允许检查和验证，就不可能产出高质量结果。

为此，团队构建了两个核心引擎：

• 公式引擎：负责准确计算公式；
• 渲染引擎：将指定区域内容渲染为带有完整格式和布局的图像，作为"真相之源"。

这套验证循环让智能体能确认操作是否正确，出错时即修正公式或格式。但有一个关键前提：引擎必须高保真。

这一要求背后有深刻的工程逻辑。Excel公式引擎内置了400余个函数，并存在大量涉及浮点精度、日期系统（Windows版Excel使用1900日期系统，Mac版历史上使用1904日期系统，两者相差1462天）、隐式交叉运算符等高度特化的边缘行为。更棘手的是，Excel在某些情况下会故意保留已知的历史Bug（如将1900年视为闰年）以维持向后兼容性——任何试图「修正」这些行为的自研引擎都会与真实Excel产生计算偏差。这一现象在软件工程中被称为「Hyrum定律」（Hyrum's Law）：当一个API有足够多的用户时，无论接口契约如何规定，所有可观察到的系统行为都会被某些用户所依赖——包括那些原本是bug的行为。Excel的日期系统bug已有数十亿份电子表格依赖其错误行为，「修正」它反而会破坏向后兼容性。

如果自研引擎仅覆盖常见函数，智能体在测试阶段学到的「正确行为」在生产环境中会因函数行为差异而失效，造成「分布偏移」（Distribution Shift）——这是机器学习中的经典问题，指训练环境与部署环境的数据分布不一致导致模型性能下降。这也解释了为什么50%覆盖率的引擎反而更差——不完整的验证比没有验证更危险，因为它给智能体提供了错误的置信信号，导致模型在错误路径上过度自信地继续执行。验证循环的质量，完全取决于其背后引擎的完整度。

什么会变，什么不会变

REPL本质上是一个接口——是向智能体呈现工具的方式。之所以REPL是当下最优选择，是因为顶尖模型目前最擅长的就是编程。但这未必永远成立：各大实验室正大力投入"计算机使用"（Computer Use）能力，未来模型或许能像编程一样熟练地用鼠标键盘操作，届时REPL可能就不再是最佳接口。

计算机使用（Computer Use）是指让AI模型直接操作图形用户界面——通过截图感知屏幕状态，通过模拟鼠标点击和键盘输入执行操作，就像一个真实的人类操作员一样。Anthropic于2024年10月率先发布了Claude的Computer Use能力，随后OpenAI的Operator、Google的Project Mariner相继跟进。这一能力路线的成熟，将使AI智能体能够直接与任何图形软件交互，从根本上绕过API集成的复杂性——但同时也引入了新的可靠性挑战：GUI操作比代码调用更脆弱，界面变化、加载延迟、弹窗干扰都可能导致操作失败。

不会改变的，是对验证循环的需求——这才是更持久的底层规律。团队在项目进行期间经历了四五次模型迭代，每次都发现：模型能力越强，从验证循环中获得的收益就越大。这一现象有其内在逻辑：能力更强的模型能够更有效地利用验证反馈来修正错误、深化推理，而能力较弱的模型即便得到反馈，也可能无法正确解读并作出有效调整。这与强化学习中的「奖励信号利用效率」概念相呼应——更强的策略网络能从相同的奖励信号中提取更多有用的梯度信息。

从50%到92%的跃迁中，REPL贡献最大（直接从50%跳至74%），随后的领域知识注入、模糊搜索、公式追踪、系统prompt优化和bug修复则层层累积。值得一提的是，这套方案几乎消除了超时问题——原本频繁触发五分钟超时限制的任务，因效率大幅提升而实现零超时。

领域知识注入与评估体系的实战经验

领域知识的本质是"提醒"而非"教学"

向prompt中注入领域知识是贯穿所有迭代、始终有效的优化手段。这并非因为LLM不懂营收或ARR（Annual Recurring Revenue，年度经常性收入）的含义，恰恰相反——它们知道的太多，需要被"框定"到当前任务的重点上。现代大模型在预训练阶段已经吸收了大量金融、会计领域的知识，但这些知识在推理时以概率方式竞争激活，缺少明确的任务约束时，模型可能激活与当前场景不完全匹配的知识路径。这一现象在注意力机制（Attention Mechanism）层面有其解释：Transformer架构中的自注意力层通过计算查询向量（Query）与键向量（Key）的相似度来决定哪些上下文信息获得更多权重——显式的领域知识prompt本质上是在引导注意力分配，使模型将有限的计算资源集中于与任务最相关的知识区域。领域知识prompt的作用，正是通过显式提示来提高相关知识路径的激活概率，抑制无关联想。这种领域知识prompt具有极强的可移植性，几乎原封不动就能适配不同的工具方案。

构建可信赖的评估体系

团队最初只使用"LLM作为裁判"（LLM-as-Judge）的评估方式。这种方法由斯坦福HELM、Chatbot Arena等研究项目推广，核心思想是用一个功能更强大的模型（如GPT-4o、Claude 3.5 Sonnet）来评估另一个模型的输出质量，优势在于可以处理开放性输出和主观质量维度，且无需人工标注大量数据。

然而随之而来的问题是「评估器漂移」（Evaluator Drift）：当底层评估模型版本更新（如从GPT-4到GPT-4o）、prompt被微调，或模型在不同上下文长度下产生不同评分倾向时，分数的纵向可比性会严重下降——当分数变化时，你无法判断是智能体变了还是评估器本身变了。研究显示，同一模型在不同prompt措辞下的评分结果可能出现高达15-20%的偏差，使得基于LLM-as-Judge的A/B测试结论充满不确定性。LLM-as-Judge还存在另一个系统性偏差：「位置偏差」（Position Bias）——研究发现，当LLM被要求比较两个回答时，它倾向于认为先出现的那个更好；以及「风格偏差」（Style Bias）——更长、措辞更正式的回答往往获得更高评分，即便内容质量相当。这些偏差会在迭代优化过程中被系统性地放大，导致团队优化的是评估器的偏好而非真正的任务质量。

为此，他们转向尽可能使用确定性对比——借鉴软件工程中单元测试的思想，给定固定输入，验证输出是否精确匹配预期值，结果是0/1的布尔量，不存在歧义。例如用一份包含既定输入输出的"黄金表格"（Golden Table）作为黑盒，把相同数字输入模型生成的表格，检验输出是否一致。这种混合评估策略——对可量化的输出使用确定性验证，对无法结构化的输出才使用LLM评判——是当前AI产品工程中逐渐形成的最佳实践共识。

另一条重要经验是：智能体的"推理失败"往往实为基础设施的bug。可能是代码本身有bug、prompt中的示例写错了（模型忠实地照错了做），或是工具报错后模型陷入重试循环。深入检查执行轨迹（trace），常能发现真正可以修复的根本问题。执行轨迹（Trace）是对智能体每一步操作的完整记录，包括工具调用的输入输出、中间推理步骤、token消耗和延迟数据。Langsmith、Langfuse、Arize Phoenix等可观测性工具正是为此而生——它们将原本黑盒的智能体执行过程可视化，使调试从「猜测」变为「诊断」。这与软件工程中「先排除环境问题再怀疑算法」的调试原则高度一致——在归因于模型能力不足之前，应当首先确认观测到的失败不是由工具链、数据管道或评估框架本身的缺陷所造成的。

可迁移到其他领域的方法论

这套经验的价值不止于电子表格，以下原则适用于构建任何垂直领域AI智能体：

1. 如果智能体在做大量顺序或并行工具调用，你其实已经发明了一门糟糕的脚本语言——不如直接给它一门真正的语言（Code Mode或REPL）。
2. 反馈验证循环至关重要。若领域内没有现成的验证工具，值得专门投入时间构建渲染引擎、计算引擎等基础设施。
3. 接口极为重要，且需要随模型能力演进持续重新审视。
4. 不要低估规划和"三思而后行"的价值，简单的优化也能带来显著收益。
5. 领域知识的核心是提醒而非教学——提醒模型该重点关注什么，而非从零灌输知识。
6. 评估尽量确定性化，并始终检查执行轨迹和底层管道，因为智能体的困惑有时只是基础设施的bug。

从电子表格实战中提炼的这套经验，为构建任何垂直领域AI智能体提供了一份务实且可操作的方法论路线图。