工單驅動的 agent 編排

資料來源#

• An open-source spec for Codex orchestration: Symphony.

摘要#

一個由 OpenAI 的 Symphony 所定型的模式，它反轉了 agentic 工作慣常的單位：issue tracker 上的工單成為工作單位，而非編寫程式的 session 或 pull request。開啟中的工單就是佇列；是 agent 被拉去處理工單，而非由人類把 session 指派給 agent；工單會橫跨多個 PR、重啟與接續回合持續存在。這個模式讓 agentic 執行同時與 session 和 PR 解耦，使非工程師也能派發工作，也讓單一工單能涵蓋產出零個、一個或多個 PR 的調查。

詳述#

反轉#

傳統的 agentic 編寫程式工作流，不是圍繞 session（Claude Code 的對話串），就是圍繞 PR（合併後的單位）來組織。両者都是為達目的而設的抽象。軟體工作真正的組織原則是交付物：issue、工單、里程碑。

Symphony 的重新框定：

「軟體工作流大多圍繞交付物來組織：issue、任務、工單、里程碑。於是我們自問：如果不再直接監督 agent，而是讓它們自己從任務追蹤器拉取工作，會發生什麼事？」

一旦工單成為單位：

• 一張工單 → 多個 PR 是常態。一張「把驗證遷移到 OIDC」的工單，可能橫跨 2 個 repo、涵蓋 3 個 PR。
• 一張工單 → 零個 PR 也是常態。「調查 CI 為何不穩定」或「草擬架構規劃」產出的是筆記／提案，而非程式碼變更。
• PR 成為工單的產物，而非工作本身。
• 由 agent 拉取工作；人類不再推送 session。

DAG 式依賴關係#

工單帶有阻擋（blocker）關係。Symphony 的 Issue.blocked_by 欄位是候選挑選規則的一部分：

「如果 issue 狀態是 Todo，只要有任何 blocker 尚未進入終結狀態，就不要派發。」

再結合 agent 能開立新工單的能力，這就形成了一個工作的有向無環圖（DAG），並依依賴順序逐步展開。文中的具體例子：

「我們把 React 升級標記為被遷移到 Vite 所阻擋。如預期，agent 只有在遷移到 Vite 完成之後，才開始升級 React。」

重要的是，這個 DAG 是可由 agent 擴充的：在實作或審查過程中，agent 若注意到鄰近的改進空間（效能問題、重構機會、更好的架構），會開立新工單，而不是擴張當前的範圍。這些後續工作中有許多接著會被其他 agent 接手。

誰來開工單#

一旦執行與 session 解耦，任何人都能在不碰 repo 的情況下派發 agentic 工作：

• 工程師開工單的方式，就和他們回報 bug 一樣。
• PM 與設計師可以直接把功能需求開進追蹤器，無須 check out repo，也不必管理 Codex session。他們的交付物是一份「審查包（review packet）」，內含功能運作的影片導覽。
• OpenAI 的文章引述了一位工程師，他「在一間舒適的小木屋裡、用著很差的 wifi，透過手機上的 Linear app」做了三項重要的變更。

經濟層面的效果是：每項變更的感知成本下降，因為人力不再是瓶頸資源。這會改變行為——投機性的工單、探索性的重構，以及「試試這個點子」的任務都變得廉價。捨棄的成本也趨近於零。

「目標，而非狀態轉移」#

這是 Symphony 演進過程中的一個關鍵教訓。他們的第一個版本把 agent 當成狀態機裡僵固的節點——Codex 只被要求實作工單裡的任務。一旦模型變得更聰明，這就顯得太過侷限：

「Codex 完全有能力建立多個 PR，也能讀取審查回饋並加以處理。所以我們給了它工具——gh CLI、讀取 CI 日誌的 skill 等等——現在我們可以要求 Codex 做更多事，例如關閉舊的 PR，或拉取已完成與已放棄工作的對比報告。」

這個轉變是：給 agent 目標（工單的標題／描述）與工具，而不是嚴格的狀態機轉移。這是在編排層對「強制不變量，而非實作」的重新表述——編排器約束的是邊界範圍（envelope）（每個 issue 的工作空間、並行上限、終結狀態的清理），而不是 agent 在這個範圍內所採取的步驟。

Workflow.md 的「prompt 即政策」模式#

在工單驅動的編排中，工作流政策存放在 repo 裡一份受版控的 markdown 檔案中（Symphony 的 WORKFLOW.md）。它捕捉了那套隱性的「人類遵循、卻從未被記錄下來的流程」：

「處理一個 issue、check out 一個 repo、把它標為進行中讓 PM 知道有人在做、附上 PR、把它移到 Review 狀態、附加影片等等——現在全都被收進一份簡單的 WORKFLOW.md 檔案裡。」

當團隊決定 agent 也應該為完成的工作附上自我反思時，他們就編輯 WORKFLOW.md；下次渲染時，agent 便會遵循這個新步驟。這就是把工作流當成 prompt 即政策——這正是促使 CLAUDE.md、AGENTS.md 與 SOUL.md 成為 agent context 檔案的同一個模式（見 Claude Code Best Practices、Hermes Agent）。

吞吐量之外的影響#

產出的提升是最顯眼的效果（Symphony 那項有所保留的 500% 已落地 PR 的說法，見 Symphony）。但更深層的效果在於團隊的行為：

1. 啟動工作的認知成本降到 ~0，因此團隊會開出多得多的投機性／探索性工單。
2. 工程師不再在多個進行中的 session 間切換脈絡，而是一次專注於一個困難的問題。
3. 最後一哩的可靠度提升——Symphony 會盯著 CI、進行 rebase、解決衝突、重試不穩定的檢查，所以等到一張工單抵達 Merging 時，變更便能在無人看顧的情況下落地。
4. 文件養護成為一種工單類型，而不是無人認領的副業專案。
5. 例行工作與有趣工作乾淨地區分開來——agent 處理大部分的實作；人類專注於模糊、需要高度判斷的工作。

這個模式不適用之處#

來源中坦誠列出的取捨：

• 失去執行途中的引導：在工單層級指派工作，意味著執行過程中無法即時微調。失敗會暴露 harness 的缺口，並以系統層級全面修補，而非當下臨時修正。
• 模糊的問題仍然需要人類：需要強烈判斷力、深厚專業或專家品味的任務，仍然更適合在互動式 session 中處理。
• 對追蹤器的依賴：編排器如今與追蹤器的 API 與可用性綁在一起。Symphony 沒有持久化的 DB，而是仰賴追蹤器＋檔案系統來進行重啟復原——當 Linear 掛掉時，工作就會暫停。

相關連結#

• Symphony — 典範實作；涵蓋 OpenAI 特定編排器的實體頁面
• Codex App Server Protocol — Symphony 用於各工單 session 的執行期協定；接續回合讓一張工單能在同一個 thread_id 上橫跨多個回合
• Agent Harness Engineering — 工單驅動的編排是 harness 工程的自然延伸：一旦各 session 的 harness 能運作，下一個瓶頸就是接下來該跑哪個 session。「目標，而非狀態轉移」正是「強制不變量，而非實作」在編排層的重新表述
• Claude Code Best Practices — Claude Code 的 claude -p 非互動模式，是在 Claude 這一側實現工單驅動編排的基礎構件；subagent 以及 Writer/Reviewer 模式都能接進追蹤器，就像 Symphony 把 Codex 接到 Linear 一樣
• Client-Side Agent Optimization — 在這種規模下，AgentOpt 式的組合挑選在營運上變得重要：在 WORKFLOW.md 的 prompt 範本裡，依工單類型（規劃者 vs. 求解者 vs. 審查者）選擇正確的模型，是一項以管線為單位的預算決策
• Hermes Agent — Hermes 的 cron 工作與 home-channel 投遞是個較輕量的類比：由 agent 自行派發、排程好的交付物，其結果回報到聊天室而非工單
• LLM-as-Compiler Knowledge Base — 這個 wiki 的 /compile 與 /lint 本身就是類似工單的工作單位，可以接進 Symphony 式的 daemon
• Model Spec Midtraining (MSM) — 把「規格即文件」的模式（SPEC.md → 工單 → agent）再往深處推一層：Model Spec 成為直接的訓練輸入，而不只是執行期的指引
• Agent Context Files — WORKFLOW.md 是「markdown 即控制平面」模式在編排層的實例；工單層會去呼叫 context 檔案所定義的政策平面

衍生內容#

• Agent Control Plane Patterns: Tickets, Loops, Specs, and Memory Files — 把工單定位為主要的持久工作圖、把迴圈作為執行、把規格／context 檔案作為政策，而記憶則作為有界的回溯

開放問題#

• 當工作單位是「一個 agent 在一個工作空間裡所做的事」時，工單大小的正確粒度是什麼？文章暗示「大得多的工作單位」變得可行，但這又如何與 agent.max_turns 上限（預設 20）互動？
• 當 agent 大量開立後續工單時，要如何避免工單擴張的連鎖效應？唯一的治理檢查點，是否就是人類在 Todo 狀態佇列上的分流？
• 這個模式能推廣到非軟體的工作嗎（研究、維運、內容）？DAG 依賴模型與「prompt 即政策」檔案應該可以移轉；但各 issue 一個工作空間的做法則不那麼顯然。
• 當 agent 把一張工單「完全做錯」（文中有提到）時，這個教訓要如何回饋進系統？Symphony 的答案是「增加 guardrail 與 skill」——但實現這件事的制度化流程是什麼？
• 工單驅動的編排，要如何與以工單聚合為操作對象的 sprint 規劃／OKRs／roadmap 工作互動？當工單被切得那麼小時，這個抽象會不會崩解？

資料來源#

• An open-source spec for Codex orchestration: Symphony.