Claude Code Workflow：AI 開始自己寫 Harness，工程師該管的是流程而不是 Prompt

010. 真正的新東西不是多 Agent｜而是 Agent 會先寫流程

多 Agent 並不是新概念。早在 Workflow 成為 Claude Code 內建能力之前，開發者就能用 shell script、CI pipeline、MCP、subagent、Task tool 或自製 orchestration，把研究、實作、測試與 review 分派給不同模型。

AI 超元域這支影片真正值得看的地方，是操作介面再往前推了一層：使用者只描述任務、預算與執行模式，Claude Code 先替這個任務產生一支 Workflow script，再由 script 依階段呼叫多個 agents。

這代表工作重心正在改變。過去，使用者通常直接要求模型「完成任務」；現在，模型會先回答另一個問題：

這個任務應該用什麼流程完成？

這就是 Harness Engineering 的核心。模型能力像引擎，Harness 則決定引擎看見什麼 Context、能使用哪些工具、何時並行、如何驗證、何時停下，以及失敗後怎麼回復。當 Agent 開始自己產生 Harness，人不必再手寫每一行編排程式，但仍然需要定義它的邊界。

影片把這個轉變形容為「抹平 Harness Engineering 的技術鴻溝」。這個說法抓到了介面層的變化，卻也容易說得太滿。自然語言確實降低了啟動多 Agent 流程的門檻，但它不會自動補上需求判斷、風險分類、驗證設計與權限治理。

更準確的說法是：編排語法正在被模型吸收，工程責任沒有消失。

以前，工程師要同時懂任務與 orchestration code；現在，他可以把部分 orchestration code 交給 Agent 產生，但必須更清楚地表達產物、階段、預算、依賴與成功條件。Prompt 從「請幫我做」升級成一份小型執行規格。

021. 先處理版本真相｜隱藏入口不是穩定產品契約

影片使用的版本是 Claude Code v2.1.150。講者透過環境變數開啟功能，再以 ultrawork 與 /workflows 進入 Workflow 介面。由於影片也明確提到逆向分析與隱藏功能，這些步驟不應被讀成 Anthropic 對外承諾的穩定 API。

官方 release note 提供了一個重要校正：

• v2.1.150只標示內部基礎設施改善，沒有列出面向使用者的新功能。
• v2.1.152才明確提到 Workflow 在 press-up 與 transcript mode 裡的進度顯示。

這兩筆資料放在一起看，可以得到一個比較穩健的結論：Workflow 並非憑空捏造，影片也確實展示了可運作的介面；但 v2.1.150 的開啟方式、關鍵詞與環境變數，至少在該版 release note 裡沒有被當成正式使用契約。

對工程團隊而言，這個差別很重要。實驗功能常有四種風險：

1. 入口會變：環境變數、slash command 或觸發詞可能改名。
2. 資料格式會變：script schema、狀態欄位或進度輸出可能不相容。
3. 安全邊界會變：沙箱允許的 API、工具與檔案存取範圍可能調整。
4. 成本模型會變：預算單位、token 計量與子 Agent 行為可能更新。

因此，最不該做的是把一段隱藏功能操作直接寫進團隊關鍵 SOP，再假設每次升級都會照常運作。比較務實的採用方法，是把版本、啟用方式與回退路徑一起記錄：

• 固定可驗證的 Claude Code 版本。
• 把 Workflow script 納入 repository，而不是只留在對話紀錄。
• 保留不用 Workflow 也能執行的人工或 script 路徑。
• 升級前先跑一個低風險 smoke test。
• 不讓未文件化功能直接取得 production 部署、刪除資料或付款權限。

影片示範的是一個很有價值的方向，但方向正確不代表每個版本細節都能長期依賴。

032. Workflow 與 Skill 的分界｜意圖重用對上執行治理

影片花了一段篇幅比較 Skill 與 Workflow。講者的說法是，Skill 依賴模型理解意圖，Workflow 則更接近按編排好的程式結構執行。這個對比雖然略為簡化，卻提供了一個實用的判斷框架。

Skill 適合封裝「怎麼做」：

• 一篇魚塘文章應該有哪些產物。
• Code review 要檢查哪些風險。
• 怎麼轉錄影片、整理摘要、生成圖片。
• 團隊偏好的格式、語氣、工具與品質門檻。

它把方法、知識與規則交給模型，讓模型依當下任務選擇細節。這種彈性很強，但同一個 Skill 在不同 Context、模型或任務描述下，可能走出不同路徑。

Workflow 適合封裝「按什麼順序執行」：

• 先派四個 agents 做研究。
• 研究完成後，啟動七個模組規格工作。
• 等所有模組產出後才能整合。
• 整合稿完成後，才進入對抗性審查。
• 任一必要驗證失敗就停止。
• 總 token 或並行數不能超過設定值。

它處理的是控制流、依賴、狀態與資源。Workflow 不必比 Skill 更「聰明」，它的價值反而是讓某些事情不要靠臨場聰明決定。

實務上，兩者最適合疊在一起：

1. Workflow 決定階段與資料流。
2. 每個階段呼叫對應 Skill。
3. Skill 告訴 Agent 如何完成該階段。
4. Workflow 收集結果、執行驗證並決定是否前進。

例如，一條內容流水線可以規定「轉錄完成後才能寫摘要，摘要通過來源核對後才能生圖」；轉錄 Skill 處理語言、時間戳與專有名詞，生圖 Skill 處理 palette、reference image 與繁中規則。前者提供結構，後者提供方法。

所以，Workflow 並不是 Skill 的替代品。它更像把散落的 Skills、tools 與 agents 裝進一張能觀測、能重跑、能限制資源的執行圖。

043. 沙箱與可觀測性｜為什麼編排腳本要有統一出口

依影片說明，Claude Code 會讓產生的 JS Workflow script 在臨時 VM 沙箱中執行。script 發出的模型呼叫會穿過受控出口，再由 Claude Code 主程序建立真正的 subagent 對話。

這個架構有三個直接好處。

隔離

Agent 產生的 orchestration code 不是普通業務程式碼。它可能包含大量迴圈、檔案操作、工具呼叫與動態 Prompt。讓它直接在主程序環境裡任意執行，風險會隨自動化程度上升。

沙箱至少能建立一道邊界：限制可用 API、隔開程序狀態，並讓某些破壞性操作無法直接逃出執行環境。不過，沙箱不等於萬無一失。真正的風險仍取決於主程序暴露哪些工具，以及外部呼叫是否具備寫入、部署、付款或刪除權限。

可觀測

多 Agent 系統最容易出現的問題，不是「完全沒做事」，而是做了很多事卻不知道錢花在哪裡、哪個分支卡住、哪個輸出被後續採用。

如果所有模型呼叫都走同一個 gateway，系統就能記錄：

• 每個 agent 的 Prompt、模型與 token。
• 各階段開始、完成、失敗與耗時。
• 哪些輸出成為下一階段輸入。
• 目前預算消耗與剩餘額度。
• 哪個錯誤導致 retry、降級或停止。

這些資料讓 Workflow 從一串聊天，變成可以診斷的執行紀錄。

相對確定性

Workflow 的確定性不是指「模型每次會給一樣答案」，而是控制流比較可預期：哪些任務可以並行、哪些必須等待、失敗後重試幾次、最後必須通過什麼 gate。

這種相對確定性很重要。模型輸出仍然具有隨機性，但外圍 Harness 可以把變動限制在可管理的範圍。例如研究結果不同沒關係，只要每份結果都符合 schema，且整合前都有來源核對；程式實作不同也沒關係，只要測試、lint 與 security gate 都通過。

真正成熟的 Agent 系統，不是消除模型的不確定性，而是讓不確定性有邊界、有紀錄、有驗證。

054. 規格文件案例｜四階段流水線如何拆工作

影片第一個完整案例，是替背單詞應用產生規格文件。Claude Code 顯示的初始編排包含四個並行研究、七個模組規格轉寫，接著綜合整合，再做對抗性審查；啟動訊息稱為 13 個 agents 的四階段流水線。

這個案例的重點不是 agent 數量，而是工作拓樸：

第一階段：並行研究

可以把互不依賴的問題分開，例如使用者流程、資料模型、技術架構與市場慣例。研究 agent 彼此不必等待，因此適合並行。

第二階段：模組規格

研究結果成為各模組的共享 Context，再由不同 agents 撰寫帳號、學習流程、複習演算法、內容管理、通知、分析與非功能性需求。這一階段也能並行，但必須遵守共同名詞、介面與架構決策。

第三階段：綜合整合

並行產出不會自動形成一致文件。整合 agent 必須處理重複需求、互相衝突的資料結構、跨模組流程與優先順序。這是一個收斂階段，不適合無限制地繼續分散。

第四階段：對抗性審查

審查 agent 不再負責增加內容，而是刻意尋找缺口：需求是否可測、錯誤流程是否完整、隱私與安全是否被忽略、技術決策是否互相矛盾、成功指標是否可量測。

影片後來顯示的執行摘要是 18 個 agents、約 700K tokens、8 分鐘。這可能包含額外的整合或審查工作，與啟動時顯示的 13 個 agents 不完全相同。因為影片沒有提供完整 script 與逐筆計量，這些數字適合視為該次示範結果，而不是固定效能基準。

更重要的是，700K tokens 是否划算，不能只看「八分鐘完成」。還要問：

• 產出的規格能否直接進入開發？
• 人工修正花了多久？
• 是否引用不存在的功能或錯誤技術假設？
• 相較單 Agent 或人工撰寫，品質提升在哪裡？
• 同一份規格重跑時，差異有多大？

多 Agent 很容易製造規模感，卻不一定製造資訊增量。如果四個研究 agent 都讀同一段需求、用相似 Prompt、產生相似摘要，那只是重複消耗。好的拆分應該讓每個 agent 有不同責任、不同證據來源或不同檢查角度。

065. 預算不是一句上限｜Token、並行度與停止條件

影片多次強調可以在 Prompt 裡設定 token 預算：規格案例使用約 1M 上限，issue 分析案例設定 500K，PR 深度 review 也設定 1M。這確實比「盡量省一點」更具體，但預算治理不能只靠一個總數字。

一條可控的 Workflow 至少需要三層限制。

總量限制

整個任務最多能消耗多少 token、時間或金額。這是最後一道保險，避免 retry、循環或過度探索無限延伸。

但總量限制太高時，仍可能在早期就把大量預算花在低價值研究；太低時，流程可能在最重要的整合或驗證階段被迫停止。因此，除了總額，也應分配階段額度。

並行限制

影片在 PR review 案例裡，要求把同時並行數改成最多三個 agents。這不只是成本問題，也涉及 rate limit、Context 一致性與結果整合。

並行越高，牆鐘時間可能越短，但同時會增加：

• API 峰值與限流風險。
• 多份輸出互相重複或衝突的機率。
• 整合 agent 的 Context 壓力。
• 同時寫入同一 repository 的衝突。
• 問題發生時的診斷難度。

合理的並行度應該來自任務依賴與資源限制，不是越多越好。

停止條件

只設定「最多花多少」，卻沒有「什麼情況該停」，系統仍可能把剩餘預算全部消耗完。停止條件可以包括：

• 必要來源取不到。
• 測試連續失敗且沒有新診斷。
• 產物 schema 不合格。
• 某一步需要產品或安全決策。
• 修改將觸及未授權範圍。
• 連續兩次 review 沒有帶來實質改善。

另外還需要定義成功條件。對規格文件而言，成功不應是「寫完一份很長的 Markdown」，而是需求可追蹤、介面一致、驗收條件可測、風險被列出。對 PR review 而言，成功不應是「產生很多 finding」，而是 finding 能定位到程式碼、說明影響、提出可驗證修法，並控制誤報。

成本控制的本質不是要求模型省錢，而是讓系統知道哪些工作值得繼續。

076. 先寫腳本、再審、最後跑｜把人放回控制迴路

影片最成熟的一段，不是自動啟動 18 個 agents，而是要求 Claude Code 只生成 Workflow script，先不要執行。

講者先要求 Workflow 對一個 PR 做深度 review，接著在 VS Code 檢查 script，也使用另一個 Claude Code session 與 Codex 做交叉審查。確認流程後，再要求把並行上限調成三個 agents，最後才批准執行。

這個順序建立了一個清楚的控制迴路：

1. 生成計畫：Agent 把自然語言任務轉成具體 script。
2. 檢查結構：人確認階段、依賴、Prompt、工具與寫入範圍。
3. 交叉審查：另一個模型尋找邏輯漏洞、無界迴圈、錯誤權限與成本風險。
4. 調整護欄：修改並行度、預算、停止條件與核准點。
5. 人工批准：確認後才讓 script 取得執行權。

這比「相信 Opus 很會寫 JS，所以可以直接跑」可靠得多。旗艦模型確實能快速產生 orchestration code，但這類 code 的錯誤成本和一般 UI bug 不同。它可能放大成數十次模型呼叫、跨 repository 修改、重複留言、錯誤部署或敏感資料外送。

審查 Workflow script 時，可以優先看以下項目：

• 是否存在沒有上限的 loop 或 recursive retry。
• subagents 是否拿到超出責任範圍的工具。
• 是否把不可信文字直接拼進 shell、SQL 或 Prompt。
• 多個 agents 是否會同時修改相同檔案。
• 每一階段輸出是否有 schema 或明確格式。
• 失敗是否會中止，還是帶著錯誤結果繼續。
• 是否保留 log、產物與可重跑的 checkpoint。
• push、deploy、刪除與外部發訊息前是否需要批准。

跨模型 review 也有價值，但不能把兩個模型都同意當成正確證明。它更適合增加檢查視角：一個模型產生流程，另一個模型以攻擊者、維運者或 reviewer 的角度找問題，最後仍由人依風險決定。

這裡可以濃縮成一條原則：把可逆的審查放在不可逆的動作之前。

087. Harness 民主化之後｜真正稀缺的是驗證能力

影片預測，半年後主流模式會變成 AI Agent 自己寫 Harness、自己執行 Harness，而使用者只需描述任務。時間尺度未必能精準預測，但方向確實可見：模型正在逐步吸收 Prompt 拆解、工具選擇、subagent 分工與 script 生成。

這會讓更多人能啟動過去只有熟悉 orchestration 的開發者才能建立的流程。然而，當編排變便宜，新的瓶頸會移到四個地方。

規格

Agent 可以把一句需求擴寫成複雜流程，但如果原始目標含糊，它只會替模糊需求增加更多步驟。誰是使用者、產物要解決什麼問題、哪些約束不能犧牲，仍需要人回答。

驗證

生成十份報告很容易，證明其中的判斷可靠比較難。驗證必須靠測試、schema、來源、benchmark、人工抽查與獨立 review，而不是靠更多 agent 投票。

成本

Agent 自己決定分工時，很容易傾向「多做一些」。團隊需要知道每個階段帶來多少資訊增量，並建立可比較的成本與品質指標。

風險

越能自主執行的 Workflow，越需要權限最小化、秘密管理、審批點、審計紀錄與 rollback。對讀檔與寫摘要的流程，可以容許較高自治；對 production、財務、個資與外部溝通，應保留更強的人為控制。

因此，真正可移植的學習不是記住 ultrawork 或某個環境變數，而是學會寫一份 Workflow contract：

目標：要產出什麼，供誰使用。
輸入：哪些來源可信，哪些只供參考。
階段：哪些工作並行，哪些必須等待。
產物：每一階段輸出的 schema 與存放位置。
驗證：通過哪些檢查才能進入下一階段。
資源：token、時間、並行數與 retry 上限。
權限：每個 agent 可以讀、寫、執行與對外做什麼。
停止：何時失敗、何時請人決策。
批准：哪些不可逆動作必須由人確認。

當這份 contract 清楚，無論底層是 Claude Code Workflow、Codex、CI pipeline 或自製 Agent framework，流程都比較容易遷移與審查。反過來說，如果只有一句「用很多 agents 幫我做到最好」，就算工具能自動產生 Harness，也只是把不可控的 Prompt 放大。

Claude Code Workflow 最有意思的地方，不是讓工程師退出流程，而是把工程師從逐步操作拉到流程設計與風險治理。當 Agent 開始自己寫 Harness，人最需要提升的能力，正是判斷這個 Harness 值不值得被執行。