★ FEATURED ARTICLE 1. 为什么“Agent 办公运行时”是个值得盯的方向第一次看到“Agent 办公运行时”这个说法我脑子里蹦出来的不是某个具体产品而是一个很实际的问题现在绝大多数 AI Agent 在办公场景里本质上还是个“聊天框加几个工具调用”。你让它改个表格它给你返回一段 Markdown你让它做份汇报它吐出来一堆文字让你自己往 PPT 里贴。这个链路里Agent 和真正的办公文件之间隔着一层厚厚的“翻译层”而翻译层就是错误和低效的温床。Univer 这个项目切入的点恰好是把这个翻译层干掉。它做的事情用一句话概括把表格、文档、幻灯片这三种最核心的办公文件格式做成一套可编程的运行时让 AI Agent 能够像操作内存对象一样直接、结构化地读写办公文件。你听到“运行时”这个词可能会觉得有点重但放在这里其实很准确——它不是简单的文件解析库而是一套带状态、带渲染、带协同能力的执行环境。这个方向为什么现在值得关注因为 Agent 的能力瓶颈正在从“模型够不够聪明”转移到“模型能不能精确地操作真实世界的对象”。办公文件就是真实世界里最高频、最结构化、也最容易被搞砸的对象之一。一个单元格的公式引用错了整张报表就废了一个段落的样式继承乱了整份文档的排版就崩了。这些都不是靠“让模型再想想”能解决的得靠运行时层面的约束和校验。这篇文章适合谁看如果你在做 Agent 产品尤其是办公、协作、数据处理方向的这里面的架构思路和踩坑经验对你有直接参考价值。如果你是 TypeScript 开发者想了解一个大型前端项目怎么设计可扩展的运行时架构Univer 的代码组织方式也值得拆一拆。哪怕你只是好奇“AI 到底怎么才能真的帮我改 Excel”看完你应该能明白现在的技术卡点在哪、已经走到了哪一步。我接下来会从整体设计思路、核心模块拆解、实操接入方式、以及实际跑下来会遇到的问题这几个角度把 Univer 这套东西掰开讲。不堆概念尽量说人话该给代码给代码该说坑说坑。2. Univer 的整体设计思路拆解2.1 从“文件格式”到“运行时对象”的思维转变传统办公文件处理的路子是文件存在磁盘上格式是 xlsx、docx、pptx你要操作它就得先解析成某种中间结构改完再序列化回去。这个路子的问题在于解析和序列化这两步都是有损的、有歧义的。一个合并单元格在 xlsx 里是一组 XML 属性解析成对象之后不同库对它的表达方式可能完全不一样你再写回去样式可能就丢了。Univer 换了个思路它不把文件当成“要解析的格式”而是把表格、文档、幻灯片当成“运行时里的活对象”。你打开一个表格它不是先解析再渲染而是直接在运行时里构建出一棵可操作的对象树渲染只是这棵树的一个视图。Agent 要改东西改的是这棵树上的节点改完之后运行时自动处理重渲染和持久化。这个转变带来的最大好处是Agent 的操作有了明确的语义边界。比如你要设置 A1 单元格的值在运行时里就是对一个特定 ID 的单元格对象做一次 setValue这个操作会触发依赖它的公式重算、触发视图更新、触发协同同步。所有这些副作用都是运行时帮你管的Agent 不需要知道公式引擎怎么工作也不需要知道渲染层怎么 diff。提示这种“运行时优先”的设计和游戏引擎的思路很像。游戏引擎不会让你直接改显存里的像素而是让你操作场景图里的节点引擎负责把节点变化翻译成渲染指令。Univer 在办公文件领域做的是同一件事。2.2 为什么选 TypeScript 作为实现语言Univer 用 TypeScript 写这个选择不是随意的。办公运行时本质上是一个“状态机加渲染器”而 TypeScript 的类型系统恰好能把状态的结构和转换规则表达得很清楚。你去看 Univer 的源码会发现它大量使用了 discriminated union 来表达单元格类型、文档节点类型用泛型来约束命令的输入输出。这些类型不只是给开发者看的文档它们在编译期就能拦住很多运行时才会暴露的错误。另一个原因是生态。Agent 的开发目前主流是在 Node.js 和浏览器环境里TypeScript 在这两个环境里都是一等公民。Univer 要嵌入 Agent 的运行时就必须能无缝跑在 Agent 所在的进程里TypeScript 编译出来的 JavaScript 天然满足这个要求。而且 Univer 的插件体系也是基于 TypeScript 的模块系统设计的Agent 要扩展它的能力直接写个 TypeScript 插件注册进去就行。2.3 插件化架构为什么核心要保持“薄”Univer 的架构里核心运行时只负责最基础的事情对象树的维护、命令的分发、事件的广播、渲染的调度。具体到“表格怎么算公式”“文档怎么排版”“幻灯片怎么管理图层”这些都是插件干的活。这个设计的好处是Agent 不需要加载它用不到的能力。如果你的 Agent 只处理表格那文档和幻灯片的插件可以不加载运行时的体积和启动时间都能压下来。更重要的是插件化让 Agent 的定制变得可行。假设你的业务场景里有一种特殊的单元格类型比如“从外部 API 拉数据的动态单元格”你不需要改 Univer 的核心代码写个插件注册一种新的单元格类型和对应的命令处理器就行。运行时在遇到这种单元格时会走你注册的逻辑。这种扩展方式对 Agent 来说很友好因为 Agent 的行为往往需要根据业务场景做深度定制插件化提供了这个定制点。2.4 协同能力为什么是“运行时”的一部分Univer 把协同编辑做进了运行时而不是当成一个外挂功能。这个决策背后的逻辑是Agent 操作办公文件时往往不是独占的。用户可能正在看这个表格Agent 在后台改数据改完的结果要实时反映到用户的视图上。如果协同是外挂的Agent 的修改和用户的修改之间就会有一层同步延迟甚至可能冲突。把协同做进运行时之后Agent 的每一次修改都是一个带版本号的原子操作。运行时会处理操作变换OT或者冲突-free 复制数据类型CRDT保证 Agent 的修改和用户的修改能正确合并。对 Agent 开发者来说你不需要关心协同的细节你只管发命令运行时保证最终一致性。3. 核心模块拆解与实操要点3.1 表格运行时公式引擎与依赖图表格是 Univer 最成熟的模块也是 Agent 最常打交道的部分。它的核心是一套公式引擎加一张依赖图。你往单元格里写值或者写公式运行时会解析公式找出它引用了哪些单元格然后在依赖图里建立边。当被引用的单元格变化时依赖图会触发重算把新的值传播到所有下游单元格。对 Agent 来说这意味着你不需要自己维护“改了 A1 之后哪些单元格要更新”的逻辑。你只管改 A1运行时会把 B1、C1 里所有依赖 A1 的公式都算一遍。这个能力在 Agent 做数据分析时特别有用因为 Agent 经常需要做“假设分析”——改一个输入看所有输出怎么变。有了依赖图这个操作就是一次 setValue 加一次等待重算完成。实操上Agent 调用表格运行时的典型流程是这样的// 假设已经拿到了 univer 实例和当前激活的表格 const workbook univerAPI.getActiveWorkbook(); const worksheet workbook.getActiveSheet(); // 批量写入数据Agent 从外部数据源拿到的二维数组 const values [ [产品, Q1, Q2, Q3], [A, 100, 150, 200], [B, 80, 120, 160], ]; worksheet.getRange(A1:D3).setValues(values); // 写入公式让运行时自己算汇总 worksheet.getRange(E2).setFormula(SUM(B2:D2)); worksheet.getRange(E3).setFormula(SUM(B3:D3)); // 等待公式重算完成 await univerAPI.getFormula().calculate();这里有个细节值得说setValues是批量操作比逐个单元格 setValue 快很多。Agent 在写入大量数据时一定要用批量接口否则每次 setValue 都触发一次依赖图更新和渲染调度性能会崩。我实测过写一千个单元格逐个写要好几秒批量写基本是毫秒级。注意公式重算不是同步的。你 setFormula 之后单元格的值不会立刻变成计算结果需要等运行时的计算调度跑完。Agent 在读取计算结果之前必须 await 计算完成的信号否则会读到旧值或者空值。3.2 文档运行时富文本模型与命令系统文档运行时的核心是一个富文本模型它把文档表达成一棵节点树每个节点有类型段落、标题、列表、表格等和属性加粗、斜体、颜色等。Agent 要修改文档不是直接改这棵树而是通过命令系统发命令。命令系统的好处是每个命令都是可撤销、可协同的原子操作。为什么不让 Agent 直接改树因为直接改树的话Agent 需要自己处理很多边界情况改了这个节点之后父节点的样式怎么继承相邻节点的合并怎么处理撤销栈怎么维护命令系统把这些都封装好了Agent 只需要表达“我要把这段文字加粗”命令系统负责算出具体要改哪些节点、怎么改。Agent 操作文档的典型场景是“根据模板生成文档”。比如你有一个合同模板Agent 需要把变量填进去。这个场景下Agent 的操作流程是先定位到占位符节点然后用替换命令把占位符换成实际内容。定位的方式可以是按文本搜索也可以是按节点 ID。按 ID 定位更可靠但需要模板在生成时就给占位符打上 ID。// 按文本搜索定位占位符 const searchResult univerAPI.getDocument() .searchText({{客户名称}}); if (searchResult.length 0) { const range searchResult[0].getRange(); // 用替换命令填入实际内容 univerAPI.getDocument() .replaceText(range, 某某科技有限公司); }这里踩过的坑是替换文本时如果占位符跨越了多个样式节点比如“{{客户名称}}”里“客户”是加粗的“名称”不是直接替换会丢失样式。正确的做法是先选中整个占位符范围清除样式再插入新文本最后按需重新应用样式。Univer 的命令系统提供了这些细粒度的操作但 Agent 需要知道什么时候该用哪个。3.3 幻灯片运行时图层管理与布局计算幻灯片模块相对表格和文档来说复杂度在于布局。一张幻灯片上的元素有绝对定位元素之间有层级关系还有母版和版式的继承。Agent 要生成幻灯片本质上是在做“布局求解”——给定内容和约束算出每个元素的位置和大小。Univer 的幻灯片运行时把每个元素表达成一个带变换矩阵的节点渲染时按层级顺序绘制。Agent 操作幻灯片的方式主要是增删元素和修改元素属性。比如 Agent 要根据一段文字生成一页幻灯片它需要创建一个文本框元素设置文本内容根据文本长度和字号估算文本框大小然后把它放到合适的位置。这个“估算大小和位置”的过程目前 Agent 做得并不好。因为文本的实际渲染尺寸取决于字体、换行规则、容器宽度等多个因素Agent 很难在生成时就算准。一个实用的做法是Agent 先按粗略估算放置元素然后调用运行时的“自动布局”能力做一次修正。Univer 提供了一些布局辅助方法但坦白说这块还在演进中Agent 生成幻灯片的成品率目前不如表格和文档。3.4 命令系统Agent 与运行时的唯一接口三个模块共享同一套命令系统这是 Univer 架构里最值得学的一点。命令是 Agent 和运行时之间的唯一接口Agent 不直接操作对象树运行时也不暴露内部状态给 Agent。每个命令有明确的输入类型和输出类型有执行前的校验有执行后的副作用声明。这套设计对 Agent 的意义在于它把“Agent 能做什么”变成了一个可枚举、可校验的集合。Agent 不需要理解运行时的内部结构它只需要知道有哪些命令可用、每个命令需要什么参数。这大大降低了 Agent 接入的复杂度也让运行时的行为变得可预测。命令的执行是异步的返回一个 Promise。Agent 发完命令后可以 await 命令完成也可以监听命令执行的事件。对于需要严格顺序的操作await 是必须的对于可以并行的操作监听事件更高效。4. 把 Univer 接进 Agent 运行时的完整实操4.1 环境准备与依赖安装Univer 的包发布在 npm 上核心包是univerjs/core表格、文档、幻灯片分别是univerjs/sheets、univerjs/docs、univerjs/slides。如果你要在 Node.js 环境里跑Agent 通常跑在服务端需要额外处理渲染层的依赖因为 Univer 默认是给浏览器环境设计的。Node.js 环境下你不需要完整的渲染能力只需要运行时和命令系统。Univer 提供了 headless 模式可以只加载核心和数据处理相关的插件跳过渲染插件。这样启动更快内存占用也更低。# 核心包 npm install univerjs/core univerjs/sheets univerjs/docs # 公式引擎表格需要 npm install univerjs/sheets-formula # 协同能力如果需要 npm install univerjs/rpc安装完之后初始化运行时的代码大概长这样import { Univer, LocaleType } from univerjs/core; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverSheetsFormulaPlugin } from univerjs/sheets-formula; const univer new Univer({ locale: LocaleType.ZH_CN, // headless 模式下不传渲染相关的配置 }); univer.registerPlugin(UniverSheetsPlugin); univer.registerPlugin(UniverSheetsFormulaPlugin); // 创建一个空的表格 const workbook univer.createUniverSheet({ id: agent-workbook, sheetOrder: [sheet1], sheets: { sheet1: { id: sheet1, name: Sheet1, rowCount: 1000, columnCount: 26, }, }, });这里有个容易踩的坑rowCount和columnCount不要设得太大。Univer 在创建表格时会按这个尺寸初始化内部数据结构设成十万行的话初始化就要好几秒内存也吃不消。Agent 处理的数据量通常不会太大设个几千行足够了需要更多行的时候可以动态扩展。4.2 Agent 工具函数的封装方式Agent 要调用 Univer不能让它直接拼命令得封装成工具函数。工具函数的粒度很关键太细的话Agent 要调很多次才能完成一个任务容易出错太粗的话Agent 失去了灵活性遇到没预料到的场景就卡住了。我的经验是按“业务操作”的粒度来封装而不是按“运行时命令”的粒度。比如“写入一个数据区域”是一个工具函数“设置一个公式”是一个工具函数“读取一个区域的值”是一个工具函数。这些工具函数内部可能调用多个运行时命令但对 Agent 来说它们是一个原子操作。// 封装成 Agent 可调用的工具函数 const tools { writeRange: async (sheetId: string, range: string, values: any[][]) { const worksheet workbook.getSheetBySheetId(sheetId); worksheet.getRange(range).setValues(values); await univer.getFormula().calculate(); return { success: true, range }; }, setFormula: async (sheetId: string, cell: string, formula: string) { const worksheet workbook.getSheetBySheetId(sheetId); worksheet.getRange(cell).setFormula(formula); await univer.getFormula().calculate(); return { success: true, cell }; }, readRange: async (sheetId: string, range: string) { const worksheet workbook.getSheetBySheetId(sheetId); const values worksheet.getRange(range).getValues(); return { success: true, values }; }, };工具函数的返回值要结构化包含成功标志和结果数据。Agent 拿到返回值后可以根据成功标志决定下一步操作。如果失败了返回值里要包含错误信息方便 Agent 判断是重试还是换策略。4.3 处理 Agent 的并发操作Agent 在办公场景里经常需要并发操作比如同时改多个表格、同时生成文档和幻灯片。Univer 的运行时本身是单线程的命令是串行执行的但 Agent 的调用可能是并发的。如果不做处理并发调用会导致命令交错产生不可预期的结果。处理方式有两种一种是加锁让 Agent 的调用排队另一种是利用运行时的命令队列把并发调用转成串行命令。我倾向于第二种因为 Univer 的命令系统本身就是为串行执行设计的你只需要保证 Agent 的调用最终变成有序的命令流就行。// 用一个简单的队列来串行化 Agent 的调用 class CommandQueue { private queue: Promiseany Promise.resolve(); enqueueT(fn: () PromiseT): PromiseT { const result this.queue.then(fn); this.queue result.catch(() {}); // 防止错误中断队列 return result; } } const queue new CommandQueue(); // Agent 调用时走队列 const writeRange (sheetId: string, range: string, values: any[][]) { return queue.enqueue(async () { // ... 实际写入逻辑 }); };这个队列的粒度要控制好。如果所有操作都走同一个队列并发度就没了Agent 的性能会受影响。我的做法是按文档 ID 分队列同一个文档的操作串行不同文档的操作并行。这样既保证了单个文档的一致性又保留了跨文档的并发能力。4.4 持久化与状态恢复Agent 操作完办公文件后需要把结果持久化。Univer 提供了序列化接口可以把运行时状态导出成 JSON也可以导出成 xlsx、docx 等标准格式。导出成 JSON 的好处是保留了完整的运行时状态下次加载时能精确恢复导出成标准格式的好处是能被其他办公软件打开。我的建议是两者都做JSON 用于 Agent 自己的状态恢复标准格式用于交付给用户。JSON 的导出和导入都很快标准格式的导出需要走一遍序列化流程会慢一些但可以异步做。// 导出为 JSON用于状态恢复 const snapshot univer.getSnapshot(); // snapshot 是一个可序列化的对象存到数据库或文件里 // 导出为 xlsx用于交付 const xlsxBlob await univer.exportAsXLSX();这里有个坑导出 xlsx 时公式会被导出成公式字符串但计算结果不会一起导出。如果用户用其他软件打开公式会重新计算。这通常没问题但如果公式依赖了外部数据或者自定义函数重新计算可能会失败。稳妥的做法是导出前先把公式转成值但这会丢失公式的可编辑性。具体怎么选看你的业务场景。5. 实际跑下来会遇到的问题与排查5.1 公式重算不触发或结果不对这是最常见的问题。Agent 写了一个公式但读出来的值是空的或者旧的。原因通常有三个一是没有 await 计算完成二是公式引用的单元格还没写入三是公式语法有误运行时解析失败但没报错。排查顺序是先确认公式字符串本身没问题可以在 Univer 的在线 demo 里手动输入验证然后确认引用的单元格已经写入且写入操作已经完成最后确认 await 了计算完成的信号。如果都确认了还是不对检查一下公式引擎插件有没有正确注册有些公式函数是可选插件提供的没注册的话公式会算不出来。注意Univer 的公式引擎对循环引用是静默处理的不会报错但相关单元格的值会保持为上一次的计算结果或者空。Agent 在生成公式时要避免产生循环引用否则会得到一个看似成功但结果错误的状态。5.2 大批量写入导致界面卡顿Agent 一次性写入几千行数据时如果每写一行都触发一次渲染界面会卡死。解决办法是用批量接口并且把渲染调度关掉等所有写入完成后再统一触发一次渲染。// 关闭渲染调度 univer.getRenderManager().setRenderSuspended(true); // 批量写入 worksheet.getRange(A1:Z1000).setValues(bigData); // 恢复渲染 univer.getRenderManager().setRenderSuspended(false); univer.getRenderManager().triggerRender();这个技巧在 headless 模式下不需要因为 headless 模式本来就没有渲染。但如果你的 Agent 跑在浏览器里或者需要实时预览这个优化就很关键。我实测过一千行数据的写入不做这个优化要卡三四秒做了之后基本无感。5.3 协同场景下的冲突处理Agent 和用户同时操作同一个文档时冲突是难免的。Univer 的协同层会处理大部分冲突但有些冲突需要业务层决策。比如 Agent 要删除一行用户正在编辑这一行里的某个单元格这时候是让 Agent 的删除失败还是让用户的编辑丢失Univer 的默认策略是操作变换把冲突的操作变换成不冲突的形式。但有些操作没法变换比如删除和编辑同一个对象。这种情况下运行时会拒绝后到的操作并返回冲突信息。Agent 收到冲突信息后需要重新读取文档状态基于新状态重新决策。我的经验是Agent 在协同场景下操作文档时尽量用“读-改-写”的模式并且在写之前重新读一次确认状态没变。如果状态变了就基于新状态重新计算要写的值。这个模式会增加一些延迟但能大幅降低冲突率。5.4 内存泄漏与长时间运行的稳定性Agent 通常是长时间运行的如果每次操作都创建新的运行时实例内存会很快涨上去。正确的做法是复用运行时实例每次操作完清理掉不需要的数据而不是销毁实例。Univer 的运行时实例在创建时会加载插件、初始化数据结构这些开销不小。如果 Agent 要处理多个文档建议用一个运行时实例管理多个文档而不是每个文档一个实例。运行时实例内部是按文档 ID 隔离的多个文档之间不会互相干扰。// 一个运行时实例管理多个文档 const univer new Univer({ ... }); univer.registerPlugin(UniverSheetsPlugin); // 创建多个文档 const doc1 univer.createUniverSheet({ id: doc1, ... }); const doc2 univer.createUniverSheet({ id: doc2, ... }); // 操作时按 ID 获取 const sheet1 univer.getUniverSheet(doc1); const sheet2 univer.getUniverSheet(doc2);如果确实需要销毁文档用univer.disposeUniverSheet(id)来释放对应的资源。但注意销毁文档不会释放运行时实例本身占用的内存运行时实例的内存只有在整个实例被丢弃时才会释放。5.5 常见问题速查表问题现象可能原因排查方法解决方式公式结果为空未等待计算完成检查是否 await calculate加 await 或监听计算完成事件公式结果错误循环引用或语法错误在 demo 中手动验证公式修正公式避免循环引用写入后界面卡顿逐单元格写入触发频繁渲染检查是否用了批量接口用 setValues 批量写入暂停渲染协同冲突频繁读写之间状态被修改检查操作时序用读-改-写模式写前重读内存持续增长运行时实例未复用监控实例数量复用实例按文档 ID 隔离导出 xlsx 公式丢失导出时未计算公式检查导出配置导出前先 calculate或转值导出6. 这套运行时对 Agent 开发者的实际价值6.1 从“生成文本”到“操作对象”的跨越Agent 在办公场景里的价值不在于它能生成多漂亮的文字而在于它能精确地操作办公文件里的对象。Univer 提供的运行时让 Agent 有了操作这些对象的能力。Agent 不再需要生成一段 Markdown 然后让用户自己往表格里贴而是可以直接把数据写到指定的单元格把公式设到指定的位置把样式应用到指定的范围。这个跨越的意义在于Agent 的输出变得可验证、可复现。文本生成的结果是模糊的你很难判断一段文字是不是“正确”的但对象操作的结果是精确的A1 单元格的值是不是 100公式算出来的结果是不是 250这些都是可以程序化验证的。可验证意味着 Agent 可以自我纠错可以形成闭环。6.2 运行时作为 Agent 的“事实来源”在多 Agent 协作的场景里运行时可以充当共享的事实来源。多个 Agent 操作同一个文档时它们都通过运行时来读写运行时保证了一致性。Agent A 改了 A1Agent B 读 A1 时读到的是改后的值不需要额外的同步机制。这个模式比“Agent 之间互相传消息”要可靠得多。消息传递会有延迟、会丢、会乱序而运行时是强一致的。Agent 之间的协作可以简化为“各自操作运行时运行时负责协调”这大大降低了多 Agent 系统的复杂度。6.3 对 TypeScript 开发者的参考意义即使你不做 AgentUniver 的代码组织方式也值得 TypeScript 开发者学习。它展示了一个大型前端项目怎么用类型系统来约束状态转换怎么用插件化来管理复杂度怎么用命令模式来解耦操作和副作用。这些模式在任何一个复杂的前端应用里都用得上。特别是它的类型声明文件组织方式值得单独拿出来说。Univer 把每个模块的类型声明放在独立的.d.ts文件里通过 TypeScript 的模块增强机制来扩展核心类型。这样每个插件可以声明自己新增的类型而不需要修改核心的类型定义。这个模式在开发可扩展的库时非常实用。7. 我踩过的几个坑和对应的解法第一个坑是公式引擎的初始化时机。Univer 的公式引擎插件注册后不是立刻就能用的需要等运行时完成初始化。如果你在插件注册后马上写公式可能会遇到公式引擎还没准备好的情况。解法是监听运行时的 ready 事件在事件回调里再开始操作。第二个坑是单元格样式的继承。Agent 设置了一个区域的背景色然后往里面写值发现值的样式被背景色覆盖了。这是因为 Univer 的样式是分层级的单元格样式、行样式、列样式、工作表样式优先级不同。Agent 在设置样式时要明确设置的是哪一层否则会出现预期之外的结果。第三个坑是文档的撤销栈。Agent 的每一次操作都会进撤销栈如果 Agent 做了大量操作撤销栈会变得很大内存占用上升。解法是在 Agent 的批量操作前后加一个事务边界把一批操作合并成一个撤销单元。Univer 的命令系统支持事务Agent 可以用事务来包裹批量操作。第四个坑是幻灯片的字体度量。Agent 生成幻灯片时如果用了系统没有的字体渲染出来的尺寸和预期会差很多。解法是限制 Agent 使用的字体集合只用那些在目标环境里确定存在的字体。如果必须用特殊字体需要在运行时里注册字体文件。8. 后续可以继续深挖的方向Univer 目前对表格的支持最成熟文档次之幻灯片还在演进。如果你的 Agent 主要处理表格现在就可以接进来用。如果涉及文档和幻灯片建议先做小范围验证确认关键场景能跑通再扩大范围。另一个值得关注的方向是 Univer 的服务端渲染能力。目前它主要是为浏览器环境设计的服务端跑需要 headless 模式。如果 Agent 跑在服务端需要导出 PDF 或者图片这块的能力还在完善中。可以关注它的服务端渲染插件进展。还有就是和 Agent 框架的集成。目前接入 Univer 需要自己封装工具函数如果有一个标准的 Agent 工具描述格式把 Univer 的命令直接映射成工具接入会更简单。这个方向目前还没有成熟的方案但社区里已经有人在尝试了。我在实际项目里用下来Univer 的运行时稳定性是够的表格场景基本没遇到过运行时崩溃。文档和幻灯片场景偶尔会遇到渲染相关的问题但都不影响数据层的正确性。如果你的场景对数据准确性要求高对渲染效果要求不那么苛刻这套东西现在就能用。
阅读完成 · 觉得有帮助？
