如果企业真的要在业务系统中加入“会理解业务目标、会操作表格、会生成结果、还能接受人工复核”的表格智能体，底层架构应该怎么设计？

我的判断是：表格智能体不是“把大模型接到表格界面上”这么简单。

它应该是一个由电子表格引擎（Spreadsheet Engine）、工具系统、文件与外部数据、智能体编排、权限控制、执行回滚和人工复核组成的工程系统。

【关键判断 01】企业真正需要的不是会聊天的表格，而是能安全执行任务、保留过程、支持回滚、接受人工复核的表格智能体。

1. 表格智能体不是聊天框，而是执行系统

很多团队第一次做“AI + 表格”时，容易从聊天框开始。

用户在右侧输入：“帮我分析这张销售表。”AI 返回一段文字：“华东区增长明显，华北区利润率偏低。”

这个体验有价值，但还不是企业级表格智能体。

真正的表格智能体不应该只回答问题，而应该能完成任务：

• 读取指定工作表和区域；
• 理解表格中的数据、公式、图表和业务字段；
• 生成新的公式、透视分析或图表；
• 修改工作簿内容；
• 导入历史 Excel 文件或导出结果；
• 把执行过程记录下来；
• 在高风险操作前请求人工确认；
• 出错时能够撤销或回到执行前状态；
• 最终把结果交还给业务人员复核。

这就是“对话”与“执行”的差异。

根据 SpreadJS AI 智能体中文官网页面，SpreadJS AI 智能体强调为业务系统中的表格赋予对话智能，并提供 50+ 内置工具、支持任意主流大模型、闭环执行、可直接嵌入业务系统等能力。

这几个词放在一起，说明了正确方向：表格智能体的核心不是“模型更聪明”，而是“模型能被放进一个可治理的执行闭环里”。

2. 基础层：SpreadJS 承担电子表格运行环境

表格智能体的底层，不应该是一个临时拼出来的 Grid，也不应该是一组散乱的 DOM 操作。

它需要一个成熟的电子表格引擎（Spreadsheet Engine）。

SpreadJS 的基础角色可以概括为：为表格智能体提供工作簿对象、工作表对象、单元格与区域、公式、样式、图表、数据透视表、文件导入导出、打印导出和浏览器端交互基础。

从 SpreadJS 官方文档看，SpreadJS 的默认对象模型可以理解为：

Workbook -> Worksheet -> Range / Cell / Table / Shape

这非常适合作为智能体工具系统的底座。因为 AI 不能直接“随便改页面”，它需要面向明确对象执行动作：读哪个工作表、写哪个区域、生成哪条公式、创建哪张图表、导出哪个文件。

根据 SpreadJS 中文官网，SpreadJS 是纯前端表格控件，可嵌入系统开发在线 Excel；支持在线导入导出 Excel、CSV、JSON 等文件，支持 PDF 导出、打印及预览，并兼容 450 种以上 Excel 公式。

这些能力在普通表格应用里是产品能力；在表格智能体架构里，它们会变成 AI 可以调用的执行能力。

3. 工具层：不要让大模型直接操作表格

表格智能体的核心设计原则是：不要让大模型自由操作表格。

更稳妥的做法，是把 SpreadJS 能力封装成一组可控工具。AI 只能选择工具、填写参数、等待执行结果，而不是直接生成一大段不可控代码去改工作簿。

工具层至少应该具备三类工具：

工具类型	示例	主要作用
读取工具	读取工作表列表、读取区域、读取公式、读取表格结构	给 AI 提供上下文
修改工具	写入值、写入公式、设置样式、创建图表、生成透视表	执行表格操作
交付工具	导入 Excel、导出 Excel、导出 PDF、生成快照	连接文件与业务流程

工具定义可以是这样的伪代码：

type SpreadsheetTool = {
  name: string
  description: string
  inputSchema: object
  riskLevel: 'read' | 'write' | 'export' | 'destructive'
  requiresApproval: boolean
  execute: (context, input) => Promise<ToolResult>
}

几个典型工具可以这样规划：

const tools = [
  readRange,          // 读取指定 Sheet 和区域
  writeValues,        // 写入一组值
  writeFormula,       // 写入公式
  createChart,        // 基于区域生成图表
  createPivotTable,   // 基于数据表生成透视分析
  importWorkbook,     // 导入 Excel / SJS 等文件
  exportWorkbook,     // 导出 Excel / PDF
  createSnapshot      // 执行前生成快照
]

这里的重点不是这些名字本身，而是工具治理思路：每个工具都必须有明确输入、明确边界、明确风险等级、明确执行结果。

4. 编排层：把“用户目标”拆成可控步骤

用户不会说：“请读取 Sheet1!A1:G200，然后生成数据透视表，再设置字段，再导出 PDF。”

用户更可能说：

帮我把这个销售明细整理成按区域、产品和季度汇总的分析表，再生成一张趋势图，最后导出给销售总监。

表格智能体要做的，是把自然语言目标拆成可执行步骤：

1. 识别当前工作簿中有哪些工作表和数据区域；
2. 判断销售明细表的数据结构；
3. 询问或推断汇总维度；
4. 创建透视分析；
5. 生成趋势图；
6. 检查公式和图表引用是否有效；
7. 请求用户确认导出；
8. 导出 Excel 或 PDF；
9. 保存执行日志。

这个过程里，AI 的价值在于理解意图和组织步骤；SpreadJS 的价值在于提供稳定的工作簿、公式、图表、数据透视表和导出能力。

这也是为什么表格智能体不能只看模型能力，还要看底层电子表格引擎（Spreadsheet Engine）是否能承接执行。

5. 数据层：连接 Excel 文件、业务系统和外部数据

企业表格智能体很少只面对一张孤立表格。

它通常要连接三类数据来源：

• 历史 Excel 文件；
• 业务系统数据；
• 用户临时补充的数据和假设。

SpreadJS 在这里承担两个关键角色。

第一，它让历史 Excel 资产进入 Web 业务系统。企业过去沉淀的模板、报表、预算表、检测报告和报价单，可以通过导入能力进入在线工作簿，再由 AI 进一步理解和操作。

第二，它让 AI 生成的结果回到可交付文件。用户不只是看一段分析文字，而是要拿到可以继续编辑、复核、流转和归档的 Excel、PDF 或系统结果。

从工程角度看，数据层要处理的不只是“读数据”，还包括：

• 文件来源是否合法；
• 数据字段是否匹配；
• 公式和格式是否保留；
• 导出后是否仍可编辑；
• 是否需要保留操作日志；
• 是否需要把结果回写业务系统。

这些问题都不应该丢给大模型自由发挥，而应该通过工具层和业务规则约束。

6. 安全层：确认、回滚、审计和权限不能后补

表格智能体真正进入企业系统后，最大的风险不是“AI 不够聪明”，而是“AI 改得太快”。

如果一个智能体可以写公式、改参数、删数据、生成报表、导出文件，那么它就必须受到治理。

我建议至少做四层安全控制：

控制项	作用
权限控制	不同用户只能操作自己有权限的工作簿、工作表、区域和工具
执行确认	写入、导出、删除、批量修改等操作必须让用户确认
快照与回滚	高风险操作前保存状态，失败或用户不满意时可以恢复
审计日志	记录用户意图、工具调用、参数、结果、时间和操作者

这部分可以借鉴 SpreadJS 的命令、撤销、重做和事务思路。SpreadJS 官方文档中提到，SpreadJS 支持撤销管理器，也支持通过命令事务组织可撤销操作。

但在企业级智能体架构里，我们不能简单假设“所有 AI 操作都能自动撤销”。更稳妥的设计，是在工具层主动建立执行前快照、执行后校验和人工确认机制。

伪代码可以这样理解：

async function runSpreadsheetTask(task) {
  const plan = await planner.createPlan(task)
  const risk = assessRisk(plan)
​
  if (risk.requiresApproval) {
    await askUserToConfirm(plan)
  }
​
  const snapshot = await tools.createSnapshot()
​
  try {
    for (const step of plan.steps) {
      const result = await runTool(step)
      await auditLog.record(step, result)
    }
    await validator.checkWorkbook()
    return await askUserToAcceptOrRollback(snapshot)
  } catch (error) {
    await tools.restoreSnapshot(snapshot)
    throw error
  }
}

这段伪代码想表达的不是具体 API，而是企业级表格智能体的基本原则：先计划、再确认、再执行、再校验、可回滚、可审计。

7. 嵌入层：表格智能体必须进入业务系统

SpreadJS AI 智能体页面中特别重要的一点，是“可直接嵌入业务系统”。

这决定了它不是一个孤立的 AI 工具，而应该成为业务系统的一部分。

在 ERP、预算、报表、风控、供应链、LIMS、报价、项目管理等场景里，表格智能体不应该只回答泛泛问题，而应该理解当前业务上下文：

• 当前用户是谁；
• 他在哪个流程节点；
• 他能看哪些数据；
• 他能改哪些字段；
• 这个工作簿属于哪个业务对象；
• 结果要提交给哪个流程；
• 导出文件要发给谁；
• 哪些操作必须留痕。

这也是为什么表格智能体要基于企业级电子表格开发基座，而不是基于一次性 Demo。

AI 可以生成步骤，但业务系统要负责身份、权限、数据、流程和审计。SpreadJS 则负责把电子表格能力稳定嵌入这些业务系统中。

8. 一套更稳妥的落地架构

综合来看，基于 SpreadJS 构建表格智能体，可以采用这样的分层：

层级	职责	关键问题
业务系统层	用户、权限、流程、业务对象	谁能做什么，结果提交到哪里
智能体编排层	理解意图、拆解任务、选择工具	任务如何被拆成可执行步骤
工具治理层	工具定义、参数校验、风险等级	AI 能调用什么，不能调用什么
SpreadJS 能力层	工作簿、工作表、公式、图表、透视表、导入导出	表格操作如何稳定执行
数据与文件层	Excel 文件、业务数据、外部数据、导出结果	数据从哪里来，到哪里去
安全审计层	确认、快照、回滚、日志、复核	如何降低误操作和幻觉风险

这套架构的核心，不是把每一层做得很复杂，而是把边界划清楚。

大模型负责理解和规划，工具层负责约束执行，SpreadJS 负责电子表格能力，业务系统负责权限和流程，审计层负责可追溯与可回滚。

边界越清楚，表格智能体越容易进入真实企业场景。

9. 结论：表格智能体的竞争力，最终来自底座与治理

表格智能体不是一个聊天框，也不是一个炫技 Demo。

它是企业业务系统中的执行型 AI 能力。

当 AI 开始读取、修改、生成和导出电子表格（Spreadsheet）时，底层电子表格引擎（Spreadsheet Engine）的价值会进一步放大。因为 AI 输出越多，企业越需要确定的计算、稳定的文件、可控的工具、可复核的结果和可追溯的执行过程。

这就是 SpreadJS 在 AI 时代的战略位置：

它不是普通表格控件，而是 AI 时代企业级电子表格开发基座。

基于 SpreadJS 构建表格智能体，真正要做的不是“让 AI 会说话”，而是让 AI 能在企业级电子表格环境中安全地执行任务。

文末检查清单：构建表格智能体前必须确认的 8 个问题

问题	如果答案不清楚
AI 可以读取哪些工作簿、工作表和区域？	需要补权限模型
哪些工具只读，哪些工具会修改数据？	需要补工具风险分级
批量写入、删除、导出前是否需要人工确认？	需要补执行确认机制
高风险操作前是否有快照或回滚方案？	需要补状态管理
每次工具调用是否有日志和参数记录？	需要补审计链路
导入 Excel 文件后如何校验公式、格式和数据？	需要补文件校验流程
AI 生成结果是否需要业务人员复核？	需要补人工验收节点
表格智能体如何嵌入现有业务流程？	需要补业务系统集成设计

参考资料

• SpreadJS 中文官网产品页
• SpreadJS V19.0 新特性页
• SpreadJS AI 智能体页面
• SpreadJS API：Workbook
• SpreadJS API：Worksheet
• SpreadJS 文档：导出 PDF
• SpreadJS 文档：撤销与重做