01
定義任務
先明確輸入、限制、輸出格式與完成條件，避免一開始就讓 Agent 在模糊目標下亂跑。
Agent / Workflow / 多步任務實戰
先講結論：多步任務的關鍵不是讓模型想更多，而是把任務拆清楚、每一步可觀測、每一層有明確收斂條件。前面三章談的是能力封裝、能力接入與執行環境；這一章開始談的是它們如何真的一起跑成工作流。
這章要解決什麼問題？
前面三章已經回答了三件事：怎麼封裝做事方法、怎麼接外部能力、以及這些能力在什麼環境裡被組起來。 第 9 章要處理的，就是最後一個最實務的問題：這些能力在真實任務裡，到底怎麼跑成一條能交付結果的多步流程？
從單次問答到多步任務，差在哪裡？
單次問答通常是一輪輸入、一輪輸出；多步任務則需要規劃、查資料、執行工具、檢查結果，再決定下一步。這兩者不是難度多一點而已，而是系統型態不同。
面向
單次問答
多步任務
輸入型態
一次性問題與上下文
會隨步驟逐步補充資訊與中間結果
執行方式
模型直接生成答案
模型要配合流程、工具、檢查與回饋
穩定關鍵
Prompt 品質
流程設計、觀測能力、停止條件
常見風險
答非所問、格式不穩
無限循環、工具亂調、步驟失控、錯誤累積
一個實用的 Agent Workflow 長什麼樣？
與其期待模型一次想完全部，不如把它放進一條可觀測的任務管線：理解任務、拆解步驟、查資料、執行、驗證、收斂。
02
拆成子任務
把大目標切成幾個能執行的步驟，例如分類、檢索、生成、比對與總結。
03
調用工具或能力
需要資料時再查，需要執行時再做，不要什麼都先調一輪。
04
檢查與收斂
看結果是否足夠、是否偏題、是否需要補查，最後再決定結束或進入下一步。
一個具體實戰案例：從需求到可交付結果
這裡用一個常見場景示範：使用者要 AI 幫忙診斷專案問題並提出修法。重點不是 domain 本身，而是 workflow 怎麼設計才不失控。
Step 1
先釐清問題與成功標準
例如：是 build fail、runtime error、還是 API 契約不一致？最後要的是解法、原因，還是可直接提交的修補方案？
Step 2
再根據流程決定查什麼
先看設定檔、錯誤訊息、模組結構，再去查 log、版本與依賴，不要直接跳到猜修法。
Step 3
最後把輸出收斂成可行動結果
回答應該包含結論、根因、修法與驗證方式，而不是一堆未整理的中間觀察。
多步任務最容易踩的坑
- 目標不明確： Agent 會一直做事，但不知道什麼時候該停。
- 步驟太大： 每一步都過於抽象，導致很難觀察與驗證。
- 工具亂調： 沒有條件就先呼叫一堆工具，成本上升、訊號反而變髒。
- 沒有中間檢查點： 一旦早期判斷錯，後面會整條流程一起偏掉。
- 輸出不收斂： 最後交付的是過程，不是答案。
設計 Workflow 的實務原則
好的 workflow 不一定複雜，反而通常是簡單、分層、可觀測、能停止。
先切最小步驟
把每一步縮到可以描述、觀察、驗證，避免讓 Agent 一口氣吞整個大任務。
每一步都要有出口
不是繼續跑，就是回報不確定、請求補件、或結束流程，不要永遠停不下來。
先能用，再加自動化
先做半自動、可觀測版本，確認穩定後再增加更多工具與更多自動決策。
把這章跟前面串起來
- Prompt 讓每一步說得清楚。
- Skill 讓某類 workflow 可以被反覆重用。
- MCP 讓 workflow 在需要時能接到外部能力。
- OpenClaw 則是把整條多步任務真正跑起來的執行環境。
所以多步任務不是額外附加的技巧，而是前面幾章能力真正開始協作的地方。
這一段學完後，你應該會有什麼感覺？
到這裡，讀者應該已經能把整條路徑串起來：先理解模型，再學會下指令，接著封裝 Skill、接入 MCP、理解 OpenClaw 這類 runtime，最後把它們放進真的能交付結果的多步 workflow。
1 分鐘小測驗
Q：做多步任務時，哪個做法最穩？