22 道上下文管理与可靠性练习题及答案

Claude 认证架构师（基础级）考试练习的全部上下文管理与可靠性练习题，附正确答案和简短解析。

1. 一个内部客服 agent 每个会话调用工单 API 十二次。每次响应包含四十多个字段，而 agent 只用其中五个；到第八轮时，请求因为上下文窗口被占满而失败。最有效的修复是什么？
- A.在系统提示里加一条指令，让模型读取工具结果时跳过自己不需要的字段。
- B.把工单调用交给子 agent，由它接收同样的完整负载，再把内容回报给协调者。
- C.在集成层重塑每个工具的响应，只让约定好的那几个字段进入模型上下文。✓ 答案
- D.等上下文压力出现后压缩对话，把先前的工具结果概括成一段较短的文字。
Messages API 是无状态的，每次请求都要重发完整历史：第一轮多余的字段到第八轮仍在付费。在集成层把每个工具裁剪成约定的响应结构，可以在结果进入上下文之前就去掉这份成本；而提示指令、事后压缩和子 agent 转发都至少要为完整负载付一次费。
编号 QB-YUSCSE依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.1 (tool-result trimming at the integration layer)报告此题的问题
2. 一个研究型 agent 在最初几次工具调用中表现良好，之后开始给出含糊、笼统的回答，而日志里没有任何报错。团队提议换一个模型。最佳的第一步是什么？
- A.把工作负载换到宣称窗口更大的模型上，重跑同一会话并对比两者的输出结果。
- B.降低采样温度，让这条很长的工具调用链最终给出更稳定、更具体的答案内容。
- C.对比整段运行中 API 报告的输入 token 用量，看窗口是否随历史累积而被填满。✓ 答案
- D.提高每次请求的输出 token 上限，让模型有更多空间写完那个被截断的回答。
只在长运行后期才出现的退化，是上下文耗尽这一资源问题的典型特征，而不是模型能力不足。每次响应都会返回用量数据，因此输入 token 的增长可以直接测量而无需猜测；换模型、调输出上限或改温度都碰不到真正的原因。
编号 QB-FCM77E依据： Claude Certified Architect – Foundations Exam Guide, Domain 5 (context window as a finite resource; usage reporting)报告此题的问题
3. 某团队把一份很大且稳定的政策文档放进系统提示并启用了提示缓存，但几乎每次请求都按未命中缓存计费。系统提示的第一行会渲染当前时间戳。为什么缓存从来没有命中？
- A.缓存匹配的是逐字节相同的前缀，第一行的时间戳改变了前缀，其后的一切随之作废。✓ 答案
- B.缓存会拒绝超过一定体积的系统块，而这份很长的政策文档超出了单条缓存能容纳的量。
- C.缓存要求系统块渲染在工具定义之前，而开头的这个时间戳恰好把这个顺序颠倒过来了。
- D.缓存只覆盖请求中的最后一条用户消息，放在系统提示里的文本本来就没有复用资格。
提示缓存是前缀匹配：复用从渲染后请求的开头开始，到第一个不同的字节为止。把逐请求变化的时间戳放在最前面，意味着任何两次请求都没有共同前缀，无论文档其余部分多稳定，整段缓存区都会在每次调用时失效。
编号 QB-XUE2MD依据： Anthropic docs — Prompt caching: cached content is matched as an exact prefix of the rendered request报告此题的问题
4. 某助手每次请求都发送相同的工具定义和系统提示，另外还有一段随调用者变化的用户档案。已知请求的渲染顺序是工具、系统、消息，为了获得最佳缓存效果，这段档案应放在哪里？
- A.放在系统提示最上方，让模型在读到任何常驻指令之前先知道自己在服务哪位用户。
- B.写进每条工具描述中，使路由决策能在挑选工具时一并权衡该调用者的权限范围。
- C.做成按用户定制的工具清单，让每位调用者获得一段对他本人长期稳定的请求前缀。
- D.放进消息里、稳定的工具块和系统块之后，让它前面的共享前缀保持逐字节一致。✓ 答案
由于缓存按前缀匹配，而渲染顺序是工具、系统、消息，稳定内容应尽量靠前，易变内容应尽量靠后。把用户档案放在消息里，工具块和系统块就能被所有用户复用；放进系统块或工具清单，则会把第一个差异字节推到最前面，共享随之被摧毁。
编号 QB-JCP7QH依据： Anthropic docs — Prompt caching: request render order (tools, system, messages) and placement of volatile content报告此题的问题
5. 某网关通过遍历哈希表来构建工具数组，因此工具定义的顺序在不同的工作进程之间并不一致。对于其余部分完全相同的请求，缓存命中率忽高忽低。应该怎么修？
- A.以固定且确定的顺序输出工具定义，因为工具块最先渲染，顺序一变整个前缀都作废。✓ 答案
- B.每当观察到未命中就把该请求重试一次，因为第二次尝试会复用第一次写入的那份缓存。
- C.在提示更靠后的位置增加缓存断点，好让顺序被打乱的工具块仍能从后面某处开始匹配。
- D.把工具定义挪到请求的末尾，这样它们的排列顺序就再也干扰不到前缀中稳定的那部分。
工具块最先渲染，位于可缓存前缀的最开头；任何重新排序都会改变最前面的字节，使其后的一切失效。确定性序列化是唯一的修复方式：更靠后的断点救不了已经出现差异的前缀，请求也无法把工具挪到最后。
编号 QB-2VG25H依据： Anthropic docs — Prompt caching: silent invalidators (varying tool sets and non-deterministic serialization)报告此题的问题
6. 某架构师希望获得证据，证明新缓存的前缀在生产环境中确实被复用，而不只是假设它被复用。什么可以确认这一点？
- A.在本地统计提示的 token 数，再从月度账单显示的输入总量中减去这个数字。
- B.把渲染后的提示与上一次请求做差异比较，两串完全一致即视为复用成立。
- C.对比启用缓存前后的响应延迟，把延迟下降视为前缀确实被复用的证据。
- D.查看每次响应随附的用量数据中，缓存读取与缓存写入的 token 计数。✓ 答案
每次响应都会把输入 token 拆分为缓存读取与缓存写入两项报告，这是关于前缀是否被复用的逐请求直接测量。延迟会因许多无关原因波动，渲染字符串相同也不能证明缓存条目仍然存在，而账单加减无法把复用归因到某一次具体请求。
编号 QB-HCBVHG依据： Anthropic docs — Prompt caching: verifying cache performance from the usage object (cache_read / cache_creation input tokens)报告此题的问题
7. 某团队想缓存一段简短的前言，这段前言在每次请求时重新拼装，并且在该请求内只被读取一次。架构师应该怎么说？
- A.缓存这段前言有帮助，因为前缀一旦注册完成，写入与读取就会按完全相同的价格计费。
- B.缓存这段前言会增加成本，因为写入缓存的单价高于未缓存读取，而之后没人再读它。✓ 答案
- C.缓存这段前言在成本上是中性的、只改善延迟，所以凡是可用的地方都值得把它打开。
- D.缓存这段前言既省不了钱又会拖慢请求，因为写入缓存是模型作答之前多出来的一步。
缓存的经济学只有一个方向：缓存读取显著便宜于未缓存读取，而缓存写入则略贵于未缓存读取。只写入、之后再也不被读取的内容因此只付了溢价却拿不到折扣，所以缓存应留给那些在多次请求间重复出现的前缀。
编号 QB-ZU5QXF依据： Anthropic docs — Prompt caching pricing direction (cache writes above, cache reads well below uncached input)报告此题的问题
8. 某长会话 agent 使用了压缩。响应返回了压缩后的历史，但客户端只保存助手的文本并把它追加进自己的记录里。后续轮次表现得好像之前的工作从未发生过。问题出在哪里？
- A.压缩阈值设得太低，历史在窗口远未真正吃紧之前就已经被概括成了较短的形式。
- B.压缩会永久丢弃较早的轮次，所以客户端只能从自己保存的原始记录里重放整段对话。
- C.客户端把摘要挂在了错误的角色下，用户角色的摘要会被模型当成一条新的指令来执行。
- D.响应返回的那些块就是新的历史，下一次请求必须把它们整体发回，而不只是文本。✓ 答案
压缩会把较早的对话改写成更短的形式，并通过响应的内容块把结果交还给调用方。这些块此时就是权威历史，因此只保留渲染文本的调用方会悄悄丢掉压缩后的状态，之后每次请求都建立在残缺的记录之上。
编号 QB-CCJ7PA依据： Anthropic docs — Compaction: the returned content blocks constitute the conversation history the caller must resend报告此题的问题
9. 某 agent 的历史中留有不再需要的大段工具负载，而助手先前做出的决定仍必须逐字可读。在这种情形下，清除与概括有什么区别？
- A.清除会丢掉较早的工具结果而保持周围轮次原样；概括则把历史改写成更短的叙述文字。✓ 答案
- B.清除与概括都会把较早的轮次替换成一段浓缩描述，两者只在删减力度上有强弱之分。
- C.清除会移除当前轮次之前的所有轮次，因此先前做过的任何决定都得由模型从头重新推导。
- D.概括会直接丢掉较早的工具结果，而清除则把整段对话改写成一段紧凑连贯的叙述文字。
清除与概括保住的东西不同。清除只移除选定的旧工具结果，其余记录逐字保留，因此决定原样存续；概括则把成段历史压缩成新的文字，措辞与精确数值都可能受损。当先前的推理必须原样留存时，清除才是保住它的那种缩减方式。
编号 QB-UUC24A依据： Claude Certified Architect – Foundations Exam Guide, Domain 5 (clearing versus summarizing context)报告此题的问题
10. 某 agent 通过一次工具调用取回了一张很大的财务表，三步之后还需要其中少数几个精确数字，但这份负载正在挤占窗口。保住这些数字的最佳方式是什么？
- A.让压缩来概括这份负载，并指示概括器保留后续步骤将会用到的每一个具体数字。
- B.把整份负载留在上下文中，并附一条说明，指出剩余步骤真正用得上的是哪几行数据。
- C.现在就清除这条工具结果，之后每当某个步骤需要某个数字时再重新发起同一次调用。
- D.把需要的数字写入外部文件，在上下文里只留一个简短引用，精确值即可挺过后续缩减。✓ 答案
外部化把数值放在任何上下文缩减都碰不到的地方，在窗口里只需付出一个指针的代价。概括是有损压缩，靠指令保不住高精度信息；重新调用工具每次都会把整份负载再取一遍；而保留负载加一条说明，则让原本的压力原封不动。
编号 QB-D5F8KS依据： Claude Certified Architect – Foundations Exam Guide, Domain 5 (clearing, summarizing, or externalizing context)报告此题的问题
11. 某检索型 agent 把每个问题检索的段落数从八条改成了五十条。尽管正确段落被纳入的频率提高了，准确率却下降了。最好的解释与对策是什么？
- A.五十条时召回率仍然偏低，应继续提高检索深度，直到正确段落每次都被包含进来为止。
- B.模型需要被允许跳过噪声，因此应保留这五十条，并指示它忽略其中无关的那些段落。
- C.多余的段落会稀释注意力并把正确段落埋在提示中部，因此应检索更少、更精准的段落。✓ 答案
- D.回答是被输出上限截断了，因此应提高输出上限，直到五十条段落都能被完整使用为止。
检索本身就是上下文管理，检索得越多并不等于越好：每多一条段落都在争夺注意力，并把关键文本推向提示的中部，而中部恰恰是注意力最弱的位置。当正确段落通常已被包含时，检索的精确度比召回率更重要。
编号 QB-WMMD6T依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.1 (retrieval scope and positional attention)报告此题的问题
12. 在一个多 agent 研究系统中，每个子 agent 都会把它读过的每份文档全文返回。协调者还没开始综合就已用尽上下文。修复应该做在哪里？
- A.做在子 agent 一侧：每个子 agent 返回带论断、来源与日期的结构化发现，而不是文档原文。✓ 答案
- B.做在调度上：每次少跑几个子 agent，让协调者分成若干小批次陆续收到它们的完整报告。
- C.做在选型上：把协调者换到窗口更大的模型，使其足以容纳所有子 agent 输出的合计内容。
- D.做在协调者一侧：子 agent 返回的文本一进入协调者历史，协调者就立刻把它概括成摘要。
跨越 agent 边界时，上下文膨胀要在上游解决：由子 agent 决定什么内容才进入协调者的窗口。让它返回带引用与元数据的结构化关键事实，可以把冗长的阅读隔离在发生地；事后概括、分批调度或换更大窗口，都得先为原文买单。
编号 QB-C54WDR依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.1 (subagents return structured facts, not verbose content)报告此题的问题
13. 某团队用字符数除以四来估算 agent 历史的大小，并信任这个估计值。请求会间歇性地因超出模型上限而失败。他们应该怎么做？
- A.每当请求被拒绝就截断最早的那些消息并重发，如此反复直到某一次请求终于通过为止。
- B.给这个基于字符的估计值加一个固定的安全余量，使拼装后的请求保持在模型上限之下。
- C.改用某个第三方分词库，并把它给出的计数当作他们调用的每个模型的权威大小依据。
- D.在请求发出前，用 API 的 token 计数功能统计已拼装请求的实际 token 数。✓ 答案
一段提示真正要花多少 token 是数出来的，不是估出来的：分词随内容和模型而变，字符除以四的规则会以不可预测的幅度出错。在发送前对已拼装的请求做计数，把猜测变成了测量；加余量、被拒后重试、换第三方分词库，仍然都是在猜。
编号 QB-VM93ZR依据： Claude Certified Architect – Foundations Exam Guide, Domain 5 (measure context cost rather than estimate it)报告此题的问题
14. 某客服 agent 运行长会话并使用渐进式概括。记录显示，247.83 美元的退款到第二十轮已变成“一笔退款”，客户所说的“周五之前”也消失了。最有效的修复是什么？
- A.指示概括器在压缩会话中较早的那一段时，务必保留其中的金额、日期和各类标识编号。
- B.维护一个包含金额、日期与各类编号的案件事实块，逐字注入每次提示，且置于摘要之外。✓ 答案
- C.降低概括的频率，让更多原始轮次得以留存，高精度细节也就能在历史中多停留一段时间。
- D.每当 agent 准备对该案件采取行动时，就请客户重新说一遍金额和期限，以此确认关键信息。
渐进式概括是有损压缩，最先被摧毁的正是高精度信息：金额、日期、编号和客户提出的期望。靠写提示是绕不过去的，因此必须存续的事实要放进一个结构化块，逐字注入每次请求，只让周围的对话被概括。
编号 QB-B5RJ8Q依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.1 (persistent verbatim case-facts block)报告此题的问题
15. 某 agent 收到一份汇总研究材料，其中决定性的发现位于这份很长输入的中部，而它总是漏掉这个发现。正确的缓解措施是什么？
- A.把工作负载换到窗口更大的模型上，因为输入中部注意力偏弱是这个模型自身的缺陷。
- B.把整份输入在提示末尾再重复一遍，使那个发现同时落在注意力较强的位置上出现。
- C.把关键发现的摘要放在输入的开头，并为每个部分标上明确的小节标题以便定位。✓ 答案
- D.提高输出上限，让模型有足够空间把整份输入通读处理完，然后再给出最终的答案。
对长输入中部注意力偏弱，是提示被处理时的结构性特征，而非某个模型的缺陷，因此要用结构手段缓解：把关键发现的摘要放在注意力可靠的开头，并用明确标题让各部分可被定位。换更大窗口、调高输出上限或重复整份输入，都没有触及位置本身的问题。
编号 QB-UMWQTQ依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.1 (positional attention: structural mitigations)报告此题的问题
16. 两个子 agent 都返回了空结果。其中一个连上了档案库，只是查询没有匹配到任何记录；另一个在档案库应答之前就超时了。协调者应如何处理这两种情况？
- A.两次都当作已答复，因为协调者没有可靠办法判断这两个来源中哪一个真正被访问到。
- B.两次都上报给人工复核，因为任何来源返回的空结果都无法与出故障的情况区分开来。
- C.两次都重试，因为空响应在外部看来是同一种结果，而多试一次的代价其实很小。
- D.两次要分开处理：重试超时那次，把无匹配的空结果当作答案。✓ 答案
访问失败与有效的空结果在外观上完全一样，处理方式却相反：超时根本没有触达来源，值得重试；无匹配本身就是答案，重试只会白白消耗窗口。区分二者的是子 agent 上报的结构化失败类型，这正是错误上下文要带类别而不是只给一个状态的原因。
编号 QB-A5D83P依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.3 (access failure versus valid empty result)报告此题的问题
17. 某子 agent 的数据源返回了权限错误。该子 agent 却返回一个状态为“ok”的空结果集，好让工作流继续推进。这样做的后果是什么？
- A.协调者会自动重试该子 agent，并在第二次尝试时把底层的权限错误如实暴露出来。
- B.协调者会认定这些数据并不存在，且没有任何恢复路径，因为失败根本没有传到它那里。✓ 答案
- C.协调者会为该主题记录一处覆盖缺口，并在综合结论中注明有一个来源未能被读取。
- D.协调者会中止整个工作流，把其他子 agent 已经收集到的那些部分结果一并丢弃掉。
把失败悄悄转成一次“空的成功”，是错误传播中最坏的结果：协调者无法重试、无法降级、也无法标注覆盖情况，因为在它看来来源已被读取且内容为空。只有把失败类型、尝试内容和已获得的部分结果结构化地上传，才能保住恢复的可能。
编号 QB-TMJDNP依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.3 (silent error suppression anti-pattern)报告此题的问题
18. 在一次故障排查会话进行到第十轮时，客户写道：“直接给我转人工。”而 agent 距离一个看起来可行的解决方案只差一次工具调用。它应该怎么做？
- A.先完成那次待执行的工具调用，只有当得到的方案没能解决客户的问题时才转交人工处理。
- B.先安抚客户的情绪并提出解决方案，只有当客户第二次要求转人工时才真正执行升级操作。
- C.立即转交人工并同时移交案件事实，因为客户明确要求真人是一个硬性的升级触发条件。✓ 答案
- D.对这条消息做情绪打分，等测得的不满程度越过该队列设定的阈值之后再执行升级操作。
客户明确要求真人是为数不多的硬性升级触发条件之一，应立即执行，而不必先调查或先证明 agent 本可以解决。先安抚再提出方案，适用于只有情绪而无明确请求的情形；情绪打分则根本不是可靠的触发条件，因为不满程度与案件复杂度并不相关。
编号 QB-952WVM依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.2 (escalation triggers: explicit human request)报告此题的问题
19. 某多 agent 流水线在运行中途崩溃。重启后，协调者必须重建崩溃前各个 agent 已经确立的内容。这套设计应当依赖什么？
- A.从最初的任务描述干净地重跑一遍，因为重新推导出结论比信任可能已经过期的状态更稳妥。
- B.每个 agent 保存下来的完整对话历史，从头逐条重放，使整次运行重新抵达同一个状态。
- C.一份记录各 agent 已导出状态的清单，在恢复时加载并注入重启后各 agent 的提示。✓ 答案
- D.协调者自己记录的、它先前告诉过各 agent 的内容，作为各重启会话的开场消息重新发出。
崩溃恢复应围绕结构化的状态持久化来设计，而不是围绕对话记录：每个 agent 把状态导出到已知位置，协调者在恢复时加载清单并注入重启后的提示。重放历史代价高昂，且未必能复现相同的工具结果；而干净重跑则会丢掉崩溃前已经确立的一切。
编号 QB-SM73GN依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.4 (structured state persistence and resume manifests)报告此题的问题
20. 在探索一个陌生代码库两个小时后，助手开始援引“常见模式”而不是它先前读过的那些类，并与自己早先的回答相互矛盾。最有效的应对是什么？
- A.把目前的发现写入草稿文件持久保存，并把后续探索交给只回报摘要的子 agent 去完成。✓ 答案
- B.在每个问题开始前重新读一遍主要源文件，让相关细节始终位于最近的那几轮对话之中。
- C.把工作拆到两位工程师各自的会话里，使每个会话只需把代码库中较小的一部分纳入视野。
- D.要求助手更加谨慎，并为它关于代码库设计所作的每一条论断都附上具体的文件路径。
不再引用具体文件而改用泛泛的“常见模式”，是长会话中上下文退化的典型信号。对策是把知识移出窗口，并让冗长输出不再进入窗口：用草稿文件保存供随后查阅，再由子 agent 承担探索以隔离其输出。每轮重读文件只会加速同样的耗尽。
编号 QB-A3F33P依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.4 (scratchpads and subagent delegation in large-codebase work)报告此题的问题
21. 两个子 agent 报告了同一个指标：一个给出 2022 年研究的 28%，另一个给出 2024 年研究的 32%。综合阶段应如何处理这两个数字？
- A.取两者的平均值并同时引用两项研究，因为两个来源都可信，谁都不能被单方面排除掉。
- B.两个数字连同来源与采集年份一并报告，把它们视为一条趋势，而不是彼此矛盾的说法。✓ 答案
- C.把这一对标记为未解决的冲突，并把该问题退回给给出较低数值的那个子 agent 重新核查。
- D.只报告 2024 年那个数字并舍弃较早的一个，因为更近的研究已经取代了更早的那项发现。
时间元数据正是区分冲突与趋势的关键：同一指标在不同年份的测量结果反映的是随时间的变化，去掉年份就会凭空造出一个并不存在的矛盾。来自可信来源的数值应带完整出处一并向下传递，既不取平均，也不悄悄只留一个。
编号 QB-SJ9WFN依据： Claude Certified Architect – Foundations Exam Guide, Domain 5, TS 5.6 (temporal metadata, provenance, and conflict annotation)报告此题的问题
22. 某 agent 有四个相似的查询工具，却经常调错；每个工具的描述都只有一句很短的话。团队的第一反应是上下文窗口太拥挤。他们首先应该改什么？
- A.在 agent 前面加一层路由模型，由它挑选工具，并把这个选择作为固定参数传递下去。
- B.扩写每条工具描述，写清输入格式、示例查询，以及它与另外三个工具之间的适用边界。✓ 答案
- C.大力裁剪对话历史，好让工具定义在渲染后的提示中处于更靠近末尾的那个位置上。
- D.在系统提示里给出少样本示例，展示过去十几个用户请求分别选用了哪一个查询工具。
这看起来像上下文问题，实则是工具设计问题：描述是主要的路由机制，而四条一句话的描述没给模型任何可供区分的依据。补上输入格式、示例和明确边界，是与问题相称的第一步；调整提示顺序、加路由层或搬出少样本示例，都跑到了尚未尝试的低成本修复前面。
编号 QB-934RVM依据： Claude Certified Architect – Foundations Exam Guide, Domain 2 (tool descriptions as the primary routing mechanism)报告此题的问题

本考试的其他主题

智能体架构与编排22 道免费练习题工具设计与 MCP 集成21 道免费练习题 Claude Code 配置与工作流22 道免费练习题提示工程与结构化输出22 道免费练习题

练习题依据官方 Claude 认证架构师基础级（CCAR-F）考试指南和 Anthropic 公开文档编写。这是一个独立的学习工具，与 Anthropic 无关联、未获其认可，也不授予任何认证。考试由 Pearson VUE 交付；当前的题量、考试时长、通过分数和费用以 Anthropic 官方 CCAR-F 考试指南公布的为准。官方认证页面 →

1. 一个内部客服 agent 每个会话调用工单 API 十二次。每次响应包含四十多个字段，而 agent 只用其中五个；到第八轮时，请求因为上下文窗口被占满而失败。最有效的修复是什么？

2. 一个研究型 agent 在最初几次工具调用中表现良好，之后开始给出含糊、笼统的回答，而日志里没有任何报错。团队提议换一个模型。最佳的第一步是什么？

3. 某团队把一份很大且稳定的政策文档放进系统提示并启用了提示缓存，但几乎每次请求都按未命中缓存计费。系统提示的第一行会渲染当前时间戳。为什么缓存从来没有命中？

4. 某助手每次请求都发送相同的工具定义和系统提示，另外还有一段随调用者变化的用户档案。已知请求的渲染顺序是工具、系统、消息，为了获得最佳缓存效果，这段档案应放在哪里？

5. 某网关通过遍历哈希表来构建工具数组，因此工具定义的顺序在不同的工作进程之间并不一致。对于其余部分完全相同的请求，缓存命中率忽高忽低。应该怎么修？

6. 某架构师希望获得证据，证明新缓存的前缀在生产环境中确实被复用，而不只是假设它被复用。什么可以确认这一点？

7. 某团队想缓存一段简短的前言，这段前言在每次请求时重新拼装，并且在该请求内只被读取一次。架构师应该怎么说？

8. 某长会话 agent 使用了压缩。响应返回了压缩后的历史，但客户端只保存助手的文本并把它追加进自己的记录里。后续轮次表现得好像之前的工作从未发生过。问题出在哪里？

9. 某 agent 的历史中留有不再需要的大段工具负载，而助手先前做出的决定仍必须逐字可读。在这种情形下，清除与概括有什么区别？

10. 某 agent 通过一次工具调用取回了一张很大的财务表，三步之后还需要其中少数几个精确数字，但这份负载正在挤占窗口。保住这些数字的最佳方式是什么？

11. 某检索型 agent 把每个问题检索的段落数从八条改成了五十条。尽管正确段落被纳入的频率提高了，准确率却下降了。最好的解释与对策是什么？

12. 在一个多 agent 研究系统中，每个子 agent 都会把它读过的每份文档全文返回。协调者还没开始综合就已用尽上下文。修复应该做在哪里？

13. 某团队用字符数除以四来估算 agent 历史的大小，并信任这个估计值。请求会间歇性地因超出模型上限而失败。他们应该怎么做？

14. 某客服 agent 运行长会话并使用渐进式概括。记录显示，247.83 美元的退款到第二十轮已变成“一笔退款”，客户所说的“周五之前”也消失了。最有效的修复是什么？

15. 某 agent 收到一份汇总研究材料，其中决定性的发现位于这份很长输入的中部，而它总是漏掉这个发现。正确的缓解措施是什么？

16. 两个子 agent 都返回了空结果。其中一个连上了档案库，只是查询没有匹配到任何记录；另一个在档案库应答之前就超时了。协调者应如何处理这两种情况？

17. 某子 agent 的数据源返回了权限错误。该子 agent 却返回一个状态为“ok”的空结果集，好让工作流继续推进。这样做的后果是什么？

18. 在一次故障排查会话进行到第十轮时，客户写道：“直接给我转人工。”而 agent 距离一个看起来可行的解决方案只差一次工具调用。它应该怎么做？

19. 某多 agent 流水线在运行中途崩溃。重启后，协调者必须重建崩溃前各个 agent 已经确立的内容。这套设计应当依赖什么？

20. 在探索一个陌生代码库两个小时后，助手开始援引“常见模式”而不是它先前读过的那些类，并与自己早先的回答相互矛盾。最有效的应对是什么？

21. 两个子 agent 报告了同一个指标：一个给出 2022 年研究的 28%，另一个给出 2024 年研究的 32%。综合阶段应如何处理这两个数字？

22. 某 agent 有四个相似的查询工具，却经常调错；每个工具的描述都只有一句很短的话。团队的第一反应是上下文窗口太拥挤。他们首先应该改什么？

本考试的其他主题