问题出现得很突然，日志倒是留得挺全。用 claude-3-5-sonnet-20241022 一次提交 46 页的合同扫描件做比对，messages 里塞了 46 个 image block，接口返回 400，原文是 messages: at most 20 image blocks are allowed per request。
刚开始盯着「重试逻辑把上一次的 content 又追加了一遍」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。单次请求的 image block 数量超过 20 个上限。少数情况下是PDF 转图时每页切成了两半，实际张数是页数的两倍。
少数情况下是同一份文档在多个消息轮次里重复携带。
数清请求体里 image 块的真实个数
python -c "import json;m=json.load(open('req.json'))['messages'];print(sum(1 for c in m[-1]['content'] if c.get('type')=='image'))"再往下按 20 张一组切片后分轮提交
python split_pages.py --input pages/ --per-request 20 --out parts/每轮只带本批图片并复用同一段文字说明
curl https://api.anthropic.com/v1/messages -H "x-api-key: $KEY" -H "anthropic-version: 2023-06-01" -d @part_01.json等前面都确认过，再把各轮结论合并后再做一次跨页比对
python merge_findings.py --parts parts_out/ --out final.json怎么算真的好了，看的是同一批现象。每批请求都返回 200，46 页全部覆盖，合并后的比对结论与人工抽查一致，日志里不再出现 20 image blocks 的报错。
图片数量上限按 block 算而不是按页算，PDF 一页拆两半就会翻倍，切片前先统计真实块数，能省掉一轮失败。报错文案容易误导，真正的原因往往在相邻那一层的日志里。