Chapter 04 · Domain 1(权重 27%)
强制与状态hooks、prerequisite gates、session resume 与 fork
本章是 P3「关键规则用确定性强制」的技术实现层。官方样题 12 道里有 1 道直接考它(Q1),而它的判断轴——概率性合规 vs 确定性保证 ——渗透在客服、CI、数据抽取三个场景里。后半章讲会话状态:什么时候续接,什么时候重开。
一、两种强制手段的分工
Exam Guide 用一句话定了调:hooks 提供 deterministic guarantees,prompt 提供 probabilistic compliance。 当确定性合规是需求(例如资金操作前的身份验证),单靠 prompt 指令有非零失败率 ——注意这个措辞,它不是「效果差一点」,而是「在足够多的样本上必然会失败若干次」。
程序化强制hooks / prerequisite gates Prompt 引导system prompt / few-shot
保证强度 确定性:违规路径根本走不通 概率性:失败率非零,且不可预测
适配 资金、身份验证、合规、外发内容审查 风格偏好、软性流程、优先级倾向
成本 要写代码、要维护;规则变更需改代码 改一行文本
题干识别信号 出现金额、合规、已造成损失 的字样,或「X% 的案例跳过了某一步」 出现「输出格式不一致」「有时会漏掉某个建议」
别走到另一个极端 — 把一切都程序化会回到 P2 的过度工程。判断轴是后果严重性 ,不是手段的强弱本身。一个「希望 Claude 优先建议函数式写法」的团队约定,用 CLAUDE.md 就够了,上 hook 是杀鸡用牛刀。
二、Prerequisite gate:阻断式前置条件
最典型的形态:阻断下游工具调用,直到前置步骤完成 。guide 的原例就是官方样题 Q1 的场景——在 get_customer 返回一个已验证的 customer ID 之前,阻断 process_refund(样题里同时阻断了 lookup_order)。
# 伪代码:出站 tool call 拦截
def before_tool_call(name, args, state):
if name in ("lookup_order", "process_refund"):
if not state.get("verified_customer_id"):
return Block(reason="get_customer must return a verified customer ID first")
return Allow()
关键在于「阻断」二字:gate 不是提醒模型、不是在 prompt 里写 mandatory,而是让那次调用无法发生 。返回给模型的阻断理由会进入对话历史,模型据此自行纠正顺序——这就是「用确定性机制约束模型驱动的循环」(ch02 第三节)的具体样子:agent 保留了灵活性,但违规路径被物理封死。
三、Hooks 的两个方向
Agent SDK 的 hook 按拦截方向分两类,考试都考过:
方向 Hook 做什么 官方举例
入站 工具结果 → 模型
PostToolUse
在模型处理之前转换/归一化 工具结果
把不同 MCP 工具返回的异构格式(Unix timestamps、ISO 8601、数字状态码)归一化成统一格式
出站 模型 → 工具
tool call interception
拦截并阻断 违反业务规则的操作,重定向到替代流程
拦截 refunds exceeding $500,重定向到人工升级流程
入站方向的价值容易被低估:如果三个 MCP 工具分别返回 1735689600、"2025-01-01T00:00:00Z"、"01/01/2025",模型每一轮都要花注意力做格式推断,还会在跨工具比较日期时出错。PostToolUse 把这件事从「模型每次都要做对的推理」变成「代码做一次的转换」——同样是把概率换成确定性,只是这次换的不是合规而是数据一致性。
工程上还有一个常被一起讨论的收益:PostToolUse 归一化的同时可以顺手裁剪 ——只保留下游真正需要的字段。这与 TS 5.1 的「trimming verbose tool outputs」是同一个拦截点上的两件事,实现时通常写在一起。Exam Guide 把它们分别归在 TS 1.5 与 TS 5.1 下,考试可能从任一角度问,但正确答案的形态是一致的。
四、多诉求请求的处理
客户一条消息里塞了三件事(「我的退货没退款、上个月被重复扣费、还想改配送地址」),标准做法分三步:
拆项 ——把多诉求请求分解成互相独立的条目;
并行调查 ——各条目基于共享上下文 并行调查(不是三次独立会话,客户身份等共享事实要复用);
统一综合 ——合成一个 统一的解决方案回复,而不是三段互不相干的答复。
考场上的干扰项通常是「让客户一次只提一个问题」(D4 把负担转嫁给用户)或「按顺序逐条处理」(丢掉了并行与共享上下文)。
五、交接摘要:给看不到 transcript 的人
升级到人工时,接手的客服看不到对话记录 。这个前提决定了交接摘要必须是结构化的,guide 点名了四项内容:
customer ID — 接手的人不必重新问身份
root cause — 已经诊断出的根因,不是对话流水
refund amount / 涉及金额
recommended action — agent 的建议动作
反面:把整段对话原样转给人工(对方要重读一遍),或只写一句「客户对退款不满意」(对方要从零调查)。
六、会话状态:续接、分叉、还是重开
claude --resume <session-name> ✔ 真实存在 · 按名字续接特定的既往会话
fork_session ✔ 真实存在 · 从共享基线创建独立分支,探索分歧方案
/compact ✔ 真实存在 · 压缩冗长发现输出,降低 context 占用
/memory ✔ 真实存在 · 查看已加载的 memory 文件,诊断跨会话行为不一致
/memory 与 /context :考纲(TS 3.1)把 /memory 描述为查看已加载的 memory 文件、诊断跨会话不一致,全书题目按这个口径,考试也按这个口径作答 。当前产品里,/memory 列出 user / project 各作用域的 memory 文件位置(包括尚未创建的),用来打开编辑这些文件、开关 auto memory;要确认启动时实际加载了哪些 CLAUDE.md 与 rules 文件,文档指向 /context(看 Memory files 列表)。
来源:How Claude remembers your project · View and edit with /memory ;Commands 。查阅于 2026-10-16。
三个机制的分工是考试的高频对照表:
机制 用在什么时候 关键前提
--resume <session-name>跨工作日续接同一条调查线 既往上下文大体仍然有效
fork_session从同一份分析基线并行探索分歧 方案(两种重构路线、两种测试策略) 基线可共享,分支需互不污染
新开会话 + 结构化摘要注入 既往 tool results 已经过期(代码改了、订单状态变了) stale 时优于 resume
最后一行是 TS 1.7 里最容易被忽略、也最容易出题的一条:当既往 tool results 已经陈旧,新开一个会话并注入结构化摘要比 resume 更可靠。 原因是 resume 会把过期的文件内容、过期的查询结果一起带回上下文,模型无从知道哪些还作数——它会自信地基于旧快照推理。
还有一条配套 skill:确实要 resume 时,应当告知会话哪些文件已经变更 (guide 的措辞是「informing the agent about changes… is important」),让它做定向重新分析,而不是要求它把整个代码库重新探索一遍。
外部课程 · CertSafari — 本章 3 个考点(展开查看)
用于补读和错题复盘;第三方 AI 生成练习材料,非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对:2026-10-16。
考点回链 — 本章覆盖:TS 1.4(程序化强制 vs prompt 引导、阻断式前置条件、多诉求拆项并行调查、结构化交接摘要)、TS 1.5(PostToolUse 归一化异构格式、出站 tool call 拦截阻断超阈值操作并重定向、确定性保证 vs 概率性合规)、TS 1.7(--resume <session-name>、fork_session、告知文件变更、stale tool results 时新会话 + 摘要优于 resume)。相邻考点:agentic loop 见 ch02,escalation 判据见 ch14。
本章题组
ch04 · Q1 · 准则 P3
Your billing agent must never issue a credit before confirming the account is not already in a dispute state. The system prompt says this is mandatory and includes three few-shot examples. Over 4,000 sessions, 47 credits were issued without the dispute check, three of which hit accounts with active chargebacks. What should you implement?
A Rewrite the system prompt instruction in stronger language and move it to the top of the prompt where the model attends to it most reliably.
B Add six more few-shot examples covering the specific account states that were missed, so the pattern generalizes.
C Add a programmatic prerequisite that blocks the credit-issuing tool until the dispute-status tool has returned a result for that account.
D Have the agent self-report after each session whether the dispute check was performed, and audit the sessions where it reports "no."
正确 C TS 1.4 / TS 1.5:需要确定性合规时,prompt 指令有非零失败率——题干把这个失败率量化了(47/4000)。正确形态是阻断式前置条件:在前置工具返回结果之前,下游工具调用根本发不出去。与官方样题 Q1 完全同构(金钱后果 + 跳步)。
D6 概率当保证 违反 P3 A :加重措辞、调整位置,都还是概率性合规。题干已经证明现有的 prompt + few-shot 组合失败了 47 次;同一类手段的另一个版本没有理由跨越到 100%。
D6 概率当保证 违反 P3 B :few-shot 在判断边界模糊 时有效(TS 4.2),但这里的规则毫不模糊——它只是没被 100% 执行。同官方样题 Q1 的 C 选项。
D5 吞错或炸链 违反 P6 D :事后审计不阻止任何一次违规发生,钱已经出去了;而且它依赖 agent 自报自己漏了哪一步——恰恰是最不可能被自己发现的错误类型。
ch04 · Q2 · 准则 P1
Your support agent queries three MCP tools. get_customer returns signup_date: 1735689600, lookup_order returns placed_at: "2025-01-01T00:00:00Z", and the legacy shipping tool returns ship_date: "01/01/2025". The agent frequently misorders events and once told a customer their order predated their account. What is the most appropriate mechanism?
A Add a note to the system prompt describing each tool's date format so the model can convert them whenever it compares or orders events.
B Ask the owning teams to change all three MCP servers to emit ISO 8601, and block the agent rollout until they do, since one shared format removes the ambiguity at its source.
C Give the agent a convert_timestamp tool it can call whenever it needs to compare two dates from different sources.
D Implement a PostToolUse hook that normalizes all three formats into a single representation before the model sees the results.
正确 D TS 1.5 的原例:PostToolUse hook 拦截工具结果,在模型处理之前把异构格式(Unix timestamps、ISO 8601、数字状态码)归一化。它把「模型每一轮都必须推理正确的格式转换」变成「代码做一次的确定性转换」。
D6 概率当保证 违反 P3 A :把格式转换的正确性押在模型每次都推理无误上。题干已经出现了实际的对客错误——这正是概率性手段不够用的证据。
D4 甩锅错位 违反 P2 B :把负担转嫁给三个上游团队并且阻塞自己的上线,而问题在你这一侧 有一个成本极低的拦截点。改上游合约是长期正解,不是这道题问的「最合适的机制」。
D2 过度工程 违反 P4 C :多给一个工具反而增加了工具选择的决策复杂度(TS 2.3),而且它仍然依赖模型记得 在每次比较前调用它——把确定性问题又变回了概率问题。
ch04 · Q3 · 准则 P3 + P6
Policy states that refunds exceeding $500 require human approval. Your agent occasionally issues larger refunds directly. You add an interception hook. When the hook fires on a $780 refund, what should happen?
A Block the tool call and redirect into the human escalation workflow, returning to the agent a result that explains the block so it can inform the customer and hand off with a structured summary.
B Block the tool call and return a generic "Operation failed" result so the agent retries with a different approach, keeping internal policy thresholds off the tool surface.
C Allow the call but flag the transaction for post-hoc review, so the customer experience is not interrupted and every over-threshold refund still lands in front of a human reviewer.
D Block the call and silently split it into two refunds under the threshold so the policy limit is respected per transaction and the customer is made whole without an approval delay.
正确 A TS 1.5 的原例语义完整:拦截违反策略的操作并重定向到替代流程 (人工升级)。阻断只是一半,另一半是把它导向一条可用的路径;返回给 agent 的结果要说明原因,agent 才能得体地告知客户并按 TS 1.4 编制结构化交接摘要。
D5 吞错或炸链 违反 P6 B :泛化错误消息("Operation failed")正是 TS 2.2 点名的反模式——它隐藏了恢复决策所需的上下文。agent 不知道这是策略阻断还是瞬时故障,只会盲目重试。
D6 概率当保证 违反 P3 C :放行 + 事后复核不是强制,是记录。策略要求的是人工批准 (事前),这个方案把它降级成了人工知晓(事后),钱已经出去了。
D5 吞错或炸链 违反 P6 D :拆单绕过阈值是把合规控制主动规避掉,而且「silently」意味着人工与审计都看不到——这是把一个合规缺口变成了一个合规违规。
ch04 · Q4 · 准则 P5
Two days ago an agent session analyzed a 60-file service to plan a migration. Since then, teammates merged 9 commits touching 14 of those files, including the module the plan depends on most. You want to continue the migration work today. What is the best approach?
A Resume the session with --resume and continue from where it left off; the analysis is only two days old and the whole 60-file picture is still loaded.
B Start a fresh session and inject a structured summary of the prior analysis, since the earlier tool results no longer reflect the current files.
C Use fork_session from the prior session so the stale branch is preserved while you work on a clean one, keeping the earlier reasoning available for comparison.
D Resume the session and instruct it to re-read all 60 files from disk before continuing, refreshing the whole analysis before any migration step is planned.
正确 B TS 1.7 的明确排序:当既往 tool results 已经陈旧时,新开会话 + 结构化摘要注入比 resume 更可靠 。resume 会把 14 个文件的过期快照一起带回上下文,模型无从判断哪些还作数,会自信地基于旧内容推理。
D6 概率当保证 违反 P5 A :resume 的适用前提是「既往上下文大体仍然有效」。题干精确地否定了这个前提——变更命中了计划最依赖的模块。用时间新旧(两天)代替内容有效性判断,是错的代理指标。
D3 治标不治本 违反 P5 C :fork_session 的用途是从有效 基线探索分歧方案。这里基线本身失效了,从一个失效基线分叉只会得到两条都基于旧快照的分支。
D2 过度工程 违反 P2 D :重读全部 60 个文件既昂贵又与 TS 1.7 的另一条 skill 相悖——正确做法是告知具体变更做定向重新分析 ,而不是要求全量重新探索。而且旧的过期内容仍留在上下文里与新内容并存。
ch04 · Q5 · 准则 P1
A customer writes: "My return from March still hasn't been refunded, I was double-charged in April, and I need my delivery address updated before the next shipment." Your agent handles the refund, then ends the turn. The other two issues are silently dropped in 40% of such messages. What is the correct design?
A Instruct the agent to ask the customer to submit one issue per message so each can be handled cleanly and tracked as its own ticket.
B Add an iteration cap of at least three turns so the agent cannot end the session before addressing three concerns, which matches the observed length of these messages.
C Decompose the message into distinct items, investigate each in parallel using the shared customer context, then synthesize one unified resolution response.
D Route any message containing more than one question mark or conjunction directly to a human agent, since multi-issue messages are exactly where the drop rate is concentrated.
正确 C TS 1.4 的原话级 skill:把多诉求请求分解成互相独立的条目,用共享上下文 并行调查,再综合成统一的解决方案。三个要素缺一不可——拆项(否则漏)、共享上下文(否则重复验证身份)、统一综合(否则回复支离破碎)。
D4 甩锅错位 违反 P1 A :把系统缺陷转嫁给用户,与官方样题 Q12 的 B 选项(要求开发者拆小 PR)同一工艺。而且它直接损害 first-contact resolution 这个场景目标。
D6 概率当保证 违反 P3 B :迭代上限是 TS 1.1 点名的反模式,用在这里更离谱——它强制 agent 多跑几轮,但完全不保证多出来的轮次用在了被漏掉的诉求上。
D3 治标不治本 违反 P2 D :用标点符号当复杂度代理(对照 TS 5.2:sentiment 与自报 confidence 都不是复杂度的可靠代理,同类谬误)。而且把本可自主解决的常规诉求推给人工,正是官方样题 Q3 里 55% first-contact resolution 的病因。「多诉求正是掉件高发区」这个观察成立,但它推出的是「要把多诉求拆开处理」,不是「要把多诉求整批转人工」。
ch04 · Q6 · 准则 P6
Your agent escalates a complex warranty dispute to a human queue. Human agents report they spend 6–8 minutes per escalated case rebuilding what happened, because they have no access to the conversation transcript. Currently the agent passes along the customer's last message. What should the handoff contain?
A The full conversation transcript, so the human agent has complete information, nothing is lost in summarization, and the customer's own wording is preserved.
B A structured summary: customer ID, the root cause the agent diagnosed, the amount in question, and the recommended action.
C A one-line severity label and a confidence score so the queue can prioritize which escalations to handle first.
D A link to the session so the human agent can resume it in the agent console and inspect whatever they need.
正确 B TS 1.4 点名的四件套:customer ID、root cause、涉及金额、recommended action。这个清单的设计前提正是题干给的那句——接手的人看不到 transcript ,所以交给他的必须是结论性的结构化事实,不是原始素材。
D3 治标不治本 违反 P1 A :转发全文把 6–8 分钟的重建工作原样保留给了人工,只是换了个载体。「不做摘要就不会丢信息」听起来稳妥,实际是把 agent 已经完成的诊断成果扔掉了。
D6 概率当保证 违反 P8 C :severity 标签 + 未校准的 confidence score 解决的是排队顺序,不是接手成本;而自报 confidence 不可作路由依据(TS 5.2 / TS 5.5)。人工拿到它仍然要从零调查。
D4 甩锅错位 违反 P1 D :题干的前提就是人工无法访问 会话内容;给一个链接并不改变这个前提,只是把「无 transcript」重新表述了一遍。
ch04 · Q7 · 准则 P2
Your team's CLAUDE.md asks Claude to prefer table-driven tests over parameterized helpers. Compliance is around 85%; the remaining 15% are still correct, working tests that reviewers occasionally rewrite for consistency. A teammate proposes adding a hook that blocks any test file write not matching the table-driven pattern. How should you evaluate this?
A Approve it — hooks provide deterministic guarantees, and 85% compliance is clearly insufficient for a documented team standard; the residual 15% is exactly the kind of drift hooks were built to remove.
B Approve it, but only after the pattern matcher is proven accurate on the existing test suite to avoid false blocks, which turns the main objection to hooks into a solvable engineering problem.
C Reject it and remove the convention from CLAUDE.md instead, since a standard that cannot be enforced deterministically is not a real standard, and the always-loaded file should carry only rules worth their context cost.
D Reject it — the failure mode is a style preference with no correctness, financial, or compliance consequence, so prompt-level guidance is the proportionate mechanism; a path-scoped rule for test files is the appropriate next step if 85% is not enough.
正确 D 确定性强制的判断轴是后果严重性 ,不是手段强弱(P3 的边界 + P2 的比例原则)。题干明说剩余 15% 是「正确、能工作的测试」——没有资金、合规或正确性后果。TS 3.3 给了恰当的中间档:用 .claude/rules/ 的 glob path-scoping 让约定只在编辑测试文件时加载。
D2 过度工程 违反 P2 A :「hooks 提供确定性保证」是对的,但它不是「所以任何合规缺口都该上 hook」的理由。把风格偏好程序化,正是 ch01 P3 边界点名的反向陷阱。
D2 过度工程 违反 P2 B :给过度工程方案加一道验收条件,仍然是过度工程——而且引入了一个需要长期维护的模式匹配器,用来拦截本来无害的代码。
D4 甩锅错位 违反 P9 C :「不能确定性强制就不算标准」是个假二分。CLAUDE.md 的定位正是始终加载的普适标准 (TS 3.2),概率性引导对风格约定完全够用;删掉它等于放弃已经拿到的 85%。
ch04 · Q8 · 准则 P5
You spent Monday inside a named Claude Code session, checkout-latency, tracing a p99 regression through 38 files of a payment service. The session ended with six ranked candidate causes, two of which still have to be measured against the load-test harness. Overnight the service took exactly one merge: a log message string was reworded in refund_notice.go — one of the 38 files the session read, and a file none of the six ranked causes routes through. It is Tuesday morning and you want to finish those two measurements. How should you continue?
A Resume with --resume checkout-latency and open the turn by naming the one file that changed, so the session re-checks that file and continues down its ranked list.
B Start a fresh session and inject a structured summary of Monday's six ranked causes, since the overnight merge means the session's tool results no longer match what is on disk.
C Use fork_session on Monday's session so one branch measures the top-ranked cause while the other re-derives the ranking against the current tree, then compare what the two branches conclude before committing to a fix.
D Resume with --resume checkout-latency --refresh, which re-reads every file whose contents changed while the session was suspended before it answers anything further.
正确 A TS 1.7 的取舍是双向 的,这道题考的是 Q4 的另一侧:prior context 大体仍然有效时,--resume <session-name> 续接命名会话正是 guide 的 Skills 明写的做法(把同一条调查跨多个工作日续下去)。题干把「仍然有效」写死了——38 个文件里只动了 1 个,且六条候选因果都不经过它。正确项的后半同样是 guide 原文:续接后要告知哪些已分析文件被改过 ,让它做定向再分析而不是整轮重新探索 。与本章 Q4 的分界线就在这里:那里 14 个文件变了、还命中计划最依赖的模块,前提翻转,答案才翻到 fresh session + 结构化摘要。
D2 过度工程 违反 P5 B :把「文件动过 = tool results 过期」当成无条件规则,套在一个题干已经否定的前提上——变的是一行日志文案,六条候选因果一条都不经过它。代价是真实的:重建会话要把周一的推理压成一段摘要,而排名背后的细节正是摘要最先丢掉的东西。
D2 过度工程 违反 P2 C :fork_session 的适应症是从有效基线 分叉出两条需要互相比较的路线(guide 的原例是比较两种测试策略、两种重构方案)。这里只有一条工作线、一个待办清单,没有第二种方案要比;分叉出来的第二条分支做的是重排一份没有理由怀疑的排名。
D1 凭空捏造 违反 P5 D :guide 记载的形态只有 --resume <session-name>,--refresh 在 Exam Guide 里没有任何出处——D1 的识别信号正是「官方材料里从没见过它」,别拿「名字看着顺理成章」当放行理由。更要紧的是它把一件 prompt 层的事想象成了开关——「告诉会话哪些文件变了」本来就是你在续接后的第一句话里说的,这也正是 TS 1.7 那条 skill 的字面内容。