乐于分享
好东西不私藏

Codex 是怎么读取 PDF 的?

Codex 是怎么读取 PDF 的?

最近我们在查 Claude Code 是怎么读 PDF 的。顺着这个问题,我们又想知道:同样把一份 PDF 交给 Codex,它走的是不是同一套流程?

查下来,两者并不一样。Codex 没有一个统一的 PDF 阅读器。你在本地 Codex 里让它读工作区文件、通过 Responses API 上传 PDF,或者把 PDF 放进 File Search,背后走的是三套不同的流程。

这个区别会直接影响 Codex 能看到什么。本地 Codex 通常先调用工具抽取文字、检查文件结构,再把页面渲染成图片;Responses API 会把抽出的文字和每页图像一起交给模型;File Search 则先把长文档切成片段,只找与问题相关的部分。下面把这三种情况分开讲清楚。

先把三个“读 PDF”分开

如果只记一个结论,可以记这张图:本地 Codex、Responses API 和 File Search,模型最后拿到的材料并不一样。

这意味着,同一句“我已经读了 PDF”,背后可能是逐页检查,也可能只是抽了文字,或者只检索了几段相关内容。判断答案靠不靠谱之前,最好先问清楚它走的是哪条路。

本地 Codex 怎么读工作区文件

截至 2026 年 8 月 24 日,OpenAI 的 Codex CLI 命令参考列出了图片附件参数 --image,没有列出 PDF 专用附件参数。

所以,在我们当前使用的 Codex 环境里,让它读工作区中的 PDF,更像是交给 Agent 一项文件任务。它通常会先看页数和文件状态,再抽取能复制的文字;遇到表格、图表或复杂排版时,把页面转成图片;如果是扫描件,再增加 OCR。

这里真正值得看的不是工具名,而是过程记录:它看了多少页?哪些页做了 OCR?图表页有没有渲染?如果这些步骤没有发生,最后一句“已经读完整份报告”就没有足够依据。

本地工具链的好处是灵活。一张表看不清,可以单独放大;怀疑数字有问题,可以同时对照抽取文字和页面原图。风险也在这里:这些检查需要 Agent 真的去做,不是文件扩展名叫 .pdf 就会自动完成。

Responses API 会同时提供两种材料

如果开发者把 PDF 作为文件输入交给 Responses API,OpenAI 官方公开的处理方式是:提取 PDF 里的文字,同时把每一页作为图像交给支持视觉的模型。

文字适合搜索名字、段落和数字;页面图像保留表格位置、扫描内容、颜色和版面。两者放在一起,确实比只拿到其中一种材料更完整。

但这仍不是双保险。文字层可能本来就是错的,页面图像也可能因为字号太小或旋转而看不清。官方没有公开具体使用什么 PDF parser、OCR 引擎,也没有说明文字和页面显示发生冲突时,内部一定听哪一个。

所以我们可以确认“模型收到了什么”,不能从这里直接推出“模型一定读对了”。

File Search 解决的是“找到”

对于几百页的报告或者一批 PDF,File Search 会先把内容切成小段、建立索引,收到问题后再找相关片段。官方文档把它描述为语义搜索和关键词搜索。

它很适合做一件事:从大量文字里快速找到可能有用的部分。

它不等于逐页视觉阅读。一个问题如果依赖跨页表格、图例颜色,或者两页之后的限定条件,相关内容没有被召回,模型就没有机会看到完整证据。

那 Codex 怎么尽量读准

我们没有查到一个能保证正确的单一机制。更可靠的做法,是让几种材料互相核对。

比如表格里写着 -3.8%。文字抽取可能漏掉负号,OCR 可能认错小数点,页面图片又可能因为字号太小而看不清。只信其中一路,很容易把“下降 3.8%”写成“增长 3.8%”。

因此,重要 PDF 至少要做几件事:

  • 先确认页数和文件状态,避免一开始就漏页;
  • 抽取文字用于定位,但不要只靠文字判断版面;
  • 把表格、图表和扫描页渲染出来看;
  • 扫描件做 OCR 后,回到页面原图核对;
  • 对关键数字检查主体、日期、正负号、小数点、单位和限定条件;
  • 留下页码、表号或章节,让别人能重新找到证据;
  • 如果不同结果互相冲突,就把冲突说出来,不要猜一个确定答案。

这套方法的价值,是让阅读过程更容易检查。它是否能把错误降低多少,还需要真实测试,不能先写成一个漂亮的准确率。

“支持 PDF”不等于“保证读对”

OpenAI 的视觉文档已经明确提醒:小字号、旋转文字、中文等非拉丁文字、图表颜色和线型、空间关系、精确计数,都可能出错。模型也仍然可能给出错误描述。

所以,“可以上传 PDF”只是在说输入能力。要证明它读得准,还需要具体文件、具体问题、事先确定的标准答案,以及能被复查的评分规则。

目前我们还不知道,本地工具链、API 的文字加页面图像、File Search 和纯文字路线,在真实 PDF 上分别会错在哪里;也不知道什么分数才足以支持摘要、关键数字抽取或合同审阅。

关于评分,我们只走到第一步

我们已经用 4 份人工 PDF、7 页、18 道题跑通了一轮很小的验证流程。过程中还发现,自动评分器会把一句带有 not 的正确回答判错。修订规则后,这组样本是 18/18。

这个结果只能说明测试链路跑通了。文件是人工生成的,只运行了一次,评分规则也在过程中改过。它不能叫“Codex 读 PDF 的准确率”,更不能拿来和 Claude Code 排名。

下一轮会换成公开的真实 PDF,先把标准答案和评分规则冻结,再比较不同读取路径。到时我们会公布具体错题,而不是只放一个平均分。

Claude Code 是怎么读取 PDF 的,我们也会单独写一篇。等真实样本跑完,再写第三篇,专门讨论:AI 说自己读完 PDF 后,我们到底怎么判断它有没有读对。

这篇先把已经查清的部分分享出来。没有查清的,继续查。


资料来源

  • OpenAI Codex CLI Reference
  • OpenAI File inputs
  • OpenAI File Search
  • OpenAI Retrieval
  • OpenAI Images and vision limitations