1. 從「搜完就寫」到「邊搜邊改」WebWeaver 雙 Agent 框架到底解決了什么如果你讓一個普通 LLM 智能體去寫「帕金森病不同階段的預警信號及術后護理」這種題目大概率會看到兩種翻車現(xiàn)場。第一種是它先瘋狂搜索十幾輪把一堆網(wǎng)頁片段塞進上下文然后一次性硬生成兩萬字結果中間章節(jié)開始胡編引用對不上號。第二種是它一開始就定死大綱后面搜到再好的證據(jù)也不改結構最后報告像八股文深度全靠堆字數(shù)。通義實驗室的 WebWeaver 就是沖著這兩個毛病去的。它把開放式深度研究OEDR拆成規(guī)劃Planning和寫作Writing兩個階段分別交給 Planner 和 Writer 兩個 Agent。Planner 負責在 ReAct 循環(huán)里反復「搜索—讀證據(jù)—改大綱」Writer 負責拿著帶引用 ID 的大綱逐節(jié)從記憶庫里精準取證據(jù)、內部推理、再落筆。核心檢索詞就是 WebWeaver 雙 Agent 框架、ReAct 推理機制、動態(tài)大綱優(yōu)化。它適合誰如果你正在做 LLM Agent 開發(fā)、RAG 長報告生成、或者想復現(xiàn)一個能跟做的多 Agent 研究流程這篇就是給你寫的。我下面會給出可復現(xiàn)的角色配置、工具調用鏈路、ReAct 循環(huán)偽代碼以及在本地環(huán)境跑通雙 Agent 協(xié)作的具體步驟。論文里最關鍵的三個設計是動態(tài)大綱協(xié)同進化、記憶庫Memory Bank做上下文管理、Writer 的分層檢索與上下文清理。這三件事決定了它為什么能在 DeepResearch Bench 上把引用準確率做到 93% 以上。先說清楚一個常見誤解WebWeaver 不是「兩個模型互相聊天」。Planner 和 Writer 共享同一個記憶庫但職責邊界非常硬。Planner 只輸出結構化大綱和引用 ID不寫正文Writer 只消費大綱和證據(jù)不改結構。這種硬邊界是它能穩(wěn)定跑長任務的前提也是你在本地復現(xiàn)時最該先固定下來的部分。2. 前置準備TaoToken 接入與本地環(huán)境依賴在本地驗證雙 Agent 協(xié)作之前你需要一個能穩(wěn)定調用 Claude 或 Qwen 系列模型的入口。我實測下來用 TaoToken 的 API 做基座調用比較省事Base URL 固定為https://taotoken.net/apiKey 在控制臺生成。如果你還沒建 Key可以直接去 API Keys 頁面拿https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi_keys 。接入文檔在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc 里面有各語言 SDK 的調用示例。本地環(huán)境我建議用 Python 3.10依賴三件套openai走兼容接口、requests、pydantic。搜索引擎部分論文用的是網(wǎng)頁檢索本地復現(xiàn)你可以先用一個 mock 檢索器返回固定片段把 Agent 循環(huán)跑通再換成真實搜索 API。這樣排障成本最低。模型選擇上Planner 建議用推理能力強的模型Writer 可以用同款或稍小的模型。論文里 SFT 實驗用的是 Qwen3-30B微調后引用準確率從 25% 提到 85.9%說明工具調用格式的穩(wěn)定性比模型大小更關鍵。你本地先用 Claude Sonnet 系列跑通流程再考慮換小模型。環(huán)境變量這樣配export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后驗證一下連通性from openai import OpenAI import os client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( modelclaude-sonnet-4-20250514, messages[{role: user, content: 只回復 ok}], ) print(resp.choices[0].message.content)如果這里報 401先檢查 Key 有沒有復制完整如果報 model not found去模型對話頁面確認當前賬號可用的模型 IDhttps://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel_chat 。這一步跑通再往下否則后面 Agent 循環(huán)里的報錯你分不清是邏輯問題還是鑒權問題。3. 可復制配置Planner 與 Writer 的角色定義與工具 Schema這一節(jié)是全文最核心的可復制部分。我按論文的行動空間把兩個 Agent 的 system prompt、工具 JSON Schema、以及記憶庫結構都寫成可直接落地的片段。你新建一個webweaver_config.json把下面內容貼進去。Planner 的行動空間是search、write_outline、terminate。Writer 的行動空間是retrieve、write、terminate。工具定義用 OpenAI function calling 格式{ planner_tools: [ { type: function, function: { name: search, description: 根據(jù)當前知識缺口發(fā)起網(wǎng)頁搜索返回候選 URL 與片段, parameters: { type: object, properties: { query: {type: string, description: 搜索查詢詞}, top_k: {type: integer, default: 5} }, required: [query] } } }, { type: function, function: { name: write_outline, description: 新增或優(yōu)化大綱每個小節(jié)必須帶 citations 引用 ID 列表, parameters: { type: object, properties: { outline: { type: array, items: { type: object, properties: { section_id: {type: string}, title: {type: string}, goal: {type: string}, citations: {type: array, items: {type: string}} }, required: [section_id, title, citations] } } }, required: [outline] } } }, { type: function, function: { name: terminate, description: 當大綱覆蓋全面且證據(jù)充分時終止規(guī)劃, parameters: {type: object, properties: {}} } } ], writer_tools: [ { type: function, function: { name: retrieve, description: 按引用 ID 從記憶庫取回原始證據(jù), parameters: { type: object, properties: { citation_ids: {type: array, items: {type: string}} }, required: [citation_ids] } } }, { type: function, function: { name: write, description: 輸出當前小節(jié)的正文用 write 標簽包裹, parameters: { type: object, properties: { section_id: {type: string}, content: {type: string} }, required: [section_id, content] } } }, { type: function, function: { name: terminate, description: 所有小節(jié)寫完時終止, parameters: {type: object, properties: {}} } } ] }記憶庫結構用 Pydantic 定義每條證據(jù)必須有唯一 ID、來源 URL、摘要、原文片段from pydantic import BaseModel from typing import List class Evidence(BaseModel): evidence_id: str source_url: str summary: str raw_snippet: str class MemoryBank: def __init__(self): self.store {} def add(self, ev: Evidence): self.store[ev.evidence_id] ev def retrieve(self, ids: List[str]) - List[Evidence]: return [self.store[i] for i in ids if i in self.store]Planner 的 system prompt 關鍵約束我寫成這樣你可以直接抄你是研究規(guī)劃者。每輪先思考當前大綱缺什么證據(jù)再決定調用 search 還是 write_outline。search 返回的片段只用于決策原始證據(jù)由系統(tǒng)寫入記憶庫。write_outline 必須為每個小節(jié)標注 citations引用 ID 來自記憶庫。當大綱覆蓋主題且每個小節(jié)都有至少 2 條證據(jù)時調用 terminate。Writer 的 system prompt你是報告寫作者。按大綱順序逐節(jié)處理。每節(jié)先調用 retrieve 取回該節(jié) citations 對應的證據(jù)在內部推理中合成關鍵見解再調用 write 輸出正文。寫完一節(jié)后該節(jié)證據(jù)從上下文清除只保留占位符。全部小節(jié)完成后調用 terminate。這里有個容易踩的坑Planner 的write_outline每次返回的是完整大綱還是增量論文里是「回顧并優(yōu)化」我建議實現(xiàn)成完整大綱覆蓋這樣狀態(tài)機簡單不會出現(xiàn)增量合并沖突。代價是 token 多一點但排障容易得多。4. ReAct 循環(huán)偽代碼與本地驗證跑通雙 Agent 協(xié)作配置就緒后核心是一個雙層循環(huán)。外層是 Planner 的 ReAct 循環(huán)內層是 Writer 的逐節(jié)寫作循環(huán)。偽代碼如下我把它寫成接近可運行的 Pythondef planner_react_loop(client, memory, max_rounds8): outline [] for step in range(max_rounds): # Reason: 讓模型基于當前大綱和記憶庫摘要決策 messages build_planner_messages(outline, memory) action call_llm_with_tools(client, messages, planner_tools) if action.name search: results web_search(action.args[query]) for r in results: summary summarize(r, action.args[query]) ev Evidence( evidence_idfev_{hash(r.url)}, source_urlr.url, summarysummary, raw_snippetr.snippet, ) memory.add(ev) # Observe: 把摘要回填給 Planner messages.append({role: tool, content: summary}) elif action.name write_outline: outline action.args[outline] elif action.name terminate: break return outline def writer_loop(client, outline, memory): report [] for section in outline: # Retrieve: 精準取回該節(jié)證據(jù) evidences memory.retrieve(section[citations]) # Think: 內部推理合成見解 think internal_reasoning(client, section, evidences) # Write: 輸出正文 content call_llm_with_tools( client, build_writer_messages(section, think), writer_tools, ) report.append(content) # Clear: 清理該節(jié)證據(jù)只留占位符 clear_context(section[section_id]) return \n\n.join(report)本地驗證時先用 mock 搜索器返回 3 條固定片段跑一輪 Planner看它能不能生成帶 citations 的大綱。成功標志是大綱里每個小節(jié)都有非空 citations且這些 ID 都能在記憶庫里查到。然后跑 Writer檢查每節(jié)正文是否引用了對應證據(jù)。我試過把max_rounds設成 3 和 8 對比輪次越多大綱越細但超過 8 輪后邊際收益明顯下降token 成本卻線性漲。論文圖 5 也顯示大綱優(yōu)化輪次與質量單調上升但實際工程里你要在成本和深度之間取平衡。驗證成功的輸出長這樣{ outline: [ { section_id: s1, title: 帕金森病早期預警信號, goal: 列舉運動與非運動早期信號, citations: [ev_a1, ev_b2] }, { section_id: s2, title: 術后護理要點, goal: 分階段說明護理措施, citations: [ev_c3, ev_d4] } ] }如果你想讓 Writer 用更小的模型跑建議先把工具調用格式固定成 few-shot 示例塞進 system prompt否則小模型很容易把retrieve的參數(shù)寫成自然語言。論文的 SFT 實驗本質上就是在教模型穩(wěn)定輸出這種結構化調用。5. 常見報錯排查401、local proxy failed、reading choices、OAuth本地跑雙 Agent 時報錯基本集中在四類。我按真實遇到的順序列出來你對照著查。第一類401 Unauthorized。這個最常見九成是 Key 沒帶對。檢查TAOTOKEN_API_KEY有沒有多余空格Base URL 是不是寫成了帶路徑的https://taotoken.net/api/v1。正確寫法就是https://taotoken.net/apiSDK 會自動拼/v1/chat/completions。如果還報 401去控制臺重新生成一個 Key 再試。第二類local proxy failed或連接超時。這通常是你本地網(wǎng)絡環(huán)境或代理配置干擾了請求。先確認沒有設置HTTP_PROXY、HTTPS_PROXY環(huán)境變量再確認防火墻沒攔 443。如果你在公司內網(wǎng)可能需要找網(wǎng)管放行taotoken.net。這類報錯跟 Agent 邏輯無關先單獨用 curl 測通再跑循環(huán)。第三類reading choices或KeyError: choices。這是響應體結構不符合預期常見于模型返回了錯誤 JSON 或者你用了不存在的 model ID。打印完整resp看error字段。如果是model not found去模型對話頁面確認可用模型列表。如果是工具調用返回格式問題檢查你的tools參數(shù)有沒有傳對有些模型要求tool_choiceauto顯式聲明。第四類OAuth相關報錯。如果你用的是 Claude Code 或 Codex 這類帶 OAuth 的客戶端報錯往往出在 token 刷新環(huán)節(jié)。這時候不要混用 OAuth 和 API Key 兩套鑒權。用 API Key 就統(tǒng)一走base_urlapi_key別讓客戶端去讀本地 OAuth 緩存。Claude Code 接入時Base URL、Key、Model ID 三件套必須同時配對缺一個都會在 OAuth 回調和 API 調用之間打架。還有一個隱蔽的坑Writer 的上下文清理如果沒做干凈第二輪 retrieve 會把上一節(jié)的證據(jù)也帶進來導致章節(jié)間信息串味。排查方法是打印每輪 Writer 的 messages 長度正常應該隨小節(jié)推進保持穩(wěn)定而不是單調增長。如果一直漲說明clear_context沒生效。6. 從跑通到跑好把雙 Agent 研究流程用起來跑通最小閉環(huán)之后你可以按三個方向加深。第一把 mock 搜索器換成真實檢索注意論文里的兩階段過濾先用標題和片段篩 URL再解析正文提取證據(jù)。這一步?jīng)Q定了引用準確率的上限。第二給 Planner 加一個「知識缺口檢測」步驟讓它每輪先輸出當前缺什么再決定搜什么這樣搜索查詢會更聚焦。第三Writer 的內部推理步驟可以顯式輸出方便你調試它到底合成了什么見解而不是黑盒生成。如果你打算長期跑這類研究型 AgentCoding Plan 的額度模型比按次調用更適合高頻循環(huán)https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding_plan 。接入文檔里也有 function calling 的完整參數(shù)說明遇到工具 schema 報錯可以直接對照https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc 。最后留一個我踩過的坑別一上來就追求兩萬字長報告。先用一個 3 小節(jié)的小題目把 Planner 和 Writer 的邊界跑穩(wěn)確認引用 ID 能對上、上下文能清干凈再放大到 10 節(jié)以上。WebWeaver 的威力在長任務上才體現(xiàn)但長任務的排障成本也高循序漸進比一步到位靠譜得多。