CCAR-F 备考手册 · Claude Certified Architect – Foundations
Chapter 13 · Domain 5（权重 15%）

上下文管理
lost-in-the-middle、case facts、scratchpad 与 /compact

Domain 5 权重最小，但它的知识点渗透在其他四个 domain 的题干里——「长会话之后 agent 开始给出不一致的答案」这种描述，在客服、研究、代码探索三个场景都会出现。本章讲两件事：什么会在上下文里丢失，以及把它放在哪里才不会丢。

一、三种信息损耗

① 渐进摘要压掉了硬事实

长对话滚动摘要时，最先被压成模糊表述的恰恰是最不该丢的东西：数值、百分比、日期、客户明确表达的预期。「客户对退款金额不满」这句摘要看起来完整，但 $347.82 这个数字、以及客户说过「周五之前必须解决」这个预期，都已经没了。

解法是把这些事实抽出来单独放——建立一个持久的 case facts 块（金额、日期、订单号、状态），放在被摘要的历史之外，每次 prompt 都原样带上。多诉求会话则把结构化的问题数据（order IDs、金额、状态）持久化到一个独立的 context layer。

┌─ CASE FACTS（不参与摘要，每轮原样携带）─────────────┐
│ customer_id : CUS-448120                          │
│ order_id    : ORD-771904   status: delivered      │
│ amount      : $347.82      order_date: 2026-06-14 │
│ stated_expectation: "resolved before Friday"      │
└───────────────────────────────────────────────────┘
┌─ 摘要后的对话历史（可压缩）──────────────────────────┐
│ 客户首次联系，描述包装破损；已请其提供照片…          │
└───────────────────────────────────────────────────┘

② lost-in-the-middle

模型对长输入的开头和结尾处理可靠，中段容易漏。这不是能力缺陷，是位置效应，换更大的 context window 也不会消失（这正是官方样题 Q12 的 C 选项被判错的原因）。两条对策：

③ 工具结果不成比例地吃 token

guide 给了一个具体数字：一次订单查询返回 40+ 个字段，而其中只有 5 个是相关的。这些结果会累积在上下文里，占用的 token 与它们的价值完全不成比例。解法是在它们进入上下文之前裁剪——只保留与当前任务相关的字段（退货场景就只留退货相关字段）。实现位置通常是 PostToolUse hook（见 ch04）。

不要把裁剪与「不传历史」搞混 — TS 5.1 同时强调：后续 API 请求要传完整的对话历史以保持连贯性。裁剪的对象是单次工具结果里的无关字段，不是对话本身。这两条常在同一道题里做对照。

二、多 agent 场景的上下文预算

两条与 ch03 衔接的 skill：

三、长会话的退化与四件工具

扩展会话里的上下文退化有一个非常具体的识别信号，guide 写得很精确：模型开始给出不一致的答案，并且引用「典型模式」而不是它先前发现的具体类。看到题干里出现这句话的任何变体，就是在考 TS 5.4。

工具解决什么形态
scratchpad 文件 关键发现跨上下文边界持久化 agent 边探索边把发现写进文件，后续问题回头引用它
subagent 委派 隔离冗长的探索输出 派 subagent 去查具体问题（"find all test files"、"trace refund flow dependencies"），主 agent 只保留高层协调
阶段摘要注入 阶段之间的交接 开始下一阶段前先把上一阶段的关键发现摘要出来，注入下一批 subagent 的初始上下文
/compact 会话内 context 被冗长发现输出占满 压缩当前上下文，继续同一条会话

崩溃恢复：manifest

还有一条独立的设计：结构化状态导出——每个 agent 把自己的状态导出到一个已知位置，coordinator 在 resume 时加载 manifest 并注入到 agent 的 prompt 里。这是把「会话状态」从进程内存搬到了外部存储，使得崩溃后可以从断点续接而不是从零重来。它与 --resume（ch04）解决的是不同层面的问题：--resume 续接的是一条会话，manifest 恢复的是一个多 agent 系统的整体进度。

scratchpad 与 manifest 在实现上常常是同一批文件，但设计意图不同：scratchpad 是给模型自己看的备忘录（对抗上下文退化），manifest 是给 coordinator 看的状态快照（对抗进程中断）。考试若要区分，看题干问的是「答案开始不一致」（scratchpad）还是「崩溃后如何续上」（manifest）。
外部课程 · CertSafari — 本章 2 个考点（展开查看）

用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。

考点回链 — 本章覆盖：TS 5.1（渐进摘要压掉数值/日期/客户预期、lost-in-the-middle 与开头摘要+section headers、tool results 不成比例吃 token 与字段裁剪、传完整对话历史、case facts 块、多问题会话的独立 context layer、subagent 输出带 metadata、上游改返回结构化数据）、TS 5.4（长会话退化的识别信号、scratchpad 跨上下文边界、subagent 隔离探索输出、阶段摘要注入、manifest 崩溃恢复、/compact）。相邻考点：Explore subagent 见 ch06，PostToolUse 裁剪见 ch04，provenance 见 ch14。

本章题组

ch13 · Q1 · 准则 P6
A support conversation runs 40+ turns. Your pipeline summarizes older turns to control context. In post-mortems you find the agent quoted a refund amount of "about $300" when the customer had stated $347.82, and missed that the customer had said the issue must be resolved before Friday. What should you change?
正确 BTS 5.1 的原话级 skill：把交易性事实（金额、日期、订单号、状态）抽成持久的 "case facts" 块，置于被摘要的历史之外，每个 prompt 都带上。它从结构上保证这些事实不进入摘要压缩通道——正是 guide 点名的渐进摘要风险（数值、日期、客户明确表达的预期）。
D2 过度工程违反 P2A：完全放弃摘要会让 40+ 轮的对话迅速吃满上下文，且中段内容照样受 lost-in-the-middle 影响。摘要本身没错，错的是没给硬事实留一条不被压缩的通道。
D6 概率当保证违反 P3C：要求摘要器「务必保留所有数字与日期」是概率性合规。而且它保不住「周五前必须解决」这类客户预期——那不是一个数字，是一句会被判定为「非关键」而压掉的表述。
D3 治标不治本违反 P1D：把压缩边界往后挪，只是推迟了同一种损耗。第 60 轮时那 20 轮同样会进入摘要，$347.82 照样变成「about $300」。
ch13 · Q2 · 准则 P1
Your coordinator aggregates findings from six subagents into one long input for the synthesis agent. Reviewers notice that findings from the second, third, and fourth subagents are consistently underrepresented in the final report, while the first and last are well covered. What should you change?
正确 CTS 5.1 的 lost-in-the-middle：模型对长输入的开头与结尾处理可靠、中段易漏——题干的分布（首尾覆盖好、中间三个被漏）是它的教科书形态。guide 给的对策正是这两条：关键发现摘要置于开头 + 用显式 section headers 组织详细结果。
D3 治标不治本违反 P7A：更大的 context window 解决的是「装不下」，而位置效应是注意力分布问题，装得下的时候照样发生。官方样题 Q12 的 C 选项被点名的正是这个混淆。
D3 治标不治本违反 P1B：减少 subagent 会直接缩小研究覆盖面（TS 1.2 的分解过窄风险），用牺牲覆盖来换注意力，代价与收益完全不对等。而且四份材料同样有中段。
D5 吞错或炸链违反 P6D：随机化把系统性遗漏变成随机性遗漏——每次报告都有几块内容被漏，只是漏的位置每次不同。它让问题更难被发现，而不是更少发生。
ch13 · Q3 · 准则 P2
Each lookup_order call returns 44 fields (warehouse routing codes, carrier metadata, internal audit flags, …). Your return-handling agent needs about 5 of them. After a dozen lookups the session's context is dominated by order payloads and quality degrades. What is the appropriate fix?
正确 DTS 5.1 的原例几乎逐字：一次订单查询返回 40+ 字段而只有 5 个相关，工具结果占用的 token 与相关性不成比例——对策是在它们累积进上下文之前裁剪到只剩相关字段。PostToolUse 正是这个拦截点（TS 1.5）。
D3 治标不治本违反 P1A：/compact 治的是「已经堆积起来的冗长输出」，属于事后补救。每次查询仍会灌进 39 个无关字段，压缩只是周期性地清理垃圾而不是不产生垃圾。
D4 甩锅错位违反 P2B：让上游为一个消费方裁字段，会损害其他真正需要那些字段的消费方；而你这一侧有一个成本极低、只影响自己的拦截点。
D5 吞错或炸链违反 P6C：把结构化数据转成散文，既不保证省 token，又破坏了字段的可寻址性——正是 TS 5.1 反过来提醒的方向（下游预算紧时应让上游返回结构化数据而非冗长正文）。
ch13 · Q4 · 准则 P1
Two hours into an exploration of an unfamiliar 400-file service, the agent starts contradicting itself about which module owns retry logic, and begins describing "the typical repository pattern" instead of naming the concrete classes it identified earlier. What is the most appropriate response?
正确 ATS 5.4 把这个症状写得极其精确——扩展会话中模型开始给出不一致的答案、并引用「典型模式」而非先前发现的具体类。guide 给的对策正是让 agent 维护 scratchpad 文件记录关键发现，并在后续问题中引用它，以跨越上下文边界。
D6 概率当保证违反 P3B：要求模型「只依据本会话的具体证据回答」，而那些证据恰恰已经滑出有效上下文了。指令改变不了信息不在场这个事实。
D3 治标不治本违反 P1C：重来一遍会丢掉两小时的探索成果，而且同样的退化会在同样的位置再次发生——「做快点」不是一个可设计的机制。
D3 治标不治本违反 P1D：采样温度影响措辞的随机性，与「先前发现已不在上下文中」这个根因无关。降温只会让模型更一致地给出泛泛而谈的答案。
ch13 · Q5 · 准则 P5
Your multi-agent codebase analysis runs for 45 minutes across four agents. When the orchestrating process crashed at minute 38, all progress was lost and the run restarted from zero. What design prevents this?
正确 BTS 5.4 点名的崩溃恢复设计：每个 agent 把状态结构化地导出到已知位置，coordinator 在 resume 时加载 manifest 并注入 agent 的 prompt。它恢复的是多 agent 系统的整体进度，而不是某一条会话。
D3 治标不治本违反 P5A：--resume 续接的是一条命名会话（TS 1.7），它不覆盖四个 agent 的协同状态——哪些子任务已完成、各自产出了什么，都不在任何单条会话里。用错了机制的层级。
D1 凭空捏造违反 P5C：/compact 压缩的是会话内的上下文占用，它不做任何持久化。进程一死，压缩过的上下文和没压缩的一样消失。
D3 治标不治本违反 P5D：把一次崩溃的损失从 100% 降到 25%，但没有任何一个 agent 的成果被持久化——被击中的那个照样从零重来，而且四条独立会话之间还失去了 coordinator 的编排（TS 1.2 的 hub-and-spoke）。
ch13 · Q6 · 准则 P4
Your synthesis agent has a tight context budget. Upstream research agents currently return full article text plus their reasoning chains, and the synthesis agent can only fit three of the seven agents' outputs. What is the correct change?
正确 CTS 5.1 的原话级 skill：下游 agent 上下文预算有限时，改造上游让它返回结构化数据（key facts、citations、relevance scores），而不是冗长正文与推理链。注意方向是改上游的返回结构，不是在中间加一层压缩。
D3 治标不治本违反 P6A：在中途做散文摘要，正好触发 TS 5.1 点名的渐进摘要风险——数值、日期、来源归属在这一步被压掉，而 synthesis 恰恰需要它们做带引用的综合。
D3 治标不治本违反 P6B：滚动摘要跨三个 pass 传递，等于把同样的损耗做三次；前两批材料到最后一 pass 时已经被压缩了两轮，覆盖会系统性偏向最后一批。
D2 过度工程违反 P4D：给 synthesis agent 加检索工具，既增加了它的工具面（TS 2.3 的专业外工具误用风险），又把 context 压力换成了往返延迟；而上游本来就该只交付它需要的东西。
ch13 · Q7 · 准则 P5
Ninety minutes into a single Claude Code session on an unfamiliar billing service, the context window is 92% full: dozens of Grep and Read payloads, three full test-run logs, and a 400-line dependency dump — all of it already read and folded into the migration plan you are now executing. None of that output needs to be consulted again, but the remaining edits depend on the module ownership you worked out in this session, and none of them is a self-contained question you could hand to someone else. The agent has started re-asking about decisions it made an hour ago. What should you do?
正确 DTS 5.4 给 /compact 的适应症逐条对上：扩展会话中 context 被冗长的发现输出占满时，压缩当前上下文并继续同一条会话。题干的三个条件锁死了其余选项——工作要留在这条会话里（后续编辑依赖此处建立的模块归属理解）、占位的输出已经消费完（不需要回头引用）、没有可拆出去的独立子问题。与本章 Q3 的对照是本题的要点：那里的冗长字段每次工具调用都会再产生一遍，源头有 PostToolUse 裁剪这个正解，所以 /compact 只是事后补救；这里的输出是一次性的、已经用过的，压缩就是对症的那一步。
D3 治标不治本违反 P5A：scratchpad 的适应症是关键发现需要跨上下文边界存活（本章 Q4 的形态）。这里的发现已经被消费完、不需要回头引用；更要命的是写文件不腾出任何已被占用的 context——那些 payload 原封不动地留在窗口里，占用率还是 92%。
D2 过度工程违反 P2B：subagent 委派加阶段摘要注入，对付的是「有可拆出去的独立子问题、且冗长探索输出还没产生」的局面。题干两条都不成立：剩下的编辑没有一块自洽，且都依赖这条会话建立的理解——要委派就得把这份理解整份再传一遍，为一条命令能解决的问题架起一层多 agent 编排。
D5 吞错或炸链违反 P6C：重开会话确实清空了 context，代价是把这一小时建立起来的模块归属理解一起清空，而后续编辑正依赖它。用信息销毁换空间是 P6 的反面；/compact 压缩的是同一条会话的历史，理解留在原地。