Paper Circle 用多代理 LLM 做研究探索

科學文獻的增長速度，已經快到很多研究者跟不上。真正的痛點也不只是「找得到論文」而已。你還要判斷哪些值得看、怎麼分類、怎麼整理成可重用的結構。Paper Circle: An Open-source Multi-agent Research Discovery and Analysis Framework 就是針對這條工作流下手。

這篇論文把研究工作拆成兩條管線：一條負責 discovery，一條負責 analysis。它的目標不是做一個單純的文獻搜尋器，而是把原本很零碎的文獻回顧流程，改造成更有結構、可重現，也更容易自動化的系統。

從摘要看，Paper Circle 想解的不是抽象問題，而是很實際的研究日常：如何有效找文獻、如何評估文獻、如何組織文獻、以及如何把文獻內容轉成可操作的知識。這對做研究的人有用，對做研究工具、內部知識系統、或技術團隊的資訊檢索流程也同樣有參考價值。

它到底想解什麼痛點

這篇論文的出發點很直接。當科學產出越來越多，研究者花在搜尋和篩選的時間也跟著增加。摘要把這個問題描述成：有效發現、評估與綜整文獻，變成一個難以負荷的工作。這種感受對做過系統性回顧、比較多篇方法論、或追蹤某個技術領域演進的人來說，應該都很熟悉。

Paper Circle 想減少的，是文獻工作裡幾個最耗時的環節：找論文、評分、整理、理解。它不是只幫你把搜尋結果列出來，而是希望一路把結果整理成後續可以直接使用的格式。這也是它和一般聊天式研究助理最大的差別。

摘要也把它放進目前很熱的 multi-agent LLM 流派裡。作者提到，近年的多代理大型語言模型，在理解使用者意圖與使用工具方面很有潛力。Paper Circle 的做法，是把這種能力用在研究探索與論文分析，而不是泛用對話。

系統怎麼運作

Paper Circle 的架構分成兩條互補流程。第一條是 Discovery Pipeline。它結合離線與線上檢索，從多個來源抓資料，再透過多準則評分與考慮多樣性的排序，輸出結構化結果。白話一點說，就是它不只想搜尋得廣，還想排序得更聰明，避免結果太重複、太單一。

第二條是 Analysis Pipeline。它不把論文當成一大段純文字，而是把內容轉成結構化知識圖譜。這個圖譜使用有型別的節點，像是 concepts、methods、experiments、figures。這種設計的重點，是讓系統可以對論文內容做更細的推理，而不是只產生一段摘要。

摘要也提到，知識圖譜可以支援 graph-aware question answering 和 coverage verification。意思是，系統不只可以拿圖譜來回答問題，還能檢查重要內容有沒有被涵蓋到。對文獻分析來說，這比單純摘要更接近「可檢查、可追蹤」的工作方式。

這兩條管線都建在 coder LLM-based 的 multi-agent orchestration framework 裡。摘要沒有把每個 agent 的提示詞或互動細節全部展開，但架構意圖很清楚：不同 agent 負責不同步驟，讓搜尋、排序、抽取、分析分工處理，再把結果同步起來。

這種同步也很實用。因為 Paper Circle 在每個 agent 步驟都會輸出多種格式，包括 JSON、CSV、BibTeX、Markdown 和 HTML。對工程師來說，這代表它不是只做展示，而是有考慮到後續整合：可以接資料庫、接 citation flow、接網頁介面，也可以接內部報表或自動化管線。

論文證明了什麼

摘要明確說，Paper Circle 對兩個任務做了 benchmark：paper retrieval 和 paper review generation。使用的指標是 hit rate、MRR、以及 Recall at K。這些都是很標準的檢索導向評估方式，方向合理，也符合它的任務設定。

但摘要沒有公開完整 benchmark 數字，所以沒辦法只靠這段文字判斷提升幅度有多大。也就是說，我們知道它有做評估、也知道它用了哪些指標，但看不到具體分數。這點對想比較不同工具的人來說，是目前最明顯的資訊缺口。

摘要另外給了一個很重要的訊號：結果顯示，隨著 agent 模型變強，系統表現也會持續改善。這代表 Paper Circle 的效果，不只是來自流程設計，也跟底層代理模型能力有關。換句話說，框架本身有用，但模型選擇仍然是關鍵變因。

除了評估結果，這篇論文還把系統架構、agent 角色、檢索與評分方法、知識圖譜 schema，以及 evaluation interfaces 都講了出來。從摘要能看出來，它不是一個只停留在概念層的想法，而是一個完整工作流的設計，並且強調有公開釋出。

知識圖譜 schema 也是這篇的核心貢獻之一。把論文拆成 concepts、methods、experiments、figures 這類有型別節點，代表系統可以用比純文字摘要更機器可讀的方式表達內容。這對後續做問答、比對、覆蓋檢查，都是很實際的基礎。

對開發者有什麼影響

如果你在做研究工具、企業內部知識搜尋，或是面向技術團隊的文獻助手，Paper Circle 提供了一個很清楚的設計方向：把搜尋、排序、抽取、分析拆成多個 agent，各自負責一段流程。這通常比把所有事情塞進單一大 prompt 更容易除錯，也更容易擴充。

尤其是 structured outputs 這件事，很值得注意。JSON、CSV、BibTeX、Markdown、HTML 幾乎涵蓋了從程式整合、引用管理、文件輸出，到前端展示的常見需求。對開發者來說，這種輸出形式比單純自然語言更容易接進既有系統。

另一個值得借鏡的地方，是分析管線裡的 knowledge graph。很多文獻工具會停在 embedding 搜尋或文字摘要，但這篇論文顯示，若把論文內容轉成有型別節點的圖譜，就能支援更精準的問題與覆蓋檢查。對需要做深度閱讀輔助的產品，這是一個很實用的替代路線。

不過，這也不是沒有代價。多代理系統通常會碰到協調成本、維護成本、以及模型依賴問題。摘要沒有提供延遲、成本、資料來源範圍或失敗模式，所以目前還不能判斷它在真實場景裡有多穩、多快、或多省。

• Discovery pipeline：離線與線上檢索、多準則評分、考慮多樣性的排序
• Analysis pipeline：把論文轉成具型別節點的知識圖譜
• 輸出格式：JSON、CSV、BibTeX、Markdown、HTML
• 評估任務：paper retrieval、paper review generation
• 評估指標：hit rate、MRR、Recall at K

限制與還沒回答的問題

這篇摘要最大的限制，就是沒有公開完整 benchmark 細節。雖然知道它評估了 retrieval 和 review generation，也知道用了哪些指標，但沒有數字就很難比較，也很難判斷改善幅度是否足以支撐實際導入。

摘要也沒有交代資料集大小、涵蓋哪些來源、處理速度、成本、或失敗案例。這些都是多代理 LLM 系統落地時很重要的資訊。因為一旦進到真實工作流，系統可能不是只看準確率，還要看穩定性、可維護性，以及是否會因為代理互動而變得太重。

知識圖譜的實際效果也是一個開放問題。摘要說它能做 question answering 和 coverage verification，但沒有說在不同類型論文上是否都一樣好用，也沒有說要不要額外人工整理。這會直接影響它能不能從 demo 走到日常使用。

即便如此，Paper Circle 的方向還是很清楚：它想把文獻工作做得更結構化、更可重現，也更容易自動化。對開發者來說，這種把研究流程拆解成可組合元件的思路，本身就很值得參考。

摘要最後也提到，這個專案有公開網站與程式碼。雖然我們不能從摘要補充更多外部資訊，但至少可以確認作者是把它當成可檢視、可延伸的框架在釋出。對想研究 multi-agent workflows、檢索排序、或知識抽取的人來說，這會是一個值得追的案例。

總結來說，Paper Circle 不是在回答「LLM 能不能幫你找論文」這種粗問題，而是在處理更實際的下一步：找完之後怎麼評、怎麼整理、怎麼結構化、怎麼讓後續分析真的可用。這正是研究工具最常卡住、但也最有價值的地方。