Symphony：OpenAI 把 issue tracker 變成 Codex agent 的控制台

工程師用 Codex 的最大瓶頸不是 Codex 不夠強，而是人只有一雙眼睛。

OpenAI 自己說，工程師同時管理 Codex session 的上限大概是 3 到 5 個，超過這個數字，context switching 就開始拖慢生產力。他們做了 Symphony 來解這個問題。

什麼是 Symphony

Symphony 是一個開源的編排規格（spec），把 issue tracker（現在的 reference implementation 用 Linear）變成 Codex agent 的控制平面。概念很直接：每一個 open issue 對應一個 agent，agents 持續運行，工程師的工作從「操控 Codex session」變成「審查 agent 的產出」。

架構上，Symphony 由幾個部分組成：

Tracker Poller：持續輪詢 issue tracker，抓取新工作
Workspace Manager：為每個 issue 建立獨立的 workspace，映射到 repo 路徑
Agent Runner：建立 workspace、從 issue + workflow template 組出 prompt、啟動 coding agent、串流更新回 orchestrator
Status Surface（選用）：給操作者看的即時狀態介面

ticket 的狀態（Unclaimed / Claimed / Running / RetryQueued / Released）驅動整個系統的行為，相當於一個狀態機。agent 崩潰或卡住，Symphony 自動重啟。

真實效果

OpenAI 內部使用 Symphony 後，部分團隊的 PR 合併量在前三週增加了 500%（根據 OpenAI 官方 blog 和 SiliconReport 引用，來源是 OpenAI 自述，非獨立第三方驗證）。

更重要的是他們描述的方式變了：工程師不再「驅動實作」，而是「管理工作」。一個 issue 可以產生多個 PR，跨多個 repo；另一些 issue 產生的只是調查報告，從來不碰 codebase。Symphony 讓這兩種工作都能在同一套系統裡運行。

具體例子：React 升級被標記為「blocked on Vite migration」，agents 自動等 Vite migration 完成才開始動 React——不需要人工監控依賴關係。

技術選擇

Reference implementation 用 Elixir 寫，理由是 Elixir 的並發模型適合管理大量同時執行的 agent 進程。但 OpenAI 明確表示，Symphony 是一份規格而不是一個產品——Codex 本身成功把規格移植成 TypeScript、Python、Rust 版本。

開源到 GitHub 後，截至 2026-04-28 已累積超過 15,000 GitHub stars（根據 MEXC News 引用 OpenAI 發布資訊，截止 2026-04-23 的數字）。

值得注意的限制

OpenAI 自己在 blog 裡承認了幾個邊界：

不是所有任務都適合 orchestra 模式。需要強判斷力的模糊問題、需要大量脈絡的設計決策，還是用互動式 Codex session 更好。
安全信任模型需要自己定義。Symphony 規格裡沒有強制規定 sandboxing 或審批機制，各個 implementation 要自己明確宣告 trust posture。
更多 agent 自主性 = 更大的代碼審查壓力。PR 量增加 5 倍，代表 review 的工作也增加了——這個成本可能轉嫁到資深工程師身上。

Symphony 在 2026 年 4 月 27 日正式發布，定位是 reference implementation 而非 OpenAI 維護的長期產品。有興趣的團隊可以 fork 並依照自己的 workflow 客製化，或直接把 repo 丟給 Codex 讓它生成一份符合自家環境的版本。

這個模式的關鍵轉變是：AI coding tool 從「加速單一工程師的工作」變成「讓一個工程師能管理 N 個工作流」。Symphony 是 OpenAI 給這個轉變的一個具體實作答案，但能不能複製到你的團隊，取決於你的 codebase 有多少能被 ticket-driven agent 安全處理的工作。