OpenAI 5 月 17 日開源了 Symphony —— 一份 SPEC.md 加上一份 Elixir 參考實作,用來從專案管理 task board 來調度自主編碼 agent。Symphony 持續盯住這個 board(issue、任務、ticket、milestone),把每一個活躍的任務分派給一個專屬的 agent,這個 agent 自主跑直到任務做完,然後把結果擺出來給人去接受或拒絕。github.com/openai/symphony。OpenAI 的 framing:「agent 犯錯的代價顯著下降,因為它主要變成審閱已完成的工作然後拒絕它」 —— 批次非同步審,而不是互動式飛行中糾正。
把 Symphony 跟現有 agent 框架分開來的架構選擇,是 control plane。LangGraph 把狀態建模成一個由調度器擁有的圖;AutoGen 把它當成 agent 之間的對話;CrewAI 用顯式的角色/任務分派。Symphony 寄生在團隊已經在用的任何 issue tracker 上當 control plane —— 團隊 board 裡存在的每一個任務就是 agent 的輸入,agent 的輸出流回去成為 ticket 的更新。這是一個不瑣碎的設計點:它消掉了客製化調度器 UI,複用了團隊已經在跑的人工審閱工作流。它也把 agent 的任務面限制在「能裝進一個 issue 的東西」,這是一個有用的 prior。值得注意的實作細節:Elixir,不是 Python 或 TypeScript。Elixir 的 OTP 監督樹語意乾淨地映射到那些需要重啟和隔離的、長時間執行的每-agent 行程上。
把這條放在 5 月這一週的調度器發布堆裡看。Anthropic 發了 Routines(Claude Code 工作流跑在 Anthropic 自家雲上,由 repo 事件觸發,未公開定價)。BerriAI 開源了 LiteLLM Agent Platform(Kubernetes 自託管,MIT,多 provider)。現在 OpenAI 發 Symphony(SPEC 加 Elixir 參考,issue tracker 做 control plane)。9 天裡三種不同的調度哲學。Symphony 的具體押注:agent 調度器應該消失到團隊現有的 PM 工具裡去,而不是成為一個新的介面 —— 這是跟「我們營運雲」(Routines)或「你營運 Kubernetes」(LiteLLM)不一樣的競爭 framing。SPEC.md 是變成一個真正的互操作標準,還是停在一個 OpenAI 專屬的約定,取決於非 Codex agent 的社群實作有沒有落地。
週一上手:如果你團隊已經在跑某個 issue tracker(Linear、GitHub Issues、Jira),又一直在考慮自主編碼 agent,Symphony 的模式值得好好看一看 —— 整合故事是「你現有的 board,加一個盯著它的 agent」。Elixir 參考實作是一道門 —— 如果你沒有 BEAM 經驗,要麼把它當成一個模型,用你偏好的執行時重新實作,要麼等社群移植。短期可看的問題:Symphony 是不是會變成一個讓 Codex Mobile、Codex CLI 和第三方 agent 收斂過去的 SPEC,還是停在一個只服務 Codex 的調度器。在未來四到六週裡,盯緊 GitHub 倉庫有沒有非 Codex 的 adapter PR,以及 SPEC.md 裡關於「協議 vs 實作」的措辭。