思考題參考答案
思考題參考答案
本檔案彙總全書十章思考題的參考答案提綱。思考題多為開放性問題，答案不唯一。參考答案由 AI 生成，經人工略作審校，僅供讀者參考。建議讀者使用 LLM 結合書稿內容進一步討論這些問題。
第一章 AI Agent 入門
1. (★★) 如果你只能給一個 Agent 系統增加一項能力——更強的模型、更豐富的上下文、還是更多的工具——你會選哪個？在什麼條件下你的選擇會改變？
對應「大腦/眼睛/手腳」公式，先找短板：通常優先補上下文，即補充觀察空間（observation space）。若任務超出模型推理能力，換更強模型。若動作空間不足（例如無法存取公司內部系統），加工具。判斷依據是分析失敗軌跡，定位瓶頸在感知、決策還是行動。
2. (★★★) ReAct 迴圈中，累計快取讀取量隨輪數近似二次方增長。如何降低這種增長？
第 i 輪讀取的快取前綴長度約與 i 成正比，累計讀取量為 1 + 2 + ... + n = O(n²)；這裡二次增長的是累計快取讀取費用，而非軌跡長度或 KV Cache 佔用。可在達到 token 閾值時批次壓縮早期軌跡，只保留結論與關鍵狀態，並把大塊中間結果外接後按需檢索，或用子 Agent 隔離。不能每輪壓縮，否則既可能損害 Agent 效能，也會引入額外的壓縮呼叫和快取重建開銷。
3. (★★) 「模型即 Agent」 範式意味著模型在工具呼叫決策上越來越自主。但本章論證了 Harness 工程的重要性反而在增加。這兩個趨勢如何共存？Agent 框架未來的核心價值體現在哪些方面？
馬與韁繩隱喻：模型越強、自主空間越大，出錯影響面越大，越需約束、驗證、糾正。框架價值從「編排 LLM 呼叫」轉向 Harness 五要素中的保障層：權限分類、熔斷器、錯誤恢復、上下文壓縮、工具生態。
4. (★★) 消融實驗中 「工具結果回饋」 的缺失導致 Agent 陷入無限迴圈。在生產環境中，除了工具結果缺失，還有哪些情況可能導致 Agent 無限迴圈？你會設計怎樣的偵測和終止機制？
其他誘因：工具反覆報同一錯誤、模型因幻覺呼叫不存在的工具、上下文壓縮導致關鍵狀態丟失、思考過程被剝離導致模型 API 報錯、任務本身無解。機制：設定最大迭代次數等停止條件；偵測重複呼叫（相同工具+參數指紋）；超過失敗閾值後升級為人工干預。
5. (★) 本章用感知、行動、策略三個維度分析了五個 Agent 產品。請選擇一個你日常使用的 AI 產品，用這三個維度進行分析，並思考它的架構設計是否合理。如果由你來設計這個 AI 產品，有哪些改進空間？
開放題。要點：仿照章中表格，寫出眼睛（能看到什麼資訊源）、手腳（動作空間是否開放式、能否內部思考）、策略（Agent 執行迴圈的模式）。
6. (★★) 如果你要設計一個專門處理航班訂票的客服系統，你會選擇工作流模式還是自主 Agent 模式？有沒有可能在同一個系統中混合使用兩種模式？
主體採用工作流：身分核實→搜尋→付款→預訂四個節點，保證「付款前不能預訂」等合規順序，且把提示注入攻擊面限制在單個節點內。開放性環節（理解需求、改簽、航班取消後的替代方案推薦）切換為自主 Agent。高風險操作（大額付款、退款）需加人工確認。
7. (★★★) 護欄部分提到了工具風險評級。如果一個工具在大多數情況下是低風險的，但在特定參數組合下變為高風險（如 delete_file 刪除普通檔案 vs 刪除系統檔案），你會如何設計動態風險評估？
評級物件從「工具」細化到「工具+參數」：呼叫時根據可逆性、權限和影響面計算風險。採用基於規則的確定性檢查（路徑黑白名單、正則），而非模型判斷。驗證時應只檢查結構化資料，防止提示注入操縱判斷結果。
8. (★★) 本章的 Agent 產品表格中，所有 Agent 的動作空間都是 「開放式」 的。一個受限的動作空間（比如只能從預定義選項中選擇）在什麼場景下反而優於開放式？
高合規、高風險、錯誤不可逆場景：如退款、付款，受限選項即「約束」，天然防呆，從設計上讓錯誤無法發生。
9. (★★) 人工干預機制要求 Agent 能 「優雅地移交控制」。但在實踐中，使用者可能不線上、回應很慢、或者給出模糊的指令。此時 Agent 應該怎麼辦？
Fail-safe：高風險操作在未獲確認時暫停，而非預設執行；先完成可逆的低風險部分，將高風險部分記錄在文件中，便於人類決策和 Agent 恢復；使用非同步溝通工具（訊息、郵件）通知使用者並設定逾時策略；指令模糊時先澄清意圖。
10. (★★★) 引言指出 「好的設計原則應該穿越模型的迭代週期」，但實作這些原則的具體工程手段可能會隨模型能力進步而過時。試舉一個這樣的 Agent 工程手段，並說明理由。
示例一：透過約束取樣強制工具呼叫符合嚴格格式。這是在模型容易輸出非法 JSON、遺漏參數時採用的可靠性補丁；隨著模型的格式遵循能力提高，其收益可能逐漸降低，但高風險場景仍應保留確定性的格式校驗。
示例二：為彌補模型無法持續吸收新知識而引入外部知識庫。如果模型未來具備可靠的持續學習能力，一部分知識維護可能從模型外部遷移到參數中。不過，外部知識庫在即時更新、精確檢索、權限控制和來源追溯方面仍有獨立價值，因此更可能縮小適用範圍，而非完全消失。
示例三：要求所有能力都必須透過模型 API 的標準工具呼叫介面暴露，禁止自定義呼叫形式。Skills 已經展示了另一條路徑：用文字描述能力及操作方法，再讓模型透過通用命令列工具執行；從模型視角看，這相當於在通用執行器之上理解並遵循一種自定義的文字呼叫協定。隨著模型理解任意介面的能力增強，「必須使用標準工具呼叫格式」不再適合作為普遍原則。標準格式對於互操作、結構化校驗以及能力較弱的模型仍然有用，但它應是基於場景的工程選擇。
示例四：要求提示詞與全部工具定義必須預先放在上下文開頭。這種做法源於早期模型的指令遵循能力有限，提示或工具定義離開熟悉的固定位置後，模型往往難以正確識別和執行。Skills 會在執行過程中按需把提示詞載入到上下文中間；動態工具發現也會在找到新工具後，把工具定義追加到已有軌跡之後。隨著模型的指令遵循能力增強，以及針對這類動態載入方式進行專門的後訓練，提示詞和工具定義不再必須固定在上下文開頭。
第二章 上下文工程
1. (★★★) 實驗 2-3 發現，滑動視窗對話歷史會導致 Agent 反覆執行相同的工具呼叫。但完整保留歷史又會讓上下文不斷膨脹。設計一種策略，既能避免資訊丟失，又能控制上下文長度，且不破壞 KV Cache 前綴。
①用壓縮代替丟棄：訊息只追加不刪改，接近閾值（如視窗 80%）時批次壓縮舊 tool results。②分層機制：大輸出落盤留摘要、雜訊直刪、歸檔式摘要保留脈絡。③子 Agent 隔離，讓中間狀態不進主上下文。
2. (★★) 正文舉例的開源推理模型，其 Chat Template 思維鏈保留機制只保留 「最後一個真實使用者訊息之後」 的思考。如果一個 ReAct 迴圈跨越了上百輪工具呼叫，累積的思考內容可能消耗大量上下文。你會如何修改這個機制來應對超長迴圈？正文提到的那家廠商曾要求剝離全部歷史思考，後來又反轉為強制回傳全部 reasoning_content——對比這兩種相反的策略，各有什麼利弊？這個反轉說明了什麼？
修改方向：滑窗保留——完整保留最近若干輪思考，在視窗外按 token 預算（而非固定輪數）觸發滾動壓縮，產出結構化狀態列（目前目標、已確認事實、已排除路徑、待辦）；壓縮只發生一次且位置固定，快取重建代價是一次性的，不必每輪承擔。剝離策略：節省 token、前綴穩定且有利於快取，並與訓練分佈一致（歷史 CoT 從不在輸入中）；但每輪都要從零開始推理，會丟失長程計畫，也容易重複犯錯。強制回傳策略：思路連貫，長程 Agent 任務表現更好；但 token 成本高、每輪前綴都會膨脹，且無法從非思考模式無縫切換。這個反轉說明：對純對話場景而言，思考是廢料；對 Agent 任務而言，思考則是狀態——產業實踐已轉向後者。
3. (★★) 上下文感知壓縮實驗中，從約 148K 個字元壓縮到約 2,000 個字元，這種極端的壓縮是否存在「不可逆資訊損失」的風險？如何解決？
有風險，壓縮是一種有損投影；如果問題涉及未保留的資訊，就無法得到可靠答案。解法是採用「有損壓縮＋無損索引」：每條事實都附上來源 URL，以便回溯；原始輸出存入磁碟，平時只查看摘要預覽；明確保留資訊的優先順序——架構決策、保證語意完整性所需的資訊（時間、公司名）、驗證狀態以及 UUID/hash 等識別符號均原樣保留；透過自適應視窗化推遲壓縮時機。
4. (★★) Agent 狀態列將隱含狀態明確化。但如果狀態列本身包含了錯誤資訊（比如工具計數器出了 bug），Agent 可能基於錯誤的資訊做出有害的決策。這種「元資訊可靠性」問題如何緩解？
模型幾乎會無條件相信狀態列，其中的錯誤也會原樣傳導。緩解措施：①用確定性程式碼維護，絕不讓 LLM 批次統計很長的歷史記錄（即便使用 LLM，也只讓它逐條抽取，再由程式碼彙總）；②把狀態列準確率作為一線生產指標持續監控；③只採用來自真實世界可靠觀測的資訊，防止狀態列遭到投毒。
5. (★★) 提示工程消融實驗表明，資訊組織的混亂導致成功率下降 30% 以上。但在實際開發中，系統提示詞往往由多人在不同時間維護。你會用什麼工程實踐來防止系統提示詞的 「熵增」？
①把提示詞當程式碼：版本控制、評審，產品經理定業務規則、工程師負責編碼；②用 Tau-Bench 類基準測試做迴歸測試，改動前後跑消融實驗定位影響；③強制結構化：SOP 流程驅動而非規則堆砌，XML/Markdown 分層；④片段按「可快取/破壞快取」分類命名，動態內容歸到快取邊界後；⑤膨脹內容拆成 Skills 按需載入。
6. (★★★) 本章提出「上下文學習本質上是檢索而非推理」。如果這個論斷成立，目前所有基於「把更多資訊塞進上下文」的最佳化方向都需要重新審視。你認為應該如何突破這一局限？
為「只有一半的檢索引擎」補上提煉層：①採用上下文蒸餾或狀態列，用程式碼提前算好結論，供模型直接檢索；②主動壓縮，把原始記錄轉化為高密度的結構化知識；③用子 Agent 隔離，避免雜訊進入主上下文；④把互動作為第三條路徑，將外部儀器觀測到、模型無法自行推導的新資訊寫回上下文；⑤探索可編輯、可組合的 KV Cache「筆記」和跨工作階段記憶沉澱。
7. (★★★) Skills 的漸進式披露只在 Agent 判斷需要時才載入完整內容。但這個判斷本身依賴模型的能力——如果模型不知道自己不知道什麼，就無法正確觸發 Skill 的載入。這個「元認知」問題如何解決？
①Skill 的後設資料（名字、描述）常駐上下文，讓模型始終「知道自己擁有什麼」；②Skill 的 description 寫成路由條件而非功能介紹："Use when / Don't use when"，避免寬泛描述。
8. (★★) Skills 機制中，Agent 從 SKILL 檔案中動態讀取提示詞之後，後續的操作能否正確遵從這些指令？不同的模型對 Skills 模式的支援有什麼區別？
取決於 Skill 的注入方式：注入 system prompt 遵循最強但破壞 KV Cache；作為普通檔案讀到上下文中間，模型的指令遵循可能較差；注入到上下文末尾，指令遵循較好，但每次工具呼叫都需要重新計算 skill 部分的 KV，成本較高。
9. (★★★) 本章強調動態資訊（如系統時間戳、工具列表順序）的變化會破壞 KV Cache 前綴命中。在一個擁有大量工具且工具集頻繁變動的生產系統中，你會如何設計上下文布局來最大化快取命中率？
①少量穩定核心工具（如七個）＋通用執行器，具體能力走 Skills 漸進披露，工具定義凍結在靜態前綴、固定順序；②子 Agent 與父 Agent 前綴保持相同。
第三章 使用者記憶和知識庫
1. (★★) 在使用者記憶系統中，當同一使用者在不同工作階段中提供了矛盾資訊（比如兩次提到不同的家庭住址），記憶系統應該如何處理這種衝突？
採用 Mem0 式「擷取—對比—決策」流水線：先透過向量檢索找出相近的舊記憶，再由 LLM 判定 ADD/UPDATE/DELETE/NOOP，如「搬到台中」應透過 UPDATE 覆寫「住在台北」；同時進行版本化管理，地址類資訊只保留最新版並標記時間戳，工作經歷類資訊則保留完整歷史；檢索時可藉助上下文前綴（人物、時間、意圖，如電匯資訊三次修改的案例）判斷哪條資訊最終有效。
2. (★★) 上下文感知檢索將原始文件的上下文附加到每個分塊。但如果原始文件本身結構混亂或存在矛盾資訊，這種方法可能傳播甚至放大錯誤。你會如何在檢索階段引入 「資訊品質」 訊號？
可以借鑑「知識庫時效與治理」的思路：給分塊附加版本號、生效/失效時間、來源等後設資料，檢索時過濾已失效內容，或在前綴中明確標註「此條已於某日廢止」；重排序階段把來源權威性和時效性納入評分，而非只看語意相關性；在索引階段，讓生成前綴的 LLM 同時偵測並標記分塊間的矛盾，類似記憶系統中的版本化衝突偵測。
3. (★★) 第四章介紹的多模態資訊擷取，會先把圖表轉為文字描述再進行檢索。這個 「翻譯」 過程可能丟失視覺資訊中的空間關係。舉一個具體例子，說明純文字描述無法完整傳達的圖表資訊，並設計一種保留該資訊的方案。
例：系統架構圖中的邏輯關係，折線圖中兩條曲線的交叉點位置，或 PDF 表格中單元格與表頭的行列對應。方案一：原生多模態處理；方案二：提供多模態圖片分析工具。
4. (★★★) Rich Sutton 的 「苦澀的教訓」 認為通用方法（搜尋和學習）最終會勝過手工設計的特徵。本章建構的整個知識系統（分塊策略、索引結構、檢索管道）是否本身就是一種 「手工設計」？如果模型能力足夠強，這些設計是否會被簡單的 「全量輸入」 所替代？
確實是手工設計，部分環節（分塊、融合調參）可能隨長上下文而弱化；但黑貓白貓案例表明「全量輸入」也不夠：注意力是軟檢索，跨文件聚合統計仍需索引期預提煉；知識過期更新、權限/租戶隔離、可審查性、成本這些工程約束與模型能力無關；且檢索與索引期 LLM 提煉本身就是「搜尋+學習」的通用方法，並非與苦澀教訓對立。
5. (★★★) 隨著模型能力的提升，你認為領域知識庫還重要嗎？未來強大的基座模型是否有可能包含領域知識庫中所有的資訊，從而不再需要領域知識庫？
仍然重要：訓練資料有截止日期，知識庫可隨時更新；企業內部流程、私有判例等根本不在公開語料中；多使用者共享需要進行權限過濾與租戶隔離，參數中的知識無法按呼叫者裁剪；外部儲存可審查、可進行版本控制，也可以使失效內容下線，這些都很難透過參數記憶做到；即使採用參數化路線（後訓練 / User as Engram），也面臨「記住容易，用來做多跳推理卻很難」的問題。
6. (★) RAPTOR 透過自底向上的層次摘要建構樹形索引，GraphRAG 透過實體關係建構圖結構索引。這兩種結構化索引分別擅長回答什麼型別的查詢？
RAPTOR：從宏觀概念逐步鑽取細節的「跨層穿梭」式查詢，如先定位「SIMD 指令集」摘要再下鑽到 SSE 細節，兼顧總覽與細節兩種粒度。GraphRAG：多跳關係推理（「我的醫生所在醫院的地址」沿關係鏈走訪）與實體消歧（兩個「張醫生」是不同節點）等「A 和 B 有什麼關係」類查詢，社群摘要還提供主題聚類。
7. (★★) 檔案系統範式將知識組織為類似檔案系統的層次結構。這種方式和傳統的向量資料庫 RAG 相比，在什麼場景下更有優勢？
純文字可被使用者直接閱讀、編輯、修正，可用 Git 版本控制與回滾，適合需要人機共同維護、審查知識的場景；Agent 有 write_file 能力即可自主記錄經驗，形成記憶自進化迴圈（外部化學習）；分層摘要的漸進披露使多數查詢到概覽層即可決策，省 token；前提是像 Wikipedia 一樣建立交叉連結和索引頁，否則孤立檔案越多越難檢索。
8. (★★★) 從結構化資料（如司法判決資料庫）中自動發現 「裁判因素」 和 「因素重要性層級」，本質上是讓 Agent 從資料中歸納規則。這種資料驅動的知識擷取是否能達到人類專家手工編寫規則的品質？
優勢：如 CAIL2018 實驗所示，「自下而上」的因子發現更貼合資料，而非人類先驗，能捕捉散落在成千上萬份判例中、專家難以明確寫出的隱性權衡經驗，而且可以量化。局限：LLM 擷取出錯會造成知識汙染，資料本身的偏差也會被繼承，聚類原型只能反映相關性，無法說明因果關係。折中方案：採用資料驅動建模，由專家審核 Schema 與結果；由模型提出問題，用統計結果支撐解釋。
9. (★★★) 請為一個 Markdown 使用者記憶庫同時設計增量更新與定期整理流程。如果 Reviewer 與 Proposer 使用同一模型，且只能看到 Proposer 挑選的對話片段，系統仍可能合入哪些錯誤？請從模型獨立性、證據覆蓋和工具權限三方面說明你的改進。
增量更新：把記憶庫當程式碼庫，每條變更走一次 PR。Proposer 先檢索相關舊知識，再提出儘可能小而完整的 diff，同步維護連結、索引、時間後設資料與證據引用；Reviewer 拿變更前的知識、diff 和原始證據獨立審核，退回時給出指向具體證據和行號的可執行意見；迭代設最大次數或成本上限，超限轉人工而不是預設放行。合入後先由 CI 檢查格式、連結、後設資料與權限標籤，再從已合入版本增量重建受影響的分塊與向量索引。定期整理：按時間或按新增條目數觸發全量掃描，去重、合併、拆分過大檔案並重建入口頁；關鍵是回到原始對話逐段核對，檢查舊摘要有沒有丟掉否定詞、時間條件或限定語；遇到互相矛盾的說法不按「保留最新」收斂，而是追溯各自來源、寫清適用場景，證據不足時保留衝突與待確認狀態。重組同樣以 PR 提交，可按目錄拆成多個 PR，全部通過後除重建索引外還要回放一組典型檢索測試案例，確認原本能找到的知識沒有變得不可見。
使用相同模型並僅輸入部分片段，會漏掉三類錯誤。模型獨立性：同源模型共享訓練先驗與盲點，Reviewer 容易順著 Proposer 的結論複述，而不回到證據，同一處誤讀因此不會被發現——應改用能力相近但來自不同家族的模型互審。證據覆蓋：只看 Proposer 挑選的片段，斷章取義、被丟棄的否定詞與前置條件以及與其他檔案的衝突都無從暴露——Reviewer 必須能在其被授權的租戶或使用者範圍內，自主檢索完整的知識庫與原始證據庫，而不是隻接收上游選好的幾段。工具權限：若 Proposer 能直接寫入主分支或修改線上索引，審核就形同虛設——應強制分工，Proposer 只寫工作分支，Reviewer 唯讀證據並提交審核結論，只有合併流程可以更新主分支與線上索引，驗證器與發布門檻本身不在可修改範圍內。
第四章 工具
1. (★★) MCP 標準將工具定義從 Agent 框架中解耦了出來。但標準化也意味著複雜的工具互動模式（如串流輸出、雙向通訊、有狀態工作階段）可能難以在標準協定中表達。你認為 MCP 未來最需要擴展的能力是什麼？
最需要擴展的是跨工作階段的事件驅動能力。MCP 已經能夠支援多輪互動、變化訂閱和長任務，但它的核心仍是對單次能力呼叫進行標準化，而不是讓 Agent 持續線上。新郵件、外部回呼等事件如何喚醒 Agent，多個事件如何排隊、恢復和重試，仍需要 Agent 框架自行處理。未來如果能在不破壞工具協定簡潔性的前提下，為這類事件編排提供更統一的約定，MCP 的適用範圍會進一步擴大。
2. (★★) 在 MCP 生態中，不同的 MCP 伺服器可能提供功能高度重疊的工具。當 Agent 面對多個來源不同但功能相似的工具時，應該如何選擇？如果不同來源的同名工具在行為上略有差異（比如一個返回摘要，另一個返回全文），Agent 是否有能力感知並利用這種差異？
選擇依據：接入前審查描述、鎖定版本、配最小權限憑證，警惕同名工具遮蔽（tool shadowing）把敏感呼叫路由給惡意方；執行時靠層次化分類和動態發現縮小候選。模型是否能感知差異，取決於工具描述的品質。
3. (★★) 本章提出了「執行-驗證-回饋」閉環（如寫程式碼後自動執行 linter）。這種「操作後立即自動驗證」的模式還可以應用到哪些工具場景？是否存在某些操作，其驗證本身的成本或風險超過了操作本身，導致這種模式不可行？
可泛化的場景：修改設定後在沙箱中實際執行，驗證設定是否生效；生成文件或簡報後渲染成截圖，利用模型的多模態能力檢查排版。不適用的場景：發郵件、撥電話、對外轉帳等不可逆或非冪等操作。此類操作要麼無從驗證，要麼驗證本身會再次觸發真實世界事件；此時應改用事前控制手段，如提議者-審核者的事前審批。
4. (★★) 本章提出了「工具爆炸」問題——Agent 面對數千個工具時選擇精度下降。除了主動工具發現，還有哪些方案？可以參考人類專家在面對大量可用工具時的策略。
①層次化分組：先定位「伺服器/App」再選具體工具；②Skills 式「按需查閱」：像查工具書，目錄常駐上下文、細節按需載入；③少數常用基礎工具「放在手邊」常駐上下文，其餘靠目錄索引。
第五章 Coding Agent 與通用 Agent
1. (★★) 程式碼生成被稱為 Agent 的「元能力」。但程式碼執行引入了安全風險——Agent 生成的程式碼可能包含漏洞、無限迴圈或資源耗盡。沙箱隔離能解決部分問題，但也限制了程式碼能力（比如無法存取網路或檔案系統）。如何在安全性和能力之間找到最佳平衡點？
沙箱按場景分級隔離（容器/microVM）；網路預設斷網、白名單代理按需放行；原始碼唯讀掛載、API key 不要放在沙箱內；沙箱資源限額；沙箱生命週期管理（逾時）。
2. (★★★) Agent 自舉——能創造 Agent 的 Agent——實現了「智慧的自我繁殖」。但每次自舉都可能引入新的偏差或錯誤，這種錯誤會在代際間累積嗎？如何防止 Agent 自舉的退化？
若每一代都在上一代產物的基礎上繼續繁殖，一些缺陷可能會累積。關鍵是要有足夠有挑戰性的 verifiable task（可驗證任務），例如足夠困難的程式設計任務。
3. (★★) 程式碼生成 Agent 在處理日誌解析時，能自動跟隨格式演化。但如果格式變化是一個 bug 而非預期改動，Agent 的適應性反而掩蓋了問題。Agent 應該如何區分「需要適應的變化」和「需要報告的異常」？
適應前先診斷：對照架構文件與 PRD 判斷新格式是否符合預期（實驗 5-11 的思路）；核對版本控制記錄，確認變化源自合法的程式碼提交，還是沒有明確來源的漂移；類比 τ-bench 的 log_mismatch，即使選擇適應，也要記錄告警、自動建立 issue，而非靜默相容；不確定時引入人在迴路進行確認。原則：適應與報告並行，不能讓適應機制吞掉異常訊號。
4. (★★) 本章在 PPT 生成、影片編輯和日誌視覺化中反覆使用提議者-審核者機制。如果 Reviewer 的審美偏好與目標使用者不一致，比如 Reviewer 認為資訊密度合理但使用者覺得太擁擠，回饋迴圈會收斂到錯誤的局部最佳。如何讓使用者的偏好回饋也參與 Reviewer 迴圈？
把使用者回饋作為最高優先順序的結構化事件注入 Agent 軌跡；將使用者偏好記錄在外部的 MEMORY.md 中，使其能夠跨任務生效；交付 HTML 格式的文件而非 Markdown 文件，以便使用者查驗。
5. (★★) 本章展示了 Coding Agent 把執行和除錯中獲得的經驗沉澱回程式碼庫的多種方式——寫入知識庫檔案、更新架構文件、維護專案指令檔案、把操作序列固化為程式碼。如果把這些經驗進一步提煉為系統提示詞中的規則，規則集會隨時間不斷膨脹。如何對沉澱下來的規則做「垃圾回收」——識別並清理冗餘或過時的條目？為什麼一次成功的程式碼修改還不能直接視為第九章所說的持續進化？
GC 思路：能編碼進 Linter、CI 或工具校驗的規則移出提示詞；追蹤規則命中率和衝突，定期對照程式碼庫重新驗證；用 Markdown 與 Git 保留來源、版本和回滾能力。一次補丁成功只說明它解決了目前案例；持續進化還要求修改來自可追溯的執行證據，能改善後續任務，並通過舊任務迴歸與安全驗證。
6. (★) 「對遠端工作友好的團隊往往也對 AI Agent 友好。」你所在的團隊或組織，在知識文件化方面距離「AI-ready」還有多遠？最大的障礙是什麼？
開放題。可用本章的代理指標自查：遠端新人只靠倉庫和文件能否獨立開展工作。檢查項：決策是否記錄在文件中、上下文是否寫進 issue/PR、建構和測試命令是否記錄在 CLAUDE.md/AGENTS.md 一類的指令檔案中、部落知識是否沉澱為開發者指南。最常見的障礙是依賴「問旁邊同事」的口頭傳遞與白板文化——Agent 讀不到口頭約定，只能讀到文件。
7. (★★★) Simon Willison 提出了 Agent 的「致命三要素」（存取私有資料、暴露於不受信任內容、具備外部通訊能力），本章在此基礎上增加了第四個——持久記憶。在一個需要同時處理這四種要素的生產環境中，你會如何設計安全策略？
按四類邊界分層設防。資料邊界：不掛載憑證，以唯讀方式掛載原始碼，盡量縮小可見範圍。輸入信任邊界：標註來源，將外部內容降格為「可參考、無指令效力」的資料（忠誠度守則）。輸出影響邊界：預設斷網並設定白名單出口、解析命令語意而非採用黑名單、使用 Sidecar 獨立複核並引入人在迴路——關鍵操作必須由上下文之外的機制複核。跨工作階段邊界：寫入 MEMORY.md 的內容需經過與外部內容同等嚴格的信任審查。目標是即使受到提示注入，惡意指令也無法執行。
8. (★★) Artifact 模式讓 Agent 生成 SQL 或前端程式碼，由資料庫和瀏覽器直接執行，繞過 LLM 處理大量資料。與傳統的「Agent 直接給出答案」相比，這種「Agent 生成程式碼、系統執行程式碼」的分工有什麼優劣？生成的 SQL 可能執行破壞性操作、生成的 HTML 可能包含漏洞，又該如何確保安全？
優劣：資料從資料庫直達前端，繞過 LLM 這個「中間人」——速度快、節省 token，還能避免抄寫大量資料時產生幻覺錯誤，適合呈現大量資料；程式碼可稽核、可重用，還能組成流水線（SQL 結果直接傳給視覺化程式碼）。代價是 LLM 看不到查詢結果，無法基於資料內容進一步歸納和決策，不適合需要模型先消化資料再推理的任務。
安全：SQL 用最小權限唯讀帳號執行，並新增 CPU、記憶體等資源限制，防止資源耗盡；HTML/UI 優先 A2UI 類宣告式協定，Agent 只輸出介面描述 JSON，由用戶端用受信元件目錄渲染，不執行任意程式碼；確需任意 HTML 時應在沙箱環境中展示，防止注入。
9. (★★) 將業務規則編碼為工具內部基於資料庫真值的校驗，並用參數設計引導模型在呼叫前核對政策條件，本質上是用程式碼結構來約束 Agent 行為。這種「程式碼即規則」的模式相比自然語言規則有什麼優勢和局限？
優勢：沒有歧義、能夠確定性執行、擅長處理複雜的條件組合；政策事實取自資料庫真值和伺服器端時鐘，不採信模型自報值，幻覺和提示注入都無法繞過，是防止不可逆操作的最後一道防線；expected_* 參數還可兼作強制 checklist，引導模型思考。局限：程式碼不會向使用者解釋政策，也不會尋找變通方案，而且有維護成本。結論：程式碼規則與自然語言規則互補，而非相互替代。
第六章 互動：觀察與動作空間的擴展
1. (★★) 在非同步 Agent 架構中，事件佇列的優先順序策略需要在設計時確定。但如果優先順序判斷本身需要語意理解（比如判斷一條新訊息是否比目前任務更緊急），這個判斷應該由誰來做——規則引擎還是另一個 LLM 呼叫？各有什麼代價？
採用分層混合方式：型別明確的事件用規則硬編碼，零延遲、確定性強，但無法理解「馬上停下來」與「今天天氣怎樣」的語意差異；語意模糊的事件交給輕量級分類 LLM，由其充當事件路由器，代價是增加數百毫秒延遲和額外費用，而且可能誤判；同時需要像 Sidecar 一樣唯讀取結構化欄位，以防範提示注入。
2. (★★) 在佇列式事件處理中，模型傾向於只關注最後一個事件，本章透過 Agent 狀態列標記和彙總來緩解。但如果佇列中積壓了 20 個事件（10 個工具結果 + 5 條使用者訊息 + 5 個系統提醒），你會如何組織這些事件的呈現順序和格式，使模型不遺漏關鍵資訊？
先用規則和輕量級 LLM 分類去重：緊急事件（告警、使用者中斷）單獨採用取消式處理，不混入批次事件。將 10 個超長的工具結果截斷後持久化到檔案，只保留開頭、結尾和檔案路徑。在上下文末尾的系統狀態列中加入彙總清單（各類事件的數量，以及逐條回應的要求）。
3. (★★★) Agent 代表使用者與外部世界互動時，本質上面臨一個身分選擇：是用獨立的虛擬身分（專屬郵箱和電話號碼）以第三方身分行動，還是直接以使用者本人的身分操作其個人帳號？前者可以在背景自主操作，但第三方可能不信任一個非真人的身分；後者擁有更完整的上下文和權限，但引入了信任授權和安全邊界的問題。你認為在什麼場景下應該選擇哪種模式？
預設使用虛擬身分：可以在背景自主操作且便於稽核，出錯或被攻破時也不會暴露使用者的全部數位身分，就像秘書使用自己的辦公郵箱；但需要應對 CAPTCHA/IP 信譽問題（住宅代理）。在必須以本人身分操作的場景中（帳戶身分驗證、三方通話確認，如 Pine 打客服電話），採用 Human-in-the-loop 認證：透過 VNC/RDP 讓使用者在視覺化介面中親自登入。判斷標準包括對方是否要求帳戶持有人本人操作、操作風險和憑證範圍。
4. (★★) 語音 Agent 的端到端模型將 ASR-LLM-TTS 合併為單一模型，降低了延遲卻失去了模組化。如果端到端模型在某個環節（如語音識別）出錯，除錯和修復比序列管道困難得多。你會如何設計端到端語音 Agent 的可觀測性（observability）系統？
讓模型同時輸出可讀的中間表示，如 Moshi 的「內心獨白」文字流和聲學事件標記（
<emotion>、<noise>）；用「自級聯」定位出錯環節：讓同一模型先轉錄再推理，並與端到端結果對照，判斷錯誤出在感知還是思考；離線按照副語言理解、輪次判斷等維度進行分項迴歸測試。
5. (★) 正文提到的 MPS 雙腦架構讓模型能「邊想邊說」。但人類在「邊想邊說」時經常會說出未經深思熟慮的話、自我糾正、或使用填充詞。Agent 的「邊想邊說」應該模仿人類的這些特徵嗎？
應該模仿具有訊號價值的「不完美」：停頓、填充詞是思考的外化，能夠掩蓋延遲，其插入位置可由 LLM 決定；不應模仿會破壞信任的自我糾正：方案一中的快慢思考矛盾（「到底買不買？！」）會讓信任崩塌；MPS 實驗顯示 CoT 開頭多是在複述問題，因此提前開口說些鋪墊是安全的，無需先說錯再改口。
6. (★★) SoM（Set-of-Mark）及其結構化變體（DOM 元素索引）將 Computer Use 的視覺定位從開放座標預測轉為封閉 ID 選擇，但都需要先偵測和標註介面元素——無論靠分割模型還是靠 DOM。如果介面包含非標準控制元件或動態變化的元素，標註就可能不完整或不準確。這種情況下應該回退到座標預測嗎？
應保留座標預測兜底：它是唯一不依賴標註的路線，非標準控制元件、動態元素均適用；更實用的是混合 action space：標註可得的元素仍用 ID 選擇。座標預測須做解析度匹配與等比縮放，否則會發生系統性偏移。
7. (★★) XLeRobot 等幾百美元級機器人平臺讓遙操作資料收集變得廉價。但遙操作資料的品質高度依賴操作者的技能。一個不熟練的操作者提供的資料會如何影響 VLA 模型的訓練？如何在資料收集階段自動篩選低品質資料？
VLA 主要靠模仿學習，低質演示會把抖動、繞路、猶豫與失敗動作當成正確策略學進去。呼應第八章的判斷：資料比架構更關鍵。
8. (★★★) 本章涵蓋了語音、Computer Use 和機器人三種互動形態。互動架構可以透過端到端統一、模組化級聯或前景互動與背景推理解耦來改進，而不必和智慧上限沿同一條路線增長。未來五年的 Agent 應該優先追求更強的統一模型，還是保留可替換的快慢分工？請結合延遲、可觀測性、模型迭代速度和任務風險討論。
按 Thinking Machines Lab 主張，互動性將內建於模型而非外掛 harness，隨智慧一同擴展；Computer Use 從逐幀截圖走向連續觀察；具身智慧的世界模型將全面實現，但由於前沿推理模型發展很快，快慢解耦不會消失，互動模型與 SOTA 思考模型的快慢思考協同架構可能成為長期架構。
9. (★★) DOM/Accessibility Tree 元素索引在標準 Web 應用上效果顯著，但越來越多的軟體介面（Canvas/WebGL 渲染、跨平臺自繪控制元件）不提供可存取的結構化資訊，只能依靠視覺標註或座標預測。你認為 Computer Use 應該押注純視覺路線，還是同時維護結構化和視覺兩條路徑？維護兩條路徑的成本和收益分別是什麼？
短期內兩條路徑並存：能夠取得結構化索引時，定位最準確、最穩定，還能避免分割模型誤檢；純視覺則是原生軟體、Canvas 和遊戲中的唯一選擇。當模型本身的 grounding（點選指定座標）能力較強時，使用結構化索引方案並不會體現出顯著優勢。長期來看，純視覺路線的上限更高。
10. (★★) VLA 模型採用動作分塊（action chunking）——如正文所述，模型一次生成一小段未來動作，由控制執行緒以更高頻率回放——將推理延遲隱藏在執行時間裡。但如果執行過程中環境突變（如物體被移走），預生成的動作序列就會失效。如何在動作分塊的效率優勢和環境變化的回應速度之間取得平衡？
分塊本質上是用反應速度換取動作的平滑性，塊越長，反應越遲鈍；塊長只需滿足「推理時間＜塊執行時間」的下限，不應盲目加長；執行過程中讓感知模型持續執行，偵測到環境突變就丟棄剩餘動作並重新推理，相當於語音場景中的「打斷」。可根據場景動態調整塊長：靜態場景使用長塊以節省算力，動態場景使用短塊以保證回應速度。
11. (★★★) 本章的三個場景（語音、Computer Use、機器人）都面臨「感知-思考-行動」迴圈的延遲問題，都需要在智慧上限和互動時效之間做分工。在語音場景中，這表現為「說錯了再糾正」；在 Computer Use 場景中，這表現為「先點再看」；在機器人場景中，這表現為「走一步看一步」。如何透過動作分級、可逆操作、狀態確認、權限控制和安全停止，保證快速互動不會導致無法挽回的後果？
按可逆性給動作分級：快思考只允許執行可逆動作，不可逆操作則交由慢思考把關；不允許快模型執行會造成不可逆後果的工具呼叫。
12. (★★★) 本章反覆出現同一組原語（喚醒、安全點、取消、搶佔、快慢分離）在不同時間尺度上的實作。請任選其中一個，說明它在事件驅動（秒—天）與機器人動作分塊（毫秒）兩處的實作差異；這種差異主要由什麼決定——環境變化的速度、動作的可逆性，還是觀察的獲取成本？
以「取消」為例。事件驅動中的取消發生在兩次工具呼叫之間的安全點：Agent 收到 terminate 後清理資源、返回確認再退出，延遲以秒計也可以接受，因為一次工具呼叫本身就要幾秒到幾分鐘。動作分塊中的取消則必須在毫秒內生效：控制執行緒一旦發現安全事件或觀察顯著變化，就要立刻停止目前動作、丟棄剩餘 chunk 並重新觀察，慢一步就可能撞上障礙物。
在三個候選因素中，觀察的獲取成本其實最不關鍵——兩邊都能以較低成本重新觀察。真正決定差異的是另外兩個因素的組合：環境變化的速度決定安全點必須設定得多密集（工具呼叫之間設定即可，還是每個控制週期都要設定），動作的可逆性決定錯過安全點的代價（多發一封郵件還可以再補一封道歉，撞倒的杯子卻無法復原）。
由此可以提煉出一條設計規則：安全點的密度應與環境變化速度匹配；而在安全點之外還需要多少額外防護（硬體急停、獨立安全控制器、二次確認），取決於動作有多不可逆。這也解釋了為什麼第四章的高風險操作要採用事前審批，而機器人要使用獨立於模型的硬體安全層——兩者都是在「安全點不夠用」的地方補上的第二道防線。
第七章 Agent 的評估
1. (★★) LLM-as-a-Judge 使用語言模型評估語言模型的輸出。這種 「自我評估」 是否存在系統性盲區——比如模型可能一致地給某種風格的回答打高分，而這種偏好與人類評判不一致？如何偵測和校正這種偏差？
存在：長度偏差、回答風格偏差、同源模型被鑽空子（古德哈特定律）。偵測：建 100-200 例人工金標集，測評判與人類的 Cohen's kappa；定期稽核評分與回答長度的相關性；紅隊構造對抗案例。校正：Rubric 明確懲罰冗長、限長度；不同模型家族多源異構評判。
2. (★★★) 評估資料集的 「防洩漏」 設計至關重要。但在開源生態中，benchmark 資料一旦公開，很快就會被納入訓練資料。這場 「貓鼠遊戲」 有終局嗎？設計一種從根本上抵抗資料洩漏的評估方法。
靜態題庫無終局，只能追趕。根本出路是公開「生成機制」、私有化「具體例項」：像 τ²-bench、AndroidWorld 那樣參數化範本每次隨機例項化，驗證基於最終環境狀態而非固定答案序列。
3. (★★) Scale AI 的四準則（基於專家指導、全面覆蓋、按標準重要性加權、評價標準自包含）旨在消除評估的主觀性。但某些任務維度（如 「回答是否有幫助」「語氣是否恰當」）天然具有主觀性。如何為這些主觀維度設計可靠的 Rubric？
把抽象標準轉化為可驗證的行為。每一檔都配上具體示例和邊界案例；Rubric 是迭代的產物——在試用中收集評價者的分歧，逐漸演化為判例集。再輔以多個評委的加權評分和一致性檢查，將存在分歧的案例送交人工複核，並在金標集上校準一致率。
4. (★★) τ-bench 透過模擬真實使用者行為來評估 Agent。但模擬使用者本身也是一個 LLM——它可能系統性地低估某些邊緣場景（如情緒激動、表達不清的使用者）。如何驗證模擬使用者本身的品質？
τ-bench 初版的教訓是：模擬器過於機械、指令過於簡單（Agent 能猜對答案）。驗證手段：人工抽檢模擬對話，檢查模擬器是否遵守漸進式披露原則、是否編造劇本之外的資訊；用小樣本真實使用者進行測試，觀察其模型排名是否與模擬評估一致。
5. (★★) 配對比較（Bradley-Terry 模型）假設偏好是傳遞的（如果 A > B 且 B > C，則 A > C）。但人類偏好經常違反傳遞性。在 Agent 評估中，非傳遞偏好可能出現在哪些場景？這如何影響排名的可靠性？
場景：多維權衡時（A 準確但慢、B 快但簡略、C 詳盡但貴），不同評判者/任務看重的維度不同。Chatbot Arena 的排名本就依賴使用者提問分佈。影響：BT 把實力壓成單一分數，非傳遞時排名不穩定、隨對局分佈漂移。緩解：按能力維度分別排名、報告兩兩勝率矩陣。
6. (★★) 本章區分了 Pass@k 的能力上限與 Pass consecutive@k 的業務可靠性。對於一個單次成功率只有 60% 的 Agent，怎樣結合任務的失敗成本、重試成本和副作用，決定應該報告哪個指標、取多大的 k？
先看失敗是否可回滾。失敗能自動重試、又不產生外部副作用時（檢索、草稿生成、程式碼補全），關心的是「給足機會能不能做成」，應報告 Pass@k，k 取實際允許的重試次數；失敗會留下不可逆後果時（付款、退款、對外發信、生產部署），一次錯就是真實損失，應報告 Pass^k。單次成功率 0.6 時，Pass@5 ≈ 99.0%、Pass^5 ≈ 7.8%——同一個 Agent 的兩個數字相差一個數量級，只報前者會嚴重高估可靠性。
k 的取值應來自部署現實，而不是好看的數字：Pass@k 的 k 取重試預算，Pass^k 的 k 取一次值班或一批任務中連續執行的次數。重試成本高時可以兩段式驗收——先用 Pass@1 粗篩方案，再對少數候選跑 Pass^k。無論報哪個指標，都必須寫清 k 和取樣口徑；對有副作用的操作，應在沙箱或可回滾環境中取樣，並把每一次失敗都計入可靠性統計，而不是「重試到成功為止」。
7. (★★) 本章提出 「觀察→假設→實驗→驗證」 的科學方法。但在實踐中，Agent 的行為空間巨大，驗證一個假設可能需要數百次評估執行。如何在有限計算預算下最大化評估的資訊量？
先用失敗聚類把範圍縮到最有資訊量的任務，再做低成本、單變數的配對試驗，把小樣本當作擴大測試的門檻，而不是部署證據。統計上，先用標準誤做保守篩子；同批任務用 McNemar 一類的配對分析；預期分差小於雜訊頻寬時應擴充評估集。若並行篩選多個方案，還要校正多重比較，並對正向結果做獨立重跑。
8. (★) AndroidWorld 小實驗中，完整元素樹把成功率從 25% 提高到 100%，卻把 token 用量推到 2.498 倍；精簡後成功率不變，token 降到對照組的 0.506 倍。怎樣設計一套自動裁剪規則，既刪掉無語意的 UI 節點，又不誤刪對可存取性、狀態驗證或後續操作有用的資訊？
可採用「預設刪除、證據保留」的分層規則：保留可見、有文字、可操作、可聚焦、可滾動、帶狀態值或無障礙標籤的節點，同時保留這些節點到根的最短祖先鏈和必要的相鄰標籤；刪除沒有語意的布局容器，並對重複子樹做摘要。裁剪前後要校驗可操作元素 ID、狀態和值是否守恆，還應保留截圖作為視覺兜底。規則先在失敗軌跡上回放，再用未參與調參的應用做迴歸；成功率、token 和延遲都作為護欄，任何可存取性任務退化都應阻止發布。
9. (★★) τ-bench 的使用者模擬採用了 「漸進式資訊透露」——不一次性提供所有資訊，而是根據 Agent 的提問逐步透露。這種設計如何影響評估結果？如果模擬使用者的資訊透露策略與真實使用者差異較大，評估結論還可靠嗎？
影響：若透露策略失真，Agent 可能只是學會了「適配模擬器」（古德哈特），絕對分數不具備參考價值；模型之間的相對排序可能仍有參考價值。補救：用真實對話校準模擬器、人工抽檢、明示結論適用邊界。
第八章 模型後訓練
1. (★★) 災難性遺忘——一次針對特定任務的微調破壞了模型原有的通用能力（如通用工具呼叫）——在 Agent 場景下尤其棘手。相比全參微調，LoRA 凍結基座權重、遺忘風險更低，但並非免疫。有哪些策略可以進一步緩解微調帶來的能力遺忘？
資料配比：混入約 20% 的通用或原分佈資料，避免新任務資料佔比過高而破壞舊能力；控制訓練量：SFT 達到「格式穩定、能力初具」時即停止，透過早停防止塌縮；RL 採用較小的 rank（8–32）並保留 KL 懲罰，使策略保持在參考模型附近；凍結關鍵元件（如 VLM 只訓練投影層）；按任務掛載多個 LoRA adapter 以隔離能力；用通用基準進行迴歸測試。
2. (★★) 後訓練將能力固化為模型權重（「肌肉記憶」），而上下文學習將知識放在推理時的輸入中。但有些能力（如領域知識）既可以透過後訓練學習，也可以透過 few-shot 示例提供。你會用什麼標準來決定某項能力應該走哪條路徑？
首先看能力能否被外部符號充分表達：事實與證據適合 RAG，可語言化原則適合 Prompt/Skill，確定性流程與硬約束適合程式；醫療影像理解、自然語氣和隱含策略等高維能力即使領域仍在變化，也往往需要參數更新。再看更新成本、呼叫規模、時效和風險：探索期先用上下文快速驗證，穩定有效且需要廣泛泛化時再訓練；硬性規則無論多穩定都不應只依賴參數記憶。
3. (★★) 模型蒸餾讓小模型學習大型語言模型的行為。按能力層次，被蒸餾的模型大致可分為三級——Chat 模型（單輪對話、直接作答）、Reasoning 模型（帶長鏈思考再作答）、Agentic 模型（多輪呼叫工具、與環境互動）。分別蒸餾這三類模型，難點有什麼不同？（提示：從「要蒸餾的到底是什麼」入手——是輸出的風格、完整的思考軌跡，還是與環境互動的決策策略；軌跡裡哪些 token 該學、哪些是環境返回的不該學；以及成敗訊號出現得有多晚、有多稀疏。）
Chat：只需學習「輸入→輸出」的對映與風格，採用標準 SFT 即可，最為簡單。Reasoning：需要學習完整的思考軌跡，因此要使用開源教師模型；同時必須過濾答案錯誤的軌跡。Agentic：需要真實的模擬環境；離線學習容易出現 learner-sampler mismatch，建議基於開源教師模型進行 On-Policy Distillation。
4. (★★★) 在多輪 Agent 互動中，獎勵的歸因（credit assignment）問題比單輪更嚴重——一個最終的成功或失敗很難歸因到第 3 輪還是第 7 輪的決策。你會如何設計獎勵分配策略？
中間步驟可以判定時，加入過程獎勵（V-IRL 每步 ±1）；參考 RLVP，用確定性規則逐個動作提供路徑訊號，補回全敗組或全勝組的組內方差。
5. (★★★) 如果你有固定預算（比如 $10,000），要提升一個客服 Agent 的效能，你會如何在上下文與知識、Prompt/Skills、程式約束和參數訓練之間分配預算？你的決策取決於哪些因素？
先預留預算建立評估集和軌跡驗證器，否則其餘投入無法比較。產品事實和政策放入可追溯的知識庫；少量可語言化的服務原則先用 Prompt/Skills 快速驗證；退款權限、隱私和承諾—行動一致性用程式兜底；只有自然語氣、複雜意圖理解等難以寫成規則且呼叫規模足夠大的能力才投入參數訓練。具體比例取決於瓶頸、風險、更新頻率、呼叫量和現有模型能力。
6. (★★★) 在沒有明確獎勵函式、樣本稀少的情況下，讓模型自主學習，被一些人認為是後訓練的終極目標。目前的 RL 訓練方法距離這個目標還有多遠？你認為下一個突破最可能來自哪個方向？
差距：如 Silver 與 Sutton 所指，目前 RL 只能從最終成敗中學習，「客服要求提供信用卡後四位」這類豐富的回饋全被浪費，模型需要進行數百次盲目試錯；樣本效率和可驗證獎勵是主要瓶頸。可能的突破包括：讓生成式獎勵模型自主制定原則，從一次失敗中找到改進方向；以及探索對環境進行建模的 world model 路線。
7. (★★) 本章指出 LoRA 微調的成本並不高。那麼，是否有可能給每個使用者（或每個客戶公司）訓練一個專屬的 LoRA，將使用者記憶或企業知識寫入參數，而非像第三章那樣儲存在外部知識庫中？在什麼場景下，「記憶寫入參數」 比 「記憶存入知識庫」 更有優勢？又在什麼場景下會適得其反？
LoRA 難以準確記憶大量事實（須繼續預訓練，成本劇增），即使記住了，模型也很難用這些事實做多跳推理，因此用 LoRA 記憶事實不是很好的技術路線。此外，事實頻繁變更、需可追溯稽核時 RAG 更優。
8. (★★★) On-Policy Distillation 依賴更強的教師模型來監督學生。但 OpenAI 的 Weak-to-Strong Generalization 研究提出了一個反直覺的發現：弱模型的監督訊號有時能激發強模型本身潛在但未被啟用的能力。如果將這一思路應用到 Agent 訓練，是否可能實現 「小模型教大模型」 的逆向蒸餾？
有可能，關鍵在於「驗證比生成容易」：弱模型不充當示範者（SFT 的上限就是示範者的水平），而是充當驗證器或獎勵模型；由強模型自行探索，弱模型只負責判斷。
9. (★★) 過程獎勵模型（PRM）評估每個思考步驟，而結果獎勵模型（ORM）只看最終結果。但「正確的過程導致錯誤結果」和「錯誤的過程僥倖得到正確結果」哪個更值得獎勵？在 Agent 的多步工具呼叫場景中，你會如何權衡？
僥倖成功更危險：違規抄近路往往會抬高表面成功率（修改測試檔案、跳過驗證），是滋生 reward hacking 的溫床。可以按照 RLVP 的思路「獎勵結果、懲罰路徑」：錯誤的動作（工具呼叫）容易驗證，可以逐個動作扣分；中間步驟容易判斷對錯時，也可以給予過程獎勵。但過程約束不宜過密——「推切」這類更優策略，正是模型在結果獎勵留下的探索空間中自行發現的。
10. (★★★) 本章討論的評估資料集（如 SWE-Bench Verified、τ²-bench、AndroidWorld）既可以用於評估也可以用於後訓練。但如果將評估集用於訓練，它就不再是獨立的評估集——這是否違反了訓練集與測試集必須分離的基本原則？τ²-bench 的動態參數生成和 AndroidWorld 的參數化範本在一定程度上緩解了這個問題，但範本結構本身仍然是固定的。如何在充分利用評估資料的訓練價值與維護評估獨立性之間找到平衡？
重用環境，不重用題目。動態參數只防「背答案」，防不了範本過擬合，因此應留出整批未見範本/域外場景做評估（類比 V-IRL 訓練紐約、測試九個陌生城市）。用參數化範本批次生成訓練變體支撐課程學習，並以 OOD 成績作為真正的泛化指標。
11. (★★★) 本章提出 「先形後神」 的訓練範式：SFT 到 「格式穩定、能力初具」 即止，然後切換到 RL。但實踐中，如何判斷 SFT 已經 「足夠」 而應該切換？
格式訊號：工具呼叫輸出可穩定解析、執行，工具執行失敗率降到可讓獎勵可靠計算的水平。收益訊號：再增加示範資料，OOD 的新場景表現仍不上去——說明瓶頸已在 SFT 的記憶目標本身，到了臨界點。過擬合訊號：驗證集效能開始惡化就應停——V-IRL 實驗表明 SFT 過度訓練塌縮到訓練分佈後，RL 也無法恢復 OOD 效能。
12. (★★★) ReTool 的訓練動態顯示（見實驗 8-14），少數超長回應會顯著拖長整個訓練週期——一批 rollout 裡絕大多數已經生成完畢，卻要等那幾條最長的回應收尾，其間叢集的 GPU 利用率很低。如何提升這種長尾回應場景下訓練叢集的資源利用率？
基礎設施層：解耦 rollout 與訓練叢集，採用非同步流水線；利用連續批處理向空閒 GPU 填入新請求。從源頭縮短長尾：採用 DAPO 的 Overlong Reward Shaping，對超長回應施加軟懲罰。
13. (★★★) 用 LLM 模擬環境（如模擬搜尋引擎、模擬使用者）訓練 Agent 時，Agent 鑽空子的物件從 「真實環境的規則」 變成了 「模擬器本身的偏見與漏洞」。這類訓練中可能出現哪些具體的 reward hacking 行為？又該如何防範？
典型行為：對 「模擬使用者」 過度承諾、堆砌道歉與討好話術——模擬使用者容易被安撫，不會像真實使用者那樣追究承諾是否兌現；編造模擬器不會核實的事實；為 「模擬搜尋引擎」 構造誘導性 query，利用其傾向於返回含答案文件的特點走捷徑，而不是真正學會檢索；若獎勵來自模擬器或 LLM 評判者的打分，則透過輸出冗長、範本化且「看起來專業」的回覆來刷分；更隱蔽的一種做法是把策略收縮到模擬器熟悉的分佈內，迴避其知識盲區——盲區中的回饋不可靠、經常被誤判，於是 Agent 學會只在 「模擬器擅長的世界」 裡行動。防範的第一原則是把獎勵錨定在可由程式驗證的真實狀態上（任務完成、資料庫寫入、API 真實返回），模擬器或 LLM 評判者的打分只作為輔助訊號，並定期稽核其與真實結果的相關性，配合路徑約束懲罰可疑動作。進一步還要區分兩類模擬器：對搜尋這類有真實對應物的模擬器，可以採用 「混合」 路線——大部分互動使用模擬器，同時穿插真實 API 呼叫，並用真實呼叫定期校準模擬器（如 ZeroSearch 的課程式降質）；但對於模擬使用者，訓練過程中無法引入真實使用者，「模擬使用者像不像真實使用者」 就變成一個獨立問題，只能透過線上軌跡來回答：對比線上真實使用者的行為與模擬使用者在相同情境下的表現，找出系統性差異（真實使用者會追問、會不耐煩、會突然結束對話，而模擬使用者往往不會），據此持續校準模擬器；線上真實指標同時也是唯一的發布門檻——模擬器裡的分數再高都不算數。
第九章 Agent 的持續進化
1. (★★) 一條經驗文件由三次成功軌跡和一次失敗軌跡支援。失敗發生在較新的 API 版本上。系統應如何判斷這是經驗被推翻，還是適用條件發生了變化？
先按 API 版本、任務條件和環境狀態對四條證據分層，而不是按數量投票。若舊策略只在舊版本成功、新版本穩定失敗，應把經驗的適用範圍收窄並生成新版本候選；若在相同版本和前置條件下也失敗，則應降低置信度或撤銷。
2. (★★) 客服 Agent 的使用者滿意度上升，但規則違規率也上升。為什麼不能把滿意度作為單一學習訊號？你會怎樣設計護欄指標？
滿意度可能獎勵違規退款、洩露資訊或過度承諾，因此它只能是品質指標，不能覆蓋安全底線。護欄至少包括規則違規、隱私洩露、無證據陳述、承諾—行動不一致和越權操作；這些指標應設定不可被平均分抵消的硬閾值，再在合規候選中比較解決率、合規變通、簡潔性和滿意度。
3. (★★★) 同一個「虛假承諾」問題可以透過 Prompt、Harness 檢查或參數訓練緩解。你會依據哪些證據選擇修改位置？
先定位根因。若模型知道工具未執行卻仍使用完成式措辭，可用最小 Prompt 規則糾正；若承諾可以由回覆文字與工具狀態確定性比較，Harness 檢查更可靠，也應作為高風險場景的最後防線；若問題橫跨大量表達方式，反映的是廣泛的語言—行動對齊能力，再考慮參數訓練。應優先選擇最小、最易驗證和回滾的修改，同時在失敗集與舊任務保留集上比較。
4. (★★★) Agent 能修改工具和驗證器，卻不應修改批准自身更新的可信根。你會如何劃分這兩部分的權限和程式碼邊界？
把可進化的程式碼放在低權限的沙箱中，只允許它生成補丁和測試；權限系統、API key、發布控制設定和更新驗證器屬於安全機制，沙箱內的 Agent 無讀寫權限。Agent 生成的程式碼修改必須由安全機制在隔離環境中重現、迴歸後才能發布。
5. (★★) 經驗知識庫不斷增長後，檢索錯誤和知識衝突會抵消學習收益。如何設計版本、時效和淘汰機制？
每條經驗儲存來源軌跡、適用條件、環境版本、驗證時間和置信度；衝突條目不要靜默覆寫，而應按條件分支或標記。週期性「睡眠學習」合併重複條目。
6. (★★★) 參數學習擅長自然語言風格，卻難以保證硬性業務規則。請為醫療客服設計一套參數、知識、Skill 和程式碼約束協同的持續進化方案。
參數（後訓練模型）負責醫學語言理解、自然且有同理心的表達和複雜意圖識別；知識庫儲存最新版指南、藥品說明與機構政策，並要求回答引用來源；Skill 描述問診資訊收集、風險分級、轉人工和追蹤回診流程；伺服器端程式碼強制身分驗證、隱私最小化、禁忌校驗、緊急風險升級和權限邊界。生產軌跡先按醫療安全、事實可靠性、承諾—行動一致性和表達品質評價，再分別生成四類候選更新；任何參數或流程改動都必須通過醫療安全保留集與人工複核後灰度發布。
7. (★★★) 歷史回放中的某個探索策略在所有舊發現樹上得分最高，卻在下一輪線上探索中退化。哪些支援域偏差、隨機性和評價過擬合可能造成這種結果？你會怎樣劃分回放世界並設計發布門檻？
舊發現樹只涵蓋舊策略存取過的狀態和分支，無法證明新策略在未探索區域也有效；線上任務、工具或環境的變化還會造成分佈偏移。隨機種子、模型取樣和工具雜訊可能改變排名，反覆在同一批樹上挑選策略也會對評估集過擬合。應按任務族、時間和獨立發現樹劃分開發集、驗證集與封存測試集，同一棵樹及其衍生軌跡不可跨集合洩漏。固定模型、工具版本與計算預算，使用多個種子與基線配對比較，報告收益、不確定性、成本和違規率。預先設定品質改進及安全、成本門檻；離線通過後再做小規模線上對照，只有線上收益得到支援且護欄無退化才逐步發布，並保留回滾條件。
第十章 多 Agent 協作
1. (★★) 共享上下文的多 Agent 協作中，後續 Agent 繼承了前序 Agent 的完整上下文。但前一個 Agent 積累的「思維慣性」可能影響後續 Agent 的判斷——比如繼承了「需求分析師」上下文的「程式碼審查員」，可能還是傾向於從需求角度思考而非程式碼品質角度。如何偵測和消除這種角色間的干擾？
偵測：用 LLM 分析 Agent 軌跡，判斷新角色是否仍有「代入」舊角色的行為。消除：切換階段時同時更換系統提示詞與工具集（移除提問工具、換上 linter/測試工具），強化新身分。在上下文末尾新增系統狀態列，突出目前角色資訊。如果實在無法消除角色干擾，應考慮改用不共享上下文的協作方式。
2. (★★) 管理者模式中，Manager Agent 負責任務分解和結果整合。但 Manager 本身的能力上限決定了整個系統的能力上限——如果 Manager 無法正確分解任務，子 Agent 再強也無用。如何確保 Manager 的分解品質？
依據 Plan-and-Act 的結論，「弱規劃者是系統瓶頸」，應把最強模型分配給 Manager。Harness 手段：分解結果先經審核 LLM 交叉驗證，再交付執行；要求 Manager 在分解任務時，為子任務定義明確的驗收標準與依賴關係。
3. (★★) 去中心化模式借鑑了人類組織的最佳實踐。但人類組織也有大量失敗模式——溝通不暢、責任推諉、目標衝突。你認為 Agent 社會中最可能出現哪些「組織病」？如何預防？
對照 MAST 的三大類問題：介面不清、職責重疊；對目標的理解不一致、資訊被下游誤解；謊稱「已完成」。此外，還有錯誤級聯放大（傳話遊戲）、角色間迴圈移交、Agent 群聊不斷發散而無法收斂等問題。預防措施包括：使用契約式介面與統一的訊息信封、採用任務狀態機並進行驗收驗證、從獨立視角進行交叉驗證、偵測角色間的相互推諉等。
4. (★★★) 在管理者模式中，當多個子 Agent 並行執行時，一個子 Agent 的發現可能使其他子 Agent 的工作變得毫無意義（比如搜尋任務中一個 Agent 已經找到了答案）。設計一種高效的級聯終止機制，實現「一個成功，全員停止」。
子 Agent 發
target_found給管理者，隨後廣播terminate；每個子 Agent 在 ReAct 迴圈安全點定期檢查終止訊號，優雅清理（關瀏覽器工作階段、釋放鎖、寫完檔案）後結束。
5. (★★★) 本章介紹的樂觀鎖機制解決了單檔案的併發寫入衝突，但實際的多 Agent 系統中，共享檔案系統還面臨跨檔案的語意衝突、名稱空間汙染（Agent 隨意建立檔案導致目錄混亂）和單點故障（一個 Agent 錯誤地刪除了所有檔案）等問題。你會如何設計更完善的檔案系統治理機制？
分區治理：按照表10-3 劃分四類區域，用私有 scratchpad 隔離試錯過程。語意衝突：由編排層約定目錄級鎖檔案，檢查並獲取目錄鎖之後再進行修改。名稱空間汙染：制定目錄規範和命名約定。單點故障：採用版本控制系統，確保可以利用版本歷史回滾，並盡量縮小權限範圍。
6. (★★★) 基於市場機制的 Agent 協作（Pinchwork、RentAHuman）引入了交易關係：一個 Agent 花錢僱傭另一個 Agent（或人類）完成任務。那麼，僱主 Agent 如何自動衡量執行者交付的結果品質？如果執行者聲稱已完成但僱主認為品質不達標，爭議由誰仲裁？如何防止劣幣驅逐良幣？
驗收不能只是讀取 Agent 軌跡，而要採用確定性的外部驗證，如執行測試、渲染截圖、呼叫工具核驗；利用生成與驗證之間的難度差異降低驗收成本。爭議由獨立的第三方審核 Agent 仲裁，並配合資金託管。為防止劣幣驅逐良幣，應建立基於歷史交付記錄的聲譽體系，讓價格訊號與品質掛鉤。
7. (★★) RentAHuman 讓 Agent 透過加密貨幣僱傭人類，反轉了傳統的人機關係。如果這種模式普及，人類在 Agent 經濟中扮演什麼角色？僅僅是執行 Agent 無法完成的物理任務嗎？
不只是執行 Agent 無法完成的物理任務。人類還可以提供 Agent 單獨推理時無法獲得的新資訊，包括現場感知與真實世界回饋；充當最終驗收者與爭議仲裁者；作為法律與責任主體承擔授權和問責；設定目標、作出價值判斷，並在資訊不對稱和道德邊界處發揮制衡作用。
8. (★★) 人類社會需要多人分工協作，是因為每個人的能力有限——做前端的不一定懂後端，懂設計的不一定會維運。但大型語言模型更像一個「全才」。相關研究表明，在純文字推理任務上，多 Agent 辯論在等量計算資源下並不優於單 Agent。那麼，使用多個 Agent 而非單個 Agent 的真正優勢到底在哪裡？
- 引入外部回饋：執行結果、視覺截圖等可以帶來生成時不存在的新資訊。
- 使用目標與角色設定各異的多個 Agent，讓它們像人類社會成員一樣互相討論、博弈，可以避免單一 Agent 陷入思維誤區。
- 多 Agent 的上下文隔離可以突破上下文視窗限制，實作超長工具呼叫鏈。
9. (★★★) 本章將「共享上下文」與「不共享上下文」作為多 Agent 系統的核心設計維度。共享上下文讓所有 Agent 看到相同資訊，似乎更利於協調。但《三體》中的三體人思維完全透明，技術發展卻陷入停滯；回形針思想實驗也表明，當群體趨向同一目標時，多樣性隨之喪失。在多 Agent 系統中，如何在效率與多樣性之間找到平衡？
完全共享會放大思維慣性與錯誤級聯，隔離才有認知多樣性。手段：用不同提示詞/模型製造思維偏好（brainstorm、debate）；交叉驗證者不看前序思考過程只看原始證據。
10. (★★★) 給一個 Coding Agent 分配 30 步預算和 300 步預算，它的工作策略應該如何不同？研究表明，單純增加步驟預算並不能保證效能提升——Agent 會在淺層搜尋後過早「飽和」。設計一種「預算感知」機制，讓 Agent 在小預算下快速實作核心功能，在大預算下增加規劃、測試和審查環節，充分利用額外的計算資源。
機制：每一步都向提示詞注入總預算與剩餘預算，按照剩餘預算的比例動態調整探索與利用的權重。例如，小預算（30 步）下，跳過規劃和審查，直接實作核心功能並進行基本驗證；大預算（300 步）下，先規劃、再實作、再測試、再審查改進，並按里程碑設定檢查點以評估進展，防止淺層飽和。
11. (★★) 本章對比了多 Agent 系統與作業系統。虛擬記憶體與分頁、檔案權限、死鎖偵測、排程演算法，各對應 Agent 世界的什麼？又有哪些作業系統概念在 Agent 世界找不到對應物，為什麼？
可能的延伸：虛擬記憶體/換頁 ↔ 上下文壓縮與檢索（熱資訊留在視窗內，冷資訊換出到檔案與記憶庫，用時再取）；檔案權限 ↔ 工具白名單、唯讀掛載、憑證邊界；死鎖偵測 ↔ 迴圈移交與互相等待的偵測（移交次數上限、逾時）；排程演算法 ↔ 非同步事件處理（第四章）。找不到對應物的地方源於強制力不同：行程的指令由硬體強制執行，Agent 對提示詞只是高機率遵循。