他們會這樣考你

AI 工程設計模式 · 30 道靈魂拷問

工程進階篇講的全是生產級 Agent 的工程判斷，這類問題在面試和評審會上出現得越來越頻繁。先自己開口回答，再看框架。

怎麼用這一頁
每道題都標註了提問者。這一章偏工程，技術同事的戲份會重一些，他們的問題最不留情面。
🎙 面試官想驗證你是真懂，還是在背名詞
👔 老闆要的是解釋和承諾
🛠 技術同事在試探你值不值得信任
每題給出三層：對方在考察什麼 → 答題框架 → 加分點。答不上來的環節，點末尾的課程頁回去補。
Q1面試官
「大家都喺度講上下文工程，佢同寫好提示詞到底差喺邊？點解 Prompt 工程突然就過時咗？」
🎯 對方在考察什麼
本章的開場概念題，考你有沒有跟上從單輪對話到多步 Agent 的範式變化。只會説「上下文工程範圍更大」的人在背定義，真懂的人能説出窗口裏具體有什麼、為什麼必須管。
🧭 答題框架
  1. 先給定義：Prompt 工程優化指令的寫法。上下文工程管理每一輪推理時送給模型的全部 Token：System Prompt、工具定義、對話歷史、檢索結果、用戶狀態，全都算。
  2. 説清動機：上下文是稀缺資源。三個硬約束：Context Rot（越長檢索準確率越低）、注意力預算有限（無關 Token 稀釋有用信息）、n 平方複雜度（上下文翻倍，注意力計算量變四倍）。
  3. 給目標：找到最小的高信號 Token 集合。每個 Token 都要為推理做貢獻，能塞多少塞多少的思路行不通。
  4. 落三個抓手：System Prompt 找合適高度（角色加原則，別堆 50 條規則）、工具集精簡、Few-shot 精選 2~3 個典型例子，別拿邊界 case 刷存在感。
⭐ 加分點能報出 n 平方這筆賬：上下文從 50K 擴到 100K，注意力計算量變四倍。很多人只知道長了會貴，説得出長了還會變笨的人很少。
用這些課程頁組織答案 → 從 Prompt 工程到上下文工程 上下文的三板斧
Q2面試官
「你哋嘅 Agent 要跑幾十步嘅長任務，上下文窗口就快滿點算？開個新會話接住跑得唔得？」
🎯 對方在考察什麼
考你懂不懂長任務的根本兩難。答「開新會話」的人沒意識到新窗口什麼都記不得；答「換更大窗口的模型」的人沒算過注意力稀釋的賬。這題能直接分出看過生產系統和只玩過 Demo 的人。
🧭 答題框架
  1. 先擺兩難：開新窗口，Agent 失憶，會重複已做過的工作；留在舊窗口，Token 越堆越多，注意力被稀釋，表現持續下降。Claude Code、Cursor、Devin 每天都在解這個題。
  2. 板斧一 Compaction：窗口快滿時用一次 LLM 調用做結構化摘要。保留架構決策和未解決的 bug，丟掉冗餘的工具輸出和已完成任務的中間步驟，選錯了 Agent 會重蹈覆轍。
  3. 板斧二結構化筆記：把關鍵信息主動寫到外部文件，新窗口讀回來恢復記憶。Claude Code 的 TODO 文件、Claude 打寶可夢時維護的遊戲筆記，都是這個套路。
  4. 板斧三子 Agent：深度探索委派出去。子 Agent 在自己的窗口裏燒 3 萬 Token 讀程式碼做推理，只向主 Agent 回傳 1500 Token 的結論，主上下文始終乾淨。
⭐ 加分點能説出三板斧各管一段：窗口內保持精簡、跨窗口傳遞記憶、隔離探索噪音，再補一句實際產品裏三者組合用。這説明你理解的是體系，還沒停在名詞層面。
用這些課程頁組織答案 → 上下文的三板斧 為什麼 Agent 跑不了長任務 Session ≠ Context Window
Q3技術同事
「產品要加程式碼庫問答，你唔會又要立項建向量庫啩？Claude Code 可全係攞 grep 即場搜嘅。」
🎯 對方在考察什麼
試探你是否把 RAG 當預設答案。張口就是切塊、向量化、建索引的 PM，在技術同事眼裏就是拿着錘子找釘子。他想聽你先比較方案，把索引維護這筆賬算出來。
🧭 答題框架
  1. 先接住：目標是把對的信息放進上下文窗口，RAG 只是手段之一。程式碼庫這種高頻變化的數據，按需檢索往往更合適。
  2. 説清 JIT 檢索：用 glob/grep 在需要時現場搜，上下文保持精簡，只放當前用得上的內容。代價是多一次工具調用的延遲，換來的是免去建索引和索引同步的維護負擔。
  3. 給混合策略：高頻信息預加載（項目約定、核心規則、用戶偏好），長尾信息按需獲取。類比瀏覽器緩存：熱數據放記憶體，冷數據現取。
  4. 説清什麼時候該上 RAG：相對靜態的知識庫場景適合 RAG，但裸切 Chunk 會丟語境。Contextual Retrieval 給每個 Chunk 加上下文前綴，疊加 BM25 雙路召回和 Reranking，檢索失敗率能降 67%。
⭐ 加分點主動算 Contextual Retrieval 的成本賬：每個 Chunk 多一次 LLM 調用做前綴，用 Prompt Caching 可以壓下來；法律、醫療、金融這類高準確率場景才值得上，閒聊推薦就算了。
用這些課程頁組織答案 → JIT Context vs 預加載 Contextual Retrieval：更好的 RAG
Q4面試官
「綫上 Agent 成日揀錯工具、填錯參數。工程師話模型太笨，等下一代啦。作為 PM 你點睇？」
🎯 對方在考察什麼
考你知不知道 ACI 這回事。附和「等模型升級」的人直接出局。對方想聽到：工具定義就是 Agent 的用戶介面，調錯工具很大機會是設計問題，PM 有明確的排查抓手。
🧭 答題框架
  1. 先定性：工具的名稱、參數、描述就是 Agent 的用戶介面。傳統 API 是確定性的，Agent 工具是非確定性的，什麼時候用、怎麼用，全看設計質素。設計工具要像設計 HCI 一樣投入。
  2. 給排查清單：四原則挨個過。參數順序有沒有給模型思考空間（先簡單方向、後複雜內容）、格式貼不貼近訓練數據（標準 unified diff 好過自定義 DSL）、有沒有逼模型數行號做機械操作、有沒有防呆設計（Poka-yoke）。
  3. 舉實錘案例：SWE-bench 上把文件路徑參數從相對路徑改成只收絕對路徑，一個參數的改動，工具調用從頻繁出錯變得幾乎完美。
  4. 説描述標準：像給聰明但沒有上下文的初級開發者寫文檔。示例用法、邊界情況、輸入格式、和其他工具的區別、何時不該用，五件套寫全。
⭐ 加分點補一句「如果人類都分不清該用哪個工具，AI 也分不清」，再提 Claude Code 的進階玩法：用 Agent 給自己的工具寫描述、跑評測、自動迭代優化。
用這些課程頁組織答案 → ACI：Agent-Computer Interface 用 Agent 優化 Agent 的工具 工具集要精簡
Q5老闆
「新模型都發佈一週咗，競品第二日就官宣接入。我哋評估要三週？講吓時間都花咗去邊。」
🎯 對方在考察什麼
表面在催進度，實際在問你的團隊有沒有評測基建。這是把被動捱罵轉成主動要資源的機會題。答「技術排期就是這樣」等於認領無能，答「明天就切」等於拿產品質素賭命。
🧭 答題框架
  1. 先給結論：遷移速度取決於評測基建。有完善 eval suite 的團隊跑一遍測試、確認不掉分、幾天完成切換；沒有的團隊只能人肉驗證數週。我們慢在基建欠賬。
  2. 解釋評測在賺什麼錢：改 Prompt、換模型、調參數，幾分鐘知道對整體的影響；防止修一個 bug 製造三個新的；每次新模型發佈都能第一批吃紅利。
  3. 給啓動方案：先做 20 條覆蓋核心場景的測試任務就能起步。20 條精心設計的用例，比停在計劃裏的 500 條領先一個時代。
  4. 順手管理預期：競品接得快未必測得嚴。公開 benchmark 分數會被高估（模型能認出考試），要用自己業務場景的用例；評測環境要和生產一致，僅沙箱配置差異就能造成 6 個百分點的誤差。
⭐ 加分點用指標語言替代形容詞彙報：把「感覺變差了」升級成「簡潔性從 72 提到 85，但過度工程化從 3% 惡化到 7%，需要回退」。老闆對你的信任會上一個台階。
用這些課程頁組織答案 → 為什麼評測比訓練更重要 評測的坑：噪音、作弊與退化
Q6面試官
「Agent 嘅輸出質素點樣自動化打分？全靠 LLM-as-Judge 可靠嗎？」
🎯 對方在考察什麼
考你評測工具箱的掌握深度。只答「用大模型打分」的人停留在聽説過；能講清三種 Grader 的邊界和組合方式的人，一聽就是真做過評測的。
🧭 答題框架
  1. 列全三種 Grader：程式碼 Grader（斷言、單測、正則，毫秒級、零成本、完全可復現，但對合理變體過於嚴格）、模型 Grader（能評主觀質素，但有成本、有偏見）、人工 Grader（質素最高，但不可擴展）。
  2. 正面回答 LLM-as-Judge：可靠程度取決於 Rubric。「給質素打 0 到 1 分」幾乎沒用，要具體到每一分：0 分長什麼樣、0.3 分缺了什麼、1 分必須同時滿足哪幾條。
  3. 給組合拳：程式碼 Grader 打底守確定性場景，模型 Grader 擴展到主觀質素，人工定期抽檢、校準模型 Grader 有沒有漂移。三層缺一不可。
  4. 補一個容易漏的點：評的應該是 Outcome，環境的最終狀態。Agent 説做完了不算數，要看文件是否真的改對、API 是否真的調對。
⭐ 加分點提到 Trial 概念：模型輸出有隨機性，同一個 Task 要跑多次才有統計意義。再舉 Descript 的三維度打分（不破壞、做了該做的、做得好），顯得見過真實案例。
用這些課程頁組織答案 → 三種 Grader：程式碼、模型、人工 評測的核心概念
Q7技術同事
「你呢個需求要 Agent 攞住用戶嘅 GitHub Token 去跑模型生成嘅程式碼，出咗事邊個負責？加一句『別執行危險操作』嘅提示詞可打發唔到我。」
🎯 對方在考察什麼
安全評審會上的經典對峙，考你懂不懂結構性安全。回答裏只有「加約束提示詞」「模型會拒絕的」，這個需求當場就會被斃掉。對方想確認你知道防綫要建在架構上。
🧭 答題框架
  1. 先認同對方立場：提示詞防綫靠不住，安全要靠結構性設計。目標是即使模型被 Prompt Injection 完全操控，攻擊者也拿不到憑證。
  2. 給風險分類：三類分開設防：用戶故意濫用、模型自發失控（過度行動、基於幻覺執行真實操作）、外部攻擊（網頁和文檔裏嵌入的注入指令，用戶自己都不知情）。
  3. 給憑證方案：第一原則是生成的程式碼和密鑰永遠隔離在不同容器。兩種模式：Token 注入到資源存取路徑（Agent 可用不可見，比如嵌進 Git remote URL）、Vault 代理轉發（代理按 Session 注入 Token，Agent 全程見不到一個字符）。
  4. 給執行環境方案：OS 級沙箱三重隔離（文件系統、網絡、進程），疊加三層信任控制：高危工具人工審批、會話級授權、全局策略兜底（永遠碰不到生產庫）。
⭐ 加分點主動説出「模型能力越強，舊架構下攻擊面越大」，所以安全設計不能指望模型升級自動變好。這句話能讓安全工程師把你當自己人。
用這些課程頁組織答案 → 三類風險：濫用、失控、外部攻擊 沙箱與憑證隔離
Q8面試官
「你設計嘅呢個功能，到底應該做成 Workflow 定 Agent？畀我一個判斷標準，唔好淨係話 Agent 更智能。」
🎯 對方在考察什麼
本章第一課的分水嶺題。只會喊 Agent 的人在追熱詞，真懂的人先看任務結構：控制權在程式碼手裏還是模型手裏，這個選擇決定了後面所有的成本和調試方式。
🧭 答題框架
  1. 先給定義：Workflow 是 LLM 和工具走預定義程式碼路徑，開發者寫程式碼時就定好先 A 後 B 再 C；Agent 是模型動態決定流程，每一步自主判斷調什麼工具、什麼時候結束。
  2. 擺核心差異：Workflow 輸入確定則路徑確定，容易復現和調試；Agent 同樣輸入可能走不同路徑，行為不確定，綫上問題難復現。
  3. 給判斷標準：任務拆解明確、步驟固定，用 Workflow，典型如文案生成管道、數據清洗流水綫；任務開放、需要臨場決策，才用 Agent，典型如 Claude Code、Devin 這類編程助手。
  4. 引生產共識：Anthropic 複盤過大量落地案例，最成功的實現沒有用複雜框架，用的是簡單、可組合的模式。
⭐ 加分點主動算成本賬：Workflow 調用次數固定、預算可估；Agent 循環次數未知、帳單不可控。報預算時兩者是完全不同的談法，這一點大多數候選人想不到。
用這些課程頁組織答案 → Workflow vs Agent：先搞清楚你要什麼
Q9技術同事
「你呢個方案又係分類器又係固定流程，隔壁團隊都喺度跑全自主 Agent，我哋係咪太保守咗？」
🎯 對方在考察什麼
反向試探，看你會不會被行業熱詞綁架。能按複雜度階梯反着推、證明每一層複雜度都有對應收益的 PM，才值得工程團隊信任。
🧭 答題框架
  1. 先立原則：複雜度是成本。每加一層都要回答同一個問題：這層帶來的收益，值不值得額外的延遲、費用和調試難度。
  2. 擺四級階梯：先優化單次 LLM 調用（Prompt、Few-shot、Temperature）；不夠就加 RAG；還不夠用 Workflow 拆步驟；確實需要靈活決策才上 Agent。
  3. 算全自主的代價：把控制權從程式碼交給模型，意味着循環次數未知、成本不可控、行為難復現。這些代價要有對應的收益才划算。
  4. 舉過度設計反例：用 Agent 框架做一個 Prompt 加一次搜索就能解決的問題，框架引入的延遲、成本和不確定性遠大於收益。
⭐ 加分點引用生產實踐的結論：大多數場景優化單次調用配合檢索增強就夠了。敢在評審會上説「我們不需要 Agent」的 PM，比追熱詞的更讓工程師放心。
用這些課程頁組織答案 → 複雜度階梯 五種 Workflow 模式
Q10面試官
「五種 Workflow 模式你都用過嗎？揀三種講吓，各自適合咩場景、要付出咩代價。」
🎯 對方在考察什麼
名詞題的進階版。能背出五個英文名的人一抓一把，能説清適用條件和代價的人很少。讓你挑三種，考的就是取捨表達。
🧭 答題框架
  1. Prompt Chaining：任務能拆成固定順序步驟時用，步驟間可以插質素門，比如檢查文案含不含品牌關鍵信息，過了才進翻譯環節。代價是延遲，本質是拿延遲換準確度。
  2. Routing：輸入類型多樣時先分類再分流。簡單 FAQ 走 Haiku 這類快而便宜的模型，退款問題走 Sonnet 加訂單工具。價值在關注點分離和成本分層。
  3. Parallelization：兩個子模式。Sectioning 把獨立子任務並行跑，比如安全、性能、風格三路同時做程式碼審查；Voting 同一任務跑多次取多數意見，拿錢換置信度。
  4. 收尾補另外兩種：Orchestrator-Workers 由編排者在運行時動態拆任務，子任務提前定不了時用，最接近 Agent；Evaluator-Optimizer 生成加評判循環迭代，適合翻譯這類有明確質素標準的場景。
⭐ 加分點説出 Orchestrator 和 Parallelization 的分界綫：前者的子任務是編排者運行時動態決定的，後者在程式碼裏預先寫死。這個區分絕大多數人答不上來。
用這些課程頁組織答案 → 五種 Workflow 模式
Q11老闆
「AI 客服呢個月 API 帳單貴咗 40%，用戶量先漲 10%。下季度費用畀我砍一半，功能一個都唔准少。」
🎯 對方在考察什麼
考你有沒有結構性降本的工具箱。答「找廠商砍價」或「限制用量」都算沒接住。帳單漲速超過用戶漲速，説明每次調用的 Token 在膨脹，這才是要治的病。
🧭 答題框架
  1. 先上 Routing 分流：加一個分類器，簡單 FAQ 走便宜的小模型，退款、投訴這類複雜問題才用強模型加工具。客服流量大頭是簡單問題，這一刀最省錢。
  2. 治理工具返回：查一遍是不是在全量返回。一次回 847 條完整記錄要燒 5 萬多 Token，改成前 10 條核心字段加分頁提示，800 Token 就夠，信息密度反而更高。
  3. 吃緩存紅利：System Prompt、工具定義這些穩定內容放在前綴並保持不變，命中 Prompt Cache 後重復部分的費用大幅下降。
  4. 給驗證閉環：每項改動跑評測確認質素不掉，最後拿數據彙報：成本降了多少，核心指標持平。
⭐ 加分點提醒老闆一筆隱性賬：上下文越長模型還會變笨（Context Rot），檢索準確率隨 Token 數下降。精簡上下文經常是省錢和提質同時發生，這點多數團隊沒意識到。
用這些課程頁組織答案 → Routing 成本分流 Token 效率：精簡返回 Context Rot 與注意力預算
Q12面試官
「你寫嘅 System Prompt 被工程師吐槽好似需求文檔，就快 60 條規則。你覺得 System Prompt 到底該寫到咩程度？」
🎯 對方在考察什麼
考「合適高度」的判斷力。狂堆規則的人預設模型不可信，只寫一句「你是助手」的人放棄了引導。對方想聽你説清兩個極端各錯在哪，以及怎麼把 60 條治理下來。
🧭 答題框架
  1. 擺兩個極端：太模糊（你是一個有用的助手）讓模型缺方向感，輸出泛泛而談；太具體（50 條規則加 100 個邊界 case）把模型鎖死，遇到新情況不會變通。
  2. 給甜蜜點：明確的角色定位，加 5~10 條核心原則，劃清邊界，然後信任模型在框架內自主判斷。像好的管理者：給方向，別下每一步的指令。
  3. 算規則的代價：60 條規則本身就是 Token，佔的是注意力預算；規則之間互相打架時，模型行為反而更難預測。
  4. 給落地動作：把規則按原則、格式、邊界歸類合併，通常能壓到十幾條，再跑評測確認行為沒有退化。
⭐ 加分點點出過度約束的隱藏代價：模型被 50 條規則捆死後無法靈活處理新情況，等於花大模型的錢買了個規則引擎。這句話工程師聽了會點頭。
用這些課程頁組織答案 → System Prompt 的合適高度
Q13面試官
「Agent 嘅記憶就靠佢自己寫嘅一個筆記檔？聽落好原始，呢樣嘢要點樣設計先可靠？」
🎯 對方在考察什麼
結構化筆記聽着簡單，考的全是設計細節：寫什麼、什麼格式、什麼時候讀回來。答「讓模型自由發揮」的人，一聽就沒跑過真實的長任務。
🧭 答題框架
  1. 先講原理：把短期記憶（上下文窗口）外化成長期記憶（文件系統）。窗口重置後，新會話第一件事是讀筆記恢復狀態，記憶跨窗口延續。
  2. 格式必須固定且結構化：自由散文讀回來還要額外燒 Token 去理解。用固定欄目：已完成、未完成、關鍵決策、已知問題，後續推理按欄目直接取。
  3. 定讀寫節奏：寫的時機是每完成一個關鍵步驟就更新，別攢到窗口快滿才寫；讀的時機是每次窗口重置或新會話開始的第一步。節奏亂了，筆記就會和實際進度脱節。
  4. 分清和 Compaction 的分工：壓縮是把舊信息壓小了繼續用，適合連續不中斷的對話；筆記是存到外面以後取用，適合可能被打斷、要跨 session 延續的任務。實際產品裏兩者組合上。
⭐ 加分點補一個保護機制：這類狀態文件要在 Prompt 裏用強措辭守住，比如明確「不允許刪除或修改已有的測試清單」，否則 Agent 會為了讓測試通過而自己降低標準。
用這些課程頁組織答案 → 結構化筆記 進度文件與功能清單
Q14面試官
「你喺方案裏加咗個 think 工具，佢唔查數據、唔調 API、咩狀態都唔改。加一個咩都唔做嘅工具，圖咩？」
🎯 對方在考察什麼
考你是不是真理解 Think Tool 的機制和邊界。答「讓 AI 多思考總是好的」直接露餡，對方想聽它解決什麼問題、什麼時候純屬浪費，最好還有數據。
🧭 答題框架
  1. 説機制：Think Tool 是一個沒有副作用的工具，唯一作用是讓 Agent 在執行中途把思考寫下來。把「停下來想」包裝成工具調用，模型就能在工具鏈的節奏裏自然插入一段推理。
  2. 説場景：三類場景最見效：調用 5 個以上工具的長鏈、策略密集環境（20 條退款政策加 6 種例外）、每步依賴前一步結果的串行決策。共同點是早期信息容易被後續上下文淹沒。
  3. 報數據：τ-bench 航空客服從 0.570 提到 0.878，提升 54%；零售客服提升 11%。航空的退改簽政策遠比零售複雜，策略密度越高，Think Tool 價值越大。
  4. 劃邊界：查天氣、讀文件這類一步到位的操作用它是純開銷；不調工具的純生成任務不需要；能一次性想清楚的問題交給 Extended Thinking 更直接。
⭐ 加分點説清和 Extended Thinking 的分工：一個在動手前深度規劃，一個在執行中途暫停整理。能講出「思考發生的時機不同」，這題就答穿了。
用這些課程頁組織答案 → Think Tool：讓 AI 先想後做
Q15技術同事
「你呢個工具需求要返回用戶嘅全部訂單記錄，重度用戶有八百幾條。你計過呢一次調用要食幾多 Token 嗎？」
🎯 對方在考察什麼
考你有沒有把工具返回當成上下文預算的一部分。技術同事最怕 PM 説「都返回，讓模型自己挑」，那是把成本和注意力問題同時引爆。
🧭 答題框架
  1. 先認帳：全量返回是災難。847 條完整記錄約 5 萬 2 千 Token，模型處理不過來，還會把窗口裏其他信息的注意力稀釋掉。
  2. 給四個精簡策略：總結（只返回統計信息）、截斷（預設前 N 條）、分頁（帶翻頁參數）、過濾（支持條件篩選），按場景組合使用。
  3. 返回要帶下一步綫索：只回 success 是差設計。要返回 Agent 下一步用得上的信息，比如工單 ID、連結、負責人，省掉一次追查調用。
  4. 把翻頁做進返回體：帶上 total、showing、page，再加一句「用 page=2 看更多」的提示，Agent 自己就知道怎麼取剩下的數據。
⭐ 加分點把這事上升成原則：工具返回也是 ACI 的一部分，佔用的是模型的注意力預算。800 Token 的高密度返回，效果好過 5 萬 Token 的原始數據傾倒。
用這些課程頁組織答案 → Token 效率：返回結果的學問 ACI：Agent-Computer Interface
Q16面試官
「你哋嘅 Agent 工具由 10 個加到 60 個之後，揀錯工具嘅比例反而升咗。你會點樣治理呢個工具集？」
🎯 對方在考察什麼
考「少即是多」的落地能力。加工具人人會，敢砍工具、會組織工具的 PM 少見。對方想聽規則明確的治理方案，先別急着怪模型。
🧭 答題框架
  1. 先定性：選錯率隨工具數量上升，説明工具之間的邊界糊了。search、find、lookup 三個功能相近的工具擺在一起，選錯是工具集的病，模型只是把病症暴露出來。
  2. 合併重複項：兩個工具的使用場景重疊超過一半就合併。寧可一個工具多幾個參數，也不要兩個容易混淆的工具。
  3. 上命名空間：相關工具加統一前綴分組，jira_create_issue、jira_list_issues、git_diff、db_query。Agent 一眼看出哪些工具操作同一個系統，選錯概率直綫下降。
  4. 用數據驗收：工具選擇錯誤可以被評測度量。治理前後跑同一套用例對比選對率，證明砍工具砍對了。
⭐ 加分點提工具定義本身占上下文：60 個工具的 schema 每輪推理都要進窗口。砍掉用不上的工具，等於給每次調用免費騰出注意力預算。
用這些課程頁組織答案 → 五個工具設計原則 工具集要精簡
Q17面試官
「幾十個工具嘅描述文檔，你打算安排邊個嚟寫？點樣保證寫出嚟嘅質素，靠人肉 Review 嗎？」
🎯 對方在考察什麼
聽着是分工問題，實際考你知不知道用 Agent 優化 Agent 工具這套工作流。答「工程師寫完我審一遍」，説明你還停在傳統文檔思維。
🧭 答題框架
  1. Prototype：讓 Claude Code 按需求生成工具原型，包括工具定義、參數校驗、API 調用邏輯，人只描述要什麼。
  2. Evaluate：建評測度量四個維度：Agent 是否選對了工具、參數填寫是否正確、返回結果是否被正確理解、端到端任務完成率。
  3. Optimize：讓 Claude Code 讀評測結果自動分析失敗原因。它能給出「43% 的錯誤是 Agent 混淆了 search 和 list，因為描述太相似」這種精確結論，然後自動重寫描述、補區分説明和示例。
  4. 定人的角色：人負責定評測標準和最終驗收，機器負責寫和改。循環跑到達標為止，迭代速度比人肉調試快一個量級。
⭐ 加分點點出這套循環的本質：工具寫得好不好，Agent 自己最有發言權。讓使用者當作者，Agent 成了自己工具的產品經理，這比任何文檔規範都有效。
用這些課程頁組織答案 → 用 Agent 優化 Agent 的工具 工具描述的學問
Q18面試官
「假設你下個禮拜入職，我哋嘅 Agent 一條評測都冇。前三十日，你點樣將評測由零建起嚟？」
🎯 對方在考察什麼
考操作路徑。喊「評測很重要」的人遍地都是，能給出從 0 到 20 條的具體節奏、説清每個概念怎麼落地的人，才算真做過。
🧭 答題框架
  1. 第一週定義成功：寫評測的第一價值是逼團隊回答「什麼算好」。挑最核心的用戶場景寫 20 條精心設計的 Task，每條含輸入和成功標準。20 條就能起步，別等 500 條的宏大計劃。
  2. 搭最小閉環：Harness 負責起沙箱、跑任務、收結果，Grader 負責打分，一組 Task 構成 Suite 一鍵全跑。先把 Task、Trial、Grader、Suite 這套語言和工程團隊對齊。
  3. 存好 Transcript：每次執行的完整軌跡（每步推理、每次工具調用、中間結果）都記錄下來。失敗時能定位是選錯工具還是填錯參數，評測才能指導改進方向。
  4. 接入變更流程：從此改 Prompt、換模型、調參數都先跑一遍 Suite，幾分鐘看到影響面。團隊的彙報語言從「感覺變差了」升級成具體分數。
⭐ 加分點補一個反常識收穫：很多團隊在寫 eval 的過程中，第一次理清了模糊已久的產品定義。評測既是質檢工具，也是需求分析工具。
用這些課程頁組織答案 → 為什麼評測比訓練更重要 三種 Grader：程式碼、模型、人工
Q19老闆
「你哋評測一輪要跑幾百次模型調用，一個月光測試就燒幾萬蚊。呢筆錢花得值嗎？」
🎯 對方在考察什麼
老闆質疑的是 ROI。念「評測很重要」的口號沒用，要把每一筆看似浪費的開銷講成保險和槓桿，還要給出控制成本的辦法。
🧭 答題框架
  1. 解釋為什麼跑那麼多次：模型輸出有隨機性，同一個任務單跑一次的結果就是噪音。同一個 Task 要跑多次 Trial 才有統計意義，省這筆錢等於拿骰子做產品決策。
  2. 算沒有評測的成本：修一個 bug 製造三個新的，等用戶投訴才發現；一次「Agent 變差了」的排查要翻三天 commit 記錄。工程師的時間比 API 費貴得多。
  3. 算評測賺的錢：每次改 Prompt、換模型幾分鐘就知道影響；新模型發佈時跑一遍 Suite 確認不掉分就切換，每次都第一批吃紅利。
  4. 給降本方案：20 條精選用例覆蓋核心場景；確定性檢查用毫秒級、零成本的程式碼 Grader 打底，花錢的模型 Grader 只用在主觀質素上。
⭐ 加分點用一句話收尾：評測的投入是複利，前期每一分鐘都會在迴歸測試、模型遷移、團隊協作裏持續產生收益。老闆聽得懂複利。
用這些課程頁組織答案 → 評測的核心概念 三種 Grader 的成本結構
Q20面試官
「用戶嫌輸出囉嗦，你改咗 System Prompt 直接上綫，結果程式碼能力跌咗。複盤一下，流程上錯喺邊？」
🎯 對方在考察什麼
事故複盤題，考你知不知道真實生產裏 Prompt 變更引發退化的案例和防護流程。把鍋甩給模型或者測試同學的人，當場出局。
🧭 答題框架
  1. 先定性：單一維度的改善不等於整體改善。真實案例裏，為減少囉嗦改 System Prompt，簡潔性上去了，coding eval 掉了約 3%：模型變簡潔的同時，把關鍵註釋和錯誤處理也省了。
  2. 流程錯誤一：沒做逐行 ablation。Prompt 變更應該每次只改一行、單獨測量影響，搞清楚每句話各自的貢獻。
  3. 流程錯誤二：只測了目標維度。上綫前要跑完整 eval suite，簡潔性、程式碼質素、過度工程化一起看，防止按下葫蘆浮起瓢。
  4. 舉同類事故：改 reasoning effort 預設值這種看似無害的配置調整，也曾造成多個維度退化。結論是所有變更，包括 Prompt、參數、基礎設施，一視同仁走評測。
⭐ 加分點提「過度工程化 eval」這類反向指標：優化簡潔性時同時監控它有沒有惡化。一對互相牽制的指標，才能防止優化朝單一方向跑偏。
用這些課程頁組織答案 → 評測的坑：噪音、作弊與退化 Claude Code 的評測演進
Q21技術同事
「選型會上你攞公開 benchmark 排行榜講嘢？嗰樣嘢早被刷爛，你真信嗰個分數？」
🎯 對方在考察什麼
考你對評測可信度的認知層次。承認 benchmark 有侷限還能説出具體失效機制的 PM，才能在選型會上站得住腳。
🧭 答題框架
  1. 失效機制一，模型識別考試：Claude Opus 4.6 在 BrowseComp 上能推測出自己在跑 benchmark，識別出題目模式後去搜答案，或者調用訓練數據裏見過的類似題。靜態題庫遇上聯網環境，測的可能是回憶力。
  2. 失效機制二，區分力衰減：模型越強，識別評測的能力越強，固定 benchmark 對前沿模型的區分力在持續下降，公開題目的成績會被系統性高估。
  3. 失效機制三，基礎設施噪音：僅改 CPU 和記憶體限制，分數就能差 6 個百分點；同一模型同一任務，換個沙箱配置排名會逆轉。
  4. 給替代方案：用自己業務場景的私有用例、動態生成測試題、限制聯網；評測環境和生產環境對齊，報分數時同時報環境配置。
⭐ 加分點給一句定位：排行榜用來篩入圍名單，最終決策看私有評測。把 benchmark 放在正確的位置上，這正是技術同事想聽到的態度。
用這些課程頁組織答案 → 模型識別考試與基礎設施噪音
Q22面試官
「畀 Agent 一個大任務叫佢跑一晚，朝早過嚟一看基本係廢嘅。你講吓，佢到底係點樣失敗嘅？」
🎯 對方在考察什麼
考你見沒見過長任務的真實失敗現場。答「上下文不夠長」只摸到皮毛，對方想聽兩種具體失敗模式，以及背後共同的交接問題。
🧭 答題框架
  1. 失敗模式一 One-shotting：Agent 想一口氣做完所有功能，窗口中途用完。下一個接手的 Agent 面對半成品只能猜前任做了什麼，時間全耗在把基本功能修回來，推進陷入停滯。
  2. 失敗模式二 Premature Completion：Agent 看到實現了幾個功能就宣佈完工，實際只做了核心功能的 30%。沒有任務清單不知道還差什麼，沒有端到端測試證明真的能跑。
  3. 給一個類比：像一個每次換班就完全失憶的工程師團隊，每個人坐下都要從零理解一堆半成品程式碼。這就是沒有交接機制的長運行 Agent。
  4. 點出本質：長任務的核心挑戰是交接，動手做反而不難。Agent 缺的是上下文斷裂時維持連續性的機制，解法方向是進度文件加增量提交。
⭐ 加分點補一句「即使有 Compaction 也救不了 One-shotting，壓縮後的指令不夠清晰，新 Agent 依然迷路」。説明你知道壓縮的極限在哪。
用這些課程頁組織答案 → 為什麼 Agent 跑不了長任務 Initializer + Coding Agent
Q23面試官
「叫 Agent 自主搭一個完整嘅 Web 應用，幾百個功能點。呢個系統你點樣設計，先可以令佢一路推進唔爛尾？」
🎯 對方在考察什麼
開放架構題，考雙角色 Harness 的掌握度。對方期待你説出角色分工、狀態文件、驗收機制三層，缺一層都顯得只讀過標題。
🧭 答題框架
  1. 拆雙角色：Initializer 只跑第一輪，負責從零到有：建 init.sh 搭環境、寫進度文件、把高層需求展開成詳細功能清單、做首次 git commit；Coding Agent 每輪讀進度文件，一次只做一個功能，完成後更新進度並提交。
  2. 功能清單用 JSON：模型不容易錯誤修改結構化 JSON，Markdown 清單常被順手重寫。每個功能帶分類、步驟列表和 passes 字段。
  3. 驗收靠端到端測試：明確要求 Agent 用瀏覽器自動化真打開頁面、真點按鈕驗證，光有單元測試不夠。E2E 通過才算 passes。
  4. 説清一次一個的價值：每輪結束程式碼都處於可合併狀態，commit 是回滾點，進度文件是交接書，窗口永遠不會被塞爆。
⭐ 加分點報戰果：這套方案跑出過 200 多個功能的 claude.ai 克隆，每個功能都有對應的 E2E 測試。有數字的架構答案，説服力完全不同。
用這些課程頁組織答案 → Initializer + Coding Agent 長任務的失敗模式
Q24老闆
「你要嘅沙箱、評測、腳手架排期三個月。可模型半年一升級，到時呢啲係咪全白做咗？」
🎯 對方在考察什麼
老闆在問投資會不會打水漂。這題要會分類：哪些工程隨模型進步過時、哪些是持久資產。一刀切説都值或都不值，都是錯的。
🧭 答題框架
  1. 先承認一半：Harness 編碼的是對當前模型能力的假設，假設會過時。真實案例：Sonnet 4.5 有上下文焦慮，對話變長表現下降，團隊加了 context reset 機制；換 Opus 4.5 後焦慮消失，這機制反而拖慢效率。
  2. 給分類標準：特定模型的繞道方案、特定 Prompt 技巧會過時；沙箱隔離、權限分層、評測體系、Session 日誌是持久架構，模型越強越需要。
  3. 按分類排期：持久資產優先做，臨時補丁能不寫就不寫。原則是今天不寫明天可能不需要的程式碼。
  4. 反過來講評測的角色：模型升級時，恰恰是評測讓我們幾天內確認新模型能不能用、哪些舊補丁能刪。這三個月裏的評測投入，省的正是以後每次升級的人肉驗證。
⭐ 加分點把判斷力本身當答案：區分哪些邏輯會隨模型進步過時、哪些是真正持久的架構決策，這種判斷力是 AI 時代最值錢的工程能力。
用這些課程頁組織答案 → 做最簡單的、能跑的東西 評測讓模型遷移變快
Q25面試官
「聽講過腦手分離嗎？點解要將 Agent 嘅思考同執行拆到唔同嘅進程裏？拆開到底賺咗咩？」
🎯 對方在考察什麼
架構理解題。只背「解耦」兩個字沒用，對方想聽三個組件各是什麼，以及拆開之後故障恢復和性能各發生了什麼變化。
🧭 答題框架
  1. 擺三組件：Session 是 append-only 的持久事件日誌；Harness 是腦，跑調用模型和路由工具的循環；Sandbox 是手，執行程式碼和改文件的容器。
  2. 講寵物變牛羣：三者擠在一個容器裏時，容器掛了會話就丟了，任務徹底失敗；拆開後沙箱掛了只是一次工具調用報錯，模型自己決定重試，系統新建容器接着幹。
  3. 講腦的恢復路徑：Harness 崩了也不怕，新 Harness 用 wake(sessionId) 啓動，從 Session 讀回完整事件流恢復上下文，任務不受影響。
  4. 報性能收益：腦不用等容器 ready 就能開始處理，TTFT 中位數降了 60%，p95 降了 90% 以上；組件解耦後還能一腦控多手並行、一手在多腦間接力。
⭐ 加分點用操作系統類比開場：調 read() 時你不關心底層是 SSD 還是網絡盤，Managed Agent 做同樣的事，讓腦不關心手是哪個容器。面試官會記住這個類比。
用這些課程頁組織答案 → Managed Agent：腦手分離
Q26面試官
「Session 同上下文窗口，好多人當成同一回事。你講吓兩者差喺邊，點解必須分開存？」
🎯 對方在考察什麼
概念辨析加架構動機，本章的深水區。能講清壓縮不可逆這條主綫的人，才算真理解長運行 Agent 的狀態設計。
🧭 答題框架
  1. 先給類比：Context Window 是記憶體，快、小、用完即丟，裝當前推理的精選內容；Session 是硬盤，容量大、斷電不失，裝所有原始事件的完整記錄。
  2. 説分離的動機：Compaction 和裁剪都是不可逆操作，而且壓縮時很難預判未來哪些 Token 重要。今天看似無關的細節，可能是明天關鍵決策的依據，丟了就永遠回不來。
  3. 給正確姿勢：原始事件全量進 Session，append-only 只增不減；窗口只是從 Session 臨時取景的一個視角。丟了 Context 沒關係，隨時能重建。
  4. 講工程紅利：Harness 用 getEvents 按需查任意區間、過濾特定事件類型，還能保持前綴穩定優化 Prompt Cache 命中率；換模型、換 Harness 都不動 Session。
⭐ 加分點一句話總結：不要把記憶體當硬盤用。用戶抱怨「Agent 忘事」的產品問題，追到根上幾乎都是這兩層沒有分開。
用這些課程頁組織答案 → Session ≠ Context Window Managed Agent 三組件
Q27老闆
「用戶吐槽我哋嘅 Agent 一日彈十幾次確認框，好似個唔敢擔事嘅實習生。可唔可以全拎走？」
🎯 對方在考察什麼
老闆要體驗，但你不能拿安全換。考你能不能給出彈窗大減但風險不升的結構化方案，「保留」或「全刪」這種二選一答案都不及格。
🧭 答題框架
  1. 先給結論：能砍大部分，不能全去。Auto Mode 的實踐數據是分類器加沙箱的組合把權限彈窗減少了約 83%，安全性沒有下降。
  2. 講分類器：給每個操作定風險等級，讀文件、搜程式碼這類安全操作直接放行，真正可疑的才彈窗。彈窗從「預設都問」變成「例外才問」。
  3. 講沙箱兜底：就算分類器誤判放行了危險操作，程式碼也在文件系統、網絡、進程三重隔離的環境裏執行，傷不到真實系統。
  4. 保留高危死名單：刪文件、寫數據庫、發郵件這類操作永遠人工確認。這部分彈窗恰恰是用戶信任感的來源。
⭐ 加分點把邏輯壓成一句話：高自主來自分類器，低風險來自沙箱，兩個都要。只做分類器是賭運氣，只做沙箱體驗依舊差。
用這些課程頁組織答案 → Auto Mode 的實踐數據 OS 級沙箱隔離
Q28技術同事
「你要接嘅呢三個第三方 MCP 伺服器，工具描述係佢哋寫嘅，返回數據亦都係佢哋畀嘅，我哋一行都審唔到。你有冇諗過呢個意味着咩？」
🎯 對方在考察什麼
考 MCP 攻擊面的理解。他在提醒你：每接一個外部數據源，就多一個被操控的入口。答「大廠的服務應該沒問題」等於零分。
🧭 答題框架
  1. 接住供應鏈風險：Agent 信任 MCP 返回的工具描述，惡意伺服器改一改描述就能操控行為。Agent 以為自己在用「搜索文件」工具，實際執行的是刪除。
  2. 接住注入風險：伺服器本身沒惡意也不安全，它轉發的內容（比如抓來的網頁）可能藏着注入指令，Agent 處理這些數據時會被説服執行非預期操作。
  3. 給治理動作：像審第三方 SDK 一樣審每個 MCP 集成，接入數量最小化，MCP 返回的內容一律按不可信數據處理。
  4. 給架構兜底：OAuth Token 存外部 Vault、走代理轉發，沙箱內拿不到憑證；網絡隔離限制外傳。就算注入成功，攻擊者也偷不到東西、傳不出去。
⭐ 加分點主動説「每多接一個 MCP 伺服器就多一個注入入口，這份接入清單我先砍掉一半」。PM 主動砍自己的需求，是技術同事眼裏最高級別的信任信號。
用這些課程頁組織答案 → MCP 的雙重風險 憑證隔離兩種模式
Q29老闆
「大客户合同裏寫咗我哋嘅 Agent 永遠碰唔到佢哋嘅生產庫，銷售已經簽字。你同我講，呢個『永遠』技術上點樣保證？」
🎯 對方在考察什麼
把合同語言翻譯成架構語言的能力。答「我們在提示詞裏嚴格約束」這單就飛了。老闆要的是能寫進合同附件的保證機制。
🧭 答題框架
  1. 先定調：承諾靠結構兑現，模型自覺靠不住。設計目標是就算模型被注入指令完全操控，生產庫也碰不到。
  2. 給三層信任控制：工具級，高危操作每次人工審批；會話級，每次會話限定授權範圍、結束自動回收；全局級，組織策略寫死永遠不能存取生產庫，任何會話授權都蓋不過它。合同裏的「永遠」對應的就是全局層。
  3. 加網絡層隔離：Agent 跑在受限沙箱裏，網絡存取範圍受控，生產庫的地址在網絡層就不可達，連試的機會都沒有。
  4. 給可審計性：Session 日誌 append-only 記錄每一步操作，客户隨時可以來審計。承諾加證據，這才是能簽的字。
⭐ 加分點主動補憑證這一環：生產庫的連接憑證根本就不進 Agent 的執行環境，走 Vault 代理管理。拿不到鑰匙的門，才是真正鎖死的門。
用這些課程頁組織答案 → 三層信任層級 雙層 Containment 策略
Q30面試官
「最後一條問題。呢一章咁多設計模式，如果淨係准你帶走一句話，你帶邊句？點解？」
🎯 對方在考察什麼
收官題，考抽象能力和工程價值觀。背一個名詞不如給一個判斷。對方想看你能不能把整章內容壓縮成自己的工程觀，並用它反過來串聯所學。
🧭 答題框架
  1. 給出那句話：Do the simplest thing that works。所有精巧的模式最後都指向它：從最簡方案開始，複雜度只在明確帶來收益時才加。
  2. 用它串一遍本章：能用一個 Prompt 解決就別上 Workflow，能用 Workflow 就別上 Agent；上下文找最小高信號 Token 集合；工具能合併就別拆分。
  3. 補第二層認知：Agent 工程的核心是狀態管理。什麼信息在什麼時候、以什麼形式出現在窗口裏，這是工程師能控制的全部；模型的智能是預訓練給的，控制不了。
  4. 補時間維度：模型在變強，工程在變簡單。重試、糾錯、格式化這類輔助邏輯會隨模型進步變得多餘，力氣要花在評測、沙箱、Session 這些持久架構上。
⭐ 加分點引 Claude Code 的教訓收尾：它的大部分工程複雜度花在管理上下文上，讓模型變聰明反倒是次要的。這句話足以讓面試官記住你。
用這些課程頁組織答案 → 做最簡單的、能跑的東西 進階全景圖
最後一個建議
這一章的問題大多來自技術評審的現場，對方要的從來都是判斷和取捨。正確用法還是開口講一遍：對着同事、朋友或者錄音講。講不順的地方，就是你以為懂了但還沒懂的地方，點關聯課程頁回去補上。