最近我们在查 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
夜雨聆风