--- layout: post.njk source: https://blog.qiaomu.ai/openai-symphony-ai-coding-agents speaker: 向阳乔木 title: OpenAI Symphony：给每一个任务配一个永不下班的 AI 员工 · 乔木博客 date: '2026-04-29' summary: 这篇文章介绍了 OpenAI 的 Symphony 项目，它通过将项目管理看板与 AI 编码代理结合，实现了任务的自动化分配和执行。Symphony 旨在解决 AI 编程的上下文切换瓶颈，将软件开发的重心从微观管理转向宏观任务分配，预示着代码边际成本降低后软件开发经济学的深刻变革。 area: tech-engineering category: ai-application tags: - symphony - ai-agents - autonomous-development - workflow-automation - ai-engineering people: [] companies_orgs: - OpenAI - Linear products_models: - symphony - codex - linear media_books: [] draft: true status: evergreen --- 乔木博客 全部 AI工具 AI教程 AI生成 AI资讯 健脑房 播客解读 论文学习 # OpenAI Symphony：给每一个任务配一个永不下班的 AI 员工 AI工具 · 2026年4月29日 · 522 次阅读 · 约 13 分钟 OpenAI 最近开源了一个叫 Symphony 的项目。 > https://github.com/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，管理任务就够了。 © 2026 · 向阳乔木