Escalation 與模糊情境的解決模式

CCA-F 考試任務說明 5.2——「設計有效的 escalation 與模糊性解決模式」——屬於 Domain 5（Context Management & Reliability，15% 考試比重），但透過 agentic loop 延伸至所有其他領域。儘管 Domain 5 是五大領域中比重最輕的，社群通過考試的報告一再指出，任務 5.2 是表現強勁的考生失分的重災區，平均多丟兩到三道計分題。原因在於：他們把 escalation 等同於失敗、在高風險情境下以假設取代 clarification，或設計出遺漏人工審查員真正需要之脈絡的 escalation payload。客戶服務解決方案 agent 的情境對這個任務說明的考驗最為嚴格，出題模式反覆要求考生在「詢問」、「假設並標記」、「graceful degradation」與「escalation」之間做出選擇——在給定的風險狀態與信心狀態下，只有一個答案是正確的。

這份學習筆記逐一走過 CCA-F 期待你設計的完整面向：如何偵測任務規格不足、如何塑造精準的 clarification 請求（單一問題 vs 批次問題）、何時在執行前詢問 vs 帶著明確假設嘗試執行、human escalation 的標準觸發條件、如何組合一個讓人工審查可行的 escalation payload、分層路由的運作方式（specialist → manager → system owner）、如何產生帶有明確不確定性標記的 graceful degradation 輸出、人工提供 clarification 後如何恢復 agent 執行、多 agent 系統中的模糊性所有權、避免過度 escalation 的閾值校準，以及將解決方案回饋至 CLAUDE.md 以防同一個模糊性再次需要人工處理。最後收錄常見考試陷阱、連結到客戶服務解決方案 agent 情境的練習錨點，以及六題 FAQ。

為什麼 Escalation 與模糊性解決是架構問題，而非提示問題

把任務 5.2 當作「告訴 Claude 不確定時就詢問」來應對的考生，在 CCA-F 上屢屢選到錯誤答案。考試將 escalation 視為一種具備四個具體面向的架構能力：偵測機制（判斷模糊性是否存在）、請求或 escalation 決策策略（在 clarification 與路由給人工之間擇一）、payload 形式（人工審查員要消費的內容），以及重新進入協議（以新資訊恢復 agent 執行）。這四個面向每一個都是程式化的——schema 強制執行的工具呼叫、結構化的錯誤回應、跨人工暫停持續存在的 session 狀態，以及寫回組態檔的規則更新。單靠提示層面的指引（「不確定時就詢問」）無法可靠地產生上述任何一個面向。

社群痛點 pp-01——程式化強制執行 vs 提示導向指引——在此直接適用。當 CCA-F 答案選項提供「加入更強的 system prompt 告訴 Claude 要詢問」，而另一個競爭選項提供「定義一個 request_clarification 工具，其 structured schema 要求 agent 在高風險行動前必須呼叫它」，結構化工具的答案幾乎永遠是正確答案。考試獎勵將 escalation 路徑設計為架構中的一等公民，而非寄望模型會做出正確行為。

模糊性偵測 — 識別任務規格不足的時機

第一個架構面向是偵測。在 agent 能夠提問或 escalate 之前，它必須先察覺到當前的任務規格在可接受的信心水準下無法執行。CCA-F 將模糊性偵測視為一組具體訊號，而非模糊的「模型感覺哪裡不對勁」。

六個應觸發模糊性處理的訊號

1. 缺少指示對象 — 任務提到「該使用者」、「該帳戶」或「該報告」，但存在多個候選對象，且從脈絡中無法區分正確者。
2. 未明確指定閾值 — 任務要求「近期訂單」或「高價值客戶」，卻未定義數字截止點，而截止點會實質改變結果。
3. 指令衝突 — 對話、system prompt 或 CLAUDE.md 中的兩條指令，在當前情境下相互矛盾。
4. 超出範疇的請求 — 使用者要求的事項超出 agent 的工具許可清單所能完成的範圍，或超出 agent system prompt 中記載的服務範疇。
5. 分類信心低於閾值 — 基於工具的分類器回傳的分數低於設定的信心閾值。
6. 新型邊緣案例 — 當前案例與提供的 few-shot 範例或標準作業程序模式都不相符，顯示 agent 正在進行外推。

每個訊號對應一種不同的架構回應。缺少指示對象和未明確指定閾值，透過 clarification 請求解決。超出範疇的請求，透過 graceful degradation 加上 escalation 解決。信心低於閾值的訊號，根據風險高低決定採用 clarification 還是 escalation。新型邊緣案例通常觸發帶有詳細 payload 的 escalation，以便解決方案日後能成為一條 CLAUDE.md 規則。

偵測是工具呼叫，不是直覺

最簡潔的架構是給 agent 一個結構化的 evaluate_task_completeness 工具（或同等功能的具名工具），回傳具型別的判決：ok、missing_field、ambiguous_reference、out_of_scope 或 low_confidence，並附帶可選的 details 物件。agentic loop 接著根據判決分支：ok 繼續執行，missing_field 或 ambiguous_reference 觸發 clarification 請求，out_of_scope 觸發立即 escalation，low_confidence 則查詢風險對照表後再做決定。

Clarification 請求設計 — 精準的單一問題 vs 批次問題

一旦 agent 判定需要 clarification，下一個設計決策是形式：每次問一個精準問題，還是在單一來回中批次提問？CCA-F 直接考驗這個取捨。

單一問題 clarification — 何時優先採用

單一問題 clarification 適用於以下情況：

• 第一個問題的答案，會實質改變後續需要哪些跟進問題。
• 使用者使用對話式頻道（聊天、語音），冗長的問卷會顯得像在盤問。
• 任務可以逐步推進——每個回答的問題解鎖下一個計劃步驟。

單一問題 clarification 的代價是多次對話來回；好處是絕不會問到因先前答案而已失去意義的問題。

批次 clarification — 何時優先採用

批次 clarification 適用於以下情況：

• 使用者是技術操作人員（API 客戶端、工單提交者），可以一次填妥結構化表單。
• 問題彼此獨立——任何一個答案都不會使其他問題失效。
• 任務的 context 重建成本高（例如設置費時的長篇研究任務），不宜反覆中斷。

批次 clarification 通常以 JSON 表單或編號的是/否、簡答題清單呈現，每個問題以欄位名稱標記，以便 agent 能以程式化方式將答案對應回來。

混合模式

在實務上，生產 agent 會交替使用兩種模式。一個透過聊天頻道服務的客戶服務 agent，每次問一個問題；同一個 agent 處理非同步電子郵件工單時，則發送單一整合問卷並等待回覆。選擇哪種模式，取決於 agent 對頻道的感知，而非全域偏好設定。

Clarification 時機 — 執行前詢問 vs 帶著明確假設嘗試執行

比形式更微妙的設計選擇是時機。agent 應在嘗試任何行動之前先詢問 clarification，還是帶著明確的假設繼續執行，並在答案中呈現這個假設？

執行前詢問 — 高風險時的選擇

以下情況應在執行前詢問：

• 行動是破壞性或不可逆的（刪除帳戶、退款、發布內容、合併至 main）。
• 行動有外部影響範圍（向客戶發送電子郵件、刷卡扣款、呼叫付費第三方 API）。
• 行動受合規約束（GDPR 資料刪除、HIPAA 管制的揭露、金融法規）。

這些情況下，在未驗證的假設上執行並事後補救，並不是有效的復原方式——電子郵件無法「取消發送」，扣款無法「取消扣除」。clarification 暫停的成本微乎其微；錯誤的代價高昂。

帶著明確假設嘗試執行 — 低風險且回復成本低時的選擇

以下情況可帶著明確假設嘗試執行：

• 行動是唯讀的（查詢記錄、取得文件、產生草稿）。
• 輸出是草稿，人工審查後才具權威性。
• 等待 clarification 會主導總延遲時間，且使用者明確重視速度（例如，協助打字過程中的開發者生產力 agent）。

這個模式下，agent 產出盡力而為的輸出，並在開頭或標注處說明假設（「我假設『上個月』指的是前一個日曆月；若您指的是滾動 30 天視窗，請告知」）。使用者可選擇接受或修正方向。

風險 × 可逆性矩陣

結合這兩個維度，策略就變得明確：

• 高風險、低可逆性 → 執行前詢問。永遠如此。
• 高風險、高可逆性 → 首次操作執行前詢問；對已知模式的重複操作，帶著標記的假設執行。
• 低風險、低可逆性 → 執行前詢問（罕見組合；若存在，可逆性是主導約束）。
• 低風險、高可逆性 → 帶著明確假設執行。

Escalation 觸發條件 — 信心低於閾值、缺少授權、新型邊緣案例

Escalation——有別於 clarification——是將控制權轉移給人工（或更具權威的 agent）。CCA-F 期待你認識三個標準觸發條件。

觸發條件一：信心低於閾值

agent 或底層分類器回傳的信心分數，低於當前行動風險所設定的閾值。一個發起退款的 agent，可能要求「此退款符合政策」的信心需達 0.95；任何低於此值的情況，都觸發 escalation 至人工退款專員。閾值以風險比例調整——風險愈高的行動，要求 agent 自主執行前的信心愈高。

觸發條件二：缺少授權

agent 沒有執行所請求行動所需的工具、權限或角色。一個僅有唯讀 CRM 存取權限的客服 agent，無法更新帳單地址；正確回應不是拒絕、不是假裝、也不是試圖繞道——而是 escalate 給擁有該授權的 agent（無論是人工或自動化）。在工具許可清單不包含所需行動的情境中，缺少授權的 escalation 幾乎永遠是正確答案。

觸發條件三：新型邊緣案例

當前案例與任何已知的標準作業程序、CLAUDE.md 規則或 few-shot 範例都不相符。agent 的選項是：(a) 外推並碰運氣，或 (b) 帶著詳細 payload 進行 escalation 讓人工解決並記錄。CCA-F 一貫選 (b)。新型案例是最具價值的 escalation，因為它的解決方案會成為明天的規則。

第四個、隱含的觸發條件：使用者明確要求

只要使用者說「我想跟真人說話」，agent 就必須 escalate。這與其說是架構選擇，不如說是合規底線。

Escalation Payload 設計 — 為有效人工審查提供哪些脈絡

Escalation 只有在接收端的人工能迅速採取行動時才有價值。一個迫使人工必須從頭重新調查案例的 payload，會摧毀自主 agent 先前工作的大部分價值。CCA-F 期待你將 escalation payload 設計為結構化、自給自足的交接文件。

最低可行 Escalation Payload

每個 escalation payload 都應包含：

1. 案例識別碼 — 工單 ID、session ID、使用者 ID；任何讓審查員能調出附屬記錄的識別資訊。
2. 任務摘要 — 一到三句話，以白話說明使用者請求什麼。
3. Agent 當前假說 — agent 認為正確行動是什麼，附信心分數。
4. 模糊性或觸發原因 — 導致 escalation 的具體訊號（缺少哪個欄位、缺少哪個授權、錯過哪個閾值）。
5. 證據 — 與決策相關的工具結果、文件或先前對話的子集。絕不是完整的未過濾歷史記錄。
6. 建議選項 — 審查員可一鍵接受的兩到三個具體行動。
7. 可逆性說明 — 每個建議選項是否可逆，以及影響範圍為何。

缺少第 1–5 項中任何一項，都會為人工審查員製造返工。第 6 和第 7 項，是 30 秒快速分類與 10 分鐘深入調查之間的差距。

來源記錄必須在交接中保存

payload 中的每個事實都應帶有來源標記——哪個工具產生的、來自哪份文件、何時觀察到的。審查員必須能夠區分「Claude 是從 CRM 得知這個資訊」和「Claude 是從支援討論串推斷這個資訊」。escalation 過程中的來源記錄遺失，是人工審查員橡皮圖章通過錯誤 agent 決策的根本原因之一。

Escalation 路徑路由 — 分層 Escalation（Specialist → Manager → System Owner）

並非每次 escalation 都傳給同一個人。CCA-F 期待你設計分層路由，將 escalation 的性質與適當的審查員匹配。

第一層：領域專家（Specialist）

處理常規模糊性的第一線審查員——客服專員、待命工程師、帳務分析師。specialist 具備領域脈絡，能解決大多數案例，也有採取行動的授權（發放退款、核准合併、修正記錄）。當觸發條件是信心低於閾值或缺少欄位的模糊性時，agent 預設應路由至此。

第二層：組長或主管（Manager）

specialist 無法解決的案例的第二線審查員。lead 擁有更廣泛的授權（更高的退款上限、跨團隊協調、政策解讀）。agent 通常不會直接路由至此——而是由 specialist 在一線審查失敗後再往上升。

第三層：系統所有者或工程部門（System Owner）

非案例特定、而是暴露出 agent 本身缺陷的問題的第三線審查員——工具回傳不一致的資料、CLAUDE.md 規則產生矛盾、信心閾值校準錯誤。當觸發條件是在短時間內相同模式重複出現的新型邊緣案例 escalation 時，agent 應自動路由至此——模式本身才是問題，而非任何個別案例。

路由元資料

設計良好的 escalation 系統，為每個 payload 標記層級與具體佇列。路由是觸發原因、風險和負載的函數——一個路由服務根據 agent 附加的元資料，決定哪個人工佇列接收這個案例。

Graceful Degradation — 產生帶有明確不確定性標記的部分輸出

在「自主解決」和「完全 escalation」之間，存在一條中間路徑：產出 agent 有信心的部分輸出、明確標記不確定的部分，並讓下游消費者決定如何繼續。CCA-F 將此稱為 graceful degradation。

Graceful Degradation 是正確選擇的時機

• 任務有多個子組件，只有部分子組件被模糊性阻擋。
• 使用者是能處理部分輸出的技術消費者（pipeline 步驟、API 客戶端）。
• 等待完整解決，會讓下游消費者無事可做。

一個自信地回答了五個子問題中四個、對第五個不確定的研究 agent，應產出四個有信心的答案（附引用），並對第五個回傳 {answer: null, reason: "insufficient_evidence", trigger_escalation: true}——而非捨棄那四個有信心的答案，或阻塞直到第五個解決為止。

不確定性標記的形式

輸出中每個不確定的組件，都應包含：

• 明確的 null 或哨兵值，而非捏造一個合理的答案。
• reason 欄位（insufficient_evidence、ambiguous_reference、out_of_scope、confidence_below_threshold）。
• 可選的 candidates 清單，當 agent 已縮小範圍至少數選項但無法消歧義時使用。
• suggested_action 欄位（request_clarification、escalate_to_specialist、retry_with_context）。

結構化的不確定性，是下游消費者正確分支所需的訊號。「我認為這大概是對的，但我不確定」這樣的文字修飾詞，無法組合進自動化 pipeline。

Graceful Degradation 不是 Escalation 的替代品

Graceful degradation 處理 agent 有信心的輸出；不確定的部分仍然需要 escalation 或 clarification。產出結構化的 null 然後走開，是一種拋棄而非 degradation——標記必須配合一條最終能解決它的路徑。

Escalation 後的重新進入 — 以人工提供的 Clarification 恢復 Agent 執行

一個無法乾淨重新進入的 escalation，會迫使使用者從頭重新開始任務，摧毀 escalation 之前自主工作的所有價值。CCA-F 期待你將重新進入設計為狀態機的一等轉換，而非重新啟動。

乾淨重新進入的四個組件

1. Session 持久化 — escalation 觸發時，agent 的 session 狀態（訊息歷史、工具結果、部分計畫）必須儲存。Agent SDK session API 負責處理此事；忘記持久化是一個正確性 bug。
2. Clarification 繫結 — 人工提供的答案必須繫結進 session，如同它是在上游提供的一樣，而非單純作為新的使用者訊息附加。一個結構化的 resolution payload 將答案對應回觸發暫停的具體欄位。
3. 防護欄重新評估 — 套用 clarification 後，agent 必須重新執行模糊性偵測步驟。若 clarification 解決了原始觸發但引入了新的觸發，agent 必須再次暫停，而非強行繼續。
4. 稽核記錄 — 恢復記錄必須包含誰解決了這個模糊性、何時、以及如何解決。這在高風險行動的合規上是必要的，也為更新 CLAUDE.md 的反饋迴路提供動力。

分叉 vs 恢復

Session 分叉讓你能從 escalation 前的檢查點恢復，同時保留 escalation 記錄——當人工想探索替代解決方案而不想失去原始脈絡時，這很有用。分叉是任務 1.7 的主題，但其重新進入用法存在於任務 5.2 之中。

多 Agent 系統中的模糊性解決 — 哪個 Agent 擁有 Clarification 的責任

在 coordinator-subagent 系統中，模糊性可能在任何層級浮現——在 subagent 的任務內部、在 coordinator 的分解步驟，或在面向使用者的層級。CCA-F 期待你知道哪個 agent 擁有 clarification 的責任。

規則一：Subagent 向 Coordinator Escalate，而非直接向使用者

在執行指派子任務過程中遭遇模糊性的 subagent，應向 coordinator 回傳結構化的 escalation——而非直接傳訊息給終端使用者。coordinator 擁有完整的任務脈絡；subagent 只有自己那一片。面向使用者的溝通是 coordinator 的責任。這個邊界是 subagent 脈絡隔離（社群痛點 pp-03）的直接結果：subagent 無法假設它理解使用者最初的完整要求。

規則二：Coordinator 負責解決、委派或 Escalate

當 coordinator 收到 subagent 的 escalation 時，有三個選項：

1. 本地解決 — coordinator 擁有 subagent 所欠缺的脈絡；coordinator 自行回答子問題（例如，在脈絡中提供安全的預設值），並將 clarification 繫結後重新派遣 subagent。
2. 委派給同儕 — 擁有不同工具或資料的另一個 subagent，可能能夠解決這個模糊性。coordinator 在前往使用者之前，將問題路由給那個同儕。
3. 向使用者或人工審查員 Escalate — 若本地解決和同儕委派都無效，coordinator 以整合後的 payload 向使用者或人工審查員呈現模糊性。

規則三：絕不從多個 Agent 向使用者廣播模糊性問題

各自獨立發現相同模糊性的並行 subagent，不應各自向使用者提問同樣的問題。coordinator 負責聚合與去重複。使用者在短時間內收到三個幾乎相同的 clarification 問題，是多 agent 設計有問題的症狀。

避免過度 Escalation — 設定閾值以防止瑣碎的人工中斷

過度 escalation 的系統，幾乎跟 escalation 不足的系統一樣有問題。過度 escalation 消耗人工注意力、摧毀自動化投資回報，並訓練審查員不看就蓋章。CCA-F 將閾值校準測試為一個刻意的架構選擇。

過度 Escalation 的症狀

• 超過 20% 任務的 escalation 率（確切閾值因情況而異；CCA-F 情境通常會給你一個數字）。
• 在不同案例中，相同模式反覆出現（相同的缺少欄位、相同的授權缺口）。
• 審查員佇列的累積速度超過審查員的處理能力。
• 審查員不看就全部核准（「一鍵全批准」行為）。

減少過度 Escalation 的三個槓桿

1. 降低低風險行動的信心閾值 — 例行地址查詢使用 0.9 的閾值是誤校準的；0.7 通常就足夠了。閾值應針對每個行動個別設定，而非全域設定。
2. 將常見解決方案整理進 CLAUDE.md 規則 — 若相同的模糊性模式反覆 escalation，解決方案應被整理為一條規則。下次遇到時，agent 自主解決。
3. 在 escalation 路徑之前引入 clarification 路徑 — 若模糊性是使用者可解決的（缺少欄位），先詢問。若 clarification 失敗或使用者不在線，再 escalation。

Escalation 不足的症狀 — 另一種失敗模式

• 在低信心決策上執行不可逆行動。
• 面向客戶的輸出高誤判率。
• 下游人工返工，因為 agent 產出的錯誤資料被當作正確資料信任。

目標是校準後的中間值。閾值校準使用資料：從保守值開始，同時測量 escalation 率和漏報率，並調整閾值直到兩者都在容忍範圍內。

記錄模糊性解決方案 — 將解決方案回饋至 CLAUDE.md 或規則

最有價值的 escalation，是那些永遠不需要再發生的 escalation。當人工解決了一個模糊性，解決方案應流回 agent 的組態，使相同模式的下一個實例能自主處理。CCA-F 期待你認識 CLAUDE.md 和規則更新作為反饋迴路的角色。

三階段反饋迴路

1. 捕捉 — 每個已解決的 escalation 記錄原始觸發、人工的決定，以及推理過程。
2. 模式偵測 — 定期檢查（每週或自動化）尋找跨案例重複出現的 escalation 模式——相同的觸發原因、相同的解決方案。
3. 整理成規則 — 重複的模式成為 CLAUDE.md（或路徑特定範圍規則）中的一條規則，指示 agent 在未來遇到相同模式時如何自主處理。

應寫入 CLAUDE.md 的內容

一條整理後的解決規則有四個部分：

• 觸發模式 — 識別這個模糊性的可觀察訊號（例如，「使用者說『最近』卻沒有指定日期」）。
• 預設假設 — agent 應自主套用的解決方案（例如，「將『最近』解讀為前 30 個日曆天」）。
• 安全邊界 — 預設假設不適用、仍需 escalation 的條件（例如，「若使用者處於受規範的報告情境，仍需詢問」）。
• 來源連結 — 指向激發此規則的原始 escalation 案例的指標，用於稽核和未來調整。

規則範疇

整理後的規則應存在於涵蓋其適用範圍的最窄 CLAUDE.md 範疇——特定 agent 的模式用專案層級、特定程式碼庫區域的模式用目錄層級、個人偏好模式用使用者層級。全域 CLAUDE.md 只應包含普遍適用的解決方案；將專案特定解決方案過度全域化，會造成龐大 CLAUDE.md 的反模式（社群痛點 pp-08）。

白話說明

上述機制，一旦對應到考生已熟悉的情境，就會變得直觀。以下三個來自截然不同領域的類比，涵蓋了任務 5.2 的完整面向。

類比一：廟口辦桌的總鋪師助手 — Clarification 時機與規則整理

想像廟口辦桌，東家請了一個剛入行的助手幫忙打點。客人要一道「魚料理」——助手不會隨便端上去，因為是要清蒸虱目魚還是紅燒吳郭魚，結果天差地遠。這個問題是使用者可解答的（缺少指示對象），助手直接問客人：「請問您喜歡清蒸還是紅燒？」——這是聊天頻道的單一問題 clarification。桌上有客人要求「多來幾盤」——這超出助手的授權範圍，因為加菜要另計費，助手無法自行決定，只能 escalate 給總鋪師（tier-1 specialist），並帶上完整的客人資訊、當前用餐狀況和金額試算。辦完幾場後，總鋪師發現「魚料理」幾乎每桌都問同一個問題，於是在大掛板（CLAUDE.md）上寫：「辦桌魚料理若未指定，預設清蒸，海產店場合仍需再確認。」助手從此自主解決這個模糊性。大掛板就是 CLAUDE.md，助手就是 Claude agent，總鋪師就是 tier-1 specialist，廟口就是生產系統。任務 5.2 的每個設計決策，在這裡都有直接對應。

類比二：航管塔台 — 分層 Escalation 與授權

機場航管塔台運行三個層級的管制員。地面管制員負責滑行道調度。塔台管制員負責起降。進場管制員負責機場上方的空域。每個層級有各自明確的授權範圍；超出授權時，逐層向上 escalation。飛行員要求異常滑行路線，找地面管制員。若地面無法解決（路線穿越現役跑道），地面 escalate 給塔台。若塔台無法解決（路線與進場航班糾纏），塔台 escalate 給進場管制員。飛行員絕不會直接呼叫進場管制員——分層架構保持授權邊界與無線電頻道的秩序。當前所未有的情況發生——例如新型機種有特殊的滑行特性——解決方案成為機場記錄的新程序，未來的案例在地面管制員層級自主處理。塔台架構就是 coordinator-subagent escalation 模式：低層級永遠向上 escalation，絕不橫向、絕不跳層；解決方案整理成程序，讓低層級的授權範圍隨時間擴大。

類比三：急診室分診 — Graceful Degradation 與閾值

急診室的分診護理師看診時同時做三個平行決策：哪些是我確定的結論、哪些是不確定的、哪些超出我的授權。護理師可以確信地記錄生命徵象（有信心的輸出）。護理師不確定症狀是心臟問題還是肌肉骨骼問題（不確定的輸出——標記，而非捏造）。護理師沒有開嗎啡的授權（超出授權——escalate 給醫師）。護理師把一份結構化的病歷交給醫師：病患 ID、生命徵象、觀察結果、疑似診斷類別附信心分數，以及建議的下一步行動。醫師看病歷做出授權決策。病歷就是 escalation payload；生命徵象就是 graceful degradation 的有信心輸出；疑似診斷類別就是 candidates 清單；病歷的結構化形式，正是醫師能在三十秒而非三十分鐘內採取行動的原因。這就是任務 5.2 的完整模式——產出你能產出的、標記你不能的、帶著結構 escalation、保存來源記錄。

考試當天選用哪個類比

• 關於 clarification 時機與規則整理的題目 → 辦桌總鋪師助手類比。
• 關於分層路由與 coordinator-subagent escalation 的題目 → 航管塔台類比。
• 關於 graceful degradation 與 escalation payload 形式的題目 → 急診室分診類比。

常見考試陷阱

社群通過報告指出，任務 5.2 周圍有五個反覆出現的陷阱模式，以合理的干擾選項形式出現。這五個都值得在考試前熟記。

陷阱一：把 Escalation 當作任務失敗

Escalation 是成功的架構結果，而非失敗。一個將低信心退款 escalate 給 specialist 的 agent，做了正確的事。干擾答案將 escalation 框架為「agent 未能完成任務」，並建議改為降低信心閾值或強化提示讓 agent 自主繼續。這兩種建議對高風險行動而言都是錯誤的。Escalation 不是 bug；它是功能本身。

陷阱二：高風險任務中以假設取代 clarification

對高風險或不可逆行動而言，clarification 優先於假設——毫無例外。干擾答案主張「帶著明確假設繼續執行以避免拖慢使用者」，即便是退款、帳戶刪除或發布至生產環境的行動也是如此。這些答案是錯誤的。速度優化，永遠不是在不可逆操作上略過 clarification 的有效理由。

陷阱三：將完整對話倒進 Escalation Payload

Escalation payload 必須是帶有明確來源記錄的結構化摘要，而非原始對話文字記錄。提議「將完整的思考鏈與工具歷史轉給審查員」的答案是錯誤的，因為它掩埋了決策相關資訊，並摧毀審查吞吐量。

陷阱四：Subagent 直接向使用者 Escalate

在 coordinator-subagent 設計中，subagent 向 coordinator 上行 escalation，coordinator 向使用者或人工審查員上行 escalation。描述 subagent 直接向終端使用者詢問 clarification 的答案是錯誤的。這個邊界是架構性的，而非風格性的。

陷阱五：一律 Escalation 作為安全預設

過度 escalation 是有別於 escalation 不足的獨立失敗模式。提議「信心未達滿分時一律 escalation」的答案，摧毀自動化價值，並訓練審查員進入一鍵全批准行為。正確立場是依風險比例設定閾值——高風險行動在不確定時設高閾值並強制 escalation；低風險行動在不確定時設低閾值並採用 graceful degradation。

練習錨點

任務 5.2 概念最集中出現於客戶服務解決方案 agent 情境。Multi-agent-research-system 則演練 coordinator-subagent escalation 邊界。將以下兩個情境視為任務 5.2 題目的架構骨幹。

客戶服務解決方案 Agent 情境

在這個情境中，一個客服 agent 處理涵蓋 FAQ 查詢、訂單狀態查詢、退款請求和帳戶變更的進入工單。任務 5.2 題目鎖定：在路由前對工單分類的模糊性偵測步驟；clarification 形式（聊天頻道用單一問題，電子郵件輸入用批次）；高風險行動的決策策略（退款核准需要明確 clarification，而非假設）；escalation payload 設計（結構化工單摘要加信心分數加建議行動，而非原始聊天記錄）；客服專員、組長與工程部門之間的分層路由；以及 specialist 提供 clarification 後 agent 恢復工單的重新進入流程。預期會有題目將「在 system prompt 中加入更強的指令告訴 agent 要詢問」與「帶有具型別 schema 的結構化 request_clarification 工具」相比——結構化工具幾乎永遠是正確答案。

Multi-Agent Research System 情境

在這個情境中，一個 coordinator 將研究 subagent 派遣至並行的子主題，每個 subagent 可能在其任務片段中遭遇模糊性。任務 5.2 題目鎖定：subagent 向 coordinator（而非直接向使用者）escalation 的規則；coordinator 在本地解決、同儕委派與使用者 escalation 之間的三向決策；部分子主題有信心回答而部分需要 clarification 時的 graceful degradation；以及將多個 subagent 模糊性整合為單一聚合的面向使用者 clarification，而非廣播三個獨立問題。

FAQ — Escalation 與模糊性前六大問題

Claude agent 在什麼情況下應詢問 clarification，而非帶著假設繼續？

只要行動是高風險或不可逆的，就應詢問 clarification——退款、帳戶變更、發布內容、合併至生產環境分支、刷卡扣款、發送面向客戶的通訊。只有當行動是低風險且容易回復時，才帶著明確假設繼續——產生草稿、執行唯讀查詢、回傳人工會審查的盡力而為搜尋結果。風險-可逆性矩陣是決策規則。在 CCA-F 上，對高風險行動而言，「執行前詢問」幾乎永遠是正確答案；為了避免「拖慢使用者」而選「帶著信心聲明繼續」的考生，這個模式屢屢失分。

Claude agent 中 clarification 和 escalation 有什麼差異？

Clarification 是 agent 向使用者提問以解決缺少或模糊輸入的過程——預設使用者能夠回答，任務在他們回答後立即恢復。Escalation 是將控制權轉移給人工審查員（或更具權威的 agent）的過程，觸發條件是使用者無法解決的事項——缺少授權、在依風險比例設定的行動上信心低於閾值、或需要人工判斷的新型邊緣案例。Clarification 讓使用者保持在迴圈中；escalation 引入第三方。設計良好的 agent 同時具備兩條路徑，並各用於適合的情境。

如何設計 escalation payload 讓人工審查員能快速採取行動？

至少包含七個欄位：案例識別碼、以白話呈現的任務摘要、agent 的當前假說附信心分數、具體的模糊性或觸發原因、帶來源標記的過濾後證據（不是完整對話）、審查員可一鍵核准的兩到三個建議行動，以及每個建議行動的可逆性說明。審查員應能在約三十秒內完成案例分類。最糟的反模式——CCA-F 明確懲罰的——是將原始 agent 對話歷史倒進 payload，要求審查員自行閱讀。

如何防止 agent 過度 escalation 而耗盡人工審查員的精力？

三個槓桿：(1) 針對每個行動個別校準信心閾值，而非全域設定——例行查詢應使用較低閾值，不可逆寫入應使用較高閾值；(2) 在 escalation 路徑之前引入 clarification 路徑，使使用者可解決的模糊性永遠不會到達人工審查員；(3) 將重複的解決模式整理進 CLAUDE.md 規則，使相同模糊性不會 escalation 兩次。過度 escalation 是有別於 escalation 不足的獨立失敗模式，CCA-F 情境經常將「不確定時一律 escalation」作為合理但錯誤的答案，因為它會訓練審查員進入一鍵全批准行為。

在 coordinator-subagent 系統中，哪個 agent 應向使用者詢問 clarification？

Coordinator，而非 subagent。subagent 透過結構化 escalation 記錄向上 escalation 給 coordinator；coordinator 有三個選項——利用 subagent 所欠缺的脈絡在本地解決、委派給可能能夠解決模糊性的同儕 subagent、或向上 escalation 給使用者或人工審查員。subagent 直接與使用者溝通在設計良好的多 agent 系統中是錯誤的，因為 subagent 脈絡隔離（社群痛點 pp-03）意味著 subagent 沒有完整的任務脈絡來提出一個連貫的問題。coordinator 也在多個並行 subagent 發現相同模糊性時負責去重複。

人工解決 escalation 後，如何乾淨地恢復 agent 執行？

需要四個組件：escalation 觸發時持久化 agent 的 session 狀態（訊息歷史、工具結果、部分計畫）；將人工的解決方案繫結為對應到觸發暫停的具體欄位的結構化 payload（而非作為原始附加的使用者訊息）；套用 clarification 後重新執行模糊性偵測步驟，使任何新觸發在 agent 繼續前都被捕捉到；以及記錄誰解決了模糊性、何時、以及如何解決的稽核記錄。Session 分叉讓你能從 escalation 前的檢查點分支，當人工想探索替代解決方案而不捨棄原始脈絡時很有用。在 CCA-F 上，提議「將 clarification 前置到原始提示後重新啟動任務」或「將答案作為新使用者訊息附加」的答案，因為丟失狀態而是錯誤的。

延伸閱讀

• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Subagents in the Agent SDK — error propagation and session re-entry: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• CLAUDE.md configuration — codifying resolutions as rules: https://docs.anthropic.com/en/docs/claude-code/claude-md
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

Related ExamHub topics: Conversation Context Across Long Interactions, Human Review Workflows and Confidence Calibration, Multi-Step Workflows Enforcement and Handoff, Error Propagation in Multi-Agent Systems.