Prompt 已經寫很細了，Workflow 為什麼還是不穩？

在使用 ChatGPT MyGPT 這類工具時，常會碰到這種情況：明明已經把步驟一、二、三寫得很清楚，甚至快寫到八千字長度上限，它還是不一定照順序做，也不一定會把前一步做完才往下走。¹ 結果，流程不會自己穩定推進，而是使用者得一路追著它跑，不斷補盯、補問、補救。

把 prompt 寫成 pseudo code 是否就能自動解決呢？

Pseudo code 形式的提示，的確可能改善步驟描述、問題分解與推理表現；² 把部份子工作移交給外部程式處理，也可能讓某些環節更穩（這也是 agent skills 推薦的技巧）。³ 但這多半只是局部的改善。

反觀某些工具，處理長串流程的穩定度會明顯高於單靠 prompt 的系統。以 Claude Code 為例，它做一長串動作時，常會在中途停下來，檢查某一步有沒有成立，再決定要不要往下一步走。⁴

這給了我們一個暗示，某些原本放在 prompt 裡的責任，其實應該移交給外部控制機制。⁵

這篇文章要談的，就是在多步驟 workflow 下，責任該怎麼重新分配。

Workflow 常見的失靈情況

多步驟 workflow 常見的失靈，不是 agent 完全沒做事，而是某一步其實還沒達到可以進入下一步的條件，流程卻已經先往下走了。

先看清楚有哪些失靈型態，才不會把所有問題都模糊地歸成「模型不穩」，最後又走回修 prompt 措辭的老路。

前一階段還沒做完，後一階段就先開始

很多 workflow 有明確前後順序，前一階段是否真的完成，會直接影響後一階段能不能開始。

問題是，就算 prompt 裡特別提醒「請照順序做」，agent 仍然很容易在前一段只做了一部分時就先往下走，或者把局部進展誤判成整體完成。表面上看起來流程順順地走，實際上是在偷渡。

解決這類問題的關鍵，是要有階段切換門檻：前一階段到底要滿足什麼條件，才可以切換到下一個階段。譬如說，若 workflow 要先完成資訊蒐集、列出受影響檔案、完成某個 patch，或確認某個工具結果，這些條件就得變成可檢查的切換條件。Prompt Chaining ⁶ 若少了這一環，後續步驟很容易過早展開。

只要 workflow 的階段切換開始依賴外部可檢查的完成條件，責任就不能只留在語言敘述層。⁷

說是已經做了，但其實並沒有

模型很容易把打算做的事、以為做過的事，或上一輪口頭描述過的事，直接當成已經發生的結果。這時流程雖然還在跑，但一樣是在偷渡。

解決這類問題的關鍵，是把實際結果納入流程判斷，而不是繼續相信 agent 的口頭自述。只要有工具在執行，workflow 的真實狀態就不只在 token 裡，也在檔案、命令輸出、測試結果、資料寫入狀態與其他可讀取的執行結果裡，甚至包成 sandbox。⁸ Claude Code 這類工具之所以看起來比較會在中途調整，背後也是根據外部是否有實際結果來判斷，而不是只照著一開始的語言規劃一路往前衝。⁴

不能只看模型上一輪說了什麼，要看它做了沒。

驗證還沒通過，系統就先算完成

很多 workflow 不只要求產生內容，還要求它通過測試、比對、檢查、資料讀取或其他形式的驗證。

問題是，模型很容易把「答案已產生」直接當成「工作已完成」。內容也許已經生成，但還沒通過驗證，流程卻已經先宣布結案。

解決這類問題的關鍵，就是把驗證機制真正實作出來，確實併入完成條件的一部分。⁹ Prompt 可以要求「驗證通過才能算完成」，但如果系統沒有把驗證變成真正的完成條件與放行門檻，這句話就只是許願，算不上控制。¹⁰

問題其實都落在「完成的判定」

我把以上情況整理成一張表：

這些情況表面上不同，骨子裡其實都在問同一件事：流程往下走之前，系統到底根據什麼來判定這一步已經完成，判定它已經可以繼續往下走？

Prompt 的極限到哪裡，系統的責任就從哪裡開始

既然已經知道，把 prompt 寫得更像 SOP 有其極限，接下來就要問：哪些責任仍適合留在語言層，哪些責任其實已經需要外部承接。

對多步驟 workflow 來說，prompt 最擅長處理的，仍然是流程說明：任務怎麼展開、各階段如何安排、要留下哪些中間產物、哪些不確定性要揭露、輸出格式與角色邊界是什麼。這些要求會直接影響 agent 怎麼走。

所以 prompt 通常負責這些事（這也是所謂「prompt 模板」常見的套路）：

• 任務意圖與角色界定
• 階段順序與作業程序
• 中間產物與輸出格式
• 需要揭露的不確定性與限制

但只要 workflow 開始依賴下面這些能力，責任通常就不能只留在 prompt：

• 持有真實狀態
• 判定某一步是否已完成
• 在條件未滿足時擋下後續步驟
• 接住高風險副作用
• 提供 retry、resume、rollback 與 audit
• 持續量測控制是否退化

換句話說，prompt 負責把流程講清楚；至於完成條件、階段切換條件、工具結果怎麼確認、流程卡住時怎麼處理、失敗後怎麼恢復，則比較接近系統該接手的部分。¹¹

這樣拆的好處是：不會把所有問題都塞回 prompt，也不會把所有任務都誤判成一定要上到很重的外部系統。

什麼情況需要把控制交給外部機制

談到這裡，我們可以歸納出，哪些要求值得外移，又該外移到什麼程度。

可以先看 workflow 的成敗，是否已經明顯依賴以下幾種能力：

只要遇到這幾種情況，相關控制責任通常就值得外移。像驗證是否成立、workflow 是否退化這類問題，已經需要可量測的 eval、trace 或 grader 來承接。像 retry、resume、rollback 這類恢復能力，則更明顯屬於系統層機制，而不是單靠語言承諾。¹²

相反地，若任務流程短、狀態依賴弱、錯誤成本低、副作用小，而且完成與否主要還是取決於文字品質、結構清楚或分析完整度，prompt 往往仍然是成本效益最高的主要承接方式。這種情況下，把要求留在 prompt，再配合適度的格式約束與中間產物揭露，通常就夠了。

不是每一個多步驟任務，都值得為了少量風險加上一整套外部控制。畢竟很多團隊真正需要的，未必是很重的 agent platform。常常只需要一層很薄的外層包裝，把幾件事真正接住。

所以判斷要不要外移，看的不是流程有幾步，也不是 prompt 已經寫了多長，而是：「完成」這件事，是不是已經需要由語言以外的東西來決定。

結論

步驟明明已經寫清楚了，agent 還是不照著做，很多時候不是因為 prompt 還不夠細，而是 workflow 已經進入另一種責任分配：怎麼才算完成、什麼時候才能往下走、工具結果要不要納入判斷、驗證是否成立、失敗後果由誰接住，這些都不能只靠語言承諾支撐。

多步驟 workflow 要穩，關鍵不是再把 prompt 步驟寫得很細，甚至改寫成 pseudo code，而是先分清楚：某一步算不算完成，最後由誰判定。

下一次遇到問題時，先不要急著把 prompt 再寫長一倍。