OpenAI 开源 Symphony 自主管理编码代理
The Decoder··作者 Jonathan Kemper
关键信息
OpenAI 将 Symphony 主要定义为一份以 Markdown 文档为核心的规范，并提供了一个用 Elixir 编写的实验性参考实现，而不是一个固定产品。该系统把 Linear 的工单状态当作状态机来使用，能够重启卡住的代理，支持非编码任务，并且在代理发现额外工作时自动创建后续工单。
资讯摘要
OpenAI 推出了 Symphony，作为一种利用 Linear 等项目跟踪工具来编排 Codex 代理的开源方式。OpenAI 表示，这个想法源于内部遇到的瓶颈：虽然代理本身执行很快，但开发者在并行监督大约三到五个编码会话后，就会因为频繁切换上下文而明显降低效率。Symphony 通过反转这种流程来解决问题，让每个处于激活且未被阻塞状态的工单都拥有自己的代理和工作空间，使任务看板真正成为工作分发与跟踪的中心。工单会在 Todo、In Progress、Review 和 Merging 等状态之间流转，系统持续监控看板，确保每个活跃任务都有代理负责；如果代理崩溃或停滞，系统会自动将其重新拉起。
OpenAI 表示，在上线后的前三周，一些内部团队合并的 pull request 数量提升了六倍。文章还指出，这些任务既可以是跨多个代码仓库的代码修改，也可以是完全没有代码产出的研究或分析工作。如果代理在执行过程中发现性能问题或重构机会等额外事项，它们还能自行创建新的工单；OpenAI 还称，产品经理和设计师也可以直接提交需求，并收到包含视频演示在内的审核包，而无需亲自操作代码仓库。OpenAI 强调，Symphony 被刻意设计成一套轻量规范，其核心是一份 SPEC.md 文档，因为团队发现，与其把代理锁定在僵硬的步骤流程中，不如给它们明确目标、工具和上下文，让模型发挥推理能力。
资讯正文
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，并且即使用户离线也能继续运行。
来源与参考