OpenAI 最近开源了一个叫 Symphony 的项目。
表面上看是个工程工具，但它背后折射出的工作方式变化。
从一个激进的实验说起
六个月前，OpenAI 内部一个团队做了个当时看起来很激进的决定：仓库里不允许有任何人类写的代码。
每一行，都必须由 Codex 生成。
Codex 是 OpenAI 的 AI 编程助手，可以理解需求、读懂代码库、自主完成编程任务。
他们重新设计了整个工程流程，大量投入自动化测试和防护机制，把 Codex 当成真正的团队成员。
他们把这套方法叫做"harness engineering"（脚手架工程），并专门写了一篇博客记录这段历程。
结果确实跑通了。
但随即撞上了下一个瓶颈：上下文切换。
真正的瓶颈是人的注意力
每个工程师同时开几个 Codex 会话，分配任务，审查输出，调整方向，循环往复。
实际操作下来，大多数人同时管理三到五个会话还算舒适，超过这个数字，效率就开始下降。
忘了哪个会话在做什么，在几个终端之间来回跳，调试卡在一半的长任务……
AI 跑得很快，但系统的瓶颈是人的注意力。
他们意识到，自己其实是雇了一批极其能干的初级工程师，然后让人类工程师去微观管理他们。
这显然没法规模化。
换一个视角
问题出在思路上。
他们一直在优化"编程会话"和"合并 PR"，但这些只是手段。
PR（Pull Request）：工程师完成一段代码后，向主代码库提交合并请求，等待审查和合入。
软件开发真正围绕的是可交付物：issues（问题单）、任务、里程碑。
所以他们问了自己一个问题：如果不直接监督 AI，而是让 AI 自己从任务追踪系统里拉取工作，会怎样？
这个想法变成了 Symphony。
Symphony 是什么
一句话：把项目管理看板变成 AI 编码代理的控制中枢。
他们用的是 Linear，一款工程团队常用的任务管理工具。
每一个打开的任务，都会自动分配一个 AI 代理。
代理持续运行，直到任务完成。人类只需要审查结果。
具体来说，每个 Linear issue 对应一个独立的Agent工作空间。
Symphony 持续监视任务看板，确保每个活跃任务都有Agent在跑。
Agent崩溃了，自动重启；有新任务进来，自动接手。
整个工作流用 Linear 的状态来驱动，像一台状态机：
Todo（待办）→ In Progress（进行中）→ Human Review（人工审查）→ Done（完成）AI 代理在这些状态之间流转，人类在"Human Review"节点介入。
几个让人印象深刻的细节
任务粒度可以很大
不再局限于"改一个函数"这种小粒度。
可以让代理先分析整个代码库、Slack 记录或 Notion 文档，产出实现方案，再自动拆解成一棵任务树，按依赖关系并行执行。
他们用了一个词叫 DAG（有向无环图，Directed Acyclic Graph），本质就是一张"哪些任务依赖哪些任务"的执行顺序图，确保代理不会乱序执行。
比如他们做过一个真实案例：先完成从 Webpack 到 Vite 的迁移，再升级 React。
Agent自己识别了这个依赖关系，等 Vite 迁移完成后才开始升级 React，完全符合预期。
代理会自己创建任务
在实现过程中，Agent如果发现了性能问题、重构机会或者更好的架构方案，会直接在 Linear 里开新 ticket，供人类评估和排期。
很多后续任务也会被代理接手执行。
从手机上也能工作
因为编排器跑在开发服务器（devbox）上，从不睡觉，有个工程师在信号很差的小屋里，用手机 Linear App 提了三个重要改动，Agent照样接手执行了。
数据很直接
部分团队在前三周，合并的 PR 数量增长了 500%。
Linear 创始人 Karri Saarinen 也公开提到，Symphony 发布后，Linear 上新建工作区的数量出现了明显峰值。
它的核心是一个 Markdown 文件
这是 Symphony 最有意思的设计决策之一。
打开 Symphony 的代码仓库，会发现它本质上就是一个 SPEC.md，一份对问题和解决方案的定义文档，而不是一个复杂的监控系统。
他们定义好问题，给出高层次的指引，然后把这份规范扔给 Codex，让 Codex 来实现它。
参考实现选了 Elixir，一门相对小众的编程语言，但在并发（同时处理大量任务）和进程监督方面有非常好的原语（基础构建块）。
选它的理由也很直接：当代码成本趋近于零，终于可以为了语言的优势本身来选语言，而不是为了招人方便。
Codex 一次性就把 Elixir 实现写出来了。
为了打磨规范本身，他们又让 Codex 用 TypeScript、Go、Rust、Java、Python 各实现了一遍，用这些实现来发现规范里的歧义和可以简化的地方。
每种语言都成功了。
工作流也被文档化了
这里有个值得单独说的转变。
以前，工程师们有一套隐性的工作流程：接到任务，切出分支，把任务标记为进行中，提 PR，移到 Review 状态，附上演示视频……这些步骤人人都懂，但从来没有被正式写下来。
现在，这套流程被写进了 WORKFLOW.md，Symphony 确保 AI 代理遵循它。
以前是人类遵循隐性规范，现在是把规范显式化，让 AI 来遵循。
这个文件还有一个重要特性：热重载。
修改 WORKFLOW.md 后，Symphony 会自动检测变化，无需重启，直接把新配置应用到后续任务上。
如果以后想让代理在完成工作后附上自我反思，只需要在 WORKFLOW.md 里加一行，Symphony 就会引导Agent执行这一步。
Symphony 的技术架构（不想看可以跳过）
Symphony 的内部由几个核心组件构成，理解它们有助于明白整个系统为什么可靠：
Orchestrator（编排器）：整个系统的大脑，唯一有权修改调度状态的组件。
它负责轮询任务、决定哪些任务该启动、重试或停止，并追踪所有正在运行的代理状态。
Workspace Manager（工作空间管理器）：每个任务都有自己独立的文件目录，Agent 只能在自己的目录里操作，不会互相干扰。这是一个重要的安全边界。
Agent Runner（执行器）：负责启动 Codex 进程，把任务提示词传给它，然后把执行结果反馈给编排器。
Issue Tracker Client（任务追踪客户端）：负责和 Linear 通信，拉取任务列表，同步状态变化。
整个系统的并发控制也很细致，可以设置全局最大并发代理数（默认 10 个），也可以针对特定状态的任务单独限制并发数。
重试机制用的是指数退避（exponential backoff）：第一次失败等 10 秒，第二次等 20 秒，第三次等 40 秒，以此类推，最长不超过 5 分钟。
正常完成后的续跑检查只等 1 秒。
一个重要的架构选择：App Server 模式
Symphony 使用了 Codex 的 App Server 模式，一种内置的无头（headless）运行模式。
无头（headless）：没有图形界面，完全通过程序接口控制，适合自动化场景。
这种模式通过 JSON-RPC（一种轻量级的远程调用协议，用 JSON 格式传递指令和结果）以编程方式控制 Codex，比如启动一个对话线程、触发一个执行轮次、读取执行结果。
比通过 CLI 命令行或 tmux 会话操控 Codex 方便和可扩展得多。
另一个安全细节：为了避免把 Linear 的访问令牌（API token，相当于访问密码）直接暴露给Sub Agent，他们用动态工具调用（dynamic tool calls）的方式，封装了一个叫 linear_graphql 的函数。
代理可以通过这个函数对 Linear 执行任意查询，但永远接触不到原始 token。
遇到的新问题
当然，这种工作方式也有代价，他们没有回避这一点。
从实时干预Agent，变成在任务层面分配工作，意味着失去了随时纠偏的能力。
有时候Agent会完全跑偏，产出的东西完全不对路。
但他们的应对方式很有意思：不是手动修补结果，而是补充防护机制和技能，让Agent下次能自己成功。
这倒逼他们持续完善系统，加入了端到端测试、通过 Chrome DevTools 驱动浏览器、管理 QA 冒烟测试等新能力，还大幅改善了文档质量。
还有一个认知上的转变：不能把Agent当成状态机里的僵硬节点。
早期版本只让 Codex 实现任务，这太局限了。
Codex 完全有能力同时管理多个 PR、读取 CI（持续集成，自动化测试和构建流程）日志、处理代码审查反馈。
CI（Continuous Integration，持续集成）：每次代码提交后自动运行测试，确保新代码不破坏已有功能。
所以他们最终的方向是：给Agent目标，而不是给它严格的状态转换规则。
就像一个好的管理者，给直接下属分配目标，而不是每一步都手把手指导。
给它工具，给它上下文，让它自己想办法。
不是所有任务都适合 Symphony 的工作方式。
涉及模糊问题或需要强判断力的工作，工程师还是会直接用交互式 Codex 会话。
实际上，这些往往也是工程师最感兴趣、最享受的任务。
用 Symphony 来构建 Symphony
这个细节值得单独说一下。
Symphony 基本功能跑通之后，他们就开始用 Symphony 来开发 Symphony 本身。
当他们在内部演示这个系统，看到它自主管理任务、并附上功能演示视频作为工作证明时，反应非常热烈。Symphony 的内部项目频道迅速增长，各个团队开始自发使用它。
在 OpenAI，内部产品市场契合度（PMF）是对外发布的前提条件。
基于内部的使用情况，他们决定把 Symphony 分享给外部世界。
OpenAI 不打算把它做成产品
这个项目开源后，三周内获得了超过 15,000 个 GitHub Star。
社区已经有人做了各种移植版本：
有人用 Go 语言加上 Charm CLI 的终端 UI 做了一个版本
有人把它改造成支持 Anthropic 的 Claude Code，并支持 GitHub Issues，还做成了 Homebrew 可以直接安装
有人用 Claude Code 重新实现了整套规范，取名 hatice
但 OpenAI 明确说了：不打算把 Symphony 作为独立产品来维护。
它是一个参考实现，一个演示 Codex App Server 能力的例子。
核心思路很简单：
对每一个打开的任务，保证有一个Agent在它自己的工作空间里持续运行。
他们希望大家把自己喜欢的编码代理指向这份规范，构建适合自己环境的版本。
门槛其实出奇地低，直接把规范扔给 Codex，让它帮你实现一个就行。
值得思考的地方
Symphony 解决的问题，表面上是"怎么让更多 AI 并行工作"，但更深层的变化是：当代码的边际成本趋近于零，整个软件开发的经济学都变了。
每次改动的感知成本下降，意味着大家开始愿意做以前觉得"不值得"的事：试一个想法，探索一次重构，验证一个假设，不满意就扔掉。
参与工作的人也变了。
产品经理和设计师可以直接向 Symphony 提需求，不需要懂代码，不需要管理 AI 会话，描述功能，然后收到一个包含视频演示的审查包。
在大型 monorepo（单一代码仓库，把所有项目代码放在一个仓库里管理）里，Symphony 还承担了"最后一公里"的工作：监视 CI 状态，需要时自动 rebase（同步最新代码），解决冲突，重试不稳定的检查项，把改动一路护送进主分支，不需要人类盯着。
随着模型越来越强，能解决的问题越来越大，其他公司的瓶颈也会从"写代码"转向"管理 AI 工作"。
Symphony 提供的，是一种思路：不要管理Agent，管理任务就够了。
