他們會這樣考你

解剖 Grok Build · 30 道靈魂拷問

協作方法論篇拆的是真實原始碼，這章的問題也最硬核。你說自己懂 Coding Agent，這 30 個問題就是照妖鏡，先自己開口回答，再看框架。

怎麼用這一頁
每道題都標註了提問者。這一章偏底層工程，技術同事的問題也最不留情面。
🎙 面試官想驗證你是真懂，還是在背名詞
👔 老闆要的是解釋和承諾
🛠 技術同事在試探你值不值得信任
每題給出三層：對方在考察什麼 → 答題框架 → 加分點。答不上來的環節，點末尾的課程頁回去補。
Q1技術同事
「你天天說 Coding Agent，它一輪迴圈裡到底發生了什麼？別拿 PPT 那套糊弄我。」
🎯 對方在考察什麼
試探你是把 Agent 當黑盒，還是真的理解執行時。答「大模型加工具迴圈唄」這種一句話就露餡了。對方想聽你順著呼叫鏈，把幾個關鍵元件的分工講清楚。
🧭 答題框架
  1. 從入口講起：用 Grok Build 舉例，真實入口在 main()，按執行分支分發（headless、stdio、leader、互動 TUI），最後都匯到同一個 Agent 宿主。
  2. 三個 Actor 分工：SessionActor 負責 turn 編排，接收命令、啟動待處理 turn、處理完成通知；ChatStateActor 獨佔對話狀態；SamplerActor 負責流式的模型請求。
  3. 隔離單位：每個 Session 跑在獨立 OS 執行緒上，帶自己的 current-thread Tokio runtime 和 LocalSet。會話之間天然隔離，一個卡死拖不垮別人。
  4. 收尾機制：使用者點停止靠 CancellationToken 協作式終止，各 Actor 有序退出，這就是取消邊界。
⭐ 加分點能說出「對話狀態由 ChatStateActor 透過訊息佇列序列獨佔，所以不需要共享鎖」這一句，技術同事會立刻知道你真讀過架構，後面的合作態度都會不一樣。
用這些課程頁組織答案 → 從 main() 到第一輪取樣 Session Actor 與取消邊界 79 個 Workspace 成員
Q2面試官
「Coding Agent 動不動跑幾十輪，上下文很快就滿了。生產級產品是怎麼扛住的？」
🎯 對方在考察什麼
考你對上下文預算的工程化理解。只會說「把歷史壓縮一下」的人露餡：對方想聽觸發閾值、判斷邏輯、預算控制這些真正能用的機制，這是 demo 和產品的分水嶺。
🧭 答題框架
  1. 先給觸發機制：以 Grok Build 為例，預設在上下文使用率達到 85% 時允許自動壓縮。判斷公式是 used × 100 >= context_window × threshold_percent，純整數比較。
  2. 壓縮本身要限時：單次壓縮有 300 秒的牆鐘預算。壓縮是為了救會話，自己耗時失控就本末倒置了。
  3. 講可選能力：memory flush 和 two-pass 預設都關閉。two-pass 開啟後，接近閾值時先在後臺投機摘要歷史前綴，正式壓縮時再把摘要和近期尾部合併總結。
  4. 拔高一層：這些都收在 CompactionPolicy 一個顯式配置物件裡，閾值、壓縮模型、預算全部可調。生產級系統把策略做成配置，demo 把策略寫死在程式碼裡。
⭐ 加分點主動指出 Token 用量是估算值，閾值比較用飽和乘法防溢位、視窗為 0 時直接返回 false。能講到這種邊界處理，說明你看過真實實現，這在 PM 裡鳳毛麟角。
用這些課程頁組織答案 → Compaction：85% 閾值與 two-pass 估算、百分比與嚴格閾值
Q3面試官
「讓你給 Coding Agent 規劃工具集，幾十個工具怎麼管？哪些能直接跑，哪些要使用者點頭？」
🎯 對方在考察什麼
考工具系統的設計能力。張口就說「每個工具單獨配一遍權限」的人露餡了，幾十個工具根本配不過來。對方想聽分類學、預設語義和分層控制這套體系化思路。
🧭 答題框架
  1. 先給分類學：Grok Build 用 ToolKind 列舉給工具定語義種類。讀檔案、搜尋、網頁抓取這類種類預設只讀；編輯、刪除、執行命令這類預設有副作用。
  2. 預設值可覆蓋：is_read_only() 只是種類層的預設語義，具體工具可以用自己的中繼資料覆蓋，分類和個體解耦。
  3. 說清關鍵邊界：只讀分類推不出「自動執行」。最終放行還要過命令規則、沙箱、Hook 和使用者互動批准這幾層，分類只是決策的第一個輸入。
  4. 補上註冊機制：內建工具走靜態註冊表，外部 Toolset 走行程級 Preset 註冊，MCP 工具執行時動態發現。三類來源統一收口，管理成本才不會爆炸。
⭐ 加分點舉 Task 這個反例：子任務聽起來無害，原始碼把它標為非只讀，因為子 Agent 可以執行寫操作。能講出這種邊界 case，說明你真的過了一遍分類表。
用這些課程頁組織答案 → ToolKind 與只讀語義 Toolset Preset 註冊表 實現族、註冊表與動態 MCP
Q4技術同事
「Agent 的記憶，說白了就是把聊天記錄存檔案裡，用的時候 grep 一下吧？」
🎯 對方在考察什麼
挑釁式提問，試探你懂多少檢索工程。順著說「差不多」就掉坑裡了。對方想聽召回路徑、降級策略和排序細節，這些決定記憶系統好不好用。
🧭 答題框架
  1. 先糾正前提：生產級記憶是一條檢索流水線。以 Grok Build 為例，查詢前先同步髒檔案：watcher 監聽 Markdown 變更，搜尋開始時重建對應索引，外部修改才不會丟。
  2. 雙路召回：FTS5 BM25 關鍵詞檢索始終可用，向量 KNN（sqlite-vec）在 embedding 可用時疊加。embedding 失敗只記 warning，自動降級成 FTS-only，整次搜尋照常返回。
  3. 排序有講究：雙路分數各自歸一化後加權合併，再乘時間衰減（session 記憶按半衰期衰減，global 和 workspace 視為長青）、來源權重和訪問增益。
  4. 多樣性可選：MMR 重排預設關閉，開啟後按相關性與 snippet 差異度做貪心重排，最後截斷到 max_results。
⭐ 加分點補一句後臺還有 Dream 機制：空閒門控觸發，用 DreamLock 防併發，後臺整理記憶再寫回。說明記憶系統有讀也有寫維護，你看到的是完整迴圈。
用這些課程頁組織答案 → 從檔案變更到混合排序 Dream 的真實機制 Token 估算與閾值
Q5老闆
「你要推全員用 Coding Agent？它要是把程式碼庫刪了，或者把原始碼傳出去，這責任誰來擔？」
🎯 對方在考察什麼
考期望管理加機制理解。拍胸脯說「絕對安全」的人最危險；只會說「有沙箱」也不夠。對方想聽分層防護的具體方案，以及你敢不敢誠實交代邊界。
🧭 答題框架
  1. 先給結論：風險可控，核心是核心級沙箱。Grok Build 內建五種 Profile：workspace（預設）、devbox、read-only、strict、off，各自訂檔案讀寫和子行程網路的能力集合。
  2. 講機制：約束落在作業系統層，macOS 走 Seatbelt、Linux 走 Landlock。真實邊界看解析後的能力集合，Profile 名字只是方向。
  3. 給推廣方案：按人群配 Profile。程式碼審查用 read-only，高敏感倉庫用 strict，還能配 custom profile 額外 deny 掉 ~/.ssh 這類目錄。專案配置無法悄悄覆蓋全域同名策略，安全底線握在管理員手裡。
  4. 誠實交底：平臺不支援或應用失敗時，沙箱會記錄警告繼續執行。所以要疊加權限審批和 Hook 審計做分層防護，沒有單點銀彈，責任靠制度加機制共擔。
⭐ 加分點主動分清兩層：Hook 是 fail-open 的，Hook 自己崩了工具照跑，所以它只適合提醒和審計；強制性保證必須放在權限層和沙箱。能把這兩層說清楚的人很少。
用這些課程頁組織答案 → 五種沙箱 Profile 從工具請求到受限執行 Hooks：明確 deny 才阻斷
Q6技術同事
「接個 MCP Server 不就是加兩行配置的事？這活你怎麼還給排了一個迭代？」
🎯 對方在考察什麼
反向試探你對生態整合工程量的判斷。以為「協議通了就完了」的 PM，排期一定翻車。對方想聽協議外圍那一堆髒活，你說得越具體，排期越有說服力。
🧭 答題框架
  1. 先對齊角色：Grok Build 是 MCP 客戶端，要同時支援 stdio 和 Streamable HTTP 兩種傳輸，外加 OAuth：憑證存本地 JSON 檔案，檔案鎖配合原子寫防多行程衝突。
  2. 命名與衝突：工具註冊名是 server__tool，雙下劃線恰好出現一次。兩個 Server 各有一個同名工具時，各自拿到不同 ToolId，模型側才不會打架。
  3. 可見性分流：工具多了不能全塞提示詞。禁用的、只給 UI 用的、模型可見的分三路處理，快照加 BM25 索引讓模型按需搜尋工具。
  4. 斷線恢復：狀態事件在 50 毫秒視窗內合併，stdio 重啟按 1 秒、4 秒、16 秒退避，還要靠 client_id 護欄防止舊連線的斷線事件誤刪新連線。
⭐ 加分點一句話收尾：MCP 整合的工程量集中在協議外圍，命名、可見性、身份、狀態合併和恢復策略決定連線能否長期穩定。這就是排一個迭代的原因，技術同事聽完會主動幫你補細節。
用這些課程頁組織答案 → MCP 連線、發現與恢復 動態 MCP 工具 Plugin Marketplace 與信任
Q7面試官
「你研究過 Grok Build 的原始碼？那你告訴我，xAI 為什麼選 Rust？給我一個確定的答案。」
🎯 對方在考察什麼
這題埋了陷阱：「確定的答案」根本不存在。對方在看你有沒有證據邊界意識，會不會把合理解釋包裝成官方事實。張口就替 xAI 代言動機的人，做競品分析也一定摻水。
🧭 答題框架
  1. 先立規矩：把結論分成「原始碼事實」和「課程推斷」兩套標籤。原始碼能證明的：edition 設為 2024、Tokio 1 開啟 full feature、名為 xai-grok-pager 的原生 bin target、release-dist 裡的 LTO 和 panic 配置。
  2. 再給推斷：原生二進位方便把 CLI 和執行時一起交付，所有權和 Send 邊界有助於管理多執行緒會話，強型別適合複雜協議和狀態轉換。這些是基於程式碼形態的解釋，要標明是推斷。
  3. 直接說破：選型背後的組織動機沒寫進原始碼。「xAI 為了效能選 Rust」這種話拿不出倉庫證據，我不會說。
  4. 拔高一層：本章對照表用四級證據分級：原始碼、倉庫文件、官方公開文件、本地快照觀察。證據不夠的格子保留空白，不用推測補齊。
⭐ 加分點面試官要的正是第 3 步。敢在壓力下說「這個問題原始碼回答不了」，比編一個漂亮答案值錢得多，這就是產品經理的證據素養。
用這些課程頁組織答案 → Rust 選型：事實與推斷 證據化對照 工程檢討與證據邊界
Q8技術同事
「用 Rust 寫 Agent 圖什麼？編譯半天，招人還難。我拿 TypeScript 兩週就糊一個出來。」
🎯 對方在考察什麼
試探你是跟風吹 Rust，還是能說出可驗證的工程收益。同時看你敢不敢承認代價，只會捧不會講取捨的 PM，技術團隊不會真心配合。
🧭 答題框架
  1. 先認帳：編譯時間、生命週期約束、學習門檻都是真實代價，原始碼課也是這麼標註的，沒必要嘴硬。
  2. 給可驗證收益：每個 Session 跑獨立 OS 執行緒加 current-thread runtime，所有權和 Send 邊界讓多執行緒會話狀態不靠自覺來管；enum 加 Result 把 Agent、Session、Sampler 的領域邊界建在型別上。
  3. 舉個硬例子：ALL_TOOL_KINDS 有編譯期斷言，長度和 ToolKind 列舉數量對不上直接編譯失敗。新增工具種類必須重新過一遍權限分流決策，這種約束靠 code review 很難兜住。
  4. 收口：原生二進位把 CLI 和執行時一起分發，使用者不用裝依賴。兩週糊出來的是 demo，這套是產品。
⭐ 加分點補一句「多執行緒一定更快」這類話缺少倉庫證據，屬於要標註的推斷。技術同事看到你連自己立場的證據邊界都守，態度會立刻不一樣。
用這些課程頁組織答案 → Rust 選型：事實與推斷 Session Actor 與取消邊界 工程檢討與證據邊界
Q9面試官
「同一個讀檔案工具，你們程式碼裡居然有好幾套實現。這也叫架構？改一個 bug 要改幾遍？」
🎯 對方在考察什麼
考多協議相容的程式碼組織。對方故意把「實現族」說成重複程式碼，看你能不能講清這是名稱空間隔離，以及一條工具從定義到執行的完整流水線。
🧭 答題框架
  1. 先正名：這是按協議劃分的實現族。xai-grok-tools 裡平行放著 grok_build 主產品族、grok_build_concise 精簡族、grok_build_hashline、codex 和 opencode 相容族，memory、lsp、skills 按能力單獨拆模組，namespace 列舉裡還有 MCP 留給執行時外部工具。
  2. 組裝有流水線：ToolRegistryBuilder 負責實現選擇和參數重新命名，finalize(config, context) 產出 FinalizedToolset，裡面裝著 definitions、resources 和 dispatch。
  3. 會話接入一個口：ToolBridge 持有 registry，把工具定義提供給模型，呼叫結果以 ToolOutput 交回會話。MCP 工具執行時經 register_mcp_tools 註冊進同一個 registry，和內建工具共用執行通道。
  4. 回應質疑：相容另一套 harness 是換一族實現的配置問題。真要所有協議共用一份程式碼，相容邏輯會把每個工具都攪成 if 森林，那才是改一個 bug 要改幾遍。
⭐ 加分點提煉一句分層：實現族解決多套協議的程式碼組織，registry 負責組合與執行時註冊，ToolBridge 連線會話。三層各管一事，新加一族協議支援時，執行鏈路一行不用動。
用這些課程頁組織答案 → 實現族與動態 MCP ToolKind 與只讀語義
Q10老闆
「訂閱費一年好幾萬，要不我們自己寫一個 Coding Agent？你評估一下，兩個月能上線嗎？」
🎯 對方在考察什麼
考工程量判斷和期望管理。拍胸脯說能和一口回絕都不合格，老闆要的是一個有數字、有維度、有替代方案的評估。
🧭 答題框架
  1. 先給量級：Grok Build 光 Cargo Workspace 就有 79 個成員，其中 62 個在 codegen 目錄。這是 xAI 做到生產級的真實體量，兩個月能做出來的只有 demo。
  2. 拆九個維度：結課工作臺列了九維決策：入口、狀態併發、模型流、工具合約、上下文記憶、安全、恢復、可觀測、擴充生態。每一維都要給出合約、故障路徑和驗證方式。
  3. 給判斷標準：五條硬約束裡挑兩條問自己：崩潰後能可解釋地恢復嗎？敏感資料落點說得清嗎？答不上來就不該上線。
  4. 給建議：先用成熟產品跑半年，沉澱出我們真實的權限、審計和恢復需求，再評估自研哪一層。全棧自研很難划算，自研某一層可能值。
⭐ 加分點主動提 Grok Build 倉庫是 Apache 2.0 的，可以拿來研究和構建。但它定期從內部 monorepo 單向同步、不收外部 PR，別把它當成現成的社群底座。
用這些課程頁組織答案 → 79 個 Workspace 成員 Coding Agent 設計工作臺 工程檢討與證據邊界
Q11面試官
「你們產品的 system prompt 是怎麼管理的？線上出了怪行為，怎麼排查是哪段指令惹的禍？」
🎯 對方在考察什麼
考 prompt 的工程化管理。答「維護一個大字串模板」的人還停在作坊階段，對方想聽結構化、可檢查、可回放的方案。
🧭 答題框架
  1. 給結構化答案：Grok Build 用 PromptContext 結構體儲存全部渲染輸入，帶 Serialize 和 Deserialize derive，能整體序列化下來檢查。排查看的是資料，猜的成分就少了。
  2. 欄位分三組：版本與模板（version、prompt_mode、audience、build_timestamp_utc），配置與身份（agents_md_files、persona_summaries、role_instructions、memory_enabled），使用者執行環境（os_name、shell_path、working_directory、current_date）。
  3. 渲染分工：TemplateOverride 決定基礎模板，ToolBridge 提供工具狀態和描述，TemplateRenderer 合成各個 section，輸出最終 system prompt。
  4. 更新邊界：Agent 構建後原始碼註釋稱「effectively immutable」，但保留 finalize_prompt 這個顯式入口，更新構建時間戳後重新渲染。
⭐ 加分點點出「可序列化的渲染輸入」是排查 prompt 事故的關鍵：任何一次會話的 prompt 都能還原成一份結構化資料，回放和 diff 都有依據。
用這些課程頁組織答案 → PromptContext 渲染輸入 Agent 的欄位邊界
Q12面試官
「主會話一套提示詞，子 Agent 一套，還要相容別家工具格式。模板體系怎麼設計才不失控？」
🎯 對方在考察什麼
考多模板的產品化方案。答「多寫幾個模板檔案」的人沒想過失控問題，對方想聽一個有限列舉加逃生門的收斂設計。
🧭 答題框架
  1. 給列舉：Grok Build 的 TemplateOverride 只有三個變體：None、Codex、Custom(String)，預設 None。模板選擇被收斂成一個列舉欄位。
  2. None 也有兩套：Primary 會話用標準 base template，Subagent 用對應的緊湊模板，給子會話省 token。
  3. Codex 是相容位：原始碼註釋定義為 apply-patch profile 模板，配合 codex 實現族裡的 apply_patch、read_file、list_dir 這些相容實現，服務另一套工具協議。
  4. Custom 是逃生門：呼叫方直接提供完整模板字串，覆蓋列舉照顧不到的場景。
⭐ 加分點點破模板和工具是配套切換的：切到 Codex 模板的同時，工具也換成對應的相容實現。只換提示詞那半邊，相容出來的是個縫合怪。
用這些課程頁組織答案 → TemplateOverride 三變體 實現族與動態 MCP
Q13技術同事
「我照文件註冊了個自訂 toolset preset，當前會話裡死活找不到。你們這平臺設計有 bug 吧？」
🎯 對方在考察什麼
甩鍋式提問。考你懂不懂註冊表的時序語義和可見性設計，能不能把對方眼裡的「bug」講成有明確理由的設計，並給出排查路徑。
🧭 答題框架
  1. 先給結構：註冊表是行程級的，OnceLock 加 Mutex 包住一個 HashMap，存「名稱到構建函式和可見性」的對映。builder 是 fn() 返回 ToolServerConfig 的函式指標，解析時才呼叫生成配置。
  2. 解釋時序：已經解析過的配置不會回寫。會話配置解析完成之後再註冊，這個會話看不到新 preset；之後新解析的配置才查得到。原始碼註釋明確建議在第一次解析前完成註冊。
  3. 檢查可見性：register_toolset_preset 註冊的是 Public，會進 preset_names 公開列舉；register_internal_toolset_preset 是 Internal，只能按名解析，列舉裡看不到。用列舉去驗證 Internal preset 會誤判成「沒註冊上」。
  4. 給結論：這是啟動一致性設計。晚註冊要是能悄悄改掉已解析的會話配置，那才是真 bug。
⭐ 加分點直接給排查口訣：先確認調的是哪個註冊函式，再確認註冊發生在配置解析之前還是之後，九成問題出在這兩處。技術同事最吃這種「你比我還熟」的回答。
用這些課程頁組織答案 → Toolset Preset 註冊表
Q14面試官
「不同工具的參數名五花八門，file_path、path、directory 混著來。你要做跨工具的展示和資料分析，怎麼辦？」
🎯 對方在考察什麼
考歸一化合約的設計能力。答「寫個對映表」只是開始，對方想聽穩定投影和原始資料怎麼分工，以及合約怎麼演進。
🧭 答題框架
  1. 給方案：Grok Build 把少量穩定語義投影進 x.ai/tool 中繼資料。canonical fields 只有八個：path、offset、limit、command、description、cwd、directory、pattern。
  2. 給合約：CanonicalToolMeta 七個欄位：version、name、kind、namespace、label、read_only、input，TOOL_META_VERSION 是數字 1。展示、遙測和跨工具分析共用這套詞彙。
  3. 說清邊界：input 是投影，可以缺欄位甚至整體省略。grep flags、replace_all 這類非共享欄位會被丟掉，編輯前後文字這種大欄位不進投影，完整資料留在 raw_input。
  4. 講取捨：投影層追求穩定輕量，寧可少欄位也要保證語義跨工具一致；要全量就回 raw_input 拿。
⭐ 加分點version 欄位是給合約演進留的門：今天是 1，欄位語義將來要變時，消費方能按版本區分處理。這是做資料合約的基本功，說出來就是降維打擊。
用這些課程頁組織答案 → Canonical input 穩定投影 ToolKind 與只讀語義
Q15面試官
「85% 才觸發壓縮，萬一一輪工具輸出直接把上下文打爆呢？你的預算機制拿什麼兜底？」
🎯 對方在考察什麼
考閾值之外的邊界思維。只記得 85% 這個數的人答不了這題，對方想聽預留空間、估算來源和防禦性細節。
🧭 答題框架
  1. 先給三個原語：xai-token-estimation 提供 usage_percentage（total 為 0 返回 0，結果封頂 100）、exceeds_threshold（整數交叉相乘，used × 100 >= window × percent，等號即觸發）和 exceeds_threshold_with_headroom。
  2. headroom 是兜底：在百分比閾值之前預留固定 token 空間。視窗 100,000、閾值 85%、headroom 4,000 時，觸發點從 85,000 提前到 81,000，給大輸出留緩衝。
  3. 估算來源分兩路：請求前用本地粗估，UTF-8 位元組數除以 4，單張低解析度圖片固定按 765 token；請求完成後用服務端 usage 校準。百分比函式不管來源，只算呼叫方傳進來的數。
  4. 防禦性細節：乘法用飽和乘法防溢位，headroom 的減法用 saturating_sub，視窗為 0 一律返回 false。
⭐ 加分點當場手算：視窗 128,000、閾值 85%，無 headroom 最早 108,800 觸發；headroom 4,000 時提前到 104,800。算得出來，對方就信你真懂這個公式。
用這些課程頁組織答案 → 估算、百分比與嚴格閾值 Compaction 85% 閾值
Q16面試官
「Agent 的長期記憶越攢越亂，你打算什麼時候整理？做個定時任務半夜跑一遍？」
🎯 對方在考察什麼
考後臺維護任務的工程設計：觸發條件、併發控制、冪等和失敗恢復。「定時任務跑一遍」恰好是最容易翻車的答案。
🧭 答題框架
  1. 觸發講準確：Grok Build 的 Dream 把近期 session 日誌和 MEMORY.md 合併成長期記憶。入口有三個：會話結束、/dream 手動命令、可選的週期檢查。check_interval_secs 預設是 None，週期檢查預設不開，不能說成「空閒必然自動執行」。
  2. 三道門控：enabled 預設 true 但子 Agent 會話直接跳過；min_hours 預設 4，用鎖檔案 mtime 記上次成功時間；min_sessions 預設 3，統計上次整理後修改的 session 檔案並排除當前會話。
  3. 併發與預算：DreamLock 用 .dream-lock 存 PID，是最佳努力鎖，原始碼註釋明說它不保證嚴格互斥，所以整理過程必須容忍重複。輸入截 32K，模型呼叫 30 分鐘超時。
  4. 失敗恢復：模型返回空或沒有 Markdown 標題就不寫不刪；寫 MEMORY.md 失敗調 rollback 恢復舊鎖狀態；寫成功才清理 session，5 分鐘內還活躍的檔案跳過；索引只移除真刪掉的路徑。
⭐ 加分點提煉一句「成功邊界決定清理邊界」：沒確認寫入成功之前，原始 session 一個都不刪，失敗之後隨時能重來。這是所有後臺整理任務的通用設計準則。
用這些課程頁組織答案 → Dream 的真實機制 從檔案變更到混合排序
Q17老闆
「上週讓 Agent 跑的那個重構斷在一半，重來一遍又是一遍錢和時間。就不能接著幹嗎？」
🎯 對方在考察什麼
考恢復機制的產品理解和期望管理。老闆要的是「能接、怎麼接、什麼情況接不了」三段式，含糊說「應該可以」下次翻車還是你背鍋。
🧭 答題框架
  1. 先給結論：能接。子 Agent 支援從已完成的任務恢復，ContextSource::Resumed 會複製原始 transcript 和工具狀態，改到一半的 worktree 優先複用；目錄被清了也沒關係，有 snapshot_ref 能從持久 git ref 重建。
  2. 講身份保護：恢復有校驗，subagent_type 必須和原來一致，Persona 顯式給出時也要一致。模型直接 pin 回原模型，中途換模型的請求會被軟忽略，避免上下文錯位。
  3. 交代接不了的情況：原 transcript 超過目標模型上下文視窗的 80% 會拒絕恢復；transcript 複製失敗也會失敗關閉，系統不會給你一個假裝恢復了的會話。
  4. 管理預期：plan 狀態和訊號不在複製範圍內，接手後計劃要重新確認，這是可靠續跑，不是無縫續播。
⭐ 加分點解釋 80% 上限的用心：恢復回來還要繼續做事，上下文一開始就快滿的話，跑兩輪又得壓縮，體驗反而更差。拒絕是在保護任務品質。
用這些課程頁組織答案 → 子 Agent 四個隔離維度
Q18面試官
「子 Agent 的隔離，你們分幾級？低、中、高？」
🎯 對方在考察什麼
陷阱題。順著「分幾級」答下去就輸了，對方在看你會不會把正交的維度捏成一根軸。真讀過原始碼的人會先糾正問題本身。
🧭 答題框架
  1. 先糾正模型：隔離是四個正交維度，一根「低中高」軸裝不下：上下文來源、身份連續性、工作目錄、檔案改動空間，要分開判斷。
  2. 逐個給列舉：上下文是 ContextSource 的 New 或 Resumed；改動空間是 SubagentIsolationMode 的 None 或 Worktree，列舉裡沒有「sandbox」這個成員；工作目錄按 worktree、override、父目錄的優先順序解析。
  3. 舉組合反例：Resumed 加 None 完全合法，繼承上下文但用父工作區；New 也推不出獨立檔案空間，新會話預設還在父 cwd 裡改檔案。
  4. 補充邊界：公開列舉只有 New 和 Resumed，shell 內部另有 Forked 分支用於從父會話映象上下文，不能把它說成公開列舉成員。
⭐ 加分點點破最常見的混淆：None 描述的是檔案工作空間，跟對話歷史無關。None 模式的子 Agent，上下文視窗照樣是獨立的。能分清這兩件事的人非常少。
用這些課程頁組織答案 → 子 Agent 四個隔離維度 AgentDefinition 與 Persona 合併
Q19面試官
「spawn 參數、role 預設值、persona 預設值都能設定模型，最後聽誰的？」
🎯 對方在考察什麼
考配置合併的精確理解。給一個籠統的整體優先順序排序就露餡了，真實設計是逐欄位級聯，還要先確認欄位在那種結構裡存不存在。
🧭 答題框架
  1. 給級聯順序：逐欄位級聯：spawn 顯式 override 最高，然後 role 預設值，再到 persona 預設值，都沒有就留 None 交給父級繼承。
  2. 強調「逐欄位」：這套優先順序按欄位各自走。model 聽 spawn 的同時，reasoning_effort 可以來自 persona。還要先問欄位存不存在：persona 就不提供 capability_mode。
  3. 給結果結構：解析產物是 EffectiveRuntimeConfig，欄位有 model、reasoning_effort、capability_mode、persona、persona_instructions、role_prompt、isolation 這些。原始碼裡沒有 temperature、max_tokens 和 tools 欄位。
  4. 補 fallback：解析完 shell 還有一層：reasoning_effort 仍為空會讀 AgentDefinition.effort。model 的完整順序是 runtime override、per-agent pin、AgentDefinition.model、父模型繼承。
⭐ 加分點把方法論說出來：「按欄位問優先順序之前，先問欄位存不存在」。很多人背了一套整體排序，一追問 capability 從哪來就當場露餡。
用這些課程頁組織答案 → AgentDefinition 與 Persona 合併
Q20技術同事
「我配了個 PreToolUse hook 攔危險命令，昨天腳本自己崩了，結果命令照跑！你們這安全機制是擺設？」
🎯 對方在考察什麼
考 fail-open 語義。你要能解釋這是有意的取捨，說清阻斷的準確條件，再給出強制保證該放在哪一層。慌著道歉的 PM 會被判定不懂系統。
🧭 答題框架
  1. 先講清語義：這是設計好的 fail-open。Hook 崩潰、超時、退出碼非 0 非 2、stdout 無效，dispatcher 都記警告後放行。原始碼註釋明確要求 Hook 故障不能破壞工具可用性。
  2. 阻斷只有兩條路：返回有效 JSON 且 decision 為 deny；或者沒有有效 JSON 但退出碼是 2。注意 JSON 優先：有效 JSON 寫了 allow，就算退出碼是 2 也攔不住，只記一條衝突警告。
  3. 給正確用法：Hook 適合提醒、審計和可恢復的前置檢查。要強制保證，規則放權限層（deny > ask > allow），系統邊界放沙箱，這兩層不走 fail-open。
  4. 幫他排查：15 個事件裡只有 PreToolUse 的 is_blocking 為真；matcher 是正則加相容別名，配置裡寫 Bash 能命中內部名 run_terminal_command。先確認 matcher 真的命中了。
⭐ 加分點反問一句「要是 Hook 故障就阻斷所有工具，一個寫壞的腳本能讓全公司的 Agent 停擺，你選哪種故障模式」。把兩邊風險擺上檯面，對方自然明白這是取捨。
用這些課程頁組織答案 → Hooks：明確 deny 才阻斷 從工具請求到受限執行
Q21面試官
「Persona 檔案讀不到，spawn 直接中止；role 的 prompt 檔案讀不到，卻繼續跑。為什麼區別對待？」
🎯 對方在考察什麼
超細節題，考你有沒有讀到失敗語義的差異設計。背功能列表的人根本不知道這兩條路徑存在，能講出設計理由的人才算真的搞懂了。
🧭 答題框架
  1. 給事實：請求了 Persona 之後，找不到、內容為空、讀檔案失敗都會寫入 persona_error，spawn 側看到錯誤直接中止建立，失敗關閉。
  2. 對照 role：role 的 prompt_file 讀取失敗只產生 role_prompt_warning，model、reasoning、capability、isolation 照常解析，軟降級。
  3. 講設計理由：Persona 是使用者顯式點名的行為合同，帶 instructions 和輸入輸出契約，靜默丟掉等於換了個人格在做事，風險大；role prompt 是型別層的增強指令，缺了它子 Agent 還是那個型別。
  4. 補合併細節：Persona 的 inline instructions 會合併在檔案內容之前，最終作為 persona 塊進入 prompt。
⭐ 加分點抽象成可遷移的方法論：失敗語義要跟著使用者意圖的強度走。顯式指定的東西失敗要響，預設兜底的東西失敗可以柔。這一句能用在你自己的任何產品評審裡。
用這些課程頁組織答案 → AgentDefinition 與 Persona 合併
Q22面試官
「主會話下面掛十幾個子 Agent 並行跑，你怎麼管它們的生死和結果？」
🎯 對方在考察什麼
考多 Agent 協調層的具體機制。「開多個就行了」是消費者視角，對方想聽生命週期登記、結果等待和取消路徑這套生產者視角。
🧭 答題框架
  1. 給元件：Grok Build 有真實的協調元件 SubagentCoordinator。start_subagent_coordinator 只啟動一次 drain task，所有協調事件收口到一處。
  2. 給事件面：SubagentEvent 有 Spawn、Query、Cancel、ListActive、Completions、Outstanding。每個 Spawn 各自進 spawn_local 非同步任務調 handle_subagent_request，協調器登記 pending、active、completed 三種狀態。
  3. 結果與取消：Query 可以拿即時快照，也可以註冊 block wait slot 等完成；Completions 會 drain 待通知完成項並按 suppress_ids 過濾；Cancel 支援按 subagent ID 或 parent prompt ID，過期的 completed 記錄會被淘汰。
  4. 拔高到組織策略：並行能力來自非同步任務。選單 Agent、主會話加 subagents 還是多成員共享任務，看任務圖：並行收益、依賴關係、上下文複製成本、檔案衝突和彙總責任。
⭐ 加分點提煉模式：「協調器是事件驅動的單一收口」。生死狀態只有一個 owner，查詢和取消都走訊息，從根上避免多處改狀態的競態。
用這些課程頁組織答案 → 多 Agent 的組織方式 子 Agent 四個隔離維度
Q23技術同事
「權限檢查不就是看第一個命令嗎？我 ls && rm -rf 一口氣做完，你那套攔得住？」
🎯 對方在考察什麼
半開玩笑半挑釁，考命令解析的深度。知道逐段檢查的人不多，能說出解析器和保守回退的人更少。答好了他以後不會再拿這類問題逗你。
🧭 答題框架
  1. 正面接招：攔得住。Grok Build 用 tree-sitter-bash 把可安全分解的腳本拆成一個個 plain command，識別 &&、||、分號和管道。每個非 setup 段都要獨立透過安全命令、策略或授權檢查，ls 放行救不了後面的 rm。
  2. wrapper 也算過：解析會遞迴剝離包裝層拿到實際命令，危險前綴名單裡有 rm、chmod、chown、kill 和 git push。
  3. 拆不動就保守：命令替換、複雜控制流這類沒法可靠分解的腳本，整體進保守 prompt，使用者對完整腳本確認一次。
  4. 補後手：就算批准執行，沙箱的能力集合還在。read-only profile 下 workspace 不可寫，rm 到了作業系統那層也寫不動。
⭐ 加分點點出這套設計最容易被低估的地方：按腳本結構做權限決策。用正則匹配命令字串的方案在 shell 語法面前全是洞，語法樹解析才是正解。
用這些課程頁組織答案 → 從工具請求到受限執行 五種沙箱 Profile
Q24面試官
「使用者批准了一次 rm，這個會話之後是不是就能隨便刪檔案了？把你們的授權模型完整講一遍。」
🎯 對方在考察什麼
考授權鏈全貌和兩層邊界。只答「彈窗確認」的人對安全的理解停在 UI 層，對方想聽決策輸入、規則優先順序和沙箱兜底怎麼疊起來。
🧭 答題框架
  1. 先答問題本身：批准只放行本次請求。授權決策的輸入是 AccessKind，工具輸入被解析成 Read、Edit、Bash、MCPTool 這類帶具體路徑和命令的訪問意圖，比 ToolKind 更細。
  2. 走一遍鏈路：plan gate 先攔編輯，PreToolUse hook 可以顯式 deny，然後 permission manager 評估合併後的規則。規則優先順序是 deny > ask > allow，和配置來源順序無關。
  3. 決策快速路徑有序：管理策略的 deny 最先短路，隨後才輪到 yolo pin、session grants、Auto 判定、sandbox Bash auto、只讀安全項，都沒結論才彈窗問使用者。
  4. 補第二層：權限層的 Allow 不擴大作業系統能力。沙箱 active 時，行程仍被能力集合和子行程網路策略框著。權限層決定「能否嘗試」，沙箱層限制「能做到什麼」，疊加才是完整邊界。
⭐ 加分點主動糾正一個流傳很廣的說法：「沙箱內所有寫操作自動批准」是錯的。sandbox fast path 只檢查 Bash，還受 policy_forced_prompt 和 auto_forced_prompt 約束。
用這些課程頁組織答案 → 從工具請求到受限執行 ToolKind 與只讀語義 五種沙箱 Profile
Q25面試官
「安全團隊要全公司統一沙箱策略，專案組又想自己加規則。配置系統怎麼設計才不打架？」
🎯 對方在考察什麼
考配置分層治理：誰能改什麼、衝突聽誰的、怎麼防止專案組悄悄放寬安全底線。這是企業產品繞不開的設計題。
🧭 答題框架
  1. 給合併規則：Grok Build 先讀全域 ~/.grok/sandbox.toml，再讀專案 .grok/sandbox.toml，合併用 entry.or_insert。專案只能新增 profile 名稱，宣告了和全域同名的 profile，全域定義保持生效，專案改不動。
  2. 給擴展方式：專案自訂走 custom profile，預設從 workspace 起步，extends 只能選 workspace、devbox、read-only、strict 四個內建基類，read_only、read_write、deny 往基類上追加。
  3. 給兩條禁令：不能 extends off 和 none，也不能 extends 另一個 custom。禁掉鏈式繼承，安全審計才能沿一條線看清最終能力。
  4. 提醒預設值：custom 要限制子行程網路得顯式寫 restrict_network 為 true，別指望從基類想當然地繼承。
⭐ 加分點點出 entry.or_insert 一行程式碼就是治理模型：先載入的贏。把「全域優先」做成合並語義，比做成審批制度可靠得多，這是用機制代替流程的範例。
用這些課程頁組織答案 → 五種沙箱 Profile
Q26老闆
「團隊想從外掛市場裝一堆社群外掛提效。萬一裡面藏了個惡意的，把我們程式碼偷跑了怎麼辦？」
🎯 對方在考察什麼
考外掛生態的信任設計。只會說「裝之前審查一下」的人扛不住追問，老闆想聽系統層面有幾道閘，以及閘門失效時會發生什麼。
🧭 答題框架
  1. 給三道門：裝了不等於能跑。第一道是來源與路徑，MarketplaceRelativePath 拒絕絕對路徑和父目錄穿越，遠端條目能用 git ref 或 SHA 鎖定內容；第二道是啟用狀態，專案和使用者範圍發現的外掛預設進 disabled 列表；第三道是執行信任，按外掛根目錄逐個授權，記錄寫進 ~/.grok/trusted-plugins。
  2. 講未信任的待遇：skills 和 agents 只能露中繼資料，hooks 不載入、MCP server 不啟動、scripts 不執行。最危險的可執行面全被按住。
  3. 給失敗語義：外掛根目錄 canonicalize 失敗直接按未信任處理，失敗關閉，路徑出問題也不會誤放行。
  4. 落到流程：高危外掛先在 read-only 沙箱裡審閱內容再授信，遠端安裝用 SHA 固定版本，防止上游偷偷換包。
⭐ 加分點給老闆一句能記住的總結：發現、安裝、執行是三層，每層有獨立門檻。惡意外掛要連闖三關，而且第三關預設是關著的。
用這些課程頁組織答案 → Plugin Marketplace 與信任 五種沙箱 Profile
Q27面試官
「使用者接了幾百個 MCP 工具，全塞進提示詞，上下文直接炸了。你怎麼設計？」
🎯 對方在考察什麼
考工具規模化的方案。答「做個開關讓使用者少開點」是在甩鍋給使用者，對方想聽延遲發現這套系統解法。
🧭 答題框架
  1. 給核心思路：工具中繼資料進 ToolMetadataSnapshot（tools、servers、mcp_initialized 三個欄位），配 BM25 索引，不讓幾百個定義常駐提示詞。
  2. 給兩個穩定入口：模型側只暴露 SearchTool 和 UseTool。SearchTool 按關鍵詞搜，參數是 query 加 limit（預設 5），結果按 server 分組，帶描述和 input_schema；UseTool 收 tool_name 和 tool_input，按發現到的 schema 分發執行。
  3. 講穩定性收益：模型的工具列表跨輪次不變，幾百個工具的增刪不沖刷上下文，提示詞快取也友好。
  4. 補分發細節：UseTool 收到合格工具名後走 InnerDispatch 或 managed gateway 呼叫 MCP。模型的用法是先搜到 input_schema，照著 schema 構造 tool_input 再呼叫，發現和執行徹底分開。
⭐ 加分點提 mcp_initialized 這個小欄位：能力發現還沒完成時，搜尋層知道「搜不到」和「還沒準備好」是兩回事，不會給模型一個錯誤的空結果。細節到這一層，沒人再懷疑你。
用這些課程頁組織答案 → 實現族與動態 MCP MCP 連線、發現與恢復
Q28老闆
「既然 xAI 把原始碼開出來了，我們 fork 一份改成內部版，省得從頭寫。行不行？」
🎯 對方在考察什麼
考開源治理邊界的判斷。只看 license 不看釋出模式的人會把公司帶進坑，老闆要的是「可以做什麼、代價是什麼」的完整帳。
🧭 答題框架
  1. 先給可以的部分：Apache 2.0 許可，閱讀、構建、內部改造都有空間，README 也給了原始碼構建入口。
  2. 給三個邊界：倉庫定期從 xAI 內部 monorepo 單向同步，公開樹可能落後於內部主幹；CONTRIBUTING 明確不收外部 PR，我們改的東西合不回上游；根 Cargo.toml 是生成的只讀檔案，直接改會被下次同步覆蓋，要改就改各 crate 自己的清單。
  3. 給平臺帳：受支援的構建主機是 macOS 和 Linux，Windows 屬於 best-effort 且當前未從這個原始碼樹測試過。公司要是 Windows 開發機為主，成本得重估。
  4. 給結論：fork 可行，但要按「長期維護一個分叉」計價，每次上游同步都是一筆合併成本。這和白撿一個產品是兩碼事。
⭐ 加分點補一句本地快照沒有 .git 中繼資料，連「我們拿到的是哪個 commit」都無法核對。技術盡調裡如實寫「無法確認」，這個嚴謹度老闆會記很久。
用這些課程頁組織答案 → 工程檢討與證據邊界 證據化對照
Q29面試官
「換你當面試官，別人交上來一份 Coding Agent 設計方案，你怎麼評分？」
🎯 對方在考察什麼
反向考察。你的評審標準暴露你自己的知識結構：看重什麼、忽略什麼、有沒有體系。只會挑功能毛病的人，評分體系撐不過三個追問。
🧭 答題框架
  1. 給量表：用結課評審的 100 分權重：邊界與 ADR 20 分、合約與狀態機 20 分、安全與恢復 25 分、測試與可觀測 20 分、演示與證據 15 分。安全與恢復權重最高。
  2. 給否決項：四條一票否決：敏感資料落點沒說明、高風險工具缺權限路徑、聲稱崩潰可恢復但沒有測試、引用原始碼給不出檔案路徑。分再高踩了也不過。
  3. 給檢查方法：拿九維決策卡過一遍：入口、狀態併發、模型流、工具合約、上下文記憶、安全、恢復、可觀測、擴展。每個維度要有明確決定、合約、故障路徑和驗證方式。
  4. 說明權重理由：功能是平時能看見的，安全與恢復是出事才看見的。評審就該把權重壓在「出事才看見」的地方。
⭐ 加分點引用一條評審哲學收尾：每項設計決定要能回到一個真實的失敗分支。說不出失敗預設值（停止、降級還是問使用者）的設計，都還停在 PPT 階段。
用這些課程頁組織答案 → Coding Agent 設計工作臺
Q30老闆
「你花這麼多時間啃一個別家的原始碼，說說看，最值錢的收穫是什麼？給我一句話。」
🎯 對方在考察什麼
考提煉能力。從兩萬行細節裡拿得出可複用的產品判斷，這段投入才算有回報。羅列技術名詞等於承認自己白學了。
🧭 答題框架
  1. 先給一句話：生產級 Agent 和 demo 的差距不在模型呼叫，在失敗語義。這套原始碼每一層都明確回答了「這裡壞了怎麼辦」。
  2. 展開三個例子：Hook 故障 fail-open 保工具可用性，Persona 缺失失敗關閉保使用者意圖，外掛路徑解析失敗按未信任處理保安全。三種失敗三種答案，全按風險選的，沒有一刀切。
  3. 第二個收穫：策略全部做成顯式配置物件。CompactionPolicy 五個欄位帶預設值，沙箱是可解析的 Profile，閾值、預算、壓縮模型都可調。demo 把策略寫死在程式碼裡，產品把策略交給配置。
  4. 落到自己的工作：以後評審任何 Agent 功能，我加兩個必答題：這個功能的失敗預設值是什麼？這條策略改起來要不要發版？
⭐ 加分點用具體數字收尾：85% 壓縮閾值、300 秒壓縮預算、1 秒 4 秒 16 秒的重連退避，這些數值全在配置和常量裡躺著，隨時可查可調。魔法數字可審計，本身就是工程成熟度的標誌。
用這些課程頁組織答案 → Coding Agent 設計工作臺 Compaction 85% 閾值 Hooks：明確 deny 才阻斷 Plugin Marketplace 與信任
最後一個建議
這 30 題的正確用法是開口講一遍，對著同事、朋友或者錄音講。這一章的問題最容易檢驗真假：細節說得出來就是真懂，說不出來就是在背結論。講不順的地方，點關聯課程頁回去補上。