An open-source spec for orchestration: Symphony

2026年4月27日

作者：Alex Kotliarskyi、Victor Zhu 和 Zach Brock

六个月前，在开发一个内部生产力工具时，我们团队做出了一个当时颇具争议的决定：构建一个完全没有人工编写代码的代码仓库。仓库中的每一行代码都必须由 Codex 生成。

为了实现这一目标，我们从底层重新设计了工程工作流。我们构建了一个对智能体友好的代码仓库，大量投入自动化测试和防护机制，并将 Codex 视为一个完整的团队成员。我们在此前关于运行框架 (harness) 工程⁠的博客文章中记录了这一过程。

这一方法确实奏效了，但随后我们遇到了下一个瓶颈：上下文切换。

为了解决这个问题，我们构建了一个名为 Symphony 的系统。Symphony⁠（在新窗口中打开） 是一个智能体编排器，它将类似 Linear 的项目管理看板转化为编程智能体的控制平面 (control plane)。每一个未关闭的任务都会对应一个智能体，智能体持续运行，而人类负责审查结果。

本文将介绍我们如何构建 Symphony — 在部分团队中将已合并到主分支的 Pull Request 数量提升了 500% — 以及如何将你自己的 issue 跟踪系统转化为一个始终在线的智能体编排系统。

交互式编程智能体的上限

即使编程智能体变得越来越易用 — 无论是通过 Web 应用还是 CLI 访问 — 它们本质上仍然是交互式工具。

随着 OpenAI 内部智能体工作规模的扩大，我们开始感受到一种新的负担。每位工程师都会打开多个 Codex 会话，分配任务、审查输出、引导智能体，然后不断重复这一过程。在实践中，大多数人通常只能同时管理 3 到 5 个会话，再多就会因为上下文切换而变得困难。一旦超过这个范围，生产力就会下降：我们会忘记每个会话正在做什么，在不同终端之间来回切换以将智能体拉回正轨，还需要调试那些中途停滞的长时间运行任务。

智能体本身运行很快，但系统的瓶颈在于人类注意力。我们实际上构建了一支能力极强的“初级工程师团队”，却让人类工程师对其进行细粒度管理。这种模式无法扩展。

视角的转变

我们意识到，我们优化的对象是错误的。我们一直围绕编程会话和已合并的 PR 来组织系统，而实际上，这两者只是达成目标的手段。软件工作流通常是围绕交付物组织的，例如 issue、任务、工单和里程碑。

于是我们开始思考：如果不再直接监督智能体，而是让它们从任务跟踪系统中主动获取工作，会发生什么？

这个想法最终演变为 Symphony — 一份书面规范 (spec)，作为“监督者”来编排智能体工作。

将 issue 跟踪器转化为智能体编排器

Symphony 源于一个简单的理念：任何未关闭的任务都应由智能体接手并完成。我们不再在多个标签页中管理 Codex 会话，而是将 issue 跟踪系统作为控制平面 (control plane)。

在这一模式下，每一个未关闭的 Linear issue 都会映射到一个专属的智能体工作空间。Symphony 持续监控任务看板，确保每一个活跃任务在完成之前始终有智能体在循环执行。如果某个智能体崩溃或卡住，Symphony 会自动重启它；如果出现新的工作，Symphony 会立即接手并开始组织执行。

我们的工作流是基于工单状态构建的，将任务管理工具 Linear 作为一个状态机来使用。

在实践中，Symphony 将工作从会话和 Pull Request 中解耦。有些 issue 会在多个代码仓库中产生多个 PR；而另一些则只是纯粹的调研或分析，完全不会涉及代码库。

一旦以这种方式对工作进行抽象，工单就可以代表更大粒度的工作单元。

我们经常使用 Symphony 来编排复杂功能开发和基础设施迁移。例如，我们可以创建一个任务，让智能体分析代码库、Slack 或 Notion，并产出一份实现方案。当我们确认方案可行后，智能体会生成一棵任务树，将工作拆分为多个阶段，并定义任务之间的依赖关系。

智能体只会处理未被阻塞的任务，因此在这个 DAG（一个执行步骤序列）结构中，执行会自然且高效地并行展开。在下面的示例中，我们将 React 升级标记为依赖 Vite 迁移。正如预期，智能体会在 Vite 迁移完成之后才开始升级 React。智能体还可以自行创建任务。在实现或审查过程中，它们经常会发现一些超出当前任务范围的改进点，例如性能问题、重构机会或更优架构。这时，它们会直接创建新的 issue，供我们后续评估和排期 — 其中许多后续任务同样会被智能体接手执行。在我们进行整体监督的同时，智能体能够保持有序并持续推进工作。

这种工作方式显著降低了启动不确定性任务的认知成本。即使智能体做错了，这些结果仍然具有信息价值，而我们的成本几乎为零。我们可以以极低成本创建工单，让智能体进行原型验证和探索，并随时丢弃不满意的结果。

由于编排器运行在开发环境 (devbox) 上且始终在线，我们可以在任何地方添加任务，并确信会有智能体接手处理。例如，我们团队中曾有工程师在一个网络条件较差的小木屋里，仅通过手机上的 Linear 应用就完成了三项重要变更。

这种工作方式带来的探索能力提升

在观察 Symphony 带来的影响时，最直观的变化是产出。在 OpenAI 的一些团队中，已合并到主分支的 PR 数量在前三周内增长了 6 倍。在 OpenAI 之外，Linear 创始人 Karri Saarinen 也提到，在 Symphony 发布后，工作空间创建量出现了明显增长⁠（在新窗口中打开）。不过，更深层的变化在于团队对“工作”的理解方式。

当工程师不再需要花时间管理 Codex 会话时，代码变更的成本结构发生了根本变化。由于不再需要投入人力推动具体实现，每一次变更的感知成本显著下降。

这也改变了我们的工作方式。在 Symphony 中启动探索性任务变得非常轻量：尝试一个想法、探索一次重构、验证一个假设，然后只保留那些有价值的结果。

此外，它还扩大了可以发起工作的角色范围。产品经理和设计师现在可以直接在 Symphony 中提交功能请求，无需检出代码仓库，也无需管理 Codex 会话。他们只需描述需求，就能获得一个评审包，其中包含该功能在真实产品中的视频演示。

Symphony 在大型单体仓库（就像我们在 OpenAI 用的那种) 中同样表现出色。在这种环境下，将一个 PR 成功落地到主分支的“收尾阶段”往往缓慢且脆弱。系统会持续监控 CI，在需要时自动执行变基、解决冲突、重试不稳定的检查，并整体上推动变更通过整个流水线。当一个任务进入合并阶段时，我们已经可以高度确信该变更能够在无需人工干预的情况下顺利进入主分支。

进步也会带来新的问题

在