Codex 编排的开源规范：Symphony | OpenAI
2026年4月27日
作者： Alex Kotliarskyi、Victor Zhu 和 Zach Brock
六个月前，在开发一个内部生产力工具时，我们的团队做了一个（在当时）有争议的决定 ：我们的代码仓库将不包含任何人编写的代码。项目仓库中的每一行代码都必须由 Codex 生成。
为了实现这一点，我们从零开始重新设计了工程工作流：
- 构建了一个对智能体友好的代码仓库。
- 大力投资于自动化测试 和安全护栏。
- 视 Codex 为一位完全成熟的团队成员。
我们在之前的博客文章《驾驭工程》中记录了这段历程。
这个方法奏效了 ，但随后我们遇到了下一个瓶颈：上下文切换。
为了解决这个新问题，我们构建了一个名为 Symphony 的系统。
Symphony 是一个智能体编排器，它可以将 Linear 这样的项目管理面板转变为编码智能体的控制平面 。每一个未完成的任务都会获得一个专属智能体，这些智能体会持续运行 ，而人类则负责审查结果。
本文将解释：
- 我们如何创建 Symphony（它使得某些团队的 PR 合并数量增加了 500%）。
- 如何使用它来将你自己的问题跟踪器变成一个永远在线的智能体编排器。
交互式编码智能体的天花板
尽管编码智能体（通过 Web 应用或 CLI）变得日益易用，但它们本质上仍然是交互式工具。
随着 OpenAI 内部智能体工作规模的扩大，我们发现了一种新的负担：
- 每位工程师会打开几个 Codex 会话。
- 分配任务、审查输出、指导智能体，然后重复。
- 大多数人能同时舒适地管理 3 到 5 个会话。
- 超过这个数量，上下文切换 变得痛苦，生产力下降。
核心瓶颈： 智能体速度很快，但我们遇到了系统瓶颈------人类的注意力 。我们实际上是建立了一支由能力极强的"初级工程师"组成的团队，然后让人类工程师去对他们进行微观管理 。这种方式无法扩展。
视角的转变
我们意识到我们优化错了对象。
- 我们一直在围绕编码会话 和合并的 PR 来设计系统。
- 然而，PR 和会话只是达到目的的手段。
- 软件工作流本质上是围绕可交付成果 组织的：
问题、任务、工单、里程碑。
于是我们反问自己：
"如果我们不再直接监督智能体，而是让它们从任务跟踪器中拉取工作，会发生什么？"
这个想法演变成了 Symphony ：一个作为编排智能体工作主管角色 的书面规范。
将问题跟踪器转变为智能体编排器
Symphony 始于一个简单的概念 ：任何未完成的任务都应该被一个智能体接手并完成 。我们不再在多个标签页中管理 Codex 会话，而是将问题跟踪器变成了控制平面 。
核心运作机制：
- 一一映射 ：每一个未关闭的 Linear Issue 都会映射到一个专属的智能体工作空间。
- 持续监控 ：Symphony 持续监控任务看板，确保活跃任务始终有智能体在循环执行。
- 自动修复 ：如果某个智能体崩溃或卡住 ，Symphony 会自动重启它。
- 即时响应 ：如果出现新的工作 ，Symphony 会立即接手并开始组织执行。
我们的工作流基于工单状态 构建，将 Linear 用作一个状态机。
实践中的优势：
- 解耦工作 ：Symphony 将工作从
会话和Pull Request中解耦。一个 Issue 可能产生多个 PR，也可能只是纯粹的调研（不涉及代码库）。 - 更大粒度 ：工单可以代表更大粒度的工作单元。
复杂任务编排示例：
我们经常使用 Symphony 来编排复杂的功能开发和基础设施迁移。
- 制定计划：提交任务，要求智能体分析代码库、Slack 或 Notion，并生成实施计划。
- 任务分解 ：对计划满意后，智能体生成任务树 ，将工作分解为多个阶段，并定义依赖关系。
- 自动执行 ：智能体只处理未被阻塞 的任务，工作以自然且最优的方式并行展开 。
- 例如：将"React 升级"标记为被"迁移到 Vite"所阻塞。智能体果然在完成 Vite 迁移后才开始升级 React。
- 自我驱动 ：智能体可以自己创建工作，例如提交新的 Issue（性能问题、重构机会等），供我们评估和安排。
带来的改变：
- 降低认知成本 ：启动模糊任务的成本急剧下降 。即使智能体犯错，信息也有用，且成本近乎为零。
- 随时随地的协作 ：由于编排器永不休眠 ，我们可以从任何地方添加任务。
- 真实案例 ：一位工程师在 cozy 的小木屋里，通过糟糕的 wifi，仅用手机上的 Linear 应用就完成了三项重要的代码修改。
以这种方式工作带来的探索增长
最明显的变化是产出。
- 在 OpenAI 的某些团队中，合并的 PR 数量在前三周内增加了 500%。
- Linear 创始人指出，Symphony 发布时，创建工作空间的数量出现了激增。
更深层次的转变：
当工程师不再需要花时间监督 Codex 会话时，代码变更的经济性完全改变了。
- 感知成本下降：不再投入人力来驱动实施本身。
- 行为改变 ：启动探索性任务 变得轻而易举。尝试想法、探索重构、测试假设，然后只保留有希望的结果。
- 更广泛的参与 ：产品经理和设计师 现在可以直接提交功能请求。他们只需描述功能，就能收到包含功能视频演示的评审包。
在大型单体仓库中表现出色：
Symphony 能很好地处理"最后一公里"问题（CI、变基、冲突解决、重试不稳定检查）。当一个工单到达 "合并" 阶段时，我们非常有信心，无需人工照看，变更就能顺利进入主分支。
进步伴随着新的、不同的问题
权衡与取舍：
- 失去持续微调的能力：从交互式引导转变为工单级分配后，我们无法在任务进行中随时纠偏。
- 失败是有用的：智能体完全偏离目标的情况，揭示了系统不足，帮助我们使其更健壮。
我们的应对：
- 不再手动修补 结果，而是增加护栏 和技能（如端到端测试、Chrome DevTools 驱动、QA 冒烟测试）。
- 显著改进文档，明确"好的"标准。
并非所有任务都适合：
- 有些问题（模糊不清、需要强判断力和专业知识）仍然需要工程师直接与交互式 Codex 会话协同工作。
- 区别在于 ：Symphony 处理常规实现 ，让工程师能一次专注于一个难题。
重要的经验教训：
- 避免过度限制：将智能体视为状态机中的刚性节点效果不佳。模型比我们想象的要聪明。
- 给予目标而非规则 ：我们转向给智能体设定目标 ，就像经理给下属分配目标一样。提供工具和上下文，然后让它们自由发挥。
使用 Symphony 构建 Symphony
当你打开 Symphony 的代码仓库时，首先会注意到：
Symphony 在技术上只是一个
SPEC.md文件------即对问题和预期解决方案的定义。
我们没有构建复杂的监督系统，而是定义问题与方案，为智能体提供高层次的指导。（以下是规范片段示例）
markdown
1 # Symphony 服务规范
2
3 状态：草案 v1（语言无关）
4
5 目的：定义一个服务，该服务编排编码智能体以完成项目工作。
...（SPEC.md 的详细技术内容此处省略）
技术选型：
- 参考实现语言：Elixir 。因为当代码"免费"时，可以根据语言强项（如 Elixir 的并发能力）来选择。
- 迭代过程 ：
- 第一个版本：一个在
tmux中运行的 Codex 会话，轮询 Linear 并生成子智能体（奏效但不可靠）。 - 第二个版本：位于主项目仓库中，连接智能体"驾驭"平台。
- 自举 ：一旦基本功能就绪，我们就使用 Symphony 来构建 Symphony。
- 第一个版本：一个在
- 打磨规范 ：用 TypeScript、Go、Rust、Java、Python 等多种语言实现，以识别歧义并简化系统。每种语言都成功了！
消除复杂性：
通过构建 Symphony，我们消除了很多偶然的复杂性（如对特定代码仓库或 Linear MCP 的依赖）。核心方法变得简单：
对于每一个未关闭的任务，都确保有一个智能体在其独立工作空间中运行。
关键创新：
- 文档化工作流 ：开发工作流（处理 Issue、检出仓库、更新状态、添加 PR、移至评审、附加视频等）现在都捕获在
WORKFLOW.md文件中。Symphony 确保智能体遵循它。 - 使用 Codex App Server ：Codex 内置的无头模式 ，允许通过 JSON-RPC API 以编程方式交互。比 CLI 或 tmux 会话更方便、更易扩展。
- 动态工具调用 ：例如，通过暴露
linear_graphql函数执行对 Linear 的请求，而无需暴露访问令牌。
下一步计划
Symphony 是一个有意为之的、最小化的编排层。
- 定位 ：不是独立产品 ，而是一个参考实现。
- 目的：展示 Codex App Server 与 Linear 等不同工作流工具结合时的强大能力。
- 期望 ：希望你将你最喜欢的编码智能体指向 Symphony 规范和相关仓库，以构建适合你自己环境的版本。
核心力量来源：
Codex 及其应用服务器。Symphony 是一种连接 Codex 与 Linear 的方法，用以解决工作管理问题。
未来展望：
随着编码智能体变得更好，其他公司的瓶颈也将从编写代码 转向管理智能体工作 。好消息是，尝试这些系统的门槛已经低得惊人。
你可以直接用 Codex 来构建东西。