以工單驅動的代理程式編排

資料來源#

An open-source spec for Codex orchestration: Symphony.

摘要#

OpenAI 透過 Symphony 編纂的一種模式，顛覆了代理式工作的慣常單位：問題追蹤器中的工單成為工作單位，而不是程式編寫工作階段或合併請求。未結工單就是佇列；代理程式會領取工單，而不是由人類把工作階段指派給代理程式；工單可跨越多個 PR、重新啟動和延續回合持續存在。這種模式讓代理式執行與工作階段及 PR 脫鉤，因此非工程人員也能派發工作，而且單一工單可涵蓋調查，最後產生零個、一個或多個 PR。

詳情#

反轉#

傳統的代理式程式編寫工作流程，通常以工作階段（Claude Code 的聊天串）或 PR（合併後的單位）為核心。兩者都是達成目的的抽象。軟體工作的實際組織原則是交付成果：問題、工單、里程碑。

Symphony 的重新詮釋如下：

「軟體工作流程大多以交付成果來組織：問題、任務、工單、里程碑。因此我們開始思考，如果不再直接監督代理程式，而是讓它們從任務追蹤器領取工作，會發生什麼事。」

工單成為單位之後：

一張工單 → 多個 PR 很常見。「將驗證遷移至 OIDC」這張工單可能涵蓋 2 個儲存庫中的 3 個 PR。
一張工單 → 零個 PR 也很常見。「調查 CI 為何不穩定」或「草擬架構計畫」會產生筆記或提案，而不是程式碼變更。
PR 成為工單的產物，而非工作本身。
代理程式領取工作；人類不再推送工作階段。

DAG 式相依性#

工單帶有阻擋關係。Symphony 的 Issue.blocked_by 欄位是候選項目選取規則的一部分：

「若問題狀態為 Todo，只要有任何阻擋項目尚未進入終止狀態，就不要派發。」

加上代理程式能建立新工單，便形成了依相依順序展開的有向無環工作圖。原文中的具體例子：

「我們將 React 升級標記為受 Vite 遷移阻擋。果然，代理程式直到 Vite 遷移完成後才開始升級 React。」

值得注意的是，這個 DAG 可由代理程式擴充：在實作或審查期間，代理程式若發現相鄰的改進機會（效能問題、重構機會、更好的架構），就會建立新工單，而不是擴大目前工作的範圍。許多後續工作會由其他代理程式接手。

誰建立工單#

執行與工作階段脫鉤後，任何人都能派發代理式工作，不必碰儲存庫：

工程師像回報錯誤一樣建立工單。
PM 和設計師可以直接在追蹤器中提出功能需求，不必簽出儲存庫或管理 Codex 工作階段。他們交付的是一份「審查資料包」，附上展示功能運作情況的影片。
OpenAI 的文章提到，有位工程師「在偏僻小屋裡用不穩定的 Wi-Fi，透過手機上的 Linear app 完成了三項重大變更」。

經濟上的影響是：每項變更的感知成本降低，因為人力不再是瓶頸資源。行為因此改變——推測性工單、探索性重構和「試試這個點子」之類的任務，成本都變得低廉。捨棄成果的成本也幾乎為零。

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

這是 Symphony 演進過程中的一項重要教訓。第一版把代理程式當作狀態機中的僵化節點——Codex 只被要求實施工單中的任務。模型變得更聰明後，這種方式就顯得限制太多：

「Codex 完全有能力建立多個 PR，也能閱讀審查意見並據此修正。因此我們給了它工具——gh CLI、讀取 CI 記錄的技能等——現在我們可以要求 Codex 做更多事，例如關閉舊 PR，或拉取已完成與已放棄工作的報告。」

做法改為給代理程式目標（工單標題／描述）和工具，而非嚴格的狀態機轉換。這是在編排層重新表述「強制遵守不變條件，而非指定實作方式」：編排器限制的是範圍邊界（每個問題各自的工作區、並行上限、終止狀態清理），而不是代理程式在範圍內採取的步驟。

Workflow.md：提示即政策模式#

在工單驅動的編排中，工作流程政策存在儲存庫內一份有版本控管的 Markdown 檔案裡（Symphony 的 WORKFLOW.md）。它記錄了人類一直遵循、卻從未寫下來的隱含「流程」：

「處理問題、簽出儲存庫、將狀態設為進行中讓 PM 知道有人正在處理、加入 PR、將狀態改為 Review、附上影片等——現在都記錄在一份簡單的 WORKFLOW.md 檔案裡。」

當團隊決定也要讓代理程式為已完成的工作附上自我反思時，只要編輯 WORKFLOW.md；下一次產生工作流程時，代理程式就會遵循新步驟。這就是提示即政策的工作流程模式——它也是將 CLAUDE.md、AGENTS.md 和 SOUL.md 作為代理程式脈絡檔案的動機所在（參見 Claude Code Best Practices、Hermes Agent）。

超越吞吐量的影響#

產出提升最為顯著（Symphony 謹慎提出 PR 落地量提升 500% 的主張，參見 Symphony）。更深層的影響則在團隊行為：

啟動工作的認知成本降至約 0，因此團隊會建立更多推測性／探索性工單。
工程師不再在多個進行中的工作階段之間切換脈絡，轉而一次專注於一個棘手問題。
最後階段的可靠性提升——Symphony 會監看 CI、重新定基、解決衝突、重試不穩定的檢查，因此工單到達 Merging 時，變更已可直接合併，不必有人守著處理。
文件維護成為一種工單類型，不再是無人負責的副專案。
例行工作與有趣工作清楚分流——代理程式負責大部分實作；人類專注於模糊且需要高度判斷的工作。

此模式不適用的情況#

原文坦承的取捨：

失去執行期間的引導能力：以工單層級指派工作，代表無法在執行過程中即時引導。失敗會揭露 harness 的缺口，並透過全系統修補處理，而不是當下解決。
模糊的問題仍需要人類：需要強烈判斷力、深厚專業知識或專家品味的任務，仍較適合在互動式工作階段中處理。
依賴追蹤器：編排器現在與追蹤器的 API 和正常運作時間緊密相連。Symphony 沒有耐久資料庫，依賴追蹤器和檔案系統來復原重新啟動前的狀態——Linear 停擺時，工作也會暫停。

延伸閱讀#

Symphony — 經典實作；介紹 OpenAI 特定編排器的實體頁面
Codex App Server Protocol — Symphony 用於每張工單工作階段的執行階段通訊協定；延續回合讓同一張工單能以相同的 thread_id 跨越多個回合
Agent Harness Engineering — 工單驅動編排是 harness 工程的自然延伸：每個工作階段的 harness 運作良好後，下一個瓶頸便是接下來執行哪個工作階段。「目標，而非狀態轉換」是在編排層重新表述「強制遵守不變條件，而非指定實作方式」
Claude Code Best Practices — Claude Code 的 claude -p 非互動模式，是在 Claude 端實現工單驅動編排的基礎；子代理程式以及 Writer／Reviewer 模式也能像 Symphony 將 Codex 連接至 Linear 一樣，連接至追蹤器
Client-Side Agent Optimization — 在這種規模下，AgentOpt 式的組合選擇在實務上相當重要：在 WORKFLOW.md 的提示範本中，依工單類型（規劃者、解題者、審查者）選擇適合的模型，是每條管線的預算決策
Hermes Agent — Hermes 的 cron 工作和主頻道交付，是較輕量的類似做法：代理程式自行派發排程交付項目，並將結果送回聊天，而非工單
LLM-as-Compiler Knowledge Base — wiki 的 /compile 和 /lint 本身就是類似工單的工作單位，可接入 Symphony 式的常駐程序
Model Spec Midtraining (MSM) — 將規格文件模式（SPEC.md → 工單 → 代理程式）再往深一層泛化：Model Spec 成為直接的訓練輸入，而不只是執行階段的指引
Agent Context Files — WORKFLOW.md 是 Markdown 即控制平面模式在編排層的實例；工單層會呼叫脈絡檔案所定義的政策平面
Loop Engineering — Linear 看板（或 Markdown 檔案）是迴圈的第六項基本元素，記憶——耐久的工作圖，讓晨間自動化能從昨天中斷之處繼續；工單驅動編排則是將此狀態基本元素提升為一級概念
Agentic Work Systematization — 工單代表外部化代理程式脈絡的工作圖面向；技能／外掛代表程序面向——兩者都能將臨時委派轉變為可重複、可交接的工作流程
Parallel Agent Orchestration — 這是另一種在聊天回合之外派發代理程式的機制：Cursor Projects 會訂閱 Slack／排程／PR 事件訊號並推送工作，而 Symphony 則從工單佇列領取工作；兩者都讓派發脫離同步提示，但尚未有人用相同任務比較兩者
Orchestration-Plan Simulation — 這是本文相依圖經過基準測試的形式，也是兩者的範圍界線。OrchBench 將任務 DAG 作為固定輸入，只評估規劃者如何處理它（哪個代理程式執行哪個子任務，以及哪些資訊在代理程式之間傳遞），這正是 Symphony 留給代理程式處理的一半：Symphony 的 blocked_by 圖可由代理程式擴充，並在執行期間持續成長；OrchBench 則將它固定下來，以便單獨評估計畫品質。它的研究結果揭示了本文模型容易忽略的一點——相依邊並非免費。當某張工單的輸出是另一處工單的先決條件時，就必須有人把結果傳遞過去；在 OrchBench 的測量中，幾乎所有品質損失都來自省略或過度壓縮的交接，遠多於代理程式數量的影響。追蹤器若只記錄 blocked_by，卻沒記下傳遞了什麼，記錄的就只是計畫的一半

衍生項目#

Agent Control Plane Patterns: Tickets, Loops, Specs, and Memory Files — 將工單定位為主要的耐久工作圖、將迴圈定位為執行方式、將規格／脈絡檔案定位為政策，以及將記憶定位為有界的回憶能力

待解決的問題#

當工作單位是「單一代理程式在單一工作區中執行的工作」時，工單大小應該如何拿捏？原文暗示「大得多的工作單位」也能實行，但這與 agent.max_turns 上限（預設為 20）如何相互影響？
代理程式大量建立後續工單時，要如何避免工單擴張連鎖？唯一的治理方式是由人類整理 Todo 狀態的佇列嗎？
此模式能否推廣至非軟體工作（研究、營運、內容）？DAG 相依性模型和提示即政策檔案應該都能沿用；但每個問題專屬的工作區似乎不容易照搬。
當代理程式把工單「完全做錯」（原文提及）時，如何將教訓回饋至系統？Symphony 的答案是「加入防護措施和技能」——那麼組織層面的流程又是什麼？
工單驅動編排如何與衝刺規劃／OKR／路線圖互動？這些工作的單位是多張工單的集合。工單範圍縮小到這種程度時，抽象方式是否會失效？

資料來源#

An open-source spec for Codex orchestration: Symphony.