OpenAI Symphony：Coding Agent的未来是任务队列而非聊天框

当你同时开三个Agent窗口，瓶颈不是AI，而是你

如果你已经在同时使用Codex、Claude Code或Copilot Agent做开发，大概率会遇到一个微妙的问题——不是Agent不够快，而是你开始管不过来了。这个窗口在改前端，那个窗口在跑测试，第三个窗口还在查历史bug。刚开始很爽，但开到三四个以后，人就开始忘：哪个跑完了，哪个卡住了，哪个需要确认，哪个刚才说要重试。

OpenAI在介绍Symphony的工程博客里，直接点出了这个现实瓶颈：交互才是Coding Agent的天花板，不是模型能力，而是人的注意力。 博客提到，大多数人同时管理三到五个会话之后，上下文切换就开始变得痛苦。你在终端之间来回跳，提醒Agent别跑偏，检查它是不是卡住了。最后发现，Agent很快，但人变成了瓶颈。

这就是OpenAI开源Symphony的背景。据其工程博客披露，在一些内部团队中，使用Symphony后前三周合并的PR数量增长约500%。当然，这是OpenAI对自己团队实践的公开分享，不是第三方评测结论。但这个数字背后的结构变化才是真正值得关注的：当Agent真能持续干活，团队就必须重新设计任务怎么派发、状态怎么追踪、结果怎么验收。

Symphony是什么：从聊天窗口到任务队列

更准确地说，Symphony不是一个模型，也不是IDE插件，而是一套面向Coding Agent的编排规范和参考实现。中文里可以叫它"任务编排器"或"Agent工作调度台"。

它做的事情是：持续读取任务系统里的issue，把符合条件的任务派发给Agent，并用Workspace、状态机和日志把执行过程管理起来。人的注意力不再花在盯每个会话上，而是放在任务定义、状态流转、证据审查和验收决策上。

主语从"会话"变成"任务"

我们平时用Agent，默认主语是"会话"——你开一个窗口，给它一个任务，然后盯着它输出。任务多了就开更多窗口。问题是，会话不是一个好的工作管理单位。一个真实任务可能需要多个PR，可能跨几个仓库，也可能只是调查报告，最后根本不改代码。

Symphony的思路是把主语换成任务。GitHub仓库里的spec.md给了工程化描述：为每个任务创建独立Workspace，并在这个Workspace里运行Coding Agent Session。换句话说，不是"我开了一个Agent所以它要干点什么"，而是"这里有一个明确任务，所以系统要保证Agent围绕它推进"。

这个差异很大。任务有标题、描述、状态、依赖关系、优先级、验收标准。Workspace有独立路径和生命周期。Agent只是被调度进去执行的一次运行。工作不再散落在一堆聊天窗口里，而是回到团队本来就能管理的任务系统里。

状态机即控制逻辑

GitHub仓库里的Linear参考实现包含一个workflow.md，相当于团队写给Agent和调度器看的工作流契约。它把任务状态定义为一套流转：

Todo → In Progress → Human Review → Rework → Merging → Done

表面看这只是看板列名，但在Symphony里，状态就是控制逻辑：

• Todo：系统可以把它拉到In Progress并启动Agent
• In Progress：Agent正在执行
• Human Review：PR已附上并验证过，等人审核
• Rework：Reviewer要求修改
• Merging：开始走合并流程
• Done/Closed/Canceled：停止运行并清理Workspace

Symphony不是让人彻底退出，而是把人从"每几分钟盯一次窗口"的热路径里挪出来。人类真正该做的是定义任务、确认验收标准、处理Review、批准合并——从manage agent变成manage work。

Proof of Work：不是"做完了"，而是"能证明做完了"

GitHub仓库README把Agent交付结果时需要提供的东西称为Proof of Work（工作证据）。列出的例子包括：CI状态、PR Review Feedback、复杂度分析和Walkthrough Videos。

这个设计特别重要。团队真正需要的不是一句"我完成了"，而是"我能证明我完成了"。简化来说，就是一个交付证据包：

• 改了什么？为什么这么改？
• 跑了哪些测试？结果如何？
• 截图或录屏在哪里？
• 还有哪些已知风险？
• 如果出问题怎么回滚？

只要这一步没有固化，多个Agent并行就很容易变成"好几个黑盒同时产出一堆你不敢合的东西"。这也是为什么Human Review这个状态不能省——Agent可以把活推进到可审查状态，但最后是否合并、是否发布、是否扩大权限，仍然要有明确的人工门禁。

前提条件：没有工程基础，多开Agent只会放大混乱

Symphony的README明确写了，它是一个面向Trusted Environments的Engineering Preview——更像一份架构样例，不是下载下来就能无脑放进生产的商业产品。

如果你的仓库没有清晰测试、没有任务验收标准、没有权限边界、没有工作区隔离、也没有回滚习惯，那同时开更多Agent只会把混乱放大。以前是一个人一个窗口乱，现在会变成十个Workspace一起乱。

Symphony的前提其实是Hardened Engineering：仓库要适合Agent工作，任务要可拆解，验证要自动化，状态要可追踪，失败要能恢复。没有这些基础，所谓全自动只是在更快地产生不确定性。

普通团队的五步落地路径

普通团队最该学的不是马上照搬OpenAI的架构，而是先做一个"小号Symphony"：

第一步：把任务板变成真正的控制平面。 每个任务至少要有状态、负责人、验收标准和依赖关系。

第二步：给Agent一份仓库内的工作流契约。 可以不叫workflow.md，但要写清楚：拿到任务后先看什么，什么时候能改代码，什么时候必须跑测试，什么时候进入人工审核，什么情况要停止。

第三步：每个任务用独立工作区。 尤其是多Agent并行时，物理隔离非常重要。否则很难看到某个改动到底谁引入的，也很难安全回滚。

第四步：强制交付证据包。 测试结果、截图、录屏、变更摘要、风险说明、回滚方式，至少要有其中几类。你可以不自动合并，但不能接受没有证据的"做完了"。

第五步：逐步扩大任务粒度。 先让Agent做小修、小调查、小重构，等状态流转、证据提交和审核验收都跑顺了，再让它处理跨文件、跨模块、跨仓库的复杂任务。

结语：下一阶段拼的是工作流，不是窗口数

Symphony真正提示我们的是：AI原生工作台的主界面，可能不是聊天框，而是任务、状态、证据和验收。

当Agent还不太能干时，聊天框很好，因为人要随时纠偏。但当Agent真的开始能连续工作，聊天框反而会变成瓶颈。下一阶段拼的不是谁多开几个窗口，而是谁能把Agent放进一条可追踪、可验证、可恢复的工作流里。

从"对话驱动"到"任务驱动"，这不只是交互范式的变化，更是软件工程组织方式的一次根本性重构。