長對話中的 Context 管理

長對話的 Conversation Context 管理是 Claude Certified Architect — Foundations（CCA-F）考試 Domain 5.1 的核心主題。任務說明 5.1——「管理 conversation context 以在長對話中保留關鍵資訊」——錨定了 Domain 5 中考試比重最高的情境：客服解決方案 Agent 必須應對多問題 session，而交易性事實（訂單編號、退款金額、承諾的出貨日期、客戶明確表達的期望）在對話延伸過程中不能發生漂移、模糊或消失。你在長對話的 Conversation Context 管理上做出的每一個架構決策——如何 replay conversation history、case facts block 放在哪裡、tool output 要修剪多積極、要選擇 progressive summarization 還是逐字封存——直接決定了 agent 能否正確結案，還是在三輪後自信地給出一個過期的退款政策。

這份學習筆記涵蓋 CCA-F 考生需要掌握的長對話 Conversation Context 管理完整面向：context window 作為有限資源的運作機制、progressive summarization 模式及其風險、lost-in-the-middle effect、針對交易可信度的 case facts block 架構、在資料累積前就進行 tool output trimming、section headers 與位置顯著性、conversation history replay 策略，以及將 720 分低空及格與 985 分高分區隔開來的考試陷阱。本主題不涵蓋 fine-tuning、視覺、串流、速率限制、token 計算演算法和 prompt caching 實作細節——但 Domain 5 的所有其他主題都會回頭參照這裡的基礎。

Context Window 作為有限資源 — 為何長對話 Conversation Context 管理是架構課題

Claude 的 context window 是工作記憶，同時容納系統提示、tool definitions、conversation history、tool results 和使用者當輪訊息——全部一次性讀入。Claude 4 系列的 context window 很大，但「大」不等於「無限」，考試正是測試你是否將長對話的 Conversation Context 管理視為架構課題，而非事後補丁。window 內的每個 token 都在與其他所有 token 競爭模型的注意力。一次包含 40 個欄位的訂單查詢可能把三輪之前客戶的實際投訴擠到邊緣；一個冗長的系統提示可能把解決工單所需的退款政策擠出去。

考試的工作假設是：你不能單純靠「把 window 設更大」來解決問題——你必須架構資訊進入、留存和離開 context window 的方式。三股力量塑造這個架構：

1. 累積（Accumulation） — tool results、assistant 回覆和使用者輪次隨 session 長度線性堆疊。
2. 位置顯著性（Positional salience） — window 中的每個 token 並非同等被記住；開頭和結尾優先於中間。
3. 語義漂移（Semantic drift） — 隨著簿記 token 與訊號 token 的比例上升，Claude 對實際使用者意圖的錨定會逐漸侵蝕。

為何 Context Window 主導 Domain 5.1

CCA-F 考試中每個客服解決方案 Agent 的架構題，最終都歸結為 context window 的取捨：要對第 1–8 輪做 summarize 以騰出空間給第 9–15 輪嗎？要重新查詢訂單，還是信任兩輪前的摘要？要在 Claude 看到之前就把 40 個欄位的訂單酬載縮成 5 個欄位嗎？這些不是實作問題——它們是架構問題，考試獎勵在 window 填滿前就思考這些問題的考生，而非填滿後才補救的考生。

Progressive Summarization — 壓縮前期輪次以保留近期細節

Progressive summarization 是將對話前期較冗長的輪次，隨著對話延伸以機器生成的較短摘要取代的模式。一個 30 輪的客服 session，在第 31 輪呈現給 Claude 時，可能是：一段摘要第 1–15 輪的段落、三輪逐字中間內容（第 16–18 輪），以及完整逐字的最後 12 輪。Progressive summarization 以忠實度為代價換取 context window 空間——這正是考試陷阱的所在。

Progressive Summarization 的運作機制

Progressive summarization 通常在應用層實作（你的程式碼在發出下一次請求前先彙整舊輪次），或透過 session 層級指令（例如 Claude Code 的 /compact）來執行。無論哪種方式，動作都一樣：取 N 輪，產生一段壓縮描述，捨棄或封存原文。

Progressive summarization 適合用於：

• 較早的檔案讀取已經為目前推理提供依據的長期探索式程式撰寫 session。
• 較早的網路搜尋已被整合為穩定認識的研究對話。
• 前面問題的精確措辭已不重要的教學和問答 session。

Progressive summarization 有積極危害的場合：

• 必須逐字留存數字承諾、金額、日期和狀態碼的客服 session。
• 客戶明確表達期望的精確措辭是法律憑證的合規對話。
• 訂單 ID、預訂編號和 SLA 承諾作為後續行動錨點的交易型 agent。

Progressive Summarization 風險 — 數字與語義漂移

長對話 Conversation Context 管理中頻率最高的失敗模式，是 progressive summarization 悄悄將交易性事實變成模糊的散文。「我被承諾在 4 月 26 日之前對訂單 #4812 退還 15% 款項」的客戶，在 summarization 之後變成「客戶預期近期對其最近的訂單退款」。三個數字錨點——百分比、訂單編號、日期——全部消失。agent 的下一輪將自信地給出一個錯誤的數字，而這個錯誤數字將傳遞到真實的客戶結果中。

考試的相關教訓是：progressive summarization 在設計上就是有損的，你必須在 session 開始前就決定哪些事實無法承受損失，並為那些事實選擇不同的架構路徑。

Lost-in-the-Middle Effect — 長 Context 中的位置顯著性

Lost-in-the-middle effect 是有充分記錄的現象：大型語言模型能可靠地處理放在長 context window 開頭或結尾的資訊，但對放在中間的資訊可能忽略、低估或無法檢索。這個效應不是 Claude 特有的 bug——它是 transformer attention 在長輸入序列上分配顯著性的特性，且隨輸入長度而擴大。把客戶 SLA 等級埋在一個 20,000 token 對話歷史的中間，統計上比把它放在頂部或底部的 agent 更容易忘記那個 SLA 等級。

效應的衡量與預測

實務上，設計客服解決方案 Agent 的考生應假設：任何被埋在前 2–3k token 之後、且距離長提示結尾超過 1–2k token 的事實，都有相當的機率被 Claude 低估。考試不測試精確的 token 門檻——它測試你是否以效應存在的前提來設計。把所有輔助材料放在中間一大坨 tool results 的設計、仰賴 Claude 自行找到相關事實的設計，會失敗；把關鍵發現摘要放在頂部、把詳細 tool output 放在後面、並加上明確 section headers 的設計，會通過。

緩解劇本

四個具體動作緩解 lost-in-the-middle effect：

1. 頂部優先放置關鍵發現。 在任何彙整輸入的開頭，於原始細節之前放置最重要結論的簡短摘要。
2. 底部重複關鍵事實。 在提示最末、緊接 Claude 回應槽之前，重複驅動下一輪決策的一到兩個事實。
3. 使用明確的 section headers。 用 ## Customer Profile、## Order History、## Open Promises 等標題來組織長內容，讓 Claude 能導覽輸入，而非將它視為無差別的大塊文字。
4. 將交易性事實提升到 case facts block。 將少量不可妥協的事實抽取到專用的 block，在每次提示的固定顯著位置逐字包含——免受 summarization 影響，也免於被埋入中間。

Case Facts Block — 跨輪次的持久交易可信度

Case facts block 是在客服解決方案 Agent 情境中，針對 progressive summarization 風險的架構答案。它是一個結構化、由機器維護、逐字渲染的交易性事實 block——金額、日期、訂單編號、狀態、客戶明確表達的期望——存在於摘要 conversation history 之外，並在每次後續 API 請求的固定顯著位置全部包含進去。Case facts block 是 Domain 5.1 中被考頻率最高的單一架構模式。

Case Facts Block 的結構

一個設計良好的 case facts block 大致如下：

<case_facts>
customer_id: C-9281
sla_tier: Platinum (4-hour response)
open_issue_ids: T-48122, T-48140
transactions:
  - order_id: "#4812"
    amount_usd: 289.40
    promised_refund_pct: 15
    promised_refund_by: "2026-04-26"
    current_status: "awaiting approval"
customer_stated_expectations:
  - "15% refund on order #4812 by April 26"
  - "No repeat of the delivery delay from order #4199"
</case_facts>

三個屬性至關重要：

1. 由機器維護。 應用程式程式碼（而非模型）是 block 的權威來源。Tool results 更新欄位；模型不以散文方式編輯 block。
2. 逐字 replay。 Block 在 session 的每次後續請求中以位元組一致的方式包含，而非從摘要重新生成。
3. 顯著位置。 Block 位於使用者訊息堆疊的頂部（或底部），不被埋入 tool results 的中間。

哪些內容屬於 Block，哪些留在摘要歷史中

Case facts block 不是垃圾桶。只包含同時符合以下三個條件的事實：

• 交易性 — 特定的數字、日期、ID、金額或狀態。
• 持久性 — 與超過當前輪次相關。
• 不可妥協性 — 遺失或失真會造成真實世界的客戶損害。

對話情感、建立關係的交流，以及探索性的澄清不屬於 case facts block；它們屬於（可能已摘要的）conversation history。過度填充 block 會適得其反，在 block 內部重新引入 lost-in-the-middle effect。

Tool Output Trimming — 在累積前阻止 Token 膨脹

Tool results 在 context 中累積，消耗的 token 量與其相關性不成比例。一次訂單查詢的 tool call 可能回傳 40 多個欄位——客戶地址、帳單地址、物流業者代碼、重量、尺寸、品項稅率、幣別代碼、匯率時間戳——而解決方案 agent 推理時實際只需要其中五個欄位（訂單 ID、狀態、總額、承諾到貨日期、目前追蹤事件）。如果 15 輪 session 中的每次訂單查詢都把 40 個欄位的 JSON 傾倒進 context window，agent 會在真正的問題浮現之前就溺死在簿記資料裡。

為何 Trimming 必須在累積前進行

考試會陷害試圖在冗長 tool output 進入 context 之後才清理的考生——例如在第 9 輪把前八次 tool results 摘要成一則說明。這個動作對第 9 輪之後略有幫助，但對那八個膨脹結果在第 2–8 輪期間已經置換掉其他訊號這件事毫無幫助。正確的架構在 tool 邊界修剪，讓膨脹從一開始就不進入 context。

具體來說：你的 tool handler 程式碼從訂單查詢服務接收 40 個欄位，抽取 5 個相關欄位，然後回傳只包含那 5 個欄位的 tool_result。這是一個刻意的塑形步驟，獨立於底層服務回傳的內容。

欄位選擇的啟發原則

• 問下一個推理步驟需要什麼。 如果 agent 的下一個決策是「我們還能兌現承諾的交貨嗎？」，相關欄位是狀態、目前預計抵達時間和承諾到貨日期。其他一切都是雜訊。
• 保留 ID，丟棄散文。 ID 和狀態成本低且常在後續被引用；自由形式的服務描述成本高且幾乎不再被引用。
• 在精度不具語義關鍵性的地方四捨五入或截斷。 12 位小數的座標增加 token 卻不增加訊號。
• 折疊結構性重複。 如果十個品項有相同的物流狀態，摘要為「10 件商品，全部於 2026-04-22 出貨」，而不是把欄位重複十次。

Conversation History Replay — 每次請求傳入完整歷史

Messages API 是無狀態的：每次請求都必須包含完整的先前 conversation history，Claude 才能跨輪次維持一致性。這是一個特性而非限制，因為它讓你的應用程式——而非供應商——掌控什麼被記住、被摘要或被遺忘。但這也意味著粗心的 replay 是最快速填滿 context window 的方式。

哪些逐字 Replay，哪些壓縮 Replay

客服解決方案 Agent 情境的標準劃分：

• 逐字 replay： case facts block、最近 3–5 輪使用者/assistant 輪次、目前啟用的 tool definitions。
• 壓縮 replay： 較早的使用者/assistant 輪次，壓縮成 progressive summaries。
• 不 replay： 資訊已被提煉進 case facts block 或 assistant 摘要的過時 tool results；已解決的錯誤輪次；已被取代計畫遺棄的推理草稿。

Replay 順序很重要

在該輪的使用者訊息序列中，將 case facts block 置於頂部，接著是壓縮的歷史摘要，然後是逐字的近期輪次，最後是當前使用者訊息。這個排列讓最重要的交易性事實擁有最高顯著性位置，並讓近期逐字輪次緊鄰回應槽——context window 兩端都承載訊號，中間承載（更能容忍的）摘要歷史。

Section Headers — 讓長輸入可導覽

當彙整輸入變得冗長——例如一個 tool result 將三個同時查詢打包成一個酬載——無結構的串接迫使 Claude 掃描一大塊無差別的文字。明確的 section headers（## Customer Profile、## Active Case Facts、## Order 4812 Detail、## Recent Contact History）把大塊文字變成可導覽的文件，大幅降低 lost-in-the-middle 的代價。

Header 設計原則

• 為內容命名，而非為結構命名。 ## Order 4812 Detail 優於 ## Section 3。
• 跨輪次保持 header 穩定。 每輪使用相同的 header 文字，讓 Claude 建立對資訊位置的一致心智模型。
• 按語義單元分組，而非按 tool call 分組。 關於同一訂單的多個 tool results 應合併在一個 ## Order 4812 Detail header 下，而不是分散在 ## Tool Call 1 Result / ## Tool Call 2 Result 下。
• 前置目錄。 對於非常長的輸入，頂部的兩行摘要列出後續章節，幫助 Claude 定位相關材料。

Section Headers 結合關鍵發現摘要

對 lost-in-the-middle effect 最強力的緩解，是頂部放置關鍵發現摘要加上下方細節加 section headers 的組合。摘要告訴 Claude 該得出什麼結論；headers 告訴 Claude 到哪裡驗證。兩者都不如合用有效。

白話說明

抽象的架構模式只有在與具體事物連結時才會留下印象。以下三個類比——刻意取材自截然不同的領域——錨定了長對話 Conversation Context 管理的完整面貌。

類比一：辦桌總鋪師 — 師傅的小紙條

想像一位忙碌的辦桌總鋪師正在操持一場豐盛的流水席。師傅腦袋裡的工作空間很大——但辦十二道菜的過程中，這個空間會變得嘈雜。爐火上的滷汁、上菜的時序、火候的掌控、臨時的加菜、從外場傳回的過敏提醒——師傅無法同時把所有事情維持在完全清晰的狀態。所以師傅在案板上方夾了一張小紙條：14 桌有人對麩質過敏，22 桌的白斬雞要全熟，6 桌的 VIP 被承諾了一份贈送的甜點。那張紙條就是 case facts block。師傅可能忘了 14 桌的閒聊、模糊了誰先要蒸蛋、把過去一小時摘要成「忙碌、沒有抱怨」——但 14 桌的過敏提醒逐字留在紙條上，因為紙條不受師傅內心 summarization 的影響。

延伸類比：幫廚把整份早上進貨的清單遞給師傅——四十個品項、數量、供應商代碼、有效期。如果師傅把整份清單夾在案板上，它就會蓋住小紙條。所以幫廚在清單到達師傅案前前就修剪 tool output：清單被縮減為「鮭魚品質良好，布拉塔起司短少兩箱——已改成特餐，今晚菜單不受影響」。這份修剪後的說明才是真正放到案板上的東西。師傅從未讀過完整清單；完整清單從未置換掉小紙條。

最後：師傅在每道菜上桌前，都會先瞄一眼紙條，上菜前也再瞄一眼。這就是位置顯著性——注意力的頂端和底端，而非中間。

類比二：刑警辦案 — 偵查板上的釘針

一名刑警在辦公桌後方掛著一塊偵查板。板上釘著：案主姓名、具體的查案任務、當事人提到的任何截止期限，以及刑警已對案主做出的承諾（例如：「我說了下午三點前要去調閱監視器」）。刑警身後，一疊越堆越高的筆記本——整個查案過程中取得的所有資料——就是 conversation history。

資深刑警學會把已釐清的筆記本收起來，換成索引卡摘要——「五冊建築相關的筆錄，都涉及日據時代，沒有戰後資料」——讓桌面保持可用狀態。這就是 progressive summarization。對建築類的筆錄有效，因為具體頁碼在該時期釐清後就不再重要。對案主說的截止期限或已做出的承諾無效——那些留在偵查板上，用當事人自己的話，因為模糊它們會違背刑警對案主的隱性承諾。

兩小時後回來的案主，由一個先看偵查板（注意力頂端）、再翻索引卡摘要（壓縮的中間），再直接詢問最近半小時發生了什麼（逐字近期 context）的刑警接待。如果案主的截止期限被埋在一疊索引卡的中間，它就會消失。這就是 lost-in-the-middle effect。

類比三：高考開卷考 — 考生的備忘單

想像一名考生正在應考一場長達八小時、共四十道題目的開卷考試。考生可以翻閱完整的參考書（conversation history），但無法在每道題上都從頭讀起。所以他們在桌上準備了一張備忘單：六個在一半題目都出現的公式、三個命名定理、兩個關鍵常數。每次換題，他們都先看備忘單。備忘單就是 case facts block。

參考書本身有章節標題、小節標題和索引——section headers，讓考生不必從頭掃描就能跳到正確頁面。考生發現，把最常用的公式放在備忘單上、把書用章節分隔整理，遠比「我需要時再去找」的開卷策略有效。後者浪費了他們有限的注意力。

而考生不會把整本書的每一頁抄到桌上——大部分內容留在書裡。只有必須立即可取得的事實才上備忘單。這就是 tool output trimming：相關欄位被抽出來釘好；其餘的留在原始來源，不進入工作記憶。

考試當天選用哪個類比

• Progressive summarization 風險、case facts block、交易可信度 → 辦桌總鋪師的小紙條。
• Lost-in-the-middle effect、section headers、位置顯著性 → 刑警偵查板和索引卡。
• Tool output trimming、context 預算、選擇性回憶 → 開卷考備忘單。

結構化 Context 日誌 vs 散文摘要 — 機器可讀狀態

長對話 Conversation Context 管理中一個微妙但有考試依據的選擇，是跨輪次持久化的狀態應存成機器可讀日誌（YAML、JSON、鍵值 block）還是散文摘要。答案取決於情境：

• 機器可讀（case facts block、狀態日誌、未結承諾清單） — 用於任何應用程式會以程式方式更新或查詢的內容。機器可讀狀態更易於增量更新、驗證，以及一致渲染。
• 散文摘要（先前 conversation 歷史的敘事壓縮） — 用於對話色彩、建立關係的線索，以及真正具有敘事性的探索推理。散文有損但能以 YAML 無法做到的方式保留互動的感覺。

客服解決方案 Agent 受益於混合方式：case facts、承諾和交易用機器可讀 block；conversation history 的前期輪次用散文摘要。考試干擾選項常建議「把所有內容都摘要成散文」或「把所有內容都記成 JSON」——兩個極端都是錯的。正確架構針對每種內容類型選擇正確的表示方式。

何時重置 Context — 識別 Session 已降級的訊號

即使有 progressive summarization、case facts block 和 tool output trimming，很長的 session 最終也會降級。長對話 Conversation Context 管理包括知道何時正確的動作不是更多修補，而是刻意重置。

表示 context 重置是正確動作的訊號：

• Agent 開始與 case facts block 中逐字記載的事實產生矛盾。
• Tool calls 開始以相同參數重複先前的呼叫（遺失狀態的訊號）。
• Agent 提及從未發生過的事件或承諾（幻覺增加）。
• 每輪延遲的增加與總 context 大小相關，而非與任務複雜度相關。

這個情境的重置通常意味著：將 case facts block 和緊湊的散文摘要持久化到應用程式儲存，開啟新的 conversation session，在第 1 輪頂部重新注入持久化的狀態，然後繼續。做對了，客戶不會察覺到邊界。做錯了（例如重新初始化時沒有 replay case facts block），agent 就會「忘記」客戶明確表達的期望，session 就此崩潰。

常見考試陷阱 — CCA-F 情境題實際在測什麼

CCA-F Domain 5.1 反覆利用五種與長對話 Conversation Context 管理相關的陷阱模式。

陷阱一：「Progressive Summarization 是無損的」

干擾措辭：「使用 progressive summarization 在降低 token 用量的同時保留所有交易性事實。」Progressive summarization 在設計上就是有損的——它壓縮。任何將它框架為無損、或將它作為交易性內容的 case facts block 替代品的答案，都是錯的。

陷阱二：「更大的 Context Window 解決問題」

干擾措辭：「遷移到 context window 更大的模型，讓 lost-in-the-middle 不再是問題。」更大的 window 無法修復 lost-in-the-middle effect——它們常常讓問題更嚴重，因為中間部分更多了。正確答案是架構性的（case facts block、section headers、頂部放關鍵發現），而非擴充容量。

陷阱三：「在 Tool Output 累積後才修剪」

干擾措辭：「每隔五輪，將所有先前的 tool results 摘要成一則說明以節省 token。」事後摘要對之後略有幫助，但對那些膨脹結果在先前輪次期間已經造成的置換毫無幫助。考試正確的動作是在 tool 邊界修剪，在 result 進入 context window 之前。

陷阱四：「Case Facts Block 由 Claude 更新」

干擾措辭：「指示 Claude 在回覆中維護並更新 case facts block。」Case facts block 由你的應用程式程式碼以機器方式維護，而非由模型維護。讓模型改寫 block，正好重新引入了 block 存在要防止的 progressive summarization 漂移。

陷阱五：「Lost-in-the-Middle 靠更強的提示詞修復」

干擾措辭：「在系統提示加上『請仔細閱讀，不要遺漏中間章節』。」提示提醒無法有意義地抵消位置顯著性偏差。修復是結構性的：把關鍵資訊放在開頭或結尾，並在中間加上 section headers。

練習錨點 — 客服解決方案 Agent 任務 5.1 情境題模板

CCA-F 與長對話 Conversation Context 管理相關的練習題，集中在六種反覆出現的形狀。詳細的題目和解析存放在 ExamHub CCA-F 題庫；以下模板訓練導覽這些題目所需的模式辨識能力。

模板 A：漂移的退款金額

一個客服解決方案 Agent session 已經執行了 22 輪。在第 12 輪，客戶說「我被承諾在 4 月 26 日之前對訂單 #4812 退還 15% 款項。」在第 20 輪，agent 摘要了先前的對話，提及「訂單 4812 有一筆退款承諾。」在第 22 輪，agent 根據摘要提出 10% 退款。最可能的根本原因和正確的架構修正是什麼？

• 根本原因： progressive summarization 把 15% 的數字和 4 月 26 日的日期壓縮成了模糊的散文。
• 正確修正： 維護一個 case facts block，在第 12 輪客戶表達期望時填入，在每次後續提示中逐字包含，並明確豁免於 summarization。

模板 B：被埋葬的 SLA 等級

Agent 有一個 24,000 token 的 conversation history。客戶的 Platinum SLA 等級在早期的一個 tool result 中被提及，此後沒有再重複。Agent 在第 18 輪將工單路由為標準優先級。最可能的根本原因和正確的架構修正是什麼？

• 根本原因： lost-in-the-middle effect——SLA 等級被埋在 context window 的中間。
• 正確修正： 將 SLA 等級提升到 case facts block（置於頂部），並在詳細輸入中加上 ## SLA section header，讓這個事實存在於顯著位置。

模板 C：膨脹的訂單查詢

Agent 的訂單查詢工具每個品項回傳一個含 40 個欄位的 JSON 酬載。經過 8 次 session 中的 tool calls 後，conversation history 被簿記資料主導。Agent 開始遺漏客戶的實際投訴。正確的架構修正是什麼？

• 正確修正： 在 result 進入 context window 之前，在 tool result 塑形層將 tool output 修剪為相關欄位（訂單 ID、狀態、總額、承諾到貨日期、目前追蹤事件）。不要依賴下游 summarization 來清理。

模板 D：「自行更新記憶」的干擾選項

提案架構指示 Claude 在系統提示中維護一個「案件記錄」區段，並在對話進展時自行更新。為何這個架構有瑕疵？

• 原因： 由模型維護的狀態，受到 case facts block 存在要防止的相同 progressive summarization 漂移的影響。狀態必須由應用程式程式碼以機器方式維護，由 tool results 驅動結構化更新。提示 Claude 自行維護記憶，是考試反覆標記的干擾選項。

模板 E：關鍵發現被埋在中間

一個研究合成 agent 將三個 tool results 彙整成一個 6,000 token 的組合輸入。最重要的發現在中間 tool result 的第二段。下一輪，agent 沒有引用這個發現。正確的架構修正是什麼？

• 正確修正： 在彙整輸入的頂部放置關鍵發現摘要（以要點列出三個最重要的結論），用明確的 section headers 組織詳細內容（## Finding A、## Finding B、## Finding C），並可選擇在提示結尾重複單一最具決策驅動力的事實。

模板 F：重置觸發器

一個 session 已執行了 45 輪，agent 現在開始與 case facts block 中仍逐字記載的事實產生矛盾。正確的下一步行動是什麼？

• 正確行動： 識別 context 已在當前 session 中降級超過可恢復程度的訊號。持久化 case facts block 和緊湊的散文摘要，開啟新的 conversation session，在第 1 輪重新注入持久化狀態，然後繼續。不要對當前 session 加更多 summarization——session 已經飽和了。

長對話 Conversation Context 管理 — 常見問題（FAQ）

Lost-in-the-middle effect 是什麼？在 CCA-F 上如何緩解它？

Lost-in-the-middle effect 是長 context 語言模型的位置顯著性偏差：長輸入開頭和結尾的資訊被可靠地回憶，而中間的資訊可能在 Claude 的推理中被低估或忽略。長對話 Conversation Context 管理中的緩解是結構性的，而非基於提示：在彙整輸入的頂部放置關鍵發現，在結尾重複具決策驅動力的事實，用明確的 section headers 組織長內容讓 Claude 能導覽，並將不可妥協的事實提升到在每輪固定顯著位置渲染的 case facts block。提示提醒「仔細閱讀中間部分」是干擾選項——修復在於事實所在的位置，而非你如何要求 Claude 去找它。

Case facts block 是什麼？它為何對客服解決方案 Agent 重要？

Case facts block 是提示中結構化、由機器維護、逐字渲染的區域，保存 session 的交易性事實（訂單編號、金額、百分比、日期、狀態、客戶明確表達的期望、SLA 等級）。你的應用程式程式碼——而非模型——是 block 的權威；tool results 更新欄位，block 在每次後續 API 請求的固定顯著位置以位元組一致的方式包含。它很重要，因為客服解決方案 Agent conversation 的 progressive summarization 會悄悄把「4 月 26 日前退還訂單 #4812 的 15%」壓縮成「很快會有一筆退款承諾」——而這種遺失將傳遞到錯誤的客戶結果中。Case facts block 是讓 agent 對 summarization 漂移和 lost-in-the-middle effect 都具備抗性的架構模式。

Progressive summarization 的最大風險是什麼？

Progressive summarization 在設計上是有損的：它把早期輪次壓縮成較短的摘要，以 context window 空間換取忠實度。最大的風險是：(1) 數字漂移——百分比、金額和日期被概化成模糊的散文；(2) 識別符遺失——訂單編號、工單 ID 和客戶 ID 被丟棄成「那筆訂單」或「那張工單」；(3) 承諾失真——客戶明確表達的期望失去精確措辭，變成模型的改述；(4) 靜默失敗——摘要讀起來是連貫的散文，遺失在審查時不可見，只有當 agent 根據降級資訊採取行動時才會浮現。緩解：在交易性事實能被摘要之前，就將它們抽取到 case facts block。

為何 tool output 應在進入 context window 前修剪，而非事後修剪？

事後修剪對之後有些幫助，但對已經發生的置換毫無幫助。如果八個冗長的訂單查詢 results 在第 2–8 輪期間留在 window 中，它們已經把其他訊號（case facts block、關鍵發現、客戶的實際投訴）推向 window 中間，lost-in-the-middle effect 就在那裡攻擊它。在 tool result 塑形層修剪——你的應用程式程式碼在發出 tool_result 之前從 40 欄位回應中抽取 5 個相關欄位——意味著那 35 個冗餘欄位從未消耗 token、從未擠壓訊號、也從未置換顯著內容。在邊界修剪，而非事後修剪。

如何決定哪些內容進 case facts block，哪些留在摘要 conversation history？

對每條資訊應用三個標準：它是否具交易性（特定的數字、日期、ID、金額或狀態）、它是否具持久性（與超過當前輪次相關），以及它是否不可妥協（遺失或失真會造成真實世界的客戶損害）？如果三者都成立，它屬於 case facts block。如果不是，它屬於（可能已摘要的）conversation history。建立關係的交流、探索性的澄清和對話色彩留在歷史中。過度填充 block 會適得其反，在 block 內部重新引入 lost-in-the-middle effect。

Section headers 如何幫助長 context 的可靠性？

Section headers（## Customer Profile、## Order 4812 Detail、## Open Promises）把無差別的中間大塊文字變成可導覽的文件。沒有 headers，Claude 必須線性掃描長輸入；有了 headers，它可以把輸入當作位置對應意義的結構化文件。Headers 與頂部放置的關鍵發現摘要結合時最有效——摘要告訴 Claude 該得出什麼結論，headers 告訴 Claude 到哪裡驗證。跨輪次保持 header 文字穩定，讓 Claude 建立對資訊位置一致的心智模型。

何時應完全重置 context，而非繼續修補當前 session？

當你看到 session 在自身 window 內已降級超過可恢復程度的訊號時重置：agent 與 case facts block 中逐字記載的事實產生矛盾、tool calls 以相同參數重複先前的呼叫（遺失狀態的訊號）、agent 幻覺出從未發生過的事件或承諾，或每輪延遲的增加與總 context 大小相關而非與任務複雜度相關。正確的重置將 case facts block 和緊湊的散文摘要持久化到應用程式儲存，開啟新 session，並在第 1 輪重新注入持久化狀態——客戶應不察覺到邊界。錯誤的重置在沒有 replay 持久化狀態的情況下重新初始化，丟棄了重置本應保留的客戶明確期望。

延伸閱讀

• Claude Certified Architect — Foundations (CCA-F) Exam Guide: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Context windows — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Long context prompting tips — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• 社群通過報告（893/1000，Kishor Kukreja，2026-04-09）: https://medium.com/@kishorkukreja/i-passed-anthropics-claude-certified-architect-foundations-exam-with-a-score-of-893-1000-2206c27efd6c

Related ExamHub topics: Session State, Resumption, and Forking, Context Management in Large Codebase Exploration, Information Provenance and Uncertainty in Multi-Source Synthesis, Effective Escalation and Ambiguity Resolution Patterns.