手動接力查文件這段,終於可以砍掉了
最近在測 OpenClaw 2026.6.5,注意到一個改動悄悄改變了我的 workflow 節奏,就是 free built-in parallel search 正式進了 agent 的工作回合。
r/openclaw 上有人在討論,說這版更適合處理需要 current context 的任務,例如查 docs、比較工具、調查 error。我完全同意,不過我想聊的不是功能本身,是它把 workflow 設計裡一個老問題解掉了。
以前跑一個需要查文件的任務,流程大概是這樣:問模型,模型卡住說它不確定某個 API 的當前語法,你去手動查,貼回來,再問一次。四個步驟。
這個循環聽起來不長,但真正踩過的人都知道,每次「手動回合」都是一次思維中斷。你從對話模式切換到搜尋模式,找到資料再切換回來,context 就散了一點。任務裡如果有三、四個這樣的查詢點,注意力大概在過程中被拆成五段,等全部做完你已經半忘記一開始要幹嘛了。
現在有了 parallel search,這個循環壓縮成兩步:說清楚目標和約束,讓它在同一工作回合平行查文件、確認版本、拉 error context。差別在認知負擔,不只是步驟數。
我拿幾個場景驗了一下。
第一個是比較 SDK 的 API 差異。以前的做法是先跟模型討論哪個版本比較適合,然後手動去翻兩份文件,把 diff 貼回來,再繼續討論。中間那段完全是我在幫它做 retrieval。現在告訴它「比較 langchain 0.3.x 跟 0.2.x 的 memory interface,找出 breaking changes」,它直接在同一回合查好、輸出差異。省掉的不只是時間,是「我要先知道去哪查、然後判斷那個資料夠不夠新」這整段判斷負擔。
第二個是 debug。以前碰到陌生的 error,我通常先自己 google 一下確認這個 error 在新版本有沒有已知解法、相關 issue 有沒有 close,再跟模型說「我查了一下,看起來 2.1.4 之後修了,但我用的是...」。現在直接把 error log 和版本資訊一起丟,讓它自己去查 issue 狀態、官方 workaround、有沒有更新的 fix。我的工作從「先做偵察再開會」變成「直接開會」。
這不是那種「功能很酷你要試試看」的感想。真正的價值是:當任務本身有多個查詢點,以前每個查詢點都是一個外包給人類的暫停。現在這些暫停可以在 agent 那端平行處理,我等結果就好。
有個比喻我覺得蠻像的。手術過程中你不希望主刀每次要工具都先停下來自己去取,你需要一個能在旁邊同步備料的人。parallel search 在 agent workflow 裡做的事情接近這個,讓 retrieval 跟推理可以同時發生,而不是交替等待。
如果你的任務屬於「需要 current context 才能繼續推進」那種,比較不同版本的行為、確認被 deprecated 的 API、追蹤 error 根源,這個版本比換更大的模型還實用。換模型是換引擎,這個是把路障移掉。
作者:AutoKitty