本文编译自 《An open-source spec for Codex orchestration: Symphony》
Symphony 要解决的人类监督成本问题
过去一年，大家对 coding agent 的讨论，大多还停留在它能不能把一个任务做完。但 OpenAI 在这篇文章里提出了一个更现实的问题：当 agent 已经足够能干之后，真正的瓶颈开始变成人类自己的注意力。
团队里的工程师可以同时开几个 Codex 会话，给任务、看结果、修方向、继续追问。问题在于，这种工作方式本质上仍然是交互式的。一个人也许能稳定管理 3 到 5 个会话，再往上，系统的吞吐量主要受限于人类频繁切换上下文的成本。
OpenAI 的结论很直接：如果工程师的大量时间都花在盯着 agent 干活，这套系统就没有真正释放生产力，只是把管理对象从人类初级工程师换成了 AI 工程师。
从管理会话转向管理任务
Symphony 的核心思想并不复杂，但非常关键：
不要围绕会话和 PR 来组织 agent，而要围绕 issue、ticket、milestone 这些真正的交付单元来组织。
也就是说，团队不再直接管理一堆 Codex 对话窗口，而是把任务系统本身变成控制平面。只要某个任务处于开放状态，就应该有一个 agent 在对应 workspace 里持续推进它；如果任务被阻塞、依赖未满足，agent 就等待；如果任务恢复可执行，agent 就继续。
这意味着工作被重新抽象成了一个更稳定的对象：
- 会话可以中断、重启、迁移
- PR 可以是一个，也可以是多个
- 某些任务甚至只需要调研和分析，不一定产生代码
任务始终是核心对象。Symphony 围绕任务协调 agent 的生命周期。
把 issue tracker 变成 agent orchestrator
OpenAI 在内部的做法，是让 Symphony 持续观察类似 Linear 这样的任务看板。每一个开放任务，都映射到一个独立的 agent workspace；每一个 workspace，都运行着一个长期存在、可恢复、可重试的 agent 循环。
这种方式有几个非常重要的变化。
1. agent 按依赖关系并行工作
文章里提到，复杂功能可以先让 agent 产出实现计划，再由 agent 自己把工作拆成一棵任务树，并标注依赖关系。随后 Symphony 只会让那些不再被阻塞的任务启动执行。
这说明并行性主要来自任务图本身，而不是人工手动协调。
比如 React 升级依赖于先完成 Vite 迁移，那么只有当迁移任务完成后，相关 agent 才会启动。对大型代码库来说，这种基于 DAG 的调度比同时开多个会话更可靠。
2. agent 不只是执行者，也会主动创建后续工作
Symphony 里一个很有价值的点，是 agent 在实现过程中发现新问题时，不一定当场扩 scope，而是可以直接创建新的 issue，交给系统后续评估和排期。
这使得 agent 的角色从被动接收指令，扩展到参与维护工作队列。一些性能优化、架构清理、重构机会，原本很容易在开发过程中被忽略，现在可以沉淀成结构化待办。
3. 低成本试错成为可能
当发起一个探索性任务几乎不消耗人工监督成本时，团队对先做试验的容忍度会明显提高。文章里提到，他们可以让 agent 去做原型、验证假设、做一次重构尝试，不满意就直接丢弃结果。
这主要来自工作流成本下降。
为什么 Symphony 会带来 500% 的 PR 增长
OpenAI 在文中给出的一个非常醒目的数字是：部分团队在前三周内，落地 PR 数量提升了 500%。
如果只把这个结果理解成 agent 写代码更快，很容易抓错重点。更重要的原因是，Symphony 改变了团队对于变更成本的感知。
在传统交互模式下，每做一个改动，都意味着要有人持续推动 session 前进；在 Symphony 模式下，工程师主要管理目标、约束和验收，而不是具体操作步骤。于是：
- 更小、更碎的任务也值得被提出和执行
- 产品经理、设计师也能直接提交需求，而不必亲自进入代码库
- 大型 monorepo 中那些容易卡在 CI、rebase、冲突解决上的收尾工作，可以被系统持续托管
文章提到，当任务进入 Merging 状态时，团队已经对变更是否能够顺利进入主干有了相当高的把握。因为在这之前，系统已经持续观察 CI、自动重试、处理 rebase 和冲突，尽可能降低人工介入。
这套方法并不意味着交互式 agent 过时了
OpenAI 并没有把 Symphony 描述成万能方案。相反，文章非常明确地承认：有些任务仍然更适合由工程师直接和交互式 Codex 会话配合完成。
尤其是下面这几类工作，依然需要高密度的人类判断：
- 需求本身还很模糊
- 技术路线存在较强不确定性
- 涉及跨团队权衡、架构裁剪或复杂取舍
- 成功标准很难被预先写清楚
Symphony 适合处理大量常规实现工作，从而把工程师从频繁切小任务的状态里解放出来，让人类把注意力集中在真正困难、真正需要经验判断的问题上。
这也是一个很重要的工程管理视角：并不是所有事情都应该 agent 化，但可流程化的部分应该尽量流程化。
从状态机思维转向目标委托
文章里还有一个值得单独说明的转变：OpenAI 早期曾试图把 agent 当成严格状态机里的节点，只让它做很窄的任务，比如实现某个 issue。后来他们发现这太保守了。
原因很简单，模型能力是会变化的。今天只能做单点实现的 agent，明天也许已经能：
- 自己创建多个 PR
- 读取 review feedback 并继续修改
- 分析 CI 日志
- 关闭过时分支或产出工作统计报表
于是他们逐渐从严格状态转移转向面向目标的委托：给清晰目标、边界条件、可用工具和足够上下文，然后让执行者自己完成路径规划。
这可以视为 Symphony 的方法论核心：模型最有价值的地方不在于服从固定流程，而在于基于清晰目标进行推理和自组织。
Symphony 本身几乎只是一个 SPEC.md
Symphony 有一个很明显的特点：它不是一个庞大复杂的平台。OpenAI 把它开源出来时，核心首先是一个 SPEC.md，也就是一份对问题定义、系统边界和行为预期的说明书。
这背后传递出两个信号。
第一，很多所谓 agent orchestration 问题，真正缺少的是一份清晰、稳定、机器也能执行的人类工作规范。
第二，当代码生成成本大幅下降后，规范本身的重要性正在上升。因为真正困难的事情，越来越集中在问题定义、流程约束和系统接口上。
OpenAI 甚至用 Codex 去把 Symphony 规范实现成多个不同语言版本，包括 TypeScript、Go、Rust、Java 和 Python，再反过来用这些实现暴露规范中的歧义，继续精炼 spec。这是一个典型的 agent-native 开发流程：实现同时也是验证规范的方法。
Codex App Server 是这套体系真正的基础设施
如果说 Symphony 解决的是调度和组织问题，那么支撑它落地的底层设施，实际上是 Codex App Server。
OpenAI 在文中解释，App Server 提供了一个可编程的、无头运行的 Codex 形态，外部系统可以通过 JSON-RPC 接口去创建线程、接收 turn 更新、对会话进行编排。这比直接驱动 CLI、tmux 会话或者伪造人工交互可靠得多，也更适合长期运行服务。
这里最有工程价值的一点是：Symphony 把 Codex 放进了一个可观察、可调度、可插入组织规则的运行时。
例如文中提到，为了不把 Linear token 暴露给子 agent，他们会通过 dynamic tool calls 暴露一个受控的 linear_graphql 能力，而不是直接把完整访问权交给容器。这说明一旦 agent 真正进入生产工作流，权限边界、工具抽象和审计能力都会比模型效果演示更加重要。
对团队的真正启发是什么
Symphony 更值得关注的是它所代表的组织方式变化：
- coding agent 的下一阶段会减少人工调度
- 任务系统会逐渐变成 agent 的控制平面，而不只是人类项目管理工具
WORKFLOW.md、SPEC.md这类可执行文档，会成为 agent-native 软件团队的重要资产- 工程团队的竞争力，会越来越取决于是否能把隐性流程显式化、把经验规则制度化
Symphony 关注的问题是：
当一个团队同时拥有几十个持续在线的 coding agents 时，应该如何组织它们的工作？
这正是未来一两年里，大多数高强度使用 AI 编程团队迟早都会碰到的问题。
写在最后
OpenAI 对 Symphony 的定位很克制：它不是一个准备长期维护的独立产品，更接近一份参考实现和开放规范。真正的能力核心仍然在 Codex 与其 App Server，Symphony 展示的是如何把这些能力接到现实世界的任务流、协作流和交付流里。
对开发者来说，这篇文章更有启发性的地方，在于重新审视自己的团队工作流：
- 哪些步骤已经足够标准化，可以交给 agent 持续执行？
- 哪些知识还停留在口耳相传，没有沉淀为
WORKFLOW.md？ - 哪些项目管理动作，实际上可以由 agent 代为完成？
当这些问题开始被认真对待时，agent 才会真正从辅助工具升级为持续运转的工程系统组成部分。