
WorkBuddy、QoderWork、Kimi Work、TRAE Work 与 WPS 灵犀都能根据自然语言创建、修改并交付 Word、Excel、PPT 等文件,但它们的底层实现和用户交互并不相同。
前四类产品更接近“Agent 生成文件,再交给预览器展示”;WPS 灵犀则依托金山自有的 Office/WebOffice 能力,将 Agent 直接带入文档编辑环境。二者的差异不仅体现在技术栈上,也决定了用户看到的是“生成后的文档产物”,还是“正在被修改的 Office 文档”。
这一差异也延伸出企业自研 Agentic AI 应用处理 Office 文档时的两条主要技术路线。
产品 | 文档创建与修改 | 展示方式 | 主要交互形态 |
|---|---|---|---|
WorkBuddy | 通过 DOCX、XLSX、PPTX Skill、脚本及 OOXML 工具生成或修改文件 | 内置产物区预览,也可接入腾讯文档 | 对话下达任务,查看执行步骤和最终产物 |
QoderWork | 通过内置文档 Skill 操作本地文件,持续修改同一任务中的产物 | Artifact 内联预览 | Agent 在工作目录中生成文件,用户通过对话继续迭代 |
Kimi Work / Kimi Docs | 由云端 Agent 调用文档工具,生成或修改 Office 文件 | 浏览器中预览,完成后下载原格式文件 | 对话创作、阶段性预览、下载后继续编辑 |
TRAE Work | 通过文档 Skill 和本地或云端工具生成 Office 文件 | 产物或文件预览 | 任务规划、文件生成、版本迭代 |
WPS 灵犀 | 调用 WPS 自有 Office/WebOffice 文档能力,操作文档对象和排版内核 | WPS 编辑器或 WebOffice 原生渲染 | AI 对话与 Office 编辑区同屏,支持就地修改 |
需要说明的是,各厂商没有完全公开内部实现。对于 WorkBuddy、QoderWork、Kimi Work 和 TRAE Work,能够确认的是其 Skill、文件产物和预览式工作流;具体使用 docx-js、Python 文档库、直接 OOXML 操作还是自研工具,需要以实际版本为准。
WorkBuddy、QoderWork、Kimi Work 和 TRAE Work 的典型链路是:
用户需求
↓
Agent 规划与内容生成
↓
DOCX/XLSX/PPTX Skill
↓
生成或修改 Office 文件
↓
产物预览器展示
↓
继续对话修改或下载文件Agent 操作的是文件或文件结构,用户看到的通常是任务进度、文件版本和阶段性产物。即使执行过程中可以预览,也不等于在完整 Word 编辑器中逐步修改。
这种模式更像“交付一份文档”,适合:
WPS 灵犀依托 WPS 自有 Office/WebOffice 能力,链路更接近:
用户需求
↓
Agent 理解编辑意图
↓
调用文档对象、选区、样式和排版接口
↓
直接修改当前文档
↓
WPS 排版内核实时刷新用户可以在一侧与 AI 对话,在另一侧查看文档内容、格式和分页变化。AI 不只是生成一个新文件,还可以围绕当前选区、段落、表格或页面持续修改。
这种模式更适合:
因此,WPS 灵犀的优势不只是拥有更好的 DOCX 生成工具,而是拥有从文档对象模型、排版内核到编辑界面的完整闭环。
该路线不引入完整 WebOffice,Agent 直接生成 Office 文件,再通过独立组件预览。
Agent
↓
结构化文档模型
↓
POI / docx-js / python-docx / OOXML / 模板引擎
↓
DOCX、XLSX、PPTX
↓
文件预览或转 PDF 服务该路线适合“Agent 生成、用户验收”的业务。对于 BaseMetas FileView 这类预览服务,可以承担权限控制、水印和嵌入式查看。Office 文档中,Excel 可采用浏览器端直接预览;Word、PPT 等其他格式则转换为 PDF 后展示,以兼顾还原度、稳定性和前端接入成本。
该路线将完整的在线 Office 引擎作为 Agent 的文档执行环境:
Agent
↓
文档操作接口
↓
WebOffice 文档对象与排版内核
↓
在线编辑器
↓
用户查看、修改、审阅和保存企业如果无法使用 WPS WebOffice,或希望私有化部署,可以考虑 ONLYOFFICE DocumentServer。
ONLYOFFICE DocumentServer 是 ONLYOFFICE Docs 的核心服务,作为知名WebOffice产品之一,提供浏览器端的文档、表格、演示文稿和 PDF 查看与编辑能力,主要使用 DOCX、XLSX、PPTX 等 OOXML 格式。官方架构说明参见 How it works。
文件创建流程:

文件修改及预览流程:

其中,DocumentServer 负责在线编辑和协作,BaseMetas FileView 负责轻量只读预览。Agent 不应直接管理两类产品的内部文件,而应通过业务侧的文档操作服务统一处理权限、版本、锁、存储和预览路由。
创建新文档可以采用两种方式。
企业预先准备合同、报告、通知等 DOCX 模板,Agent 负责:
模板方式可控性较高,适合格式固定的企业文档。
ONLYOFFICE Document Builder 可以通过 JavaScript 脚本或 SDK 创建、打开、修改和保存文档,支持文档、表格、演示文稿、表单和 PDF。官方说明参见 Document Builder Overview。
典型链路是:
用户需求
↓
Agent 输出结构化文档计划
↓
文档服务生成 Builder 脚本
↓
Document Builder 创建 DOCX
↓
保存到对象存储
↓
按权限路由到 FileView 预览或 DocumentServer 编辑需要注意,Document Builder 免费版本生成的文件带有水印,正式商用需要评估授权。安装与授权说明
Document Builder 是后台文档生成和修改工具,不等同于正在浏览器中运行的在线编辑器。它适合离线生成新版本;如果希望 Agent 操作用户当前打开的文档,还需要编辑器插件、前端桥接层或其他受控的文档对象接口。
修改可以分为后台自动修改和人机协同修改。
适合批量替换、插入章节、更新数据和重新生成报告:
Agent 生成修改计划
↓
Document Builder 打开原文件
↓
执行文档对象操作
↓
保存为新版本
↓
通知用户预览为避免破坏原文件,建议始终保存为新版本,并记录 Agent、模型、提示词摘要、修改范围和生成时间。
适合合同审阅、方案编写和正式报告:
ONLYOFFICE 支持审阅模式,修改可以作为建议保留,由有权限的用户接受或拒绝。Reviewing
实际落地时,需要开发编辑器插件、前端桥接层或受控的文档操作服务,不能仅依靠大模型直接修改压缩包中的 XML。
文档展示可以根据是否需要,选择 DocumentServer 或 BaseMetas FileView。
DocumentServer 可以使用 view 或 edit 模式打开文档,并通过权限配置进入审阅场景:
view:只读预览;edit:完整在线编辑;业务系统通过 api.js 嵌入编辑器,并向 DocumentServer 提供文件 url、文档 key、用户、权限和 callbackUrl 等配置。编辑器配置
该方案适合需要编辑、批注、修订、多人协作以及 Agent 与用户共同处理文档的场景。
如果只要求查看 Agent 生成或修改后的文件,可以使用 BaseMetas FileView,其不仅支持office类文件的预览,同时支持CAD,3D,视频,代码等300种+格式文件预览:
Agent 生成或修改 Office 文件
↓
保存到本地或对象存储
↓
调用 FileView 预览入口
↓
Excel:浏览器端直接预览
Word、PPT 等:服务端转换为 PDF
↓
通过嵌入式查看器展示该方案不提供完整 Office 编辑能力,重点是统一、稳定和低交互成本的只读预览。Word、PPT 等格式转换为 PDF 后,可以继续使用成熟的 PDF 查看能力,实现分页、缩放、搜索、水印、下载、打印和复制控制;Excel 保留浏览器端直接查看,以避免将大表格固定为分页文档。
与 DocumentServer 相比,FileView 更适合:
对比维度 | ONLYOFFICE DocumentServer | BaseMetas FileView |
|---|---|---|
核心定位 | 在线 Office 编辑与协作 | 多格式统一只读预览 |
Word、PPT 展示 | Office 编辑内核直接渲染 | 转换为 PDF 后预览 |
Excel 展示 | 在线表格编辑器 | 浏览器端直接预览 |
在线修改 | 支持 | 不支持 |
批注、修订、协作 | 支持 | 以查看和权限控制为主 |
资源与集成成本 | 相对较高 | 相对较轻 |
典型场景 | 人机协同编辑、合同审阅、多人协作 | Agent 结果验收、附件查看、归档和知识库 |
如果大量用户只需要查看文件,不建议全部进入完整的 DocumentServer 编辑会话。业务系统可以根据权限和用户动作动态路由:
默认查看
→ BaseMetas FileView
点击“在线编辑”或进入审阅任务
→ ONLYOFFICE DocumentServer
Agent 后台创建或批量修改
→ 文档工具 / Document BuilderDocumentServer 使用文档 key 识别编辑会话。同一协作文档应使用相同的 key;文件产生新版本后,需要按规则更新 key,避免旧缓存和新文件混用。Co-editing
DocumentServer 不负责永久保存业务文件。编辑结束后,它通过 callbackUrl 通知业务系统获取最终文件,业务系统必须完成下载、存储、版本登记和状态更新。Saving file
DocumentServer 与业务系统之间应启用 JWT,保护初始化配置、文件地址、命令和回调,避免配置被篡改。Security
Agent 不应获得不受限制的文件和编辑权限。建议将操作抽象为白名单工具,例如:
涉及覆盖原文件、删除内容、接受全部修订和对外分享时,应增加权限校验和人工确认。
需要明确 Agent 与用户是否可以同时编辑。较稳妥的策略是:
场景 | 更适合的路线 |
|---|---|
批量生成报告、合同和通知 | 文件生成工具加独立预览 |
文档生成后只需查看、下载或归档 | 文件生成工具加独立预览 |
对复杂 Word 文档进行局部修改 | WebOffice / DocumentServer |
需要批注、修订和人工审阅 | WebOffice / DocumentServer |
多人和 Agent 同时参与文档处理 | WebOffice / DocumentServer |
Office 产物的统一只读预览 | BaseMetas FileView |
高并发只读预览 | BaseMetas FileView 或转 PDF |
Excel 在线只读查看 | BaseMetas FileView 浏览器端预览 |
同时存在批量生成、预览和在线编辑 | 两条路线组合 |
对大多数企业而言,没有必要在两条路线中二选一。更合理的方式是组合使用:
自动生成与批量处理
→ 模板引擎 / OOXML / Document Builder
普通查看与业务嵌入
→ BaseMetas FileView
→ Excel 浏览器端直接预览
→ Word、PPT 等转换为 PDF 预览
复杂修改与协作审阅
→ ONLYOFFICE DocumentServer
统一入口
→ Agent 编排、权限、版本和审计服务这种架构既保留了 Agent 后台自动化的效率,也能在需要时提供接近 WPS 灵犀的“对话加 Office 编辑区”体验,同时避免让所有文件和用户都承担完整在线 Office 的资源成本。
WorkBuddy、QoderWork、Kimi Work 和 TRAE Work 展示的是以 Agent 为中心的“文档产物模式”;WPS 灵犀展示的是 Agent 与 Office 内核融合后的“文档工作模式”。
企业自研 Agentic AI 应用时,应先判断目标是“让 Agent 生成文件”,还是“让 Agent 进入 Office 与用户共同完成文档”。前者可以采用文档 Skill、模板和独立预览服务;后者则需要 WebOffice 级别的文档对象、排版、编辑和协作能力。
ONLYOFFICE DocumentServer 为第二条路线提供了可私有化集成的在线编辑基础,BaseMetas FileView 则可以承担 Agent 产物和业务附件的统一只读预览。真正可用的企业方案,需要在两类能力之上构建 Agent 编排、文件存储、权限、版本、回调、安全、审计和预览路由体系。
BaseMetas Fileview 1.2.0 介绍:https://basemetas.com/
社区版
OnlyOffice中文增强版最新镜像:
https://onlyoffice.moqisoft.com/docs/install/docker
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。