手動接力查文件這段，終於可以砍掉了
最近在測 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