OpenAI 推出 Symphony：将项目看板变为 AI 代理的自动化指挥中枢

从人工编写到 AI 生成：一场工程流程的彻底重构

六个月前，OpenAI 的一个内部团队做出了一个在当时颇具争议的决定：他们的项目仓库将不再包含任何人类编写的代码。仓库中的每一行代码，都必须由 Codex 生成。

为了实现这一目标，团队从头开始重新设计了工程工作流。他们构建了一个对 AI 代理友好的仓库结构，大力投资于自动化测试和安全护栏，并将 Codex 视为团队中的正式一员。这段经历在他们的上一篇关于“驾驭工程”（harness engineering）的博文中已有详细记载。

这个策略奏效了，但他们很快遇到了下一个瓶颈：上下文切换。

为了解决这个新问题，他们构建了一个名为 Symphony 的系统。Symphony 是一个 AI 代理编排器，它能够将 Linear 这样的项目管理看板，转变为一个用于操控编码代理的控制面板。每个未完成任务都会对应一个专属的代理，这些代理持续运行，而人类工程师则负责审核最终成果。

本文将详细阐述我们如何创建 Symphony——它使部分团队的合并请求（PR）数量提升了 500%——以及如何利用它，将你自己的问题追踪器变成一个永不掉线的 AI 代理编排器。

交互式编码代理的天花板

尽管使用起来越来越简单，但无论是通过网页应用还是命令行界面访问，编码代理本质上仍然是交互式工具。

随着 OpenAI 内部代理工作规模的扩大，我们感受到了一种新的负担。每位工程师需要同时打开数个 Codex 会话，分配任务、审核输出、引导代理，然后重复这一过程。在实践中，大多数人能舒适地同时管理三到五个会话，一旦超过这个数量，上下文切换就会变得痛苦不堪。超过这个界限，生产力便会急剧下降。我们会忘记哪个会话在处理什么任务，在多个终端之间来回切换以引导代理回到正轨，并调试那些执行到一半就卡住的长任务。

代理的速度很快，但我们的系统瓶颈在于：人类的注意力。我们实际上构建了一支由能力极强的初级工程师组成的团队，然后却让人类工程师去对他们进行微观管理。这显然无法规模化。

视角的转变

我们意识到，我们优化错了方向。我们的系统围绕着编码会话和合并的 PR 来运行，但 PR 和会话本身只是达成目的的手段。软件工作流在很大程度上是以可交付成果来组织的：问题（Issue）、任务、工单、里程碑。

于是我们自问：如果我们不再直接监督代理，而是让它们从任务追踪器中自主拉取工作，会发生什么？

这个想法催生了 Symphony——一个作为监督者来编排代理工作的书面规范。

将问题追踪器变为代理编排器

Symphony 的核心理念非常简单：任何未解决的任务都应该被代理拾取并完成。我们不再需要在多个标签页中管理 Codex 会话，而是让问题追踪器成为控制中心。

在这种设置下，Linear 中的每个未解决问题都映射到一个专用的代理工作空间。Symphony 持续监控任务看板，确保每个活跃任务都有一个代理在其生命周期内持续运行，直到任务完成。如果代理崩溃或卡住，Symphony 会重启它。如果有新任务出现，Symphony 会拾取它并开始组织工作。

我们根据工单状态来构建工作流，将任务管理器 Linear 作为一个状态机来使用。

在实践中，Symphony 将工作与会话和拉取请求解耦。有些问题会在多个仓库中产生多个 PR；有些则纯粹是调查或分析工作，不会触及代码库。

一旦工作以这种方式被抽象化，工单就可以代表更大规模的工作单元。

我们经常使用 Symphony 来编排复杂的功能开发和基础设施迁移。例如，我们可以提交一个任务，要求代理分析代码库、Slack 或 Notion，并生成一份实施计划。一旦我们对计划满意，代理就会生成一个任务树，将工作分解成多个阶段，并定义任务之间的依赖关系。

代理只会开始处理那些未被阻塞的任务，因此执行过程会自然地、最优地并行展开（形成一个有向无环图 DAG）。例如，我们将 React 升级标记为“依赖 Vite 迁移的完成”。正如预期，代理只在 Vite 迁移完成后才开始升级 React。

代理还可以自主创建新工作。在实施或审查过程中，它们经常能发现超出当前任务范围的改进点：一个性能问题、一个重构机会或一个更好的架构。当这种情况发生时，它们只需提交一个新工单，我们可以稍后评估和安排——这些后续任务中的许多也会被代理拾取。在我们监督整个流程的同时，代理保持了工作的有序性，并推动其向前发展。

这种工作方式极大地降低了启动模糊任务时的认知成本。如果代理做错了什么，这仍然是有价值的信息，而且对我们来说成本几乎为零。我们可以非常廉价地提交工单，让代理去进行原型设计和探索，然后丢弃任何我们不喜欢的探索结果。

由于编排器运行在开发盒（devbox）上，从不休眠，我们可以从任何地方添加任务，并知道会有代理来拾取它。例如，我们团队的一位工程师，在信号不佳的舒适小屋里，仅仅通过手机上的 Linear 应用就完成了三项重要的代码变更。

探索精神的提升

在观察 Symphony 带来的影响时，最明显的变化是产出。在 OpenAI 的一些团队中，我们看到合并的 PR 数量在头三周内增加了 500%。在 OpenAI 之外，Linear 的创始人 Karri Saarinen 也指出，随着我们发布 Symphony，工作区的创建量出现了激增。然而，更深层次的转变在于团队对工作本身的思考方式。

当我们的工程师不再需要花费时间监督 Codex 会话时，代码变更的经济性发生了根本变化。每次变更的感知成本大幅下降，因为我们不再需要投入人力去驱动实施过程本身。

这改变了我们的行为。发起一个探索性任务变得极其简单。

结语与展望

Symphony 代表了一种 AI 与人类协作的新范式。它不再要求人类去适应机器的交互模式，而是让 AI 代理主动融入人类以任务和项目为中心的工作流程中。这不仅解放了工程师的生产力，更重要的是，它释放了团队的创造力和探索精神。

未来，我们期待看到 Symphony 在更复杂的场景中发挥作用，并相信这种“任务驱动”的自动化编排方式将成为 AI 辅助软件开发的主流。