深度研究Agent架構解析：4種Agent架構介紹及實用Prompt模板

深度搜索Agent核心問題其實就有兩個：怎么把復雜問題拆得合理，以及怎么判斷搜索結果夠不夠用。近兩年深度搜索Agent發展很快各家的實現思路也越來越成熟，圍繞這兩個問題業界逐漸沉淀出幾種主流架構：從最基礎的Planner-Only，到加入評估反饋的雙模塊設計，再到Sentient Labs提出的遞歸式方案。這篇文章將整理這些架構并順便附上一些實用的prompt模板。

迭代式搜索Agent

在討論更復雜的架構之前，先回顧一下最基礎的迭代式搜索Agent。這類Agent通常基于ReAct（Reasoning and Acting）范式，工作流程很簡單：接收問題→思考→調用工具搜索→觀察結果→繼續思考→再搜索...如此循環直到找到滿意的答案。

但是這種簡單的迭代模式有個問題：當面對復雜查詢時單線程一步步搜效率太低。于是就有了并行工作流的思路，把一個大問題拆成多個子查詢，讓多個搜索任務同時跑。

Planner-Only架構

但并行工作流又有個明顯的短板：子查詢數量是寫死的。實際情況是簡單問題拆2-3個子查詢就夠了，而復雜問題可能要拆5-6個甚至更多。也就是說子查詢的拆分應該是動態的而不是預先固定。

Planner LLM就是為解決這個問題產生的。它的作用很簡單，就是分析用戶問題的復雜度，決定應該拆成多少個子任務，每個子任務負責什么，以及應該調用哪些工具。

一個典型的Planner提示詞結構如下：

# MAKE A STRATEGY/PLAN, YOU HAVE ACCESS TO FOLLOWING TOOLS
? describe tools & their input parameters here
# GUIDELINES FOR QUERY COMPLEXITY, TOOL CALLS & #SUBAGENTS
? simple fact finding queries requires just 1 subtask with 3-10 tool calls.
? direct comparison queries might need 2-5 subtasks with 10-15 tools call each.
? complex research might use more than 10 subtasks with clearly divided responsibilities
# CLEARLY DEFINE EACH SUBAGENT'S ROLE IN FOLLOWING FORMAT
{
objective :-
output_format :-
tool_guidance :-
rationale :-
}
# HEURISTICS FOR TOOL GUIDANCE (basically here we are doing Tool RAG)
examine all available tools first, match tool usage to subagent objective,
search the web only for broad external information or prefer specialized tools
over generic ones.

這個提示詞模板的設計思路值需要注意的是：首先告訴Planner有哪些工具可用，然后給出不同復雜度問題的拆分參考標準，最后要求它為每個子Agent明確定義目標、輸出格式和工具使用指導。這樣Planner輸出的計劃才足夠具體，下游的執行Agent才能照著執行。

Planner承擔的任務復雜度高是整個架構的核心節點。所以強烈建議用推理能力強的模型來做Planner，比如GPT-4o、Claude 3.5 Sonnet或者專門的推理模型如o1、DeepSeek-R1等。

停止條件的處理

有了Planner問題拆分的問題解決了，但還有另一個老問題：ReAct循環什么時候該停？

傳統做法是手動設一個固定閾值靠經驗調參比如最多跑5輪，但這顯然不夠靈活，因為復雜查詢需要更多輪迭代，簡單查詢幾輪就夠了。固定閾值要么會讓簡單問題跑太多輪浪費資源，要么會讓復雜問題提前結束拿不到完整答案。

所以解決辦法是引入一個評估器LLM，每輪迭代后讓評估器判斷當前答案是否已經足夠好，如果夠好就停不夠就繼續跑。

評估器的提示詞可以這樣寫：

# TASK
Your task is to analyse and determine if following information is sufficient
or there are knowledge gaps?? Provide reasoning for your answer
# Question
add here the user question
# Generated Answer
add here the answer generated by this iteration of ReAct
# OUTPUT FORMAT
{
"is_sufficient": true/false
"reasoning":
"knowledge_gap":
}

評估器需要做兩件事：判斷當前答案是否充分，以及如果不充分的話缺的是什么。knowledge_gap字段很關鍵，它可以指導下一輪迭代應該往哪個方向搜。

澄清問題機制

OpenAI在評估器的基礎上又加了一層設計。他們觀察到有些特別刁鉆的問題LLM怎么搜都找不到滿意的答案，評估器一直返回is_sufficient = false循環就沒完沒了。

這種情況往往不是搜索能力的問題而是問題本身定義不清，比如用戶問"最好的筆記本電腦是哪個"，這里的"最好"指什么？性價比最高？性能最強？便攜性最好？不同的理解會導向完全不同的搜索方向。

所以OpenAI的方案是：當評估器發現反復搜索都無法得到充分答案時，不如讓Agent主動問用戶幾個澄清問題，把人拉進來幫忙明確需求。這就是所謂的human-in-the-loop設計。

檢查清單評分

而SamayaAI提出了另一種評估思路：檢查清單評分，這個方案對長篇幅答案特別有效。

傳統評估器面對長答案容易"暈"，單個LLM很難在一大段文本里保持完整的推理鏈，上下文一長就開始丟信息，評估結果也就不太靠譜了。SamayaAI的想法是，與其讓評估器去理解和評判整個答案的內容質量不如換個角度來評估答案是否符合預設的結構規范，這個結構規范就是所謂的檢查清單。

比如說，如果用戶問的是"對比A和B兩個產品"檢查清單可能包括：是否分別介紹了A和B的特點？是否有價格對比？是否有優缺點總結？是否給出了推薦建議？評估器只需要逐項打勾比從頭讀完整個答案再打分要簡單得多。

# TASK
Your task is to analyse and determine if the answer follows following checklist
or not. If not the identify knowledge gaps. Provide reasoning for your answer.
# Question
add here the user question
# Generated Answer
add here the answer generated by this iteration of ReAct
# Checklist
add your checklist here
# OUTPUT FORMAT
{
"is_sufficient": true/false
"reasoning":
"knowledge_gap":
}

Planner + Plan Evaluator雙模塊架構

前面說的評估器主要是評估搜索結果，但其實Planner生成的計劃本身也可能有問題。于是就有了Planner + Plan Evaluator的雙模塊設計：先讓Planner生成計劃，再讓評估器審核這個計劃靠不靠譜，通過了再執行。

Plan Evaluator有幾種典型的設計思路。

思路一：多計劃競爭。讓Planner并行生成多個執行計劃，評估器從中挑最優的那個。這樣能提高計劃質量，但代價是成本和延遲都會上升——多生成幾個計劃就多幾倍的token消耗。

思路二：單計劃審核。先生成一個計劃，評估器判斷好壞，好就執行不好就打回去重新生成。這個思路成本更可控，但可能需要多輪打回-重生成才能得到合格的計劃。

計劃出問題一般都會是以下幾種情況：

目標失敗：Agent沒完成任務或者完成了但違反了約束條件。比如讓模型規劃一趟從舊金山到印度的兩周旅行，預算5000美元，結果它給你規劃到越南去了；或者確實規劃了印度行程但預算直接超了。

工具失敗：這又分好幾種情況。可能是生成了根本不存在的工具名（比如調用bing_search但工具庫里壓根沒這個）；可能是工具對了但參數個數不對（lbs_to_kg只需要一個參數,它傳了倆）；也可能是參數個數對了但值填錯了（該傳120傳成了100）。

Plan Evaluator需要針對這些常見問題設計檢查邏輯，在計劃執行前就把明顯的錯誤攔住，避免浪費執行資源。

遞歸搜索Agent

前面介紹的架構本質上都是迭代式的，但從算法角度看迭代能做的事遞歸也能做，而且遞歸天然適合處理可分解的層次化問題。

Sentient Labs就按照這個思路搞出了ROMA（Recursive Open Meta Agent）。

ROMA的核心思想是：把復雜問題遞歸地分解成子問題，每個子問題再獨立處理。和普通的并行拆分不同，ROMA的子問題之間可以有依賴關系——某個子問題的答案可能是另一個子問題的輸入。這種設計更符合復雜研究任務的實際結構。

上圖是ROMA的簡化版本，完整架構還有一層基于依賴圖的信息抽取機制。依賴圖用來管理子問題之間的前后關系，確保有依賴的任務按正確順序執行。

遞歸架構的優勢在于理論上可以處理任意深度的復雜查詢，只要問題能被合理分解。但工程實現上也更有挑戰，需要處理好遞歸深度控制、子問題結果合并、錯誤傳播等問題。

總結

這幾種架構并不是非此即彼的關系。Planner-Only適合入門，實現簡單調試方便；加上評估器后系統變得更智能，但復雜度和成本也跟著上來；檢查清單評分這類方案對長文檔輸出效果不錯，值得在特定場景下嘗試；而ROMA的遞歸思路理論上能處理更深層次的復雜查詢，不過工程實現的門檻也更高。

實際落地時，可以先從簡單架構跑通，再根據具體問題逐步疊加模塊。畢竟Agent系統的調試本身就不容易，一上來就搞太復雜容易把自己繞進去。

https://avoid.overfit.cn/post/c6f7744b34b048efb144d05c66e4c144