OpenAI 開源 Symphony：把任務看板變智慧體控制台，PR 提升 500%

Symphony 是 OpenAI 開源的一套程式設計智慧體編排規範，核心目標是把 Linear 這類任務管理看板變成 Codex 程式設計智慧體的控制台。只要在看板上建一個任務，系統就會自動派出一個常駐智慧體負責到底，人類工程師只需要在最後稽核程式碼和結果。

它能解決什麼問題

在此之前，工程師用程式碼智慧體往往要開好幾個終端或網頁會話。每個人盯三到五個視窗就到了極限，注意力全耗在切換上下文、排查卡住的任務上，人反而成了智慧體的保姆。

Symphony 把互動模式轉成了工單驅動。在 OpenAI 內部，部分團隊換用 Symphony 後的三週內，合併入庫的 PR 數量激增了 500%，Linear 創始人 Karri Saarinen 也提到相關工作區建立量出現了暴增。

這套機制把發起工作的門檻降到了極低。產品經理和設計師可以直接在 Linear 上提需求，不用拉程式碼倉庫，智慧體做完後會直接返回包含實際執行錄屏的稽核包。工程師甚至能在度假木屋裡靠著微弱的網路訊號，直接用手機上的 Linear 推進重要改動。

怎麼做到的

Symphony 在 GitHub 倉庫裡本質上只是一份 SPEC.md 規範檔案，用來定義問題和解決思路。官方提供了一套 Elixir 語言編寫的參考實現，利用 Elixir 原生的併發與程序監督能力來管理常駐智慧體。測試期間，團隊還讓 Codex 用 TypeScript、Go、Rust、Java 和 Python 分別實現過這套規範，全部一次成功。

它的運作邏輯就像一個狀態機：Symphony 持續監聽看板，為每個未受阻斷的任務分配獨立的智慧體工作區。遇到複雜功能，智慧體能自動把任務拆解成帶有前後依賴關係的有向無環圖，按順序推進。如果在寫程式碼或自測時發現了新問題，智慧體還會主動建一張新工單排期。

針對大型程式碼倉庫合併困難的問題，系統會全程盯住 CI 流水線，自己處理程式碼變基、衝突解決以及偶發性測試失敗，直到分支順利合併。

去哪裡試以及有什麼門檻

完整的 SPEC.md 和 Elixir 參考實現已經放到了 GitHub 的 Symphony 倉庫。你可以直接閱讀這份規範，或者把它餵給你熟悉的程式設計模型，讓模型用你順手的語言寫一套適配自己團隊的排程工具。

不過要注意，Symphony 極度依賴程式碼倉庫本身的防禦機制。如果沒有完善的自動化測試、端到端檢查以及清晰的程式碼風格約束，放任智慧體後臺自閉環很容易產生大量偏離預期的廢程式碼。高度模糊、需要複雜架構權衡的工作，目前依然需要工程師回到互動式終端前手動處理。

為什麼重要

對於軟體工程團隊來說，Symphony 指明瞭一條從「人工盯梢 AI」轉向「流水線化管理 AI」的務實路徑。它適合需要日常處理海量常規工單、底層庫遷移或探索性重構的中大型研發團隊，值得技術主管深入研究。

我們認為，這套方案最聰明的地方在於做減法。OpenAI 沒有去造一套笨重的排程中介軟體，而是把成熟的工單看板直接當成狀態機，把核心邏輯濃縮成一份 Markdown 規範，甚至連規範程式碼都交給模型自己寫。它標誌著程式碼生成的競爭焦點，已經從單個模型寫幾行程式碼的速度，轉向了整個工程管線的自動化編排效率。