先说一个核心判断：办公软件这个品类，终于开始被重新定义了。

你有没有想过这个问题——我们日常用的办公软件，从设计之初就是给人准备的。Word 的菜单栏、Excel 的公式栏、PPT 的动画窗格，每一个按钮、每一个交互逻辑，都是为人类的视觉和操作习惯服务的。

但 AI Agent 不一样。它不用眼睛，也不用鼠标。它需要的是能直接读写的文档接口。不需要“另存为”对话框，不需要“是否保存更改”的弹窗，不需要任何 GUI。它要的是一个能塞进命令行里的 Office。

这就叫需求倒逼供给。

而 OfficeCLI，恰好就是干这件事的。而且它开源了，MIT 许可。

这是全球第一个专为 AI 智能体设计的开源 Office 套件。一个单二进制文件，不需要安装 Microsoft Office，不需要任何依赖。扔到服务器上就能跑。

它能干什么？三件事：创建、读取、修改 Word、Excel、PowerPoint 文件。就这三件。但对 AI Agent 来说，这三件事就是全部的生产力。

过去 AI Agent 要想操作 Office 文档，要么调 Office 的 COM 接口（Windows only，还得装 Office），要么用各种 Python 库硬拼——格式保真度一塌糊涂。现在一个二进制文件全搞定。

更关键的是它的工作方式。OfficeCLI 内置了一个 HTML 渲染引擎。它先把 .docx、.xlsx、.pptx 转成 HTML 或 PNG 图片，让 AI Agent “看见”文档长什么样，然后 Agent 做出修改，再把修改后的内容渲染回来检查。

这个“渲染、查看、修复”的循环，是 OfficeCLI 最聪明的设计。

AI Agent 不需要知道文档的内部结构，不需要理解 OOXML 格式规范。它只需要像人一样“看”文档、“改”文档、“检查”文档。只不过整个过程是全自动的。

它支持的格式复杂度远超预期。公式、图表、条件格式、RTL 布局、修订追踪、数据透视表——这些在传统 Office 库中经常翻车的功能，OfficeCLI 都能处理。

还有一个细节：它提供了两种使用方式。CLI 命令行给开发者用，AionUi 桌面应用给普通用户用。后者基于自然语言交互，你不需要记任何命令。

更重要的是生态集成。OfficeCLI 可以一键安装到 Claude Code、Cursor、Windsurf、GitHub Copilot 等主流 AI 编程工具中。

这意味着什么？意味着你的 AI 编程助手不仅会写代码了，还会处理文档了。一个 Agent，既能写代码，又能写报告，还能做 PPT。这才是真正的 AI 工作流。

它的定位也很有意思。作者明确表示：这是给 AI Agent 用的办公套件，不是给人用的替代品。人继续用 Microsoft Office 或 WPS，AI 用 OfficeCLI。两条并行轨道。

但这个定位恰恰说明了一个趋势：AI Agent 正在形成自己的“操作系统”。它们需要自己的文件系统、自己的进程管理、自己的办公套件。

OfficeCLI 只是这个趋势中的一个节点。但它是第一个把“AI 专用 Office”这个品类做出来的项目，而且选择完全开源。

MIT 许可意味着你可以把它塞进任何商业产品里，不需要开源你的修改，不需要付费，不需要署名。这是最高级别的“拿去用”。

回到开头那个问题：办公软件是不是一定要给人设计？

OfficeCLI 的回答是：不一定。未来会有两套办公软件，一套给人用，一套给 AI 用。人会越来越少地直接操作文档，越来越多地通过 AI Agent 间接完成。

你告诉 AI 你要什么，AI 自己去写 Word、做 Excel、生成 PPT。

而 OfficeCLI，就是 AI 手里的那支笔。

这个项目的 GitHub 仓库刚上线不到一周就收获了数千颗星，Hacker News 首页挂了整整一天。开发者社区的反应说明了一件事：AI Agent 的“基础设施饥渴”是真实存在的。

我们可以做一个类比。移动互联网爆发之前，先爆发的是开发者工具。iOS 和 Android 的 SDK、Xcode、Android Studio，这些工具让开发者能高效地为移动端写应用。

现在 AI Agent 也在经历同样的时刻。我们需要的不是一个更好的 ChatGPT，而是一整套让 Agent 能工作的基础设施。文件系统、进程管理器、浏览器、办公套件、代码编辑器。每一个品类都需要“Agent-first”的版本。

OfficeCLI 开了一个头。下一个被重写的会是什么？Agent-first 的浏览器？Agent-first 的邮件客户端？Agent-first 的数据库？

问题不是“会不会有”，而是“谁先做出来”。

回头看 OfficeCLI 的技术实现，有一个选择特别值得玩味。它没有选择去解析 OOXML 格式（微软 Office 的底层格式，极其复杂），而是做了一个 HTML 渲染引擎。把文档转成图片，让 AI 看图理解，再反向操作。

这是一个“退一步海阔天空”的设计思路。不去追求 100% 的格式保真度，而是追求 100% 的 AI 可理解性。因为在 AI Agent 的工作流里，“让 AI 看懂”比“完美还原”重要得多。

这跟人类使用办公软件的方式形成了有趣的对照。人需要所见即所得（WYSIWYG），因为人依赖视觉反馈。AI 不需要 WYSIWYG，AI 需要的是结构化和可编程性。OfficeCLI 恰好提供了后者。

另外值得注意的是，OfficeCLI 支持的功能远比看起来多。公式编辑、条件格式、数据透视表、修订追踪、RTL 布局，这些在传统的 Python Office 库（比如 python-docx、openpyxl）中经常是雷区。一旦遇到复杂格式，库就挂了或者输出面目全非。

OfficeCLI 通过 HTML 渲染引擎绕过了这些坑。因为浏览器天然支持这些复杂排版，只要能把 Office 文档准确地转成 HTML，就能准确地渲染，就能让 AI 准确地理解。

这也是为什么它敢做“单二进制文件”。正常情况下，你要处理公式渲染，至少需要一个 MathJax 或 LaTeX 引擎。要处理图表，需要一个完整的图表渲染栈。OfficeCLI 把这些都包进了那个二进制文件里。

对于一个 AI Agent 来说，这个二进制文件就是它的生产力工具。就像终端是人操作电脑的入口，OfficeCLI 是 AI 操作文档的入口。

这个项目在 GitHub 上线的第一周就冲上了 Hacker News 首页。评论区最高亮的回复是：“终于有人做了这件事。我们等了两年。”

两年。从 2024 年 AI Agent 概念火了开始，所有人都在说 AI 要接管工作。但让 AI 接管工作的第一步，是先给它工具。

OfficeCLI 给了一个工具。下一个是谁？