超越提示詞：為什麼 AI Agent 需要確定性的控制流

關於 AI agent 的主流敘事長期以來一直圍繞著「提示工程」（prompt engineering）——即尋找神奇字句來讓模型表現出特定行為的藝術。然而，隨著開發者從簡單的原型轉向複雜且具備生產能力的系統時，他們正撞上一道牆。當你發現自己必須使用全大寫輸入 MANDATORY 或 DO NOT SKIP 來強迫模型遵循某個序列時，你就已經達到了「提示詞的瓶頸」。

軟體開發中的可靠性向來是透過確定性的控制流（deterministic control flow）來實現的：明確的狀態轉換、驗證檢查點以及遞迴的可組合性。為了讓 AI agent 從「隨機鸚鵡」轉變為可靠的工具，邏輯必須從散文式的描述中移出，進入執行階段（runtime）。

提示詞邏輯的失敗

提示詞鏈（prompt chains）本質上是非確定性的且規範定義模糊。將 LLM 視為整個系統而非系統中的單一組件，會導致隨著複雜度增加，可靠性也隨之崩潰。

想像一種程式語言，其中的語句僅僅是建議，而函數可以回傳「成功」卻同時產生幻覺結果。在這樣的環境中，推理變得毫無可能。這就是目前許多 agentic workflows 的現狀，即 LLM 被指派去管理其自身的高層級編排。正如一位用戶在 Hacker News 的討論中所提到的，讓模型管理控制流通常會導致它遺漏檔案、重複測試 bundle，或陷入迴圈——即使是像 GPT-4 或 Claude 3.5 這樣最先進的模型也會發生這些失敗。

將邏輯移至執行階段

為了構建可靠的 agent，開發者必須實施確定性的腳手架（scaffolds）。這意味著將 LLM 視為執行特定、受限任務的工具，而周圍的軟體則處理「如何做」以及「何時做」。

1. 確定性編排

與其要求 agent 「研究一個主題然後寫一份報告」，確定性系統會將其分解為一個 DAG（有向無環圖）或狀態機：

• 步驟 1： LLM 生成搜尋查詢。
• 步驟 2： 程式化搜尋執行（確定性的）。
• 步驟 3： LLM 綜合結果。
• 步驟 4： 程式化驗證輸出格式。

透過將帳務處理與路由移至符號層（symbolic layer），開發者可以降低 token 成本、提高速度，並消除 agent 「忘記」步驟的風險。

2. 激進的錯誤檢測與品質閘門

沒有程式化驗證的 agent 僅僅是快速得出錯誤結論的一種方式。社群提出了三種常見（且通常有缺陷）的錯誤處理方法：

• 保姆模式（The Babysitter）： 讓人類參與其中，在錯誤擴散之前將其攔截。
• 稽核員模式（The Auditor）： 在執行結束後進行詳盡的端到端驗證。
• 祈禱模式（The Prayer）： 對輸出結果進行「感覺接受」（vibe-accepting），並寄望於最好的結果。

為了超越這些模式，開發者正在實施「品質閘門」（quality gates）——即處理品質保證的確定性節點。例如，Stripe 的 "Minions" 系統在非確定性的 LLM 工作之間利用了確定性節點，以確保品質，而不必將驗證工作留給 LLM 本身。

來自實務界的觀點

向確定性控制流的轉向引發了各種技術反對意見與補充策略：

LLM 在軟體開發中的角色

有些人認為，最終目標並非在執行階段使用 LLM 來完成任務，而是使用 LLM 來 寫出完成該任務的軟體。在這種觀點下，LLM 的角色縮減為協助使用者向體現了硬性業務規則的系統提供符合規範的輸入。

「操作反射」方法

為了在確保一致性的同時保持一定的靈活性，一些開發者使用「鎖定檔」（lockfiles）來處理常見任務。這些檔案定義了哪些特定的技能或專業知識片段與任務相關，充當協調者，根據預定義的藍圖而非開放式的提示詞來分配任務。

混合模型

關於我們是否只是在重新發明程式語言，目前存在爭議。正如一位評論者所說：

"Can't wait for ya'll to come full circle and invent programming from first principles."

然而，其他人建議採用混合方法——類似於遊戲引擎如何使用高階腳本語言（如 Lua）來呼叫高效能的 C++ 函式庫。在這個類比中，LLM 提供靈活的「腳本」層，而確定性的框架則提供強大的「引擎」。

結論：Agent 工程的未來

設計控制流——而非僅僅撰寫提示詞——正成為 agent engineering 的新前沿。透過將 agent 迴圈與呈現層及控制層分離，開發者可以構建出具備可觀察性、容錯能力且真正具備擴展性的系統。目標並非消除 LLM 的創造力，但要將其約束在一個能保證結果符合使用者意圖的框架內。