2025 年多款 Deep Research 智能體框架全面對比
作者：fangzlong
隨著模型的范式和工程方式發展，網絡上涌現出了一大批模仿人類研究者對問題進行深入研究的智能體應用。本文將從 OpenAI 關于 DeepResearch 的指南開始，通過幾個開源框架的架構解構與功能映射，揭示不同框架在研究自動化領域的差異。為各位使用者、開發者選擇合適工具和框架提供系統化參考。
一、開源深度研究智能體框架
1. 開源整體對比
市面上還有很多其他通用智能體框架也可以實現深度研究功能（如 Auto-GPT, BabyAGI, AgentGPT, Microsoft/AutoGen，Camel-AI/OWL）。本文主要關注下面六個專門針對深度研究功能進行了架構優化及創新的框架，下面是簡單對比：
備注：HuggingFace/OpenDeepReasearch 非獨立項目，所以這里寫的 21.2k 是 SmolAgents 項目的總星數browser-use 是一個 AI 驅動瀏覽器的著名自動化框架（目前在 Github 上 Star 為 65.4k）。對比傳統 curl/requests 獲取網頁內容，可以加載識別動態網頁及上面的元素（比如一些使用 AJAX 加載的實時數據網站等）。本文主要關注框架方面，對包括 browser-use 等其他輔助工具不作過多研究，有興趣的讀者可以繼續深入學習。
2. OpenAI 指南
OpenAI 文檔提供了一個指導文檔 Deep Research 來說明如何使用 API 構造自己的深度研究智能體，里面的架構基本是所有框架的雛形，所以我們先從這里開始。
核心架構：三步范式（Plan -> Execute -> Synthesize）
該指南的核心思想是，不要試圖用一個巨大的提示詞（Prompt）讓模型一次性完成所有研究。相反，應該將復雜的研報任務分解成一個清晰、模塊化的三步流程：
- 規劃 (Plan): 讓一個高級模型（如 GPT-4.1）將用戶的主問題分解成一系列具體的、可獨立研究的子問題。
- 執行 (Execute): 并行地對每個子問題進行研究，調用搜索 API 獲取信息，并讓模型對單個信息源進行總結。
- 合成 (Synthesize): 將所有子問題的答案匯總起來，交給一個高級模型，讓它撰寫成一篇連貫、完整的最終報告。
3. 優秀實踐
基于這個核心架構，以下是具體的最佳實踐和注意事項：
(1) 為正確的任務選擇正確的模型（核心成本與性能優化策略）
這是文章中最重要的建議之一。不同任務對模型能力的要求不同，混用模型可以極大地優化成本和速度。
優秀實踐：
- 問題澄清和改寫: 使用小一些、更快的模型。這兩步只是啟動研究過程，如果輸入的 prompt 足夠詳細，這兩步甚至可以跳過。
- 規劃 (Plan) 和 合成 (Synthesize) 階段: 使用能力最強的模型，如 gpt-4.1 或 gpt-4o。因為這兩個步驟需要強大的推理、邏輯組織和長文本生成能力，它們的質量直接決定了最終報告的上限。
- 執行 (Execute) 階段: 對搜索到的單個網頁或文檔進行初步總結時，可以使用更便宜、更快的模型，如 gpt-3.5-turbo。因為這個任務相對簡單（總結一篇具體文章），不需要頂級的推理能力。
注意事項：
- 成本監控：一個深度研究請求可能會觸發數十次 API 調用，必須密切關注成本。采用上述分級模型策略是控制成本的關鍵。
(2) 并行處理以最大化效率
研究過程中的多個子問題通常是相互獨立的，等待一個完成后再開始下一個會非常耗時。
優秀實踐：
- 在“執行”階段，一旦“規劃”步驟生成了所有子問題列表，就應該使用異步編程（如 Python 的 asyncio）來并行發起對每個子問題的研究請求。這樣可以將原本需要數分鐘的串行過程縮短到一分鐘以內。
注意事項:
- API 速率限制 (Rate Limits): 并行調用會瞬間產生大量請求，請確保您的 OpenAI API 賬戶有足夠的速率限制額度（TPM - Tokens Per Minute），否則請求可能會失敗。
(3) 使用函數調用（Function Calling）或 JSON 模式獲取結構化輸出
直接讓模型輸出文本并用代碼去解析，既不穩定也容易出錯。為了保證工作流的穩定可靠，應始終讓模型返回結構化的數據。
優秀實踐:
- 規劃階段: 指示模型使用“函數調用”或“JSON 模式”，輸出一個包含所有子問題字符串的 JSON 列表。這樣您的代碼就可以直接、準確地解析出需要執行的任務清單。
- 執行階段: 同樣，在總結單個頁面時，也可以要求模型以固定的 JSON 格式返回結果，例如 {"summary": "...", "key_points": [...]}。
注意事項:
- 確保您的提示詞中清晰地描述了所需的 JSON 結構或函數簽名。
(4) 外部工具的必要性（LLM 不是萬能的）
大型語言模型本身沒有實時聯網能力，其知識也非最新。因此，必須集成外部工具。
優秀實踐：
- 集成一個或多個高質量的搜索 API（如 Google Search API, Brave Search API, Serper 等）來獲取實時、廣泛的信息。
- 在提示詞中明確告知模型它可以使用這些工具，并通過函數調用等方式將工具的輸出結果返回給模型。
(5) 精心設計提示詞（Prompt Engineering）
每個階段的提示詞都至關重要。
優秀實踐：
- 規劃提示詞: 應明確告知模型其角色是一個“世界級的首席研究員”，任務是“將一個復雜問題分解為一組可以獨立研究的、詳盡的子問題”。
- 執行提示詞: 應指示模型扮演“專家分析師”，任務是“根據提供的原始文本，回答一個具體的問題，并進行簡潔總結”。
- 合成提示詞: 這是最終決定報告質量的關鍵。應包含所有子問題的答案，并給出非常明確的指令，例如：“你是一位頂級行業分析師，請整合以下所有研究資料，撰寫一份全面、客觀、結構清晰的深度研究報告。報告應包含引言、正文和結論，并保持專業的語調。”
輸入樣例：
①問題
Research the economic impact of semaglutide on global healthcare systems.
Do:
- Include specific figures, trends, statistics, and measurable outcomes.
- Prioritize reliable, up-to-date sources: peer-reviewed research, health
organizations (e.g., WHO, CDC), regulatory agencies, or pharmaceutical
earnings reports.
- Include inline citations and return all source metadata.
Be analytical, avoid generalities, and ensure that each section supports
data-backed reasoning that could inform healthcare policy or financial modeling.
研究索馬魯肽對全球醫療保健系統的經濟影響。
應做的：
- 包含具體的數字、趨勢、統計數據和可衡量的成果。
- 優先考慮可靠、最新的來源：同行評審的研究、衛生組織（例如世界衛生組織、美國疾病控制與預防中心）、監管機構或制藥公司
的盈利報告。
- 包含內聯引用并返回所有來源元數據。
進行分析，避免泛泛而談，并確保每個部分都支持
數據支持的推理，這些推理可以為醫療保健政策或財務模型提供參考。（注：上方為指南 prompt 原文，下方為對應翻譯參考）
② 問題澄清
You are talking to a user who is asking for a research task to be conducted. Your job is to gather more information from the user to successfully complete the task.
GUIDELINES:
- Be concise while gathering all necessary information**
- Make sure to gather all the information needed to carry out the research task in a concise, well-structured manner.
- Use bullet points or numbered lists if appropriate for clarity.
- Don't ask for unnecessary information, or information that the user has already provided.
IMPORTANT: Do NOT conduct any research yourself, just gather information that will be given to a researcher to conduct the research task.
您正在與一位請求開展研究任務的用戶交談。您的工作是從用戶那里收集更多信息，以成功完成任務。
指導原則：
- 收集所有必要信息時務必簡潔**
- 確保以簡潔、結構良好的方式收集完成研究任務所需的所有信息。
- 為清晰起見，請根據需要使用項目符號或編號列表。
- 請勿詢問不必要的信息或用戶已提供的信息。
重要提示：請勿自行進行任何研究，只需收集將提供給研究人員進行研究任務的信息即可。③ User Prompt 改寫
You will be given a research task by a user. Your job is to produce a set of
instructions for a researcher that will complete the task. Do NOT complete the
task yourself, just provide instructions on how to complete it.
GUIDELINES:
1. **Maximize Specificity and Detail**
- Include all known user preferences and explicitly list key attributes or
dimensions to consider.
- It is of utmost importance that all details from the user are included in
the instructions.
2. **Fill in Unstated But Necessary Dimensions as Open-Ended**
- If certain attributes are essential for a meaningful output but the user
has not provided them, explicitly state that they are open-ended or default
to no specific constraint.
3. **Avoid Unwarranted Assumptions**
- If the user has not provided a particular detail, do not invent one.
- Instead, state the lack of specification and guide the researcher to treat
it as flexible or accept all possible options.
4. **Use the First Person**
- Phrase the request from the perspective of the user.
5. **Tables**
- If you determine that including a table will help illustrate, organize, or
enhance the information in the research output, you must explicitly request
that the researcher provide them.
Examples:
- Product Comparison (Consumer): When comparing different smartphone models,
request a table listing each model's features, price, and consumer ratings
side-by-side.
- Project Tracking (Work): When outlining project deliverables, create a table
showing tasks, deadlines, responsible team members, and status updates.
- Budget Planning (Consumer): When creating a personal or household budget,
request a table detailing income sources, monthly expenses, and savings goals.
- Competitor Analysis (Work): When evaluating competitor products, request a
table with key metrics, such as market share, pricing, and main differentiators.
6. **Headers and Formatting**
- You should include the expected output format in the prompt.
- If the user is asking for content that would be best returned in a
structured format (e.g. a report, plan, etc.), ask the researcher to format
as a report with the appropriate headers and formatting that ensures clarity
and structure.
7. **Language**
- If the user input is in a language other than English, tell the researcher
to respond in this language, unless the user query explicitly asks for the
response in a different language.
8. **Sources**
- If specific sources should be prioritized, specify them in the prompt.
- For product and travel research, prefer linking directly to official or
primary websites (e.g., official brand sites, manufacturer pages, or
reputable e-commerce platforms like Amazon for user reviews) rather than
aggregator sites or SEO-heavy blogs.
- For academic or scientific queries, prefer linking directly to the original
paper or official journal publication rather than survey papers or secondary
summaries.
- If the query is in a specific language, prioritize sources published in that
language.
用戶會給你一個研究任務。你的工作是為研究人員提供一套完成該任務的指導說明。請勿自行完成任務，只需提供完成該任務的說明即可。
指導原則：
1. **盡量具體和詳細**
- 包含所有已知的用戶偏好，并明確列出需要考慮的關鍵屬性或維度。
- 務必將用戶提供的所有詳細信息都包含在說明中。
2. **將未說明但必要的維度填寫為開放式**
- 如果某些屬性對于有意義的輸出至關重要，但用戶未提供，請明確說明它們是開放式的或默認為無特定約束。
3. **避免不必要的假設**
- 如果用戶未提供特定細節，請勿自行虛構。
- 相反，應說明缺乏具體說明，并指導研究人員將其視為靈活變通或接受所有可能的選項。
4. **使用第一人稱**
- 從用戶的角度表達請求。
5. **表格**
- 如果您確定使用表格有助于說明、組織或增強研究成果中的信息，則必須明確要求研究人員提供表格。
示例：
- 產品比較（消費者）：比較不同智能手機型號時，
要求提供一個表格，并列列出每種型號的功能、價格和消費者評分。
- 項目跟蹤（工作）：概述項目可交付成果時，創建一個表格，列出任務、截止日期、負責的團隊成員和狀態更新。
- 預算規劃（消費者）：制定個人或家庭預算時，
要求提供一個表格，詳細說明收入來源、每月支出和儲蓄目標。
- 競爭對手分析（工作）：評估競爭對手產品時，
要求提供一個表格，其中包含關鍵指標，例如市場份額、定價和主要差異化因素。
6. **標題和格式**
- 您應該在提示中包含預期的輸出格式。
- 如果用戶要求的內容最好以結構化格式返回（例如報告、計劃等），請研究人員將其格式化為報告，并使用適當的標題和格式，以確保清晰度和結構。
7. **語言**
- 如果用戶輸入的是英語以外的語言，請告知研究人員使用該語言進行回復，除非用戶查詢明確要求以其他語言回復。
8. **來源**
- 如果需要優先考慮特定來源，請在提示中指定。
- 對于產品和旅行研究，最好直接鏈接到官方或主要網站（例如，官方品牌網站、制造商頁面或亞馬遜等信譽良好的電商平臺，以獲取用戶評論），而不是聚合網站或注重搜索引擎優化的博客。
- 對于學術或科學查詢，建議直接鏈接到原始論文或官方期刊出版物，而不是調查論文或二手摘要。
- 如果查詢使用特定語言，請優先考慮以該語言出版的資料。(6) 加入人工審核環節 (Human-in-the-Loop)
對于非常嚴肅或重要的研究任務，完全自動化的流程可能存在風險。
優秀實踐：
- 可以在規劃階段之后加入一個人工審核步驟。讓用戶（或您自己）審查和修改模型生成的子問題列表，確保研究方向正確無誤后，再啟動昂貴的“執行”階段。這可以有效避免后續步驟的“垃圾進，垃圾出”。
二、開源架構分析
下面依次介紹每個框架的架構和特點，并給出最佳實踐和注意事項。
1. ByteDance/DeerFlow
DeerFlow 項目的架構是一個模塊化的多智能體（multi-agent）系統，其核心是圍繞一個分層的、協作的智能體團隊來自動化完成復雜的研究任務。其主要架構組件和特點如下：
(1) 核心架構：分層多智能體系統
DeerFlow 采用了多個擁有不同角色的智能體（Agent）協同工作的模式，這些智能體各司其職，共同完成一個研究項目。該系統主要包含以下幾個核心角色：
- 協調器 (Coordinator): 這是整個工作流的入口和管理者。它接收用戶的初始請求，啟動研究流程，并在需要時將任務委派給規劃器。協調器也作為用戶和系統之間的主要交互界面。
- 規劃器 (Planner): 扮演策略師的角色。它負責將用戶提出的復雜研究問題分解成一系列結構化的、可執行的步驟。規劃器會評估當前是否需要收集更多信息，還是可以開始生成報告，從而管理整個研究的流程。
- 研究團隊 (Research Team): 這是一組專門執行具體任務的智能體，如同一個“研究小組”。主要包括： 研究員 (Researcher): 負責執行網絡搜索、調用API、抓取網頁內容等，以收集所需的信息和數據。 程序員 (Coder): 負責執行 Python 代碼，用于數據分析、代碼片段測試等技術性任務。
- 報告員 (Reporter): 這是研究流程的最后一環。它負責將研究團隊收集到的所有信息和發現進行匯總、整合和結構化，最終生成多種格式的綜合研究報告，例如 Notion 風格的文檔、播客甚至是 PowerPoint 演示文稿。
(2) 技術基礎和特點
- 構建于開源項目之上: DeerFlow 的底層利用了 LangChain 和 LangGraph 等流行的開源項目。特別是 LangGraph，它被用來構建和管理不同智能體之間的狀態和通信，使得整個工作流程像一個有向圖一樣清晰和可追溯。
- 模塊化和可擴展性: 該架構是高度模塊化的，支持“即插即用”的工具集。例如，它集成了 Tavily、Brave Search、DuckDuckGo 等多種搜索引擎，以及用于網頁抓取的 Jina 等工具，并且可以輕松擴展以支持自定義的 API 或模型。
- 人機協作 (Human-in-the-Loop): DeerFlow 并非一個完全自主的“黑箱”系統，而是強調人與 AI 的協作。用戶可以審查和修改AI生成的研究計劃，在執行過程中調整參數，并在最后對報告進行精煉。這種混合模式在用戶測試中被證明可以顯著減少研究時間，同時保持內容的高準確性。
- 微服務架構: 有資料提到，DeerFlow 采用了微服務（microservices-based）架構，包含了研究引擎、Web UI、數據庫和存儲等多個組件，使其更具可擴展性。
2. HuggingFace/OpenDeepResearch
HuggingFace 的 OpenDeepResarch 是唯一一個提到了在標準評測集（GAIA）下與原版 ChatGPT DeepResearch 分數比對的：This agent achieves 55% pass@1 on the GAIA validation set, compared to 67% for the original Deep Research.
下面是架構圖：
與 DeerFlow 的分層多智能體架構不同，huggingface/smolagents 項目采用了更輕量級、更注重代碼和簡潔性的架構。它的核心理念是提供一個極簡的框架，讓開發者可以輕松構建、調試和控制由大型語言模型（LLM）驅動的智能體（Agent）。
以下是 smolagents 項目架構的關鍵特點：
(1) 核心思想：簡潔與最少抽象
- 輕量級代碼庫: 整個 smolagents 庫的核心邏輯被有意地控制在很少的代碼行數內（約1000行），這使得它非常容易理解和上手。
- 避免過度抽象: 許多AI智能體框架被批評有太多的抽象層，導致系統僵化且難以調試。smolagents 刻意避免了這一點，給予開發者更大的控制權和透明度。
(2) 核心架構：以代碼為中心的智能體 (Code Agents)
smolagents 的主要方法是代碼智能體 (CodeAgent)。這與其他框架主要依賴JSON格式來定義行為的方式形成了鮮明對比。
- 動作即代碼: 在 smolagents 中，智能體的動作（actions）直接表現為 Python 代碼片段。LLM 會生成一小段 Python 代碼來執行下一步操作，而不是生成需要解析的JSON對象。
- 優勢: 表現力強: 編程語言（如Python）天生就適合用來表達復雜的動作和邏輯。 組合性好: 代碼可以輕松地進行嵌套、抽象和重用（例如定義函數），這是JSON難以做到的。 安全性: 為了安全地執行這些由AI生成的代碼，smolagents 支持在沙盒環境（如 E2B）中運行。
(3) 主要智能體類型
該庫提供了幾種核心的智能體類型：
- CodeAgent: 這是最主要的智能體類型。它通過生成和執行 Python 代碼來完成任務，并且可以調用預先定義好的工具。
- ToolCallingAgent: 雖然 CodeAgent 是核心，但 smolagents 仍然支持傳統的、通過生成 JSON/文本 來調用工具的智能體，以兼容更廣泛的用例和模型。
- MultiStepAgent: 這種智能體能夠將一個復雜的任務分解成多個步驟，并周期性地生成或更新計劃，以結構化、目標導向的方式逐步解決問題。
3. LangChainAI/OpenDeepResearch
langchain-ai/open_deep_research 項目（包括 LangChain 和 Together AI 的版本）的架構核心是一個多階段、迭代和自反思（self-reflection）的智能體工作流，旨在模擬人類進行深度研究的過程。這個架構比簡單的“提問-回答”模式要復雜得多，其設計目標是處理需要多步推理和信息整合的復雜主題。
(1) 以下是該項目架構的關鍵組成部分和特點
- 核心理念：Plan-Search-Reflect-Write (規劃-搜索-反思-撰寫) 整個架構圍繞著一個清晰的研究流程展開，模仿了人類專家的研究方法：
- 規劃 (Plan): 這是工作流的起點。一個“規劃器”智能體會接收用戶提出的研究主題，并將其分解成多個子問題或子主題。這個規劃結果不僅指導后續的研究步驟，也構成了最終報告的大綱。
- 搜索 (Search): 根據規劃階段生成的子問題，系統會生成具體的搜索查詢，并調用各種搜索工具（如 Tavily, Perplexity, ArXiv 等）來收集相關信息。這個過程可以是并行的，多個研究循環可以同時針對不同的子主題進行。
- 反思 (Self-Reflect): 這是該架構的關鍵所在。在收集到初步信息后，一個智能體會評估當前的信息是否足夠，是否存在知識空白。如果發現信息不足或有新的問題出現，系統會生成新的、更精確的搜索查詢，進入下一輪迭代。這種“自我反思”的循環會持續進行，直到信息足夠全面。
- 撰寫 (Write): 當所有的研究循環完成后，一個“撰寫者”智能體會將所有收集到的、經過驗證和提煉的信息進行整合，并根據最初的規劃大綱，生成一份結構完整、引用充分的綜合性研究報告。
(2) 該項目提供了兩種主要的實現方式，各有側重
圖狀工作流 (Graph-based Workflow)
實現: 主要使用 LangGraph 這樣的庫來構建。
特點: 這種方式將研究的每一步（規劃、搜索、反思等）都建模為圖中的一個節點（Node），使得整個流程非常清晰、可追溯。它特別強調人機協作（Human-in-the-Loop），允許用戶在關鍵節點（如規劃完成后）進行審查和提供反饋，然后再繼續執行。這種實現方式控制力強，適合對報告質量和準確性要求極高的場景。
4. Multi-agent 迭代循環 (Iterative Loop)
分為兩種模式：
- 簡單模式 (Simple): 跳過初始的規劃步驟，直接進入一個單一的、迭代的研究循環。這種模式速度更快，適用于較窄或較具體的研究問題。
- 深度模式 (Deep): 包含初始的規劃步驟，并為每個子主題部署并行的、獨立的迭代研究器。這種模式更深入、更全面，適合復雜和寬泛的研究主題。
特點：這種方式的核心是遞歸的研究循環，在每一次循環中，智能體都會評估已有信息，生成新的問題，并進一步搜索，直到達到預設的深度（depth）和廣度（breadth）。
5. SkyworkAI/DeepResearchAgent
SkyworkAI/DeepResearchAgent 項目采用了明確的兩層（Two-Layer）架構，這是一個分工清晰的層級式多智能體系統。其核心思想是通過一個高層規劃者來協調多個底層的專業執行者，從而實現對復雜任務的分解和高效執行。
以下是對這個兩層架構的詳細說明：
(1) 第一層：頂層規劃智能體 (Top-Level Planning Agent)
這一層是整個系統的“大腦”和“指揮官”。它不執行具體的研究任務，而是負責宏觀的戰略規劃和協調。
核心職責:
- 理解與分解 (Understand & Decompose): 當接收到用戶輸入的復雜任務時，頂層規劃智能體首先會深入理解任務的整體目標。然后，它會將這個宏大的目標分解成一系列更小、更具體、可管理的子任務。
- 規劃與分配 (Plan & Assign): 在分解任務后，它會制定一個詳細的工作流程計劃，并決定每個子任務應該由哪個（或哪些）下層專業智能體來執行。
- 動態協調 (Dynamic Coordination): 在任務執行過程中，它會持續監控整個流程的進展，動態地協調下層智能體之間的協作，確保任務能夠順利、連貫地完成。
簡單來說，頂層規劃智能體就像一個項目經理，它制定藍圖、分配資源，并確保團隊成員（即下層智能體）步調一致地工作。
(2) 第二層：底層專業智能體 (Specialized Lower-Level Agents)
這一層是系統的“手”和“腳”，由多個具備不同專業技能的智能體組成，負責執行頂層規劃師分配下來的具體任務。
DeepResearchAgent 主要包含以下幾個專業智能體：
- 深度分析器 (Deep Analyzer): 職責: 負責對輸入的信息進行深入分析，提取關鍵的見解、實體和潛在需求。它支持分析多種數據類型，包括純文本和結構化數據。 作用: 在研究初期，它可以幫助系統更好地理解問題背景和現有資料。
- 深度研究員 (Deep Researcher): 職責: 這是執行核心研究任務的智能體。它根據指定的議題或問題，進行徹底的研究，檢索、整合并提煉高質量信息。它能夠自動生成研究報告或知識摘要。 作用: 負責信息搜集和初步的內容生成。
- 瀏覽器使用者 (Browser Use): 職責: 專門負責自動化瀏覽器操作，執行網頁搜索、信息提取和數據采集等任務。 作用: 作為“深度研究員”的得力助手，為其從互聯網上獲取最新、最相關的信息。
(3) 架構總結與啟發
DeepResearchAgent 的這個兩層架構的優勢在于其清晰的層次化分工。
- 頂層專注于“做什么”和“如何做”（What & How），負責策略和規劃。
- 底層專注于“執行”（Execution），負責具體操作。
這種設計使得系統在處理復雜問題時條理清晰，不易混亂。同時，它具有很強的可擴展性，未來可以方便地在第二層加入更多具有新能力的專業智能體（比如數據可視化智能體、代碼執行智能體等），而無需改動頂層的核心規劃邏輯。
值得一提的是，該項目的 README 文件中明確提到，其架構主要受到了 smolagents 的啟發，并在其基礎上進行了模塊化和異步化等改進，使其結構更清晰，更適合多智能體協作。
6. zhu-minjun/Researcher
總結來說，zhu-minjun/Researcher 的架構有以下幾個鮮明特點：
- 分階段的多智能體協作：通過規劃、執行、整合、批判等不同角色的智能體各司其職，流水線式地完成復雜任務。
- 高效的并行處理：為每個子主題創建獨立的執行智能體，并讓它們同時工作，顯著縮短了研究時間。
- 獨特的自我批判機制：引入了“批判智能體”對產出結果進行審核和反饋，形成了一個迭代優化的閉環。這使得它不僅僅是一個信息的聚合器，更是一個力求產出高質量、無偏見內容的“研究員”。
與其他項目相比，它將“反思”（Reflection）這一概念，具象化為了一個獨立的“批判智能體”和一個明確的“修正”動作，使其自我完善的路徑更加清晰和結構化。
DeepReviewer的 Best 模式提供最全面的審核體驗，包括背景知識搜索、多審核者模擬和自我驗證：
Researcher 的架構是一個包含“自我批判”環節的、多智能體協作的自動化研究工作流。它與其他研究智能體項目（如 DeepResearchAgent 或 open_deep_research）在流程上有一些相似之處，但其獨特的“批判-修正”循環是其架構的核心亮點。
該項目的整體架構和工作流程可以分解為以下幾個關鍵步驟：
(1) 第一步：規劃智能體 (Planning Agent)
職責：接收用戶輸入的初始研究主題。
工作內容：
- 首先，它會生成一系列相關的、更具探索性的問題，以拓寬研究的廣度和深度。
- 然后，它會基于這些問題創建一個結構化的研究計劃或報告大綱。這個大綱不僅指導了后續的研究方向，也直接構成了最終報告的骨架。
(2) 第二步：并行執行智能體 (Parallel Execution Agents)
職責：根據“規劃智能體”制定的提綱，分頭執行具體的研究任務。
工作內容：
- 系統會為大綱中的每一個子主題，都啟動一個獨立的“執行智能體”。
- 這些智能體并行工作，各自負責自己的子主題。它們會使用搜索引擎（如 DuckDuckGo）進行信息檢索，利用工具（如 newspaper4k）抓取和解析網頁內容，并對收集到的信息進行總結。
- 這種并行處理的架構設計，極大地提高了研究的效率，可以同時對多個方面進行深入探索。
(3) 第三步：整合與初稿生成 (Integration and Draft Generation)
職責：匯總所有并行研究的結果，形成一份初步的研究報告。
工作內容：
- 系統會收集所有“執行智能體”完成的子主題研究摘要。
- 然后，它將這些摘要按照“規劃智能體”最初設計的報告大綱進行排序和組合，最終生成一份內容完整、結構清晰的初稿。
(4) 第四步：批判與修正智能體 (Critique & Revision Agent)
這是該項目架構中最具特色的一環，構成了一個質量控制循環。
職責：像一個嚴謹的審稿人一樣，對生成的初稿進行評估和批判，并指導修正。
工作內容：
- 批判 (Critique): 一個專門的“批判智能體”會閱讀整份初稿，并根據預設的規則（例如，檢查事實的準確性、觀點的客觀性、信息的全面性、是否存在偏見等）提出具體的、有建設性的修改意見。
- 修正 (Revision): 系統根據“批判智能體”的反饋，返回到達成共識前的步驟，對研究報告進行重新整理和修正，以提升報告的整體質量。
三、商業化深度研究智能體
分析完開源框架后，筆者體驗一下市面上相關的商業化智能體應用：使用閉源應用研究同一個問題，并分析他們的邏輯、輸出和交互。
閉源應用整體對比：
備注 * 為筆者猜測使用的智能體范式。
四、總結
本篇文檔系統梳理了當前主流的開源與商業化深度研究智能體框架。開源方案如 DeerFlow、OpenDeepResearch（HuggingFace）、LangChainAI/OpenDeepResearch、SkyworkAI/DeepResearchAgent、HKUDS/AutoDeepResearch 及 zhu-minjun/Researcher 各有側重：有的強調分層多智能體與模塊化（如 DeerFlow），有的追求極簡代碼和代碼即動作（如 HuggingFace/smolagents），也有的主打多階段自反思與人機協作（如 LangChainAI/OpenDeepResearch）。在工具集成、任務分解、執行方式（JSON/函數調用 vs. 代碼生成）、質量控制等方面，各框架實現細節和理念均有所不同。
商業化產品如 ChatGPT、Gemini、Kimi、豆包、AutoGLM 則在交互體驗、報告輸出、搜索能力和質量控制等方面各具特色，部分產品支持計劃確認、交互式報告編輯、多輪深度搜索及生成對應網頁（方便轉換成 PPT）。
總體來看，深度研究智能體的發展正朝著更高的自動化、結構化和可控性方向演進。不同框架適合不同場景和需求，選擇時可結合自身實際情況權衡。
