從「1M 上下文也不夠怎麼辦」到LRU手撕：月之暗面這場二面，把Agent工程師的技能拆到最底層

10月中旬，一份「月之暗面 AI Agent 開發二面」的面經在牛客網流傳。發文者自述透過 Kimi 全球大使計畫獲得實習面試機會，上週投遞、隔日即收到面試邀請。題單本身由發文者事後整理，屬於單方面回憶，尚無其他獨立來源交叉核實；但題目的結構性資訊量足夠，值得從招聘篩選成本的角度拆解。

這份題單在考什麼

把三十餘道題目按主題歸類，輪廓相當清楚。第一層是代碼生成的完整流程：用戶輸入到代碼輸出經過哪些步驟、每個環節的輸入輸出是什麼。第二層是長流程的工程極限：上下文超限的具體方案、1M 上下文也不夠時怎麼辦、斷點恢復、狀態一致性、恢復失敗的兜底。第三層是並發與衝突：多 Agent 同時修改同一檔案的鎖設計、鎖粒度、更輕量的替代方案。第四層是傳統後端基本功：MySQL 的 B+ 樹、Redis 快取擊穿與穿透、Redlock 的取捨、冪等 key 的生成。最後收在手撕題，實作 get/put 皆 O(1) 的 LRU Cache，追問泛型、過期時間與執行緒安全。

值得注意的細節是面試官對答案品質的壓力測試。發文者回憶，「說具體的工程方案，不要只說摘要」「為什麼不讓大模型生成冪等 key」這類追問貫穿全場，第 4 題「1M 也不夠怎麼辦」以及第 21 題「索引在硬碟還是記憶體」是兩個明顯的卡點。

篩選成本怎麼算

一家模型公司開出這種題單，反映的是它對「Agent 開發工程師」這個職位的定價方式。上下文管理、斷點恢復、多 Agent 衝突控制，這些不是模型能力問題，是把模型包進生產系統時的純工程開銷。換句話說，月之暗面篩的不是會不會調 API 的人，而是能對系統的每一個失敗模式給出工程答案的人。

這個取捨有成本帳可算。一面與二面的面試官時間是稀缺資源，把三十分鐘到一小時集中在極限情境追問，單位時間內能取得的資訊密度高於泛泛的八股問答。發文者自述「上周才投、昨天就收到面試邀請」，若屬實，說明前置履歷篩選已被壓到很短，篩選成本被後移到技術面本身。這與我們先前拆解的字節Agent秋招一面的技能重定價結構相近：大廠把工程師技能的定價權，從履歷上的技術棧清單，移回到現場的追問裡。

傳導：誰受惠、誰承壓

受惠的一方是具備分散式系統基本功又做過 Agent 落地的候選人。題單裡 Redis、B+ 樹、Redlock、冪等設計這幾塊，完全是後端社招的標配考點，意味著傳統後端工程師轉向 Agent 開發的遷移成本，主要落在上下文工程與多 Agent 協作這些新增欄位，資料庫與並發那一欄可以直接沿用。

承壓的一方是把履歷堆滿技術棧名詞的候選人。同頁面上另一篇熱門討論已經點出這個現象：技術棧寫得越多，面試官第一反應是「哪些真是他做的」。題單越深，履歷膨脹的邊際效益越低，因為每一項都可以被一個追問擊穿。

對用人企業而言，這套篩選方式提高了漏抓率：只會講架構不會寫 LRU 的候選人會被手撕環節過濾，但短時間內答得不流暢的實戰型工程師也可能被誤判。發文者自己就在「索引在硬碟還是記憶體」一題上答得磕磕絆絆，換來面試官一聲嘆氣。這是高密度追問式面試的固有代價。這個現象也與百度Agent實習面試的十五題篩選相互印證：Agent 崗位的面試正在集體走向長題單加深追問。

收束

這份題單的可核實事實止於發文者的單方回憶，評論區當時尚無回覆，面試結果未知。但它透露的結構訊號是明確的：模型公司對 Agent 工程師的需求，正在從「會用模型」收斂到「會處理模型的失敗模式」。上下文不夠、服務重啟、鎖競爭、模型服務掛掉後的兜底，每一題對應的都是一筆真實的線上成本。考卷把這些攤開來問，等於提前把這個職位的帳本亮給了市場。