Claude剛發現了工作流，Charlie從那裏起步

Anthropic最近在Claude Code中引入了動態工作流，這一舉措在開發者社區引起了關注。然而，Charlie Labs的創始人對此持有不同看法：他認為，真正有效的架構不是圍繞會話（session）構建，而是以任務（task）和任務樹（task tree）為核心。

工作流的真正價值在於承認複雜的軟件工程並非線性過程。優秀的工程師會調查、比較選項、檢查邊緣情況、請求審查、運行測試，並在證據與計劃矛盾時調整方向。代理需要具備同樣的能力：一個工作單元可以檢查數據庫層，另一個讀取API邊界，驗證者嘗試破壞補丁，最終答案綜合所有證據形成交接。

但關鍵在於，這需要架構層面的支持，而非僅僅提示詞技巧。多個工作單元需要生命週期狀態、作用域上下文、交接、權限、取消、重試、驗證和記錄。否則，你得到的只是一個令人印象深刻的羣聊，卻消耗大量資源。

Charlie從任務出發，而非會話。一個本地聊天或IDE會話對於緊密循環很有用，但在工作需要共享、恢復、審查或跨工具協調時，會話變得笨拙。它們屬於一個人、一個時間線、一個轉錄，協調痕跡是自願加入的。相反，Charlie將請求本身視為持久對象：一個Slack線程、GitHub評論、Linear問題、定時喚醒或審查請求都成為一個任務。該任務可以創建子任務，每個子任務在有限的角色內運行並返回結構化交接結果。分支、提交、PR、測試輸出、評論和後續問題都會出現在團隊已經工作的系統中。

當出現問題時，這種差異變得至關重要。如果用户在運行中跟進，任務可以適應；如果驗證失敗，失敗成為交接的一部分；如果工作單元完成，它返回持久標識符而非模糊摘要。會話沒有變得更深入，而是工作離開了會話。

反對者可能認為任務樹聽起來很重——工作單元、交接、驗證、持久狀態——這似乎只適用於大型遷移，而非小任務。但事實恰恰相反：重工作流模式的對立面並非玩具模式，而是具有更小影響範圍的相同系統。例如，在Slack中請求修復一個拼寫錯誤，Charlie可以運行一個狹窄的任務，創建分支，格式化文件，打開PR並報告。請求回答一個GitHub審查評論，它可以保留目標，修補代碼，運行相關檢查並在原處回覆。相同的底層，更小的任務，更快的完成。

因此，“工作流模式”是錯誤的思維模型。團隊不應該決定一個請求是否值得編排——每個請求都值得完成它所需的最小編排：有時是一個工作單元和一個命令，有時是一個工作單元樹和驗證過程。編排應是底層基礎設施，而非升級按鈕。

Claude動態工作流對市場而言是一個積極信號，它明確指出了嚴肅的代理工作需要分解、並行、驗證和持久化。但作者認為，討論應更底層：問題不在於代理是否能在會話內創建工作流，而在於產品是否圍繞持久工作構建。Charlie從一開始就基於任務構建：請求成為任務，任務形成樹，工作單元運行有界作業，交接保留狀態，證據進入可審查的工件，後續請求可在運行中到達，守護進程作為有界激活而非假裝永生的後台進程。大工作和微小工作使用相同的機制。工作流不是特性，運行時才是。