探索系統怎麼查：別把錯誤當洞見、別讓暫時失敗永久燒素材
幾個月前我在《我們用 48 小時建了一套會自己變聰明的 AI 銷售系統》裡，把「每天自動寄 100 封精準冷信、自動黑名單退信域名」寫成一套會進化的探索引擎。這篇要攤開它現在的樣子：那條外聯通道 82% 退信、早就等於停了，而還活著的另一半研究鏈，正把 LLM 的錯誤訊息當洞見寫進筆記。
《Agentic Design Patterns》第 21 章講探索與發現。核心一句話：agent 不能只被動等指令，要主動去挖新素材、新機會，把外面的世界拉進來變成自己能用的東西。不主動探索的 agent，看到的永遠只有你餵給它的那一小塊。
我們讀完，點頭。這塊我們有兩條腿：一條 research-chain 每天兩次掃部落格和 HN，讀新文章、產出「這對我們有什麼意義」的研究筆記；一條 outreach/hunter 去挖潛在客戶、主動外聯。主動探索，實作完成。然後我們對自己做了對抗式稽核，發現這套探索系統是半死的：一半還在挖真洞見，另一半 82% 退信、早就停了，而活著那半，正用兩種方式默默傷害自己。
半邊活，而且活得會咬人
先看活的那半。research-chain 今天還在跑，今天還真的產出了有洞見的筆記，不是空殼。但它壞在兩個很陰的地方。
第一個：它會把 LLM 的錯誤訊息當成「分析」寫進筆記。這條鏈最後一格是叫 LLM 分析文章、吐 2 到 3 點洞見。當那次呼叫失敗，回的不是洞見，是一句錯誤字串，腳本照單全收，寫進 RESEARCH-NOTES.md。稽核翻出來的實錄：6/27 躺著 API_KEY_INVALID，7/3 躺著 run out of credits。下游的發文腳本會讀去當素材，等於把「金鑰失效」當成一條商業洞見在傳。
第二個更狠：它會把文章永久標成已讀。這條鏈為了不重複處理，會把看過的 URL 記進 seen 清單。但它在分析失敗、拿到錯誤訊息之後，照樣把 URL 標成已讀。於是一次暫時的 billing 或 API 錯誤，換一篇好文章被永久燒掉：它再也不會被重新分析，因為系統以為處理過了。一個活五秒的錯誤，造成永久的損失。
探索系統最危險的失敗不是挖不到，是它挖到了、卻把錯誤當洞見存下來，還順手把原料燒掉，讓你以為那口井已經榨乾。
另外半邊，早就沒有心跳
再看死的那半。outreach/hunter 宣稱在「主動探索客戶」，稽核一撈：82% 退信。這不是低回覆率，是通道本身死了，寄出去的信八成連對方信箱都進不去，早已暫停。探索的價值在於把外面的東西拉進來，一條 82% 退信的通道拉不進任何東西，只是每天假裝向外伸手。表面上「我們有主動探索」，攤開來是半死的：一半挖真洞見卻會咬自己，一半死透了還掛在架上。
先花幾分鐘查你自己的探索系統
01 你存下來的「分析」，會不會其實是 LLM 的錯誤訊息
翻你的探索筆記或素材檔，用關鍵詞掃一遍常見的 LLM 錯誤字串。探索鏈最後那格通常是叫 LLM 產出洞見，一旦那次呼叫失敗，回的是錯誤訊息，多數腳本不驗格式、照單全收。你的洞見庫裡可能正躺著幾條 run out of credits。
# 掃探索筆記裡有沒有混進 LLM 的錯誤訊息
grep -niE 'API_KEY_INVALID|run out of credits|quota exceeded|401 Unauthorized|429 Too Many|INVALID_ARGUMENT|no valid API' RESEARCH-NOTES.md
紅旗：掃到任何一條。你的探索產出裡混著錯誤訊息，下游還會拿去當素材。
02 暫時性的失敗，會不會造成永久的損失 找出你探索流程裡所有「不可逆」的動作：標已讀、標黑名單、標已處理、從佇列刪除。再問一句致命的問題：這個動作發生在成功之後，還是不管成功失敗都發生。如果失敗路徑上也會標已讀，一次暫時的 API 錯誤就會把一個好素材永久燒掉。
# 看標記已讀 / 已處理的動作，是不是被綁在失敗路徑上也會執行
grep -nB3 -iE 'seen\.push|mark.*read|blacklist|processed|dedupe|\.delete\(' your-explore.sh
紅旗：seen/黑名單的寫入，在「分析失敗」的分支裡照樣執行。不可逆動作必須只在確認成功後才做。
03 你的外聯 / 探索通道，今天還通嗎 探索要把外面的東西拉進來，就得有活的通道。撈出外聯通道最近的成效數字：退信率、回覆率、API 回傳筆數。一條 82% 退信的通道跟關掉沒兩樣，只是還掛在架上，讓你以為自己在向外探索。
# 撈外聯通道最近的退信 / 失敗率，别只看「有沒有在跑」
grep -ciE 'bounce|550|undeliverable|rejected' outreach.log
grep -c 'sent' outreach.log # 兩個數字相除就是你的真實退信率
紅旗：退信率破兩成，或你根本答不出「這條通道最近一次真的觸達了誰」。
我們實際怎麼修的
2026-07-04 那一刀砍在 research-chain 的分析格後面，加一道確定性的驗證閘：分析結果如果是空的，或關鍵詞命中任何已知的 LLM 錯誤訊息（API_KEY_INVALID、run out of credits、quota exceeded、429 等），就不寫筆記、也不標已讀，留到下輪重試。一刀堵兩個洞：錯誤訊息進不了洞見庫，好文章也不會被一次暫時的錯誤永久燒掉。死掉那半的 outreach，我們沒假裝它還活著，直接暫停，等有活的通道再開。
探索與發現體檢清單
對你自己的探索或發現系統跑一遍：
- 探索鏈最後那格的產出，有驗過是「分析」還是「LLM 的錯誤訊息」嗎
- 空回應或錯誤字串，會被擋在筆記外，還是照樣寫進素材庫
- 標已讀、標黑名單、標已處理這類不可逆動作，是只在成功後做，還是失敗路徑上也做
- 一次暫時的 API 錯誤，會不會讓一個好素材被永久跳過、再也不重試
- 你的外聯 / 探索通道，最近的退信率或回覆率是多少，答得出來嗎
- 死掉的探索通道，是誠實暫停了，還是還掛在架上假裝在向外伸手
這一章的四句話
- 探索最危險的失敗不是挖不到，是把 LLM 的錯誤訊息當洞見存下來。產出要驗格式，錯誤字串不是分析。
- 暫時的失敗不該造成永久的損失。標已讀、標黑名單這種不可逆動作，只能在確認成功後才做，否則一個活五秒的錯誤會燒掉一篇好文章。
- 探索需要活的通道。一條 82% 退信的外聯管子拉不進任何東西，它不是在探索，是在假裝向外伸手。
- 半死的探索系統比全死的更騙人。活的那半會讓你以為整套都健康，實際上它一邊挖洞見一邊咬自己。
原始碼位置：~/.openclaw/scripts/research-chain.sh（探索鏈，含 2026-07-04 加的錯誤偵測閘：空/錯誤訊息一律不寫筆記、不標已讀、下輪重試）；探索筆記落在 ~/.openclaw/workspace/RESEARCH-NOTES.md，已讀清單在 ~/.openclaw/data/research-seen-urls.json；outreach/hunter 那半（82% 退信）已暫停。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。