别再自己操作Word/Excel 了:GitHub 上 3 款 Office Harness 横评,按场景选才不踩坑
- 2026-09-26 14:54:14
一、当 Agent 撞上 Office,第一道墙不是"会不会",而是"怎么装"
去年这个时候,让 AI 改一份 Word、改一个 Excel、改一页 PPT,你大概会这么干:
让 LLM 写一段 python-pptx / python-docx / openpyxl 代码; 自己跑; 跑出来不对,回去再让 LLM 改; 跑出来的格式全乱了,放弃,自己粘贴。
这套死循环的根本问题不在 LLM,在"LLM 没法直接动文件"。
2026 年的事情不一样了。GitHub 上冒出三个项目,把"Agent 怎么和 Office 文件打交道"这件事,做成了产品级别的能力:
- iOfficeAI/OfficeCLI
—— 一个二进制,三行命令搞定 Word / Excel / PowerPoint; - dream-num/univer
—— 一个 TS/Node 全栈 SDK,把整个 Office 套件跑在 Node 里; - genspark-ai/genoffice
—— 一整套带桌面应用的 AI Native Office,把 AI 装进文档模型里。
但工具一多,问题反过来——到底选哪个?
这是这一篇要回答的问题。我用同一个工作流,跑了三个项目,按"它给 Agent 什么、改起来麻不麻烦、谁能用"三件事做了一份横评。看完你会知道:
哪条路线适合你(CLI / SDK / 完整套件) 3 款工具各自的强项和短板 5 类不同身份的人,怎么选最省心
先放结论,再讲细节。
二、先认清三条路线,比看工具清单重要
在说工具之前,先把"Office Harness"这个词说清楚。
Harness 被借来翻译成"工作套件 / 控制台 / 适配层"——它真正的意思是:给 Agent 用的、可以直接指挥 Office 文件的中间层。
但三个项目对"中间层"的理解是不一样的:
| 路线 A:CLI Harness | |||
| 路线 B:SDK Harness | |||
| 路线 C:套件 Harness |
三件事对应三个完全不同的需求。先认清路线,再看工具。下面按路线分三类,每类挑 1 款重点讲。
三、路线 A · CLI Harness:OfficeCLI(iOfficeAI)
它是干什么的:一个二进制 + 一组 skill 命令,让 Agent 像调工具一样调 Office。
仓库地址:https://github.com/iOfficeAI/OfficeCLI
- 强项
: - 零依赖单二进制
:Go-like 安装体验,macOS / Linux / Windows 一个命令搞定。.NET runtime 已内嵌,不需要任何前置依赖。 - 三件套全覆盖
:Word(.docx)/ Excel(.xlsx)/ PowerPoint(.pptx) 都能读写、修改、分析。 - 三层架构
:L1 语义读(view 命令)、L2 元素操作(get / set / add / remove)、L3 原始 XML(raw / raw-set)。从"看"到"改"再到"底层",一条命令到底。 - Agent 友好的渲染引擎
:可以 view html/view screenshot/watch本地 HTTP 预览 —— Agent 改完能看见自己改的对不对,而不是"改完祈祷它没崩"。 - 公式引擎内置
:350+ Excel 函数在写完就自动计算,不需要打开 Office 重算。 - MCP 兼容
:Claude Code、Cursor、Windsurf、GitHub Copilot 都能直接接, curl -fsSL https://officecli.ai/SKILL.md就能让 Agent 自动学会。 - 短板
: 不是桌面应用——你拿不到 Word / Excel / PPT 的 UI,只能通过命令行和 Agent 交互。 模板能力相对薄弱,精细排版不如 Office 本身。 社区相对新,中文资源少;SKILL.md 和 GitHub README 是主要入口。 - 适合谁
:做 Agent 开发的工程师、需要给 AI 装一个"Office 工具"的团队、CI/CD 里自动生成报告的人。
四、路线 B · SDK Harness:Univer(dream-num)
它是干什么的:把整个 Office 套件装进 Node,让你自己的产品能嵌入完整 Office 能力。
仓库地址:https://github.com/dream-num/univer
- 强项
: - 15.7K Star
(截至 2026-09-23),Apache-2.0,生态已成。 - 同构(isomorphic)架构
:同一套代码,在浏览器里跑就是 UI,在 Node 里跑就是 Agent 后端——这件事是其他两家都没的。 - 插件优先
: @univerjs/presets(快速上手)和@univerjs/*单包(精细控制)两种集成模式。 - Facade API 统一
:workbook / worksheet / range / formula / document 一套就能调用,不需要记不同 API。 - Worktree 概念
:借鉴 Git 的分支模型,把 Agent 的修改放进"草稿",人审完再合并——这件事是其他两家都没有的。 - 配套 MCP
: univer-mcp把 Sheets 通过自然语言跑通,Agent 可以直接用"把 A1 加 5"这种对话操作表格。 - 公式引擎独立
: @univerjs/engine-formula是单独包,在 Node 里也能跑——Agent 可以在没有浏览器的环境里算 Excel。 - 短板
: - 不是开箱即用的桌面应用
——你要懂前端工程才能集成。 文档 / 演示模块相对 Sheets 单薄,处于追赶阶段。 需要 Node 22+ 环境。 - 适合谁
:做 SaaS 产品的团队、想在自己 BI / 表单 / AI 产品里嵌入电子表格的工程师、headless 数据处理流水线。
五、路线 C · 套件 Harness:GenOffice(genspark-ai)
它是干什么的:一整套 AI Native 桌面 Office 应用,把 AI 装进文档模型里。
仓库地址:https://github.com/genspark-ai/genoffice
- 强项
: - Apache-2.0
,完全免费、无广告、无水印。GenSpark AI 自身的 credit 系统只用于云端推理,本地编辑不消耗。 - Byte-preserving .docx 往返
:只重写你改过的那段 OOXML,其余保持原样——这是格式保真度的关键,改合同 / 投标 / 报告这种"差一个像素都不行"的场景特别有用。 - 6 个应用合一
:Docs / Sheets / Slides / PDF / Markdown / Shell,Electron 桌面应用。 - AI 装进文档模型而不是侧边栏
:Agent 直接在文档状态上操作,block 级 diff / 段落级 diff 都能看到——不是"AI 写完你复制粘贴",是"AI 直接改文档"。 - 跨平台
:macOS(Apple Silicon + Intel)/ Windows / Linux(.deb / .rpm / .AppImage)。 - BYOK
:Claude / OpenAI / Gemini / DeepSeek / Kimi / GLM / Qwen / Doubao / Grok / Mistral / OpenRouter 全支持。 - 配套 CLI + Agent Skill
:除了桌面应用,也有命令行和 Agent 安装包——路线 A / C 两用。 - 短板
: - Alpha 阶段
(v0.8.0 / 2026-08-23),bug 不少,生产环境需要测。 项目早期由单一工程师主导,长期可持续性有待观察(2026-08-03 Alpha 上线时由 1 人在 1 周内、用约 $10K token 成本造出来)。 Sheets 内核直接用 Univer,所以如果你既要桌面应用又要 headless,可以共用。 - 适合谁
:想换掉 Microsoft Office 的个人 / 小团队、需要 AI 写文档但又不想依赖云端 SaaS 的人、对文档格式保真有刚需的乙方。
六、3 款工具一张表速览
Star 数据采集时间:2026-09-22。GenOffice 的 Star 数增长极快(2026-07-31 创建,8 月底已达 7.4K+,9 月仍在持续攀升),其余两家也都在动。看 Star 是看趋势,不是看结论。
七、按你的身份选——5 类人各取所需
1. Agent 工程师 / Prompt 工程师要给 Agent 装一个"Office 工具" → 选 OfficeCLI(最像给 Agent 装"瑞士军刀",SKILL.md 让 Agent 自学)。
2. SaaS 创业者 / 产品经理要把自己产品里的电子表格换成可编程的 → 选 Univer(API 干净、Apache-2.0、可商用)。
3. 内容运营 / 写作者想要一个能写、能改、能 AI 改的 Office 应用 → 选 GenOffice(对写作者最友好,block 级 diff 最直白)。
4. 乙方 / 咨询顾问要给客户交 .docx / .pptx,又怕格式跑掉 → 选 GenOffice(byte-preserving 往返最稳)。
5. 数据团队 / ETL 工程师要在 CI/CD 里跑报告生成 → 选 OfficeCLI(单二进制、零依赖、Agent + CI 通用)。
九、避坑——5 个常见错误
1. 把 "Harness" 等同于 "Office 应用"。 OfficeCLI 不是给终端用户的产品,GenOffice 才是;反过来,GenOffice 也不是给 Agent 开发用的。装错路线,工具再强也救不回方向。
2. 把 "Univer 能干所有事" 当结论。 Univer 是 SDK 不是应用——你要会用 TS 才能用它。只想"换掉 Office 的人"应该去看 GenOffice,不是 Univer。
3. 装 GenOffice 就放弃自己写代码。 GenOffice 的 AI 写在文档模型上,但它没有剥夺你手写 .docx / .pptx 的权利——用 BYOK 模型切换,机器不是必须靠 Genspark 自己的 Agent。
4. 装 OfficeCLI 就以为"装完 Agent 就能用"。 OfficeCLI 装的是"工具",不是"智慧"——Agent 自己要会规划改什么、怎么改,OfficeCLI 只负责让 Agent 能动 Office 文件。
5. 只看 Star 数。 OfficeCLI 没有公开 Star,Univer 是 15.7K,GenOffice 是 7.4K——Star 数对应"生态活跃度",不直接对应"适合你"。先看路线,再看工具。
十、写在最后——选工具的标准不是"哪个最强"
把三款工具铺开,会发现没有"哪个最强"这件事。
真正的标准是三句话:
你想要 Agent 怎么用 Office?(命令式 / 嵌入式 / 独立应用) 你有没有前端工程能力?(决定能不能用 SDK) 你能接受"Alpha 阶段"的 bug 吗?(决定能不能用套件)
把这三件事答完,工具就只剩 1 个候选了。
9 月底,我的口袋清单是这三件:
- Agent 开发
→ OfficeCLI(给 Agent 装工具,最稳) - SaaS 嵌入
→ Univer(API 干净、可商用) - 替代 Office
→ GenOffice(写作者的 AI Native 桌面)
剩下的,按你今天要做什么事挑就行。
工具在变,Star 数下个月可能就不一样了。但选型的逻辑不会变——先把"路线"定下来,再谈工具。
来源与说明
数据采集时间:2026-09-22 至 2026-09-23。Star 数为 GitHub 公开页面读取的近似值,会随时间变动;建议以官方仓库页实时数字为准。
