当 AI 学会＂看图＂:文档 Agent 的视觉校验,为何是事后质检而非主阅读方式

摘要：Codex、Claude Code 等编码助手处理 .docx 时，常先渲染成图片、再调用视觉模型"看一眼"。本文从 OOXML 结构、跨引擎渲染差异、全局约束满足三个层面解释其技术根源，并论证：视觉校验是一种"用计算成本换确定性"的工程妥协。

一、一个反直觉的现象

如果你观察过 Codex、Claude Code 这类编码助手处理 Word 文档，会注意到一个反直觉的细节：它们频繁地把 .docx渲染成图片，然后"看一眼"。

直觉上这很反常。.docx本质是 ZIP 包里的 XML，直接解析文本又快又省 token。为什么 Agent 要绕一大圈去"看图"？

答案藏在一个被广泛误解的问题里：文本解析和视觉校验，根本不是同一件事。

二、OOXML 的本质：ZIP 当 AI 学会"看图"：文档 Agent 的视觉校验，为何是事后质检而非主阅读方式容器中的"排版指令"

.docx格式遵循 Office Open XML 标准（ECMA-376，对应 ISO/IEC 29500）[1][2]。它不是一个二进制文档，而是一个 ZIP 压缩包，内部由若干 XML 部件（part）组成[3]：

• word/document.xml：正文内容
• word/styles.xml：样式定义
• word/header1.xml/ footer1.xml：页眉页脚
• word/media/：嵌入的图片资源

Agent 读取正文时，走的就是文本解析这条路——解析 XML、提取文本节点。这一步速度快、token 消耗低、信息精确。

但问题在于：XML 存储的是排版指令（layout instructions），而非排版结果（layout results）[3]。

一个典型的 <w:rPr>（运行属性）片段：

<w:rPr>
  <w:rFonts w:ascii="Calibri" w:hAnsi="Calibri" w:eastAsia="等线"/>
  <w:sz w:val="24"/>
  <w:spacing w:line="360" w:lineRule="auto"/>
</w:rPr>

它告诉你：西文字体 Calibri、中文字体等线（DengXian，自 Office 2013 起成为默认中文字体）[6]、字号 12pt（sz以半磅为单位，24 = 12pt）、行距 1.5 倍（line=360缇 ÷ 240 = 1.5 行）。

但它不告诉你：这行文字在当前页面宽度下会不会溢出？表格第三列的单元格会不会被撑破？图片与正文的锚定关系会不会导致分页位置偏移？

这些问题的答案，取决于渲染引擎如何解释这些指令——而渲染引擎的行为，由具体软件实现决定。

三、渲染层的不可预测性：两套引擎，两种结果

这正是 LibreOffice 与 Microsoft Office 之间兼容性问题的根源。两者使用完全不同的排版引擎，对同一份 XML 指令的解释存在系统性差异[4]：

1. 字体回退（font fallback）机制不同。MS Office 默认使用等线（DengXian）；LibreOffice 在缺少对应字体时，依 fontconfig 回退到 Noto Sans CJK SC 等替代字体。不同字体的字宽、行高、字距各不相同，直接导致换行偏移、表格溢出、分页漂移。

2. 分页算法（pagination）不同。Word 的分页考虑了"孤行控制（widow/orphan control）""段中不分页（keep with next）"等规则，Writer 的实现细节并不完全一致。同一份文档，Word 中 273 页、Writer 打开可能变成 291 页——页码差异在大文档上会被显著放大（注：示意性数字，说明量级差异，实际因文档而异）。

3. 复杂对象降级（object degradation）。LibreOffice 没有与 Microsoft 对等的 SmartArt 引擎；导入时，SmartArt 被读取为一组矢量形状，失去原有可编辑数据逻辑[5]。旋转文本框、3D 效果等对象在跨引擎时支持也不完整。这些降级在 XML 层面完全不可见——数据完好无损，视觉呈现已面目全非。

4. 浮动对象锚定（floating object anchoring）差异。图片、文本框、Shape 等浮动元素的锚定方式（锚定到段落 / 页面 / 字符）在不同引擎中的计算逻辑不同，导致位置偏移。

这些问题的共同特征是：它们存在于渲染层（rendering layer），而非数据层（data layer）。文本解析只能触及数据层，对渲染层的问题完全失明。

四、文档 Agent 的真实工作流：解析为主，校验为辅

理解了上述背景，就能看清当前文档 Agent 的典型工作流[7]：

1. 文本解析（主流程）。解析 docx 的 XML 结构，读取正文、样式、表格数据。快、省 token、精确——这是 Agent 理解内容的主要手段。

2. 修改 XML（执行流程）。根据任务直接修改 XML 节点：调字号、插段落、改表格、换图片引用。

3. 渲染并视觉校验（质检流程）。修改后，将 docx 转 PDF，逐页渲染为位图，再调用视觉模型"看一眼"。

视觉模型检查的内容包括：文字是否溢出单元格 / 文本框；表格是否跨页断裂且表头未重复；图片是否与正文重叠；页眉页脚是否正确；分页是否符合预期；字体渲染是否正常（有无方块字 / 乱码）。

若发现问题，Agent 回到第 2 步修改，再走一遍第 3 步——形成迭代闭环（iterative closed loop），直到视觉校验通过。

这正是 Codex 看起来在"疯狂看图"的原因：它不是用视觉替代文本解析，而是在反复执行事后校验。每步修改后"看一眼"，确认渲染结果符合预期才继续。这是一种保守但安全的策略，代价是 token 消耗显著增加[7]。

五、为何不能只做静态文本校验？

理论上可写规则引擎检查 XML 正确性（如验证列宽之和是否超页面宽度、图片锚点是否合法）。但这条路在实践中几乎不可行，因为排版是一个全局约束满足问题（global constraint satisfaction problem）。

一个局部修改会引发级联效应（cascade effect）：插入一段文字 → 段落变长 → 分页点后移 → 后续页码全变 → 目录需更新 → 页眉章节号变化。静态规则几乎无法覆盖所有连锁情况。

而渲染引擎天然是一个"全局求解器"——它一次性计算所有元素的最终位置。于是，让渲染引擎跑一遍、再"看一眼"结果，反而是最简单可靠的校验方式。

六、本质：用计算成本换确定性

回到最初的问题：为什么 Agent 要"看图"？

不是因为读图更快——恰恰相反，图片编码后的 token 消耗远高于纯文本。

而是因为文本解析存在结构性盲区：它能告诉你"数据对不对"，却无法告诉你"渲染结果对不对"。而渲染结果，才是用户最终看到的东西。

视觉校验本质上是一种"用计算成本换确定性"的工程妥协。它承认了一个事实：在文档处理领域，"看起来对"与"数据对"是两个不同的命题，而后者无法完全保证前者。

这种思路正成为 AI Agent 时代的一种工程范式——当 Agent 需要操作真实世界的复杂系统时，事后视觉校验可能比事前静态分析更可靠，因为视觉模型天然具备人类"看一眼就知道哪里不对"的直觉能力[7]。

只不过，这种直觉的代价，是成倍增长的 token 与延迟。而如何在准确性与效率间找到最优平衡点，是下一代文档 Agent 需要解决的核心工程问题。

参考来源

[1] ECMA International. Office Open XML File Formats (ECMA-376). https://www.ecma-international.org/publications-and-standards/standards/ecma-376/

[2] ISO/IEC 29500:2012 — Information technology — Document description and processing languages — Office Open XML File Formats.

[3] Microsoft Learn. Open XML SDK / WordprocessingML. https://learn.microsoft.com/zh-cn/office/open-xml/

[4] The Document Foundation. Feature Comparison: LibreOffice – Microsoft Office. https://wiki.documentfoundation.org/Feature_Comparison:_LibreOffice_-_Microsoft_Office

[5] LibreOffice Documentation. Images and Graphics / SmartArt import. https://books.libreoffice.org/

[6] Microsoft Support. 更改 Word 中的默认字体（等线自 Office 2013 起为默认中文字体）. https://support.microsoft.com/zh-CN/word/change-the-default-font-in-word

[7] Visual Verification 工程实践：paddo.dev《Visual Verification: Making Agents Prove Their Work》(2025)；sandbase.ai《多模态 Coding Agent：截图修 Bug 什么时候真的有效》(2026)。