--- schemaVersion: 1 slug: gp-187-20260428-openai-symphony-codex-orchestration ticketId: GP-187 lang: zh-tw title: OpenAI 開源 Symphony 編排規格——當 Codex 工作流的瓶頸從寫程式變成「切換上下文」 summary: OpenAI 工程團隊開源 Symphony——把 Linear 任務板變成 Codex agent 的中央控制台，每張開放任務自動配 agent。部分團隊頭三週 PR 落地量增加 500%，但更大的觀察是：當寫程式被 Codex 拉快，下一個瓶頸是「人類的注意力」。 originalDate: 2026-04-27 translatedDate: 2026-04-28 source: OpenAI Engineering blog sourceUrl: https://openai.com/index/open-source-codex-orchestration-symphony/ author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-187-20260428-openai-symphony-codex-orchestration status: published replacementTicketId: null replacementUrl: null --- # OpenAI 開源 Symphony 編排規格——當 Codex 工作流的瓶頸從寫程式變成「切換上下文」 > **來源:** [OpenAI Engineering blog](https://openai.com/index/open-source-codex-orchestration-symphony/) 一位工程師人在小木屋，無線網路爛到「晚點再推」都很合理，卻還能只靠手機上的 [Linear](https://gu-log.vercel.app/glossary#linear) 推進三個有份量的修改。 這句話真正怪的地方不是「手機也能工作」，而是任務板開始像程式碼庫的遙控器。按下去的不是滑鼠游標，而是一張任務卡；被啟動的不是人類記憶，而是一個 Codex 工作區。 先把重複劇情扣掉：[MP-179](https://gu-log.vercel.app/posts/mp-179-20260316-daniel-mac8-symphony-manage-work-not-agents/) 已經介紹過 Symphony 的社群版骨架——Linear 任務單接到 Codex 工作區，重點是管理「工作」而不是管理 agent。官方版新增的價值，是把這個「任務板遙控 codebase」的模式寫成規格、參考實作和失敗回饋流程。 Linear 在這篇可以先想成任務板；PR 是一包準備審查與合併的修改；Codex App Server 暫時想成「外部工具叫 Codex 接工作的門」。名詞很多，但真正要看的只有一件事：任務板怎麼從待辦清單變成操作介面。 > **Mogu 偷偷說：** > > [Mogu](https://gu-log.vercel.app/glossary#mogu) 會先記小木屋那張圖，不會先記 500% 那個數字 (◕‿◕) > > 數字容易變簡報煙火；畫面比較殘酷。它暗示工程入口正在鬆動：不是每件事都要從 IDE 開始，前提是工作要先被整理成代理程式接得住、工程師看得懂、系統追得上的形狀。 --- ## 任務板以前只是地圖，現在開始像遙控器 任務板原本只是地圖：哪張卡還沒做、哪張卡進行中、哪張卡等 review。真正的工作通常藏在人的 IDE、終端機、聊天視窗和短期記憶裡。 Symphony 想改掉這件事。任務卡沒有被封鎖，就能開出對應的 Codex 工作區；代理程式如果掛掉，可以重啟；做完的修改、測試輸出、影片證據，回到卡片旁邊，變成一包可審查的結果。 所以小木屋那位工程師不是用手機寫程式碼。手機上看到的是這張卡目前狀態：Codex 是否接到、結果是否回來、證據夠不夠、下一步能不能放行。手機不是縮小版 IDE，而是任務狀態的遙控器。 OpenAI 內部某個生產力工具團隊先做過一個激進實驗：專案程式碼庫不收人類手寫程式碼，全部交給 [Codex](https://gu-log.vercel.app/glossary#codex) 生成。真正爆掉的不是 Codex 寫不出來，而是工程師同時顧三到五個 Codex 對話後，開始忘記哪個在跑、哪個卡住、哪個需要接手。 遙控器的價值就在這裡：它不是讓人類按更多按鈕，而是讓工作狀態不要塞在人腦裡。 --- ## 遙控器按下去，回來的是審查材料 想像任務板上有一張卡：修一個介面問題。條件寫得很死：不能破壞既有測試；完成時要附測試結果；如果畫面有變，還要有產品裡跑起來的影片。 以前這張卡會先落到工程師腦袋裡。工程師開 IDE、開 Codex 對話、貼需求、等它跑、切回終端機看測試、再回任務板更新狀態。 在 Symphony 的版本裡，這張卡本身就是入口。需求如果寫清楚，結果可能不只是「Codex 改好了」一句話，而是一包審查材料：修改內容、測試紀錄、可驗證的畫面，甚至是功能在真實產品裡跑起來的影片。 這也解釋為什麼產品經理和設計師會出現在故事裡。他們不需要抓程式碼庫，也不用顧 Codex 對話；需求寫清楚，就可能先拿回可看的版本。工程師仍然負責方向、風險、可維護性、測試、衝突處理，以及最後是否合併。 部分團隊在導入後前三週，已合併 PR 增加 500%。這個數字要連同邊界一起讀：部分團隊、前三週、已合併 PR。它是早期案例自述，不是全公司長期產能永久翻五倍。 --- ## SPEC.md 是遙控器的接線圖 第一版 Symphony 很粗：一個 Codex 對話定期去看 Linear，有新任務就開工。能動，但不穩。後來它搬進 OpenAI 那個「不接受人類手寫程式碼」的程式碼庫，靠既有測試與工具穩下來，最後變成用 Symphony 開發 Symphony。 開源版沒有把內部完整系統整包丟出來，而是先給 SPEC.md 和參考實作。這比較像接線圖：任務怎麼進來、Codex 怎麼接、結果怎麼回去，寫到外部團隊能照著重做。 接著是規格檢查：讓 Codex 根據同一份規格，用不同技術棧各做一次。目的不是養一排版本，而是逼規格露出缺口。某段描述在一種環境能跑，換一種環境就歪掉，問題可能不是技術棧麻煩，而是 SPEC.md 少寫了一個工程師平常會默默補上的動作。 > **Mogu 吐槽時間：** > > 這段比 500% 更值得偷學。規格文件平常很容易變漂亮作文：大家點頭、PR 合併，三個月後才發現每個人腦中的版本都不一樣。 > > 叫代理程式照同一份規格用不同方式做幾次，就是便宜版壓力測試。文件如果真的清楚，會活下來；如果只是看起來清楚，第一輪實作就會開始冒煙。 --- ## 遙控器最重要的是撞牆後會記住 那張介面卡第一次不一定會成功。Codex 可能改到錯的地方，可能測試漏跑，可能影片沒附，可能把一個看似簡單的畫面問題牽進更大的架構判斷。 最省事的做法是工程師手修。這能救一個 PR，但救不了下一張卡。Symphony 的工程習慣，是把失敗當成系統材料：失敗模式可以變成測試、檢查、操作指令、工作說明。代理程式撞牆的位置，下一輪就該多一支護欄。 這也解釋為什麼 Symphony 不打算被包成獨立產品長期維護。它會刻意保持小，重點不是賣一套萬用任務板，而是示範 Codex App Server 這扇門可以怎麼接外部工作系統。Linear 只是這次被接上的那一端；真正被展示的是模式。 如果任務板真的變成 codebase 遙控器，最大的風險不是按鈕太少，而是按鈕太容易按。所以邊界比入口重要：模糊、需要高判斷力、驗收條件還沒長出來的問題，仍然適合工程師直接跟 Codex 互動。 Symphony 適合的是另一類工作：目標能寫清楚，檢查能自動跑，結果能被審查，失敗能回饋成下一輪規則。任務描述如果太模糊，系統就無法可靠分派；任務描述足夠明確，後面的生成、驗證和審查才有路徑可走。 回到小木屋那支手機。真正厲害的不是手機可以遠端控制 Codex，而是那張任務卡已經被整理到足夠清楚：工程師不用坐在 IDE 前，系統也知道下一步該往哪裡走。 這才是 Symphony 官方版補上的工程問題：寫程式變快以後，工作要怎麼被交出去、驗回來，並把失敗轉成下一輪可重用的檢查。