我見過不少代理系統，一開始都很有說服力：先研究、再整理、接著寫稿、最後檢查。流程聽起來完整，實際跑起來卻像一條越拉越長的排隊隊伍。前面一個步驟卡住，後面全部乾等；某個代理忘了帶一份資料，下一個代理只好猜；最後連「為什麼走到這一步」都沒人說得清。
問題往往不在提示詞寫得不夠長，而在於我們把所有工作都排成了同一條線。
rari 的〈Graph Engineering〉讓我重新看這件事：與其要求一個代理變得更全能，不如先把工作本身畫對。這篇不是某個框架的操作手冊，而是我會拿來檢查代理系統的一套工作地圖。
先承認一件事：不是每個「然後」都是依賴
「先查市場、然後看文件、再比對競品」聽起來合理，卻很容易把三件互不相干的事硬串在一起。
我現在會先問一句：下一步真的需要讀取上一步的結果嗎？
如果答案是否定的，就不該排隊。讓它們同時出發，等到真的需要比較、去重或下判斷時，再把資料收回來。這不是追求看起來很炫的平行化，而是把等待留給真正有必要的地方。
界定問題與完成條件
↓
拆解研究面向
↙ ↓ ↘
來源查證 技術查證 反例與風險
↘ ↓ ↙
程式去重與彙整
↓
撰寫初稿
↓
獨立驗證節點
↓
人工發布閘門這張圖裡最重要的不是箭頭數量，而是每一條箭頭都要說得出理由：它到底傳遞了什麼資料？如果這份資料不存在，下一步還能不能安全執行？
節點不是職稱，是一個小承諾
我不太相信「研究代理」「寫作代理」這種過度寬鬆的分工。名稱很漂亮，但它們通常什麼都做，也因此很難驗收。
一個值得保留的節點，應該只承諾一件事，而且能把四件事講清楚：
- 它要完成什麼。
- 它收到什麼輸入。
- 它會交出什麼結構化結果。
- 哪些情況算失敗。
例如，「彙整來源」不該交出一段像心得的文字，而應交出可被後續程式使用的資料：來源 URL、主張、支撐主張的段落位置、信心程度與無法確認的地方。下一個節點需要的是可檢查的交接物，不是另一段需要重新理解的散文。
把模型留給判斷，把資料整理交給確定性程式碼。去重、欄位檢查、空值過濾、排序和狀態比對，通常不必再請一個模型來猜。模型真正稀缺的價值，應該放在取捨、解釋與提出下一步假設。
邊才是系統真正的規格
圖上的節點做工作；真正決定系統會不會亂掉的，是節點之間怎麼交接。
我會把每一條邊當成資料契約，而不是簡報上的裝飾箭頭。它需要定義誰可以往下走、帶著哪些欄位、哪些欄位缺失時要停、要補、還是可以降級處理。
這樣做還有一個好處：路由不再藏在模型的長篇回覆裡。模型可以判斷「這個變更風險偏高」，但真正派發到快車道、完整審查或人工覆核，應由明確規則執行。日後回頭看，才知道不是「模型突然想這樣做」，而是某個可讀的條件把工作送往這條路。
四張地圖，已經夠應付大多數工作
我不會因為能畫圖就把每個任務變成大型流程圖。大多數情況，只要辨認自己在哪一種結構裡即可。
鏈條適合每一步都真的依賴前一步，例如先取得登入權限，才能讀資料。菱形適合把一個題目拆成幾條獨立支線，最後再整合。路由適合先判斷任務性質：低風險走短路徑，高風險才進入完整驗證。受控循環適合那些需要修正、再檢查的工作，但它必須有離開循環的硬條件。
關鍵不是記住名字，而是別把菱形畫成鏈條，也別把應該停下來交給人的情況，包裝成「再試一次」。
驗證器要站在交接點，不要坐在作者旁邊
一個代理自己產出、自己稱讚、自己發布，幾乎等於沒有審查。
我更在意那些不直接產出內容的節點。它們只做一件事：攔下不該往下流的結果。文章裡的引用是否真的支持論點？程式是否真的跑過測試？輸出格式是否符合下一段流程？這些問題需要乾淨的檢查條件，而不是讓原本的作者在同一份上下文裡替自己打分數。
驗證失敗時也不必整條流程重來。只把問題送回它所屬的最小範圍：一則沒有證據的主張回到研究節點，一段格式錯誤的資料回到轉換節點，一個高風險的決策則停在人工閘門前。失敗被縮小，修復才會變得可靠。
狀態不是聊天紀錄，是能夠回來的地方
長任務最怕的不是失敗，而是失敗後沒有人知道應該從哪裡接。
我不會把整段對話歷史塞進每一個節點。真正值得留下的，是可追溯的產出物：研究包的 ID、資料版本、驗證結果、已完成的節點、路由理由、嘗試次數與人工決定。系統中斷時，這些資料能回答三件很務實的事：已經完成什麼、為什麼走這條路、下一次能從哪個檢查點安全恢復。
這也是為什麼重跑必須考慮等冪性。若一個節點在重試時會重複寄信、重複扣款、重複寫入資料，恢復就可能變成第二次事故。能重跑的流程，應該先設計好識別鍵、覆寫規則或讀取後再寫入的保護。
讓系統停下來的，不該是疲憊
「做到滿意為止」聽起來很有彈性，對長時間運行的代理系統卻是一個沒有出口的指令。
每個循環都要有可觀察的收斂條件：驗證通過、最大輪數、Token 或成本預算、連續沒有新證據的次數，以及無法收斂時要轉交給誰。這些限制不是束縛創意，而是讓人知道系統什麼時候已經不值得再自動投入成本。
有時候最成熟的輸出不是完成，而是清楚地說：「我試到這裡，缺少這份資料，需要人來決定。」
何時根本不需要畫圖
如果任務很短、上下文裝得下、沒有獨立支線、錯了也容易回頭，而且人一眼就能審完，單一代理加上一個小循環通常比較好。圖不是成熟的象徵，只是把複雜度攤在桌上的工具。
真正值得升級成圖的情況，是工作能平行、節點需要不同工具或權限、成果必須經過獨立驗證、流程會中斷重來，或你開始需要回答「這次花了多少成本、為什麼走這條路、誰允許它做這件事」。
發布前，我會留下這八個問題
- 每條邊真的傳遞資料或授權了嗎？
- 每個節點是否只有一個可驗收的工作？
- 可以平行的地方，是否還在不必要地排隊？
- 彙整前的等待，是否真的需要全部資料？
- 關鍵產出有沒有在交給下游前被獨立驗證？
- 中斷後能不能從檢查點恢復，而且不重複造成副作用？
- 每個循環有沒有成本上限、停止條件與人工出口？
- 把這張圖拿掉後，問題會變簡單，還是反而更難看清？
最後一題最重要。如果圖比它要解決的問題還大，那就不是工程，而是把複雜度畫得更漂亮。
結語
提示詞還是重要，但它只是系統中的一句話。真正決定代理系統能不能長久工作的，是工作如何被拆開、資料如何交接、哪裡必須驗證，以及什麼時候該由人接手。
我對圖工程的理解很簡單：別再要求一個代理記住所有事；先替整個系統安排好誰該做什麼、誰可以往下走，以及誰有權按下停止鍵。