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 实现」的措辞。