当 Office 变成 Agent 的运行时：Univer 把电子表格做成"AI 操作系统"

一个场景

你让 Agent 做一件事：分析过去 12 个月的销售数据，找出流失客户，生成一份带图表的报告。

传统做法，Agent 需要这样完成：

1. 调数据库 API 拿原始数据
2. 在内存里用 pandas 处理
3. 用 matplotlib 生成图表，存成 PNG
4. 用 python-docx 拼一份 Word 文档
5. 把 PNG 塞进 Word
6. 上传到某个地方给你看

这个流程的问题在于：中间产物全是文件。数据是 CSV，图表是 PNG，报告是 DOCX。Agent 在这些格式之间来回搬运，每一步都丢失结构。你想让另一个 Agent 接手改一改？它得先解析 DOCX，把图表提取出来，重新理解数据结构。

2026 年 9 月 22 日登上 GitHub Trending 的 Univer 提出了另一个思路：让 Agent 直接操作 Office 文档本身，而不是生成文件。

Univer 是什么

Univer 的官方定位是"A full-stack, isomorphic office SDK for building spreadsheets, documents, and presentations"。翻译过来：一个全栈、同构的 Office SDK，让你在自己的产品里嵌入电子表格、文档和演示文稿。

但真正让它登上 Trending 的不是"又一个 Office SDK"——是它的最新定位："The Office Harness for AI Agents"。Harness 这个词很关键，它的意思是"运行时框架"——Univer 不只是让 Agent 能生成 Office 文档，而是让 Office 文档成为 Agent 的运行环境。

三个关键设计

1. Canvas 渲染，不是 DOM

Google Sheets、Notion、飞书表格这些产品，底层都是 DOM 渲染。每个单元格是一个 div，每个公式是一段 JavaScript。当表格大到 10 万行，DOM 节点数爆炸，浏览器卡死。

Univer 用 Canvas 渲染。整个表格画在一个 Canvas 上，只渲染可视区域。10 万行、100 万行都能流畅滚动。这不是新想法——Excel 桌面版一直这么干——但在 Web 端做 Canvas 渲染的 Office SDK，Univer 是少有的开源实现。

对 Agent 来说，Canvas 渲染意味着什么？Agent 可以操作一个百万行的电子表格，而不需要把整个表格加载到内存里。Agent 调 Facade API 改一个单元格的值，Univer 只渲染那个单元格。这让 Agent 能处理的数据规模上了一个数量级。

2. 同构：浏览器和 Node.js 同一套 API

这是 Univer 最有意思的设计。同一套 Facade API，在浏览器里操作 UI，在 Node.js 里做 headless 处理。

// 浏览器里：用户看到表格，Agent 通过 Facade API 改数据
univerAPI.createWorkbook({ sheets: [{ name: 'Sheet1', cellData: { ... } }] })

// Node.js 里：没有 UI，Agent 直接操作 workbook 逻辑
const univer = new Univer({ /* headless */ })
const univerAPI = FUniver.newAPI(univer)
univerAPI.createWorkbook({ ... })

这意味着 Agent 可以在服务端"无头"地操作 Office 文档——生成、修改、计算公式、处理数据——然后把结果交给前端渲染。Office 文档不再是文件，是运行时对象。

3. 插件架构：每个能力都是可插拔的

Univer 的每一个功能——公式引擎、图表、数据透视表、协同编辑、暗色模式——都是一个独立插件。你可以：

• 只用核心，做一个极简的表格组件
• 加上公式引擎插件，支持 Excel 公式
• 加上协同编辑插件，多人实时协作
• 加上 AI 插件，让 Agent 直接操作

这种设计让 Univer 可以从"轻量表格组件"一路扩展到"完整 Office 套件"。对 Agent 集成来说，这意味着你可以按需加载——不需要为了一个简单的数据填充任务加载整个 Office 运行时。

为什么 Agent 需要 Office 运行时

过去两年，Agent 和 Office 的交互方式经历了三个阶段：

阶段一：生成文件。Agent 用 python-docx 生成一个 DOCX，用 openpyxl 生成一个 XLSX。问题：文件是死的，改一个数据要重新生成整个文件。

阶段二：调 API。Agent 调 Google Sheets API、Microsoft Graph API 改在线文档。问题：API 调用有延迟，有配额，有认证复杂度，而且 API 能做的事远少于 Office 原生功能。

阶段三：操作运行时。Agent 直接操作 Office 运行时——同一个进程里，同一个数据结构上，Agent 和人类用户看到的是同一个文档对象。改一个单元格，公式立即重算，图表立即更新，协同编辑立即同步。

Univer 推动的是第三个阶段。它的 Facade API 让 Agent 能做人类在 Excel 里能做的一切事——写公式、建透视表、改格式、画图表——但是是程序化地做。而且因为同构，Agent 在服务端做的事可以无缝交给前端渲染。

一个具体的例子

想象一个 Agent 工作流：

1. Agent 接到任务："分析这份销售数据，找出异常"
2. Agent 在 Node.js 里创建一个 Univer workbook，把 CSV 数据导入
3. Agent 用 Facade API 写公式计算每月增长率
4. Agent 用 Facade API 创建透视表，按地区分组
5. Agent 发现华东区 7 月数据异常，高亮标记
6. Agent 把整个 workbook 序列化，发给前端
7. 前端用户看到的是一个完整的、可交互的电子表格——可以继续改、继续分析

这个流程里没有文件。没有 CSV、没有 XLSX、没有 PNG。整个数据流是 Univer 的内部数据结构，Agent 操作的是运行时对象，人类操作的是同一个运行时对象的 UI 表现。

它没解决的问题

Univer 不是完美的：

1. 学习曲线：Facade API 有几十个方法，插件系统有自己的生命周期，上手不简单。
2. 生态：相比 Excel（几十年的插件生态）或 Google Sheets（Apps Script），Univer 的生态还很年轻。
3. 性能：Canvas 渲染对大表格友好，但复杂公式重算的性能取决于公式引擎实现，和 Excel 的原生 C++ 引擎还有差距。
4. AI 集成深度：当前版本提供了 headless 运行时，但"Agent 怎么更好地操作 Office 文档"这个上层问题还需要框架和模式来回答。

一个类比收尾

Univer 之于 Office，就像 Linux 之于操作系统——一个开源的、可嵌入的、可编程的运行时。Excel 是 Windows，功能全但是黑箱；Google Sheets 是 macOS，漂亮但是锁在云上；Univer 是 Linux，你可以把它塞进任何地方，按需裁剪，程序化控制。

当 Agent 需要一个"Office 环境"来工作时，Univer 提供的不是文件，是运行时。这是 Office 从"文档"走向"基础设施"的一步。

项目地址：dream-num/univer
文档：docs.univer.ai
许可证：MIT
语言：TypeScript