OpenAI Symphony:Agent 编排引擎

你有没有同时开过3个以上的 Claude Code 或 Codex 窗口？

我试过。到第4个的时候，你已经分不清哪个窗口在改哪个 bug，发出的指令经常跑到错误的终端里。

这不是你的问题，模型也没有变弱。OpenAI 的工程团队算了一笔账：当并行运行多个 Coding Agent 时，真正的瓶颈不再是模型能力，而是人类的注意力。

他们用 Project Symphony 给出了答案：把管理层级从"盯着 Agent 干活"，提升到"验收产出结果"。

你可能在同时跑 Claude Code、Codex、Cursor，每个窗口都在写代码。但每分钟切换3次上下文，你已经成了 Agent 的陪跑员，而不是工程师。

Symphony 的思路很简单——让工单追踪器做状态机。你只管在 Linear 里创建 ticket，后台 Daemon 每30秒轮询一次，发现新工单就自动建一个隔离工作区、启动 Codex、跑完验证、上传录屏、开 PR。你只需要在人工审核阶段看结果。

认知瓶颈：为什么 Agent 越快你反而越累

过去几个月，编程 Agent 的进化速度惊人：从 Tab 补全，到交互式对话，再到多会话并行。

但人类大脑的上下文切换带宽是固定的。研究显示，每次切换任务平均损失 23 分钟的重新聚焦时间。

你现在能同时管理 3 个 Agent 会话，是因为每个会话之间还有缓冲。到第 4、5 个时，你已经不是在管理 Agent 了，你变成了消息路由器。

这就是 Symphony 要解决的问题：Cognitive Load Bottleneck（认知负荷瓶颈）。

OpenAI 的方案不是让 Agent 更聪明——而是让人退后一步。你不再是一个个盯着 Chat Session，你管理的是工单队列。这和软件工程几十年来的管理逻辑一脉相承：

工程主管管理成千上万的员工，不是通过审查每个人的 PR，而是通过 Jira、Linear、Asana 这类工具看最终结果。

Symphony 只是把这套逻辑应用到了 Agent 身上。管理层级提升一级，产出上限从 3 个 Agent 变成 N 个。

一套文件管一切：Workflow.md 的精巧设计

Symphony 最简洁的设计，是整套系统只依赖一个文件：Workflow.md。

上半部分是 YAML frontmatter，配置调度器：

1. tracker.project_id: 监控哪个 Linear 项目

2. poll_interval_ms: 轮询频率（默认30秒）

3. max_concurrent_agents: 全局并发上限

4. max_concurrent_agents_by_state: 按状态细分并发

5. stall_timeout_ms: 停滞超时（300秒自动重试）

6. turn_timeout_ms: 单轮超时（3600秒）

7. workspace.after_create_hook: 工作区初始化命令（如 git clone）

8. agent.before_run_hook: Agent 启动前命令（如 npm install）

下半部分是 Markdown 提示词，每轮对话都发给 Agent：

1. 工单详情和验收标准

2. 处理此类型工单的标准操作流程（SOP）

3. 如何规划任务、如何验证工作

4. 什么算完成、什么需要人工审核

关键是这个文件在代码库里。受版本控制、可 PR 修改、团队共享。没有管理面板，没有独立服务。配置即代码（Configuration as Code）。

这比大多数 Agent 框架的配置文件都克制。

实操：从零搭建 Symphony，30分钟跑通全流程

第一步：准备 Linear

去 linear.app 创建账号，新建一个项目。点击项目设置，复制 Project Identifier UUID——这是 Symphony 要监控的项目 ID。

然后去 Settings → Security & Access → Personal API Keys，生成一个 API Key。在终端运行：

export LINEAR_API_KEY=你的key

第二步：克隆 Symphony 仓库

git clone https://github.com/openai/symphony.git
cd symphony

你会看到 elixir/ 目录，这是官方用 Elixir 写的参考实现。大多数情况下直接用它就行。

第三步：用 Coding Agent 自动生成 Workflow.md

这是最省力的方式。打开 Codex 或 Claude Code，指向 spec.md：

codex ag "我想为我的仓库设置 Symphony，请根据 spec.md 帮我构建 workflow.md 文件"

Agent 会自动分析你的代码库结构，生成适配的 Workflow.md。你只需要填入 Project ID 和 API Key。

第四步：配置 Playwright CLI 自验证

这是最容易被忽略但最关键的一步。Symphony 要求 Agent 能证明"代码真的跑通了"——不是跑测试就够了，还要录制浏览器操作流程。

Playwright 发布了 CLI 工具，专门为后台 Agent 设计（不占上下文窗口）：

npx playwright-video start
# ... Agent 操作浏览器 ...
npx playwright-video stop --output=test_proof.mp4

生成的视频会自动上传到 Linear 工单。你只需点击播放，就能看到 Agent 的完整操作过程。

你的代码库还需要这些 Agent Skill：

1. local-server.md：告诉 Agent 如何启动本地服务器

2. linear.md：通过 Linear API 操作工单、上传视频

3. playwright-testing.md：录制视频 + 追踪调试日志

4. grafana-logs.md：获取生产日志修 bug

第五步：启动 Symphony

elixir symphony --workflow ./workflow.md --skip-guard-rails

屏幕上会显示：

1. 监控的 Linear 项目及下次刷新时间

2. 已提取的工单列表

3. 每个工单对应的 Agent 任务状态

4. 隔离工作区路径和实时日志

第六步：看板上创建测试工单

创建一个工单，比如"修改落地页文案"，状态设为 Todo。30秒后，Symphony 会自动提取、建工作区、启动 Agent。

你可以在 Dashboard UI 看到进度，也可以看终端实时日志。几分钟搞定后：Agent 把工单状态转为 Review，附上修改计划和验证视频。你检查通过，改为 Merging——Agent 会自动创建 PR。

编排层：为什么这是 Agent 工具的下半篇文章

理解 Symphony 的价值，需要先理解 Coding Agent 进化的三个阶段：

阶段	交互方式	瓶颈	代表工具
1. 补全程	你敲键盘，模型辅助	打字速度	GitHub Copilot
2. 交互层	你对话，模型执行	单窗口效率	Claude Code, Codex CLI
3. 编排层	你下工单，Agent 自主执行	基础设施改造	Symphony

你现在可能停留在阶段 2——一个窗口一个任务，边写边改。效率已经很高了，但天花板就在你前面。

Symphony 代表的编排层核心思想，是Routing + Delegation：

1. Scheduler 负责 Route——根据工单类型和状态，分配到合适的工作区

2. Agent 负责 Delegate——在隔离环境中自主执行

3. Human 负责 Approve——只看结果，不问过程

这和 PEV Loop（Plan-Execute-Verify）的思路一脉相承：代码即 Agent 骨架。Workflow.md 就是骨架，Agent 按照骨架自主填充血肉。

8 层架构拆解

Symphony 的 8 层组件，值得你理解每一层的职责：

1. Workflow Loader（策略层）— 读写 Workflow.md，解析策略

2. Config Layer（配置层）— 环境变量解析和校验

3. Issue Tracker Client（数据层）— 拉工单、轮询状态

4. Orchestrator（协调层）— 派发、重试、停止、释放决策

5. Workspace Manager（执行层）— 隔离目录管理

6. Agent Runner（执行层）— 启动 Agent 子进程

7. Status Surface（观测层）— 人类可读的运行状态

8. Logging（观测层）— 结构化日志

注意到这个设计没有数据库吗？工单追踪器本身就是 source of truth，文件系统的隔离目录保证状态可恢复。指数退避重试保证可靠性。

这比大多数创业公司做的 Agent 平台都克制。

真正被忽略的前置条件：Harness Engineering

90% 的人看到 Symphony 会高潮，然后回去发现自己的代码库根本跑不通。

为什么？因为编程 Agent 端到端完成工单，有一个前置条件：Harness Engineering（框架工程）。

你的代码库必须满足：

1. Bootstrappable：一个命令能完成所有环境设置（Agent 不会花时间琢磨怎么配环境）

2. 合理的目录结构：Agent 能找到该找的东西

3. 自验证工具：Agent 完成后能自动验证（测试、录屏、CI）

大多数人只在 CLAUDE.md 里写了"怎么启动服务"，但没写"怎么验证改完了"、"怎么录屏上传"、"怎么修线上 bug"。

Playwright CLI 的视频录制，就是填补这个关键的验证缺口。之前 Agent 只能跑 unit test，跑不了端到端测试。有了 CLI 版本，不占上下文窗口，后台 Agent 就能自主录制、自主上传、自主证明。

一个人团队怎么用？

你可能在想"我只有一个人，没有工单系统，用不上"。

错。个人开发者恰恰最适合。

你每天要做 10 个小功能？创建 10 个工单，把 Symphony 指向你的仓库。去喝咖啡、去写文案、去开会。回来验收 10 个 PR。

你是一个人，但产出可以是 10 个人的。

这就是 Solo Leverage 的本质——不是找到一个工具代替你，而是构建一套工作流让你管理产出过程。

总结

OpenAI Symphony 的核心价值可以浓缩为一句话：把人类从 Agent 陪跑员升级为产出验收官。

工单追踪器做状态机，一个 Workflow.md 管一切，每 30 秒轮询一次。Agent 在隔离环境中自主执行、自主验证、自主提交。你只看结果。

从盯着 Agent 干活，到管理工单队列。这就是 AI 编程的下半篇文章。

你有没有算过，如果你不再需要盯着 Agent 干活，一天能多产出多少？