工作流模式：確定性的編排

工作流(workflow)是通過預定義的程式路線來編排LLM和工具的系統。它的執行路徑是確定性的，由開發者預先設計好 -- 每步做甚麼、下一步去哪，都是程式寫死的，LLM只在每個節點負責理解與生成。

以一個訂票Agent為例，工作流可以設計成4個固定節點

1.核實用戶身分 -- 調用身分驗證API，確認用戶
2.搜尋可用航班 -- 根據用戶需求查詢航班數據庫
3.完成付款 -- 調用支付接口付款
4.確認預定 -- 調用預定API鎖定座位，項用戶發送確認訊息

每個節點內部可以使用LLM(ex.用自然語言理解用戶的需求)，但節點之間的順序是程式固定的 -- 系統不會在付款完成之前去預訂座位，也不會在身分核實之前搜尋航班。

工作流模式有"兩"個核心優勢。第一個是嚴格的流程控制：開發者可以確保關鍵步驟不被跳過或亂序執行，例如"付款前不能預定"這類業務規則通過程式強制執行，不依賴LLM的判斷。第二個是安全性：由於執行路徑是確定的，提示注入或模型犯錯最多只能影響當前節點內部處理，無法讓Agent跳到不該執行的分支-- 攻擊面被限制在單個節點。

舉一個最簡單的例子：文生圖。用戶需求往往是一句大白話，"幫我畫一個貓在喝水的場景";可stable diffusion這類模型只接受特定風格的提示詞--逗號分隔的英文標籤、質量詞、負面提示詞。所以工作流要在用戶和生圖模型之間安排兩個節點：

1.提示詞改寫：用LLM把用戶的自然語言轉換成文生圖模型習慣的提示詞格式。對於上面的例子，"幫我畫一個貓在喝水的場景"是個廣泛的需求，因此LLM還需要思考(哪種貓、在哪裡、水要在哪)，最後給出具體場景描述(prompt不完全，即可能給你模型最常輸出的樣式)
2.圖片生成：用改寫後的提示詞調用文生圖模型，得到圖片

執行路徑是利用程式寫死的。這個工作流裡的LLM節點是做翻譯，就是把人話轉成工具聽得懂的輸入格式，它存在的原因是文生圖模型"聽不懂人話"(就是字面上的意思😅)。這種專門給工具(或模型)的能力短版打補釘的Harness程式，可以稱為適配層。

但如果把生圖工具換成具備原生圖象生成能力的多模態模型，比如Nano Banana2、GPT-Image 2，就不再需要提示詞改寫。不管用戶怎樣措辭，模型能夠聽懂就能出圖。

Codex Harness全面開源：
GitHub： https://github.com/openai/codex
OpenAI 宣布開源 Codex Harness，將 AI Agent 的底層執行邏輯交付開發者。此次行動旨在終結「通用聊天框」的單一互動模式，允許 AI 直接集成到專業業務看板中。通過提供 CLI、SDK 與 app-server，開發者可精準控制介面、上下文與工具權限。