Chapter 10 · Domain 4（权重 20%）
批处理与多遍审查
Message Batches API 的适配轴与 multi-instance / multi-pass
本章两块内容分别对应 P5（机制匹配负载）与 P7（注意力有限、独立性有价），是官方样题里出题密度最高的两条准则——Q11 与 Q12 都在本章。两块都有一个共同特征：正确答案往往是「分开处理」，干扰项往往是「统一处理」。
一、Message Batches API 的四条事实
| 事实 | 推论 |
|---|---|
| 50% cost savings | 唯一的好处是省钱，不省延迟 |
| up to 24-hour processing window | 提交时间要向前推足窗口才能保住下游 deadline |
| 没有 latency SLA | 「实践中通常一小时内完成」不能当保证——这是官方样题 Q11 的题眼 |
| 不支持单请求内的 multi-turn tool calling | 需要「调工具 → 拿结果 → 再推理」的 agentic 流程不能整段塞进一次 batch 请求 |
第四条常被忽略，但它是一条硬性能力边界：batch 请求里不能在中途执行工具并把结果送回。所以一个完整的 agentic loop 不是 batch 的负载；能进 batch 的是「一次输入 → 一次输出」的任务（抽取、分类、总结、单遍审查）。
适配轴：阻塞 vs 非阻塞
| 用 batch ✔ | 用同步 API ✘ 不要 batch |
|---|---|
|
|
官方样题 Q11 的四个选项把这条轴的四个位置占满了，值得记住每个错法的名字：全转 batch + 轮询（把阻塞流程押在无 SLA 的机制上）、全留同步（放着 50% 折扣不要，理由还是个误解——batch 结果可以用 custom_id 关联，不存在「顺序错乱」问题）、全转 batch + 超时回退实时（在「各配各的」这个简单方案存在时引入不必要的复杂度）。
二、两个可计算的技能点
① 按 SLA 倒推提交频率
这是 guide 明确点名的一项 skill，考试可能直接给数字让你算。逻辑很简单：
下游 SLA = 30 小时（文档进来后必须在 30 小时内出结果）
batch 处理窗口 = up to 24-hour（最坏情况）
─────────────────────────────────────────────
可容忍的排队时间 = 30 − 24 = 6 小时
∴ 提交窗口 ≤ 6 小时；guide 给的答案是每 4 小时提交一次（留安全边际）要点是必须用最坏情况（窗口上限）算，不能用平均完成时间算——没有 SLA 就意味着平均值不构成承诺。
② 失败重提：按 custom_id 只重提失败的
custom_id 的作用是关联请求与响应。批次里有文档失败时，正确做法是按 custom_id 定位失败项，只重提这些，并做针对性修改（例如把超出 context 限制的文档先 chunk 再重提），而不是整批重跑。
还有一条省钱的常识被写进了 guide：先在小样本上把 prompt 调好，再上大批量——最大化首过成功率，减少反复重提的成本。
三、自审为什么弱
同一个 session 里，模型带着生成时的推理惯性——它刚刚说服自己这段代码是对的，现在让它质疑同一个决定，成功率天然偏低。guide 的措辞是：模型保留生成阶段的推理上下文，less likely to question its own decisions。
| 手段 | 有效性 | 为什么 |
|---|---|---|
| 独立实例审查（无先验推理上下文） | 最有效 | 没有需要辩护的先前决定 |
| 同 session 加一句「请审查你自己的输出」 | 弱 | 推理惯性仍在 |
| 同 session 开 extended thinking | 弱 | guide 明确点名：独立实例优于 self-review 指令或 extended thinking |
与 TS 3.6 的呼应 — CI 场景里的同一条结论：生成代码的那个 session 去 review 自己的改动，效果弱于一个独立的 review 实例。两个 TS 从不同角度说同一件事，考试可能从任一角度问。
四、多遍审查的两类 pass
这一节与 ch02 的任务分解是同一个知识点的两个入口，这里补充第三类 pass：
- per-file local pass — 逐文件抓局部问题，保证深度一致。
- cross-file integration pass — 单独一遍看跨文件数据流。
- verification pass — 让模型对每一条 finding 自报 confidence，以支持分级路由（calibrated review routing）。
第 3 条不与 P8 矛盾 — 这是本章最容易读错的地方。P8 说「未校准的自报 confidence 不可作路由依据」，这里却让模型自报 confidence。区别在于用途与前提：把自报 confidence 直接当阈值过滤器（低于 8 就丢弃）是错的；把它作为分级路由的输入，且事先用 labeled validation set 校准过（TS 5.5）是对的。关键词永远是 calibrated。
从成本角度看，多遍审查与 batch 是天然的组合：per-file pass 是典型的「一次输入一次输出」任务，数量多、彼此独立、通常不阻塞——正好是 batch 的负载画像。夜间跑的大型 code review 常见做法就是把 per-file pass 打成一个 batch，集成 pass 留到结果回来后同步跑。Exam Guide 没有把这两条 TS 合并讨论，考试也不会考这个组合本身。
外部课程 · CertSafari — 本章 2 个考点（展开查看）
用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。
考点回链 — 本章覆盖：TS 4.5（Batches API 的 50% 折扣/up to 24-hour 窗口/无 latency SLA/不支持单请求内 multi-turn tool calling、阻塞 vs 非阻塞适配、按 SLA 倒推提交频率、
custom_id 定位失败项重提、小样本先调 prompt）、TS 4.6（自审的推理惯性局限、独立实例优于 self-review 指令与 extended thinking、per-file + cross-file 两类 pass、verification pass 自报 confidence 支持分级路由）。相邻考点：任务分解见 ch02，CI 独立 review 见 ch07，confidence 校准见 ch14。本章题组
ch10 · Q1 · 准则 P5
Your platform runs two Claude workloads: (1) a pre-merge security check that blocks the merge button while developers wait, and (2) a nightly dependency-risk report read the next morning. Telemetry shows the nightly report accounts for roughly 85% of the platform's Claude spend. Finance asks for a 40% cost reduction. What do you propose?
正确 ATS 4.5 的适配轴：batch 适配非阻塞、延迟容忍的负载（过夜报告是 guide 的原例），不适配阻塞流程（pre-merge check 也是 guide 的原例）。这题还要真算一笔账：夜间报告占 85% 的支出，转 batch 拿到 50% 折扣 → 账单降幅 = 0.5 × 85% = 42.5%，越过 40% 的目标线，而阻塞路径上开发者的等待时间一秒都没变长。与官方样题 Q11 同构。
D6 概率当保证违反 P5B：「usually well within an hour」是把无 SLA 的经验分布当成保证。再算一下它多买到了什么：pre-merge check 只占 15% 的支出，把它也转 batch 只能把降幅从 42.5% 抬到 50%，多出 7.5 个百分点——代价是让等在 merge 按钮前的开发者去赌一个最长 24 小时、且没有 latency SLA 的窗口。目标已经被 A 达成，这 7.5 点买不动这个风险。官方样题 Q11 对这个选项的原判就是——依赖「往往更快」对阻塞流程不可接受。
D1 凭空捏造违反 P1C：理由是错的。batch 结果可以通过
custom_id 精确关联请求与响应，不存在「匹配不回去」的问题——这正是官方样题 Q11 的 C 选项被点名的误解。D2 过度工程违反 P5D：在「各配各的」这个更简单的方案存在时引入混合回退。而且回退逻辑本身要为阻塞流程兜底，等于承认 batch 不适合它——那就不该把它放进去。从账上看更划不来：这套额外机制服务的也只是 A 之外那 7.5 个百分点。
ch10 · Q2 · 准则 P5
Contracts arrive continuously. Your downstream obligation is that every document has an extraction result within 30 hours of arrival. You want to use the Message Batches API. How often should you submit batches?
正确 DTS 4.5 点名的 skill——按 SLA 约束倒推提交频率，guide 给的正是这个算例（4 小时提交窗口保 30 小时 SLA）。算法：可容忍排队时间 = SLA − 最坏处理时间；必须用窗口上限而非平均值，因为没有 latency SLA。
D6 概率当保证违反 P5A：紧挨窗口上限提交，等于给排队留 0 余量——刚错过一批的文档要等 24 小时排队再加最坏 24 小时处理，直接爆掉 30 小时。
D6 概率当保证违反 P5B：用「典型一小时」做规划，正是无 SLA 机制最不能做的事。一次落到窗口上限，整批文档全部违约。
D2 过度工程违反 P5C：先承认它成立的那一半——逐份提交的排队时间是 0，最坏情况 0 + 24 小时处理窗口 = 24 小时 < 30 小时 SLA，C 在 SLA 维度上确实压得进去。它错在别处：一份文档一个批次等于把批处理退化成逐条同步调用，请求数与运维开销双双最大化，批量本身的意义被放弃；同时它绕开了 TS 4.5 真正要考的那件事——从 SLA 倒推出一个提交节奏。考的是这个推导，不是任何能压进 30 小时的做法。
ch10 · Q3 · 准则 P6
A batch of 900 documents returns with 37 failures. Inspection shows 31 failed because the documents exceeded the context limit, and 6 failed for transient reasons. What is the correct handling?
正确 ATS 4.5 的原话级 skill：按
custom_id 定位失败项，只重提失败的那些并做针对性修改——guide 举的修改例子正是「把超出 context 限制的文档 chunk 后重提」。两类失败得到各自恰当的处置。D2 过度工程违反 P2B：重跑 863 份已经成功的文档，成本翻倍且毫无收益；对全部文档一律 chunk 还会把本来完整的文档切碎，损害那些原本正确的抽取质量。
D1 凭空捏造违反 P1C：同步 API 与 batch API 面对的是同一个模型上下文限制，不存在「同步端限制更宽」这回事。超长文档在哪条路径上都超长。
D5 吞错或炸链违反 P6D：把 37 份可修复的失败标成不可处理，是用一个聚合百分比掩盖具体缺口——而且这 37 份里有 31 份只需要 chunk 一下就能成功。可恢复的错误不应被吞掉。
ch10 · Q4 · 准则 P5
You want to move a nightly workflow to the Message Batches API. The workflow currently runs an agent that, for each repository, calls a search tool, reads the results, then calls a test-coverage tool based on what it found, then writes a summary. What is the correct assessment?
正确 CTS 4.5 的硬性能力边界：batch API 不支持单个请求内的 multi-turn tool calling（无法在请求中途执行工具并把结果送回）。延迟容忍只是必要条件，不是充分条件——工作流的形态也必须是「一次输入一次输出」。
D3 治标不治本违反 P5A：只检查了延迟维度就下结论。这是最容易中的陷阱——batch 的适配判断有两个维度，另一个是能力边界。
D1 凭空捏造违反 P5B：
custom_id 的作用是关联请求与响应，它不会让 batch 具备执行多轮工具调用的能力。给一个真实机制安上它没有的语义。D1 凭空捏造违反 P5D：
tool_choice: "any" 保证模型调用某个工具，它不负责执行工具、更不会把结果回灌进同一次请求。它管的是模型的输出形态，不是运行时能力。ch10 · Q5 · 准则 P7
Your pipeline has Claude generate a service module, then — in the same session — asks it to review the code it just wrote for bugs. The review consistently approves its own output; bugs are later found in QA. What is the most effective change?
正确 BTS 4.6 / TS 3.6：同 session 保留生成时的推理上下文，模型不易质疑自己的决定；没有先验推理上下文的独立实例在抓细微问题上更有效。这是 P7 后半句「自审不如换人审」的直接落地。
D6 概率当保证违反 P8A：TS 4.6 明确指出独立实例优于 self-review 指令。「要怀疑自己」是一句模糊指令，改变不了推理惯性这个结构性因素。
D3 治标不治本违反 P7C：guide 把 extended thinking 与 self-review 指令并列，明说独立实例优于两者。想得更久不等于跳出自己的前提。
D2 过度工程违反 P7D：摘要步骤仍在同一个 session 内，推理上下文没有被真正切断；而且压缩描述会丢掉审查最需要的细节——为了模拟「独立」而损失了信息。
ch10 · Q6 · 准则 P8
You are designing a verification pass over your reviewer's findings so limited human attention goes to the findings most likely to be wrong. You plan to have the model self-report a confidence value with each finding. Under what condition is this sound?
正确 DTS 4.6 允许 verification pass 让模型逐条自报 confidence 以支持分级路由，但 TS 5.5 给出了使其成立的前提：先用 labeled validation set 校准，并对高置信区间保留 stratified random sampling 持续测错。关键词是 calibrated——有它是正解，没它是干扰项。
D3 治标不治本违反 P8A：把 P8 读成了绝对禁令。guide 反对的是未校准的自报 confidence 直接当过滤器（TS 4.1），而 TS 5.5 明确把 field-level confidence 校准后用于路由列为正规手段。
D6 概率当保证违反 P8B：调高阈值不会让一个未校准的刻度变得有意义——模型恰恰在难例上错误地自信，那些正是要被 9/10 放行的条目。「反正几乎都送人工」这句辩护更是自拆台脚：题干的目标就是把有限的人工注意力集中到最可能出错的那些条目上，全送等于没有分级。
D3 治标不治本违反 P8C：理由说得通不等于分数校准了。自我辩解与自报置信来自同一个推理过程，它增加的是可读性，不是可靠性；guide 要求的是对照标注数据的外部校准。
ch10 · Q7 · 准则 P2
You are about to batch-process 5,000 archived contracts with a newly written extraction prompt. The prompt has been tested on three documents you picked by hand. What should you do before submitting?
正确 ATS 4.5 点名的 skill：在大批量处理之前先用样本集精化 prompt，以最大化首过成功率、减少反复重提的成本。三份手挑文档不构成代表性样本——它甚至可能系统性地漏掉最难的格式。
D2 过度工程违反 P2B：把重提机制当成免费的迭代手段。失败重提是异常处理，不是开发流程；用 5,000 份文档的全量成本换本可以在小样本上得到的信息，是最贵的调试方式。
D3 治标不治本违反 P2C：十个 500 份的批次比一个 5,000 份的批次好一些，但每轮仍要等最长 24 小时的处理窗口才能拿到反馈——迭代周期以天计。样本集调优的迭代周期是分钟。
D1 凭空捏造违反 P1D：
tool_choice: "any" 保证输出是结构化的，不保证内容正确。schema 合规的错误抽取比明显的失败更危险——它会静默地流进下游。