Scenario 1 · 主考 Domain 1 / 2 / 5
S1 · Customer Support Resolution Agent客服解决 agent：从 55% 到 80%+ first-contact resolution
官方设定：用 Claude Agent SDK 构建客服解决 agent，处理退货、账单争议、账户问题这类高歧义 请求；通过自定义 MCP 工具（get_customer、lookup_order、process_refund、escalate_to_human）接后端；目标是 80%+ first-contact resolution ，同时知道什么时候该转人工。
先读设定里的两个考点信号 — ①「high-ambiguity requests」意味着这个场景不会考「照流程办事」，会考歧义消解与判断；②「80%+ first-contact resolution while knowing when to escalate 」是一对张力：升级太多则 FCR 上不去，升级太少则该转人工的案子被硬扛。这个场景的题一大半都在这条张力线上。
一、从零设计：四个工具能构成什么
四个工具划出了 agent 的能力边界：查人（get_customer）、查单（lookup_order）、动钱（process_refund）、转人（escalate_to_human）。设计的第一个决定是控制流由谁驱动 。
客服请求的路径无法穷举——「我的退货没退款、上个月被重复扣费、还想改地址」这类多诉求消息随时出现。所以默认答案是模型驱动的 agentic loop ：stop_reason == "tool_use" 继续、"end_turn" 终止，工具结果回灌进对话历史（ch02 ）。 把它做成 if/else 决策树，第一个没预料到的请求类型就会卡住。
但有一条顺序不能赌
process_refund 动的是钱。身份验证必须先于资金操作 ，而 prompt 指令是概率性合规——在足够多的会话上必然失败若干次。 所以第二个决定是：在模型驱动的循环外面加一道程序化前置条件 ，在 get_customer 返回已验证的 customer ID 之前，阻断 lookup_order 与 process_refund。
再加一道出站拦截：refunds exceeding $500 拦截并重定向到人工升级流程 。 注意「重定向」——只阻断不给出路，agent 会卡在那里反复重试。
二、上线：三个真实数字暴露三个问题
踩坑 ①：12% 的会话跳过身份验证
生产数据显示 12% 的案例直接用客户自报的姓名调 lookup_order，偶尔导致账户误认与错误退款。 这就是官方样题 Q1 的场景。正确答案是程序化前置条件（"blocks ... until get_customer has returned a verified customer ID"）；「强化 system prompt 说明验证是 mandatory」与「加 few-shot 示范总是先调 get_customer」两个选项都因概率性合规不足以承担资金后果 被排除；「加路由分类器只启用相应工具子集」则解决的是工具可用性 而非工具顺序 ——不是本题的问题。
踩坑 ②：查订单时却去查客户
用户问 "check my order #12345"，agent 却调 get_customer。两个工具的描述各只有一句话（"Retrieves customer information" / "Retrieves order details"），且接受相似的标识符格式。 这是官方样题 Q2 。正确答案是扩写描述 ——补上它处理的输入格式、示例查询、边界情况，以及与相似工具的区分。官方解析的关键判断是：tool descriptions 是 LLM 选择工具的首要机制，扩写是低成本高杠杆 的根因修复。few-shot 加 token 却不修根因；routing layer 过度工程且绕开了模型的语言理解；合并成单个 lookup_entity 是合理架构但作为 "first step" 过重。
踩坑 ③：55% 的 first-contact resolution
agent 把「有照片证据的标准破损换货」这类常规案子转人工，却自己硬扛需要政策例外的复杂情况。 这是官方样题 Q3 。正确答案是在 system prompt 里加显式 escalation criteria + few-shot 示范何时升级何时自主解决 ——直指根因（决策边界不清），且是比例得当的第一反应。三个错误选项分别是：自报 confidence 路由（"poorly calibrated"，而且 agent 恰恰在难例上已经错误地自信）、训练分类器（需要标注数据与 ML 基础设施，prompt 优化都没试过）、情绪分析（解决的是另一个问题，sentiment 与案件复杂度不相关）。
三、修复之后：容易被忽略的四件事
① 交接摘要
转人工时，接手的客服看不到对话记录 。交接必须是结构化的四件套：customer ID、root cause、涉及金额、recommended action。
② case facts 不能进摘要
长会话滚动摘要时，$347.82 会变成「about $300」，「周五之前必须解决」会整句消失。把交易性事实抽成持久的 case facts 块，置于被摘要的历史之外。
③ 工具结果要裁剪
一次订单查询返回 40+ 字段，退货场景只需要 5 个。在它们累积进上下文之前裁掉——PostToolUse 是这个拦截点，同一个 hook 还可以顺手把异构的时间格式归一化。
④ 多诉求要拆项并行
一条消息三件事，正确处理是拆成独立条目、用共享上下文 并行调查、再综合成一个 统一回复。 让客户「一次只提一个问题」是把系统缺陷转嫁给用户，也直接损害 FCR 这个场景目标。
四、坑位地图
本场景最可能出题的七个决策点：
决策点 正确直觉 常见干扰项工艺
1. 资金操作的顺序保证 程序化前置条件阻断，不是 prompt 加重措辞 D6 概率当保证（"mandatory" 措辞、few-shot） 2. 工具误选 先扩写 description（四要素），再考虑改名/拆并 D2 routing layer；D3 用 few-shot 掩盖描述缺失 3. escalation 校准 显式准则 + few-shot；三个正当触发器（明确要求人工／政策空白／无法推进） D6 自报 confidence；D3 sentiment；D2 训练分类器 4. 客户明确要人工 立即转，不先调查 D3「先帮您看一下」；D4 用情绪阈值覆盖明示诉求 5. 身份多匹配 要求补充标识符，不用启发式挑 D6「选最近活跃的」「选最匹配问题的」 6. 超阈值退款 拦截并重定向 到人工流程，返回可解释的结果 D5 返回 generic failure；D6 放行后事后复核；D5 拆单绕过 7. 长会话信息损耗 case facts 块 + 工具结果裁剪 D2 完全不摘要；D6 要求摘要器「保留所有数字」
外部课程 · CertSafari — 本章 8 个考点（展开查看）用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。
考点回链 — 本场景覆盖：TS 1.1、TS 1.4、TS 1.5、TS 2.1、TS 2.2、TS 2.3、TS 5.1、TS 5.2。官方样题精讲：Q1（程序化前置条件）、Q2（扩写 tool description）、Q3（显式 escalation criteria + few-shot）。
场景题组
ch15 · Q1 · 准则 P3
Your support agent must confirm a return is within the 30-day window before calling process_refund. The system prompt states this is required and includes examples. Over 6,000 sessions, 71 refunds were issued on out-of-window returns, costing roughly $9,400. What change addresses this?
A Add a rule to the system prompt requiring the agent to state the return date and window calculation before every refund, making the arithmetic auditable in the transcript. B Add a programmatic prerequisite that blocks process_refund until an order lookup has returned a delivery date inside the eligible window. C Add a nightly reconciliation job that flags out-of-window refunds for reversal the next business day. D Reduce the refund tool's scope so it can only issue store credit, which is reversible if the window check was wrong.
正确 B TS 1.4 / TS 1.5：确定性合规需求 + 资金后果 = 程序化前置条件。题干把失败率量化了（71/6000），正是「prompt 指令有非零失败率」的实证。与官方样题 Q1 同构，只是把身份验证换成了时窗验证。
D6 概率当保证 违反 P3 A ：要求 agent「先说出计算过程」是让它自证，仍然是概率性合规——它可以一边写出正确的日期一边照样调用退款工具。
D5 吞错或炸链 违反 P6 C ：事后对账不阻止任何一次违规发生，钱已经出去了；而且向客户追回已发放的退款会制造新的客服问题。
D3 治标不治本 违反 P1 D ：把所有退款降级成 store credit 会影响 100% 的合规退款，只为兜住 1.2% 的违规——用全体客户的体验为一个可以精确解决的控制缺陷买单。
ch15 · Q2 · 准则 P1
A customer message reads: "My March return still shows unrefunded, I was charged twice in April, and please update my shipping address." Analytics show that when messages contain three or more concerns, the third is addressed only 34% of the time. What is the correct design?
A Decompose the message into distinct items, investigate each in parallel against the shared customer context, then synthesize one unified resolution. B Increase the agent's iteration budget so it has enough turns to reach every concern before ending. C Have the agent reply with a numbered list of the concerns it detected and ask the customer to confirm which to handle first, then work through them in that order. D Escalate any message containing three or more concerns to a human, since multi-issue contacts are inherently complex.
正确 A TS 1.4 的原话级 skill：把多诉求请求分解成独立条目，用共享上下文 并行调查，再综合成统一的解决方案。三要素缺一不可——拆项防漏、共享上下文免得重复验证身份、统一综合让客户收到一个连贯的答复。
D3 治标不治本 违反 P1 B ：迭代预算是 TS 1.1 点名的反模式用错地方的典型。多给轮次不保证那些轮次用在被漏掉的第三个诉求上——漏掉的原因是没有拆项，不是没轮次。
D4 甩锅错位 违反 P1 C ：把排序负担推回给客户，等于承认系统一次只能处理一件事。它直接损害 first-contact resolution——客户还要再回一轮才开始解决问题。
D3 治标不治本 违反 P2 D ：把诉求数量当复杂度代理。三个各自简单的诉求合起来仍然简单，而 TS 5.2 的正当触发器里没有「诉求多」这一条。这会系统性地压低 FCR。
ch15 · Q3 · 准则 P6
Policy blocks refunds on final-sale items. Today process_refund returns {"isError": true, "message": "Operation failed"} for these. The agent retries three times, then tells the customer the system is having trouble and to try again later. What should the tool return?
A An isError response including the full policy document text so the agent can explain the rule precisely and quote the exact clause. B An isError response with the same message, plus a global retry limit of one to avoid the wasted attempts and the delay they add. C A successful response with a zero-amount refund, so the agent stops retrying and reports the outcome to the customer. D An isError response with errorCategory identifying it as a business rule violation, retriable: false, and a customer-friendly explanation the agent can relay.
正确 D TS 2.2：结构化错误元数据让 agent 做出恰当的恢复决策。业务规则违规要带 retriable: false 与客户友好的解释 ——正是为了让 agent 能得体地告知客户「这件商品不适用退款」，而不是把策略限制说成系统故障。
D2 过度工程 违反 P4 A ：整份策略文档灌进上下文，既占 token 又让 agent 要自己从法务文本里提炼客户能听懂的解释。guide 要的是预先写好的 客户友好说明。
D3 治标不治本 违反 P6 B ：少重试两次省了点钱，客户依然被告知「系统故障，请稍后再试」——而这笔退款永远不会因为等待而变得可退。信息缺失这个根因没动。
D5 吞错或炸链 违反 P6 C ：把策略阻断伪装成成功的零元退款，客户会以为退款已办理。这是最糟的一种吞错——它制造了一个虚假的正面结果。
ch15 · Q4 · 准则 P8
Your agent resolves 58% of contacts without escalation. Review of escalated cases shows it hands off straightforward warranty replacements with clear photo evidence, while attempting cases that require documented policy exceptions. What is the most effective and proportionate improvement?
A Have the agent output a 1–10 confidence score before each response and escalate anything below 7, giving one tunable dial instead of hand-written criteria. B Add explicit escalation criteria to the system prompt with few-shot examples showing when to escalate versus resolve autonomously. C Train a classifier on twelve months of historical tickets to predict escalation need before the agent starts, learning the boundary from past human decisions. D Add sentiment detection and escalate when the customer's message registers high frustration, since escalation-worthy cases tend to be the ones customers are upset about.
正确 B 官方样题 Q3 的正确答案：显式准则划边界、few-shot 示范边界怎么走，直指根因（决策边界不清），且是比例得当的第一反应 ——改 prompt 不动基础设施。TS 4.1 + TS 4.2 + TS 5.2 三处交汇。
D6 概率当保证 违反 P8 A ：官方解析对该选项的原判是 "poorly calibrated"——agent 在难例上已经 错误地自信（它正在自主处理需要政策例外的案子），用它自己的置信度做路由等于放大既有偏差。「只有一个可调旋钮」反而是缺点：被错判的难例恰好落在高分区，任何阈值都会放行它们。
D2 过度工程 违反 P2 C ：需要标注数据与 ML 基础设施，而 prompt 优化尚未尝试。官方解析的原判就是 over-engineered。
D3 治标不治本 违反 P1 D ：解决的是另一个问题。TS 5.2 明确说 sentiment 不是案件复杂度的可靠代理；题干判错的恰恰是「有照片证据的常规换货」，与客户情绪无关。
ch15 · Q5 · 准则 P1
Each lookup_order result carries 44 fields including warehouse routing, carrier scan history, and internal audit flags. Return-handling conversations need about five of them. After several lookups in one session, the agent starts confusing order dates across orders. What is the appropriate fix?
A Trim each tool result to the return-relevant fields in a PostToolUse hook before it accumulates in context. B Summarize each order result into a short prose paragraph before adding it to the conversation. C Instruct the agent in the system prompt to focus only on the return-relevant fields and ignore the rest, which costs nothing to try first. D Limit the agent to one lookup_order call per session so payloads cannot accumulate.
正确 A TS 5.1 的原例（40+ 字段只有 5 个相关）+ TS 1.5 的拦截点：在工具结果累积进上下文之前 裁剪到只剩相关字段。PostToolUse 是 guide 点名的转换位置，同一个 hook 还能顺手做格式归一化。
D5 吞错或炸链 违反 P6 B ：转成散文破坏了字段的可寻址性，且摘要过程正是 TS 5.1 点名会压掉日期与金额的地方——恰好是题干里已经出问题的那类信息。
D6 概率当保证 违反 P3 C ：指令改变不了 token 占用——39 个无关字段仍然进了上下文并挤占注意力。「忽略它们」这件事本身还要消耗注意力。
D3 治标不治本 违反 P1 D ：限制调用次数直接废掉多订单场景（而多诉求正是本场景的常态）。为了控制 payload 体积而牺牲功能，代价与收益完全不对等。
ch15 · Q6 · 准则 P6
The interception hook blocks a $780 refund because policy caps agent-issued refunds. The agent receives the block and tells the customer "I'm unable to complete that action." The customer asks what happens next and the agent has no answer. What is missing from the design?
A The hook threshold should be raised so that legitimate refunds of this size are not blocked, since a cap that fires on ordinary cases is set too low. B The agent should retry the refund in two smaller amounts that each fall under the cap, resolving the case on first contact instead of leaving the customer waiting. C The hook should redirect into the human escalation workflow and return a result explaining the block, so the agent can inform the customer and hand off with a structured summary. D The agent should tell the customer to contact support by phone, since this path exceeds its authority and a human can approve the amount immediately.
正确 C TS 1.5 的完整语义：拦截违反策略的操作并重定向到替代流程 （人工升级）。只阻断不给出路是半个实现。返回的结果要说明原因，agent 才能得体地告知客户，并按 TS 1.4 编制交接四件套（customer ID、root cause、金额、建议动作）。
D3 治标不治本 违反 P3 A ：调高阈值不是修复缺失的重定向路径，只是把边界挪到下一个金额。策略上限本身是业务决定，不该为了绕开设计缺陷而改动。
D5 吞错或炸链 违反 P6 B ：拆单绕过上限是主动规避合规控制——把一个可以正常升级的案子变成了一次违规操作，而且人工与审计都看不到。
D4 甩锅错位 违反 P1 D ：把客户推去打电话，等于让他重新排一次队、重述一遍问题。系统里已经有 escalate_to_human，且 agent 手上已有全部诊断信息——不用它而转嫁给客户，直接损害 FCR。
ch15 · Q7 · 准则 P4
After integrating a shipping MCP server and a loyalty MCP server, your single support agent now sees 19 tools. Tool selection accuracy drops, and the agent has begun calling loyalty-tier tools during refund conversations. All tool descriptions are detailed. What is the right structural response?
A Disconnect the loyalty MCP server, since loyalty data is rarely needed in support conversations and the agent can ask the customer for their tier when it matters. B Add a system prompt section listing which tools apply to which conversation types, which needs no change to the agent topology and ships in a single deploy. C Set tool_choice: "any" so the agent commits to a tool instead of deliberating across all 19, rather than answering from memory and skipping the lookup entirely. D Split into role-scoped agents — returns, billing, account — each with roughly four or five tools, routing cross-role needs through the coordinator.
正确 D TS 2.3 的两条正面命中：工具过多（guide 举的正是 18 vs 4–5）降低选择可靠性；拿到专业外工具的 agent 倾向误用（退款对话里去够 loyalty 工具）。解法是按角色收敛工具集，跨角色需求经 coordinator。
D4 甩锅错位 违反 P4 A ：断开服务器会连带失去真实能力（会员等级确实会影响退货政策）。TS 2.4 的设计前提就是多服务器工具同时可用，控制手段是分配而非少接。
D3 治标不治本 违反 P4 B ：在 system prompt 里写工具适用清单，既是概率性约束，又会因关键词敏感反过来干扰工具选择（TS 2.1）。候选集合仍然是 19 个。
D1 凭空捏造 违反 P4 C ：tool_choice: "any" 保证模型调用某个 工具而不是返回纯文本，它不缩小候选集合，也不提升选对的概率。19 选 1 的难度没变。
ch15 · Q8 · 准则 P6
A conversation has run 30 turns across two issues. The agent escalates. The human agent, who cannot see the transcript, receives: "Customer unhappy about a return and a billing issue; please assist." Average handling time for escalated cases is 9 minutes, most of it re-investigation. What should the handoff contain?
A The full 30-turn transcript, so nothing is lost to summarization. B The last five turns, which contain the most recent state of both issues after the earlier triage is done. C A structured summary per issue: customer ID, the diagnosed root cause, the amount in question, and the recommended action. D A link to the session plus a severity rating, so the human agent can prioritize the queue and inspect whatever detail the case turns out to need.
正确 C TS 1.4 的交接四件套：customer ID、root cause、涉及金额、recommended action。这个清单的前提正是题干给的那句——接手的人看不到 transcript ，所以必须交给他结论性的结构化事实，而不是原始素材。多诉求会话则每个 issue 各一份。
D3 治标不治本 违反 P1 A ：转发全文把 9 分钟的重建工作原样保留给人工，只是换了载体；agent 已经完成的诊断成果被扔掉了。
D5 吞错或炸链 违反 P6 B ：截取最后五轮会丢掉前面的诊断过程与关键事实（订单号、金额往往出现在早期），是一种按位置而非按重要性的信息销毁。
D4 甩锅错位 违反 P1 D ：题干的前提就是人工无法访问 会话内容；给链接并不改变这个前提。severity 评级解决排队顺序，不解决接手成本。
ch15 · Q9 · 准则 P5
Your team wants to reduce cost. Two workloads exist: the live support agent, where customers wait for replies, and a nightly job that reads the previous day's transcripts and produces a quality-scoring report for the support manager. Which move is correct?
A Move both to the Message Batches API, polling for completion in the live path, since the discount applies per request regardless of workload. B Move the nightly quality-scoring job to the Message Batches API and keep the live agent on the synchronous API. C Keep both synchronous and reduce cost by trimming the system prompt and tool descriptions, since input size is the one lever that applies to both workloads. D Move the live agent to batch during off-peak hours only, when latency matters less because overnight contact volume is low enough to absorb longer waits.
正确 B TS 4.5 的适配轴：batch 适配非阻塞、延迟容忍的负载（过夜报告是 guide 的原例），不适配有人在等结果的流程。夜间质检作业还是「一次输入一次输出」的形态，不涉及单请求内的多轮工具调用——两个条件都满足。
D6 概率当保证 违反 P5 A ：客服对话是阻塞负载，batch 有最长 24 小时的处理窗口且无 latency SLA。轮询不会让它变快，只会让客户在等待中挂断。
D3 治标不治本 违反 P2 C ：裁剪工具描述与 TS 2.1 直接冲突——描述是工具选择的首要机制，缩短它会把成本问题换成准确率问题。而现成的 50% 折扣放着没用。
D2 过度工程 违反 P5 D ：客服的阻塞语义不随时段改变——夜里联系的客户同样在等回复。按时段切换机制还引入了两套代码路径的复杂度。