研究代理程式在讀完每個頁面的前 8,000 個字元後，就能完成一份報告。如果其網頁工具在來源中途截斷，而代理程式自行補齊空缺，您就會得到一個完成的執行，卻帶有未經證實的主張。
在成千上萬次執行中，您需要找出受影響的工作階段，以及它們的共同點。LiteLLM Lens 使用代理程式來完成這項工作。
以下說明其幕後運作方式：審查者會平行檢視執行結果，分組代理程式會連結相關觀察，而調查員會將每個候選模式與原始追蹤結果比對。
第 1 階段：審查每次執行
我們為每次執行配置各自的審查者，並平行執行這些審查者。每個審查者都能完整檢視一個執行，因為在一開始附近的工具回應，可能解釋了數百步之後的錯誤答案。
審查者會決定要讀什麼，並沿著工具結果與子代理程式交接追蹤線索。它會持續進行，直到有觀察結果可回傳；如果需要比對，也可以開啟其他選定的執行。
在研究範例中，審查者可能注意到某個頁面在句子中途結尾，而最終答案包含了返回文字無法支持的主張。它會用引文記錄所發現的內容，並保留原因以待調查。
我們要求審查者同時檢視過程與結果。某個代理程式可能先嘗試一個不相容的 grep 工具五次，之後才透過終端成功。我們希望即使代理程式完成了任務，這些失敗嘗試也能保持在視野中。
審查者可以使用 Python
我們為審查者提供一個工作區，其中包含追蹤結果與檢視它們的工具，就像一個在儲存庫中工作的程式碼代理程式。他們可以閱讀並搜尋證據，或撰寫 Python 來回答需要計算的問題。
在研究範例中，審查者可以撰寫一個簡短腳本來比較回應長度，並找出在相同位置停止的頁面。它會利用這些測量結果決定要開啟哪些回應，以及要檢查哪些主張。它也可以用同樣的方法來計算重複失敗次數，或重建一連串子代理程式呼叫。
追蹤結果保留在工作區中，而審查者會將所需段落或計算結果帶入模型的上下文。追蹤可以大於上下文視窗，因為代理程式可以分段搜尋並分析。
Python 會在沒有網路存取的受限環境中執行。隨著調查擴大，代理程式可以將對話濃縮為工作筆記，並在需要時回到較早的證據。
第 2 階段：分組相關觀察
多位審查者可能會標示出同一個潛在問題。我們以平行批次分組其觀察結果，然後跨批次合併匹配項目，讓調查員可以一起檢視這些範例。
我們依據檢查項目與疑似原因來分組。缺少 PDF 工具需要的修正，和 PDF 轉譯器故障需要的修正不同，因此它們應保持為不同的候選項目。
對於頁面截斷的範例，我們會把關於突然結尾與未經支持主張的觀察，收集成一個關於來源內容缺失的候選項目。調查員會取得來自不同執行的範例，並附上其證據連結，然後判斷是否有單一解釋能同時說明它們。
第 3 階段：調查候選項目
我們會為每個候選項目啟動一位調查員，並平行執行這些代理程式。他們會取得審查者的觀察結果，以及原始追蹤的存取權，並具備相同的讀取、搜尋與 Python 工具。
我們把調查員帶回原始追蹤，因為審查者可能略去了會改變解釋的上下文。在研究案例中，調查員會比較頁面回應與最終主張。他也會尋找反例，例如代理程式承認資訊不足，或擷取了來源其餘部分的執行。
當不同頁面反覆精確回傳 8,000 個字元時，這表示工具可能在固定限制處將其截斷。調查員仍需要確認缺失內容是否能解釋錯誤主張，並將該證據與合理推測區分開來。
調查員可以捨棄站不住腳的候選項目。在儲存發現之前，工作者會根據來源檢查其引文，並將無效引文送回修正。精確引文仍可能支持錯誤解讀，因此我們也在評估中檢查這項區別。
在真實追蹤上檢查設計
在一個包含 350 個跨度的真實程式碼代理程式工作階段中，審查者與調查員使用 Python 檢查驗證命令。他們發現某些檢查經由 tail 傳送，即使底層檢查失敗，也仍回報成功。Lens 辨識出這個問題，以及後來通過的檢查，但沒有聲稱這些失敗仍存在於交付的程式碼中。我們已將發現的引文與來源比對。
在該工作階段中的搜尋回傳了超過 544,000 個字元。工具存取讓代理程式能掌控其閱讀內容，但他們仍可能要求過多。我們會將其工具使用情況與發現品質一併檢視。
結果如何送達 Lens
工作者會將進度與發現傳送到 LiteLLM gateway，因此您可以在其他代理程式仍在工作時，觀察已完成的審查逐一出現。這些發現會連回原始步驟以供檢視。
工作者會在您的基礎架構上執行，並向 LiteLLM 輪詢工作。它使用 gateway 來取得證據，並呼叫您選擇的分析模型。ClickHouse 儲存追蹤結果，而 Postgres 儲存調查狀態。管線與工具 是開源的。
在我們的架構實驗中，我們建立了一個黃金資料集，包含 25 項調查、3,752 個工作階段與 99,797 個跨度。這些受控案例包含巢狀代理程式、長工具結果、健康執行，以及失敗後恢復。我們的架構找出了全部 11 種預期的失敗模式：100% 的召回率。
要在您的代理程式上試用，請連接工作者並建立調查。