1. 为什么 AI Agent 需要自己的办公“底座”Univer 的生态位AI Agent 圈子里最近讨论最多的已经不再是“能不能多轮对话”而是“能不能把对话变成文档、表格、演示文稿”。原因很简单企业办公里真正产生价值的产物大多是以电子表格、文档、幻灯片形式落地的。如果 Agent 只会生成一段 Markdown 或者一串 JSON它离“替你干活”还差得很远。Univer 正是在这个节点上被越来越多开发者注意到它是一套用 TypeScript 写的开源办公应用 SDK把在线表格、文档、幻灯片的能力打包成可嵌入的前端组件并且暴露了足够完整的编程接口方便我们用 AI Agent 来操作真实数据。我在研究这个方向时最先想明白的一件事是AI Agent 操作办公文件并不是“给模型装一个 Excel 客户端”那么简单。传统办公自动化已经发展了二十年从 VBA 宏到 Python 读写 xlsx再到 RPA 模拟点击每一个方案都存在明显短板——要么只能跑在桌面端要么只支持离线批处理要么根本无法实时感知数据变化。到了 AI Agent 时代这些问题会被进一步放大Agent 需要读取在线表格、修改单元格、生成公式、触发协同甚至要和其他协作者共享同一份数据。这不是一个 xlsx 解析库能解决的而是一个完整的、可编程的、可嵌入的在线办公引擎才能承担的事。Univer 恰恰就是这一类开源 SDK 的代表。它不像很多“在线表格组件”那样只给你一个可展示的 UI而是把数据层、命令层、渲染层、协同层全部拆开允许开发者用代码直接操作工作簿对象。这意味着 AI Agent 不必模拟鼠标键盘不必猜测 UI 坐标而是通过一条稳定的命令通道去读写数据。对我这种做过多年表格自动化的人来说这种架构上的差异几乎是决定性的。1.1 办公自动化二十年到 AI Agent 这里卡住了先说传统路径。VBA 统治桌面办公自动化很多年但它的问题大家都懂只能在 Windows 生态里跑和 Web 几乎绝缘。后来流行 Python 方案比如 openpyxl、pandas 直接读写 xlsx这一套适合离线批处理但不适合做实时在线编辑更没有办法和你自研的 SaaS 产品融合。再后来是 RPA用图像识别和坐标模拟去点击真实应用听起来很智能实际维护成本极高页面一改版脚本就报废根本不是 AI Agent 该走的路。AI Agent 对办公能力的真实需求我总结成四条实时在线Agent 修改完单元格同事能立刻看到而不是生成一个文件再发过去。结构化读写不是把表格当图片“看一眼”而是精确操作第几行第几列能拿到公式、格式、合并单元格信息。可编程扩展Agent 要能注册自定义函数、监听数据变化、批量更新区域甚至只运行在无头环境里不需要 UI。协同能力Agent 不是唯一的编辑者它要和人以及另一个 Agent 同时操作同一份数据这需要底层有真正的协同协议。仔细对照这四条你会发现大多数办公 SDK 只能满足前两条。Univer 的价值在于它把四条都纳入了自己的架构设计。特别是协同能力它不是后期加上的“插件”而是内置在数据同步层里的核心能力。这一点对 AI Agent 未来的“多智能体协同办公”场景尤其重要。1.2 Univer 到底解了一道什么题我习惯用一句话总结 Univer它是一个把办公软件“拆成零件”的 SDK而 AI Agent 可以像专业人员一样操作这些零件。拆开看它提供的能力大概是这样能力层具体内容AI Agent 的价值工作簿模型表格、区域、单元格、样式、合并、批注结构化读写数据不依赖坐标模拟公式引擎内置大量函数、支持自定义函数让 AI 生成公式、调用 AI 函数命令系统所有编辑操作走统一命令支持撤销重做AI 的每个动作可回滚、可追溯协同协议多人实时编辑同一份文档Agent 作为“第一公民”参与协同渲染引擎Canvas 前置渲染UI 与数据解耦无头模式可用也可嵌入浏览器插件机制按需注册功能模块把 AI 服务封装成插件挂进系统这里最打动我的一点是 Univer 允许我在完全不启动 UI 的情况下创建和管理工作簿。你可以在 Node.js 服务端初始化一个 Univer 实例用纯代码生成数据、计算公式、导出结果。这对 AI Agent 太重要了大部分时候 Agent 不需要“看见”表格它只需要操作数据和响应事件。需要展示给用户时再在浏览器里把 UI 渲染出来。1.3 为什么要特别在意“开源”和“SDK”这两个词“开源”和“SDK”放在一起在办公场景里其实是一个挺稀缺的组合。很多商业产品提供 API但你要么受限于厂商平台要么为每个功能单独付费要么无法把数据带到自己的私有化环境。Univer 使用的许可协议是 Apache-2.0这意味着你可以自由修改、分发也可以把它集成进自己的商业产品里。对 AI Agent 开发团队来说开源还有一层更实际的意义你可以审计整个数据流。AI 要操作表格背后涉及数据安全和权限边界。如果是黑盒产品你很难评估“Agent 执行一次清空操作到底会碰哪些数据”。自托管开源项目则可以做到完全透明这在企业服务场景里几乎是一票否决项。另外“SDK”意味着它不是最终产品而是你可以用来构建产品的积木。你做 AI Agent不需要从零写电子表格内核那至少要耗费几年时间你也不需要一个笨重的桌面客户端因为你的 Agent 跑在云端。你需要的是一个轻量的、可嵌入的、可编程的办公引擎这正是 Univer 的位置。2. 拆解 Univer一个 SDK 是如何给 AI 预留位置的我在接入 Univer 的过程中最大的感受是它的架构不是“先做了一个在线表格然后补 API”而是“从第一天就按可编程引擎来设计”。这对 AI 开发者的影响是本质性的。下面从渲染架构、插件机制、命令系统、协同协议四个角度拆解。2.1 Canvas 前置渲染UI 和数据解耦为什么关键很多前端表格组件是基于 DOM 渲染的比如用一堆div或者table来画网格。DOM 方案的好处是实现简单、样式灵活但在大规模数据和频繁更新的场景下性能容易崩。更重要的是DOM 元素的内部状态和 UI 深度耦合你想“绕过 UI 直接改数据”时会非常别扭。Univer 选择了 Canvas 前置渲染说白了就是画表格界面靠 Canvas 绘制数据和渲染分开。这种架构有一个被低估的好处它让“编程方式操作数据”成为第一等公民。AI Agent 不需要关心界面是否刷新不需要模拟点击某个按钮它直接对工作簿对象操作方法引擎负责同步渲染。这个设计角度上Univer 的定位和 Figma 对设计文档的处理思路类似——底层数据模型永远比视觉效果更稳定。如果你把 Univer 跑在 Node 环境里甚至可以直接注册核心插件而不注册任何 UI 插件这样引擎就运行在一个纯数据模式下。我实际试过用这种方式让 Agent 批量生成报表处理几百行数据完全没问题而且连浏览器都不需要启动。这种“无头办公”能力对整个服务端自动化方案都很有价值。2.2 插件机制AI 模块应该挂在哪里Univer 的项目结构采用单包多模块的方式核心包是univerjs/core负责数据模型、命令、插件系统这些基础能力。上面再挂公式引擎、渲染引擎然后在引擎之上挂具体业务模块比如univerjs/sheets是表格业务univerjs/docs是文档业务univerjs/slides是演示业务。每个业务模块又分为逻辑插件和 UI 插件。一个典型的初始化流程是这样的创建 Univer 实例然后按顺序注册渲染引擎、公式引擎、表格插件最后注册 UI 插件。这里的注册顺序是有讲究的核心实例必须先存在引擎是底层依赖业务插件依赖引擎UI 插件依赖业务插件。很多新人上来就把所有插件一股脑注册结果界面空白或者命令不生效多半就是顺序错乱。AI 模块适合做成一个独立插件在业务插件之后注册。为什么是这个位置因为 AI 插件需要访问业务层的工作簿对象又要在命令执行前后做介入。比如你想实现“AI 自动填充数据后弹一个操作确认”就需要拦截命令执行流程这个时机只能在业务插件就绪之后。2.3 命令系统AI 的“规划-执行”模式落到哪如果让我选 Univer 最值得学习的架构设计我会选命令系统。在 Univer 里用户的每一次操作、每一次代码调用最终都会转化为一个命令对象命令类型是什么作用于哪个工作簿、哪个工作表、哪个区域载荷数据是什么全部结构化。这一点和 AI Agent 的思考方式天然契合。Agent 做任何操作前其实就是在规划一串动作选中 A1 单元格填入数值 100在 B1 写入公式设置背景色。这些动作在 Univer 里能精确地对应到命令。更关键的是命令是可以被记录、回放、撤销的。遇到 Agent 操作失误你可以根据命令栈把数据恢复到操作前的状态而不是人工“改回去”。我后来做的一个安全层就是包了一层命令执行器Agent 规划好的动作先不发出去而是在内存里演练一遍检查影响范围是否超出授权区域再真正执行。这个“预演”之所以可行就是因为整个 Univer 数据层是可通过命令驱动的我甚至能拿到执行命令后受影响区域的具体范围。2.4 协同协议AI 作为协作编辑的一员协同编辑是办公 SDK 里最吃力的一块很多团队几年都磨不出稳定的协同。Univer 内部实现了文档变更的同步机制用一个人能理解的方式说多个编辑者可以同时打开同一份工作簿每个人做的修改会被拆成细粒度的操作通过协同协议广播给其他人并合并进最终数据。它在底层处理冲突、版本、合并这些棘手问题。对 AI Agent 来说这意味着你可以让 Agent 加入到一个“正在被人类编辑”的工作簿里实时更新某几个单元格也可以让两个 Agent 分别处理不同区域的数据最后合并到同一份表格。这些场景如果靠“各自操作完再合并文件”早就乱成一锅粥了。Univer 从数据层面就支持了这种并发。你需要记住一点协同能力并不是默认全部开启的。如果你只做单用户编辑不配置协同服务它也可以正常跑。只有当你需要多端实时同步时才需要额外接入协同服务。这个设计对 AI 开发者很友好初期可以先做单 Agent 操作架构上不受限制。3. 实战接入把 Univer 跑起来让 AI Agent 操作一张真实表格聊完架构直接进入动手环节。我会带你把一个最小可用的 Univer 实例跑起来然后逐步让 AI Agent 完成“填数据、写公式、改样式”这些基础操作。所有代码都以你当前从 npm 拉到的版本为准因为 Univer 的 API 仍在演进个别方法命名可能有变化但整体思路不会过时。3.1 五分钟跑通最小实例先创建一个空目录初始化项目然后安装必要依赖npm init -y npm install univerjs/core univerjs/design univerjs/engine-formula univerjs/engine-render univerjs/sheets univerjs/sheets-ui univerjs/ui univerjs/locale如果你是在 React 项目里集成可能还需要univerjs/preset-react之类的预设包。这里我尽量保持裸框架可运行方便理解本质。创建一个入口文件index.html放一个容器节点!DOCTYPE html html body div idapp stylewidth: 100%; height: 600px;/div script typemodule src./main.js/script /body /html在main.js里初始化 Univerimport { Univer, UniverInstanceType } from univerjs/core; import { defaultTheme } from univerjs/design; import { UniverFormulaEnginePlugin } from univerjs/engine-formula; import { UniverRenderEnginePlugin } from univerjs/engine-render; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverSheetsUIPlugin } from univerjs/sheets-ui; import { UniverUIPlugin } from univerjs/ui; import { enUS } from univerjs/locale; const univer new Univer({ locale: enUS, locales: { enUS }, theme: defaultTheme, }); univer.registerPlugin(UniverRenderEnginePlugin); univer.registerPlugin(UniverFormulaEnginePlugin); univer.registerPlugin(UniverSheetsPlugin); univer.registerPlugin(UniverUIPlugin, { container: app, }); univer.registerPlugin(UniverSheetsUIPlugin); // 创建工作簿 const workbook univer.createUnit(UniverInstanceType.UNIVER_SHEET, { id: workbook-1, name: AI Agent Demo, sheets: [ { id: sheet-1, name: 销售数据, rowCount: 100, columnCount: 20, cellData: { 0: { 0: { v: 产品 }, 1: { v: 销售额 }, }, }, }, ], });这段代码做完浏览器里应该能看到一个带界面的在线表格了。你甚至可以手动输入数据体验一把真实的电子表格操作。3.2 让 Agent 通过 API 操作工作簿现在 UI 已经不是重点。我们要做的是拿到工作簿对象用代码精确操作数据。Univer 的工作簿 API 采用了类似 Office JS 的模型通过getActiveSheet拿到当前工作表通过getRange取得操作区域再调用读写方法。下面这个例子展示 Agent 如何填入一组数据并生成合计// 获取当前活动工作簿FWorkbook 对象 const fworkbook univer.getActiveUnit(UniverInstanceType.UNIVER_SHEET); const sheet fworkbook.getActiveSheet(); // 直接在 A2:A4 填入数据 sheet.getRange(A2).setValue(一月); sheet.getRange(A3).setValue(二月); sheet.getRange(A4).setValue(三月); sheet.getRange(B2).setValue(12000); sheet.getRange(B3).setValue(15000); sheet.getRange(B4).setValue(13000); // 在 B5 写入求和公式 sheet.getRange(B5).setFormula(SUM(B2:B4));执行完这段代码表格里 B5 单元格应该会出现 40000 这个结果。这个动作放在传统方案里要么用 OpenXML 拼 XML要么用 Excel COM 组件都相当笨重。而 Univer 里就是几行 API 调用。这里必须说一句每个setValue都是一次独立的命令调用会触发一次数据变更和界面刷新。如果 Agent 要写入一千个单元格千万别用循环调一千次而应该用批量接口一次写入一个区域。我用这个教训换来的经验是Univer 的getRange(A1:B4).setValues([[...], [...], [...]])这种 API 才是大数据量场景的正道。3.3 公式生成AI Agent 最好用的切入点公式生成是我认为 AI Agent 在表格场景里最能直接产生价值的方向。绝大多数用户会用表格但不会用函数。AI 模型擅长把自然语言转化为结构化的公式。实现起来很简单让模型根据你的表头和数据描述生成公式字符串然后通过 Univer 的setFormula写入单元格引擎自动完成计算和刷新。一个典型链路长这样Agent 从表格读取表头和数据摘要比如“A 列是月份B 列是销售额”。用户提出需求“把 B2 到 B13 的平均值算出来”。模型生成公式AVERAGE(B2:B13)。Agent 调用sheet.getRange(B14).setFormula(AVERAGE(B2:B13))。Univer 公式引擎计算结果并渲染在界面上。这里有一个坑模型生成的公式不一定合法直接写入可能让表格显示错误。我推荐在写入前做一个校验层比如解析公式字符串检查括号是否配对、函数名是否在 Univer 支持的函数列表里。Univer 的公式引擎里维护了一份标准函数清单你可以直接拿来当白名单校验。更激进的做法是把 Agent 能力注册成公式。比如定义一个AI_SUMMARIZE()函数当用户在任意单元格输入这个公式引擎会触发一个回调把指定区域的数据发给大模型再把模型返回的摘要写回单元格。这就是把 AI Agent 嵌入到表格公式体系里的玩法对用户极其友好。4. API 矩阵一个 AI 开发者能调用的核心能力实战部分展示了最基础的读写。但 AI Agent 的能力远不止填数求和Univer 还提供了丰富的编程接口。我按自己的使用经验把对 Agent 最有价值的能力分成四类每一类都直接对着真实场景说话。4.1 区域操作不只是值还有格式、合并、批注在 Univer 里getRange是阿喀琉斯之踵般的存在啥都能干。除了值你还能一次性设置数字格式、背景色、边框、合并单元格甚至添加批注。下面这个例子展示了 Agent 如何快速把一个原始数据区整理成报表样式const range sheet.getRange(A1:B5); range.setValues([ [品类, 库存量], [手机, 120], [平板, 85], [耳机, 200], [合计, SUM(B2:B4)], ]); range.setBackgroundColor(#F5F5F5); range.setBorder({ top: { style: thin, color: #CCCCCC }, left: { style: thin, color: #CCCCCC }, bottom: { style: thin, color: #CCCCCC }, right: { style: thin, color: #CCCCCC }, });对 AI Agent 来说能把格式和数据一起写好才叫真正的“替你干活”。否则 Agent 填完数据表格还是一张素颜的脸用户还得手动美化体验大打折扣。4.2 自定义函数把 Agent 的能力嵌进单元格自定义函数是 Univer 扩展体系里最让我兴奋的一块。它意味着你可以在表格里创建真正属于自己业务逻辑的函数而且这个函数可以调用外部服务。下面是一个注册自定义函数的思路import { FunctionType, type IFunctionInfo } from univerjs/engine-formula; const AI_SUMMARIZE: IFunctionInfo { functionName: AI_SUMMARIZE, type: FunctionType.Scalar, parameterCount: [1, 1], // 关键这个函数在计算时会被引擎调用 reference: async (params) { const rangeRef params[0]; // 这里可以从 rangeRef 中取出单元格区域的数据 const data extractRangeData(rangeRef); const summary await callLLM(请用一句话总结${JSON.stringify(data)}); return summary; }, };公式引擎在计算时遇到AI_SUMMARIZE(A1:D10)会调用你注册的函数并把结果作为单元格的值返回。这意味着用户可以用公式语法把 AI 能力编织进复杂的表格逻辑里。比如“如果本月的退货率大于 5%则调用 AI 分析原因”——这种条件式的智能分析用自定义函数可以实现得非常优雅。4.3 监听变化Agent 从被动执行变成主动值守AI Agent 如果只能“你让我改我才改”那就只是个远程遥控器。真正有价值的形态是“值守”——Agent 长期监听工作簿的变化一旦发现特定条件触发自动作出反应。Univer 允许你订阅单元格变更事件sheet.onCellChange((event) [ // event 中包含被修改的单元格位置和新值 const { row, column, value } event; if (value 0) { autoAlert(检测到负数需要人工复核); } ]);这个能力可以组合出很多玩法销售数据低于阈值时让 Agent 自动发送预警多人填报的表格出现重复项时让 Agent 自动去重外部系统同步的数据落地后Agent 自动跑一遍完整性校验。Agent 从“执行器”升级成了“值守者”用户体验完全是另一个层级。5. 落地过程中躲不开的硬问题安全、性能、版本陷阱架构理解清楚、Demo 跑通只是开始。真要把 Univer 和 AI Agent 组合用到生产环境有几个硬问题必须在设计阶段就想到。5.1 权限边界Agent 不能拥有“管理员全部权限”AI Agent 操作办公文档最危险的事是它拥有和登录用户一样的完整读写权限。一句话说错可能把整份季度报表清空。这不是危言耸听我在实际项目里就见过 Agent 误调用deleteSheet的场景。解决方案是在 Agent 层建立权限沙箱给 Agent 分配独立的工作簿副本操作完成且校验通过后再合并回正式数据。明确允许操作的 sheet 范围比如只允许写入B2:F100其余区域只读。利用 Univer 的命令栈做事务性回滚批量操作前记录起始状态操作异常时回退。我在项目里实现了一个简单的“Agent 操作日志”把 Agent 的每次命令连同影响范围、执行时间、执行结果都记录下来。这样不光是出了问题能追溯还能积累数据去做 Agent 行为的安全审计。5.2 性能红线批量操作和 UI 渲染的冲突Univer 的渲染性能和操作方式强相关。前面提过逐格循环写入是大忌。正确的姿势是尽量把数据组织成二维数组一次性写入区域。一个经验值是100 行以内的数据正常调用 API 完全没问题几千行以上优先用批量接口并且可以考虑暂时隐藏 UI 或者关闭实时渲染等数据就绪后统一刷新。另外公式引擎在每次数据变更时会重新计算相关依赖链。如果你的表格里有大量跨表引用和数组公式加上 AI 频繁修改数据计算开销会直线上升。我建议对于实时性要求不高的分析场景让 Agent 在服务端无头模式下先完成计算再把最终结果同步给前端展示。这样既省了浏览器渲染压力又避免了 UI 卡顿影响用户操作。5.3 版本和依赖Univer 生态迭代很快作为一个还在快速演进的开源项目Univer 的 API 变化速度比大多数商业产品要快。不同版本之间插件注册方式、区域接口命名、甚至工作簿初始化参数都可能不一致。网上很多教程是基于旧版本写的直接照搬经常跑不起来。我的建议是务必以官方文档和 npm 上的最新 release 为准不要只看热门博客文章。升级大版本前先看项目的更新日志重点是最常使用的核心 API 是否有破坏性变更。把 Univer 的版本锁定在你的 package.json 里不要用^裸奔否则半年后重新安装依赖时一切都会崩。遇到空白界面的 bug优先检查插件注册顺序核心 → 公式引擎 → 渲染引擎 → 业务插件 → UI 插件。5.4 数据安全公式注入和内容清洗AI Agent 生成的内容不能直接信任。这里包括两层问题一是大模型输出的公式可能引用外部服务比如一个HYPERLINK(恶意网址)二是导入外部数据时单元格值如果以,,-,开头可能触发公式注入攻击。对于后者我在系统里强制做了清洗凡是来自外部数据源的字符串如果以这些符号开头一律在前面加英文单引号让它们按纯文本处理。AI 生成的公式还需要做一层合法性校验。我提到的函数白名单方法已经能挡掉大部分问题但更严格的做法是解析公式的依赖关系确保公式引用的区域没有越界、没有循环引用。Univer 的引擎本身会处理循环引用报错但越界访问可能在部分版本里只是显示#REF!并不会抛出异常需要你的校验层提前发现。6. 关于落地方案和未来空间的个人判断项目走到这一步我对“Univer AI Agent”组合的推荐方式是分层架构。服务端跑一个无头 Univer 实例负责承载数据模型和公式计算AI Agent 通过服务端 API 操作这个模型。需要给用户看的内容在浏览器里再创建一个 Univer 实例通过协同协议和服务端数据同步。这个架构的好处是两边的关注点完全分离服务端保证数据安全和计算效率浏览器端保证展示体验和交互。纯前端方案也不是不行。如果你做的是一个轻量工具类产品并且 Agent 只操作当前用户自己的表格完全可以只在浏览器里集成 UniverAgent 逻辑通过前端脚本运行。这种方案部署简单单用户场景下表现不错。但一旦涉及多人协作、权限管理、服务端审计纯前端就很难支撑了。从长期趋势看办公软件正在从“人操作工具”变成“人和 Agent 共同操作工具”。Univer 作为一个把数据层和交互层完全分离的开源办公 SDK恰好为这个趋势提供了切入点。它给了 AI Agent 一条不只是“读文件”和“写文件”的能力通道而是一条理解单元格、公式、协同、格式的完整通道。我自己在尝试构建的方向是让多个 Agent 分别负责数据采集、清洗、分析和报表生成最后协同写入同一个工作簿。这个场景里每个 Agent 都像一个熟悉电子表格的同事而不是一个只会调接口的脚本。最后分享一个实际开发中的小技巧给 Univer 工作簿的数据模型单独写一个序列化版本号。因为 AI Agent 会频繁修改数据一旦出了异常你要能在秒级内把工作簿恢复到某个健康快照。我把 Agent 每次大操作之前的完整工作簿 JSON 存一份到对象存储保留最近 50 个版本回滚策略非常简单可靠。这个机制我在这类项目里反复用几乎零成本但救过我好几次。如果你也要把 AI Agent 和办公数据深度结合我建议你从这个版本快照机制开始搭。它不炫技但它是整个系统最值得信赖的压舱石。