很多 AI 工具都会说自己能“生成文档”。
但在真实工作里,我们要的通常不是一段文字,而是一个可以交付的 .docx、.xlsx 或 .pptx。
合同有批注、修订记录和格式。预算表有公式、透视表和图表。PPT 有版式、图片、形状和动画。
这些文件对人来说是普通 Office 文档,对 AI Agent 来说却是复杂的 OOXML 文件包。
能读懂文字,不代表能稳定修改结构。能写出大纲,不代表能生成可交付文件。
iOfficeAI/OfficeCLI 要解决的,就是这个问题。它是一个面向 AI Agent 的 Office 文件操作工具,支持读取、创建、编辑和自动化 Word、Excel、PowerPoint 文件。
几个关键词:
- ●开源
- ●单二进制文件
- ●不需要安装 Microsoft Office
- ●支持 macOS、Linux、Windows
- ●可接入 Codex、Claude Code、Cursor、GitHub Copilot、OpenClaw 等 Agent 工作流
简单说,OfficeCLI 不是“命令行版 Office”,而是给 AI Agent 准备的一层 Office 文件基础设施。
为什么需要 OfficeCLI?
过去让 AI 处理 Office 文件,常见做法有几种。
把文件转成 Markdown,方便读取,但格式、表格、图片、批注会丢失。
把文件渲染成图片,方便查看,但图片本身不可编辑。
用 python-docx、openpyxl 等库分别处理 Word、Excel、PPT,能做一部分事,但工具分散,复杂格式覆盖有限。
直接调用 Microsoft Office 或 LibreOffice,保真度可能更好,但依赖桌面环境,不适合服务器、Docker、CI/CD 这类场景。

OfficeCLI 走的是另一条路:
用一个命令行工具直接操作 Office 文件结构,把复杂的 OOXML 细节封装成 Agent 可以调用的命令。
这让 AI 不再只是“建议怎么改文档”,而是可以真正去读、去改、去检查文件。
它是怎么工作的?
OfficeCLI 的能力可以分成三层。

读取和查看
通过 view、get、query 等命令,读取文档内容、结构、样式、公式,也可以返回结构化 JSON。
元素级编辑
通过 add、set、remove、move、swap 等命令,修改具体元素。
比如一页 PPT、一个 shape、一个 Word 段落、一个 Excel 单元格,都可以通过路径定位。
底层 XML 操作
当前两层不够用时,还可以用 raw、raw-set 处理更底层的 XML。
这套分层很适合 Agent:先用高层语义命令解决问题,必要时再深入到底层结构。
OfficeCLI 还有一个关键能力:渲染验证。
Agent 修改文件后,可以把结果渲染成 HTML 或 PNG 截图,再检查页面表现,然后继续修正。
这形成了一个闭环:
生成 → 查看 → 发现问题 → 再修改
对文档自动化来说,这比单纯“能写文件”更重要。
OfficeCLI 能做什么?
从官方 README 和 Wiki 看,它覆盖 Word、Excel、PowerPoint 三类文件。
Word 里,可以处理段落、表格、样式、图片、页眉页脚、脚注、批注、目录、超链接、修订记录等。
Excel 里,可以处理单元格、公式、工作表、表格、排序、条件格式、图表、透视表、数据验证、图片、批注等。官方还提到内置 350+ Excel 函数,并支持原生 OOXML 透视表。
PowerPoint 里,可以处理幻灯片、形状、图片、表格、图表、动画、转场、备注、主题、连接线、视频音频、3D 模型等。
它还支持一些适合自动化的能力:
- ●
batch:一次执行多条命令 - ●
dump:把已有文档转成可回放的 batch JSON - ●
merge:用 JSON 数据替换{{key}}占位符 - ●MCP server:方便接入 Agent 工具链
- ●SKILL.md:让 Agent 学会如何调用 OfficeCLI
OfficeCLI 不是只给人手敲命令用的,而是给 AI Agent 调用的。
它适合哪些场景?

OfficeCLI 最值得关注的场景,不是“人用命令行做 Office”,而是“各种 AI Agent 用它处理 Office 文件”。
今天很多 Agent 已经能理解需求、规划步骤、调用工具。比如 Codex、Qoder、WorkBuddy、Hermes、OpenClaw 等。
但它们都有一个共同问题:
一碰到真实 Office 文件,能力就容易断掉。
Agent 可以写内容,但需要一个稳定工具去真正读写 .docx、.xlsx、.pptx。
OfficeCLI 的位置就在这里。
它不是替代这些 Agent,而是成为它们处理 Office 文件时调用的底层工具。
比如:
Codex 可以用它根据项目数据生成 Word 周报。
Qoder 或 OpenClaw 可以用它把测试结果、性能数据、发布说明整理成 Excel 或 PPT。
WorkBuddy 可以用它批量替换合同里的公司名称、检查 Word 格式、更新 Excel 公式、整理 PPT 内容。
Hermes 可以把它放进长流程任务链:读取旧模板,理解结构,填充新数据,再渲染检查版式。

所以,OfficeCLI 的使用场景可以概括为四类:
给 Agent 补 Office 文件操作能力
Agent 负责理解任务和规划步骤,OfficeCLI 负责真正读写文件。
批量生成可交付文件
周报、月报、客户方案、销售 PPT、财务表、项目总结,都可以直接落成 .docx、.xlsx、.pptx。
修改已有 Office 文件
统一 PPT 品牌色、替换 Word 内容、更新 Excel 公式、检查标题层级、调整表格格式。
在无 Office 环境中运行文档工作流
很多任务跑在本地终端、服务器、Docker、CI/CD 或后台自动化环境里,不适合安装完整 Microsoft Office。
OfficeCLI 的单二进制和无 Office 依赖,正好适合这些场景。
它让 Agent 从“能写一段文案”,走向“能处理一份真实文件”。
但是也要看到边界
OfficeCLI 很值得关注,但不是万能替代品。
它不是 Microsoft Office 本身。复杂文档的版式和渲染,未必能和 Office 原生效果完全一致。
能修改文件,也不代表所有复杂文件都能无风险修改。尤其是复杂 Excel、深度嵌套 Word、带大量对象和动画的 PPT,都需要测试。
企业使用时,还要考虑文件权限、自动更新、配置写入、供应链安全等问题。

比较稳妥的方式,是先从低风险、高重复的场景开始:
- ●模板填充
- ●批量替换
- ●报告生成
- ●格式检查
- ●截图验证
流程稳定后,再进入更复杂的文档编辑。
写在最后
今天看 OfficeCLI,重点不是它支持多少命令,而是它代表的方向:
AI Agent 正在从“会说”走向“会做”。
在办公场景里,“会做”的一个重要标志,就是能处理真实文件。
Word、Excel、PowerPoint 仍然是企业协作和交付的核心载体。AI 如果无法稳定进入这些文件,就很难真正进入企业工作流。
OfficeCLI 提供了一种可能:
不用安装 Office,也能让 Agent 读取、编辑、渲染、检查 Office 文件。
未来的文档自动化,不会只是“AI 帮你写一段文字”,而是:
AI 帮你完成一份可交付文件。
从这个角度看,OfficeCLI 不是一个小工具,而是一块正在补齐的基础设施。
项目链接:https://github.com/iOfficeAI/OfficeCLI
如果你喜欢这篇文章
欢迎 点赞 评论 在看 转发
👇 欢迎关注我
夜雨聆风