票券驅動的代理編排

資料來源#

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

摘要#

這是由 OpenAI 的 Symphony 編纂而成的一種模式，反轉了代理工作的常見單位：議題追蹤器中的票券成為工作單位，而不是撰寫程式的工作階段或 pull request。未關閉的票券就是佇列；代理被拉取到票券，而不是由人類將工作階段指派給代理；票券可以跨越多個 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 最佳實務、Hermes Agent）。

超越吞吐量的影響#

產出增長是最明顯的效果（Symphony 宣稱落地 PR 增加 500%，但特別註明這是對沖後的估計，參見 Symphony）。更深層的影響在於團隊行為：

1. 啟動工作的認知成本降至約 0，因此團隊建立的臆測／探索性票券大幅增加。
2. 工程師不再在許多進行中的工作階段之間切換上下文，而是一次專注於一個棘手問題。
3. 最後一哩的可靠性提升——Symphony 監看 CI、重新建立基礎、解決衝突、重試不穩定的檢查，因此票券到達 Merging 時，變更可以在無需人工照看的情況下落地。
4. 文件園藝成為一種票券類型，而不是無人負責的副專案。
5. 例行工作與有趣工作清楚分離——代理處理大部分實作；人類專注於模糊且需要高度判斷的工作。

不適用此模式的情境#

來源中坦誠提到的取捨：

• 失去執行中的引導：在票券層級指派工作，意味著執行期間無法逐步調整方向。失敗會暴露出工具鞍部的缺口，並以全系統修補的方式處理，而不是當下修正。
• 模糊問題仍需要人類：需要強烈判斷、深厚專業知識或專家品味的任務，在互動式工作階段中處理仍然更好。
• 依賴追蹤器：編排器現在與追蹤器的 API 和運作時間相耦合。Symphony 沒有持久資料庫，而是依靠追蹤器與檔案系統進行重新啟動復原——Linear 停機時，工作就會暫停。

相關連結#

• Symphony — 標準實作；涵蓋 OpenAI 特定編排器的實體頁面
• Codex App Server Protocol — Symphony 用於每張票券工作階段的執行階段協定；延續回合讓單一票券能在相同的 thread_id 上跨越多個回合
• Agent Harness Engineering — 票券驅動的編排是工具鞍部工程的自然延伸：每個工作階段的工具鞍部運作後，下一個瓶頸就是接下來執行哪個工作階段。「目標，而非轉移」是在編排層重新表述「強制執行不變量，而非實作」
• Claude Code 最佳實務 — Claude Code 的 claude -p 非互動模式，是在 Claude 端進行票券驅動編排的基礎元件；子代理以及 Writer／Reviewer 模式，可以像 Symphony 將 Codex 連接至 Linear 一樣接入追蹤器
• 用戶端代理最佳化 — 在這個規模下，AgentOpt 式組合選取變得具備營運重要性：在 WORKFLOW.md 的提示模板中，依票券類型（規劃者、解題者、審查者）選擇正確模型，是每條 pipeline 的預算決策
• Hermes Agent — Hermes 的 cron 工作與主頻道傳遞是較輕量的類比：由代理自行派發的排程交付成果，結果回填到聊天，而不是票券
• LLM 作為編譯器知識庫 — wiki 的 /compile 與 /lint 本身就是類似票券的工作單位，可以接入 Symphony 式 daemon
• Model Spec Midtraining (MSM) — 規格即文件的模式（SPEC.md → 票券 → 代理）再向下一層泛化：Model Spec 成為直接的訓練輸入，而不只是執行階段指引
• 代理上下文檔案 — WORKFLOW.md 是 markdown 作為控制平面模式在編排層的實例；票券層呼叫由上下文檔案定義的政策平面
• 迴圈工程 — Linear 看板（或 markdown 檔案）是迴圈的第六個原語：記憶——讓早晨自動化能從昨天執行停止的地方繼續的持久工作圖；票券驅動的編排，就是將這個狀態原語提升為一等公民
• 代理工作系統化 — 票券是外部化代理上下文的工作圖面；技能／外掛是程序面——兩者都將臨時委派轉化為可重複、可交接的工作流程

推導#

• 代理控制平面模式：票券、迴圈、規格與記憶檔案 — 將票券定位為主要的持久工作圖，迴圈作為執行，規格／上下文檔案作為政策，記憶作為有界回憶

未決問題#

• 當單位是「一個代理在一個工作區中完成的工作」時，票券大小的適當粒度是什麼？文章暗示「大得多的工作單位」變得可行，但這與 agent.max_turns 上限（預設 20）如何互動？
• 如何避免代理自由建立後續票券而造成票券擴張連鎖？唯一的治理檢查是否就是人類對 Todo 狀態佇列進行分流？
• 這種模式能否泛化至非軟體工作（研究、營運、內容）？DAG 相依性模型和以提示作為政策的檔案應該可以移植；但每個議題的工作區就不那麼明顯了。
• 當代理把票券「完全做錯」（文章中曾提到）時，這項教訓如何回饋至系統？Symphony 的答案是「加入防護欄和技能」——實務上，這件事的制度流程是什麼？
• 票券驅動的編排如何與以票券集合為運作對象的 sprint 規劃／OKR／路線圖工作互動？當票券切得這麼小時，這個抽象是否會崩潰？

資料來源#

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