从 Office Skill 到 WebOffice：Agent 处理 Office 文档的两种实现方式

weixin_42258782

336人浏览 · 2026-07-31 08:00:00

weixin_42258782 · 2026-07-31 08:00:00 发布

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 操作还是自研工具，需要以实际版本为准。

二、最大的区别不只是生成技术，而是交互模式

1. 产物型 Agent：先生成文件，再预览结果

WorkBuddy、QoderWork、Kimi Work 和 TRAE Work 的典型链路是：

用户需求
  ↓
Agent 规划与内容生成
  ↓
DOCX/XLSX/PPTX Skill
  ↓
生成或修改 Office 文件
  ↓
产物预览器展示
  ↓
继续对话修改或下载文件

Agent 操作的是文件或文件结构，用户看到的通常是任务进度、文件版本和阶段性产物。即使执行过程中可以预览，也不等于在完整 Word 编辑器中逐步修改。

这种模式更像“交付一份文档”，适合：

自动生成报告、方案和会议纪要；
批量创建合同、通知和证明材料；
从 PDF、Excel 等资料生成 Word 报告；
后台无人值守的文档流水线；
生成后只需查看、下载或归档的场景。

2. Office 原生型 Agent：在文档中直接完成工作

WPS 灵犀依托 WPS 自有 Office/WebOffice 能力，链路更接近：

用户需求
  ↓
Agent 理解编辑意图
  ↓
调用文档对象、选区、样式和排版接口
  ↓
直接修改当前文档
  ↓
WPS 排版内核实时刷新

用户可以在一侧与 AI 对话，在另一侧查看文档内容、格式和分页变化。AI 不只是生成一个新文件，还可以围绕当前选区、段落、表格或页面持续修改。

这种模式更适合：

对现有复杂文档进行局部修改；
保留原样式、分页、批注和修订；
用户需要边看边改、随时接管；
需要完整 Office 编辑能力的专业创作；
多人协作、审阅和版本管理。

因此，WPS 灵犀的优势不只是拥有更好的 DOCX 生成工具，而是拥有从文档对象模型、排版内核到编辑界面的完整闭环。

三、企业自研 Agentic AI 的两条技术路线

路线一：文件生成工具加独立预览服务

该路线不引入完整 WebOffice，Agent 直接生成 Office 文件，再通过独立组件预览。

Agent
  ↓
结构化文档模型
  ↓
POI / docx-js / python-docx / OOXML / 模板引擎
  ↓
DOCX、XLSX、PPTX
  ↓
文件预览或转 PDF 服务

优点

架构较轻，易于拆分为异步任务；
适合批量生成和无人值守处理；
Agent、文档生成和预览可以独立扩容；
不需要长期维持在线编辑会话；
接入成本和资源消耗相对较低。

局限

复杂 Word 排版和格式保留难度较高；
局部修改可能破坏样式、编号、分页和浮动对象；
用户主要看到结果，缺少原生 Office 编辑体验；
批注、修订、公式、图表等高级对象需要深入处理 OOXML；
生成文件与实际预览效果可能存在差异。

该路线适合“Agent 生成、用户验收”的业务。对于 BaseMetas FileView 这类预览服务，可以承担权限控制、水印和嵌入式查看。Office 文档中，Excel 可采用浏览器端直接预览；Word、PPT 等其他格式则转换为 PDF 后展示，以兼顾还原度、稳定性和前端接入成本。

路线二：基于 WebOffice 的文档智能体

该路线将完整的在线 Office 引擎作为 Agent 的文档执行环境：

Agent
  ↓
文档操作接口
  ↓
WebOffice 文档对象与排版内核
  ↓
在线编辑器
  ↓
用户查看、修改、审阅和保存

企业如果无法使用 WPS WebOffice，或希望私有化部署，可以考虑 ONLYOFFICE DocumentServer。

优点

创建、修改和预览使用同一套 Office 内核；
用户可以直接看到最终版式；
支持在线编辑、批注、修订和多人协作；
更适合复杂文档和人机共同编辑；
Agent 修改后，用户可以立即接管。

局限

部署和集成复杂度更高；
需要处理编辑会话、回调保存、版本和并发；
资源消耗高于单纯文件预览；
Agent 需要把自然语言转换为稳定、可控的文档操作；
商业授权、并发规模和二次开发能力需要提前评估。

四、Agentic AI 与 ONLYOFFICE 的集成方案

ONLYOFFICE DocumentServer 是 ONLYOFFICE Docs 的核心服务，作为知名WebOffice产品之一，提供浏览器端的文档、表格、演示文稿和 PDF 查看与编辑能力，主要使用 DOCX、XLSX、PPTX 等 OOXML 格式。官方架构说明参见 How it works。

1. 总体架构

文件创建流程：

文件修改及预览流程：

其中，DocumentServer 负责在线编辑和协作，BaseMetas FileView 负责轻量只读预览。Agent 不应直接管理两类产品的内部文件，而应通过业务侧的文档操作服务统一处理权限、版本、锁、存储和预览路由。

2. 创建文档

创建新文档可以采用两种方式。

模板填充

企业预先准备合同、报告、通知等 DOCX 模板，Agent 负责：

理解用户需求；
检索业务数据；
生成结构化字段；
调用文档服务填充模板；
保存为新的 DOCX；
只读查看时通过 FileView 预览，需要编辑时通过 DocumentServer 打开。

模板方式可控性较高，适合格式固定的企业文档。

Document Builder 生成

ONLYOFFICE Document Builder 可以通过 JavaScript 脚本或 SDK 创建、打开、修改和保存文档，支持文档、表格、演示文稿、表单和 PDF。官方说明参见 Document Builder Overview。

典型链路是：

用户需求
  ↓
Agent 输出结构化文档计划
  ↓
文档服务生成 Builder 脚本
  ↓
Document Builder 创建 DOCX
  ↓
保存到对象存储
  ↓
按权限路由到 FileView 预览或 DocumentServer 编辑

需要注意，Document Builder 免费版本生成的文件带有水印，正式商用需要评估授权。安装与授权说明

Document Builder 是后台文档生成和修改工具，不等同于正在浏览器中运行的在线编辑器。它适合离线生成新版本；如果希望 Agent 操作用户当前打开的文档，还需要编辑器插件、前端桥接层或其他受控的文档对象接口。

3. 修改已有文档

修改可以分为后台自动修改和人机协同修改。

后台自动修改

适合批量替换、插入章节、更新数据和重新生成报告：

Agent 生成修改计划
  ↓
Document Builder 打开原文件
  ↓
执行文档对象操作
  ↓
保存为新版本
  ↓
通知用户预览

为避免破坏原文件，建议始终保存为新版本，并记录 Agent、模型、提示词摘要、修改范围和生成时间。

人机协同修改

适合合同审阅、方案编写和正式报告：

用户在 DocumentServer 中打开文档；
Agent 读取文档内容和用户选区；
Agent 给出修改建议或结构化操作；
文档操作服务将修改应用到文档；
使用修订或批注展示 AI 改动；
用户接受、拒绝或继续调整。

ONLYOFFICE 支持审阅模式，修改可以作为建议保留，由有权限的用户接受或拒绝。Reviewing

实际落地时，需要开发编辑器插件、前端桥接层或受控的文档操作服务，不能仅依靠大模型直接修改压缩包中的 XML。

4. 展示与预览

文档展示可以根据是否需要，选择 DocumentServer 或 BaseMetas FileView。

方案一：DocumentServer 在线预览与编辑

DocumentServer 可以使用 view 或 edit 模式打开文档，并通过权限配置进入审阅场景：

view：只读预览；
edit：完整在线编辑；
审阅：在编辑模式下结合 review 权限使用修订能力；
Live viewer：实时查看协作者的修改；
Common viewer：查看静态文档快照。

业务系统通过 api.js 嵌入编辑器，并向 DocumentServer 提供文件 url、文档 key、用户、权限和 callbackUrl 等配置。编辑器配置

该方案适合需要编辑、批注、修订、多人协作以及 Agent 与用户共同处理文档的场景。

方案二：BaseMetas FileView 在线预览

如果只要求查看 Agent 生成或修改后的文件，可以使用 BaseMetas FileView，其不仅支持office类文件的预览，同时支持CAD,3D，视频，代码等300种+格式文件预览：

Agent 生成或修改 Office 文件
  ↓
保存到本地或对象存储
  ↓
调用 FileView 预览入口
  ↓
Excel：浏览器端直接预览
Word、PPT 等：服务端转换为 PDF
  ↓
通过嵌入式查看器展示

该方案不提供完整 Office 编辑能力，重点是统一、稳定和低交互成本的只读预览。Word、PPT 等格式转换为 PDF 后，可以继续使用成熟的 PDF 查看能力，实现分页、缩放、搜索、水印、下载、打印和复制控制；Excel 保留浏览器端直接查看，以避免将大表格固定为分页文档。

与 DocumentServer 相比，FileView 更适合：

Agent 产物的快速验收；
OA、合同、档案和知识库附件预览；
高并发只读访问；
无需在线编辑的业务页面嵌入；
多格式统一预览和安全管控。

两种预览方案的定位

对比维度	ONLYOFFICE DocumentServer	BaseMetas FileView
核心定位	在线 Office 编辑与协作	多格式统一只读预览
Word、PPT 展示	Office 编辑内核直接渲染	转换为 PDF 后预览
Excel 展示	在线表格编辑器	浏览器端直接预览
在线修改	支持	不支持
批注、修订、协作	支持	以查看和权限控制为主
资源与集成成本	相对较高	相对较轻
典型场景	人机协同编辑、合同审阅、多人协作	Agent 结果验收、附件查看、归档和知识库

如果大量用户只需要查看文件，不建议全部进入完整的 DocumentServer 编辑会话。业务系统可以根据权限和用户动作动态路由：

默认查看
  → BaseMetas FileView

点击“在线编辑”或进入审阅任务
  → ONLYOFFICE DocumentServer

Agent 后台创建或批量修改
  → 文档工具 / Document Builder

五、集成时的关键设计点

文档标识与版本

DocumentServer 使用文档 key 识别编辑会话。同一协作文档应使用相同的 key；文件产生新版本后，需要按规则更新 key，避免旧缓存和新文件混用。Co-editing

保存回调

DocumentServer 不负责永久保存业务文件。编辑结束后，它通过 callbackUrl 通知业务系统获取最终文件，业务系统必须完成下载、存储、版本登记和状态更新。Saving file

安全认证

DocumentServer 与业务系统之间应启用 JWT，保护初始化配置、文件地址、命令和回调，避免配置被篡改。Security

Agent 操作边界

Agent 不应获得不受限制的文件和编辑权限。建议将操作抽象为白名单工具，例如：

读取指定文档；
获取当前选区；
插入或替换指定段落；
添加批注；
创建修订；
更新指定表格；
保存为新版本。

涉及覆盖原文件、删除内容、接受全部修订和对外分享时，应增加权限校验和人工确认。

并发与冲突

需要明确 Agent 与用户是否可以同时编辑。较稳妥的策略是：

后台批量任务执行时锁定对应版本；
在线协作时，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 编排、文件存储、权限、版本、回调、安全、审计和预览路由体系。