AI 程式開發／代理評測
DeepRepoQA 以蒙地卡羅樹搜尋追蹤跨檔案程式關係，但評分仍依賴 LLM 裁判
DeepRepoQA 不再讓程式代理沿單一路徑搜尋，而是以 MCTS 比較多條程式庫探索分支，再從具行號的證據合成答案。官方在 SWE-QA 報告 4 至 7 個百分點增益，但資料污染、推論成本與有限的跨語言測試仍待驗證。
上海交通大學等機構提出 DeepRepoQA，把程式庫問答從一次向量檢索或單一路徑 ReAct，改寫成最多反覆展開的蒙地卡羅樹搜尋（MCTS）。系統先以 Tree-sitter 解析類別、函式、呼叫與模組關係，同時建立語意向量索引；代理可執行 `FindClass`、`FindFunction`、`FindCodeSnippet`、`SemanticSearch`、`ViewCode` 與 `Finish` 六類動作。
每次探索由感知、規劃、執行及評估四個角色接力：感知模組整理目前路徑和兄弟分支，規劃器提出候選動作，執行器擷取並去除重複程式片段，評估器再以 LLM 產生效用分數及下一步建議，向樹根回傳。論文實驗把每個節點最多展開三個子節點、搜尋上限設為 15 次，最後答案必須附上檔案與行號證據。這種設計的價值在於，代理走錯目錄或只找到相鄰概念時，仍可回到另一分支，而非把早期檢索偏差一路帶到答案。
在 SWE-QA 上，作者稱不同模型骨幹較既有代理提高約 4 至 7 個百分點；GPT-5.1 組合取得 70.06 分，接近 Cursor 的 70.71，並略高於通義靈碼的 69.12。可是這並非修復程式碼的通過率，而是程式庫問答的綜合分數；評估又由三個 LLM 裁判平均，仍可能偏好特定寫作或推理格式。論文亦承認預訓練資料污染風險，跨語言驗證只有三個 Java 專案、30 題。
程式、基線腳本與資料已公開，但目前設定必須提供自訂 LLM 端點及 Voyage embedding API，因此不是完全離線的重現套件。工程團隊下一步應量測樹搜尋增加的 token、延遲與 API 成本，並在未公開的新程式庫、人工核對答案及實際維護任務上重測。