Univer 1.0：把 Office 变成 AI Agent 的运行时

核心判断

绝大多数「开源 Office」项目止步于做一个能用的在线表格；Univer 走的是另一条路——它不做产品，做运行时（runtime）。2026 年 9 月 24 日连发 v1.0.0 / v1.0.1 / v1.0.2 三个版本，官方定位从「开源 Office SDK」演进为 “The Office Harness for AI Agents”：同一个运行时，既渲染在浏览器里供人编辑，也跑在 Node.js 里供 Agent 读写。这个「同构 + 无头」的组合，是它区别于 Luckysheet 后继者们的关键。

截至本文写作，仓库 19,124 stars / 1,627 forks，TypeScript 为主语言，Apache-2.0 协议，最新提交停留在 v1.0.2 发布当日，维护节奏密集。

系统地图

理解 Univer 的最短路径是把它的能力栈切成四层：

这个分层里最有工程判断力的一条是：公式引擎与渲染引擎都是独立包。表格类应用的性能瓶颈从来不在 UI 组件，而在公式重算与大面积重绘——Univer 把这两件事从「功能」降格为「基础设施」，业务能力（数字格式、筛选、图表）才以插件形态叠上去。

插件形态的两种用法

README 给出了明确的二分法：

Preset 模式（快速集成）：@univerjs/preset-sheets-core 一个包带走精选插件集合、样式与 Facade 注册，三五行代码得到能用的表格。适合原型与标准场景。

Plugin 模式（完全控制）：手动 registerPlugin 逐个装配，包列表、按需加载、bundle 体积都由你决定。代价是初始化代码膨胀到四十余行（见 README Quick Start），收益是可以裁掉不需要的整块能力。

这个取舍设计得很诚实：preset 不是阉割版，只是「帮你做了组合决策」的插件集合；两条路最终落在同一套 Facade API 上。

为什么它把主轴押在 Agent 上

1.0 阶段 Univer 明确提出了三条 Agent 工作流（见仓库 “Office Workflows for AI Agents” 一节）：

1. 程序化编辑——Agent 通过结构化 API 检查与修改 Office 内容，而非模拟鼠标键盘；
2. 输出验证——Agent 通过内容检查、渲染截图与布局诊断确认自己的产出；
3. Worktree 协作——Agent 在隔离草稿里干活，人类审阅后决定合并什么。

配套动作是一组围绕 SDK 的卫星仓库：univer-workspace（可自托管的人机协作工作区，含 Agent 生成「表格小程序」的示例：网页上的图表与控件直接绑定单元格）、univer-cli（本地命令行工作区）、面向 DeepSeek Harness / OpenClaw / WorkBuddy 的集成插件。这不是宣传语，是已经在跑的集成面。

需要划清的边界：实时协同编辑、Worktree 工作流依赖对应的 Web SDK 与协作能力，部分能力属于 Pro 授权范围，开源仓库覆盖的是核心运行时与单机插件。选型时应先过一遍仓库的 Open Source and Pro 章节与 univer.ai/capabilities 能力矩阵。

采用建议

• 你的产品需要嵌入电子表格/文档编辑，且不想被托管 SaaS 锁死 → Univer 是当前 TypeScript 生态里架构最完整的选择之一；
• 要在服务端批量生成/校验 Office 内容（报表流水线、Agent 产出验证）→ 无头运行 + Facade API 是它相对竞品的独占优势；
• 只想快速预览 xlsx 文件 → 杀鸡用牛刀，轻量 viewer 更合适；
• 需要协同编辑等 Pro 能力 → 先确认授权条款再投入集成。

阅读路径建议：README → docs.univer.ai 的 preset 快速上手 → 需要深度定制时再回到 Plugin 模式与 Facade API 参考。1.0 意味着 API 面已承诺稳定，现在进入的集成成本是可预期的。

项目地址：https://github.com/dream-num/univer（v1.0.2，Apache-2.0）