现场是这样的。把一份 30 页的 PDF 转成文本后整段塞进 messages，返回 400，提示 prompt is too long: 205312 tokens > 200000 maximum，可正文看上去并没有那么长。
中间走过弯路，把「没有做历史裁剪，前几轮的完整回答一直累加」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。system 提示词和多轮历史都会计入总 token；PDF 转文本后空白与页眉页脚让体积翻倍；图片按尺寸折算 token，混排文档实际占用更高。
先按官方口径统计输入 token 再决定切多少
python -c "import anthropic;c=anthropic.Anthropic();print(c.count_tokens(open('doc.txt').read()))"接着按章节切块，每次只送一块并保留结论
python split_doc.py --max-tokens 60000 --input doc.txt历史只保留最近三轮，超出的做摘要替换
messages = [summary_msg] + messages[-6:]请求带回 usage 字段，逐次记录输入规模
print(resp.usage.input_tokens)恢复的判定其实很直接。请求返回 200，usage.input_tokens 落在 20 万以内，长文任务能分块跑完并汇总出结构化的结果。
补一句。图片也会按尺寸折算 token，一份图文混排的文档往往比按字数估算的高出不少，务必用接口自带的计数方法核一遍再切。报错文案容易误导，真正的原因往往在相邻那一层的日志里。