58同城Agent一面題目流出：先逼你證明「真的做過Agent」，再考SQL怎麼生成

一份58同城Agent開發崗位的一面題目清單，10月18日起在牛客網流傳。發文者形容這場面試是「少有的雙向奔赴的快速結束」，從留言區的反應看，多數人關注的倒不是考題難度，而是58同城這家公司還在招Agent開發這件事本身，有網友留言表示「還以為58都沒了呢」。 把題目單逐條讀完，這場面試的結構其實相當清楚，也值得正在準備Agent相關職缺的求職者對照。

整場面試的主軸：先驗證專案是自己的

題目單的前半段，幾乎全部圍繞發文者履歷上的「數據分析Agent」專案打轉。面試官的問法有一條明確的推進線：描述這個Agent的使用對象、主要功能、解決什麼問題；接著追問，如果不用Agent、正常也能取數，那Agent帶來的價值是什麼。 這一問是整份題目單裡最值得琢磨的。它逼的是商業判斷，不是技術展示。一個只會把檢索增強生成（RAG）和工具調用串起來的求職者，在這裡很容易答成功能清單；能答好的人，得講清楚原流程的人力成本、等待時間或出錯率，Agent省下的是哪一段。 接下來的追問更細：MCP介面對外包含哪些能力、有多少種方法；對外與使用者互動的是不是一個Agent；外層流程控制是不是由Java專案實現、是不是相當於在專案裡做了一個工作流；整個流程怎麼拿到想要的部分，是否在某個節點請求一次模型。 這串問題像剝洋蔥。面試官在確認的只有一件事：這個專案是不是求職者自己動手做的。外包給模型廠商API、用現成框架拼起來的專案，在「流程控制放在哪一層」「哪個節點打模型」這種問題面前很難站得住。這與我們先前整理過的Agent崗面試官親筆題目整理呈現同一個訊號：企業在這輪招募裡最想排除的，是只會調框架、沒碰過工程細節的人。

SQL生成題：Agent職缺裡的傳統工程味

題目單中段出現一道具體的系統設計題：給很多表和需求，生成SQL的整個邏輯是什麼，資料來源和流程控制大概分幾步。 這道題把58同城這類平臺的實際業務場景攤開了。生活服務平臺的數據分析需求，本質是大量非工程人員要從幾十上百張表裡取數。Agent在這裡的價值是把自然語言需求轉成可執行的SQL，但面試官要聽的不是「模型會寫SQL」，而是表結構怎麼餵給模型、schema怎麼檢索、生成結果怎麼驗證、失敗怎麼兜底。這些步驟的分法，直接反映求職者有沒有真的做過資料。 ，這種「AI外皮、資料庫裡子」的考法在近期的面試題目流出裡反覆出現，小紅書PE一面AI全棧考卷也是一半篇幅在問資料庫扛不扛得住。想往Agent方向走的後端工程師，SQL與資料庫基本功仍然是硬門檻。

後半段：JVM、Spring、排序，一樣都沒少

專案問完，面試官轉向第二個專案「生產環境記憶體問題治理」，要求展開說明原因、分析過程和修復方式，並追問最後有沒有調JVM參數，還是只從工程上優化。 再往後是標準的Java後端題組：Spring的動態代理、MySQL的索引、現場手寫一個熟悉的排序演算法（偽代碼或完整代碼皆可）。 還有一條容易被略過的題目：「你有真正自己開發過Agent或寫過Skill嗎？不一定生產，自己練習也行。」這句話的寬容度本身是個訊號。校招生很少有生產環境的Agent經驗，企業真正想聽到的是課外的動手紀錄，哪怕是一個自己寫的小工具。這與TikTok後端一面把主菜換成Agent工程設計的趨勢一致，可參考我們先前的TikTok後端一面題目分析。

從這份題目單能讀出的徵才訊號

綜合來看，58同城這場一面篩選的是「Java工程師底子加真實Agent專案經驗」的組合，兩邊權重沒有明顯偏廢。專案部分驗證真實性與深度，基礎部分驗證工程訓練是否扎實。 對求職者的實際意義有兩層。第一，履歷上寫的Agent專案，要能回答到「哪一層做流程控制、哪個節點請求模型、對外暴露幾個方法」這個顆粒度，否則會在前十分鐘被問穿。第二，「不用Agent也做得到，那價值是什麼」這類問題已經成為固定考法，準備答案時不妨從業務成本與效率的角度想，而不是從模型能力的角度想。 至於留言區「58還在嗎」的疑問，恰好說明這類平臺的技術團隊仍在招募AI方向的工程師，只是考卷上的要求，已經和三年前的生活服務平臺後端面試不太一樣了。