OpenAI 的 Symphony 让代理自主管理编码工作
The Decoder··作者 Jonathan Kemper
关键信息
OpenAI 表示，Symphony 把 Linear 当作一个状态机来使用，工单会在 Todo、In Progress、Review 和 Merging 等状态之间流转，系统会确保每个活跃工单都有代理负责。OpenAI 还说，代理可以自行创建后续工单，而参考实现使用 Elixir 编写，核心行为则主要写在一个 SPEC.md 文件里。
资讯摘要
OpenAI 发布了 Symphony，这是一个开源规范加参考实现，目标是让 Codex 代理更自主地处理软件任务。这个系统把 Linear 这类任务跟踪器当作工作的调度层，因此开放工单可以直接由代理领取，而不是由开发者手动监督多个会话。OpenAI 表示，这一变化是为了解决他们内部遇到的实际瓶颈：当同时运行超过三到五个 Codex 会话时，人类的上下文切换就成了限制生产力的因素。公司认为，真正的瓶颈不是模型速度，而是人类注意力。使用 Symphony 后，每个开放工单都会对应一个独立的代理和工作区，并一直运行到任务完成。若代理崩溃或卡住，系统可以把它重新拉起；只有未被阻塞的工单才会被选中，这样依赖关系允许时，工作就能并行推进。
OpenAI 还说，代理在发现相关问题时可以自己创建新工单，比如性能问题或重构机会。有些任务可能跨多个 pull request，甚至跨多个仓库；另一些则可能是纯研究或分析工作，并不涉及代码改动。OpenAI 称，在引入该系统后的前三周里，内部团队的合并 pull request 数量增长了六倍。这个项目的核心并不是复杂监控系统，而是一个名为 SPEC.md 的 Markdown 规范文件，参考实现则使用 Elixir 编写。OpenAI 从 Symphony 的实践中得到的一个结论是，代理很难被当作固定节点硬塞进严格的状态机里，因此公司现在更倾向于给它们目标和上下文，而不是逐步操作手册。文章还提到，社区已经开始把这个系统改造到其他模型和平台上。
资讯正文
OpenAI 表示，人类注意力才是瓶颈，因此它构建了一套让代理自行管理的系统。
OpenAI 发布了 Symphony，这是一个开源规范，并附带参考实现，可将 Linear 这类任务跟踪工具变成 Codex 代理的指挥中心。开发者不再需要同时周旋于多个会话之间，代理会自行领取未处理的工单，而人类只需审核结果。
据 OpenAI 称，一些内部团队在最初三周内，已合并的 pull request 数量跃升至原来的六倍。Linear 创始人 Karri Saarinen 也注意到，在这一发布之后，他的项目规划工具中新建工作区的数量出现了激增。
借助 Symphony，每个未关闭的工单都会分配到一个独立的 Codex 代理和专属工作区，并持续运行直到任务完成，这使任务看板真正成为工作被分发出去的地方。
当人类注意力成为瓶颈
OpenAI 表示，在 Symphony 出现之前，OpenAI 的开发者会并行运行多个 Codex 会话、分派任务，并跟进每个会话的进展。实际操作中，如果没有因频繁切换上下文而导致生产力大幅下降，想要同时运行超过 3 到 5 个会话几乎是不可能的。
开发者写道：“代理运行得很快，但我们的系统瓶颈是：人类注意力。”他们原本打造出了一支“初级开发者”团队，却把微观管理的负担留给了人类同事。这也促使他们想到将工作流反转：不再由人监督各个会话，而是让代理直接从任务跟踪器中拉取自己的工作。
把 Linear 当作状态机
Symphony 将 Linear 用作状态机。工单会在 “Todo”“In Progress”“Review” 和 “Merging” 等状态之间流转。系统会监视看板，并确保每个活跃工单都有一个代理负责。如果某个代理崩溃或停滞，Symphony 会将其重新拉起。
只有未被阻塞的工单才会被领取，这使一个任务树能够并行运行。团队举了一个 React 升级的例子：只有在上游迁移到 Vite 之后，这项工作才会启动。工单的规模也可能远不止一次代码修改。有些工单会在不同代码仓库中衍生出多个 pull request，而另一些则完全是研究或分析任务，根本不涉及代码。
如果代理在执行当前工单的过程中发现了当前工单之外的问题，比如性能问题或重构机会，它们会自行新建工单。OpenAI 表示，产品经理和设计师也可以直接提交功能请求，并收到一个包含视频演示讲解的审查包，而完全不必检出代码仓库。
从打造 Symphony 的过程中得到的一个教训是：很难把 agents 当作状态机里的固定节点来对待。模型一直在进步，也能处理比模板计划中更大的问题。团队现在更倾向于给 agents 设定目标，而不是规定严格流程，就像经理给员工的是要交付的结果，而不是一步一步的操作手册。
团队表示：“模型的力量来自它们的推理能力，所以给它们工具和上下文，然后让它们自己发挥。”
其核心是一个 Markdown 文件
打开 Symphony 的代码仓库，你大多会看到一个 SPEC.md。这个 Markdown 文件列出了问题和期望的解决方案。OpenAI 没有构建一个复杂的监控系统，而是提供了一份规范，让 agents 自行去实现。参考实现是用 Elixir 编写的，这是一种在并发进程方面拥有扎实工具链的语言。OpenAI 表示，Codex 一次就完成了这一实现。为了对这份规范进行压力测试，Codex 团队还让它分别用 TypeScript、Go、Rust、Java 和 Python 实现了一遍。
开发工作流——接受工单、检出代码仓库、设置状态、附加 PR、附加视频——写在一个 WORKFLOW.md 中，Symphony 会把它作为指南交给 agents。要改变流程，只需编辑这个文件，Symphony 就会把 agents 指向新版本。
限制、分支，以及下一步
OpenAI 表示，并不是每一项任务都适合 Symphony。那些含糊不清的问题，或者需要判断力的工作，仍然由开发者在交互式 Codex 会话中直接处理。Symphony 的主要作用，是吸收日常例行工作，让人们能够一次只专注于一个困难问题。
OpenAI 不打算把 Symphony 作为独立产品来维护，而是将它更多视作一个参考实现。社区已经推出了多个分支版本，其中包括一个面向 Anthropic 的 Claude Code、并集成 GitHub Issues 的版本。代码和规范都已在 GitHub 上提供。
Symphony 是 OpenAI 多个 agent 项目之一。4 月中旬，这家公司在 ChatGPT 中推出了工作区 agents，同样由 Codex 驱动，目标是自动化复杂的团队工作流。它们拥有自己的工作区，可以接入 Slack，并且即使用户离线也能继续运行。
来源与参考
收录于 2026-05-05