【开源】基于 Harness 工程构建生产级智能表格工作台

【开源】基于 Harness 工程构建生产级智能表格工作台

一、前言

​ 生成式人工智能进入企业软件之后，最先被验证的并不是“模型会不会回答”，而是“系统能不能承担责任”。在真实的经营报表、财务分析、销售汇总和跨部门协作场景中，用户不关心一次演示是否惊艳，而关心同一份数据在同一条指令下是否能得到可复现的结果，关心 AI 对表格做出的每一步修改是否可解释、可回滚、可保存，关心当模型判断不确定时系统是否会诚实停止，而不是用一段看似专业的文字掩盖执行失败。单纯依赖大语言模型 API 或更长的 Prompt，在这种生产环境里是不够的。企业级 AI Agent 真正需要的是一套包裹在模型外部的工程化运行套件，它把概率模型的自由度限制在合适的范围内，把输入、计划、执行、校验、状态同步和失败处理都纳入确定性轨道。

​ 本文讨论的 Harness Engineering，并不是一个抽象概念，而是一种从生产系统中被逼出来的架构方法。它的核心思想是：承认大模型天然不确定，但不能让这种不确定性直接暴露给业务结果。围绕模型建立计划契约、操作注册表、参数验证器、流式执行协议、查询桥接、文件版本控制和模式隔离之后，AI Agent 才有资格进入企业的核心工作流。SheetBot 正是沿着这条路径构建的在线智能表格平台。它以 Excel 作为企业数据工作的入口，以 Univer Canvas 承载在线表格体验，以 FastAPI 和 Claude Agent 组织 Agent 运行时，以 SSE 分发执行指令，以确定性编译器把分析任务转换成可验证的 operations，并通过内存数据库支撑大文件分析场景。

​ 文章将保持从理论到实践、从问题到架构、从架构到复盘的展开方式。前半部分讨论为什么 Harness Engineering 会成为 AI Agent 生产化的关键范式；中间部分结合 SheetBot 的真实架构，说明一个智能表格协同平台如何在时延、准确性、可解释性和状态一致性之间做取舍；后半部分则复盘系统演进中的边界、代价和经验。本文不试图把 SheetBot 描述成一个“什么都能做”的 AI 工具，而是从首席架构师视角回答一个更难的问题：当 AI 开始真正修改企业数据时，系统应该如何设计，才不会把智能变成新的风险源。

二、Harness Engineering 的崛起与范式转变

​ 传统软件工程建立在确定性之上。输入格式被接口定义约束，业务逻辑被代码显式表达，输出结果可以通过单元测试、集成测试和回归测试不断收敛。即使系统足够复杂，工程师仍然可以通过调用栈、日志、事务和状态机找到问题发生的位置。然而，当大语言模型进入业务系统，尤其是进入可以调用工具、修改数据、生成报表、操作文件的 Agent 形态之后，这套确定性世界被撕开了一道口子。模型不是函数，它不会只因为输入相同就天然给出完全相同的执行细节；模型也不是数据库事务，它不会天然理解哪些单元格不能覆盖、哪些字段不能猜测、哪些结论必须引用真实汇总结果。

​ 这正是 Harness Engineering 出现的原因。Harness 一词在软件语境中原本就有测试套件、运行支架、约束环境的含义。放到 AI Agent 系统里，它指的是围绕概率模型构建的一整套确定性外围系统。这个外围系统不幻想消灭模型的不确定性，而是把不确定性关进一组明确的边界内：模型可以理解意图，但不能绕过操作协议；模型可以选择分析维度，但不能自由决定落点和布局；模型可以提出计划，但计划必须通过契约验证；模型可以触发工具，但工具调用必须进入注册表、参数规范化和前后端双重校验。一个生产级 Agent 系统的可靠性，往往不是来自模型本身，而是来自这套外围工程对模型输出的驯化能力。

​ 在 SheetBot 的工程实践中，Harness Engineering 并不是某个孤立功能，而是一套贯穿系统始终的工程纪律。它解决的核心问题是：大模型可以理解人的意图，但不能让它直接接管企业数据的修改权。原因很简单，智能表格场景里的错误往往不是一句话说错那么轻，而是会直接落到单元格、图表、汇总结果和最终汇报文件里。一旦模型把编号当成金额，把标题行当成表头，把空白区域当成有效数据，或者在某个步骤已经失败的情况下仍然告诉用户已完成等等，用户看到的就不再是一次无伤大雅的回答偏差，而是一份可能被继续保存、下载、汇报甚至用于决策的错误结果。因此，SheetBot 的设计不是让模型从头到尾自由发挥，而是把它放在一个受控流程中：先理解用户想做什么，再形成可检查的执行思路，然后由系统判断这些动作是否合理，最后再一步步落到真实表格里。模型负责理解和规划，系统负责校验、执行、同步和兜底。这样做的价值在于，AI 仍然可以处理复杂的分析意图，但每一步都必须经过平台的边界约束，不能随意覆盖原始数据，不能绕过保存规则，不能把不确定的判断包装成确定的结果。对企业级智能表格来说，真正的安全并不只是防止恶意代码，更是防止看似合理但无法复核的错误结果进入业务流程。Harness Engineering 的本质，就是在模型出错之前先建立护栏，让 AI 的能力被释放在正确的位置，而不是把整个工作表交给概率模型冒险。

三、解决企业最后一公里数据痛点与 SheetBot 的诞生

企业数字化建设中有一个长期被低估的事实：越是大型组织，越离不开 Excel。ERP、CRM、OA、HRM 和 BI 系统承担了流程、审批和主数据管理，但真正落到经营分析、临时汇总、部门汇报和跨系统对账时，业务人员仍然要把数据导出成文件，再回到熟悉的表格环境里完成最后一公里。这个过程并不优雅，却足够真实。它包含大量复制粘贴、透视表、公式、格式整理、截图、邮件流转和人工解释，也包含大量隐藏的错误：口径被复制错，公式引用被拖偏，版本在群聊中分叉，报表截图无法追溯来源，业务专家的经验沉淀在个人电脑而不是组织系统里。

传统 BI 试图用统一数据模型解决这个问题，但 BI 更适合稳定指标和固定看板。真实业务每天都会出现临时问题：某个区域为什么下滑，某个渠道是否异常，某批客户是否重复，某份明细能否快速生成汇报，某个模板能否按 Excel 每一行批量生成 Word。这些需求变化快、上下文强、解释性要求高，往往来不及进入正式数仓建模流程。低代码工具降低了一部分门槛，但它依然要求用户理解字段、流程、条件和组件。Excel 的生命力恰恰来自它的低摩擦：用户可以先把数据放进去，再逐步形成分析思路。SheetBot 选择的不是替代 Excel，而是把 Excel 变成一个可被 AI 理解、可被系统执行、可被组织沉淀的在线工作台。SheetBot 的产品形态围绕这个判断展开。普通工作表由 Univer Canvas 承载，用户仍然面对熟悉的行列、公式、筛选、排序、样式和图表；AI 助手不是在旁边给建议，而是可以通过 SSE 接收后端 Agent 生成的 operations，并在前端工作簿模型中逐步执行；大文件场景不强行塞进浏览器，而是进入内存数据库驱动的服务器端分析路径；报表、PPT 汇报、批量转 Word、表单收集、外部连接器和 Skill 技能库则围绕“把一次 Excel 工作沉淀为可复用流程”展开。这个平台的关键价值不在于让用户少写几个公式，而在于把分散在 Excel 文件里的个人经验，转化为有协议、有状态、有边界的组织能力。

从架构角度看，SheetBot 不是一个 Chat 面板加一个表格控件，而是一个以智能表格为中心的多模块协同系统。它既要处理用户手动编辑，又要处理 AI 批量操作；既要支持小文件的交互体验，又要支持大文件的吞吐能力；既要让模型理解自然语言，又不能让模型直接覆盖原始业务数据；既要允许用户随时保存，又要防止并发版本冲突造成数据丢失。正因为 Excel 是企业最后一公里，SheetBot 才必须比普通聊天机器人更克制、更确定，也更工程化。

四、架构的演进：在时延与准确性中不断抉择

AI驱动的在线表格协同平台的架构难点，并不只是“让模型回答得更准”。真正的困难在于把多个时间尺度叠在一起：用户期望界面秒级响应，模型推理需要时间，Canvas 状态持续变化，文件保存有版本边界，大文件查询可能持续数秒甚至更久，而 AI 生成的一组操作又必须逐步落地，不能在最后一瞬间把二十个变更一次性砸到前端。SheetBot 的设计目标是在这些约束之间找到稳定解：简单操作尽可能走确定性执行，复杂分析才进入 Agent；分析结果必须先汇总、再图表、后结论；任何关键步骤失败，都不能让后续样式或文案继续制造“成功假象”。前后架构选型经历了以下几个阶段：

第一阶段：采用基于RAG与API检索机制

首先尝试的方案是基于行业比较流行SpreadJS官方推荐的方案，即利用LangGraph构建Agent，配合MCP Server来实现。其核心逻辑是将SpreadJS庞大的API文档（包含数千个接口）切片存入向量数据库，当用户输入指令时，先通过context7.com或本地RAG进行意图识别，检索出可能用到的API片段，然后将这些片段作为Context喂给LLM，让LLM现场组装出一段可执行的JavaScript代码，最后在前端执行。在实际测试中，这个方案暴露出了致命的缺陷：

• 结果准确性问题：Excel的API之间存在着极强的上下文依赖。例如要设置一个单元格的样式，你可能先要获取当前的Style对象，修改属性，然后再set回去，如果RAG检索时只找回了setStyle方法，而漏掉了getStyle方法，LLM生成的代码就会覆盖掉原有的样式。更糟糕的是LLM经常产生幻觉，捏造出不存在的API参数。在实际测试中，复杂指令（如“创建透视表并按季度分组”）的代码生成成功率不足40%。这就像是让一个不懂外语的人，靠着查字典去写一首十四行诗，结果往往是词不达意。

• 无法忍受的高时延：由于整个链路太长了：用户输入 -> Embedding -> 向量检索（耗时200ms） -> Rerank重排序（耗时100ms） -> LLM阅读长文档并生成代码（耗时3-5秒） -> 前端执行等，用户只是想把一列数字标红，却需要等待近6秒钟。这种“卡顿感”在交互式应用中是毁灭性的体验。

第二阶段：基于Skills动态构建处理脚本沙箱方案

放弃了RAG方案后，我们转向了另一种看似更稳健的路线：基于当下非常流行的skills机制实现，在该场景下此模式类似于OpenAI的Code Interpreter，其逻辑是：后端维护一个Python环境，当用户发出指令时，LLM生成一段Python脚本（使用openpyxl或pandas库），在服务器端直接操作Excel文件，处理完后将新的文件返回给前端。

这个方案解决了准确性问题，因为Python处理Excel的库非常成熟且逻辑严密。但是，在“在线协作”的场景下，它遇到了更底层的问题：

• 状态同步的噩梦： 在线Excel的核心是“流”，而Python脚本处理的核心是文件，当用户A在前端修改了A1单元格，这个变更只是前端内存里的一个Diff。如果此时用户B要求AI“计算A列总和”，后端必须先从前端拉取最新的完整文件保存到磁盘，再加载进Python内存计算，最后再把结果推回去。这不仅带来了巨大的网络开销，因每次操作都要传输整个文件，更导致了严重的并发冲突。如果两个用户同时操作，文件版本瞬间就会乱套。

• 资源消耗的黑洞：想象一下，如有1000个并发用户，后端就需要启动1000个Python进程，每个进程都要加载几十兆的Excel文件到内存中。这种架构的服务器成本是惊人的，且完全无法通过简单的扩容来解决延迟问题。

第三阶段：基于LangGraph开发MCP组合ReAct与ReWOO执行方案

在不断探索过程中，我们也尝试基于Langgraph开发MCP来结合经典的 ReAct 与 ReWOO模式来提升 Agent 的自主规划能力，在实际复杂的业务场景中，这种“边想边做”的机制暴露出了严重的稳定性与性能瓶颈。

• 规划死循环与退出机制失效：ReAct 模式依赖模型在每一步操作后观察反馈并决定下一步，当任务链路超过 3 步（例如：筛选数据 -> 统计求和 -> 格式化 -> 生成图表）时，模型极易陷入逻辑死循环。尽管我们在 Tool Definitions 中明确添加了独立的 finish_task 或 exit 工具，但在多轮交互的上下文干扰下，模型命中该退出工具的概率显著下降。它往往会反复执行“验证数据”或“微调格式”等非必要操作，导致任务无法收敛，用户端表现为长时间的 Loading 却无结果输出。

• 串行执行带来的高延时： ReAct 的本质是串行的：思考(T1) -> 执行(T2) -> 观察(T3) -> 思考(T4)...。每一步都需要等待 LLM 的完整推理和工具的完整回包，在网络波动或模型生成较慢的情况下，一个包含 4 个步骤的简单任务可能需要 10-15 秒才能完成，这种延迟在实时交互的 Excel 场景中是用户无法接受的。

• ReWOO 模式的灵活性缺失：为了解决延时问题，我们尝试切换到 ReWOO (Reasoning WithOut Observation) 模式，即让模型一次性生成所有规划步骤，然后并行或顺序执行，不再依赖中间步骤的观察。这种方式虽然降低了延时，但牺牲了极大的灵活性。一旦第一步的输出结果，比如数据格式与预想不符，后续所有基于该假设生成的步骤都会报错。在数据结构多变的供应链报表中，这种缺乏运行时纠错能力的刚性规划几乎无法落地。

如何破局：基于Claude Agent+MCP自主规划的 Harness Engineering方案

​ 走到这一步之后，架构选择已经不再是“换一个更强的模型”或者“再补一层检索”可以解决的问题，而是必须重新定义模型与系统之间的权力边界。基于 Claude Agent + MCP 自主规划的 Harness Engineering 方案，本质上是把 Claude Agent 放在受控的规划层，让它面向业务目标理解意图、选择路径、组织步骤；同时用 MCP 风格的工具边界、项目内置的操作契约、参数验证器和前端执行协议，把它的自主性限制在可校验、可审计、可熔断的工程范围内。对于 SheetBot 这样的在线智能表格平台，这种架构比前面三个阶段更契合业务现场：它不像 RAG 方案那样要求模型临时阅读庞大的 API 文档并拼装脆弱代码，也不像纯 Python 文件沙箱那样把在线协同退化为后端文件批处理，更不会像传统 ReAct 那样在多轮思考和工具观察中把用户拖进不可预期的等待。它保留了 Agent 对复杂任务的自主拆解能力，又把最终执行交还给 SheetBot 自己掌控的表格引擎、操作协议、数据查询通道、计划校验机制和大文件处理链路，确保 AI 的每一步动作都能落到真实工作簿中，被系统验证、被用户看到、被文件保存，而不是停留在模型生成的一段不可复核的脚本或文本里。换句话说，Claude Agent 负责判断“应该做什么”，MCP 和 Harness 负责规定“只能怎样做”，这正是企业级 Excel 场景所需要的先进性：既允许 AI 理解跨表、跨模块、跨产物的复杂业务目标，又不允许它绕过数据边界、保存边界和执行边界去制造不可复核的结果。

后续为了在时延和准确性之间建立可控路径，SheetBot 采用“前端可视化执行 + 后端 Agent 编排 + 大文件独立引擎”的混合架构。普通模式下，后端 Agent 并不直接改写 Excel 文件，而是通过 Claude Agent 理解用户指令，并输出经过验证的 operations；这些 operations 通过 SSE 分发到前端，由 excelOperations.js 修改 SheetBot workbook JSON，再同步到 Univer Canvas。大文件模式则完全不同，它通过 REST API 将数据加载到服务器端 DuckDB，由内存数据库和 pandas 执行预览、汇总、筛选和下载，避免浏览器承担百万行数据的内存压力。两条链路在模块、API 和执行方式上严格隔离，这是平台稳定性的底层前提。

分层架构 × AI Harness Engineering：将大模型能力约束为确定性、可校验、可审计的业务执行：

图-1：SheetBot 核心技术架构图

​ 在 SheetBot 的整体架构中，时延与准确性的博弈贯穿了每一个核心组件。平台并没有把所有请求都送进长链路 Agent，也没有把模型生成的内容直接写入工作簿。它会先判断用户的指令属于哪一类：有些信息可以从当前表格结构中直接获得，有些问题必须回到完整数据里重新计算，有些分析任务需要先形成计划再执行，有些高频动作则应该直接调用已经沉淀好的技能流程。这个架构不追求表面上的“模型自治”，而追求每一层都有明确的职责和停止条件，让 AI 在该判断的地方判断，在该执行的地方受控执行。

4.1 意图分发器：高频简单请求的极速分流

​ 并非所有 Excel 操作都值得动用完整的大模型推理链。用户让系统把某一列排序、筛选某个条件、查看某列有哪些不同取值，和用户要求系统完成跨表分析、生成汇总图表、继续输出汇报材料，显然不是同一类任务。SheetBot 在入口层做的第一件事，就是判断这条指令到底应该走哪条路径：能由表格引擎直接完成的，就不让模型反复思考；必须理解业务目标的，再交给 Agent 规划；需要扫描完整数据的，先从当前工作簿里得到真实结果；文件规模过大时，则直接切换到服务器端的大文件分析链路。这里的“意图分发器”不是一个孤立的分类按钮，而是贯穿整个系统的交通规则，它决定了每个请求应该进入低延迟的确定性执行、受控的智能规划，还是面向大数据量的专用处理通道。

​ 这种分流带来的收益并不只是降低模型调用成本，更重要的是减少误判空间。一个成熟的系统不应该让模型去猜一列里到底有多少个客户，也不应该让模型临场决定一个排序动作该如何写参数；这些事情应该由表格系统自己完成。模型真正应该参与的是那些需要理解业务目标、拆解步骤和组织结果的复杂任务。SheetBot 把确定的计算留给确定性引擎，把常见流程沉淀为可复用技能，把百万行级别的数据交给专门的大文件引擎处理，让模型站在“规划者”的位置，而不是把它推到每个细碎动作的执行现场。这种分工才是低延迟和高可靠能够同时成立的原因。

4.2 动态上下文裁剪：攻克海量表格的 Token 瓶颈

​ 表格数据对大模型并不友好。一个工作簿可能包含多张表，顶部可能有装饰性标题，真实列名可能藏在第二行或第三行，合并单元格可能让同一个标题被重复读取，日期和数字格式也可能因为历史文件设置而互相污染。用户真正关心的列，往往只占整个文件的一小部分。如果把整张表原封不动转换成文本交给模型，模型不仅会被上下文成本拖垮，也会在大量无关单元格里迷失重点。SheetBot 的做法是先理解这份表格的轮廓：哪一行更像列名，数据从哪里开始，哪些列更像数值，哪些列更像分类，哪些样本能代表当前数据质量。系统先把这些结构信息整理成一份简明的数据画像，再决定哪些内容值得送给模型。

​ 关键是SheetBot 把“事实查询”和“模型推理”拆开了。模型如果想知道某一列有哪些不同值、某个区域的真实内容、某个指标的合计或平均值，不应该根据前几十行样本去猜，而应该让系统回到用户当前正在编辑的工作簿里做一次真实计算，再把计算结果交给模型组织表达。这样一来，上下文裁剪就不只是节省成本的技巧，而成为事实边界的一部分：模型可以基于真实查询结果给出解释，但不能把局部样本包装成全局结论。对于企业报表来说，这一点比回答得流畅重要得多。

4.3 确定性状态机与双向同步：协同冲突下的强一致性保障

​ 在线表格系统最容易被低估的，是用户看到的数据和系统准备处理的数据必须始终一致。SheetBot 的普通模式使用 Canvas 表格引擎提供接近桌面 Excel 的编辑体验，但 AI 执行、页面状态、文件保存和导出并不是天然共享同一份内存。如果用户刚刚在画布里改了一个单元格，而系统没有在发送 AI 指令或保存文件前同步这次修改，就会出现一个很危险的分裂：用户看到的是最新表格，AI 分析的却是旧数据，最终保存下来的又可能是第三种状态。为了解决这个问题，SheetBot 在关键动作之前都会先把画布中的最新内容合并回统一的数据模型，再进入 AI 分析、技能执行、保存或导出流程。

​ AI 生成的修改也不会直接覆盖文件，而是先被转换成一组标准动作，例如创建工作表、写入汇总、设置样式、生成图表、切换当前表等。每个动作在执行前都要被系统识别和检查，确认它作用在哪张表、哪个范围、使用什么数据、是否可能覆盖原始内容。执行过程中，前端会持续接收后端推送的思考状态、执行步骤和完成事件，让用户能够看到任务从分析、执行到结束的过程。更重要的是，一旦关键步骤失败，系统会停止后续动作，而不是继续添加标题、样式和结论，制造一个看似完成但核心结果错误的半成品。这套状态管理让 AI 的执行过程从黑箱生成变成了逐步落地。

4.4 评估与自纠错闭环：用工程确定性驯服模型幻觉

​ 模型幻觉在表格场景里常常不是一句话的错误，而是一次错误操作的连锁后果。它可能选择一列不存在的数据做汇总，也可能把编号列当成金额列求和，还可能把“总计”行放进图表，导致图形看起来完整但解释完全失真。更危险的是，工具执行已经失败，模型却继续输出一段“已完成”的说明，让用户误以为结果可信。SheetBot 的纠错策略不是等错误发生后再让模型反复重试，而是尽量把这些高频风险提前变成系统规则：哪些数据可以聚合，哪些结果必须新建工作表，哪些图表范围需要自动裁剪，哪些失败必须立即停止。

​ 在分析任务中，这种思想体现得尤其明显。模型并不是直接决定每一个单元格怎么写，而是先提交一份分析计划，说明它想围绕哪些维度、哪些指标展开。系统随后检查这份计划是否合理，再把它转换成固定的执行步骤：先生成汇总，再创建图表，最后补充结论和说明。图表生成时，系统还会自动避开空行、标题行和总计行，防止把不该进入图表的数据画进去。真正的自纠错，并不是让模型在错误之后一次次补救，而是把模型最容易犯的错误提前固化为工程约束。能用规则消灭的特殊情况，就不要交给模型临场发挥；能被系统验证的结果，就不要让用户凭感觉相信。

五、为什么选择开源：构建企业级信任与开发者共建的护城河

​ 企业级 AI 应用面对的第一道门槛不是功能，而是信任。SheetBot 处理的是 Excel 文件、经营数据、客户信息、报表结论和汇报材料，这些数据往往比普通聊天内容更敏感，也更贴近企业真实经营。闭源 SaaS 产品可以通过隐私条款承诺安全，但对金融、制造、政企和集团型客户来说，真正有说服力的是可审计、可私有化、可控制。开源在这里不是营销姿态，而是架构信任的一部分：客户可以审查 LLM 调用是否统一经过 Claude Agent，可以确认是否存在直接调用外部大模型的绕行路径，可以检查上传文件是否遵循文件上传分区规范，可以看到普通模式与大文件模式是否严格隔离，也可以验证文件保存是否使用内容版本戳保护覆盖写入等等。

​ 开源的另一个价值，是可以让复杂系统的边界接受外部检验。一个智能表格平台横跨前端 Canvas、Excel 导入导出、Agent 工具协议、DuckDB 大文件处理、PPT/Word 生成、支付、管理后台和多语言界面，很容易在快速迭代中产生局部最优和隐性耦合。只有把架构文档、目录边界、操作注册表、测试策略和部署约束都暴露出来，系统才有机会被更多工程师以不同视角审视。SheetBot 的很多长期规则，例如普通模式和大文件模式禁止互相专稿、UGC 统一存储在项目根存储、分析类任务必须走计划合约、LLM 调用必须通过 Claude Agent，本质上都是开源项目在长期演进中需要写进明面的工程契约。

​ 当然，开源并不意味着把所有未验证的技术故事都包装成事实。一个成熟项目更应该诚实描述当前架构，而不是为了显得先进去堆叠 WebAssembly、容器沙箱、多模型集群、分布式协同等概念。SheetBot 当前真正的技术核心点在于：它把 Excel 工作流中最容易失控的部分做成了可验证管线，把模型输出收敛成计划和操作，把画布状态和保存状态建立了明确同步点，把大文件从普通模式中剥离出去。这些能力没有那么浮夸，却是企业可以长期使用的根基。开源的意义也在这里：让信任建立在代码和边界上，而不是建立在形容词上。

六、项目复盘：在实战中沉淀的几点反思

​ SheetBot 的落地价值不应该被简单描述为“AI 自动生成报表”。真正有价值的是，它把分散在 Excel 里的重复工作拉回到统一工作台，把自然语言意图编译成可执行操作，把报表、PPT、Word、表单收集和连接器串成围绕工作簿展开的业务闭环。对于销售分析、财务汇总、项目台账和经营汇报这类场景，效率提升往往不是来自某一次模型回答，而是来自流程被重新组织：数据不再在本地文件和聊天工具之间反复漂移，分析结果不再依赖个人手工复现，常用动作可以沉淀为 Skill，报表和汇报材料可以从同一份工作簿状态继续生成。

​ 从工程角度看，SheetBot 的实战经验更像是一系列边界问题的修复史。合并单元格的从属值会污染表头检测，ExcelJS 的日期对象可能把普通数字转成 1900 年日期，图表数据范围如果包含总计行会严重失真，操作结果如没有强制注入会让 Univer 停留在旧状态，updated_at 如果被误用为内容分片版本戳会造成伪并发冲突。这些问题单独看都不像宏大的 AI 架构的范畴，但它们才是生产系统每天会遇到的真实风险。一个平台是否成熟，不取决于它能否在理想数据上跑通演示，而取决于它能否在脏数据、旧文件、异常格式、网络中断和用户连续操作中保持可解释的行为。

6.1 反思1：在线表格真源切换的复杂度被低估

​ 早期我们低估了从传统 DOM 网格迁移到 Univer Canvas 后带来的状态复杂度。Canvas 提供了更接近桌面 Excel 的交互体验，但它也让系统从“React 状态即表格状态”变成了“Canvas 内部状态、SheetBot JSON、React workbook、AI operations、文件保存”之间的多方同步。只要某个入口忘记 flushToSheetbot，用户刚刚在画布上做出的修改就可能没有进入 AI 分析或保存流程；只要 workbookJsonAdapter 漏掉条件格式、冻结窗格、隐藏行列、合并单元格，用户看到的表格和系统保存的表格就会出现偏差。

​ 这个教训让我们重新理解了在线表格平台的状态管理。所谓“真源”不是一句口号，而是一组严格的同步协议。用户编辑时，Univer 是真源；AI 执行、Skill 运行、保存、导出、未保存检测之前，SheetBot JSON 必须通过 flush 成为最新真源；后端文件保存成功后，前端还要同步 accessed_at 版本戳，避免下一次保存用旧版本触发冲突。表格系统最难的不是画出网格，而是让每一个入口在同一份状态上达成一致。

6.2 反思2：人机协同下的失败边界比预期更细

​ 在 Agent 参与表格修改之后，失败不再只有“请求失败”这一种形态。更危险的是局部失败：汇总生成了，但图表没生成；图表生成了，但数据范围包含总计行；工具调用失败了，但模型文本仍然说完成；保存被并发保护拦截了，但用户以为只是普通提示。这些局部失败如果没有被及时熔断，就会在界面上形成一种虚假的完整性。用户看到标题、样式和结论都在，却不知道关键中间产物已经错了。

​ SheetBot 后来的策略是把成功定义得更严格。分析并出图的请求必须实际产生 create_chart；批量操作中关键步骤失败后不再继续执行后续样式和文案；前端执行状态有 thinking、executing、done、error 的可视化反馈；后端错误文案不向用户暴露堆栈，但也不能承诺无法兑现的“稍后重试”；文件保存冲突必须阻止覆盖，而不是为了流畅体验强行写入。这些设计看上去会让系统更保守，但企业软件宁可保守，也不能伪成功。

6.3 反思3：对模型“隐式假设”的捕获不足

​ 大模型最擅长补全上下文，也最容易在表格场景中补出不存在的上下文。它可能默认第一行就是表头，默认数值列都适合求和，默认日期格式统一，默认数据范围没有空行，默认字段名具有某种业务含义。真实 Excel 文件恰恰相反：第一行可能是合并标题，第二行才是列名；数量列可能被误设为日期格式；客户 ID 可能看起来像数字但不能聚合；同一工作簿里可能混有明细表、汇总表和分析表。如果这些隐式假设不被 Harness 捕获，模型生成的计划越完整，造成的错误就越隐蔽。

​ 因此，SheetBot在研发阶段把“输入去硬编码、输出强约束”写成了系统原则。输入侧不靠行业词典猜字段语义，而优先使用数据分布、数值密度、去重率、格式模式、样本稳定性来判断可操作性；输出侧则必须硬编码协议，包括固定分析顺序、固定目标表、固定失败策略、固定覆盖区域和幂等清理规则。这个原则听起来反直觉，却非常关键：输入世界是混乱的，系统不能假装理解所有行业；输出世界必须有秩序，否则用户无法复核和复用。

七、核心模块演进与对比

​ SheetBot 的演进像是一次权力边界的重新划分，从早期方案让模型负责找接口、写代码、改文件、观察结果；当前方案则让模型负责理解目标和组织计划，把具体执行交给平台已经定义好的表格引擎、操作协议、查询机制、保存机制和大文件处理链路。下面的对比表格可以说明一个生产级系统如何从“模型能做什么”，逐步走向“系统允许模型怎样做”，这正是Harness的本质。

八、结语：迈向确定性的未来

Harness Engineering 并不是削弱大模型，而是让大模型进入它真正适合的位置。一个成熟的企业 AI 系统不应该让模型直接面对所有复杂性，也不应该把所有不确定性都推给用户承担。模型应该负责理解意图、提出计划、组织解释；工程系统负责验证计划、执行操作、同步状态、保护文件、处理失败。这个分工越清晰，AI Agent 就越不像一个随机助手，越像一个可以被纳入生产流程的系统成员，从SheetBot 的实践说明，智能表格协同平台的壁垒并不只是“能聊天”或“能生成图表”，而在于它是否真正理解企业表格工作的复杂性。Excel 文件不是普通文本，它有工作表、合并单元格、格式、公式、图表、筛选、隐藏行列、版本和用户操作历史；AI 分析不是普通回答，它会修改数据、创建结果表、生成图表、影响汇报材料；保存也不是普通上传，它涉及内容版本、并发保护和用户信任。只有把这些细节放进架构，平台才可能从演示工具走向生产系统。

未来的智能表格平台不会是传统 Excel 的简单替代，也不会是聊天机器人加文件上传的轻量组合。它更像一个业务数据工作台：底层承载 Excel 的自由度，中层用 Harness Engineering 约束 Agent 的行为，上层把分析、报表、汇报、收集、连接和技能沉淀成组织能力。AI 的价值不在于替系统制造更多不可控的魔法，而在于被工程化之后，稳定地完成那些过去依赖人工经验、难以复用、难以审计的工作。确定性不是 AI 的反面，确定性是 AI 进入企业生产环境的门票。

九、项目开源与交流

​ SheetBot 已在 Gitee 开源，项目地址为：https://gitee.com/yorkoliu/sheetbot 。如果你关注企业内部 Excel 工作流改造、AI Agent 工程化落地、在线表格协同、大文件分析、报表与汇报自动化，欢迎通过开源仓库了解项目实现，也欢迎提交 Issue、参与二次开发或反馈真实业务场景中的问题。对一个仍在快速演进的生产级 AI 应用来说，代码开放只是第一步，更重要的是让真实用户、开发者和企业技术团队共同参与边界打磨：哪些能力应该交给模型，哪些能力必须由系统硬约束，哪些业务流程值得沉淀为可复用能力，这些问题只有在真实场景中反复碰撞，才会得到可靠答案。

本文首发于微信公众号，同步收录于比特意图实践洞察。