一句话总结
Symphony 是一个将项目管理看板（Linear）变成 AI 编程 Agent 编排控制面板的开源规范——每一个未关闭的 Issue 自动对应一个独立 Agent，7×24 不间断执行，人类只需要 review 结果。
部分团队在上线 3 周内，landed PR 数量增长了 500%。
背景：为什么需要 Symphony？
前传：Harness Engineering
六个月前，OpenAI 内部一个团队做了一个激进实验：仓库中 0 行人写代码，所有代码必须由 Codex 生成。为此他们重新设计了工程工作流，打造了”Agent-friendly repository”——完善的自动化测试、guardrails、文档，把 Codex 当成正式队友。
这个方法奏效了。但随即撞上了下一个瓶颈：上下文切换。
人类注意力成为系统瓶颈
当 Agent 工作规模扩大后，工程师的日常变成了：
打开 3-5 个 Codex 会话 → 分配任务 → 审查产出 → 纠偏 → 重复
超过 5 个并行会话后，生产力骤降。工程师忘了哪个 session 在做什么，在终端间跳来跳去，调试卡住的长任务。
本质问题：Agent 已经很快了，但人类成了瓶颈。他们相当于雇了一堆极其能干的初级工程师，然后让高级工程师去”微管理”他们——这不 scale。
视角转换
关键洞察：他们一直在优化错误的东西。
之前围绕”Codex 会话”和”PR”组织工作，但会话和 PR 只是手段，不是目的。软件工程的工作实际上围绕交付物组织：Issue、任务、里程碑。
于是他们问了一个问题：如果不再直接监督 Agent，而是让 Agent 自己从任务看板拉取工作会怎样？
这就是 Symphony 的起点。
核心架构：Issue Tracker = Agent 控制面板
基本运作模式
┌─────────────────────────────────────────────────────┐
│ Linear 看板 │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │Todo │ │In │ │Human│ │Merg-│ │Done │ │
│ │ │ │Prog │ │Revw │ │ ing │ │ │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └─────┘ │
└─────┼────────┼───────┼───────┼──────────────────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────────────────────────────────────────────┐
│ Symphony Orchestrator │
│ │
│ • 持续轮询看板 │
│ • 每个活跃 Issue → 独立 Workspace → 独立 Agent │
│ • Agent 崩溃 → 自动重启 │
│ • 新任务 → 立即认领 │
│ • DAG 依赖 → 自动按序执行 │
│ • 指数退避重试 │
└─────────────────────────────────────────────────────┘
六层架构
Symphony 规范定义了清晰的六层分离：
| 层级 | 名称 | 职责 |
|---|---|---|
| 1 | Policy Layer | WORKFLOW.md — 团队级的 Agent 行为策略，随代码版本控制 |
| 2 | Configuration Layer | 解析配置，处理默认值和环境变量 |
| 3 | Coordination Layer | 轮询循环、任务调度、并发控制、重试、状态协调 |
| 4 | Execution Layer | 工作区生命周期管理、Agent 子进程协议 |
| 5 | Integration Layer | Issue Tracker 适配器（当前为 Linear） |
| 6 | Observability Layer | 结构化日志 + 可选状态面板 |
核心组件
- Workflow Loader — 读取
WORKFLOW.md，解析 YAML front matter + prompt body - Issue Tracker Client — 拉取活跃 Issue，归一化为统一模型
- Orchestrator — 调度核心：轮询、分派、重试、停止、释放
- Workspace Manager — Issue → 独立目录映射，生命周期钩子
- Agent Runner — 构建 prompt，启动 Codex app-server，流式回传状态
- Status Surface — 可选的人类可读状态展示
关键设计决策
| 决策 | 理由 |
|---|---|
| 每 Issue 独立工作区 | 隔离性——Agent 命令只在自己目录内执行 |
| WORKFLOW.md 随仓库版本控制 | 团队策略可追踪、可回滚、可 review |
| 无持久化数据库 | 重启恢复靠文件系统 + Issue 状态，简化部署 |
| 不规定沙箱策略 | 不同环境信任度不同，留给实现者决定 |
| Agent 只读 Issue，写操作由 Agent 工具完成 | Symphony 是调度器，不是业务逻辑引擎 |
DAG 任务编排：自动发现最优并行路径
Symphony 最强大的能力之一是任务依赖图（DAG）编排：
示例：React 升级项目
┌── Vite 迁移 ──┐
│ │
分析代码库 ──────┤ ├── React 升级 ── 集成测试 ── 完成
│ │
└── 清理旧依赖 ──┘
- Agent 可以自动将大任务拆解为子任务树
- 有阻塞关系的任务按序执行
- 无依赖的任务自动并行
- Agent 还会自主创建新 Issue（发现重构机会、性能问题等）
这意味着 Symphony 不只是一个执行器，而是一个能自我扩展工作范围的系统。
关键数据与效果
| 指标 | 数据 |
|---|---|
| Landed PR 增长 | 500%（部分团队，3 周内） |
| GitHub Stars | 21.8k（发布不到 2 周） |
| 参考实现 | Elixir（95.5%），Apache 2.0 协议 |
| 发起工作的角色扩展 | 工程师 → PM、Designer 都能直接提需求 |
深层洞察：四条工程哲学
1. “给目标，不给步骤”
We moved toward giving agents objectives instead of strict transitions, much like a good manager would assign a goal to a direct report.
早期他们把 Agent 当状态机的刚性节点——只做”实现这个功能”。后来发现 Codex 完全可以：创建多个 PR、读取 review 反馈并修复、关闭过期 PR、生成完成报告。
教训：模型越来越聪明，不要限制在你为它设计的盒子里。给工具、给上下文、让它自己想办法。
2. “失败成本趋近于零”
If the agent gets something wrong, that’s still useful information, and the cost to us is near zero.
这彻底改变了团队行为：随手创建探索性任务、试想法、试重构、试假设，只保留有价值的结果。
当每次尝试的边际成本趋近于零时，探索的总量会爆发式增长。
3. “不要修结果，修系统”
Instead of patching the result manually, we added guardrails and skills so the agents could succeed the next time.
Agent 产出质量不够时，不手动改输出，而是增加 E2E 测试、增加 Chrome DevTools 集成、改善文档、明确”什么算好”。
投资系统性解法，而不是一次性补丁。这是一个正反馈飞轮。
4. “Symphony 用 Symphony 来构建 Symphony”
仓库里的核心只是一个 SPEC.md——问题定义和解法规范。他们把 SPEC 交给 Codex，让 Codex 来实现 Symphony 本身。
这展示了一种新的软件开发范式：规范驱动开发（Spec-Driven Development）。人类写 Spec，Agent 写实现。
局限性与适用边界
| 适合 Symphony 的 | 不适合的 |
|---|---|
| 明确可描述的实现任务 | 高度模糊、需强判断力的探索 |
| 标准化的工程流程 | 需要频繁实时纠偏的工作 |
| 可自动化验证的工作 | 涉及微妙权衡的架构决策 |
| 大量重复性实现 | 需要深度领域专家知识的任务 |
不适合的场景恰恰是人类工程师最有趣、最值得花时间的工作——这正是设计意图：让 Agent 处理大量常规实现，让人聚焦于真正有挑战性的单一难题。
与现有方案的对比
| 维度 | Symphony | Copilot Workspace | Devin | 传统 CI/CD |
|---|---|---|---|---|
| 粒度 | Issue 级 | PR 级 | 会话级 | 构建级 |
| 自主性 | 全自主 + 人 Review | 半自主 | 全自主 | 无 AI |
| 任务来源 | Issue Tracker | IDE | 对话 | Git push |
| 并发模型 | N 个隔离 Workspace | 单一 Workspace | 单 Session | 按 runner 数 |
| 长时运行 | ✅ Daemon 模式 | ❌ | ❌ | ❌ |
| 自我扩展工作 | ✅ 自创 Issue | ❌ | 部分 | ❌ |
| 开源 | ✅ Apache 2.0 | ❌ | ❌ | 视工具 |
对行业的启示
“Agent 管理”将消亡，”工作管理”将崛起
旧世界：人管理 Agent 会话 → 人是瓶颈
新世界：人管理工作看板 → Agent 是执行层 → 无限并行
这意味着：
- 项目管理工具（Linear、Jira、GitHub Issues）将进化为 Agent 编排平面
- PM 的角色从”写需求给工程师”变为”写需求给 Agent”
- 工程师的角色从”写代码”变为”设计系统让 Agent 能正确写代码”
“Harness Engineering” 是前置条件
Symphony 能工作的前提是仓库已经是 Agent-friendly 的：完善的自动化测试、清晰的文档、好的 guardrails、明确的质量定义。
没有 Harness Engineering 的基础，直接上 Symphony 会是灾难。
规范优于实现
Symphony 选择开源一个 SPEC 而不是一个产品——任何语言都能实现、任何 Issue Tracker 都能适配、任何 Agent 都能对接。这比开源一个耦合的产品有更大的生态潜力。
实践建议：如何在自己团队落地
Step 1: 评估准备度
- 仓库有 CI/CD 和自动化测试？覆盖率 > 70%？
- 有清晰的文档和编码规范？
- 有明确的 PR review 标准？
Step 2: 小范围试点
- 选择相对独立的子系统
- 创建
WORKFLOW.md定义 Agent 行为策略 - 从简单、可验证的任务开始
Step 3: 逐步扩大
- 观察失败模式 → 补 guardrails
- 培训非工程角色直接提交任务
- 建立度量体系（成功率、干预率、PR 质量）
Step 4: 文化转变
- 接受”试错零成本”的心态
- 把 Agent 失败当成系统改进的信号
- 人类聚焦高判断力工作
结语
Symphony 不是又一个 AI 编程工具——它是一种工程组织方式的范式转变。
它回答的核心问题是：当 Agent 能力已经足够时，瓶颈在哪里？
答案是：在人类的注意力和组织方式上。
Symphony 的解法优雅而实用：不去做更好的 Agent，而是改变人和 Agent 的协作方式——从”微管理”变为”目标驱动”，从”会话级”变为”工作级”，从”一对一”变为”一对多自动编排”。
对于任何规模化使用 AI Agent 的团队来说，这个规范都值得深入研究。不管你用不用 Codex，Symphony 提出的思想和架构模式是跨平台、跨工具的普适原则。