用于编排的开源规范：Symphony

2026 年 4 月 27 日

作者：Alex Kotliarskyi、Victor Zhu 和 Zach Brock

加载中……分享六个月前，在开发一个内部生产力工具时，我们团队做了一个在当时颇具争议的决定：我们要构建一个没有人工编写代码的 repo。项目 repository 中的每一行都必须由 Codex 生成。

为了让这件事可行，我们从头重新设计了 engineering workflow。我们构建了一个 agent-friendly repository，大量投入 automated tests 和 guardrails，并把 Codex 当作正式队友看待。我们在上一篇关于 harness engineering⁠ 的 blog post 中记录了这段过程。

这套方法奏效了，但随后我们遇到了下一个瓶颈：context switching。

为了解决这个新问题，我们构建了一个名为 Symphony 的系统。Symphony⁠(opens in a new window) 是一个 agent orchestrator，可以把 Linear 这样的 project-management board 转换为 coding agents 的 control plane。每个 open task 都会获得一个 agent，agents 持续运行，而 humans 负责 review 结果。

本文会解释我们如何创建 Symphony——它让一些团队的 landed pull requests 增加了 500%——以及如何用它把你自己的 issue tracker 变成一个 always-on agent orchestrator。

即使 coding agents 变得更易用，无论是通过 web apps 还是 CLI 访问，它们仍然是 interactive tools。

随着 OpenAI 内部 agentic work 的规模扩大，我们发现了一种新的负担。每位 engineer 会打开几个 Codex sessions，分配 tasks，review output，引导 agent，然后重复这个过程。实践中，大多数人一次最多能舒服地管理三到五个 sessions；再多，context switching 就会变得痛苦。超过这个范围后，productivity 会下降。我们会忘记哪个 session 在做什么，在不同 terminals 之间来回切换以把 agents 拉回正轨，还要 debug 那些运行很久却中途卡住的 tasks。

Agents 很快，但我们的系统瓶颈是：human attention。我们实际上构建了一支能力很强的 junior engineers 队伍，却让 human engineers 去 micromanage 他们。这种方式无法 scale。

我们意识到自己优化错了对象。我们一直围绕 coding sessions 和 merged PRs 来组织系统，但 PRs 和 sessions 实际上只是达成目标的手段。Software workflows 很大程度上是围绕 deliverables 组织的：issues、tasks、tickets、milestones。

于是我们问自己：如果我们不再直接监督 agents，而是让它们从 task tracker 中拉取工作，会发生什么？

这个想法后来成为 Symphony：一个 written spec，用作 supervisor 来 orchestrate agentic work。

Symphony 起始于一个简单概念：任何 open task 都应该由一个 agent 接手并完成。我们不再在多个 tabs 中管理 Codex sessions，而是把 issue tracker 变成 control plane。

在这个设置中，每个 open Linear issue 都映射到一个专用的 agent workspace。Symphony 持续观察 task board，并确保每个 active task 在完成前都有一个 agent 处于 loop 中。如果 agent crash 或 stall，Symphony 会 restart 它。如果出现新 work，Symphony 会接手并开始组织工作。

我们基于 ticket statuses 构建 workflow，使用 task manager Linear 作为 state machine。

实践中，Symphony 将 work 与 sessions、pull requests 解耦。有些 issues 会在多个 repos 中产生多个 PRs；另一些则是纯 investigation 或 analysis，完全不接触 codebase。

我们经常使用 Symphony 来 orchestrate 复杂 features 和 infrastructure migrations。例如，我们可能创建一个 task，让 agent 分析 codebase、Slack 或 Notion，并生成一个 implementation plan。当我们认可这个 plan 后，agent 会生成一棵 task tree，把工作拆分成多个 stages，并定义 tasks 之间的 dependencies。

Agents 只会开始处理未被 blocked 的 tasks，因此对于这个 DAG（一系列执行步骤），execution 会自然且最优地并行展开。例如，我们把 React upgrade 标记为依赖 migration to Vite。正如预期，agents 只有在 migration to Vite 完成后才开始升级 React。Agents 也可以自己创建 work。在 implementation 或 review 期间，它们经常会注意到当前 task scope 之外的改进点：performance issue、refactoring opportunity，或更好的 architecture。发生这种情况时，它们会直接 file 一个 new issue，供我们之后评估和排期——其中许多 follow-up tasks 也会被 agents 接手。我们会监督这个过程，而 agents 会保持有序并推动工作继续前进。

这种工作方式显著降低了启动 ambiguous work 的 cognitive cost。如果 agent 做错了，这仍然是有用信息，而我们付出的成本几乎为零。我们可以非常低成本地给 agent file tickets，让它去 prototype 和 explore，并丢弃任何我们不喜欢的 explorations。

由于 orchestrator 运行在 devboxes 上且不会休眠，我们可以从任何地方添加 tasks，并知道某个 agent 会接手。例如，我们团队的一位 engineer 曾在一个舒适小木屋里，用信号很差的 wifi，通过手机上的 Linear app 完成了三项重要 changes。

观察 Symphony 带来的影响时，最明显的变化是 output。在 OpenAI 的一些团队中，我们看到 landed PRs 的数量在前三周增加了 500%。在 OpenAI 之外，Linear founder Karri Saarinen 在我们发布 Symphony 时也提到 workspaces created⁠(opens in a new window) 出现了增长。不过，更深层的变化是 teams 对 work 的思考方式。

当我们的 engineers 不再花时间监督 Codex sessions 时，code changes 的 economics 完全改变了。每次 change 的感知成本下降了，因为我们不再把 human effort 投入到驱动 implementation 本身。

这改变了我们的行为。在 Symphony 中启动 speculative tasks 已经变得非常轻松。尝试一个 idea，探索一个 refactor，测试一个 hypothesis，然后只保留看起来有前景的结果。

它也扩大了能够发起 work 的人群。我们的 product manager 和 designer 现在可以直接把 feature requests file 到 Symphony 中。他们不需要 check out repo，也不需要管理 Codex session。他们描述 feature，然后得到一个 review packet，其中包括该 feature 在真实产品中运行的视频 walkthrough。

Symphony 在大型 monorepos 中也很有价值（比如 OpenAI 使用的 monorepo），因为 PR landing 的 last mile 往往缓慢且脆弱。系统会观察 CI，在需要时 rebase，解决 conflicts，retry flaky checks，并整体上把 changes 推过 pipeline。当一个 ticket 到达 Merging 状态时，我们已经高度确信该 change 会进入 main branch，而不需要 human babysitting。

实现 Symphony 后，我们把更多 work delegate 给 agents，并把精力集中在更困难、更探索性的 tasks 上。

在这个层级上运行也有 tradeoffs。当我们从 interactive 地引导 agents 转向在 ticket level 给它们分配 work 时，我们失去了在执行过程中持续 nudging 并按需 course-correct 的能力。有时 agent 会产出完全偏离目标的东西。这是有用的——这些 failures 暴露了系统中的 gaps，并帮助我们让它更 robust。

我们没有手动 patch 结果，而是添加 guardrails 和 skills，让 agents 下一次能够成功。随着时间推移，这让我们为 harness 增加了新的 capabilities，例如运行 end-to-end tests、通过 Chrome DevTools 驱动 app，以及管理 QA smoke tests。我们显著改进了 documentation，并澄清了什么才算 good。

并非每个 task 都适合 Symphony 风格的工作。一些问题仍然需要 engineers 直接使用 interactive Codex sessions，尤其是 ambiguous problems，或需要强判断力和专业知识的 work。实践中，这些通常也是 engineers 最感兴趣、最愿意投入时间的 tasks。

不同之处在于，Symphony 可以处理大量 routine implementation work。这让 engineers 可以一次专注于一个 hard problem，而不是不断在 smaller tasks 之间 context-switch。

我们还学到，把 agents 当作 state machine 中刚性的 nodes 并不好。Models 会变得更 smart，并且能解决比我们试图塞给它们的框更大的问题。我们早期的 agentic work 只是要求 Codex implement task。这种方法后来证明过于受限。Codex 完全有能力创建多个 PRs，也能读取 review feedback 并加以处理。因此我们给了它 tools——gh CLI、读取 CI logs 的 skills，等等——现在我们可以要求 Codex 做更多事情，比如关闭 old PRs，或拉取 completed vs. abandoned work 的 reports。这类 tasks 远远超出了最初的 feature implementation 框。

所以我们最终转向给 agents objectives，而不是严格的 transitions，就像一个好的 manager 会给团队中的 direct report 分配 goal 一样。Models 的力量来自它们的 reasoning 能力，所以给它们 tools 和 context，然后让它们发挥。

当你打开 Symphony repository⁠(opens in a new window) 时，首先会注意到 Symphony 在技术上只是一个 SPEC.md file——对问题和预期解决方案的定义。我们没有构建一个复杂的 supervision system，而是定义了问题和预期 solutions，给 agents 高层 steering。

参考实现使用 Elixir 编写——因为当代码几乎是免费的时，你终于可以根据语言的优势来选择语言，比如 Elixir 的 concurrency——但核心想法可以用一个简单的 Markdown document 表达。我们鼓励你把自己喜欢的 coding agent 指向这份 spec，让它实现自己的版本。

Symphony 的第一个版本只是一个运行在 tmux 中的 Codex session，轮询 Linear，并为 new tasks 启动 sub-agents。它能工作，但并不特别可靠。第二个版本存在于我们的 main project repository 中，而这个 repository 本来就是为 agents 设计的。我们已经构建了 agent harness，为 agents 提供在这个 repo 中高质量工作的 skills 和 context，所以 Symphony 只是把这一切连接起来。

一旦 basic functionality 存在，我们就用 Symphony 来构建 Symphony。

当我们在内部 demo 这个系统如何管理 tasks 并附上 proof-of-work video 时，反馈非常积极：我们的 Symphony project channel 增长了，组织内各团队也开始自发使用它。Internal product market fit 是 OpenAI 对外发布的前提。基于我们在 OpenAI 看到的使用情况，我们很清楚应该把 Symphony 分享到公司之外。

于是我们把这个想法抽取成一个 standalone SPEC.md，并要求 Codex 实现它。对于 reference implementation，我们选择了 Elixir，这是一门相对小众但拥有优秀 primitives 来 orchestrate 和 supervise concurrent processes 的语言。Codex 一次性构建了 Elixir implementation，之后我们继续迭代 spec 和 implementation。为了打磨 spec，我们甚至要求 Codex 用其他几种语言实现它——TypeScript、Go、Rust、Java、Python——并利用这些结果识别 ambiguities、简化系统。它在每种语言中都成功了。

在构建 Symphony 的过程中，我们移除了很多 incidental complexity，例如对特定 repositories 或 Linear MCP 的依赖。Symphony 不再依赖我们的 internal repositories 或 workflows。核心方法变得简单：

除了帮助完成 active work，development workflow 现在也成为 agents 了解并遵循的内容。Development workflow——处理一个 issue，check out 一个 repo，把它设为 in progress 让 PM 知道它正在被处理，添加 PR，把它移到 Review 状态，附上 videos，等等——现在被记录在一个简单的 WORKFLOW.md file 中。所有这些本来都是 humans 遵循的流程，但从未被记录下来。与其依赖这组隐式步骤，我们现在把它文档化，而 Symphony 确保 agents 遵循它。这让我们能够构建与我们并肩工作的 agents。如果我们决定 agents 也应该给完成的 work 附上 self-reflection，我们会把它添加到 WORKFLOW.md 中，Symphony 会引导 agents 完成这个步骤。

我们也得以使用 Codex 的 app server mode⁠(opens in a new window)，这是 Codex 内置的 headless mode。这个 mode 允许我们运行 Codex，并通过文档完备的 JSON-RPC API 以编程方式与它交互，用于启动 thread、响应 turns 等。相比通过 CLI 或 live tmux sessions 与 Codex 交互，它更方便，也更可 scale。

Codex App Server 非常适合我们的 use case：我们利用 Codex 提供的 harness，同时又有 knobs 和 hooks 可以接入。例如，为避免把 Linear access token 暴露给 subagents，我们使用 dynamic tool calls⁠(opens in a new window) 暴露 raw linear_graphql function，用于向 Linear 执行任意 requests，而无需依赖 MCP，也无需把 access token 暴露给 containers。

Symphony 是一个有意保持 minimal 的 orchestration layer。我们将其 open source，是为了展示 Codex App Server 与不同 workflow tools（如 Linear）结合时的能力。因此，我们不打算把 Symphony 作为 standalone product 来维护。可以把它看作一个 reference implementation。类似于许多 developers 曾把自己的 coding agents 指向 harness engineering post 来 scaffold 他们的 repositories，我们希望你把自己喜欢的 coding agent 指向 Symphony spec⁠(opens in a new window) 和 repository⁠(opens in a new window)，构建适合自己环境的版本。

真正的力量来自 Codex 及其 app server。Symphony 是一种把 Codex 连接到 Linear 的方式——这两者都是我们已经在使用的工具——用来解决 work management problem。随着 coding agents 更擅长 reasoning 和 following instructions，我们认为其他公司的瓶颈也会从 writing code 转向 managing agentic work。值得关注的是，现在试验这些 coding agent systems 的门槛已经很低。你可以直接用 Codex 构建东西。

我们很高兴看到 engineering community 在发布后的几周里使用 Symphony；截至 4 月 23 日，它已经获得超过 15K GitHub stars⁠(opens in a new window)。