OpenAI 开源 Symphony：把任务看板变智能体控制台，PR 提升 500%

Symphony 是 OpenAI 开源的一套编程智能体编排规范，核心目标是把 Linear 这类任务管理看板变成 Codex 编程智能体的控制台。只要在看板上建一个任务，系统就会自动派出一个常驻智能体负责到底，人类工程师只需要在最后审核代码和结果。

它能解决什么问题

在此之前，工程师用代码智能体往往要开好几个终端或网页会话。每个人盯三到五个窗口就到了极限，注意力全耗在切换上下文、排查卡住的任务上，人反而成了智能体的保姆。

Symphony 把交互模式转成了工单驱动。在 OpenAI 内部，部分团队换用 Symphony 后的三周内，合并入库的 PR 数量激增了 500%，Linear 创始人 Karri Saarinen 也提到相关工作区创建量出现了暴增。

这套机制把发起工作的门槛降到了极低。产品经理和设计师可以直接在 Linear 上提需求，不用拉代码仓库，智能体做完后会直接返回包含实际运行录屏的审核包。工程师甚至能在度假木屋里靠着微弱的网络信号，直接用手机上的 Linear 推进重要改动。

怎么做到的

Symphony 在 GitHub 仓库里本质上只是一份 SPEC.md 规范文件，用来定义问题和解决思路。官方提供了一套 Elixir 语言编写的参考实现，利用 Elixir 原生的并发与进程监督能力来管理常驻智能体。测试期间，团队还让 Codex 用 TypeScript、Go、Rust、Java 和 Python 分别实现过这套规范，全部一次成功。

它的运作逻辑就像一个状态机：Symphony 持续监听看板，为每个未受阻断的任务分配独立的智能体工作区。遇到复杂功能，智能体能自动把任务拆解成带有前后依赖关系的有向无环图，按顺序推进。如果在写代码或自测时发现了新问题，智能体还会主动建一张新工单排期。

针对大型代码仓库合并困难的问题，系统会全程盯住 CI 流水线，自己处理代码变基、冲突解决以及偶发性测试失败，直到分支顺利合并。

去哪里试以及有什么门槛

完整的 SPEC.md 和 Elixir 参考实现已经放到了 GitHub 的 Symphony 仓库。你可以直接阅读这份规范，或者把它喂给你熟悉的编程模型，让模型用你顺手的语言写一套适配自己团队的调度工具。

不过要注意，Symphony 极度依赖代码仓库本身的防御机制。如果没有完善的自动化测试、端到端检查以及清晰的代码风格约束，放任智能体后台自闭环很容易产生大量偏离预期的废代码。高度模糊、需要复杂架构权衡的工作，目前依然需要工程师回到交互式终端前手动处理。

为什么重要

对于软件工程团队来说，Symphony 指明了一条从「人工盯梢 AI」转向「流水线化管理 AI」的务实路径。它适合需要日常处理海量常规工单、底层库迁移或探索性重构的中大型研发团队，值得技术主管深入研究。

我们认为，这套方案最聪明的地方在于做减法。OpenAI 没有去造一套笨重的调度中间件，而是把成熟的工单看板直接当成状态机，把核心逻辑浓缩成一份 Markdown 规范，甚至连规范代码都交给模型自己写。它标志着代码生成的竞争焦点，已经从单个模型写几行代码的速度，转向了整个工程管线的自动化编排效率。