OpenAI Symphony 解读：用 Issue Tracker 重新定义 Agent 编排
OpenAI 一位工程师坐在网络很差的小木屋里，打开 Linear 手机 App，提了 3 个 issue，然后关掉手机休息。等他回到城市，这 3 个 issue 对应的 PR 已经跑完 CI、进入 review 队列。全程没打开过终端。
这件事背后的系统叫 Symphony。
OpenAI 工程团队在 2026 年 3 月开源了 Symphony，并附带了一份 SPEC.md。它不是一个产品，是一套工作方式的规范化，以及把这套工作方式交给 Agent 执行的尝试。发布 3 周后 GitHub stars 超过 15K，Linear 创始人 Karri Saarinen 在 X 上专门指出这段时间 workspace 创建量出现了明显峰值。
多线程的 Codex 会话管理有什么问题
Symphony 团队此前有一个激进的设定：整个代码库不能有人写的代码，所有实现都由 Codex 生成。他们把这套工程基础设施整理成了 Harness Engineering 博客，算是把"让 Codex 当队友"的方法论化了一遍。
跑通之后，新问题随之浮现。Agent 承担的任务越来越多，工程师开始同时管着好几个 Codex 会话，分配任务、查看结果、纠正方向、再分配。这个循环能跑起来，但有上限，大多数人同时盯 3 到 5 个会话就到头了。再往上，Codex 跟得上，但工程师自己在会话之间跳来跳去，搞不清哪个在做什么，长时间任务卡住了也发现不了。
他们自己总结这段经历时说：相当于招了一批能干的助手，然后让人类工程师去全程盯着这批助手干活。这种模式没法推广。
工作单元是 issue，不是会话
重新想一下工程师的工作单元，其实不是"这个 Codex 会话"，而是"这个 issue"。PR 是产物，会话是过程，issue 才是事情本身。大多数工程工作流围绕 issue、task、ticket 组织，而不是围绕编辑器会话。
Symphony 的核心转换就在这里，把 Agent 和 issue 绑定，而不是和会话绑定。
具体做法是把 Linear 的 issue tracker 当成编排层。每个活跃 issue，Symphony 都给它启动一个对应的 Agent workspace，持续运行，直到任务完成或状态改变。Issue 状态变成终态（Done、Cancelled 等），对应 workspace 就结束。新 issue 进来，自动分配一个 Agent。
很多团队已经有一个 issue tracker，里面的 ticket 天然是优先级排序好的工作单元，有状态机，有负责人，有截止日期。把它接进来比从零设计调度系统便宜得多，而且团队已经在用。编排层不一定要自己建。
这套设计目标很简单：
对每个 open task，确保有一个 Agent 在它自己的 workspace 里运行。
这个机制带来一个额外变化：issue 变成了更大的工作单元。有的 issue 会产生多个 PR，跨多个代码仓库；有的 issue 只是调研，没有代码改动。PR 是产物之一，不再是终点。Agent 也会在实现过程中主动创建新 issue，遇到值得单独处理的问题就提出来进 backlog，后续可能还是由 Agent 处理。
这套机制还支持任务依赖。复杂功能可以先让 Agent 分析代码库、制定实施计划，再把计划拆成有依赖关系的子任务树。Agent 只处理当前没有前置阻塞的任务，依赖完成后自动接着跑。比如把 React 升级标记为"依赖 Vite 迁移"，Agent 会等 Vite 跑完再启动 React 的部分，不需要人来排序。
SPEC.md：规范即产品
打开 Symphony 的仓库，主体是一个 SPEC.md，两千多行，从编排状态机到 workspace 安全边界都写清楚了。参考实现用 Elixir 写，但 SPEC 本身是语言无关的。
他们用 Codex 把同一份 SPEC 在 TypeScript、Go、Rust、Java、Python 各实现了一遍，每次的目的是找规范里的歧义和模糊之处，然后把 SPEC 改得更精确。Elixir 实现是参考实现，不是唯一的实现。规范的质量可以从它被准确实现的程度来判断。TCP/IP 没有 "开源" ，全世界的网络设备都在按它运行；HTTP/1.1 的 RFC 是一个规范，它写得足够精确，所以浏览器、服务器、CDN 都在遵循这个规范。Symphony 用 5 种语言实现同一份 SPEC，其实是在做同一件事：把规范丢给不同的执行者，看会不会走样。
当代码生成的成本足够低，选 Elixir 做并发编排是一种合理的技术选择。Elixir 在并发进程管理上有天然优势，正好适合编排大量并发的 Agent 会话。变化在于：代码生成成本趋近于零之后，技术选型的逻辑也跟着变了，不再根据"谁能实现"来选语言，而是根据"谁最擅长这个场景"来选。
Symphony 发布时，GitHub 上 15K stars 大多是给 SPEC.md 的，而不是那些参考实现。这很有意思，代码是 Elixir 写的，但是关注点却不在语言本身。
当规范比代码更核心，要怎么定义 "开源" ？代码开源，意思是任何人可以 fork、修改、提交 PR。规范开源呢？fork 一份 SPEC.md 然后改，算不算贡献？如果有人给 TCP 协议提了一个新 RFC，那算不算开源社区的贡献？Symphony 的 LICENSE 是 Apache 2.0，SPEC.md 在仓库中，它的演进不像代码那样清晰，没有明确的正确性。规范怎么接受社区贡献，现在还没有好的答案。
SPEC 之外还有一个 WORKFLOW.md，放在各团队的代码仓库里，由团队自己维护。它描述的是团队的开发流程：新建分支、更新 issue 状态、提 PR、移到 Review 状态、附上演示视频…… 这些操作很多团队一直在做，但从来没有文档。Symphony 要求把它写下来，Agent 才能照着执行。
这个要求本身有一个意外效果，工程团队的很多隐性流程，以前靠经验传递，或者靠 review 反馈才能发现。显性化之后，新来的人看 WORKFLOW.md 就能懂，Agent 看也能懂。文档维护不再只靠自律，是强制的要求。
PR 涨了 500%，然后呢
Symphony 上线后，部分 OpenAI 团队在前 3 周落地的 PR 数量增加了 500%。
把任务交给 Agent 的成本压到极低之后，探索性的工作开始容易启动了。试一个重构方案，验证一个假设，探索一条可能不值得的优化路径，这些以前因为人力成本不合算而直接跳过的事，现在可以当成 issue 提出来，让 Agent 去探索，结果不好就关掉，有价值再认真做。
发起工作也不再是工程师的专属动作了。PM 和设计师可以直接在 Symphony 里提 issue，不需要访问代码仓库，不需要管 Codex 会话。提完之后，他们拿到的不是代码差异，而是一个演示视频，展示功能在真实产品里跑起来的样子。
Symphony 在大型 monorepo 里还承担了另一类工作：CI 的最后一公里。PR 提出去之后，等待 CI、rebase、解决冲突、重试 flaky 测试，这些环节往往需要人持续跟进。Symphony 把这些接管了，等 ticket 到了 Merging 状态，基本不需要人再盯着。
规模大了，问题也在变
从交互式会话切换到 ticket 级分配，有一样东西随之消失：运行过程中随时调整方向的能力。以前发现 Agent 跑偏，可以直接在会话里插一句话。现在 Agent 在自己的 workspace 里持续运行，等你发现结果走样了，这一轮往往已经结束。
Openai 的团队没有绕回来手动 patch，而是回过头修工具和文档。在 Agent 跑偏的地方加 guardrail，补端到端测试，让 Agent 下次自己能发现问题。Chrome DevTools 操作 UI、QA smoke test，这些能力都是 Agent 多次失败之后加进来的。
Symphony 能接管的是大量常规实现工作，边界不明确的问题、需要深度判断的工作，仍然要工程师直接开 Codex 会话。把这些常规工作交给 Agent，工程师才能集中在一个真正难的问题上，而不是在一堆小任务之间来回切换。
状态机限制了 Codex 的能力
Symphony 早期的设计把 Agent 当成严格的状态转移节点：收到 issue、实现代码，提 PR，然后结束。这套流程的问题是低估了 Codex 实际能做的范围。
Codex 可以读 review 评论、响应 CI 失败、关掉旧 PR、生成覆盖多个仓库的改动。把它限制在"只做实现"，等于给了一个会开车的人一张只写了"从 A 到 B"的便条，然后不让他绕过施工路段。
他们后来的做法是给 Agent 目标而不是操作序列，就像给一个新工程师说"把这个 issue 解决掉"，而不是"做以下三步操作"。模型有推理能力，给上下文和工具，让它自己决定路径。
WORKFLOW.md 在这里的角色也变了，它是流程边界的描述，不是操作手册，说明什么是正常流程里的动作，什么是需要等待人工确认的节点。Agent 在边界内自己选路径，人在边界节点做决策。
Codex App Server：程序驱动 Agent
Symphony 的底层接口是 Codex 的 App Server 模式，这是 Codex 的一个 headless 运行方式，通过 JSON-RPC API 来交互，能用程序操作 thread、切换 turn，而不是靠 CLI 或者在 tmux 会话里发消息。
Symphony 用这个接口启动 Agent、接收状态事件、控制并发，没有额外的进程管理复杂度。Line-delimited JSON 从 stdout 流出，Symphony 的调度进程处理每条事件，Agent 崩溃可以重启，会话超时可以重试，这些都是可以通过程序控制的行为，不需要人盯着，是另一种层次的 harness。
运行机制之外，安全边界也值得单独说。Symphony 需要读写 Linear，但不能把 Linear 的 access token 暴露给子 Agent。解决方式是用 Codex 的动态工具调用接口，在编排层实现一个 linear_graphql 工具，子 Agent 可以调用这个工具来操作 Linear，但拿不到底层的 token。
Symphony 是怎么演进过来的
Symphony 不是一天建成的。第一个版本就是一个跑在 tmux 里的 Codex 会话，轮询 Linear，有新任务就启动子 Agent。能用，但不太可靠。
第二个版本把这个逻辑集成到了 OpenAI 内部的主项目里（这个项目本来就是用 Agent 建的，已经有了完整的 Agent 工具链和上下文，所以 Symphony 只是把已有的东西串起来）。
有了可用的版本之后，团队用 Symphony 来构建 Symphony 本身。这个内部演示反响很好，其他团队也开始自发用起来。看到这样的内部使用率，团队决定把它开源出来。
于是他们把核心概念提取成一份独立的 SPEC.md，让 Codex 按规范实现。参考实现选 Elixir，因为它的并发模型很适合编排大量并发的 Agent 会话。
两个实现方式：编排层外置 vs 内置
Symphony 的做法是把 Linear 当编排层，issue 是状态机，workspace 是执行单元。这个选择很实际：团队已经在用 Linear，不需要再维护一套新工具。
前不久出现的另一个项目 Multica，走的是另一条路。它不依赖外部工具，自己造了一套平台：Agent 有身份档案、有看板、能实时推送进度，实际是一个专为 Agent 工作流设计的"Linear + CI"。
Symphony 的逻辑是编排层外置：用团队已有的工具，只在编排层做调度。好处是迁移成本低，坏处是受限于宿主平台的能力。Multica 的逻辑是编排层内置：把整个 Agent 工作流封装成一个独立产品。好处是完全可控，坏处是需要从零建立团队的使用习惯。
两个方案回答的是同一个问题：Agent 和团队的关系应该是什么？
工具视角下，Agent 是高级助手，人分配任务、审核结果、维持质量。成员视角下，Agent 是团队的一员，有自己的上下文、可以主动提 issue、可以在 review 里发表评论。前者是人指挥 Agent，后者是 Agent 在团队里有自己的位置。这两种视角的差别在于：Agent 是替代人的工具，还是团队里的一个成员。
Symphony 的线性设计倾向于前者，Multica 倾向于后者。但两者都在解决同一个核心问题：怎么让 Agent 的工作真正融入团队的工作流，而不是在团队外面单独跑一堆会话。
软件工程进入"内燃机时代"
Symphony 带来的 PR 增量是 500%，数字并非重点。重点是背后的变化：发起工作不再需要工程师亲自上手，Agent 可以直接参与团队的工作流，PM 和设计师可以跳过工程师直接提需求。
这意味着什么？软件工程的生产力范式正在从人力密集转向 Agent 密集。就像工业革命换掉了动力来源，而不是让马跑得更快；现在不是让工程师写代码更快，是把执行层外包给 Agent。
一开始 Agent 只用来"让工程师的日常工作更快"，从自动补全代码、自动写测试到自动生成代码。后来 Agent 开始承担完整的工作单元，issue 可以直接变成 PR，提需求可以直接看到演示。这个循环跑通之后，不只是效率变了，谁在发起工作、谁在做决策、谁来负责结果，都变了。
工程师的位置在哪里
Symphony 团队说过一句话，大意是：Symphony 能接管大量常规实现工作，但边界不明确的问题、需要深度判断的工作，仍然要工程师直接开 Codex 会话。
所以他们的做法是回头修工具和文档，在 Agent 跑偏的地方加 guardrail、补端到端测试，让 Agent 下次自己能发现问题。
这个模式说得很清楚：人从执行者变成了系统设计者。
人不再做 code review，而是设计让 Agent 能自己做 code review 的系统。人不再盯着 CI 重试，而是设计让 Agent 能自己处理 CI 失败的工作流。人的位置从"做"变成了"让 Agent 知道怎么做"。
这不是一个简单的角色转换。以前靠技术判断吃饭，以后可能要靠流程建模、边界设计、异常处理。
但这里有一个问题：系统设计的能力不是所有工程师都有的，甚至不是工作年限能直接换来的。Agent 时代的到来，不只是替代一批劳动力，对工程师的能力模型也提出了新的要求。
最后
Symphony 探索的是当下的工程问题，但它指向的是一个更大的问题，工具正在重新定义工作的边界。
Linear、Notion、Jira，这些会不会变成 Agent 时代的 "操作系统"？这个问题目前没有答案，但可以确定的是，当 Agent 能独立完成 issue，当规范可以像代码一样作为有效开源，工程师的定义也会跟着改变。
时代在加速变化，新的工作范式正在被探索，很多旧的定义正在被更新，这是一个最好的时代，也是一个最坏的时代，你准备好了吗？