Deep Research Agent 實作課：把「查資料」變成可稽核的管線

今日主題：Deep Research Agent 的技術棧與實作

2026-10-18 | 資料來源：Anthropic 工程部落格（多智能體研究系統）、史丹佛 STORM 研究團隊（NAACL 2024）、DeepResearchEval（arXiv 2026）、LangChain deep agent 教學

前言：研究報告不是「答得好」，而是「查得深」

一般的對話機器人回答問題時，是把訓練記憶倒出來；Deep Research Agent 做的是另一件事：拿到一個開放式問題，先寫計畫、再發動幾十到上百次檢索、交叉比對不同來源、最後交出一份附引文的報告。單次執行往往要跑好幾分鐘，消耗的 token 是普通對話的十幾倍——但換來的是「可稽核」：報告裡的每個關鍵主張都能追到出處。

過去一年，這套做法從 ChatGPT Deep Research、Gemini Deep Research、Claude Research 變成產業標配；學術端則有史丹佛的 STORM 把同一套流程做成開源系統。這篇文章拆開它的技術棧：五階段架構、計畫與努力分級、平行子 Agent、引文驗證，以及怎麼評測它。

一、Deep Research 是另一種物種

不要把 Deep Research 當成「比較會聊天的 RAG」。兩者的差別不在模型，在工作方式：

- RAG：檢索一次（top-k 切片）→ 生成一次。線性、單跳。

- Deep Research：計畫 → 檢索 → 看結果缺什麼 → 改寫查詢再檢索 → 重複多輪 → 交叉驗證 → 綜合寫成報告。迴路式的、多跳的。

一個經驗法則：當問題的答案「不存在於任何單一頁面」，需要跨來源拼圖時，就該上 Deep Research。這也是為什麼它的失敗模式跟 RAG 不一樣：不是「找錯段落」，而是「查著查著迷路」（遞迴搜尋迴路、驗證到超時），或是「太認真」——問個快速摘要，回來一篇兩千字的學術分析。

二、核心架構：五個階段

如圖一，一次 Deep Research 執行可以拆成五個階段：

1. Clarify（對齊）：把模糊的問題重述一遍，列出已知與未知，必要時先問使用者。複雜研究一跑就是十幾分鐘，方向錯了全盤重來，對齊是最便宜的保險。

2. Plan（計畫）：把問題拆成可並行的「跳」（hop）——每跳是一個子問題，帶著預期的權威來源方向。同時決定深度等級：quick、standard、deep、exhaustive。

3. Execute（執行）：實際發動檢索。重點是平行：多個子 Agent 同時查不同面向，查到缺口就改寫查詢再查。

4. Validate（驗證）：主張逐一回查來源，標出矛盾與不確定。專門的 Citation Agent 做歸因。

5. Report（報告）：寫成結構化報告：摘要、發現、來源表（URL、標題、可信度、備註）、後續問題。

Plan → Execute → Validate 是一個迴圈，不是一條直線：驗證發現證據不足，就回到 Execute 補查。

三、Plan：多跳分解與「努力分級」

計畫階段有兩個技術活。

多跳分解：把「2026 年最活躍的 AI 新創投資人是誰，他們還投了什麼」拆成：先查 2026 年 AI 新創融資事件 → 整理出重複出現的投資機構 → 針對每家查其投資組合 → 交叉驗證。每跳的輸出是下一跳的輸入，這就是 multi-hop——問題本身需要推理鏈才能回答，單次檢索永遠打不中。

努力分級（effort scaling）：Anthropic 工程部落格公開的經驗是，Agent 很不會判斷「這題該花多少力氣」。他們的做法是把規則寫進提示詞：簡單事實查核只派 1 個 Agent、3 到 10 次工具呼叫；直接比較派 2 到 4 個子 Agent、各 10 到 15 次呼叫；複雜開放研究派 10 個以上、職責明確劃分。沒有這條規則，早期版本常犯的錯是「殺雞用牛刀」——簡單問題也派出一整支研究大隊。

STORM 則從另一個角度解決計畫問題：多視角提問。它先從既有文章中挖掘不同視角（實務者、學者、懷疑者、經濟學家、史學家），再讓扮演不同視角的「寫作者」去向「主題專家」提問。同一主題被五種腦袋問過一遍，盲點自然浮現。發表在 NAACL 2024 的論文顯示，這套做法讓產出文章的組織性提升 25 個百分點、覆蓋廣度提升 10%。

四、Execute：平行子 Agent 與上下文隔離

執行階段的關鍵洞察來自 Anthropic：token 量解釋了研究評測八成的效能差異。單一 Agent 的上下文與時間都有牆，撞牆時換更大的模型幫助有限；真正的解法是編排——Lead Researcher 拆任務、派子 Agent 平行探索。

架構長這樣：

- LeadResearcher：分析問題、定策略、派任務。計畫寫進外部記憶體，因為 200K token 以上的上下文會被截斷，計畫必須活在對話之外。

- Subagents：各自帶獨立上下文視窗，平行探索不同面向。每個子 Agent 收到的是完整任務包：明確目標、輸出格式、可用工具與來源指引、清楚的職責邊界。早期版本給模糊指令（「研究一下半導體短缺」）的教訓是：三個子 Agent 會查出同一批東西，或各自解讀成不同題目。

- CitationAgent：事後處理，把發現逐一歸因到來源。

子 Agent 還有一個被低估的功能：上下文隔離。詳細的檢索過程留在子 Agent 自己的視窗裡，只把提煉過的洞察交回給 Lead——這是 10/10 寫過的上下文工程「Isolate」支柱在研究場景的具體長相。子 Agent 寫大輸出時直接落檔，只傳回輕量引用，避免把幾萬 token 的檢索殘骸倒進主對話。

平行化的收益是實打實的：Anthropic 把序列式搜尋改成平行派發後，複雜查詢的研究時間最多縮短九成。代價是 token：多智能體系統的 token 消耗約為普通對話的 15 倍——這也是為什麼各家產品都要對 Deep Research 次數設限。

五、Validate：引文是稽核的起點，不是終點

Deep Research 報告的價值在引文，但引文只保證「可查」，不保證「正確」。Agent 可能誤讀來源、引用過時頁面、或把推論寫得像事實。驗證階段要做三件事：

1. 逐主張回查：每個關鍵主張都能指到具體來源段落，指不到的降級為「推論」。

2. 矛盾標記：不同來源說法衝突時，不要和稀泥——把矛盾寫出來，標出各自來源與可信度。

3. 不確定性揭露：查不到、或證據薄弱的部分，直接說「證據不足」，不要硬湊。

如圖二，驗證是一個獨立的迴路：主張 → 回查原文 → 通過／標記矛盾／打回補查。2026 年 1 月發表的 DeepResearchEval 甚至把這件事自動化：Active Fact-Checking 管線會自主抽取報告中的陳述、再用網路搜尋驗證——即使原文沒有引文也能查。這給了我們一個評測上的啟示：引文完整性可以機器檢查。

六、怎麼評測 Deep Research

評測研究型 Agent 比評測聊天難：同一份好報告可以走完全不同的路徑。所以業界評的是產出，不是過程：

- BrowseComp：OpenAI 發布的硬核網路瀏覽評測，考的是多跳檢索能力。Anthropic 透露 token 量解釋了這張考卷八成的效能變異——這也是多智能體架構的理論依據。

- DeepResearchEval（arXiv 2026）：自動化框架，兩招——用 persona 驅動生成貼近真實的研究任務（只保留需要多源證據整合的題目），再用自適應評分（依任務動態決定評分維度與權重）加上主動事實驗證來打分。

- Anthropic 內部研究評測：Lead 用 Claude Opus 4、子 Agent 用 Sonnet 4 的多智能體配置，比單一 Opus 4 高出 90.2%。

自己動手時可以偷師：準備 20 到 50 個「答案分散在多個來源」的題目，評分只看最終報告的事實正確率與引文覆蓋率，不看中間走了幾步。

七、成本與失敗模式：先談錢，再談夢

Deep Research 是 token 怪獸，部署前先算帳：

- 15 倍 token：Anthropic 公開的數字。多智能體研究系統的 token 消耗約為普通對話的 15 倍。這決定了它的商業模式：只能用在高價值任務，產品端必須限次。

- 遞迴搜尋迴路：Agent 為了驗證一個事實不斷點連結，最後超時。這是停止條件（Harness 的一部分）沒寫好的症狀——10/17 寫 Coding Agent 時談過同樣的病。

- 過度認真：要快速摘要，回來兩千字學術分析。解法在 Clarify 階段：把輸出規格（長度、深度、格式）寫進任務定義，不要事後抱怨。

- 努力錯配：簡單問題派大軍、複雜問題只派一個。努力分級規則是 Plan 階段的必備品。

一句話：Deep Research 的工程，七成在「什麼時候停、派多少人、查多深」，三成在模型本身。

八、動手：一個最小可跑的骨架

LangChain 的 create_deep_agent 把這套流程封裝好了，但骨架自己寫也不難。核心是一個「計畫 → 平行檢索 → 驗證 → 綜合」的迴圈：

def deep_research(question, search, max_hops=6):
    plan = llm(f"把研究問題拆成可並行的子問題：{question}\n"
               "輸出 JSON：[{\"subq\": ..., \"why\": ...}]")
    evidence = []
    for hop in range(max_hops):
        # 每輪：子問題平行檢索（實務上用 asyncio.gather）
        results = [search(sq["subq"]) for sq in plan]
        notes = llm(f"從檢索結果提煉事實，標註來源 URL：\n{results}\n"
                    "輸出：已確認的事實 / 仍缺的資訊 / 下一輪查詢")
        evidence.append(notes)
        if notes["仍缺的資訊"] == "無":
            break
        plan = [{"subq": q} for q in notes["下一輪查詢"]]  # 缺口驅動改寫
    # 驗證：逐主張回查
    checked = llm(f"逐條驗證以下主張，每條註明來源或標記存疑：\n{evidence}")
    return llm(f"寫成結構化報告（摘要、發現、來源表、後續問題）：\n{checked}")

三個實作要點，對應上面的架構：

1. 檢索回傳結構化記錄（去重後的事件、來源 URL、日期、後設資料），而不是連結清單。Agent 看不到乾淨的資料，就寫不出可引用的報告。

2. 缺口驅動的查詢改寫：每一輪的下一批查詢來自「還缺什麼」，而不是預先寫死的清單。這是 Deep Research 與固定管線 RAG 的本質差別。

3. 驗證獨立成步：綜合之前先跑一輪「主張 → 來源」的對帳，通過的才進報告。

起手清單

1. 先定義深度等級（quick／standard／deep）與每級的 Agent 數、工具呼叫上限——努力分級寫在提示詞裡，不要靠模型自覺。

2. 子 Agent 的任務包一次給齊：目標、輸出格式、工具與來源指引、職責邊界。

3. 檢索層回傳結構化記錄；子 Agent 的大輸出寫檔、只回傳引用。

4. 驗證獨立成步：主張逐條回查，矛盾與不確定直接寫進報告。

5. 準備 20 個多跳題目當考卷，評分只看產出的事實正確率與引文覆蓋率。

6. 上線前算 token 帳：15 倍是常態，先設限次與預算告警。

結論

Deep Research Agent 把「查資料」從一次性的問答，變成一條可稽核的管線：對齊、計畫、平行執行、驗證、報告。它的效能主要不來自更大的模型，而來自編排——Anthropic 用同一代模型、只改架構就拿下 90.2% 的提升；STORM 則證明，連「怎麼提問」都可以系統化（多視角提問讓文章組織性提升 25 個百分點）。

但它也是最貴的 Agent 形態：15 倍 token、分鐘級執行、限次供應。什麼時候該用它，答案很單純——當答案不存在於任何單一頁面、而你需要一份「敢拿去做決策」的報告時。

資料來源

- Anthropic 工程部落格〈How we built our multi-agent research system〉：LeadResearcher 加子 Agent 架構、努力分級、90.2% 提升、15 倍 token（第三方整理：https://agentic-ai.readthedocs.io/en/latest/ContextEngineering/anthropic/ ）

- 史丹佛 STORM 研究計畫（NAACL 2024）：多視角提問、pre-writing／writing 兩階段：https://storm-project.stanford.edu/research/storm/

- DeepResearchEval（arXiv 2026）：自動化任務建構、自適應評分、主動事實驗證：https://liner.com/review/deepresearcheval-automated-framework-for-deep-research-task-construction-and-agentic

- Marco DeepResearch（arXiv 2026）：以驗證為中心的設計：https://arxiv.org/html/2603.28376v1

- LangChain 教學〈How to Build a Deep Research Agent〉：研究執行的生命週期：https://www.newscatcherapi.com/blog-posts/build-deep-research-agent-catchall-langchain

- 2026 年 Deep Research 產品橫評：https://ai.blocksize.hr/blog/en/deep-research-ai-agents-2026.html