一句话看懂：有开发者在 Codex 本地运行环境中发现了完整的 LibreOffice 依赖包，这意味着 OpenAI 正在为 AI 智能体直接读写文档、表格和演示文稿提前铺好底座——这不是聊天功能的小升级，而是代理式 AI 处理办公文件的基建动作。
事件核心：发生了什么
根据 Hacker News 上的用户反馈，在 ChatGPT/Codex 桌面应用首次运行后，本机缓存目录 codex-runtimes 的依赖列表中出现了 libreoffice-headless、poppler、libheif、jxrlib 等组件。其中 LibreOffice 是完整版的无头模式，而非简化包。
该发现来自 Windows 和 macOS 端的实际安装日志，有用户在 macOS 首次运行后看到该依赖，Windows 上则未出现，说明不是所有平台的安装包都默认捆绑，但至少一部分安装路径已经预置。被发现的版本还包含 PowerShell 和 Git 等工具，表明 Codex 的本地运行时架构比此前外界猜测的更为“重”。
值得注意的是，有用户提到即使不启用 Computer Use 等高级功能，仅用 Codex 做代理式编程，这些依赖也会被拉取。这说明 LibreOffice 不是某个实验性功能的可选组件，而是默认为整个智能体运行环境提供文档能力。
为什么重要
LibreOffice 是 Mozilla Public License 下发布的开源办公套件，包含了数十年积累的文档格式解析和渲染逻辑。OpenAI 选择将其打入端侧运行时，而不是简单调用云端 API 或等待模型直接输出格式，说明 AI 智能体在处理实际文档时，仍需要传统软件层来保证格式兼容性和文件解析可靠性。
这释放了一个清晰的信号：代理式 AI 的下一个战场不只是写代码，而是直接操作办公文档。ChatGPT/Codex 桌面版正在从一个“对话工具”变成“能打开、修改、生成 .docx、.xlsx、.pptx 文件的电脑管家”。这也侧面回应了微软在 Copilot 上的布局——OpenAI 正在用开源组件在自家应用中复刻类似能力，而不是依赖微软的 Office 生态。
从技术路线看，引入成熟开源组件而不是靠大模型直接输出文件，也说明当前模型在处理复杂文档结构时仍有天花板，厂商倾向于用“模型+传统工具”混合架构来降低出错率。
对用户/开发者/创作者的影响
对普通用户而言，如果 Codex 后续开放文档处理能力，意味着你可以直接用自然语言让 AI 整理表格、生成演示文稿或批量修改文档格式，而不需要手动下载模板或使用宏。但要注意，携带完整 LibreOffice 运行时会显著增加本地磁盘占用和首次启动负担，在低配 Windows 设备上可能带来类似 Hacker News 用户反馈的卡顿问题。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对开发者来说，这提供了一个可参考的开源依赖整合路径：与其让模型直接生成复杂格式，不如在本地预置成熟解析引擎，让模型调用外部工具完成文件操作。同时，这一做法也可能暗示 OpenAI 正在推进 Codex 本地执行环境的标准化——跨平台依赖管理将成为智能体开发的重要课题。
对内容创作者和办公软件生态使用者而言，若该能力正式开放，文档生成的技术门槛会大幅降低，但“AI 生成的文档是否兼容 WPS/Office 格式”仍是实际问题，LibreOffice 的兼容性记录并不完美，实际体验有待验证。
值得关注的后续
目前公开信息显示，LibreOffice 被内置进 Codex 运行时是客观存在的，但 OpenAI 尚未正式宣布任何文档处理功能。接下来值得关注三点：
一是 OpenAI 是否会在桌面版中开放面向普通用户的文档编辑入口，还是仅作为 Codex 智能体内部处理文件的底层工具；二是这一依赖是否会被逐步推广到 Windows 全量安装包，并优化安装体积和启动性能；三是微软的 Copilot 和 Google 的 Gemini 是否会跟进相似路径，在端侧同样捆绑办公套件，从而引发新一轮“AI 办公运行时”竞赛。
来源：hackernews
