Agentic 搜尋架構模式：能進生產的五種

摘要：推理循環是最便宜的那部分。真正決定一套代理式檢索能不能落地的，是它外面的控制環：類型化工具、上下文隔離、硬預算，以及一個能把任務打回去的評估器。

關鍵要點

收益是實測的。 在同一個嵌入模型下，代理式檢索把 nDCG@10 提高 8.7 個點。
代價也是實測的。 同一項研究給出每條查詢 107.4 秒，而單次檢索是 0.67 秒；每條查詢輸入 token 達 764.1K、輸出 5.8K。
子查詢彼此獨立時，計劃執行優於 ReAct。 延遲大約是標準檢索的兩倍，而 ReAct 在可並行的問法上要到四倍。
上下文隔離是阻斷錯誤傳播的那個模式。 主機—管理—worker 的分層設計，讓一條爛子查詢不至於污染最終答案。
生產事故多數是預算事故。 沒有 token 上限、沒有牆鐘上限的循環不是架構，而是一次等待被觸發的故障。

一、"代理式"到底加了什麼

傳統檢索是一次過：編碼問法、取 top-k、重排、作答。代理式檢索在中間加了一層決策——由系統決定搜什麼、搜幾次、拿到的證據夠不夠答。

這層決策換來的是泛化。在域外任務上，固定的檢索流水線會明顯退化，而同一個代理循環在兩個不同榜單上都還能打。它也換來了一個可測的品質增量：在嵌入模型不變的前提下，nDCG@10 提高 8.7 個點——說明增益來自問法構造與迭代，而不是換了個更好的編碼器。

代價在同一份測量里同樣清楚：每條查詢 107.4 秒對 0.67 秒，輸入 764.1K token、輸出 5.8K。兩個數量級的延遲差、五位數的 token 賬單，這不是四捨五入的誤差，它直接改變了系統能用在哪，也是為什麼架構比選模型更重要。

二、五種模式，各自什麼時候是錯的

模式	形態	適用	失效場景
計劃執行	一次規劃產出類型化子查詢，再並行執行	多條件問題、看板、合規核查	子查詢彼此依賴
ReAct 循環	想—做—看，反復到證據足夠	探索式調研、陌生語料	延遲預算在五秒以內
分層 worker	主機拆解、管理聚合、worker 並行且上下文隔離	大語料、長會話	編排開銷超過檢索耗時
檢索即工具	把搜尋、過濾、SQL 作為類型化函數給模型調	結構化與非結構化混合	工具 schema 與索引漂移
評估器把關	一個檢查器給證據打分，不通過就重規劃	高風險答案、受監管領域	評估器與規劃器共享盲區

第一種是主力。當一個問題能拆成互不依賴的幾段，規劃一次、並行執行，延遲就停在標準檢索的一個小倍數上，而不是隨推理步數線性增長。

ReAct 更適合"確實不知道該搜什麼"的時候，它也是最容易打爆延遲預算的模式，因為每一次觀察都是一次模型調用。

分層設計存在的理由很樸素：上下文飽和。所有子查詢的結果都落進同一個窗口，後面的推理就會退化。把 worker 上下文隔開、在管理層聚合，能保住最終綜合的乾淨，並行也吸收掉一部分額外成本。

檢索即工具是多數團隊實際在跑的東西，因為它讓同一個代理既回答"制度怎麼規定"，也回答"上個月有多少工單超時"，不用兩條流水線。它的失效點是 schema 漂移：工具描述說一套、索引是另一套，代理會安靜地搜錯字段。

評估器把關多花一個模型來判斷證據是否支持答案。受監管場景有用，但前提是評估器的失敗分布與規劃器不同——否則兩邊會漏掉同一件事。

三、我們會怎麼搭這個控制環

狀態放在模型外面。 計劃、已執行的子查詢、證據集，都放在編排器自己的存儲里。模型會改寫自己的草稿區，編排器不能依賴它。
類型化工具加校驗 schema。 每次工具調用在執行前先過 schema，而 schema 由索引定義生成，從根上避免漂移。
兩個硬預算。 token 上限與牆鐘上限，由編排器執行，不靠提示詞。任一觸頂就返回支撐最好的局部答案，並標注置信度。
證據台賬。 每個召回段落帶 ID、來源、時間戳、分數。最終答案引用 ID，不引用散文。這是答案可審計的前提。
評估器帶重規劃路徑。 證據不過關就帶著失敗原因回到規劃，只回一次；第二次失敗就給出拒答並說明缺什麼。
按步可觀測。 記錄每一步的延遲、token 消耗、召回條數。聚合 trace 會把吃掉 80% 預算的那一步藏起來。

第三點是多數團隊投入不足、但其實很便宜的一環。提示詞里寫"請高效"不是預算，一個能終止循環的計數器才是。

還有一個模式值得單獨命名，因為它才是壓住成本的東西：在子查詢層做緩存，而不是在答案層。兩個問題只要共享主體名與時間區間，就可以復用同一次檢索結果，前提是緩存鍵由歸一化子查詢加索引版本構成。答案層緩存注定低效，因為每個問法的最終答案都不同；子查詢層緩存命中率夠高，而且索引一變就能幹淨失效。

反方觀點是：緩存會讓循環變懶。確實會——規劃器會復用先前結果而不是重新構造，而這正是你想要的，因為重新構造一條本來就能用的子查詢，純燒 token。

四、我們在一個真實合同檢索項目里改了什麼

一個有代表性的案例：企業合同庫，1,400,000 份文檔，平均問法是一條帶兩個到三個條件的法務問題。第一版代理用的是 ReAct 循環，p95 打到 9 秒，token 花費讓財務來問話。

我們換成計劃執行。一次規劃調用產出三到五個類型化子查詢（主體、條款類型、時間區間、管轄地），對同一個混合索引並行執行，然後一次綜合。p95 降到 3.4 秒，nDCG@10 同時上升，因為子查詢把條件拆開了，而不是指望一個向量同時裝下所有條件。

兩件沒預料到的事。第一，規劃器需要一條"最多五個子查詢"的硬上限——超過之後召回不再提升，延遲線性增長。第二，最大的收益來自證據台賬而不是循環本身：答案一旦引用段落 ID，法務複核的糾錯率就下降，因為他們能直接核對原條款，不用重讀一遍答案。

工具 schema 這件事值得單獨說，因為它是藏得最久的故障。工具用散文描述（"按相對方檢索合同"）時，模型會傳一段自由文本相對方，索引再拿它去匹配錯字段——比如把主體名匹配到文檔標題上。把工具定義成"索引字段枚舉加每字段校驗類型"，讓模型在裡面挑。散文式工具會產出針對錯字段的、看起來很合理的查詢，這比調用失敗更糟，因為證據看起來是相關的——而錯的相關證據，最終會變成一份自信的錯誤答案。

五、邊界，以及那些看著高級的錯覺

代理越多不等於能力越強。 超過三到四個 worker，編排開銷開始主導，答案品質走平。
並行只對獨立工作有效。 對相互依賴的子查詢做扇出，產出的是一份建立在錯證據上的、看起來很漂亮的答案。
107 秒是研究環境下的數字，不是服務標準。 生產只有在無界循環里才會撞到，修法是預算，不是更快的模型。
流式輸出掩蓋延遲，但不消除延遲。 我們的日誌里，用戶在看著 token 往外蹦的時候，30 秒還是關掉了頁面。
評估器會繼承規劃器的偏見。 把關環節換一個模型家族，或者用規則型檢查器。
每條查詢多少 token，才是真約束。 按 764.1K 輸入 token 算，每月 10,000 條查詢的部署，先是產能規劃問題，然後才是品質問題。

最後一個結構性的點，關於評估：循環要按任務成功率與證據覆蓋率打分，不能只看排序指標。一個系統召回了排得很漂亮的段落，但這些段落合起來答不了問題，它的 nDCG 提高了，任務卻失敗了。兩個都記；當排序品質上升而任務成功率不動時，說明規劃器產出的子查詢是索引能排、但滿足不了的。

常見問題

問：到底要不要上代理？
A：如果一次檢索就能答，就別上。先量"需要第二條子查詢"的問法佔比；低於 15% 時，換個更好的重排器更便宜。

問：先上哪個模式？
A：計劃執行加類型化工具。它在各類問法上都能擴展，延遲也可預測。

問：成本怎麼封頂？
A：編排器里設硬 token 與時間預算，再加租戶級月度上限和一條優雅降級路徑。

問：上下文隔離值不值這個複雜度？
A：單次會話召回超過 20 個段落就值；低於這個量，單窗口加一個好摘要器就夠了。

問：循環怎麼評估？
A：固定問法集加分級相關性；排序品質看 nDCG@10，循環本身看任務成功率與每步延遲。

問：安全怎麼管？
A：在工具層做授權，不在提示詞層。代理應該根本調不到用戶角色無權使用的工具。

關於通智雲

通智搜尋把代理式檢索做成受控能力：類型化工具、硬預算、證據台賬、按步可觀測，讓循環的品質收益能穿過生產環境的延遲指標。

資料來源

超越語義相似度：代理式檢索的性能與成本——同一嵌入模型下 nDCG@10 提高 8.7 個點；每條查詢 107.4 秒對 0.67 秒；輸入 764.1K、輸出 5.8K token。
企業生產環境的 Agentic RAG——計劃執行延遲約為標準檢索兩倍，ReAct 在可並行問法上為四倍。
InfoSeeker：分層並行代理框架——主機—管理—worker 拆解與嚴格上下文隔離。
生產級代理式搜尋架構——控制環、評估器、運行時預算與可觀測性。