最近翻 arXiv 看到一篇很有意思的論文：《Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction》，作者來自德州農工、滑鐵盧、加州大學聖地牙哥分校、史丹佛、伊利諾大學厄巴納-香檳分校等學校，外加 Verdent AI、Lambda 幾間公司。
「
標題已經把核心觀點透露得差不多了——別再圍著 retriever 轉了，搜尋這件事本身就值得重新想一遍。筆者讀完覺得很受啟發，下面把這篇論文掰開揉碎來講。
圖 1：BrowseComp-Plus 上效能 vs 成本的帕雷托前沿。藍色五角星是 Qwen3-Embed-8B 檢索器的方案，綠色五角星是這篇論文的兩個 DCI-Agent。可以看到右上角性價比那塊，DCI 的方案直接把傳統 retriever 打趴在地上——準確率高 11 個百分點，成本反而省了 424 美元。
麥克魯漢那句老話又被翻出來了
論文一開頭就引了一句麥克魯漢的話："The medium shapes and controls the scale and form of human association and action."（媒介本身決定了互動的規模與形式）
放在 Agent 檢索這個脈絡下，這句話就變成了：Agent 怎麼「看到」語料庫，決定了它能做什麼、不能做什麼。
傳統那套 RAG 流程大家都很熟了——文件切塊、建索引、跑 BM25 或 dense embedding，每次丟個查詢進去拿回 top-k 結果。這套範式在靜態大語料、單輪問答的情境下沒什麼問題，效率也夠。但作者說，問題出在哪？出在 Agent 越來越強了。
像 Search-R1、ASearcher，再到 BrowseComp-Plus 這類新基準裡的深度研究任務，Agent 已經能自己規劃、改寫查詢、多輪搜尋了。但不管它再怎麼折騰，跟語料庫之間始終隔著一層 retriever，每一步只能看到被壓縮過的 top-k 切片。這就尷尬了——Agent 有想法，但「眼睛」被限制住了。
舉幾個 retriever 長年無解的場景：要做精確字串比對怎麼辦？要把好幾個弱訊號疊起來組合查詢怎麼辦？發現一條新線索想立刻在原文裡驗證一下怎麼辦？這些事情走傳統檢索介面都很彆扭，很多有用的證據在 top-k 之前就被過濾掉了，下游再強的推理也救不回來。
那不如讓 Agent 直接 grep？
作者的思路簡單粗暴——既然 retriever 是瓶頸，那乾脆把這一層拆掉。讓 Agent 直接拿 bash、grep、find、cat 這些通用終端工具，對著原始語料庫直接開工。
這個思路被命名為 Direct Corpus Interaction（DCI），直譯就是「直接語料互動」。
圖 2：左邊是傳統的 retriever-mediated 模式，離線建好索引，Agent 提查詢拿 top-k；右邊是 DCI 模式，Agent 直接拿 grep、glob、bash 這些指令在原始語料上操作，沒有 embedding 模型，沒有向量索引，什麼都沒有，就一個 shell。
聽起來有點反直覺對吧？2026 年了，怎麼還在玩 grep？但仔細想想，這件事其實很合理：
Coding Agent 這一兩年已經把 CLI-based 操作玩得很熟了——SWE-agent、Agentless、Claude Code、OpenHands、Aider 這些專案都證明了一件事：grep + read + bash 這套組合拳，對一個夠強的模型來說，足以在一個程式碼倉庫裡精確定位、改程式碼、跑測試。既然寫程式能這麼幹，搜文件為什麼不行？
DCI 這套範式的好處也很直白：
- 沒有離線建索引的開銷，丟個語料過去就能搜
- 天然適應動態語料，文件改了立刻就能搜到，不用重建索引
- 介面解析度高——Agent 可以做
grep 'foo' file | grep 'bar'這種疊加約束，可以grep -n 'keyword' file | head看精確位置和上下文 - 語義理解從索引下沉到 LLM 自己，模型變強直接吃到紅利
兩個 Agent 實作：一個輕量，一個全武裝
為了對照實驗，作者搞了兩套 DCI 實作：
DCI-Agent-Lite 是個極簡版本，基於一個叫 Pi 的輕量終端編碼 agent 改造而來，只給兩個工具：bash 和 read。基座模型用的是 GPT-5.4 nano，推理力度拉到最高（high）。這個版本的目的是把「介面變化」這個變數隔離乾淨——沒有任何檢索專用模組，沒有 embedding，沒有 reranker，純靠 shell。
DCI-Agent-CC 則是把 Claude Code 直接拿來當控制器，基座模型換成 Claude Sonnet 4.6，推理力度調到中等（medium）。這個版本是為了探探效能上限——更強的提示詞、更穩健的工具編排、內建的上下文管理都加上。但要注意，它本質上還是 DCI，沒碰任何 retriever 介面。
兩個 agent 的最大回合預算都是 300，給足探索空間。
長軌跡怎麼不爆上下文？
DCI 一個繞不開的問題是——grep 一搜可能數百上千個匹配，cat 一個檔案可能幾萬 token，幾十輪搜下來上下文視窗早就炸了。
圖 3：三種運作時上下文管理策略——截斷、壓實、摘要。
作者給 DCI-Agent-Lite 配了一套輕量的運作時上下文管理，三種機制疊著用：
截斷（Truncation） 是最簡單的——每個工具呼叫的輸出超過一定字元數就截掉，但保留「這個呼叫發生過」的痕跡。
壓實（Compaction） 不需要調 LLM，純記憶體操作。當累積的工具輸出超過閾值，就把老舊回合的工具結果替換成短佔位符，但保留工具呼叫的結構骨架。
摘要（Summarization） 是最重度的干預——上下文壓力還是太大，就讓一個摘要 agent 把歷史壓成一段簡短總結，最近幾輪原樣保留。
這三種機制組合出 L0 到 L4 五檔策略，從完全不管到全開。L0 什麼都不做，L1 只截斷到 5 萬字元，L2 截到 2 萬，L3 加上壓實，L4 再疊加摘要。
評估別只看準確率，得看覆蓋率和定位精度
光看答題準確率沒法說清楚 DCI 和傳統檢索的差別在哪。所以作者引入了兩個軌跡級別的指標。
覆蓋率（Coverage）：這條軌跡到底有沒有浮現出黃金文件？分三個口徑——any（至少碰到一個）、mean（召回率，平均碰到幾個）、all（全部碰到）。這是個「廣度」指標。
定位精度（Localization）：浮現出黃金文件之後，能不能在文件內部精準定位到關鍵證據片段？這是個「深度」指標，反映「搆到關鍵文件之後能不能再往下鑽」的能力。
簡單說，覆蓋率測「搆沒搆到」，定位精度測「搆到之後能不能精修」。這兩個一組合，DCI 和 retriever 的差異就現形了。
實測結果：把 retriever 按在地上摩擦
作者跑了三類基準測試：BrowseComp-Plus（代理人搜尋）、6 個多跳問答（NQ/Trivia/Bamboogle/HotpotQA/2Wiki/MuSiQue）、6 個 IR 排名（BRIGHT 4 個 + BEIR 2 個）。
代理人搜尋這塊，同樣用 Claude Sonnet 4.6 做基座模型，把 Qwen3-Embedding-8B 這個 retriever 換成 DCI，準確率從 69.0% 提升到 80.0%（+11 個百分點），成本從 1440 美元降到 1016 美元（-29.4%）。DCI-Agent-CC 也直接超過了所有檢索基準線，包括最強的 GPT-5 + Qwen3-Embedding-8B 組合（71.7%），高出 8.3 個百分點。輕量版 DCI-Agent-Lite 跑出 62.9% 準確率，成本只要 93 美元——和 o3 + Qwen3-Embedding-8B（66%）打得有來有回，但成本省了 647 美元。
多跳問答這塊，DCI-Agent-CC 平均準確率 83.0%，比最強的檢索代理人基準 ASearcher-Local-14B（52.3%）整整高了 30.7 個百分點。最誇張的是難度最高的 MuSiQue，DCI-Agent-CC 拿到 74%，ASearcher 只有 24%——50 個百分點的差距。HotpotQA 高 30 個百分點，2Wiki 高 26 個百分點。輕量版 DCI-Agent-Lite 也有 68%，穩坐第二名。
IR 排名這塊就更誇張了，按理說這是 retriever 的主場吧？結果 DCI-Agent-CC 在 6 個資料集上全部奪冠，平均 NDCG@10 達到 68.5，比最強的 ReasonRank-32B（47.0）高了 21.5 個百分點。Lite 版本 56.7，也比 ReasonRank-32B 高 9.7 個百分點。
那 DCI 到底贏在哪了？
這是論文最精彩的部分——作者花了很大篇幅做控制變因，釐清成效到底是從哪來的。
圖 4：左邊是 BrowseComp-Plus 全部 830 題上 DCI-Agent-CC vs 傳統 retriever 的對比，右邊是 DCI 調用工具的分佈——Bash 佔 62.4%，Grep 佔 33%，剩下零零碎碎。Bash 內部又拆成鏈式搜尋、文件窺探、正則表達式這些具體意圖。
先看研究問題一之後的反直覺發現：DCI 贏，不是因為它撈到了更多黃金文件。
在 100 題的子集上對比，Qwen3-Embedding-8B 的平均覆蓋率是 56.7%，DCI-Agent-Lite 只有 28.0%。但 coverage_any（至少抓到一個黃金文件）兩者幾乎打平（74.0 vs 70.0），而定位精度分數 DCI 是 48.4，retriever 只有 21.7——差了 26.7 個百分點。
這就說明問題了。BrowseComp-Plus 的題目大部分只有 1 到 4 個黃金文件，DCI 一旦抓到一個有用的文件，立刻就能切換模式：從「廣撒網」變成「深挖局部」。它放棄了把整條黃金鏈全部撈回來的執念，而是專注於「已經搆到的那個文件我能不能榨出更多價值」。
作者把這個現象命名為 檢索介面解析度（retrieval interface resolution）——retriever 給的是「文件級」或「段落級」解析度，而 DCI 能給到「字元級」解析度。Agent 可以精確鎖定一行、一句、甚至一個 token 周圍的上下文，再據此發起下一輪搜尋。
工具使用分佈也印證了這點。Bash 指令裡頭，鏈式搜尋（grep 套 grep）佔了 22.3%，文件窺探（head/tail/sed 看局部）佔 18%，正則表達式搜尋 17%，單關鍵詞 grep 14.1%，find 文件 14%——這些全是「精修」型操作。完整 cat 一個文件只佔 9.2%。Agent 在幹的事情就是：組合約束、精確比對、片段驗證、按需讀取。
不是所有場景都吃這套
作者也很誠實，做了幾個壓力測試來劃清界線。
研究問題四——語料規模這道檻：作者把 BrowseComp-Plus 的語料從 10 萬份文件擴到 20 萬份（注入 FineWeb 的干擾項），然後擴到 40 萬份。
圖 5：DCI-Agent-CC 在不同語料規模下的表現——10 萬份時性價比最優，20 萬份時工具調用次數從 38.5 次漲到 86.9 次，準確率掉 13.6 個百分點；40 萬份時直接崩壞，準確率掉到 37.5%，平均要調 122.4 次工具，還有 20 題打到預算上限。
這個結論很關鍵——DCI 在搜尋深度上擴展性很好，但在搜尋廣度上代價陡升。一旦 Agent 找到一個好的「錨點文件」，後續操作很高效；但找到第一個錨點的成本，會隨候選空間膨脹而急劇上升。所以傳統的 dense/sparse 檢索在大規模靜態語料上仍然有不可替代的價值。
研究問題五——上下文管理策略到底重不重要：跑了 L0 到 L4 五檔對比。結論挺反直覺——更激進的管理不一定更好，呈現明顯的非單調曲線。L1 速度最快、保留黃金證據最多（31.3），但 L3 準確率最高（77）。L2 成本最低但準確率最差（69），L4 加了摘要反而又掉了。
這說明什麼？該忘的得忘。完整保留所有證據 ≠ 保留好的工作狀態。多步假設修訂需要「選擇性遺忘」，壓縮太弱會讓 Agent 漂移，壓縮太狠又把有用的中間結構丟了。要找到那個甜蜜點。
研究問題六——工具表達力到底貢獻了多少：這個消融實驗很狠。作者把 DCI-Agent-Lite 的工具削到只剩 read + grep（連 bash 管線都不給），看看還能不能打。
結果是——能打。read + grep 跑出 61% 準確率，仍然比 Qwen3-Embedding-8B 的 retriever（45%）高 16 個百分點，工具調用次數還差不多。完整 bash 工具集再多 12 個百分點，但工具用量、延遲、算力都翻倍。
所以最核心的增益來自介面本身的變化，而不是 bash 多麼花俏。一個最小工具集就能撬動大部分提升。
扒一扒程式碼：薄薄一層 Python 套在 Pi 上面
研究問題六那段說「最小工具集就夠用」，那這個最小工具集到底長什麼樣？光看論文不過癮，筆者順手把倉庫複製下來扒了一遍（github.com/DCI-Agent/DCI-Agent-Lite），結果發現整套東西的工程實作比想像中要「輕」很多——總共 87% Python + 13% Shell，目錄結構也清清爽爽。
整體架構：DCI-Agent-Lite ≈ Pi + 上下文管理補丁 + 評測鷹架
先講個反直覺的事——DCI-Agent-Lite 自己的 Python 程式碼量很少，它本質上是一個膠水層。真正做事的 agent 核心是 Pi，一個由 Earendil 團隊開發的極簡終端編碼 agent（用 TypeScript 寫的，npm 安裝）。
倉庫目錄結構大致是這樣：
DCI-Agent-Lite/
├── src/dci/ # Python CLI 包裝層（dci-agent-lite 入口）
├── prompts/ # 任務模板和評測提示詞
├── scripts/ # 資料下載 + 基準測試跑分腳本
├── setup.sh # 一鍵安裝環境
└── pyproject.toml # uv 管理 Python 相依套件注意 setup.sh 裡頭有一步是去複製 jdf-prog/pi-mono（論文第一作者江東甫的 fork）的 codex/context-management-ablation 分支，然後 npm run build。也就是說，作者把 Pi fork 了一份，在上面打了「上下文管理消融實驗」的補丁——論文裡 L0 到 L4 那五檔策略，就是這個補丁實現的。Lite 這邊的 Python 程式碼主要負責：參數透傳、調起 Pi 行程、收集輸出、儲存軌跡。
為什麼選 Pi 當底座
Pi 的設計哲學跟 DCI 簡直是絕配——Pi 官網那句口號 "There are many agent harnesses, but this one is yours" 已經說明問題。具體看幾個關鍵屬性：
極簡的系統提示詞。Pi 的預設系統提示詞短到出乎意料，沒有那些「你是一個有用的助手」之類的廢話，給 token 留足空間。這對長軌跡的深度研究場景特別關鍵。
只有少數原生工具，bash 是核心。Pi 不像 Claude Code 那樣自帶一堆 Read/Grep/Glob/Edit/Task 工具，它就給你一個 bash + 一個 read，剩下的全靠你自己拼 shell 指令。這正好是論文研究問題六想驗證的——最小工具集就夠用。
內建壓實機制。Pi 預設會在接近上下文限制時自動把老舊訊息摘要成短文字。作者在 fork 裡把這個機制擴展成了可調整檔位的 L0-L4 策略。
沒有花俏功能。沒有子代理人、沒有計劃模式、沒有 MCP——這些都是 Pi 故意「砍掉」的，都靠延伸功能自己加。這種「砍到見骨」的風格讓作者很容易做控制實驗：能確定效能差異不是控制器本身引入的雜訊。
跑起來到底是個什麼流程
最小可執行的指令長這樣：
uv run dci-agent-lite \
--provider openai \
--model gpt-5.4-nano \
--cwd "corpus/wiki_corpus" \
--extra-arg="--thinking high" \
--extra-arg="--context-management-level level3" \
"用當前目錄下的 wiki_dump.jsonl 回答：倫敦大火起源於哪條街？用 rg 不要用 grep。"拆開來看關鍵參數：
--cwd "corpus/wiki_corpus" 是個重點——Agent 的工作目錄就是語料目錄。Pi 啟動後 bash 的當前工作目錄直接指向 wiki_dump.jsonl 所在的資料夾。Agent 後續所有 rg、find、cat 都在這跑，相當於讓模型「住進」了語料庫裡。這個設計跟論文裡「agent operates directly within the environment it is reasoning over」那句話完美對上。
--extra-arg="--thinking high" 透傳給 Pi，再透傳給 OpenAI 的推理力度。GPT-5.4 nano 的便宜 + 高推理力度是這個 lite 版本能打的關鍵配方。
--extra-arg="--context-management-level level3" 就是論文裡表 1 那五檔策略的開關，level3 是預設值（截斷 + 壓實，不開摘要）。
使用者提示詞裡那句 "Use rg instead of grep for fast searching" 看起來像廢話，其實是個工程細節——rg（ripgrep）比 grep 快一個量級，對百萬份文件的語料幾乎是必需的。setup.sh 裡也專門安裝 ripgrep。
軌跡是怎麼落盤的
跑完之後，agent 會把整個搜尋過程序列化到 outputs/runs/<timestamp>/ 下面：
question.txt— 原始問題final.txt— 最終答案conversation_full.json— 完整對話歷史，每一輪的思考、bash 指令、工具結果全在裡面
這個 JSON 就是論文裡做軌跡分析的原料——研究問題二那張工具分佈圖（grep 33%、bash 鏈式搜尋 22.3% 等等），就是從這種 JSON 裡解析出來的。也是為什麼論文能那麼細粒度地拆解 agent 在幹嘛。
上下文管理那一層到底怎麼實現的
這是工程上最值得說的地方。論文裡畫了三種機制（截斷/壓實/摘要），但落到 Pi 這種 agent 循環裡具體是怎麼掛上去的？根據 Pi 的延伸機制（extensions 可以「在每輪之前注入訊息、過濾訊息歷史」）和作者打的補丁，大致可以推斷：
截斷發生在工具結果寫入訊息歷史之前——bash 跑完，原始輸出可能幾萬字元，截斷邏輯根據 level 的閾值（L1 是 5 萬，L2-L4 是 2 萬）卡掉多餘部分，給模型看的就是截斷後的版本。這個對 token 消耗影響最大。
壓實是「in-memory, zero-LLM operation」——純結構化操作，不調模型。一旦累積工具輸出超過 24 萬字元（L3 的閾值），就把「除最近 12 輪以外」的老舊工具結果替換成 <Result_Placeholder> 佔位符，但工具呼叫本身的結構（「曾經調過 grep xxx」）還保留著。這樣 agent 知道自己做過什麼，但不再背著那些已經消化過的原文。
摘要是 L4 才啟用的重型操作——壓實之後如果估算 token 還是超閾值，就調一次 LLM 把壓實後的歷史壓成一段簡短總結，最近 2 萬 token 原樣保留。論文還提到一個細節：連續三次摘要失敗就放棄，避免死循環。
這三層從輕到重疊加，配合論文研究問題五那個非單調結論（L3 最優、L1/L4 次之、L2 最差），其實就把一件事講清楚了——該忘什麼、什麼時候忘、怎麼忘，本身就是工程問題，沒法靠「壓得越狠越好」這種樸素直覺解決。
為什麼這套東西能跑出 62.9%
把上面這些拼起來，DCI-Agent-Lite 能在 BrowseComp-Plus 上幹掉 GPT-5.2 + retriever 的方案（用的還是便宜的 GPT-5.4 nano），筆者覺得是這幾個因素疊出來的：
一是 Pi 的系統提示詞極簡，token 不浪費在「自我介紹」上。二是工作目錄直指語料，agent 不需要費力學一套自定義的檢索 API，它本來就會用 bash。三是上下文管理把長軌跡的爆炸問題壓住了，300 回合預算才有可能不爆。四是 GPT-5.4 nano 的高推理力度 + ripgrep 的速度讓「邊搜邊想」這個循環跑得起來。
最後一個特別打動筆者的點是——這玩意兒真的可以直接對著自己電腦裡的文件跑。倉庫 README 那句 "Your private deep-research assistant" 不是行銷話語——不需要給任何雲端服務上傳文件、不需要裝向量資料庫、不需要等幾個小時跑 embedding。uv run dci-agent-lite --cwd ~/my-papers/，開工。這種「開箱即用」對個人知識庫情境的吸引力相當強。
筆者的幾點感受
讀完這篇論文、又把程式碼扒了一遍，筆者覺得它真正有價值的不是某個具體數字，而是把「檢索」這件事重新框定成了一個介面設計問題，而不僅僅是 retriever 設計問題。
過去十年的檢索研究基本都在卷模型——更好的稀疏演算法、更強的密集嵌入、更聰明的 reranker。但如果 Agent 自己已經能像研究者一樣思考——提假設、驗證字串、讀上下文、改查詢——那壓縮成相似度向量這一層反而成了瓶頸。給它一個更高解析度的介面，讓它自己處理語義，整體表現可能反而更好。
當然這套範式也有清晰的界線：
- 大規模靜態語料（千萬級文件以上）依然是密集 retriever 的天下
- 對基座模型能力要求很高，弱模型扛不住長軌跡的複雜搜尋
- 成本結構變了——從「一次性建索引的固定成本」變成「每次搜尋的邊際成本」，對於高 QPS 服務不見得划算
- 評估指標得更新——光看 recall@k 已經不夠了，得看軌跡級的定位精度
但反過來說，在那種本地、異質、動態變化的代理人工作空間裡——比如開發者本地的程式碼庫、企業內部不斷更新的文件、研究者電腦裡散落的 PDF——DCI 這套範式是真的有競爭力。不用建索引，文件改了立刻能搜，Agent 直接在它推理的那個環境裡操作，體感會非常順。
而且 GitHub 上 Anthropic 這一年推 Claude Code、推 agent skills，整個 agent 工具鏈都在往這個方向走——把 LLM 直接放到 shell 裡、放到檔案系統裡、放到真實環境裡。從這個角度看，DCI 幾乎是水到渠成的產物。
下一步值得追一下的方向，筆者覺得有幾個：DCI 怎麼和傳統檢索做混合（比如先密集召回粗篩，再 grep 精修）；怎麼給 DCI 加快取層降低重複搜尋的成本；以及更輕量的基座模型（7B/14B 那一檔）能不能也吃到這套範式的紅利。
倉庫目前 9 個星、1 個分支，論文是上週剛掛上 arXiv 的（2605.05242），整個專案還很早期。但筆者覺得這套思路值得追——它的工程門檻低到幾乎所有人都可以重現一遍，跑跑自己的 PDF、自己的 Notion 匯出，看看效果到底如何。比讀論文有趣多了。