面了一輪 Agent 崗之後，面試官把題目全寫出來了：缺的從來不是會用框架的人

牛客網上一位署名「程式設計師花海」的開發者發文，分享他近期替團隊招募 Agent 開發工程師的面試題整理。他前後面了十餘位候選人，最大感想是：履歷上寫「熟悉 LangGraph」「落地過 RAG」的人很多，能把「為什麼這麼選、出了問題怎麼辦、效果怎麼量化」講清楚的很少。

這篇文章值得留意的地方在於，它把 Agent 崗位的真實篩選標準攤開了。對照我們先前整理過的Agent 開發者踩出來的五道工程題，兩份材料指向同一件事：這個領域的門檻已經從「會不會用工具」移到「會不會做判斷」。

第一關：選型判斷，刷人最多的一章

原PO明說，這一章是他必問、也是刷掉最多人的部分。他給出的判斷框架相當樸素：能上 workflow 就別上 Agent，能單 Agent 就別硬拆多 Agent。多 Agent 不是高級，是最後的手段。

他列出的取捨是：workflow 適合步驟固定、流程確定的需求，可預期、成本低、好測試；Agent 適合任務開放、需要動態決策的場景，代價是不可控與 token 開銷；多 Agent 處理角色衝突、需要並行制衡的情境，但得付出通信開銷、死鎖與除錯難度的代價。

面試題包括「Agent、RAG、workflow、微調，四選一怎麼判斷」「你做過最失敗的一次 Agent 設計是什麼」。這種題目沒有標準答案，考的是候選人有沒有真的付過學費。用買車來比喻，會開車的人滿街都是，但能說清楚「這趟路況該租車、該搭高鐵還是該走路」的人，才是真正跑過不同路線的人。

第二部分的題目圍繞框架與底層設計：LangChain、LangGraph、CrewAI、AutoGen 怎麼選；LangGraph 的節點、邊、條件邊怎麼設計；Agent 跑到一半行程掛了怎麼恢復；多實例同時處理同一個會話，狀態怎麼不打架。

原PO的篩選邏輯很實際：不要求背 API，只想聽有沒有真實落地的判斷。能說出 checkpoint 存什麼、怎麼序列化、多實例怎麼鎖的，基本就是真做過。

這與AI 編程工具兩年內換了一批人描述的現象互為表裡：工具汰換速度太快，履歷上的框架名稱貶值極快，真正保值的是框架底下的狀態管理與錯誤恢復這類工程常識。

第三部分問的是實務災難現場。死循環怎麼防，除了 max_iterations 還有什麼；使用者點停止生成，後端怎麼真正把推理停下來；審批流程的暫停與恢復怎麼設計；流式輸出斷線重連，上下文怎麼恢復；重試、熔斷、冪等在 Agent 場景下怎麼做。

原PO提到，死循環這題能答出狀態哈希去重、工具調用指紋、分階段預算的候選人，他會建議對方把履歷裡 Agent 那段標粗。這三個名詞翻譯成日常語言：發現機器人在原地打轉就記下「這個狀態我看過了」、記下「這個工具用同樣參數調過了」、並且事先給每個階段發有限的點數，花完就停。

後面幾章涵蓋多 Agent 協作（通信協議、共享狀態還是訊息傳遞、互相等待怎麼解）、對齊訓練（RLHF 完整流程、DPO 為什麼可以不要獎勵模型、線上點讚點踩怎麼變成訓練資料）、幻覺分類與度量、以及評測體系。

評測部分他給出了明確的分層：工具調用級、任務級、系統級三層。能把 badcase 歸因到檢索、工具、模型、產品四個層面的候選人，他說基本直接給過。他也點出 LLM-as-judge 有坑、上線前怎麼灰度，這些都是目前業界還在摸索的開放題。

最後一章是他近期面試必問的資安題：prompt injection 為什麼防不住、縱深防禦怎麼做、RAG 投毒的攻擊路徑、Agent 被誘導調用危險工具怎麼辦、敏感資料怎麼防外洩。來源內文在此處截斷，但題目方向已經足夠清楚：他把資安視為 Agent 崗位的新必修，而非附加分。

對求職者，這份題單等於一份免費的自我檢核表。把每一題當成「我能不能用自己的專案回答」來檢驗，答不出來的段落就是履歷上不該寫粗體的段落。

對用人主管，它照出一個結構問題：Agent 崗的篩選成本極高，因為市面上「上過課、跑通過 demo」的人遠多於「扛過 production 事故」的人。面試題往「為什麼這樣選、出事怎麼辦、效果怎麼量化」這三個方向設計，比考框架 API 有效得多。這份題單本身，就是那個篩選邏輯的公開版本。