Symphony

資料來源#

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

摘要#

Symphony 是由 OpenAI 的 Codex 團隊（Alex Kotliarskyi、Victor Zhu、Zach Brock——也是撰寫代理程式運行框架工程文章的團隊）推出的開源代理協調規格。它將議題追蹤器（v1 使用 Linear）轉變為編碼代理的控制平面：每張未結案的工單都有專屬工作區，以及持續執行的 Codex App Server 工作階段。「產品」主要是一個位於 openai/symphony 儲存庫中的 SPEC.md 檔案——OpenAI 明確表示不打算將 Symphony 維護為獨立工具，而是希望它成為參考實作，讓使用者指示自己的編碼代理採用。

細節#

起源故事#

Symphony 在 2026 年 3 月公開宣布前六個月便已建立，其所處理的瓶頸不同於代理程式運行框架工程所處理的問題。當 OpenAI 生產力工具團隊擁有一個可供代理使用的儲存庫（沒有人工撰寫的程式碼、約 100 萬行程式碼、約 1,500 個 PR）後，新的瓶頸變成了人的注意力——在生產力因上下文切換崩潰前，一名工程師可以輕鬆管理 3–5 個並行的 Codex 工作階段。

演進路徑：

1. v1 — 在 tmux 中執行 Codex 工作階段，輪詢 Linear，並為新任務啟動子代理。能運作，但不可靠。
2. v2 — 存在於他們的主要專案儲存庫內，利用既有的運行框架。
3. v3 —「使用 Symphony 建造 Symphony。」核心功能完成後，系統開始自我啟動開發流程。
4. 對外發布 — 擷取成獨立的 SPEC.md。OpenAI 要求 Codex 以 Elixir 實作規格，接著再以 TypeScript、Go、Rust、Java 和 Python 實作——利用各實作之間的差異作為規格模糊測試訊號，以消除歧義。（這為何重要，請參閱 LLM-as-Compiler Knowledge Base。）

參考實作採用Elixir，因為它具備並行與監督原語。正如文章所述：「當程式碼幾乎免費時，你終於可以根據語言的優勢來選擇語言。」

它實際上做什麼#

Symphony 是一個長時間執行的 daemon，會：

1. 每隔 30 秒（預設值）輪詢 Linear，尋找處於作用中狀態（Todo、In Progress）的議題。
2. 為每個符合資格的議題，在 <workspace.root>/<sanitized_identifier> 建立具決定性的議題專屬工作區。
3. 在該工作區中啟動 Codex App Server 工作階段，從 WORKFLOW.md 根據團隊提示詞範本產生提示詞。
4. 每次 tick 都重新協調狀態——終止票券已轉為終止狀態的工作階段，並以指數退避重試崩潰或卡住的工作階段。
5. 不會自行寫入追蹤器。 狀態轉換、留言與 PR 連結皆由編碼代理使用自己的工具執行。Symphony 是「排程器／執行器與追蹤器讀取器」。

SPEC.md 就是產品#

開啟儲存庫時，第一個看到的是 SPEC.md——不是原始碼。規格定義了：

• 工作流程契約：WORKFLOW.md 是一個帶有 YAML front matter 的 markdown 檔案，版本控制於使用者的儲存庫中，用於解析執行階段設定（tracker、polling、workspace、hooks、agent、codex）以及相容於 Liquid 的提示詞範本本文。
• 狀態機：5 個協調狀態（Unclaimed、Claimed、Running、RetryQueued、Released）與 11 個執行嘗試階段。追蹤器狀態與協調器狀態彼此分離。
• 並行控制：全域上限（max_concurrent_agents，預設 10）、每個狀態的上限，以及可選的每個 SSH 主機上限。
• 工作區安全不變量：代理只能在議題專屬工作區中執行；工作區路徑必須維持在工作區根目錄內；識別碼會被清理為 [A-Za-z0-9._-]。
• 沒有持久化的協調器資料庫：重啟復原由追蹤器與檔案系統驅動。啟動時清理過時的終止工作區。
• 刻意保留跨執行的工作區。這與典型 CI 的短暫性相反——能享有暖快取效益，也承擔狀態污染風險。

這是一種刻意的反轉：OpenAI 沒有建立複雜的監督系統，而是定義問題，讓編碼代理實作它。

Linear 作為控制平面的洞見#

Symphony 強迫人們面對的更深層轉變，收錄於票券驅動的代理協調：票券成為工作單位，而不是工作階段或 PR。在 OpenAI 的部分團隊中，落地 PR 在前三週增加了 500%（這項說法有所保留——僅稱「部分團隊」，且未定義基準）。Linear 創辦人 Karri Saarinen 另行回報，工作區建立量的激增與 Symphony 的發布相關。

OpenAI 之外的證據：截至 2026 年 4 月 23 日，GitHub 星數超過 15,000，發布約 6 週內達成。

###「目標，而非轉換」——重新學到的教訓

OpenAI 的 Symphony 初版將代理視為狀態機中的剛性節點——只要求 Codex 實作任務。他們發現這過於受限：

「模型變得更聰明，能解決比我們試圖把它們塞進去的框框更大的問題。」

轉變是：給 Codex 工具（gh CLI、讀取 CI 日誌的技能等）與目標，而不是狀態轉換。這將「強制執行不變量，而非實作」原則重新表述為協調問題——相同理念，不同層次。

Codex App Server 與權杖隔離的工具注入#

Symphony 使用 Codex 的無頭模式（App Server），而不是驅動 CLI。完整協定記錄於 Codex App Server Protocol。值得注意的是動態工具呼叫的使用方式（實驗性功能）：Symphony 不直接將 Linear 存取權杖提供給子代理，而是公開 linear_graphql 工具，使用協調器的驗證資訊代理已驗證的請求——權杖永遠不會抵達子代理容器。

在精神上，這與 MCP 平行，但專門針對編碼代理執行階段。

Symphony 不會解決什麼#

文章指出了以下誠實的取捨：

• 失去執行中的引導：工作以票券層級分配後，你無法再於執行期間推動代理。失敗會揭示運行框架／技能的缺口，之後再於全系統修補。
• 並非所有任務都適用：需要強烈人類判斷的模糊問題，仍需要互動式 Codex 工作階段。Symphony 處理大量例行實作。
• 狀態機僵化（早期教訓，已修正）：請參閱上方的「目標，而非轉換」。

與其他事物的關係#

• Symphony 與 Claude Code agents：平行的生態系統。Symphony 以 daemon 為核心（永遠在線、持續輪詢）；Claude Code 以工作階段為核心，並可選擇非互動模式（claude -p）。兩者都依賴儲存庫版本控制的 markdown 來設定行為（請參閱 Claude Code Best Practices 的 CLAUDE.md，以及 Hermes Agent 的 AGENTS.md／SOUL.md）。
• Symphony 與 Hermes Gateway：兩者都是以 systemd／launchd 服務執行的多租戶 daemon。Symphony 的租戶單位是議題；Hermes 的租戶單位是使用者（請參閱 Hermes Agent）。兩者都隔離每個租戶，並偏好使用 Docker 以確保安全。

相關連結#

• 票券驅動的代理協調 — Symphony 編纂的核心抽象；可延伸至 Linear／Codex 之外
• Codex App Server Protocol — Symphony 所依賴的執行階段協定；詳細涵蓋 JSON-RPC stdio 交握、延續回合與動態工具呼叫
• 代理程式運行框架工程 — Symphony 是同一 OpenAI 團隊早期工作的自然「作為服務的運行框架」演進；「目標而非轉換」與「強制執行不變量，而非實作」是同一理念
• LLM-as-Compiler Knowledge Base —「以 6 種語言編譯規格，利用差異找出歧義」的技術，是目前 LLM-as-compiler 最具體的延伸；它將跨實作漂移作為規格模糊測試工具
• Claude Code Best Practices — Symphony 的 WORKFLOW.md 與 CLAUDE.md 是相同模式：版本控制於儲存庫的純文字作為代理控制平面，但前者位於協調層而非工作階段層
• Hermes Agent — 平行的「永遠在線代理 daemon」架構，採用按使用者而非按議題隔離
• Client-Side Agent Optimization — Symphony 的每狀態並行上限與延續回合預算，是 AgentOpt 所形式化的預算槓桿之作業實例
• Claude's Constitution / Model Spec — 不同層次的相同「規格即文件」模式：Symphony 的 SPEC.md 位於產品層；Model Spec / Constitution 位於對齊層，但兩者都將純文字規格視為承重構件
• Model Spec Midtraining (MSM) — 將規格作為槓桿的概念進一步延伸：對齊規格現在是直接的訓練輸入，而不只是執行階段指引文件
• Model Spec Science — 規格模糊測試技術（以 6 種語言編譯規格，利用差異揭示歧義）是實證研究 Model Spec 的方法論近親
• Agent Loop Pattern — 協調層的 daemon 驅動等價物；Symphony 是在票券追蹤器上提供的迴圈即服務
• Agentic Misalignment (AM) — 部署中的代理產品正是 AM 威脅模型所適用的表面（自主、使用工具、對每次行動的監督薄弱）
• OpenAI — 建造並開源 Symphony 的實驗室，其 Codex 團隊

開放問題#

• 500% 落地 PR 的說法有所保留——沒有基準定義，且僅限於「部分團隊」。各團隊的分布情況如何？在這種吞吐量下，PR 的品質與還原率會發生什麼變化？
• 「跨執行保留工作區」與典型 CI 的短暫性相反。從先前執行留下的狀態污染（過時的 node_modules、遺留分支、建置產物）開始造成的傷害，何時會超過暖快取帶來的益處？
• Symphony 不寫入追蹤器——代理會寫。這表示追蹤器政策是 WORKFLOW.md 中的提示詞。實務上當 Linear 改變 API 時，這有多脆弱？當代理擁有提示詞層級的裁量權時，如何強制一致的狀態機行為？
• 規格透過以 6 種語言實作而簡化。這項技術的延伸是什麼？這個 vault 中的 compiler-prompt.md 是否也能以類似方式進行跨實作模糊測試？
• Symphony 明確表示代理可以自行建立票券。什麼治理機制能防止票券圖無限制擴張？由人類對代理建立的票券進行分流，是否是唯一的檢查機制？

資料來源#

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