構(gòu)建分層的 Agentic RAG 系統(tǒng)：具備自主糾錯的多模態(tài)推理

作者 ｜ Abhijit Ubale

譯者 ｜ 張衛(wèi)濱

引 言

企業(yè) AI 團(tuán)隊長期面臨著一個難題，那就是大多數(shù)檢索增強(qiáng)生成 (RAG) 系統(tǒng)要么擅長結(jié)構(gòu)化的數(shù)據(jù)查詢，要么擅長文檔檢索，但當(dāng)兩者需要同時使用時就會無能為力。比如財務(wù)分析師提出“為什么歐洲業(yè)務(wù)表現(xiàn)不佳？”這類問題時，既需要 SQL 數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù) (營收、利潤率、員工數(shù)量)，也需要非結(jié)構(gòu)化文檔 (市場報告、競爭分析、監(jiān)管文件)。現(xiàn)有 RAG 系統(tǒng)往往會返回缺少監(jiān)管上下文的營收數(shù)據(jù)，或給出缺乏量化校驗的市場報告，最后仍需分析師手工補(bǔ)齊。當(dāng)前 RAG 方法把這些模式當(dāng)成彼此獨立的問題，迫使工程師要么構(gòu)建定制的編排層，要么接受不完整的答案。

本文將探討如何通過分層多智能體編排解決這一“模態(tài)鴻溝（modality gap）”問題，并以 Protocol-H 作為參考實現(xiàn)來說明這些概念如何落地。文中討論的模式，也就是帶有自主糾錯能力的 supervisor-worker 拓?fù)洌⒃?LangGraph/LangChain 的 agentic 模式之上，類似 xAI 和 Databricks 等團(tuán)隊采用的方法。配套的開源 代碼 展示了這些模式如何在 Docker/K8s 環(huán)境下實現(xiàn)企業(yè)級部署；讀者也可在自己偏好的框架中復(fù)用同樣的架構(gòu)原則。

本文中的架構(gòu)基于參考實現(xiàn)和面向生產(chǎn)環(huán)境的企業(yè)數(shù)據(jù)集實驗。為了聚焦架構(gòu)模式而非某個特定系統(tǒng)的具體實現(xiàn)，一部分部署細(xì)節(jié)做了泛化處理。

模態(tài)鴻溝問題：
為什么傳統(tǒng) RAG 無能為力

傳統(tǒng) RAG 系統(tǒng)通常是線性的流水線：向量化用戶問題、檢索文檔、交給 LLM、生成答案。它在文檔中心型的問題上表現(xiàn)尚可，但在企業(yè)多模態(tài)數(shù)據(jù)環(huán)境中就無能為力了。

以客戶流失分析為例：“哪些客戶群體流失率最高？結(jié)合工單看常見原因是什么？”這個問題執(zhí)行如下步驟：

• 結(jié)構(gòu)化推理 (SQL)：連接客戶、交易和流失表，計算群體的流失率。

• 語義推理 (向量檢索)：檢索與流失語義相關(guān)的支持工單。

• 跨模態(tài)匯總：將 SQL 結(jié)果與文檔洞察進(jìn)行關(guān)聯(lián)，識別因果關(guān)系。

大多數(shù) RAG 系統(tǒng)會嘗試“一次性完成”：

查詢 → 向量檢索 + SQL 查詢 → LLM → 答案

但是，結(jié)果往往是不完整甚至幻覺化的答案，原因包括：如果預(yù)先固定檢索路徑，開發(fā)者必須首先決定查詢哪些 SQL 表、檢索哪些文檔，這常常會漏掉關(guān)鍵的數(shù)據(jù)；上下文窗口有限時，即使檢索到了相關(guān)的結(jié)果，也可能無法在單次 LLM 推理中實現(xiàn)完整的匯總；初始 SQL 可能會找到高流失群體，卻遺漏關(guān)鍵工單；缺乏重試機(jī)制 (比如，迭代修正) 時，系統(tǒng)會直接基于不完整的信息作答。尤其當(dāng)結(jié)構(gòu)化與非結(jié)構(gòu)化信號沖突時，LLM 仍會給出“看起來很自信”的答案。

真實影響

在針對三家金融服務(wù)場景的內(nèi)部評估中 (Q4 2025，大約 1500 條多跳查詢)，約 30% 的案例出現(xiàn)“靜默失敗”：即答案表面權(quán)威，但遺漏了超過 20% 的相關(guān)數(shù)據(jù)點 (比如，績效分析中缺失監(jiān)管上下文)，且推理路徑不透明，不利于審計。

這正是需要分層 Agentic 推理的原因。

分層 Agentic 解決方案：
架構(gòu)總覽

Protocol-H 引入了受組織層級與人類問題求解方式啟發(fā)的 supervisor-worker 拓?fù)浣Y(jié)構(gòu)：

就像管理者會先把專業(yè)分析分派給數(shù)據(jù)分析師 (SQL) 和研究員 (文檔) 再匯總結(jié)論一樣，supervisor 負(fù)責(zé)拆解問題，worker 負(fù)責(zé)執(zhí)行各自模態(tài)的任務(wù)。

圖 1：Protocol-H 架構(gòu)。supervisor 將查詢路由到專用 SQL/ 向量 worker，并借助 reflective retry 進(jìn)行糾錯，其設(shè)計靈感來自組織層級 (來源：Protocol-H 倉庫)。

這里的核心在于基于編排進(jìn)行專業(yè)化：每個 worker 專注自身的模態(tài) (SQL 或語義檢索)，supervisor 負(fù)責(zé)管理推理流并處理復(fù)雜的多跳（multi-hop）場景。

組件詳解

Supervisor 智能體：元認(rèn)知編排器

Supervisor 是系統(tǒng)的推理中樞。它不直接執(zhí)行查詢，而是扮演策略的指揮者。

核心職責(zé)：

• 查詢分析：判斷問題需要 SQL、語義檢索，還是兩者都需要。

• 任務(wù)分解：把復(fù)雜問題拆成原子步驟 (例如“先找歐洲客戶，再取其工單，再與流失數(shù)據(jù)關(guān)聯(lián)”)。

• Worker 路由：基于任務(wù)與當(dāng)前狀態(tài)決定下一步由哪個 worker 執(zhí)行。

• 結(jié)果綜合：將各 worker 輸出整合成連貫的最終答案。

• 錯誤管理：檢測失敗并觸發(fā) reflective retry。

實現(xiàn)模式：

    return {"next_step": decision.next_worker, ...}

SQL Worker：Schema 感知查詢引擎

SQL Worker 專注于確定性、結(jié)構(gòu)化推理。

關(guān)鍵特性：

Schema 自省

SQL worker 會通過數(shù)據(jù)庫元數(shù)據(jù) API(比如，INFORMATION_SCHEMA) 自動發(fā)現(xiàn)表與列。關(guān)系識別會通過兩種機(jī)制來實現(xiàn)：一是元數(shù)據(jù)中的顯式外鍵約束 (作為權(quán)威依據(jù))；二是在缺少外鍵時，基于列命名規(guī)范的 LLM 啟發(fā)式推斷 (比如，跨表匹配 customer_id)。

為降低推斷關(guān)系帶來的正確性風(fēng)險，系統(tǒng)使用了多層防護(hù)：首先，實現(xiàn)置信度評分，基于字符串相似度與命名約定強(qiáng)度打分；低置信度的推斷 (相似度<0.8) 不會自動使用，而是要求顯式確認(rèn)。其次，由 supervisor 仲裁：推斷關(guān)系以“帶置信度的候選建議”而非硬約束形式提交，需要 supervisor 逐條批準(zhǔn)后才可生成查詢。再次，做運行時驗證：使用推斷 join 的查詢會先以行數(shù)受限的形式執(zhí)行；如果結(jié)果異常 (比如，空結(jié)果、笛卡爾積或類型不匹配)，會觸發(fā) reflective retry 并提醒 supervisor 重審 join 的有效性。最后是顯式外鍵優(yōu)先：一旦元數(shù)據(jù)存在顯式外鍵，相關(guān)表將完全跳過啟發(fā)式推斷階段。

查詢校驗

生成的 SQL 在執(zhí)行前會先基于 schema 進(jìn)行校驗。

方言優(yōu)化

為生成特定數(shù)據(jù)庫方言的 SQL(比如，Snowflake、Redshift、BigQuery)，系統(tǒng)會把目標(biāo)方言與 schema 上下文注入 LLM 提示詞，并在執(zhí)行前進(jìn)行語法校驗。復(fù)雜的方言特性 (如 Snowflake 的 QUALIFY、BigQuery 的 STRUCT) 是該方法的已知限制。reflective retry 能處理失敗，但無法保證首輪就完全正確。對于嚴(yán)重依賴方言或合規(guī)敏感場景 (例如，要求精確 QUALIFY 語義的監(jiān)管財報、對 STRUCT 校驗嚴(yán)格的醫(yī)療數(shù)據(jù))，團(tuán)隊可優(yōu)先采用 connector 級模板或查詢構(gòu)建器 (SQLAlchemy、dbt 等)，由 Protocol-H 編排已驗證的查詢片段，而非從零生成 SQL。

工作流:

圖 2：工作流

安全機(jī)制：

在 SQL 注入防護(hù)方面，系統(tǒng)通過參數(shù)化查詢 API(比如，cursor.execute(query, params)) 執(zhí)行 SQL，而不是字符串拼接，確保用戶輸入不會被當(dāng)作可執(zhí)行 SQL。行級訪問控制方面，worker 使用已認(rèn)證用戶的憑據(jù)和會話上下文訪問數(shù)據(jù)庫，把權(quán)限控制交給數(shù)據(jù)庫原生 RBAC，而不是在應(yīng)用層重復(fù)實現(xiàn)。為防止出現(xiàn)失控的查詢，每次執(zhí)行都帶有可配置的超時時間 (默認(rèn) 30 秒)；超時后會取消查詢并通知 supervisor 縮小范圍重試或返回部分結(jié)果。

為保護(hù)內(nèi)存，會限制結(jié)果的大小。查詢結(jié)果在進(jìn)入 LLM 上下文前會按可配置行數(shù) / 字節(jié)上限截斷，避免超大負(fù)載耗盡內(nèi)存或超過 token 限制。

Vector Worker：語義檢索智能體

vector worker 負(fù)責(zé)面向文檔的語義推理。

關(guān)鍵特性：

• 語義檢索通過查詢向量化、檢索向量索引并返回相關(guān)文檔來實現(xiàn)。

• 混合檢索將 BM25 關(guān)鍵詞匹配與稠密向量余弦相似度結(jié)合，并通過 RRF（Reciprocal Rank Fusion）融合排序結(jié)果。該方案在精確性 (精確詞命中，比如，表名或產(chǎn)品碼) 與召回 (概念相關(guān)的內(nèi)容) 之間取得了平衡，優(yōu)于單一的方法。

• 相關(guān)性過濾通過閾值抑制偽匹配。

• 摘要步驟用于提取檢索文檔中的關(guān)鍵信息。

關(guān)鍵挑戰(zhàn)：

當(dāng)不存在相關(guān)文檔時會出現(xiàn)冷啟動的問題，worker 不會臆造結(jié)果，而是向 supervisor 返回顯式的 null 信號，觸發(fā)回退到 SQL 形式或向用戶發(fā)起澄清。對于語義過寬、可能產(chǎn)生多種沖突解釋的查詢，worker 會將其標(biāo)記為歧義，并把 Top-N 結(jié)果及其相關(guān)性分?jǐn)?shù)交給 supervisor 仲裁，而非盲目合并。如果時效性非常重要 (時間感知)，可在相關(guān)分?jǐn)?shù)中加入時間衰減因子，使近期報告、文件或工單優(yōu)先。本文報告的 EntQA 測試未啟用該能力；基準(zhǔn)結(jié)果基于無時間加權(quán)的標(biāo)準(zhǔn)向量檢索。

Reflective Retry 機(jī)制：自主的錯誤恢復(fù)

這正是 Protocol-H 與標(biāo)準(zhǔn)智能體系統(tǒng)的根本差異。當(dāng) worker 遇到錯誤時，系統(tǒng)不會把錯誤“包裝成答案”繼續(xù)傳播，而是會進(jìn)入 reflective retry 模式。

錯誤流

圖 3：Reflective Retry 節(jié)點——Protocol-H 中的自主錯誤恢復(fù)流程

示例：SQL 語法錯誤恢復(fù)

    return attempt_alternative_approach(correction)

與標(biāo)準(zhǔn) RAG 相比，這套機(jī)制使幻覺率下降約 60%(7.1% 對 28.5%，見表 1)。但這并非 retry 機(jī)制單獨的貢獻(xiàn)，而是 Protocol-H 整體架構(gòu) (supervisor-worker 拓?fù)洹chema 感知查詢生成和 reflective retry) 協(xié)同作用的結(jié)果。通過這種集成設(shè)計，錯誤會在傳播到最終答案生成前被捕獲并修正。

理解 Protocol-H“為什么這樣設(shè)計”只是第一步。上述 supervisor-worker 拓?fù)浜?reflective retry 機(jī)制只有在確保同等健壯性的時候，才能實現(xiàn)其收益。接下來將展開介紹關(guān)鍵架構(gòu)決策、狀態(tài)管理、數(shù)據(jù)庫抽象和 worker 的設(shè)計，說明如何把概念框架落成可用于生產(chǎn)環(huán)境的系統(tǒng)。

實現(xiàn)與集成：架構(gòu)決策

使用 LangGraph 進(jìn)行狀態(tài)管理

Protocol-H 使用 LangGraph 的 StateGraph 進(jìn)行確定性工作流編排：

    error_message: Optional[str]        # Error context for debugging

StateGraph 保證的是圖級別的確定性執(zhí)行：在相同輸入下，控制流圖 (訪問哪些節(jié)點、按什么順序訪問) 會保持一致 (路由決策通過 temperature=0 約束)。確定性的部分包括：節(jié)點訪問的順序、狀態(tài)遷移、重試觸發(fā)邏輯，以及何時調(diào)用哪個 worker。非確定性的部分包括：worker 生成的具體文本 (SQL、文檔摘要、推理解釋)，這些內(nèi)容即使輸入相同也可能因 LLM 采樣而產(chǎn)生變化。也就是說，編排邏輯與狀態(tài)遷移可完全復(fù)現(xiàn)并可審計；worker 輸出在結(jié)構(gòu)上可復(fù)現(xiàn)，但不保證逐字一致性。

StateGraph 具備良好可審計性，可完整追蹤決策與數(shù)據(jù)流；同時通過重試計數(shù)器與超時機(jī)制提升安全性，避免循環(huán)失控。

云中立的數(shù)據(jù)庫適配器

通過 Adapter 模式，Protocol-H 對數(shù)據(jù)庫差異做了抽象：

        pass

這種設(shè)計使團(tuán)隊可以在不修改編排邏輯的前提下替換數(shù)據(jù)庫后端，這對異構(gòu)基礎(chǔ)設(shè)施企業(yè)非常重要。在實踐中，各個 connector 會在內(nèi)部處理方言差異 (例如，Snowflake 的大寫標(biāo)識符、Redshift 的 pg_catalog 元數(shù)據(jù)、BigQuery 的嵌套 STRUCT 類型)，從而讓 supervisor 和 worker 始終面向統(tǒng)一的 QueryResult 接口。但它仍有一定的局限性：高度依賴方言的特性 (比如，Snowflake 的 QUALIFY、BigQuery 的 ARRAY_AGG、Redshift 的 DISTKEY hint) 通常需要 connector 級定制，無法實現(xiàn)自動抽象。團(tuán)隊在新數(shù)據(jù)庫后端接入 Protocol-H 時，應(yīng)先審計這些邊界場景再假定可完全地移植。

專用 Worker 智能體

每個 worker 都運行自己的 ReAct 循環(huán) (推理與行動)：

    }

基準(zhǔn)測試結(jié)果

本次評估比較了以下方法。

Protocol-H 在 EntQA 基準(zhǔn)上進(jìn)行評估。該基準(zhǔn)包含 200 道企業(yè)問題，需要同時在 SQL 與文檔數(shù)據(jù)上進(jìn)行多跳推理。

Protocol-H：即本文描述的分層 supervisor-worker 架構(gòu)，帶有 reflective retry 功能。

同時，評估了扁平化的智能體，也就是，單個通用 LLM 智能體可以訪問 SQL 和向量檢索工具，但不具備分層編排和專用 worker。這代表了最常見的“把所有工具都交給 LLM”的方案。

最后評估的是標(biāo)準(zhǔn) RAG，這是一個傳統(tǒng)的“先檢索后生成”流程 (向量化查詢→檢索文檔→交給 LLM→生成答案)，不具備 agentic 推理和 SQL 能力。

性能對比

表 1：性能對比

“推理步數(shù)”指系統(tǒng)在生成最終答案前觸發(fā)的獨立工具調(diào)用次數(shù) (SQL 查詢或向量檢索)。數(shù)值越高，通常表示多跳推理更充分；數(shù)值越低，往往表示系統(tǒng)嘗試了更少的輪次就嘗試給出答案，在該基準(zhǔn)中這會與更高的幻覺率密切相關(guān)。

基準(zhǔn)方法論

EntQA 是 Protocol-H 團(tuán)隊內(nèi)部構(gòu)建的基準(zhǔn)，用于評估異構(gòu)企業(yè)數(shù)據(jù)上的多跳推理能力。它目前并不是公開的基準(zhǔn)，但為了保證可復(fù)現(xiàn)性，評估腳本與匿名化問題集已放在 Protocol-H 倉庫) 中。

該數(shù)據(jù)集包含 200 道企業(yè)問題，分為三個復(fù)雜度層級。Tier 1(簡單，n=60)：單模態(tài)問題，一次 SQL 或一次向量檢索即可解決；Tier 2(中等，n=80)：需要一次 SQL 和一次向量檢索并做基礎(chǔ)匯總；Tier 3(復(fù)雜，n=60)：需要跨兩種模態(tài)進(jìn)行 3 步及以上的多跳推理，并進(jìn)行跨模態(tài)匯總 (例如，“哪些客戶分群流失率最高，他們的工單揭示了什么根本原因？”)。

本文中所有的準(zhǔn)確率數(shù)據(jù)均針對 Tier 3 的問題，即最難、也最貼近企業(yè)真實需求的子集。

測試配置：

• LLM：GPT-4o(三套系統(tǒng)統(tǒng)一使用，以隔離編排差異的影響)

• Embedding 模型：text-embedding-3-large(OpenAI)

• 向量庫：Pinecone(standard tier)

• SQL 后端：Snowflake Enterprise

• 硬件：Docker 容器，4 vCPU / 16GB RAM

• 評估方式：由 GPT-4o 對照標(biāo)準(zhǔn)答案打分，并對 20% 響應(yīng)做人類抽檢。局限：GPT-4o 既是三套系統(tǒng)的推理引擎又是評估器，可能引入循環(huán)偏差；基于人類抽檢校驗評估可靠性。

• 可復(fù)現(xiàn)性：完整評估腳本、提示詞和標(biāo)準(zhǔn)答案已在倉庫提供。說明：EntQA 所用的企業(yè)數(shù)據(jù)源沒有公開，復(fù)現(xiàn)實驗需使用具有類似 schema 復(fù)雜度的 SQL/ 向量數(shù)據(jù)集。

關(guān)鍵發(fā)現(xiàn)

準(zhǔn)確率提升

與扁平化的智能體相比，分層路由在多跳準(zhǔn)確率上相對提升了 34.6%(84.5% vs 62.8%)；與標(biāo)準(zhǔn) RAG 相比相對提升 87.0%(84.5% vs 45.2%)。換算為絕對值，分別提升 21.7 和 39.3 個百分點。

延遲方面的權(quán)衡

Protocol-H 的 p95 延遲為 2.1 秒，相比標(biāo)準(zhǔn) RAG(0.8 秒) 慢約 1.3 秒，相比扁平化的智能體 (1.4 秒) 慢約 0.7 秒，主要是由更高的推理步數(shù) (3.2 vs 1.0 vs 1.8) 導(dǎo)致的。這是多跳推理的直接成本。作為參照，同步儀表盤查詢通常可接受 2-3 秒的響應(yīng)，因此 Protocol-H 對多數(shù)分析型負(fù)載仍在可接受的范圍之內(nèi)。

對于延遲敏感的場景 (比如，面向客戶的實時應(yīng)用)，建議采用基于 webhook 的異步模式。以 2.1 秒延遲換來 21.7% 的準(zhǔn)確率提升，在“決策質(zhì)量優(yōu)先于速度”的企業(yè)分析場景中這通常是更優(yōu)的權(quán)衡。

健壯性

在高錯誤率查詢 (有意制造的 schema 不匹配) 方面，Protocol-H 的正確恢復(fù)率為 89%，而扁平化的智能體僅為 12%。

生產(chǎn)環(huán)境的部署考量

安全與合規(guī)性

企業(yè)部署不僅要準(zhǔn)確率，還要確保安全與可治理。Protocol-H 在這方面實現(xiàn)了：

確定性的控制流

StateGraph 保證執(zhí)行路徑可復(fù)現(xiàn)，這對合規(guī)審計至關(guān)重要。

Schema 感知

初始化時，每個 worker 都會讀取數(shù)據(jù)庫元數(shù)據(jù) (如 INFORMATION_SCHEMA)，構(gòu)建在已認(rèn)證用戶 RBAC 權(quán)限范圍內(nèi)可訪問表 / 列的運行時映射。worker 只會針對可證實有權(quán)限的數(shù)據(jù)生成查詢，從執(zhí)行前就阻斷未授權(quán)的訪問。

策略控制

團(tuán)隊可在 schema_policy.yaml 中定義額外的業(yè)務(wù)規(guī)則 (比如，exclude_tables:['pii_raw'])，在數(shù)據(jù)庫權(quán)限之外再加一層數(shù)據(jù)邊界控制，適用于多租戶部署或監(jiān)管分區(qū)場景。

錯誤診斷

系統(tǒng)會返回完整的上下文解釋“為何會失敗”，而不是直接給出幻覺化的答案。

限流

限流可防止智能體失控并保護(hù)基礎(chǔ)設(shè)施。

結(jié)果校驗

在結(jié)果返回給 supervisor 前，worker 輸出會經(jīng)過可配置的校驗層，對如下情況進(jìn)行檢查：數(shù)值異常 (如營收超閾值)、NULL 主導(dǎo)結(jié)果 (如超過 80% 為 NULL，提示 schema 不匹配)、按上下文不應(yīng)為空卻為空的結(jié)果集，以及預(yù)期類型與返回類型不一致。校驗失敗時會觸發(fā) Reflective Retry Node，而不是把可疑數(shù)據(jù)繼續(xù)傳遞到最終答案。

部署模式

同步 API

print(result["final_answer"])

基于 Webhook 的異步方式

})

Docker 容器化

CMD ["python", "main.py"]

常見的挑戰(zhàn)與解決方案：
Schema 漂移

企業(yè)數(shù)據(jù)庫會持續(xù)演進(jìn)，比如，列重命名、表廢棄、引入新的業(yè)務(wù)邏輯。

Protocol-H 通過兩種互補(bǔ)機(jī)制應(yīng)對 schema 的漂移。第一是周期性的 schema 校驗，應(yīng)用運行時的輕量級后臺線程會按照可配置的周期 (默認(rèn) 24 小時，或在出現(xiàn)“unknown column”錯誤時觸發(fā)) 重新抓取INFORMATION_SCHEMA元數(shù)據(jù)，并更新各 worker 內(nèi)存中的 schema 映射。高可用部署中，也可改用 Kubernetes CronJob 或外部調(diào)度器實現(xiàn)，避免實例級輪詢。

第二是基于替代建議的優(yōu)雅錯誤處理。worker 在查詢時遇到“unknown column”不會靜默失敗，而會觸發(fā)恢復(fù)流程，也就是，先對當(dāng)前 schema 做模糊匹配 (例如，識別profit_margin已改名為net_margin)，通過字符串相似度打分；如果命中高置信的候選者 (>0.8)，會把建議列名連同原始錯誤上下文 (如“Column profit_margin not found - did you mean net_margin?”) 提交給 supervisor。隨后由 supervisor 決定按建議重試、請求澄清還是將問題升級給用戶；如果沒有命中候選者，則附帶完整診斷信息通知 supervisor 改寫查詢或告知用戶存在數(shù)據(jù)不匹配的問題。

這種做法避免了 schema 漂移變成“靜默失敗”。每一次漂移相關(guān)的錯誤都會產(chǎn)出可執(zhí)行的信號，而不是幻覺化的答案。

復(fù)雜 Join 下的幻覺問題

當(dāng)查詢涉及 3 張及以上表的連接時，LLM 有時會生成錯誤的 join 條件。

reflective retry 機(jī)制可以通過捕獲失敗查詢并建議替代 join 策略，或?qū)⒉樵儾鸱殖筛〉牟襟E來解決該問題。

多跳場景下的延遲

每增加一步推理都會引入增量延遲。在需要 3-5 步串行推理的多跳場景中，總查詢延遲可能超過同步交互界面的容忍閾值。

解決方式包括，對常見子查詢進(jìn)行結(jié)果緩存，在步驟相互獨立時進(jìn)行并行執(zhí)行。

Protocol-H 通過 LangGraph 的 Send API 支持該模式，同時保持確定性的圖結(jié)構(gòu)。這里的“確定性”指編排邏輯 (哪些節(jié)點執(zhí)行、執(zhí)行順序) 可復(fù)現(xiàn)，而非必須串行執(zhí)行。如果一個查詢同時需要 SQL 聚合和向量檢索且兩者無依賴，supervisor 會并行分派給兩個 worker，再在確定性的同步點匯合結(jié)果后做最終匯總。也就是說，控制流圖仍完全可復(fù)現(xiàn)，只在 worker 層執(zhí)行并行化。(見圖 1 中的并行 worker 路徑)。

還應(yīng)緩存 schema 信息以避免重復(fù)自省：schema 元數(shù)據(jù)按可配置 TTL(默認(rèn) 24 小時) 緩存，并與 Schema Drift 章節(jié)中的校驗周期保持一致，確保緩存與漂移檢測同步。緩存失效與刷新節(jié)奏與后臺 schema 校驗一致，從而在性能 (減少會話內(nèi)重復(fù)INFORMATION_SCHEMA查詢) 與新鮮度 (保證 worker 不使用超過 TTL 窗口的舊 schema) 之間取得平衡。

成本管理

每次智能體調(diào)用都要觸發(fā) LLM，規(guī)模化后成本會明顯累積。

為了控制成本，可以采用更快更便宜的模型做路由決策 (比如，supervisor 使用 GPT-4o mini)。這是面向未來成本優(yōu)化的通用架構(gòu)建議。需要強(qiáng)調(diào)的是，本文基準(zhǔn)結(jié)果 (84.5% 準(zhǔn)確率、7.1% 幻覺率) 均來自統(tǒng)一使用 GPT-4o 的 supervisor 和 worker。我們尚未正式評估混合模型配置下的成本 / 準(zhǔn)確率權(quán)衡；采用該模式的團(tuán)隊?wèi)?yīng)先結(jié)合自身的準(zhǔn)確率門檻完成驗證，再進(jìn)行規(guī)模化部署。另外，可以對相同查詢緩存推理結(jié)果，并批處理相似查詢以提升效率。

經(jīng)驗總結(jié)

專業(yè)化優(yōu)于泛化

專用的 SQL 和 Vector worker 在各自模態(tài)上持續(xù)優(yōu)于單一的通用智能體：SQL worker 擅長結(jié)構(gòu)化推理，vector worker 擅長語義檢索。這種專業(yè)化會在端到端上形成復(fù)利化的收益。

錯誤恢復(fù)至關(guān)重要

在內(nèi)部測試中 (n≈1500，覆蓋三套金融服務(wù)部署，Q4 2025)，對幻覺響應(yīng)的錯誤分析顯示：大約 60% 并非源于 LLM 基礎(chǔ)推理能力不足，而是來自未處理執(zhí)行錯誤、SQL 失敗、向量檢索為空或 schema 不匹配，并被靜默傳播到最終答案階段。這意味著恢復(fù)機(jī)制的價值極高：僅通過修復(fù)錯誤處理，就能覆蓋大部分幻覺問題，而不必升級模型。

Schema 感知是關(guān)鍵

理解可用數(shù)據(jù)邊界 (schema 與訪問控制) 的 worker，比只處理原始數(shù)據(jù)的 worker 能做出更好的決策。

確定性帶來信任

企業(yè)往往把“可復(fù)現(xiàn)執(zhí)行”看得比“最大化準(zhǔn)確率”更重要，因此確定性工作流編排是生產(chǎn)級智能體系統(tǒng)的關(guān)鍵設(shè)計要求。StateGraph 的圖級確定性 (相同輸入下節(jié)點訪問順序與狀態(tài)遷移一致) 提供了這種可復(fù)現(xiàn)性。具體來說，Protocol-H 會為每次決策生成可追蹤的審計日志：調(diào)用了哪些 worker、順序如何、輸入是什么。對于受 SOC 2、GDPR 或內(nèi)部模型治理約束的企業(yè)團(tuán)隊，這種可復(fù)現(xiàn)能力是剛需，它能把答案追溯到具體數(shù)據(jù)來源和推理步驟，使合規(guī)審計相較非確定性系統(tǒng)更具可操作性。

多模態(tài)推理需要編排

沒有單一的智能體能夠同時在 SQL 與語義數(shù)據(jù)上都推理得足夠好，分層委派是必需的。

未來展望

本文框架是當(dāng)前企業(yè)級 agentic RAG 實踐的一個階段性切片。后續(xù)重點研究方向包括：

自適應(yīng)路由

研究目標(biāo)是學(xué)習(xí)“不同查詢類型最有效的 worker 組合”。當(dāng)前主要在探索兩條互補(bǔ)的路徑。第一是查詢?nèi)罩痉治觯和诰驓v史執(zhí)行軌跡，找出與高準(zhǔn)確性、低重試相關(guān)的 supervisor 路由決策，再將這些模式反饋到未來路由 (例如，“財務(wù)的階段性問題通常先需要 SQL，再執(zhí)行向量檢索以補(bǔ)全上下文”)。第二是輕量 RL 優(yōu)化：把 supervisor 路由決策建模為可優(yōu)化的策略，以“答案準(zhǔn)確率 + 幻覺率 + 查詢延遲”的組合作為獎勵信號，讓系統(tǒng)在無需人工調(diào)參下逐步學(xué)習(xí)查詢類型的特定路由。兩者仍處于早期研究階段；考慮到實現(xiàn)的復(fù)雜度，日志分析是更接近階段性可落地的路徑。

語義化緩存

緩存向量檢索結(jié)果，減少重復(fù) embedding 計算。

跨模態(tài)融合

探索更高級的 SQL 證據(jù)與語義證據(jù)融合方法。

可解釋性

為多跳的推理路徑生成人類可讀的闡述形式，這可能是企業(yè)采用的最關(guān)鍵前沿領(lǐng)域。當(dāng)前 Protocol-H 能輸出完整的執(zhí)行軌跡 (調(diào)用了哪些 worker、順序如何、輸入輸出是什么)，但這仍是技術(shù)日志，不是業(yè)務(wù)可讀的闡述形式。下一步是把軌跡轉(zhuǎn)成自然語言推理摘要，例如：“為回答你關(guān)于歐洲業(yè)務(wù)表現(xiàn)不佳的問題，我先按地區(qū)查詢營收與利潤率數(shù)據(jù) (SQL)，再檢索歐盟最新監(jiān)管文件和市場報告 (向量檢索)，并發(fā)現(xiàn)德國利潤率下滑與 2024 年 Q3 三份監(jiān)管文檔提到的新 VAT 合規(guī)成本相關(guān) ”。這種透明度對分析師信任、合規(guī)性審計和模型治理都至關(guān)重要。歐盟 AI 法案對高風(fēng)險 AI 系統(tǒng)要求保留系統(tǒng)運行日志 (第 12 條)，其中就包括決策的可追溯性。

結(jié) 論

企業(yè) RAG 中的“模態(tài)鴻溝”(結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)協(xié)同) 本質(zhì)上不是單純的技術(shù)能力不足，而是編排方面的挑戰(zhàn)。Protocol-H 證明，具備自主錯誤恢復(fù)的分層多智能體系統(tǒng)可以達(dá)到企業(yè)級準(zhǔn)確性、安全性和可審計性。

通過職責(zé)分離 (supervisor 負(fù)責(zé)編排、worker 負(fù)責(zé)專長執(zhí)行) 并實現(xiàn) reflective retry 機(jī)制，團(tuán)隊可以構(gòu)建在異構(gòu)企業(yè)數(shù)據(jù)上穩(wěn)定推理的 agentic 系統(tǒng)，同時滿足確定性與合規(guī)要求。

對構(gòu)建企業(yè)級 agentic 系統(tǒng)的團(tuán)隊而言，核心架構(gòu)原則很簡單：先編排再委派，先專業(yè)化再泛化，先恢復(fù)再傳播錯誤。帶自主糾錯的分層多智能體設(shè)計，能夠在異構(gòu)數(shù)據(jù)模態(tài)上實現(xiàn)可靠推理，彌合理論能力與生產(chǎn)可用之間的鴻溝。參考實現(xiàn) Protocol-H 已經(jīng)在實踐中驗證了這些原則，也為團(tuán)隊按自身基礎(chǔ)設(shè)施和合規(guī)需求做二次落地提供了基礎(chǔ)。

代碼示例：本文所有代碼片段均來自 Protocol-H 框架的原始 Python 實現(xiàn)。

參考資料：

• LangChain v0.3.x

• LangGraph v0.2.x

• OpenAI Python SDK v1.x

• GPT-4o (gpt-4o-2024-08-06) — 用于 Worker 推理

• GPT-4o mini (gpt-4o-mini-2024-07-18) — 推薦用于 Supervisor 路由

• text-embedding-3-large — 用于向量 embedding

• Pinecone v3.x

• Snowflake Connector for Python v3.x—Python Connector

注意：版本號對應(yīng)基準(zhǔn)測試時所用版本 (Q4 2025)。

開源倉庫可以參見此處。

Building Hierarchical Agentic RAG Systems: Multi-Modal Reasoning with Autonomous Error Recovery (https://www.infoq.com/articles/building-hierarchical-agentic-rag-systems/)

聲明：本文由 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。