企业官网建设流程全解析

做AI应用这么长时间，我一直有个很深的体会：模型推理能力强只是第一步，真正让用户觉得“这玩意有用”的，是最后那一公里的产物——可视化界面、可编辑的数据、顺手能改的表格和文档。最近在构建面向企业客户的AI数据分析助手时，我遇到了一个很现实的问题：Agent把分析结论算出来了，却不知道该怎么“交付”给用户。

直接返回一段文字？用户说要能自己筛选、排序。生成一张Markdown表格？用户说要在Excel里继续处理。用Ant Design画一个表格？数据的增删改查、公式计算、单元格样式全得自己造轮子，维护成本高到离谱。

后来我接触到了Univer，一个面向AI Agent场景设计的开源办公应用SDK。它把在线表格、文档、幻灯片的能力打包成一个可嵌入的SDK，让我能把Agent的“计算结果”直接变成“用户熟悉的办公界面”。这篇文章就把我自己的集成思路、踩过的坑、以及我对“AI Agent + 办公应用SDK”这个组合的理解，完整地分享出来。

1. 为什么AI Agent需要一个开源办公应用SDK

很多开发者第一次听到“给AI做表格应用”这个组合，第一反应是：有必要吗？大模型直接生成CSV文件不好吗？让用户下载不就完事了？

这个想法我在早期项目里也试过，然而实际投入企业环境后发现，用户根本不会因为你给了个CSV就满足。他们真正要的，是一个“打开就能用、能改、能算、能存”的工作台。

1.1 常见的三种“AI输出交付”方式，为什么都不够

我梳理一下自己在不同项目里用过的方案，以及它们各自的问题：

你会发现一个共性：在这些方案里，AI Agent只是“算力”的提供者，并没有参与到“操作”环节。而真正的办公场景恰恰是“算完之后，人要上手修改、确认、流转、汇报”。这个过程发生在表格里、文档里、幻灯片里，不是在聊天对话框里。

1.2 Agent产出物需要的是“可编辑的真实文档”，不是“聊天记录”

我现在的看法是：AI Agent未来的核心价值不只是“回答问题”，而是“产出工具”。它应该能帮你建好一张数据结构、算好一列指标、写好一页报告，然后你接手继续改。要做到这一点，Agent需要有能力“操作”一份真实的文档对象，而非仅仅输出字符串。

这里就凸显了办公应用SDK的价值：它能给Agent提供一个“表达空间”。Agent说“我想生成一张2025年Q2销售明细表”，SDK就真的开一张表格，把数据填进去，配好表头、样式、公式；Agent说“帮我在下方加一个汇总行”，SDK就真的插入一行SUM公式。用户看到的是一个每天都在用的工具，自然没有学习成本。

这也就是我把Univer拿来重点研究的原因——它定位在前端可嵌入、开源、支持多人协同和多端渲染，恰好满足了Agent产物的承载需求。当然Univer不是唯一选择，但在AI Agent集成的亲和度上，它是少数一开始就把“命令操作、插件扩展、数据模型与渲染分离”当作基座设计得这么清楚的项目。

1.3 为什么选择“嵌入SDK”而不是“独立部署一个办公网站”

这里有一个产品层面的取舍。企业级项目里，办公套件有两种集成方式：一种是部署一套完整的在线Office网站，用户跳过去使用；另一种是把SDK嵌进你现有的应用界面里，表格作为其中一块画布。

我倾向于后者。原因有两点：

• 用户不应当脱离AI应用的主流程。对话界面、分析面板、数据表格最好在同一个视图中连续完成。
• SDK嵌字可以让Agent直接操控画布内容，而不需要走一套复杂的页面跳转和鉴权协议。

从技术上来说，Univer提供了多种挂载方式，既支持直接以DOM节点嵌入，也支持iframe等隔离容器，给“嵌入现有系统”留了足够空间。这个设计对AI应用很友好：前端的React/Vue组件里可以直接调用Univer实例，让Agent指令的输出结果直接落到表格区域。

2. Univer的核心架构：为什么它适合被Agent“驱动”

如果只把Univer当成一个“长得像Excel的组件”，那集成起来没有问题，但也体会不到它最值钱的部分。真正让Univer适合AI Agent的核心，是它“数据模型、渲染层、命令系统”三者相对清晰的职责划分。

2.1 数据、界面、行为的拆分逻辑

在Univer的体系里，文档最终不是“画布上的一堆DOM节点”，而是一套结构化的数据模型。渲染层只是把数据模型画出来，你可以理解为照片与底片的关系。用户能看到的表格只是底片冲洗出来的照片，真正可持久化、可传输、可在后台操作的是数据模型本身。

这意味着Agent要修改表格，最合理的路径不是去“模拟用户点击界面按钮”，而是直接通过SDK提供的命令接口操作数据模型。Univer拿到命令后，会走一套统一流程：校验、执行、推入撤销栈、广播给协作者，最后再由各端渲染出来。这种架构天然适合AI驱动——Agent发指令，和用户敲键盘，在数据层没有区别，也就意味着AI产生的操作同样可以被撤销、被审计、被同步。

2.2 命令系统和撤销栈：让“AI的操作”有后悔药

我一直觉得，让AI直接改文档很危险，哪怕它99%是对的，只要1%错了，用户就需要“回滚”能力。Univer的命令模式给了我一个很舒服的实现方式：每次改动都是一个Command，Command进入撤销栈，用户按Ctrl+Z就能按顺序回退，包括AI执行的那几步，也可以被一起撤掉。

在具体集成时，我把Agent的每一次修改动作（写数据、加行、改样式、设置公式）都转换为对应的Command。这样用户随时可以撤销AI的某一步操作，而不需要“清空重来”。如果你正在产品里接入Agent，建议一定要设计这一层，否则用户的真实安全感会大打折扣。

2.3 模块化插件系统：按需加载，避免一上来就背全套依赖

Univer的包组织是比较典型的前端monorepo风格，核心包负责数据模型、渲染引擎、命令系统，而具体功能（电子表格、文档、幻灯片）以插件/包形式存在，使用时可动态注册。这样做的好处非常实际：如果我的场景只需要表格，就不用把文档和幻灯片模块一起打包，构建产物体积能控制在可以接受的范围。

这种按需加载的设计，对AI应用还有一层额外的价值：插件本身可以成为Agent能力的“扩展坞”。例如，Agent想给表格加一个自定义的“趋势预测”面板，我只需要在Univer插件体系里做一个侧边栏插件，再把Agent的流式输出接到这个面板上，即可完成一个原生化体验。

2.4 多端渲染与后置办公场景

Univer的渲染设计让我比较看好它在移动端与管理后台的复用：同一套数据模型，可以在PC端完整编辑器里渲染，也可以在手机端以轻量视图展示，还可以嵌入到某一管理后台的局部区域。对不同端适配，避免了我为每个入口写一套独立表格组件。对AI Agent而言，这意味着同一次任务产出，能以不同形态呈现给管理员、业务人员、老板，而不需要多次重复生成。

3. 从零开始集成Univer：我跑通的最小实践

这一节我会用比较贴近真实开发的方式，把“引入Univer并完成表格挂载”的初始路径写出来，方便你直接复刻。

3.1 安装依赖与项目初始化

我这边用的是Vite + React + TypeScript的组合，Univer官方也有对应的示例工程。先安装核心包和预设包：

npm install @univerjs/presets

预设包的好处是省心，它会把Univer运行所需要的核心能力和默认插件一次性组装好。你在业务快速验证阶段完全可以依赖它，不需要一层层手动引入几十个包。

如果你面向的是重度定制场景，后面可以做“分包加载”优化：只引入 @univerjs/core、@univerjs/sheets、@univerjs/ui 等核心包，再按需注册你自己的扩展。但第一次入门，我建议用 preset 先把链路走通，再去深究内部细节。

3.2 在React组件中挂载Univer实例

下面这段代码是我在项目里实际跑过的最小Demo，说明“如何在React组件里创建并挂载一个Univer表格”，你可以根据自己的技术栈微调。因为不同版本的API命名可能存在差异，写代码前最好先去对应文档里核对一下当前版本的实例化方式。

import { useEffect, useRef } from 'react'; import { createUniver } from '@univerjs/presets'; export default function UniverBlock() { const containerRef = useRef<HTMLDivElement>(null); useEffect(() => { if (!containerRef.current) return; const univer = createUniver({ container: containerRef.current, // 这里可以根据需求传入初始配置 locale: 'zhCN', }); // 拿到 univer 实例后，可以挂到全局或状态管理中，供 AI 指令调用 (window as any).__univerInstance = univer; return () => { univer.dispose(); }; }, []); return <div ref={containerRef} style={{ height: '80vh' }} />; }

这段代码里有一处值得留意的细节：我把Univer实例挂到了window上，这看起来有点“野”，但在AI Agent接入的前期验证里非常实用。Agent模块拿到同一实例，才能直接向表格发送数据操作指令。如果你们用的是状态管理库或依赖注入体系，也可以换成更规范的方式，核心思路是“让Agent模块能访问Univer的实例句柄”。

3.3 配置项与样式定制

Univer默认会给你一套接近现代表格的UI，包括工具栏、编辑栏、工作表标签条等。在项目接入时，有几个配置点会比较常用：

• 语言和区域设置：中国项目建议设置中文区域，涉及日期、货币格式时会自动按本地习惯显示；
• 主题颜色：可以根据企业品牌色定义主题变量，避免和现有后台风格割裂；
• 功能开关：有些场景下你需要关闭某些按钮（比如导出、分享、更多菜单），Univer支持在工具栏层面做配置或二次开发。

我第一次接入时，最大的“不习惯”是Univer有相当多配置以“插件”形式注入，而不是简单的一堆开关。你要学会的是“注册哪些插件、不注册哪些插件”，这和组织你产品的功能边界非常像。

4. 让AI Agent上手操作表格：从自然语言到结构化指令

Univer集成完毕，只是把“画布”铺好了。接下来难点在于：AI Agent怎么把用户的自然语言请求，变成Univer可以执行的数据操作。我实践下来，核心是把“意图解析”和“表格操作”解耦。

4.1 链路设计：LLM负责理解，SDK负责执行

我目前采用的链路是这样的：

用户输入自然语言 ↓ 后端大模型（LLM）解析意图，输出结构化指令 ↓ 前端Agent执行器收到指令 ↓ 调用Univer SDK接口，将指令落到数据模型 ↓ 表格渲染更新，用户看到可编辑的结果

关键点在于：不要让Agent直接去拼接页面DOM操作，而是让大模型“翻译”成一个结构化的操作清单，再通过Univer的API执行。这样做的好处是，大模型不需要掌握前端细节，它只需要输出类似“在第3行到第10行之间生成一列数据”这样的结构化语义。

4.2 一个具体的例子：让AI生成一张销售数据表

假设用户输入：“帮我把这张订单表按地区汇总一下，生成一张地区销售汇总表，并在末尾加上合计行。”

Agent的后端可以返回如下JSON结构给前端执行器：

{ "actions": [ { "type": "createSheet", "sheetName": "地区汇总" }, { "type": "setCellValues", "range": { "row": 0, "col": 0, "size": [6, 3] }, "data": [ ["地区", "销售金额", "占比"], ["华东", 1280000, "42%"], ["华南", 830000, "27%"], ["华北", 620000, "20%"], ["西南", 340000, "11%"], ["合计", 3070000, "100%"] ] } ], "summary": "已按订单数据生成地区销售汇总表" }

前端拿到这个结构后，循环执行每个action，就能把内容落到表格里。这个方案有一个额外好处：用户可以直接在表格中继续编辑“地区汇总表”，AI生成的产物不是一张死图，而是一份活数据。

4.3 传入公式：让Agent不只是“塞数据”，还能“写逻辑”

单纯让AI填入静态数据，还停留在“搬运工”水平。真正让我觉得它像“助手”的，是让AI能往单元格写入公式。Univer具备公式引擎，当单元格值以等号开头时，它会按照标准表格语法进行计算。

实践中，我会让LLM输出公式字符串，而不是让它直接算好最终数字。例如用户问：“帮我在每个月的业绩后面加一列同比增长率。” Agent返回：

{ "type": "setCellFormulas", "range": { "row": 1, "col": 7, "size": [12, 1] }, "formulas": [ ["=(F2-G2)/G2"], ["=(F3-G3)/G3"], ... ] }

Univer会自动计算这些公式的结果。这对Agent的价值很大，因为原始数据后续如果有变动，公式会跟随重算，而不是生成一张“一次性的截图”。这也是“让AI操作办公应用”和“让AI输出答案”最本质的区别：前者具备持续生命力，后者只是静态产出。

4.4 把AI封装成一个Univer插件：让助手始终在侧

除了让Agent在幕后执行数据操作，我更推荐把AI“拉进”Univer的界面里，做成一个侧边栏插件。具体做法是：注册一个自定义面板，面板内部渲染聊天输入框和流式响应区，用户点开侧边栏即可与Agent对话。

插件内部拿到Univer实例后，对话逻辑可以这样设计：

• 用户问：“当前表格的A1到D10区域，分别统计每列的平均值。”
• 插件把当前工作表数据和用户问句拼接成Prompt，发送到后端大模型；
• 大模型返回结构化指令；
• 插件调用Univer API写入结果。

这个体验很接近“在Excel里装了一个Copilot”，而且因为是基于插件体系开发的，代码和主业务解耦，后续加新能力都很顺。

5. 实际场景拆解：AI Agent + Univer的几种典型玩法

我把几个自己在做产品方案时反复遇到的场景整理出来，它们都有明确的需求支撑，不是拍脑袋想出来的。你可以对照自己的项目判断哪些适合落地。

5.1 数据分析助手：从上传文件到透视报表

这是最常见的需求。用户上传一份CSV，Agent读取表头和数据样例，快速生成数据质量报告，然后自动完成清洗步骤（去重、补空值、改格式），最终生成结果表和透视表。

在Univer里的落地路径是：Agent先把原始数据一次性灌入工作表，然后新开一个Sheet形成“清洗后”的数据集，再通过Univer的透视表相关能力生成可视化汇总。用户每一步都能看到过程，并且可以随时反悔撤销。

5.2 自动报表平台：定时任务直接写表

固定周期报表很适合发挥SDK的自动化能力。例如每天凌晨后台任务拉取业务数据，通过后端SDK或前端无人页面调用Univer，把数据追加到日期对应的工作表，并自动刷新折线图的引用范围。

这种方案和我以前“后端生成图片报表发送到群”的做法相比，用户体验完全不同：决策者打开的就是一张真实表格，可以自己下钻筛选，而不是看一张固定截图。

5.3 多人协同工作区：人类和Agent在同一张表上分工

Univer本身支持协同，这就衍生出一个很有意思的场景：一个表格里，人类用户和AI Agent在并行工作。Agent负责拉数、算指标、做预填，人类负责审批、微调、补充经验判断。两者通过命令系统在同一条时间线上协作，操作不会互相踩踏。

我在设计这类场景时，会给Agent一个独立的操作颜色，比如背景色或边框标记，让用户一眼看出哪些单元格是AI填充的，哪些是自己维护的。这样既能发挥Agent效率，又保留了人类掌控感。

5.4 文档模块的辅助写作

如果只是做表格，Univer的文档模块就有点被浪费了。在实际产品里，很多业务流程是“先分析表格，再输出报告”。用户完成数据汇总后，希望Agent在公司格式要求的文档模板里，把结论自动生成文字，顺带插入关键图表。

Univer支持文档与表格在同一个工作区内使用，这让我可以把“数据分析”和“报告撰写”连成一条完整链路：数据在表格里算好，Agent引用计算结果生成文档段落，用户直接在文档里终审修改。这种连贯性，是传统“从Excel复制到Word”所不具备的。

6. 集成过程中的坑与设计建议

毕竟Univer在中文社区里还在快速迭代，接入过程中遇到一些坑是正常的。下面这些是我实际踩过或深度复盘后认为值得提醒的地方。

6.1 不要绕过命令层直接修改内部状态

刚开始我把Univer实例当作一个普通对象，想直接改它的内部数据属性，让表格刷新。结果发现撤销栈失效、协同状态错乱，界面自动刷新也失灵了。后来我强迫自己只通过命令/API来改动数据，才解决问题。

这个教训也适用于AI接入：无论你的Agent拿到多高的权限，都应该走命令通道下发操作。这样你能获得撤销和审计能力，而不是在用户不知不觉中越改越乱。

6.2 大数据量写入时的性能策略

当Agent需要一次性灌入大量数据（比如几千行、几十列）时，逐格setCellValue是不现实的。需要优先使用批量写入API，一次把矩阵数据发给Univer，减少前端执行次数。此外，界面渲染和数据处理可以错峰，比如先让用户看到表格骨架，后台异步把数据填充完毕后再做一次聚焦滚动。

如果数据量特别大，还要考虑把数据切块写入，不要一次性把五十万行全塞进去。Univer虽然有渲染优化，但浏览器的内存约束始终存在。我的建议是：让Agent在返回数据时带上分批策略，并在界面上显示写入进度。

6.3 公式注入的可靠性问题

LLM生成的公式偶尔会出错，比如引用了不存在的单元格，或者括号不匹配。我在实践里增加了一步“公式预检”：把Agent生成的公式字符串在后台或前端做一次简单语法校验，再写入单元格。一旦校验失败，保留待审列表，而不是直接覆盖用户数据。

还有一个细节：公式引用区域时，要防止Agent把整列引用导致的计算量爆炸。我会要求LLM在生成公式前，先描述目标区域的范围描述，再交付执行器，这样能减少“SUM(A:A)”这类对整张表的无谓运算。

6.4 身份、权限和审计：AI操作也要有“用户”

协同场景中，AI操作应当归属于某个“身份”。如果把所有AI操作都挂在系统管理员账号下，审计日志会失去意义，权限控制也会错乱。我在方案里会让Agent以“虚拟协作者”身份加入文档，并带有独立的权限标识。这样用户能看到“AI助手刚刚修改了G列”，而不是神秘的数据自己变了。

如果企业内部对数据安全要求高，还要在Service层补充限制：比如Agent只能访问某些工作表、不能导出外部、不能在公式里拼接外部URL。这些都是我建议在设计阶段就定义的，毕竟修权限比补漏洞容易得多。

6.5 版本迭代带来的API漂移

Univer版本更新比较快，API有可能会调整。如果你从GitHub上或社区复制了一段代码，直接套用可能无法在当前版本编译。我的习惯是锁定依赖版本，并且把关键API的调用封装到一个独立模块中，这样以后Univer升级时，我只改封装层，不用满项目搜索替换。

这一点尤其重要——当AI指令执行模块依赖了多个Univer API时，任何一个签名变化都会导致Agent任务链路中断。封装一层“执行器”，可以让Agent集成保持稳定。

最后想说的

从我自己的实践体会来看，Univer带给AI Agent开发最大的价值，不是“多了一个好看的表格组件”，而是给了Agent一个真正可以被信任的“工作台”。在这个工作台上，Agent既能高效地产出结构化内容，用户又能无感地接手编辑，两个角色在同一份数据上无缝协作。

如果你正在做AI Agent，并且你的Agent未来要跟“表格、文档、报告”打交道，我建议尽早把Univer这类开源办公应用SDK纳入技术选型。第一次接入时可以先只跑通表格挂载和Agent数据写入，把最小闭环搭起来；后续再把公式、文档、协同逐步加入。这样你既能快速验证产品价值，也可以在用户反馈中逐渐修正方向，而不是一上来就被复杂功能拖住。

最后分享一个实操小心得：遇到不确定的API时，不要急着翻源码，先去仓库的示例目录或官方Demo里查找对应版本的使用方式，往往比读源码更快。Univer的示例工程维护得还不错，这会是你最好的上手学习资料。