OpenAI 發表了 Symphony，這是一個開源規範及其參考實作，能將 Linear 等任務追蹤工具轉變為 Codex 代理人的指揮中心。開發者不再需要同時處理多個工作階段，而是由代理人自行領取待辦事項，人類只需負責審核成果。 根據 OpenAI 表示，部分內部團隊在 Symphony 發布後的三週內，合併的程式碼合併請求（pull requests）數量激增了六倍。Linear 創辦人 Karri Saarinen 也觀察到，其專案規劃工具中的新工作區數量在發布後顯著增加。 透過 Symphony，每個待辦事項都會分配到一個專屬的 Codex 代理人及獨立工作區，直到任務完成為止，這使得任務看板成為實際工作分派的中心。 ## 當人類注意力成為瓶頸 OpenAI 指出，在 Symphony 推出之前，開發者必須同時執行多個 Codex 工作階段，手動分配任務並追蹤每個任務的進度。實際上，若要同時運行超過三到五個工作階段，幾乎不可能不因頻繁的上下文切換而導致生產力大幅下降。 開發者寫道：「代理人速度很快，但我們面臨一個系統瓶頸：人類的注意力。」他們建立了一支由初級開發者組成的團隊，卻讓人類同事陷入了微觀管理的困境。這正是他們萌生顛覆工作流程想法的原因：不再由人類監督工作階段，而是讓代理人直接從追蹤器中領取自己的工作。 ## Linear 作為狀態機 Symphony 將 Linear 作為一個狀態機來使用。任務會依序經過「待辦 (Todo)」、「進行中 (In Progress)」、「審核 (Review)」和「合併中 (Merging)」等狀態。系統會監控看板，確保每個活躍的任務都有代理人負責。如果代理人崩潰或停滯，Symphony 會重新啟動它。 只有未被阻擋的任務會被領取，這使得任務樹能夠平行運行。團隊舉例說明，一個 React 升級專案只有在上游遷移到 Vite 後才會啟動。任務的範圍可能遠大於單一的程式碼變更。有些任務會跨多個儲存庫產生數個程式碼合併請求，而有些則純粹是研究或分析任務，完全不涉及程式碼。 如果代理人在執行過程中發現當前任務之外的問題，例如效能問題或重構機會，它們會自行提交新的任務。OpenAI 表示，產品經理和設計師也可以直接提交功能需求，並收到包含影片導覽的審核套件，而無需檢出儲存庫。 從建構 Symphony 中學到的一個教訓是：代理人很難被視為狀態機中的固定節點。模型持續進步，能夠處理比預設範本計畫更大的問題。團隊現在傾向於給予代理人目標，而非嚴格的流程，就像經理給員工一個要交付的成果，而不是一步一步的執行手冊。 團隊表示：「模型的強大之處在於它們的推理能力，所以給予它們工具和上下文，讓它們自由發揮。」 ## 核心是一個 Markdown 檔案 打開 Symphony 的儲存庫，你會主要看到一個 SPEC.md 檔案。這個 Markdown 檔案闡述了問題和期望的解決方案。OpenAI 並沒有建立一個複雜的監控系統，而是發布了一個規範，讓代理人可以自行實作。參考實作是用 Elixir 編寫的，這是一種具有強大並行處理工具的語言。OpenAI 表示 Codex 一次性就建構了這個實作。為了對規範進行壓力測試，Codex 團隊也讓它在 TypeScript、Go、Rust、Java 和 Python 中進行了實作。 開發工作流程——接受任務、檢出儲存庫、設定狀態、附加程式碼合併請求、附加影片——都寫在一個 WORKFLOW.md 檔案中，Symphony 會將其作為指南交給代理人。要更改流程，只需編輯該檔案，Symphony 就會引導代理人使用新版本。 ## 限制、分支與下一步 並非所有任務都適合 Symphony。OpenAI 表示，模糊不清的問題或需要判斷力的工作，仍然由開發者在互動式的 Codex 工作階段中直接處理。Symphony 的主要目的是承擔例行性工作，讓人們可以一次專注於一個困難的問題。 OpenAI 不打算將 Symphony 作為獨立產品維護，而是將其視為一個參考實作。社群已經發布了多個分支版本，包括一個適用於 Anthropic 的 Claude Code 並整合 GitHub Issues 的版本。程式碼和規範可在 GitHub 上取得。 Symphony 是 OpenAI 眾多代理人專案之一。四月中旬，該公司在 ChatGPT 中推出了工作區代理人，同樣由 Codex 提供支援，旨在自動化複雜的團隊工作流程。這些代理人擁有自己的工作區，可以整合 Slack，即使使用者離線也能持續運行。