Codex 读取被截断，仍继续审查与决策

Codex 读过文件，不代表它读完了文件。作者检查一支通过 Markdown 文件协作的 LLM agent 团队，发现输出被截断后，agent 仍会依据残缺的评审意见和工作计划继续决策。

问题不只是文档太长，而是多层输出预算叠在一起，模型反复漏设其中一层。作者最后用固定参数和补读规则改善了表现。这篇最值得带走的，是如何识别「工具返回成功，但证据并不完整」。

文件少了一截，为什么任务还能继续

作者团队的部分角色运行在 Codex CLI 0.165.0 上，工具调用采用 code mode。它们读取任务、评审结果、计划和设计文档，再决定下一步。

10 月 24 日，作者检查了围绕同一个目标工作的 33 个 Codex 会话：31 个至少出现过一次工具输出截断，总计 129 次。被截断的内容里，就有评审者的发现和正在执行的工作计划。

截断不会让调用失败。输出会出现类似 Warning: truncated output (original token count: 15382) 的警告，保留开头和结尾，删除中间内容，并留下 …4107 tokens truncated… 这样的标记。

对模型来说，这仍然是一次 cat 的返回结果。若它没有处理警告，就可能拿着文档的头尾作判断，而关键约束恰好留在被删掉的中间。

工具调用成功，只能证明拿到了结果，不能证明拿到了完整证据。

为什么把上限调到 40,000，仍然没解决

作者先调整了配置项 tool_output_token_limit。默认值是 10,000 tokens，而他最大的文档约有 39,000 tokens，于是把上限提高到 40,000。

但还有单次调用的 max_output_tokens，由模型设置。作者在另一个项目 codex-workflows 中，要求先用 wc -c 测量文件大小，再读取文件。这次为了省去频繁读取前的额外步骤，他只解释预算机制，让模型自行选择。

结果，工具输出仍有 11% 被截断，前一周是 13%。一次回放更暴露出异常：模型明明申请了 18,000 或 26,000 tokens，输出却都在约 10,000 tokens 处停止。

原因是第三层限制：code mode 中，命令运行在 JavaScript exec cell 内，整个 cell 返回的内容也有独立预算。没有首行 pragma 时，这层默认仍是 10,000。

作者统计五天日志中的 9,538 次调用，模型只写过 137 次 pragma。按原文所述，这对应已知问题 openai/codex#33402，自 7 月起处于开放状态。

这里有两件事要分清：配置上限、命令预算和 cell 预算都可能限制输出；多个命令放在同一个 cell 里，还会共同消耗 cell 的返回预算。只提高其中一层，另一层仍可能先截断。

固定参数之后，真正有用的是补读规则

作者两次重写说明，第二次明确强调两个预算取较小值。四次回放中，24 次调用仍有 19 次被截断，模型一次 pragma 都没写。

于是，他不再让模型逐次判断预算，而是给出固定指令，同时规定截断后的处理方式：

Start every `exec` call with the first line `// @exec: {"max_output_tokens": 40000}` and give every `exec_command` `max_output_tokens: 40000`. Output past the smaller of the two budgets loses its middle, marked `…N tokens truncated…`, and you miss whatever detail that middle held; without the first line that budget is 10000. Base a judgment only on text you received, reading again any cut part it depends on.

要看的是最后一句：判断只能依据实际收到的文本，依赖被截断部分时必须重新读取。单纯提高预算，不能保证文件一定完整。

随后三次回放中的 16 次调用，都携带了两层预算。仍有三次截断，每次都是批量读取至少八个文件，总量超过 40,000 tokens；但模型都返回去按范围补读了缺失内容。

这组结果支持的是：明确的固定动作，加上缺失内容的恢复规则，比这几轮实验中的自由预算选择更可靠。

我的判断

作者抓到了一个容易漏查的环节：agent 的决策质量，也受工具返回内容是否完整影响。评审意见读丢一段，后面的推理再认真，也可能建立在缺失的前提上。

但这些仍是作者单个团队的日志和少量回放，不能据此认定所有 Codex 工作流都有相同比例的问题。原文没有交代回放时的模型、完整运行配置，也没有提供严格对照实验。固定 40,000 是这套文档规模下的经验值，不能直接当成通用最优参数。

与先执行 wc -c 相比，固定预算更省步骤，却仍挡不住批量读取过量；而字节数也不能直接等同于 token 数。对于较长文档，按章节或行范围读取，再检查截断标记，依然有必要。

能拿来做什么

• 给依赖文件协作的 AI 编程流程增加一条硬规则：评审结论、验收条件或执行计划一旦截断，先补读相关部分，再继续决策。
• 使用原文所述 code mode 时，同时检查 exec 的首行 pragma 和 exec_command 的 max_output_tokens，并留意批量读取的总输出量。
• 先审计已有会话日志，确认截断是否真实发生。作者提供的命令兼顾普通日志和旧的 .jsonl.zst 压缩日志：

find ~/.codex/sessions -name '*.jsonl*' -exec zstd -dcqf {} + \
  | grep -oE '…[0-9]+ tokens truncated…' | wc -l

这里要注意 grep 匹配的是截断标记；统计结果能提示问题规模，具体缺了什么、是否影响判断，还要回看对应调用。