這三年下來，我已經离不开用 AI 輔助做行業研究，為此還搭建過一系列的 skill 和輔助系統，解決資訊的篩選，歸納，聯結，驗證，沉澱。
直到這週深度體驗了 Claude Code 的動態工作流之後，才發現「人不要和大時代做對抗」這句話的真正含義。
再想一想：在 AI 時代，人類應該進行哪些深度研究，以及如何建立我與 AI 的協作互補關係。
一、從調研的陷阱說起
進行技術調研其實是一件充滿陷阱的事（無論對人還是AI），畢竟從調研的開始，會接收到大量的資訊，資訊觀點越來越多，結論越來越模糊。所以時刻要懂得回歸目標本身。
這也一直以來是 AI 不夠優秀的原因，因為從注意力和聯想的角度來看，它會比人類更受限於當前的資訊量，並且對於真正有價值的跨界聯想很薄弱。
當然，AI 足夠優秀的地方，在於他的執行力，會以 agent 的形式一層層地去尋找、歸納、總結，完全可以避免細節的損耗。
雖然我這半年都沒怎麼對外發公眾號了，但幾乎行業裡主流的戰場我都有在全面的關注和研究，而支撐這輸入輸出的，則是一套自己的 deep-research 系統。
而面對上周 Claude Code 上線了 Dynamic Workflows 這個功能，我想互相 battle 下，看他的預設能力，能否完全超越我自己。
二、Dynamic Workflows 是什麼
Dynamic Workflows（動態工作流）的核心思路是：在執行任務之前，先由 AI 自動設計這個任務應該用什麼工作流來完成，然後再啟動執行。
這與我們以前使用的「計劃模式」和「skill」有本質區別。計劃模式是將任務拆得更細，但不一定符合某種合理的工作流程，只有根據你的提示詞安排，才可能加入驗收指標（這對研究而言至關重要）；同樣地，也只有在有提示詞的情況下，它才會更好地預設一些 harness 規則。
But the dynamic workflow automatically incorporates acceptance logic, result convergence, and adversarial validation.
觸發方式很簡單，直接在 cc 中使用 /deep-research，然後提供一些調研模板和入口資料即可；如果想單獨使用動態工作流的功能，則使用提示詞或直接說 ultracode。使用前請注意，token 消耗約為平常的數十倍。
三、內置的六種工作流模式
在動態工作流的底層，是官方總結的六種核心調度模式，這正是它比普通對話/agent/skill 更強大的原因。
其實 這六種模式背後其實只有兩個核心問題：任務怎麼拆？結果怎麼合？ 分開六種本質就是對這兩者的排列組合。
3.1 路由模式（Classify-And-Act）
先由一個 agent 辨別任務類型，再把任務分發給最適合的專門 agent 去做。核心邏輯是路由的選擇邏輯，而非並行或迭代。一個任務只走一條路徑，其他路徑完全不執行。
例如，我可以先設定三個預設的 subagent 角色：一個嚴格驗證數據的分析 agent、一個擅長寫作的輸出 agent，以及一個專門尋找漏洞的挑戰 agent。讓路由層判斷當前子任務適合交給誰，而不是讓一個 agent 全包。
這種模式的價值在於：精準與節儉，每個 agent 的提示詞可以高度獨立，不受其他目標干擾，形成具有垂直深度的探索。token 消耗最低，響應速度最快。職責邊界非常清晰。
缺點也很明顯，對邊界模糊的任務（例如「既是技術問題又是帳戶問題」）處理能力較弱。
3.2 拆分合併（Fan-out & Merge）
這也是我最常用的模式，核心邏輯是並行+合併。將任務拆分成 N 個獨立子任務同時執行，待全部完成後統一合併。
優勢在於速度和隔離。總耗時約等於最慢的子任務，而非所有子任務之和。每個子任務擁有獨立的 context，互不干擾，也不會因某個子任務的噪聲污染其他子任務。
弱點是 token 成本是串行的 N 倍，合併層（Synthesize）本身也有難度——N 路結構不一致的輸出怎麼融合是個設計挑戰。子任務劃分不好會導致遺漏或重複覆蓋。
3.3 對抗驗證（Adversarial Verification）
核心邏輯是檢驗，對同一個結論，讓多個 agent 從「反駁」的角度去挑戰，票數過半才算通過。
優勢在於，由於 Verifier 不知道 Worker 的思路，只看結果，從結構上消除了「讓模型檢查自己寫的代碼」時的自評偏差。
這種模式解決了一個長期困擾我的問題：我們經常以口語化的方式與 AI 交談，但 AI 傾向於順應你的預期來回答，容易產生「確認偏誤」。透過對抗驗證，強迫 AI 去尋找反例，並基於數據和實驗進行驗證，而非迎合你的想法。
但是，驗證這件事時，如果他做出錯誤的判斷，就會帶偏 Worker，使其迎合 Verifier。因此，優先應基於可重複的事實，而非依賴觀點。
開個玩笑說，如果你讓 AI 找問題，他能無窮無盡地找出問題，所以你得限制他找問題的邊界。
3.4 生成與過濾（Generate & Filter）
核心邏輯是發散再收斂。先刻意產生過量的候選，再用 rubric 淘汰到精華，只保留高置信度的結果輸出。
與其讓一個 agent 輸出一個「還行」的答案，不如讓它生成十個，再用驗證層篩選。因此優勢在於多樣性。多個 Generator 可以用不同策略、不同提示詞，產出人工難以預想到的解法，過濾步驟讓最終輸出質量高度集中。
弱點在於，Filter 的評分標準品質直接決定最終效果，評分標準設計錯誤等於整個流程報廢
Suitable scenarios include situations where the correct answer is unknown beforehand, requiring selection among multiple possibilities, and where diversity is explicitly needed.
與 Fanout-And-Synthesize 僅表面相似：兩者都是「多路並行 → 單一輸出」，最容易混淆。
關鍵差異在於意圖：Fanout 的每一路都處理任務的不同部分，結果是互補的，合併時所有路都有貢獻；Generate-And-Filter 的每一路處理的是同一個任務，結果是競爭的，合併時大部分會被丟棄。前者是「拼圖」，後者是「選美」。
3.5 錦標賽模式（Tournament）
核心邏輯是競爭淘汰。N 個 agent 各自獨立做同一件事，透過 pairwise 對比逐輪淘汰，最終選出最優解。
我以前曾手動做過——同一份程式碼變更運行兩三個版本，再讓 AI 比較哪個更好。現在可以直接整合到工作流程中。
優勢在於評判的穩定性。兩兩對比（"A 和 B 哪個更好？"）比絕對評分（"給 A 打分"）穩定得多，因為排除了評分標準漂移的問題。結果經過多輪競爭，最終勝者的可信度高。
與 Generate-And-Filter 也表面相似：兩者都是從多個候選中選優。關鍵差異在於選優機制：Tournament 使用 pairwise judge 進行兩兩比較，是「讓候選者互相競爭」。當評分標準難以量化、判斷本質上是相對的時候，會更可靠。
3.6 循環模式（Loop）
核心邏輯是自適應迭代，不斷嘗試，遇到阻力時收集錯誤資訊，補充上下文，重新嘗試，直到滿足驗收條件為止。
本質上是在對抗 AI 的隨機性：多試幾次，總會撞上更好的結果。但更成熟的做法是結合對抗驗證，讓每次迴圈都帶著更多資訊去執行，而不是純靠隨機。
優勢在於處理工作量未知的任務。其他五種模式都假設任務邊界是確定的，Loop Until Done 是唯一能處理「不知道要做多少輪」的模式
弱點是潛在的失控風險——停止條件設計不佳會導致無限迴圈。每輪的 agent 都是全新的 context，無法累積跨輪狀態（除非顯式寫入檔案）。
四、我自己的 skill 與官方工作流的 Battle
在動態工作流推出之前，我曾專門設計過一套自己的 deep-research。我那套 skill 的邏輯大概是這樣：
- Midnight (NIGHT) 現已在 KuCoin 上線！
- 讓 AI 去搜索所有相關資料：官方文檔、源代碼、市場輿論
- 將資訊壓縮成有意義的摘要
- Multiple agent roles conduct adversarial analysis and generate reports
- 自動去重，因為多 agent 的內容重複率很高
使用了一段時間，我覺得挺好用的。但它有一個根本性的缺陷：缺乏以目標為導向的收斂。
而且很多時候即使有第五步的去重，但這時他經常刪掉有價值的信息；如果不做去重，又特別容易 skill 會給你一篇萬字長文，信息很全，但沒有直接告訴你「這件事跟你有什麼關係、你應該怎麼做」。
然而，研究是為「決策」服務的，這就是為什麼許多技能只能止步於研究本身，有80分，但少了最關鍵的20分。
因此，AI 在初步完成研究後，仍需再進行十次思考與對話，才能達成滿意的全面結論。
官方動態工作流多做了什麼
通過這週幾次複雜調研任務的實驗，我發現，Claude Code 內置的 deep research 工作流（注意不只是 skill，而是編譯內嵌到 cc 裡的模組），對比在我自己 skill 的基礎上，多了幾個關鍵環節：
- 問題拆解層：它不會直接開始搜索，而是先提出問題，將我的問題拆分成多個子問題：你真正想搞清楚什麼？這件事和你有什麼關係？哪些維度值得深究？這一步我以前是跳過的。
- 可信度評估：對每條資訊評估可證偽性，類似傳統 SEO 裡的權威性評分——來源是否可信？引用次數如何？這是我以前沒想到要加的環節。
- 交叉刪除而非平均合併：我以前的做法是平均選取所有結論，所以文檔很大。動態工作流會對每個結論做多 agent 投票，票數不足的刪掉，不是簡單合併。
- 目標導向的輸出：最終報告不是資訊的堆砌，而是圍繞你的原始目標提供判斷與建議方案。而實現這一點的關鍵，在於其調度多子 agent 的預設能力。我之前之所以 skill 容易缺乏最終目標導向，是因為在海量資訊後，指令權重的衰減。
這些機制解決了什麼問題？
針對的就是 AI 執行長任務的幾個典型問題：
目標偏移：任務開始時狀態良好，到中間卻不知所云，結束時又重新找回節奏——類似人類上課走神。任務越長，這種現象越明顯。
過早停止：跑著跑著遇到困難，AI 認為自己「完成了」就停下了，實際上驗收標準根本沒過。
上下文污染：單個 agent 執行複雜任務時，前置的大量 prompt 會壓縮後續的執行空間。更好的方式是將前置 prompt 控制在幾 k 以內，並使用多個 agent 分攤上下文。
AI 傾向於順著你的預期回答，口語化提問更容易觸發這個問題。
而動態工作流以結構化的方式解決了這四個問題：自動加入驗收指標以防止過早停止；並行隔離上下文；對抗驗證以抵消輸出偏倚；拆解問題並層層約束 AI，使其先理解目標再行動。
五、小結
最後，筆者作為一名長期的研究工作者，對此 CC 新機制嘆為觀止，它內置的六種模式——路由選擇、拆分合併、對抗驗證、生成過濾、錦標競選、Loop 循環——覆蓋了絕大多數複雜研究任務的調度需求。
讓我無需手動設計 agent 調度，也無需自行進行去重和交叉驗證，這些都已編入工作流本身。
而且他特別適合在資訊匱乏、開放性問題的探討中進行思考，因為天然的多agent調度＋任務目標的拆分，讓他在通用性上再次提升。其實早在3年前的AI，對於層層約束、僅解決極其清晰的小問題時，已經做得很好了，但AI真正的質變在於通用性，這一點才讓他從競爭對手中脫穎而出，從簡單的代碼真正成為Agent，從固態解決單一問題，轉變為適應任何問題。
因此，Dynamic Workflows 動態工作流不是「更聰明的單次對話」，而是將研究流程本身結構化。
原本我需要發起十幾次獨立對話的調研，現在壓縮到 3-4 次。雖然對應的 Token 消耗是數十倍的增長了。
那為什麼還需 3-4 次呢？我覺得根因在於這些需求的差異。
第一是驗證機制的嚴苛度，我主要研究區塊鏈上的新技術，許多事情官方文件都落後了，更有參考價值的是開源代碼、鏈上交易等數據，而目前AI仍默认以官方文件為準，而非以事實性驗證為準。
第二是完全跨界的深度思考，這點雖然可透過工作流預設解決部分問題（預定義各種維度的 subAgent）來對同一個問題進行思考，但 AI 擅長的仍是主流思考模型，對於非常新、非常深刻且缺乏數據依據的情況，則稍顯不足。
第三是解決方案的設計與驗證，解決方案的意義不在於提出，而在於驗證與支持，它依賴於對現有機制、投入和成本的衡量。如果能很好地調教AI，當然可以做得更好，但這就與通用性有所背離了。
最後是極致的資訊濃縮，這需要回歸到對資訊受眾的了解程度上，有的人毫無背景基礎，需要你以擬人化的表達方式講述，而有的聽眾，則需要你一句話打動他~。