百度文心把搜索底子变成Agent能力

以前我看 AI 先问会不会聊，现在我先问它能不能把活做完。

我最近一直在看一类产品，表面上都在说 Agent，實際用起來卻還是老毛病：你丟一個任務給它，它先點頭，再補一句「我會盡力」，然後開始亂跑。最煩的是，它不是不會做，而是做著做著就忘了上下文，或者把交付物搞成一堆半成品。我自己試過不少這種工具，最常見的感受就是，模型會聊天，但不會交差。

百度文心這次讓我停下來重新看了一遍。不是因為它突然會說漂亮話了，而是它把「幹活」這件事做得很像樣：能記住前文，能拆任務，能調工具，能把結果收回來再整理成你能直接用的東西。更讓我在意的是，它不是只在中文場景裡刷分，還在國際榜單裡拿了高分，而且還是免費開放。這個組合很少見，至少不是那種「演示很好看，落地還要再等等」的老套路。

這篇我不是來復述宣傳稿的。我是把這篇知乎文章裡真正有用的東西拆開，看看它到底在夸什麼、為什麼能夸，以及我會怎麼把這套思路拿去做自己的 Agent 項目。

別再拿會聊天當 Agent

衡量一個 AI 好不好，標準正在從答得對不對換成事辦沒辦成。

這句話我很認同。以前我們看模型，主要盯的是回答品質：有沒有胡說、邏輯順不順、文風像不像人。現在不一樣了，任務型產品要的是交付。你讓它寫報告，它得真的把報告寫完；你讓它做網頁，它得真的把 HTML 交出來；你讓它查資料，它得真的把資料整合好，而不是只給你一段搜尋建議。

這就是 Agent 和聊天機器人的分界線。聊天機器人擅長回應，Agent 需要完成。前者像一個反應快的同事，後者像一個能把活接過去的執行者。差別不在嘴上，在流程裡。

我自己踩過的坑很典型：我給模型一個多步驟需求，第一輪它說得頭頭是道，第二輪開始偏題，第三輪忘了輸入限制。最後我發現，問題根本不是它會不會推理，而是它能不能把推理結果持續保留到任務結束。這就是為什麼文心這次的記憶分數會被強調，因為記憶不是錦上添花，是地基。

文章裡提到 SuperCLUE 的 XClaw 測評，核心不是選擇題，而是交付題。這個設計我很喜歡，因為它逼著模型面對真實工作流：理解需求、拆分步驟、調用技能、產出結果。沒有選擇題那種僥倖空間，也沒有看起來懂了的假象。

如果你也在做 Agent，我建議你先別問模型聰不聰明，先問三個問題：

• 它能不能把任務拆成穩定的步驟？
• 它能不能記住前文和約束？
• 它能不能把結果整理成可直接交付的格式？

這三個問題比回答像不像人更接近真實生產環境。因為生產環境裡，使用者不想看過程作文，只想要結果。

97.62 分不是重點，重點是它在交付題上穩

文章裡最先拋出來的數字是 XClaw 的 97.62 分，文心助手在十個國產產品裡拿了最高分。這個分數本身當然亮眼，但我更在意的是它下面那幾項拆分：記憶 100 分，資料處理 98.86 分，內容創作 99.44 分，研究分析 96.44 分。因為這些項不是會不會背答案，而是能不能把任務做完。

尤其是記憶 100 分。很多人做 Agent 的時候把記憶當成附屬模組，想著後面再補。結果一上線就翻車，因為多輪任務裡最怕的就是上下文斷掉。使用者第一輪說不要總結，只要表格，第三輪再補一句只保留三欄，模型如果忘了，就會輸出一坨不合格內容。記憶做不好，整個 Agent 就像短路。

我以前做一個內部文件助手時，最煩的就是它總在第二輪把第一輪的格式要求忘掉。後來我們不是先改 prompt，而是先改狀態保存。這件事和文章裡說的很像：記憶能力不是裝飾，它是多輪任務的粘合劑。

資料處理 98.86 分也很說明問題。文章舉的例子是讓文心生成一份 2026 年 Q2 商業計劃書，並輸出 Word 文件。它不是簡單寫一段商業建議，而是先用 pandoc 提取上傳文件，再做結構化拆解，最後生成格式化文件，交付的是 6000 多字、148 段的完整 BP。這個流程我看著很熟，因為這才像真正的工作流：先理解輸入，再抽取結構，再生成成品。

如果是我來落地，我會把交付題拆成三層：

• 輸入層：文件、網頁、聊天記錄、資料庫記錄
• 處理中間層：拆解、校驗、補全、歸一化
• 輸出層：Word、HTML、Markdown、JSON、表格

你會發現，很多 Agent 產品死在中間層。它們不是不會輸出，而是不會把輸入變成結構化中間態。文心這次被夸的點，就是它能把這段髒活做完。

記憶能力不是花活，是多輪任務的地基

文章裡對記憶的描述很直接：你跟 AI 聊了三輪，第四輪它忘了第一輪的條件，那叫一個崩潰。這個說法一點都不誇張。我自己最煩的就是這種假連續性，模型每輪都像重新認識你一次，前面說過的限制全沒了。

從工程角度看，記憶能力至少有三層意思。第一層是短上下文保持，也就是當前會話裡別丟條件。第二層是跨步驟狀態保存，任務拆成幾步後別把前一步結果忘了。第三層才是更長週期的使用者偏好和任務歷史。很多產品連第一層都沒做好，就開始吹個性化。這很滑稽。

文心這次在記憶項拿滿分，說明它在多輪任務裡更接近持續執行而不是單輪應答。這對 Agent 特別重要，因為 Agent 的本質就是把一次任務拉長成一串動作。你不是在問它一個問題，你是在讓它替你做一件事。

我建議你在設計自己的 Agent 時，專門寫一個記憶檢查清單。每次任務開始前，把這些東西顯式存下來：

• 目標是什麼
• 禁止項是什麼
• 格式要求是什麼
• 中間結果是否允許覆蓋
• 失敗後是否重試，重試幾次

這套東西聽著笨，但真的管用。因為模型很容易在長鏈路裡漂移。你不給它約束，它就按自己的合理想像補劇情。那不是智能，那是瞎編。

文章把記憶和搜尋引擎的 session 理解聯繫起來，我覺得這個比喻很準。搜尋引擎做了很多年的事，本來就是理解使用者意圖、持續保持上下文、再把結果組織回來。Agent 只是把這套能力從找資訊擴展成做事情。

資料處理和內容創作，拼的是交付感

資料處理 98.86 分和內容創作 99.44 分，看起來像兩個不同維度，其實底層要求很接近：都得按格式交付。一個是表格、欄位、精度；一個是語氣、字數、結構。說白了，都是別自由發揮。

我特別認同文章裡那句對資料處理的解釋：錯一個數，全盤皆輸。很多 AI 產品的問題不是不會算，而是太愛自作主張。比如讓它整理財務資料，它會順手幫你四捨五入；讓它寫報告，它會順手幫你改口徑。使用者要的是忠實執行，不是創作欲。

內容創作也是一樣。很多人以為內容創作就是會寫長文，其實不是。真正厲害的是按指定格式、語氣、字數、用途，直接給你一份能用的成品。你要它寫 PRD，它就別寫成散文；你要它寫行銷頁，它就別寫成論文。

我自己做過一個最樸素的測試：給模型一個固定模板，讓它填空。結果很多模型不是填錯，就是自己加段落。那一刻我就知道，它還停留在表達型模型，不是交付型模型。文心被夸的地方，恰恰是它更像交付型工具。

如果你要把這個能力搬到自己的項目裡，我建議直接做一個格式鎖。也就是在生成前先明確三件事：

• 輸出類型：Markdown、Word、HTML 還是 JSON
• 內容邊界：必須包含什麼，不能包含什麼
• 驗收標準：長度、欄位、標題層級、引用格式

別小看這些規則。很多時候，模型不是不會做，是你沒把驗收標準說清楚。你讓它寫得專業一點，它就開始裝腔作勢；你讓它輸出可直接複製的成品，它才會收斂。

這也是為什麼文章裡那個 3D 太陽系模擬器的例子很有說服力。它不是只寫了幾段介紹，而是直接用 Three.js 做了一個 31KB 的單文件 HTML。對使用者來說，這才叫完成任務，不是給思路。

研究分析真正考的是檢索、驗證和收口

研究分析 96.44 分這一項，我覺得最能看出一個 Agent 到底有沒有做研究的骨架。因為研究不是搜幾篇文章就完了，研究是檢索、交叉驗證、篩選，再把結論收口成結構化輸出。少一步都不算。

文章裡提到一個很好的例子：圍繞王虹和三維掛谷猜想，文心先規劃了 6 步研究流程，再呼叫多個子智能體並行處理，搜尋了 16 篇學術資料，最後輸出 markdown 文件和 62KB 的互動式 HTML。這個流程我很買帳，因為它不是我知道答案，而是我知道怎麼找答案。

這就是研究型 Agent 的關鍵。真正有用的不是一次性回答，而是知道什麼時候該繼續查、什麼時候該交叉比對、什麼時候該停下來寫結論。很多產品在這裡會犯一個很蠢的錯誤：找到一條資訊就開始下結論。那不是研究，是拼貼。

文章後面還有一個更現實的例子：做近一個月國內外大模型能力和價格分析報告。文心先搜 45 篇資料，再補 29 篇定向搜尋做價格驗證，最後才開始寫。這個過程我很喜歡，因為它把先驗證再輸出做實了。尤其是價格資料這種東西，最怕來源不一致。你不交叉驗證，報告就會變成幻覺合集。

如果你想讓自己的 Agent 具備研究能力，我會建議你按這個順序設計：

1. 先定義研究問題，不要一上來就搜
2. 再列資訊源，明確哪些可信、哪些只做參考
3. 然後做交叉驗證，至少兩輪
4. 最後才生成結論和圖表

我見過太多研究助手其實只是搜尋摘要器。它們能把網頁內容縮短，但不會判斷證據強弱。文心這次被強調的地方，就是它不只是找到了資訊，還把資訊整理成了能交差的報告。

百度真正占便宜的是搜尋底子，不是臨時抱佛腳

文章最後把原因說得很直白：百度做了二十多年搜尋，搜尋引擎和 Agent 在技術結構上高度同構。我覺得這不是一句漂亮話，而是很實在的工程判斷。搜尋引擎本來就要做意圖理解、任務分解、工具調用、結果整合，這些東西和 Agent 的鏈路幾乎是一回事。相關背景可以看 百度、文心一言、SuperCLUE，以及 Three.js 這類工具棧。

我特別認同這個類比。使用者搜北京到上海最便宜的機票，系統要理解這是比價需求，拆成出發地、目的地、日期、價格排序，然後去查資料、排結果。你把搜尋框換成對話框，把查詢換成任務，本質上沒變多少。

所以百度的優勢不是突然學會了 Agent，而是它本來就在做 Agent 的前身。搜尋引擎是受限工具集裡的高頻任務系統，Agent 是開放工具集裡的高頻任務系統。底層骨架很像，差別在工具邊界更大、任務更複雜、狀態更長。

這也解釋了為什麼文心在記憶和研究分析上更突出。前者對應多輪上下文保持，後者對應檢索、整合、輸出，這兩項都和搜尋的長期積累關係很大。不是說別家做不好，而是百度在這條路上確實有現成底盤。

我自己的結論很簡單：如果一個團隊想從聊天模型走到 Agent，別先急著堆花俏功能，先看看自己有沒有任務分解、狀態管理、結果整合、工具調用這四塊底子。沒有的話，產品會很飄。文心這次讓我看到的，不是它會說，而是它把這四塊接上了。

我會怎麼照著這套思路做自己的 Agent

如果只看熱鬧，文心這次就是又拿第一了。但如果看方法，我覺得它給我的啟發更直接：Agent 不是先追求會說，而是先追求會做。會做的前提，是把任務拆解、記憶、工具調用、驗證、交付這條鏈路打通。

我自己如果要做一個類似的產品，會先把能力分成五層：輸入理解、狀態保存、工具執行、結果校驗、格式化交付。每層都要有明確的驗收標準，不能靠模型自己想辦法。因為一旦你把責任全丟給模型，最後出事的還是你。

還有一點我特別想提醒：別迷信單次高分。榜單有用，但真正重要的是穩定性。文章裡提到 PinchBench 的 94.6% 和 94.4% 差距很小，我更看重的是這種連續跑也不崩的能力。因為真實任務不是一次跑通就結束，而是每天都要跑、一直跑、跑到你想罵人。

所以我更願意把文心這次理解成一個信號：中文場景裡，Agent 已經開始從能演示走向能交付。這一步很難，但一旦跨過去，很多產品定義就會變。你不再是做一個會答題的模型，而是在做一個能替使用者收尾的執行系統。

可抄的模板

# Agent 任務執行模板（可直接改成你自己的版本）

## 1. 任務定義
- 任務名稱：
- 使用者目標：
- 交付物類型：Markdown / Word / HTML / JSON / 表格
- 完成標準：

## 2. 輸入約束
- 必須保留的條件：
- 禁止修改的內容：
- 允許補充的內容：
- 資料來源優先級：

## 3. 執行流程
1. 解析使用者意圖
2. 拆分為子任務
3. 確認缺失資訊
4. 呼叫工具或檢索資料
5. 交叉驗證關鍵結果
6. 生成中間草稿
7. 按格式輸出最終交付物

## 4. 記憶規則
- 當前會話中的約束必須持續保留
- 多輪任務中，任何新指令都要和舊約束合併
- 若出現衝突，先提示衝突，再繼續執行

## 5. 校驗規則
- 數字是否一致
- 引用是否可追溯
- 格式是否符合要求
- 是否遺漏使用者明確要求
- 是否加入了不該有的內容

## 6. 輸出規則
- 只輸出最終交付物
- 不要解釋執行過程，除非使用者要求
- 不要擅自改寫使用者目標
- 不要把建議混進結果裡

## 7. 失敗處理
- 若資訊不足，先列出缺失項
- 若工具失敗，重試一次並切換備用方案
- 若仍失敗，明確說明卡點並返回可繼續執行的狀態

## 8. 最終檢查清單
- [ ] 任務目標已完成
- [ ] 約束未丟失
- [ ] 結果可直接使用
- [ ] 格式正確
- [ ] 沒有多餘廢話

這套模板不是為了看起來專業，而是為了逼 Agent 像一個真正的執行系統一樣工作。你要是做文件助手，就把交付物類型改成 Word 和 Markdown；你要是做研究助手，就把資料來源和交叉驗證寫細一點；你要是做程式助手，就把測試和回滾規則補上。

我建議你直接拿這個模板去跑一次自己的任務流。跑完你就會知道，問題到底出在模型能力，還是出在你沒有把任務定義清楚。很多時候，後者占大頭。

原文來自知乎專欄文章，我這裡做的是拆解和再組織，不是原創事實報導。文中提到的測評、分數和案例，均以原文為準；我補的是我的判斷、經驗和可直接拿去改的模板。