OpenAI 於 2026 年 2 月 26 日開源 Symphony，專案在 GitHub 累積 27,772 顆星標，主要語言為 Elixir，採 Apache 2.0 授權。它的定位不是另一個編碼代理，而是一層排程服務：持續讀取工單系統的待辦工作，為每張工單建立隔離工作區，再啟動 Codex 會話直到完成。
OpenAI Symphony 是什麼？
Symphony 是 OpenAI 開源的代理排程服務，持續讀取工單系統的待辦項目，為每張工單建立獨立工作區並啟動 Codex 執行。專案採 Apache 2.0 授權。
專案的核心概念是把手動執行轉為常駐流程。傳統做法由工程師逐項指派任務給編碼代理，並在旁邊確認輸出；Symphony 則把排程、併發控制、重試與狀態回收集中到一個常駐服務，工程師改為在較高層次管理待辦清單。
值得注意的是專案的分發形態。儲存庫根目錄的 SPEC.md 長達 2,312 行，以語言無關的方式定義服務契約；實際可執行的 Elixir 實作只是其中一個參考版本。README 明確建議團隊依規格自行實作硬化版本，這種「規格優先、實作其次」的釋出方式，在大型機構的開源專案中並不常見。
官方同時標註此專案屬於低調的工程預覽，僅建議在受信任環境中測試。這句提示決定了後續所有評估的基準線：它是一份可遵循的設計藍圖，而不是可以直接搬上生產線的成品。
Symphony 為何要解決代理監督問題？
代理執行成本低，監督成本高。Symphony 把重複的派工、隔離、重試與狀態追蹤自動化，讓團隊管理待辦工作，而不是逐次監督代理的每一個動作。
專案在規格書中列出四項營運問題。第一是把工單執行從手動腳本轉為可重複的常駐流程；第二是把代理指令限制在每張工單專屬的工作區目錄內；第三是把流程策略寫進儲存庫的 WORKFLOW.md，讓提示與執行設定跟程式碼一起版控；第四是提供足夠的可觀測性，讓多個併發執行可以同時被操作與除錯。
這四項問題對應到實務上的具體痛點。當代理數量從一個增加到十個，人工切換工作區、確認分支、追蹤哪個任務卡住，很快就會吃掉工程師大部分時間。規格書把這類工作定義為協調層職責，並要求由單一權威元件序列化所有狀態變更，避免重複派工。
專案亦明確劃出非目標：不提供豐富的網頁介面、不做多租戶控制平面、不是通用工作流程引擎或分散式任務排程器、不內建工單編輯的業務邏輯。這種削減範圍的做法，讓規格可以在數千行內保持可實作。
Symphony 的架構由哪些元件組成？
架構分為八個元件：工作流程載入器、設定層、工單轉接器、編排器、工作區管理器、代理執行器、狀態介面與日誌。編排器是唯一能變更排程狀態的元件。
工作流程載入器負責讀取 WORKFLOW.md，解析 YAML front matter 與提示本文，回傳設定與提示模板兩部分。設定層把原始設定轉為具型別的取值介面，處理預設值、環境變數間接引用與路徑正規化，並在派工前完成驗證。
工單轉接器把不同平台的資料正規化為統一的工作項模型，包含編號、標題、描述、優先級、狀態、標籤與阻塞關係。規格把工作項編號定義為不透明字串，避免核心邏輯依賴特定平台的欄位語意，這個設計讓同一套編排邏輯可以跨平台運作。
編排器持有輪詢節奏與記憶體內的執行狀態，決定哪些工作要派工、重試、停止或釋放。工作區管理器把工作項編號映射為目錄路徑，處理目錄建立、生命週期掛鉤與終止狀態的清理。代理執行器負責建立工作區、組裝提示、啟動代理的子程序通訊，並把更新串流回編排器。
規格另把抽象層次切成政策層、設定層、協調層、執行層、整合層與可觀測性層，並指出這種分層是為了讓實作容易移植到其他語言。對於考慮以 TypeScript 或 Go 重寫的團隊，這份分層說明等同於一份實作路線圖。
WORKFLOW.md 如何定義團隊流程？
WORKFLOW.md 以 YAML front matter 描述工單來源、輪詢間隔、工作區路徑與掛鉤，Markdown 本文則是每張工單的提示模板，與程式碼一同版控。
設定分為五個區塊。tracker 指定工單來源種類與必要標籤、活動狀態與終止狀態；polling 控制輪詢間隔，預設 30,000 毫秒；workspace 指定工作區根目錄，預設落在系統暫存目錄；hooks 定義工作區建立、執行前、執行後與移除前的四段 shell 腳本；agent 與 codex 則控制併發數量、輪次上限與代理執行參數。
提示模板使用嚴格的模板語意，只允許已定義的變數與過濾器，遇到未知變數會直接讓渲染失敗，而不是默默輸出空白。規格對這點的堅持有其道理：一份安靜失敗的提示，會讓代理在錯誤資訊下持續執行，事後極難追查。
載入器對錯誤的分級同樣值得注意。檔案缺失、YAML 解析失敗或 front matter 不是映射結構，都會阻擋新的派工直到修正；模板錯誤則只讓該次執行失敗。這種分級讓設定錯誤不會一次拖垮整個服務，同時保留明確的修復訊號。
Symphony 的排程與重試機制怎樣運作？
每次輪詢先核對執行中的工作，再驗證設定、抓取候選工單、依優先級派工。失敗重試採指數退避，上限預設五分鐘；正常結束後另排一秒延續重試以複查狀態。
派工條件相當嚴格。工作項必須具備編號、識別碼、標題與狀態，狀態需落在活動清單且不在終止清單，必須含有全部必要標籤，且未被執行中或已聲明，同時仍有全域與分狀態的併發空位。排序依優先級一至四優先、其後依建立時間由舊到新，最後以識別碼作穩定排序。
併發控制分兩層。全域上限由 agent.max_concurrent_agents 決定，預設十個；分狀態上限由 agent.max_concurrent_agents_by_state 指定，未設定時回退至全域值。這種設計讓團隊可以限制同時修改同一狀態的代理數量，例如只允許兩個代理同時處理待驗證項目。
重試策略區分兩種情況。代理正常結束後，服務安排約一秒的延續重試，用來複查工單是否仍為活動狀態，若仍是活動狀態便在同一執行緒上開始新一輪，最多二十輪。異常結束則採指數退避，延遲為十秒乘以二的嘗試次數次方，並以五分鐘為上限。
停滯偵測是另一道保險。若某個執行中的工作超過五分鐘沒有收到代理事件，服務會終止該工作並排入重試。這項機制針對的是代理卡在無回應的工具呼叫或等待輸入的情境，規格要求將這類狀態明確標記為受阻，而不是讓它無聲佔用併發名額。
Symphony 如何處理多平台工單整合？
內建轉接器涵蓋 Linear、GitHub Issues、Jira Cloud、Asana 與 GitLab。代理透過平台原生工具回寫工單，不需額外登入或持有憑證。
轉接器的職責包括抓取候選工作、刷新特定工作狀態、在啟動時清理終止狀態，以及把平台資料正規化為統一模型。規格另外允許轉接器向代理提供平台原生工具，例如 Linear 提供 GraphQL 介面、GitHub Issues 提供 API 介面、Jira Cloud 提供 REST 介面。
這個設計解決了憑證散落的問題。轉接器由服務端以主機側的授權執行工具呼叫，並在啟動代理子程序前移除已宣告的工單憑證環境變數，因此代理本身不需要第二次登入，也無法直接讀取權杖。規格在邊界說明中特別強調這點，因為把權杖寫進儲存庫的工作流程檔，正是最常見的洩漏途徑。
工作區命名亦有防碰撞設計。目錄名由工作項識別碼推導，非英數字元一律替換為底線；若替換後與原識別碼不同，需附加原識別碼的雜湊後綴，確保兩個不同識別碼不會因為正規化而指向同一個目錄。這類細節在單人使用時無感，在多團隊共用工作區根目錄時卻直接影響資料隔離。
Symphony 有哪些可觀測性與部署介面？
服務提供終端狀態輸出、可選的 Phoenix 儀表板與 JSON API。/api/v1/state 回傳執行中會話、重試佇列、累計詞元與運行秒數，便於外部監控接入。
儀表板掛載於根路徑，顯示活動會話、重試延遲、詞元消耗、累計運行時間與近期事件。JSON 介面則提供狀態摘要與單一工作項的除錯細節，回應包含會話編號、輪次計數、最近事件、起訖時間與詞元分解。
詞元統計的規則寫得相當具體。代理事件可能以多種負載形態回報用量，規格要求優先採用執行緒的絕對總量，忽略增量型負載，並在絕對總量更新時以差值累計，避免重複計算。對於需要對代理成本做內部計價的團隊，這段規則直接決定了帳務數字的可信度。
部署形態有三種。第一種是依規格自行實作；第二種是使用 Elixir 參考實作，透過版本管理工具安裝 Erlang 與 Elixir 後啟動；第三種是下載打包好的自帶執行檔，涵蓋 macOS 與 Linux 的兩種架構，但仍需在目標機器上具備代理執行檔、Git 與工單憑證。專案目前有九位貢獻者，版本停在 0.0.3，並持續產出每日建置的快照版本。
Symphony 的主要數據有哪些？
儲存庫累積 27,772 顆星標與 2,883 個分支，採 Apache 2.0 授權，主要語言為 Elixir。專案建立於 2026 年 2 月，最新版本為 0.0.3。
星標與分支的比例值得留意。分支數接近星標數的一成，在僅有九位貢獻者的專案中屬於偏高水位，通常反映外部團隊正在複製規格進行實驗，而非單純的關注收藏。這種使用形態與一般工具型專案不同：多數分支不會合併回主線，而是各自演化為內部版本。
版本節奏亦反映專案的預覽定位。從 7 月的 0.0.1 到 9 月的 0.0.3，兩個月內三次發布，之後進入每日快照節奏，主線提交在 9 月中旬後明顯放緩。對評估者而言，這代表專案的價值主要集中在規格本身，而非參考實作的成熟度。
如何開始使用 Symphony？
先確認專案已具備良好代理協作條件，再取得工單平台的個人存取權杖，複製 WORKFLOW.md 並依專案調整欄位，最後安裝 Erlang 與 Elixir 環境啟動服務。
啟動流程的第一步不在工具本身。官方建議先讓程式庫具備適合代理作業的結構，也就是清楚的建置指令、可重現的測試與明確的目錄邊界，否則代理在缺乏回饋訊號的環境中只會反覆嘗試。
第二步是憑證與流程檔。以 Linear 為例，需在帳號設定中建立個人 API 權杖並設為環境變數，再把參考實作中的 WORKFLOW.md 複製到目標儲存庫，調整專案代號與狀態名稱。參考流程依賴三個非標準狀態，分別代表待重做、待人審與合併中，這些狀態需要在平台的團隊設定中先行建立。
第三步是執行環境。使用版本管理工具安裝對應的 Erlang 與 Elixir 版本後，執行初始化與建置指令，再以工作流程檔作為參數啟動服務。若只需要觀察行為，可以加上連接埠參數啟動儀表板，先以小規模工單驗證派工、重試與清理三條路徑，再逐步放寬併發上限。
Symphony 的安全邊界如何設計？
工單憑證留在主機側，代理子程序不繼承；工作區限制在每張工單的目錄內，代理預設採工作區寫入權限，並在需要核准時標記為受阻而非靜默等待。
規格對信任姿態採取明確但不強制的立場。文件要求實作必須說明自身的信任與安全設定，但不規定單一的核准、沙箱或人工確認政策，理由是部分實作面向高信任的內部環境，部分則需要更嚴格的核准流程。
參考實作選了較保守的預設值。代理的核准政策預設拒絕沙箱升級、規則變更與工具誘導請求，執行緒沙箱設為工作區寫入，單輪沙箱政策以當前工單工作區為根目錄。若工作流程需要執行套件管理或解析外部主機，必須在沙箱政策中明確開啟網路存取，否則域名解析會被拒絕。
受阻狀態的處理方式同樣值得記錄。當代理回報需要人工輸入、核准或工具誘導時，服務會保留該工單的聲明並在儀表板與介面中標示為受阻，而不是放行或丟棄。這類狀態僅存在於記憶體，重啟後會清空，仍處活動狀態的工單將重新成為派工候選，因此重啟期間可能出現重複提交，維運上需要預留對應的檢查流程。
出處連結有哪些？
本文數據取自 openai/symphony 官方儲存庫、SPEC.md 規格書、Elixir 參考實作說明與版本頁，資料讀取時間為 2026 年 10 月 22 日。
官方儲存庫：https://github.com/openai/symphony
服務規格刊載於儲存庫根目錄的 SPEC.md，全文 2,312 行，涵蓋領域模型、工作流程契約、設定規格、編排狀態機、輪詢與協調、工作區管理、代理通訊協定、工單整合契約與可觀測性。參考實作說明位於 elixir/README.md，另有官方部落格文章說明開源背景與設計取向。
總結：Symphony 適合什麼團隊？
已在多專案間管理多個編碼代理、且具備工單系統與容器化隔離能力的團隊最適合評估。單人或缺乏審核流程的團隊，建議先以規格理解概念再考慮導入。
Symphony 的真正產出是一份可執行的設計文件。它把代理排程中被視為常識卻很少被寫下來的細節，例如工作區命名防碰撞、憑證不得進入子程序、停滯偵測的判定基準、重試與延續的差別，全部寫成可驗證的條款。對正在自建代理流程的團隊，這份規格能省下大量試錯。
限制亦同樣清楚。專案僅有九位貢獻者與三個修補版本，參考實作以 Elixir 撰寫，對多數以 Python 或 TypeScript 為主的團隊意味著額外的維運成本；官方明言只建議在受信任環境測試，並不提供多租戶隔離或完整的權限模型。
評估的判斷標準可以收斂為兩點。若團隊已在多個專案間調度多個代理，並具備工單系統與可重現的建置流程，這份規格提供了直接可用的骨架。若目前仍處於單人試用階段，先理解其中關於工作區隔離與憑證邊界的設計思路，會比直接部署參考實作更有價值。
