OpenAI 开源 Symphony:让每个任务自动跑一个 AI Agent

瓶颈不在 Agent，在人

OpenAI 的工程师 Alex Kotliarskyi（也是 React Native 的核心贡献者）在推文中说得很直白：

Codex 很聪明，但人的注意力是有限的。当团队里每个人同时开好几个 Codex 会话，在终端之间来回切——这个会话卡住了要调试，那个会话在做什么已经忘了——工程师的时间被「微管理 Agent」吃掉了。

实际上，大多数人能同时管理的 Codex 会话只有 3-5 个。超过这个数，效率直线下降。会忘掉哪个会话在做什么，在终端之间跳来跳去纠偏，调试半路卡住的长任务。

Agent 的速度很快，但系统瓶颈出现了：人的注意力。OpenAI 的团队实际上造了一群能力极强的初级工程师，然后让高级工程师全职去微管理他们。这不是长久之计。

视角转换：从管理会话到管理任务

团队意识到他们在优化错误的东西。之前一直围绕「编码会话」和「合并 PR」来设计流程，但这些只是手段。软件工程的真正组织单元是什么？是需求、是任务、是里程碑。

那如果不再让人去直接监督 Agent，而是让 Agent 从任务管理器里自己拉活呢？

这个想法变成了 Symphony。

Symphony 的核心思路：把 Issue 看板当成控制面板。每个待办任务自动分配一个 Agent，Agent 7×24 小时运行直到任务完成，人类只需要看结果。

Symphony 的完整工作流程

先看一张全景图，了解单个任务在 Symphony 里是怎么走完一圈的：

具体来说，Symphony 做了这几件事：

1. 1自动接单：持续轮询 Linear 看板，每个处于活跃状态的任务都会被分配一个独立的 Agent 工作区
2. 2独立工作区：每个任务有自己的目录空间，Agent 之间互不干扰，不会出现两个 Agent 同时改同一个文件的情况
3. 3自动重启：Agent 崩了或卡住了，Symphony 自动拉起来继续跑，不需要人工干预
4. 4状态驱动：通过 Linear 的任务状态（Todo → In Progress → Review → Done）驱动整个流程。注意，Symphony 本身只负责读取和调度，状态转换是 Agent 通过工具完成的
5. 5依赖管理：任务之间可以设依赖关系。Agent 会自动判断：哪些不依赖别人可以并行，哪些得等前置完成

这种设计有个很实际的用处。比如一个复杂需求可以拆成一棵任务树：先做「迁移到 Vite」，再做「升级 React」，再做「更新组件库」。Agent 自动识别依赖关系，Vite 迁移没完成之前，React 升级的任务会被标记为 Blocked，不会提前启动。等 Vite 搞定了，React 升级自动开始。

还有一些有趣的细节：

• Agent 在实现过程中发现改进点（性能问题、重构机会、更好的架构），会自己创建新的 Issue，后面这些新任务也会被其他 Agent 接走
• 每个任务不一定只产生一个 PR——有些任务可能跨多个仓库产出多个 PR，有些可能是纯分析调研，根本不碰代码
• 一旦工作被抽象成「任务」而非「会话」，任务的粒度可以大得多——团队经常用 Symphony 来编排复杂的功能开发和基础设施迁移

Agent 的能力是怎么一步步进化的

OpenAI 坦诚分享了一个关键教训：把 Agent 当成状态机里的刚性节点是行不通的。

早期版本，Symphony 只让 Codex 去实现任务描述里的功能。结果很快发现这个框太窄了。Codex 完全有能力创建多个 PR、阅读 review 反馈并处理它、甚至做更多事情。

所以 OpenAI 开始给 Agent 装工具——gh CLI、读 CI 日志的技能等等。Agent 的能力边界被不断推远：

最终的思路是：给 Agent 目标，而不是严格的步骤。 就像好的管理者给下属定方向而不是写操作手册——模型的核心能力是推理，给它工具和上下文，让它自己发挥。

但也不是所有任务都适合。需要强判断力的模糊问题、需要深度专业知识的工作，仍然需要工程师直接用交互式 Codex 会话来做。好消息是，日常重复性的实现工作被 Symphony 接管了，工程师可以专注在真正有意思的难题上。

实际效果：PR 数量翻 5 倍

OpenAI 公布了内部数据：部分团队在使用 Symphony 后的前三周，合并的 PR 数量增加了 500%。

Linear 创始人 Karri Saarinen 也分享了一个有意思的观察：

Symphony 开源发布后，Linear 上的新工作空间数量出现了明显增长。这说明不只是 OpenAI 在用，整个开发社区都在尝试这种「看板驱动 Agent」的模式。

更深层的变化不是产出量，而是工作方式本身变了。当工程师不再花时间盯 Agent 会话，发起一个代码变更的心理门槛一下子就降下来了。想试个想法？提个任务就行。探索性重构？提个任务就行。反正 Agent 24 小时在线，不睡觉，随时接单。搞出来不好用？扔掉就是，成本几乎为零。

这也改变了谁可以发起工作。产品经理和设计师现在可以直接往 Symphony 里提需求——不用 checkout 代码库，不用管理 Codex 会话，描述完需求就能收到一个包含功能演示视频的审核包。

Ryan Carson 分享了他的实践经验：

他同时跑 5 个 Agent，用 Symphony + Codex + Linear 的组合，实现了团队 100% 代码由 AI 编写。甚至有工程师在山间小木屋里用手机上的 Linear App 就完成了三个重大变更——因为只需要提任务，Agent 会在 devbox 上自己干活。

还有一个有意思的细节：团队在观察中发现，使用 Symphony 后最大的变化不是产出量，而是探索行为大幅增加。当发起一次代码变更的代价趋近于零，人们开始更频繁地做实验性尝试——试一个想法、探索一次重构、验证一个假设，然后只留下看起来有希望的结果。这种「低成本试错」模式以前只有在 Google 这种级别的内部工具链里才能做到。

对大仓库特别有用

OpenAI 自己是巨型 monorepo，PR 合并的最后一段路程（过 CI、rebase、解冲突、重试不稳定的检查）特别慢、特别容易出问题。

Symphony 在这块帮了大忙——它会持续盯着 CI 状态，自动 rebase，自动解冲突，自动重试偶然失败的检查项。等任务到达「合并中」状态时，团队已经很有信心这个变更能顺利合入主分支，不需要人工 babysit。

技术本质：一个 Markdown 规格文件

打开 Symphony 的 GitHub 仓库，你会发现一个出乎意料的事实：Symphony 技术上就是一个 SPEC.md 文件——对问题的定义和预期解决方案的描述。

OpenAI 没有去造一个复杂的监控系统。它定义了以下核心组件：

整个系统的状态机只有 5 个状态：Unclaimed → Claimed → Running → RetryQueued → Released。

这种「规格即代码」的思路很有意思：不是硬编码每个状态转换，而是定义好目标和约束，让 Agent 自己推理怎么从 A 走到 B。社区已经基于这个 spec 做了多种实现（包括 Elixir/OTP 版本），说明 spec 本身的设计足够通用。

用 Symphony 构建 Symphony

最 meta 的是：Symphony 本身就是用 Symphony 来开发的。

团队把 Symphony 的开发任务拆成 Issue，然后用 Symphony 自己来编排 Agent 完成这些任务。等于说这个工具在开发自己的过程中就在被验证和迭代。

代价和局限

说了这么多好处，也得讲讲代价。

Token 消耗巨大。 有用户（Dan McAteer）报告，他的 Symphony 在处理一个项目时，14 小时内消耗了约 3.88 亿 Token，按 GPT-5.4 API 定价算下来大约 1000 美元。他的一周 Codex 用量已经清零（可能是用量配额被吃光了）。对个人开发者来说，这个成本目前可能不划算。

不适合模糊问题。 需要强判断力、需要深度专业知识的任务，仍然得工程师亲自上手。Symphony 解决的是「知道要做什么」之后的那部分执行工作。

需要完善的前置条件。 自动化测试、护栏、文档——这些东西得先到位，否则 Agent 跑起来就是在制造混乱。OpenAI 在此前的 harness engineering 博客里详细讲过怎么建这些基础设施。

失去了实时纠偏的能力。 从「实时引导 Agent」变成「事后审核结果」，有时候 Agent 产出的东西完全跑偏了。OpenAI 的策略是不手动修补结果，而是把失败当作系统改进的信号——加护栏、加技能、完善文档，让 Agent 下次能自己搞定。

写在后面

Symphony 背后反映的趋势很明确：AI 编码工具正在从「人和模型对话」进化到「人给系统派活」。

以前是你打开终端，跟 Codex 聊，等它写完代码，你再审。现在是你往 Linear 里提个任务，Agent 自己拉代码、写代码、跑测试、提 PR，你只需要看最终结果说「行」或「不行」。

这个转变对团队的影响比单个工具大得多。它改变了谁可以发起工作、发起工作的成本有多低、以及工程师的时间花在哪里。正如那条推文说的：提示词框只是一个阶段，未来是 always-on 的编排。

OpenAI 开源了 Symphony——一个把任务看板变成 AI Agent 自动化编排系统的工具。每个待办任务自动分配 Codex Agent，7×24 小时运行，工程师只需要审核结果。内部数据显示部分团队 PR 数量增长 500%。它代表了一个趋势：AI 编码从「人跟模型对话」走向「人给系统派活」。不过 Token 成本不低（14 小时可能烧 1000 美元），也不适合所有类型的任务。

参考链接

• OpenAI 官方博客：https://openai.com/index/open-source-codex-orchestration-symphony/
• Symphony GitHub 仓库：https://github.com/openai/symphony
• OpenAI 此前博客「Harness Engineering」：https://openai.com/index/harness-engineering/
• Linear 创始人 Karri Saarinen 讨论：https://x.com/karrisaarinen/status/2031773828284919878