夜雨聆风
推荐一个能让 Agent 操作 Word、PPT、Excel 的工具
但如果你真的把它放进日常办公流程里，很快会遇到一个很现实的问题：
AI 看纯文本很容易，但一碰到真实的 Office 文件，就没那么稳了。
Word、PPT、Excel 这些文件，表面上看只是“文档”，但它们并不是一坨纯文本。
一个 Word 文档里有段落、样式、表格、页眉页脚、批注、修订记录。
一个 Excel 表格里有公式、单元格格式、命名区域、条件格式、透视表、图表。
一个 PPT 里有 slide、shape、文本框、图片、图表、母版、布局、层级关系。
所以真正难的不是“让 AI 读出里面的文字”。
真正难的是：
它能不能知道自己正在改文档里的哪一个结构？改完以后，文件还能不能正常打开？格式有没有乱？
这也是很多 Agent 处理 Office 文件时最容易露馅的地方。
它可能能总结一个 Word 文档，但不一定能稳定修改第 3 段的样式。
它可能能读出一个 PPT 的标题，但不一定知道第 2 页右下角那个文本框到底是哪一个 shape。
它可能能分析 Excel 里的数据，但一旦涉及公式、图表、透视表，事情就不再是“读一个 CSV”那么简单。
这就是我今天装 officecli 时觉得它值得单独写一篇的原因。
officecli 是什么
简单说，OfficeCLI 是一个给 AI Agent 用的 Office 操作工具。
它想解决的问题，是让 Agent 能创建、读取、分析和修改 Office 文件。
它支持三类文件：
.docx
.xlsx
.pptx
也就是 Word、Excel、PowerPoint。
官方强调几个点：
-
开源； -
单个二进制文件； -
不需要本机安装 Office； -
无额外依赖； -
可以创建、读取、分析、修改 Office 文档； -
内置 HTML 渲染，可以把文档转成 HTML 或 PNG，让 Agent 有“看见结果再修改”的可能。
安装命令也很简单：
curl -fsSL https://d.officecli.ai/install.sh | bash
我本地安装了一下，目前版本是：
officecli 1.0.129
安装过程中它检测到了 Hermes Agent，并安装了对应的 Hermes skill：
Hermes Agent detected.
Installed officecli skill for Hermes Agent.
这说明它确实考虑了 Agent 接入场景，而不只是一个给人手动敲的命令行工具。
真正有用的是这层“结构接口”
如果只是把 Word 转成纯文本，很多工具都能做。
但 Agent 真正需要的不是“看一眼文档内容”，而是一个稳定的操作接口。
比如它要能做这些事：
查看文档结构
定位某个段落 / 文本框 / 单元格
查询哪些元素符合条件
修改某个元素的文字、样式、颜色或位置
新增或删除元素
修改后检查文档有没有坏
OfficeCLI 的命令基本就是围绕这套动作设计的。
读的时候有：
view
get
query
改的时候有：
set
add
remove
move
swap
改完以后还能：
validate
view issues
这就让 Office 文件从“一个黑盒二进制文档”，变成了 Agent 可以一步步操作的对象。
举个例子。
PPT 里一个元素可以被定位成类似这样的路径：
/slide[1]/shape[2]
Word 里的段落可以是：
/body/p[3]
Excel 单元格可以是：
/Sheet1/A1
有了这种结构化路径，Agent 才不需要靠猜。
它可以先读结构，再决定改哪里，改完再验证。
这比“你帮我改一下这个 PPT”然后模型在脑子里幻想文件结构，要靠谱得多。
这解决的是 Agent 的一个老问题
我觉得 OfficeCLI 最有意思的地方，不是它能不能生成一个 Word 或 PPT。
而是它把 Agent 处理非纯文本文件的流程变清楚了。
以前很多 Agent 工作流最舒服的对象是代码文件、Markdown、JSON、CSV。
因为这些文件天然适合被读、被 diff、被 patch、被验证。
但 Office 文件不一样。
它们是压缩包里的 OpenXML 结构，里面既有内容，也有样式、布局、关系和资源。
你让 Agent 直接改，很容易出现两个问题：
第一，它只拿到了文本，改不了真实结构。
第二，它真的去改底层 XML，又很容易改坏。
OfficeCLI 补的是中间这一层。
它不是让 Agent 直接裸改 XML，而是提供一组更高层的命令：读结构、查元素、改属性、加内容、做校验。
这对 Agent 来说很重要。
因为 Agent 真正需要的不是“会打开 Office”，而是能把 Office 文件纳入自己的行动链路。
怎么使用
如果你不是开发者，其实不用记 officecli 的命令。
更自然的用法，是直接用人话把任务交给 Agent，让它自己决定怎么调用工具。
比如处理 PPT，可以这么说：
帮我检查这个 PPT，每一页的标题、主要内容和明显格式问题都列出来。
顺便看看有没有空标题、字体不统一、元素遮挡、页面内容太挤的问题。
如果要改 PPT，可以这么说：
把这个 PPT 里所有“2025”改成“2026”，改完后帮我验证文件能不能正常打开，有没有结构问题。
处理 Word 文档，可以这么说：
帮我读一下这个 Word 文档，先总结结构，再指出哪些段落像 AI 写的。
如果要修改，先告诉我你准备改哪里，我确认后再动文件。
或者：
把这个 Word 里的“草稿”统一替换成“正式版”，保留原来的段落结构和样式，改完后跑一遍校验。
处理 Excel，可以这么说：
帮我检查这个 Excel，有没有空值、重复行、异常值，以及公式报错。
先给我一份问题清单，不要直接改原文件。
如果要做汇总，可以这么说：
根据这个 Excel，按月份汇总收入和支出，新增一个汇总 sheet。完成后检查公式和表格结构有没有问题。
这里的关键不是你会不会写命令。
关键是你可以开始把 Office 文件当成 Agent 能操作的对象，而不是只能让它“帮我看一下”。
以前 Agent 说“我改好了”，你不一定知道文件有没有坏。
现在至少可以让它在修改后跑一遍：
validate
view issues
也就是说，改完以后不是只靠嘴说，而是可以再走一遍结构校验和问题检查。
它的边界也要说清楚
我也试过用它生成一个小 PPT，确认它确实能创建 slide、文本框和基础样式。
但实际看下来，这个方向不适合作为文章重点。
它确实可以创建 PPT、添加 slide、放文本框、设置背景、字号、颜色和位置，也能读回大纲、检查问题、跑校验。
但生成出来的页面更像“结构化 PPT 文件”，不是那种可以直接拿去汇报的漂亮商业演示。
所以这里不要把它理解成“PPT 美化工具”。
它适合处理 Office 文件的结构层：创建、读取、定位、修改和验证。
它不适合单独承担审美设计、业务判断和复杂版式设计。
如果你期待的是“帮我做一套很好看的融资 BP”或者“自动设计一份精美发布会 PPT”，那它不能单独解决这个问题。
更合理的用法是把它放在流程里：
先让 Agent 规划内容
再用 officecli 操作 Office 文件结构
最后由人或更专业的设计流程做审美和版式判断
Excel 也一样。复杂模型里的业务口径、公式逻辑，不会因为用了一个 CLI 就自动正确。
所以更稳的做法是：重要文件先备份；修改前先确认计划；不确定命令属性时先查 help；修改后再跑校验和问题检查。
我会把它放在什么位置
我不会把 officecli 当成一个“自动办公神器”。
更准确地说，它适合放在 Agent 工作流里，负责 Office 文件那一层具体操作。
以前 Agent 处理 Markdown、代码、JSON、CSV 会比较顺，因为这些文件容易读取、修改和验证。
Office 文件麻烦一点，它有内容，也有样式、布局、公式、图表和各种内部关系。
如果 Word、PPT、Excel 也能被拆成可读、可改、可检查的结构，Agent 在办公文件里的可用范围就会大一些。
但这不代表它能自动替你完成所有办公工作。
它更像一个底层工具：把 Office 文件从“只能打开看”的文件，变成 Agent 可以按步骤处理的对象。
这就是我觉得它值得关注的地方。
如果你平时也会让 AI 处理 Word、PPT 或 Excel，可以先把它当成一个可选工具了解一下。
尤其是那些需要读取结构、批量修改、修改后校验的场景，它会比单纯让模型读文本更合适。
到这里，如果觉得这篇文章还不错，欢迎点个关注，也可以顺手点个赞、来个三连。
后面我会继续把自己折腾 AI 工具和 Agent 的真实过程、踩过的坑、跑通的办法，慢慢分享出来。
感谢你看我的文章，下篇见咯！