上周处理一份 300 页的投标文件让 agent 一上来就整读全文document_get_text直接甩回一个DOCUMENT_TOO_LARGE。当时第一反应是这什么破限制把机制看完之后我收回这句话——这个阈值拦的不是我是我自己都没意识到的坑。踩坑复盘如下。机制约 80k 的阈值两条出路document_get_text在文本超过约 80k 时会拒绝整读同时给出两条路一是加force:true强制整读二是改用document_chunks按 cursor 加 limit 的方式分页分块读。另外document_meta会返回文档的名称、字数、段数以及是否建议分块的判断——也就是说工具会提前告诉你这份文档该不该分块前提是你先问一句。这一步的价值别小看有些文档字数没超但段落结构碎比如几十个短表格拼起来的照样建议分块有些文档页数看着吓人纯文字量其实在阈值内整读毫无压力。先问元数据等于让工具替你做一遍预判。为什么不该无脑 force:true气头上我也想过全程 force冷静下来算了三笔账Token 成本一份超阈值文档几十万字符灌进上下文贵的不只是这一次调用——多轮对话里每轮都驮着这座山账单是复利式上涨的。2026 年大家都在谈 Token 成本优化大文档整读就是最大的隐形开销之一。质量损耗长上下文的中间遗忘不是玄学塞得越满模型对中段内容的注意力越差校对反而漏得更多。实测感受是超过一定长度后模型对开头结尾还算认真中段的错字漏检明显变多——不是模型不行是注意力预算就那么多摊到每个字头上了。而全文校对最需要的恰恰是中段。写回风险一次整读的 agent 倾向于一次全改误报面积跟着放大分块校对、分块确认每块的爆炸半径都是可控的。正确姿势先问元数据再分块我现在跑大文档的固定顺序先调document_meta看字数和是否建议分块的提示建议分块就用document_chunkscursor 加 limit 一页一页读每块校对完走 dryRun 出清单确认过的批量写回document_apply_ops一次最多 200 个操作。分块的节奏也有讲究cursor 翻页直到取空每块读完立刻出清单、立刻确认别攒到最后一起看——攒着攒着上下文就满了前面的块等于白读全部块跑完再做一次跨块的全局检查术语、序号、数字一致性。分工也顺带理清分块阶段管局部对不对全局阶段管互相咬合不咬合两个阶段用不同的提示词别指望一条提示词包打天下。多文档交叉核对同理用这条提示词起手打开目录下这几份文档交叉检查错别字与术语是否一致force:true 的合理场景阈值不是牢房有些活确实需要全局视野术语统一、数字勾稽这类任务切开看反而失真。比如数表与正文的数字核对核对数表与正文数字是否一致合计、百分比这种时候 force 一次是值得的——但注意读一次拿到结构化结论就好别让 agent 每轮对话都重新整读一遍。全局读是手段不是习惯。序号体例检查也属于全局任务附一条我常用的检查标题/条款序号一、一、1.是否层级混乱批注指出这类问题的病根往往在全文模板分块看每块都对拼起来就乱。所以我的节奏是分块跑三遍全局补一遍各占各的时间谁也不抢谁的活。边界与收尾说回适用人群标书、学报长文、年报、政策汇编、标准规范全文凡是页数上三位数的文档这个阈值你迟早会碰到。团队里新人一上来就报 DOCUMENT_TOO_LARGE把这篇甩给他能省一次深夜求助。我的建议是把它当护栏而不是墙护栏拦住的是无意识的整读真需要翻墙时force:true就在参数里用不用是你清醒的选择。工具的克制是替还没吃亏的你先犹豫一下。