DeepSeek对Office.js与WPS JS的比较（二）
Office Web Add-ins 已进化为“Copilot 的扩展界面”，其首要定位不再是单纯的办公自动化工具，而是微软智能生态的代理节点；WPS 加载项仍是“办公能力的增强工具”，其核心使命是服务中国本土复杂办公场景、提供高兼容性的自动化方案。两者已走上截然不同的技术演进路径。
一、架构与运行机制：智能代理 vs 本地增强
对比维度 | Office Web Add-ins | WPS 加载项 |
运行模式 | 用户手动触发 + 后台事件静默激活 + Copilot 代理调用。插件可注册为 Copilot 的工具，由 AI 在适当时机自动调用完成业务操作，无需用户介入 UI。 | 仅限用户手动触发。必须通过功能区按钮、菜单项或任务窗格显式启动，无后台静默执行能力，无法由系统或 AI 代理自动唤醒。 |
渲染内核 | WebView2 (Edge Chromium) 已全面替代 IE/Edge Legacy，现代前端框架（React/Vue）可原生运行，彻底摆脱历史兼容性包袱。 | 内嵌 Chromium 内核，自始采用现代架构，支持完整前端技术栈，UI 渲染性能与 Web 端无差异，与 Office 已拉平内核代差 。 |
与宿主的交互深度 | API 覆盖标准 Office 对象模型，面向云文档、协作、AI 集成优化。对极端复杂排版、国产化报表格式的支持仍弱于 WPS。 | 毫秒级响应的本地 API 调用，深度支持中国式复杂报表（合并单元格智能填充、跨表联动引用、金融级精度浮点运算），这是 Office 生态不具备的本土化能力 。 |
二、开发与分发生态：统一智能体 vs 灵活接地气
对比维度 | Office Web Add-ins | WPS 加载项 |
开发工具链 | Microsoft 365 Agents Toolkit：单一 Manifest 同时描述加载项与 Copilot 代理行为，一体化调试 AI 交互、API 模拟、身份验证。跨应用统一开发（Word/Excel/Outlook/Teams 共享核心代码）已成标准实践。 | wpsjs 命令行工具：脚手架生成、热更新调试、打包发布。各产品线（文字/表格/演示）API 存在差异，尚无统一代理开发框架 。 |
跨平台能力 | 原生跨平台：同一套代码运行于 Windows/macOS/iOS/Android/Web，API 行为高度一致。 | 一次开发、多端部署：支持 Windows/macOS/Linux/Android/iOS/Web，但移动端需主动适配触控交互，部分 API 在 Web 端存在降级 。 |
离线与内网部署 | 显著改善：事件激活机制使内网自动化插件成为标准方案，无需用户点击即可在文档打开时静默执行合规检查、数据同步等任务。仍依赖 HTTP 服务，无法打包进文档。 | 传统优势保持：纯离线运行、文档级 JS 宏（代码随文档分发）、内网共享文件夹部署。无需服务器、无需商店审核，仍是国内中小企业最易落地的方案 。 |
分发管控 | 应用商店为主，企业可通过集中目录服务部署，个人开发者上架门槛较高。 | 极其灵活：网页一键安装、本地安装包、内网共享、文档内嵌。开发者分发零成本 。 |
三、API 能力与功能边界：生态广度 vs 场景深度
对比维度 | Office Web Add-ins | WPS 加载项 |
通用办公自动化 | 完备的文档读写、格式设置、事件监听。异步 API 模型（Promise + context.sync），符合 Web 规范但 VBA 开发者需适应。 | 同步/异步混用 API，大量命名与行为向 VBA 靠拢，VBA 开发者迁移成本极低。支持JS 宏录制，用户操作可反向生成代码 。 |
专属领域能力 | 标准全球化能力：无对中国本土报表格式的特殊优化。 | 国产化增强：合并单元格智能填充、跨 Sheet 跨文件联动引用、符合国标的审计追踪日志、金融级精度浮点运算。这些是 Office 无法替代的核心差异 。 |
自定义函数 (UDF) | 仅限 Microsoft 365 订阅用户，永久授权版 Office 无法使用。 | 全版本支持，无订阅限制，企业存量用户可无缝使用 。 |
PDF 与跨格式能力 | 无原生 PDF 编辑 API，需依赖外部服务或文件转换。 | 内置 PDF 表单字段映射、批注、水印控制 API，与文档处理能力同源 。 |
四、AI 集成能力：决定性分野
这是当前 Office 与 WPS 加载项体系最根本的能力鸿沟，无任何模糊地带。
对比维度 | Office Web Add-ins | WPS 加载项 |
AI 能力对开发者开放程度 | 完全开放：插件可注册为 Copilot 的代理工具。开发者通过 Manifest 声明插件能力，Copilot 在适当时机（如用户自然语言请求）自动调用插件完成业务操作。这是标准化的、文档化的开放能力。 | 未对第三方开发者开放：WPS AI 是面向终端用户的内置功能（写作、摘要、PPT生成），加载项无法调用 wps.ai 系列 API。开发者无法让自己的插件被 WPS AI 代理调用。 |
插件与 AI 的关系 | 插件是 AI 的扩展：Copilot 是大脑，插件是手和脚。 | AI 是插件的竞品：WPS AI 是独立功能，与第三方加载项形成替代关系，而非协作关系。 |
外部 LLM 集成 | 标准化实践：插件可自由调用任意云端 LLM（OpenAI、AWS Bedrock、Azure OpenAI），将生成内容写回文档。生态已形成成熟案例。 | 能力未释放：加载项可发起网络请求调用外部 LLM，但无官方优化指引或标准化集成方案，依赖开发者自行实现。 |
五、选型决策指南：当前状态下谁适合什么
✅ 坚定选择 Office Web Add-ins 的场景
你需要让插件具备 Copilot 代理能力——这是 WPS 加载项无论如何都无法实现的能力，单点即可决定选型。
深度绑定微软 365 生态（Teams、SharePoint、Outlook），需跨应用统一体验。
面向国际客户，必须上架 AppSource 全球分发。
项目强制要求 TypeScript 与前沿 Web 架构，追求开发生态的规范度。
✅ 坚定选择 WPS 加载项的场景
你的最终用户以 WPS 为主（政府、国企、教育、传统制造业），这是无法绕过的前提。
需要纯离线运行，文档发给客户就能执行自动化任务。
核心痛点是中国式复杂报表（合并单元格、多级表头、跨文件引用），Office.js 无法优雅解决。
开发团队从 VBA 转型，希望复用既有对象模型思维，通过录制宏快速上手。
需要零成本分发、零服务器部署，不希望被应用商店审核流程卡顿。
客户使用 Office 永久授权版，且需要使用自定义函数——Office 订阅制门槛在此场景下是硬伤。
最终陈述
Office Web Add-ins 与 WPS 加载项的当前差异，本质是“生态定位”的根本分化。
微软将加载项体系升级为 Copilot 的代理网络，插件不再是孤立的自动化工具，而是智能助理的能力延伸。这是一条高门槛、高上限的技术路线，开发者付出学习成本的同时，获得的是进入微软智能生态的入场券。
金山将 WPS 加载项持续打磨为 “VBA 的现代替代者”，在保持低门槛、高兼容性、强本土化的传统优势基础上，不断填补 API 覆盖的空白。这是一条务实、接地气、高回报的技术路线，尤其在中国存量企业市场中具备极强的生命力。
两者已无需强行分出优劣——它们正在服务完全不同的开发者群体与业务场景，且各自在专属赛道中建立起了对手难以逾越的护城河。
