快速摘要：OpenAI 于 2026 年 3 月初开源了名为 Symphony 的自动化编排框架，项目发布仅数天便在 GitHub 上引发广泛关注。Symphony 的核心理念很明确——让开发团队不再需要逐行监督 AI 编码智能体，而是在更高维度"管理工作本身"。它通过轮询 Linear 看板自动发现待办任务，为每个任务创建隔离的工作空间，调度 Codex 编码智能体独立完成编码、测试、提交 PR，并在合并前提供完整的"工作证明"。整套系统基于 Elixir/Erlang BEAM 运行时构建，天然支持高并发与容错。如果你对 AI 辅助开发的工程化落地感兴趣，往下看有更详细的原理拆解和操作指南。
一、AI 编程助手的现状与痛点
过去两年，AI 编程领域的进化速度有目共睹。从最初 GitHub Copilot 式的行级代码补全，到如今的 Codex、Claude Code 等能够完成整个函数甚至重构模块的编码智能体，AI 在"写代码"这件事上的能力已经不容小觑。
但真正在团队中用过这些工具的工程师都会有一个共同感受：AI 写代码确实快，但你需要花大量时间去"管理"这个 AI。 你得确认它是否正确理解了需求，检查它写出的代码是否有逻辑漏洞，验证它有没有引入安全风险，还得在它犯错时反复解释哪里理解偏了。本来指望 AI 帮你提高效率，结果你变成了一个"AI 保姆"——全天候监控它的每一行输出。
这个问题在多任务并行的场景下尤为突出。当你的团队看板上有十几个待办任务，每个任务都需要派一个 AI 智能体去处理时，单靠人工逐个监控根本不现实。手动触发智能体、检查输出、纠正错误、再重新运行——这套流程本身就消耗了工程师大量的精力，反而形成了新的管理瓶颈。
更深层的问题在于，当前大多数 AI 编码工具的交互模式本质上是"对话式"的——你给 AI 一个提示，它给你一段代码，你审查后给出反馈，它再修改。这种模式在处理单个小任务时效率还可以，但当你需要让 AI 同时处理多个相互关联的任务时，人工协调成本会呈指数级增长。你需要确保不同任务之间的代码不会冲突，需要管理多个会话的上下文，还需要跟踪每个任务的进度——而这些本来应该由系统自动完成的"管理工作"，全都落在了工程师的头上。
另一个常被忽视的问题是代码质量的持续性。在人工监督模式下，你的审查质量高度依赖于工程师当时的精力和注意力。当你连续审查了几个小时的 AI 生成代码后，注意力不可避免地会下降，这时候就容易放过一些隐蔽的 Bug 或架构问题。我们需要的不是更多的人工审查，而是一种系统化的质量保障机制。
OpenAI 内部在这方面有切身体会。他们在 2025 年底到 2026 年初的一个内部项目中，用三名工程师带领 Codex 智能体团队，在五个月内生成了超过一百万行代码（包括应用逻辑、测试、CI 配置、文档和内部工具），其中没有一行是人类手写的。这个实验中工程师的角色不是写代码，而是"设计环境、指定意图、构建反馈循环"——OpenAI 把这套方法论称为 Harness Engineering（驾驭工程）。
正是在这个实践基础上，OpenAI 将经验凝练为一个开源项目——Symphony。它代表的不是一个新的代码补全工具，而是一套完整的编码智能体编排服务。
莫潇羽@源码七号站 在第一时间关注到了这个项目，并花了数天时间研读其技术规范（SPEC.md）、参考实现和社区讨论。下面这篇文章，将从原理、架构、操作三个维度为你做一次深度拆解。
二、Symphony 到底是什么？
简单一句话概括：Symphony 是一个长期运行的自动化服务，它持续从任务追踪器（目前支持 Linear）中读取工作项，为每个工作项创建隔离的工作空间，然后在该空间中调度编码智能体（Codex）去完成任务——整个过程不需要工程师逐个监督。
它不是一个聊天式的编程助手，也不是一个 IDE 插件。它更接近于一个"自动调度中心"，你只需要在项目看板上写好任务（Issue），Symphony 就会自动安排 AI 去做，做完后给你一份完整的工作报告。
从定位上来说，Symphony 解决的是"从手动脚本到可靠服务"的鸿沟。手动给一个编码智能体丢一个任务，这很简单，就是一段脚本。但要让多个智能体同时处理多个任务、互不干扰、自动重试、安全合并，这就需要一个正规的服务框架了。这正是 Symphony 的价值所在。
该项目目前处于工程预览阶段，采用 Apache 2.0 开源协议发布。项目的核心代码使用 Elixir 语言编写（约占代码的 96%），同时提供了一份与编程语言无关的技术规范文档 SPEC.md，方便开发者用任意语言实现自己的版本。
GitHub 仓库地址：https://github.com/openai/symphony
从技术分类上讲，Symphony 属于"智能体编排框架"（Agent Orchestration Framework）这个新兴类别。它和我们熟知的 LangChain、AutoGen 等智能体框架有着本质的区别：后者关注的是"如何让单个智能体更强大"，而 Symphony 关注的是"如何让多个智能体在真实的软件开发工作流中可靠地协同工作"。你可以把它理解为 AI 编码智能体领域的"Kubernetes"——它不关心单个容器（智能体）内部在做什么，它关心的是如何调度、隔离、监控和管理大量并发运行的容器。
值得一提的是，Symphony 与 OpenAI 在今年早些时候发布的 Codex App Server 紧密相关。Codex App Server 提供了一个标准化的 JSON-RPC 协议接口，让不同的客户端（CLI、IDE 扩展、桌面应用）可以用统一的方式与 Codex 编码智能体交互。Symphony 正是基于这个接口来启动和管理 Codex 会话的。这意味着随着 Codex App Server 协议被更多的编码智能体支持，Symphony 未来有潜力不仅编排 Codex，还可以编排其他兼容该协议的智能体。
三、核心理念：从"监督智能体"到"管理工作"
这一节是理解 Symphony 最重要的部分，因为它不是在技术细节上的小修小补，而是一次开发范式的根本转变。
传统的 AI 编程辅助模式是这样的：
开发者 → 给 AI 发指令 → 审查 AI 输出 → 修正错误 → 重复在这个模式下，人是"驱动者"，AI 是"执行者"。你必须时刻在旁边看着，因为 AI 随时可能跑偏。
Symphony 倡导的模式是这样的：
开发者 → 在看板上写好任务 → Symphony 自动调度智能体 → 智能体独立完成 → 提供工作证明 → 开发者审查结果在这个模式下，人的角色从"AI 监督员"变成了"工作管理者"。你不再关心 AI 写代码的每一步过程，而是关心"需要完成什么工作"以及"完成质量是否合格"。这就好像从手工作坊的工头，转变为现代工厂的生产经理——你管理的是生产线和产品质量，而不是每个工人的每一个动作。当然，这并不意味着人类工程师变得不重要了。恰恰相反，在这种模式下，工程师的技术判断力、系统设计能力和产品洞察力变得更加关键——因为这些是 AI 目前还无法替代的能力。
这种理念的背后有一个更深层的认知：AI 编码智能体的瓶颈，往往不在于模型本身的编码能力，而在于它运行的环境质量。 OpenAI 在 Harness Engineering 的实践中发现，同样的模型，在精心设计的环境中与在粗糙的环境中，表现差异巨大。LangChain 团队也曾公开过类似的实验数据——他们的编码智能体在一个基准测试中仅通过优化"驾驭"层（而非更换模型），就从排行榜第 30 名跃升到了前 5 名。
Symphony 正是这种"驾驭工程"思想的产品化体现。它把那些原本需要人工完成的调度、隔离、重试、清理等"驾驭"工作，全部自动化为一个长期运行的服务。
四、Symphony 的整体架构深度剖析
要真正理解 Symphony 是怎么工作的，我们需要从它的架构层面入手。根据官方的技术规范文档，Symphony 的架构可以划分为几个核心层，每一层都有明确的职责。
4.1 Tracker Adapter（任务追踪器适配层）
这是 Symphony 与外部任务管理工具的接口层。目前的规范版本中，它默认与 Linear 集成。这一层的核心职责包括：
- 从 Linear 中获取处于特定活跃状态的候选任务
- 获取特定任务 ID 的当前状态（用于状态对账）
- 在启动时清理处于终态的任务
- 将 Linear 的原始数据格式标准化为 Symphony 内部的任务模型
值得注意的是，Symphony 本身只负责"读取"任务状态，不负责"写入"。也就是说，当一个任务从"待处理"变为"进行中"再变为"已完成"，这些状态变更是由编码智能体（Codex）通过技能（Skills）来执行的，而不是由 Symphony 直接操作。Symphony 的定位是调度器和运行器，不是任务管理器。
这一层的设计考虑了容错性。如果获取候选任务失败，Symphony 会记录日志并跳过本轮调度；如果刷新运行中任务的状态失败，已经在运行的智能体不会被中断。
4.2 Orchestrator（编排器）
这是 Symphony 的大脑。编排器是整个系统的核心调度中枢，负责以下关键工作：
- 维护轮询时钟，定期检查是否有新任务需要处理
- 管理内存中的运行时状态，包括每个任务的运行状态（running/claimed/retry_attempts 等）
- 决定哪些任务需要被调度、重试、停止或释放
- 追踪会话指标和重试队列状态
编排器的一个重要设计决策是：运行时状态保存在内存中，而不是持久化数据库中。这听起来似乎不太可靠，但实际上 Symphony 通过在重启时重新读取 Linear 的任务状态来恢复运行，避免了需要维护一个额外的持久化存储系统的复杂度。这在 Erlang/BEAM 运行时的容错机制下是合理的。
编排器还内置了完善的重试机制。当一个智能体因为某种原因失败时（比如 API 调用超时、代码编译错误等），编排器不会立即放弃，而是将该任务加入重试队列。每个任务都有一个重试计数器，只有当重试次数超过配置的上限时，任务才会被标记为需要人工介入。这种设计让系统能够自动处理大部分临时性故障，大幅减少了需要人工干预的场景。
此外，编排器在每个轮询周期（Poll Tick）中都会执行状态对账（Reconciliation）。它会对比内存中的运行状态与 Linear 上的实际任务状态，处理两者之间的不一致。例如，如果某个任务在 Linear 上已经被人工关闭了，但对应的智能体还在运行，编排器会检测到这种差异并优雅地终止该智能体。
4.3 Workspace Manager（工作空间管理器）
工作空间管理器负责为每个任务维护一个独立的工作目录。这一层解决的核心问题是任务隔离——确保一个智能体在处理任务 A 时执行的命令，不会影响到正在处理任务 B 的另一个智能体。
在没有工作空间隔离的情况下，多个智能体同时在同一个代码仓库中工作可能会导致严重的问题。比如，智能体 A 修改了某个配置文件准备提交，而智能体 B 恰好也在修改同一个文件但出于不同的目的。没有隔离机制的话，两个智能体的改动会互相覆盖，导致不可预期的结果。Symphony 通过为每个任务创建完全独立的工作目录来彻底规避这类风险。
它的职责包括：
- 将任务标识符映射到对应的工作空间路径
- 确保每个任务的工作空间目录存在
- 执行工作空间生命周期钩子（比如在创建工作空间后自动克隆代码仓库）
- 在任务完成后清理工作空间
4.4 Agent Runner（智能体运行器）
智能体运行器是实际启动和管理编码智能体的组件。它的工作流程是：
- 创建工作空间
- 将任务信息和工作流模板组合成提示词
- 启动 Codex App-Server 客户端
- 将智能体的运行更新流式回传给编排器
这里有一个关键的技术细节：Symphony 本身不实现任何代码编辑逻辑。 它通过 JSON-RPC 协议（over stdio）以 app-server 模式启动 Codex，发送提示词，流式接收事件，并管理轮次（turn）的生命周期。换句话说，Symphony 是"管理者"，Codex 才是"干活的人"。
关于 App-Server Protocol，这里值得多说几句。这是 OpenAI 为 Codex 设计的一套标准化通信协议，它让外部程序可以像调用一个本地服务一样与 Codex 交互。协议采用行分隔的 JSON 格式通过标准输入输出（stdio）进行双向通信。Symphony 向 Codex 发送启动会话、提交提示词等命令，Codex 则流式地返回推理过程、工具调用、代码生成等事件。这种基于 stdio 的设计非常轻量，不需要额外的网络服务或端口占用，也避免了 HTTP 通信的开销。
Symphony 在管理 Codex 会话时还会跟踪 Token 消耗量。每一轮（turn）的 Token 使用情况都会被记录在结构化日志中，这对于成本监控和性能优化非常有帮助。你可以通过分析日志来了解哪类任务消耗了最多的 Token，进而优化任务描述或提示词来降低消耗。
4.5 Display（可观测性展示层）
这一层负责为操作人员提供人类可读的运行时状态。在 Elixir 参考实现中，Symphony 提供了一个基于 Phoenix LiveView 的可视化仪表盘，你可以通过浏览器实时查看所有智能体的运行情况。此外还提供了 JSON API 接口（如 /api/v1/state、/api/v1/refresh 等），方便与其他系统集成。
4.6 Logger（结构化日志层）
Symphony 输出结构化的运行时日志，包含关键的上下文字段如 issue_id、session_id 和 Token 消耗量等。这些日志可以输出到一个或多个配置的目标（sink），方便调试和审计。
4.7 层级关系总结
Symphony 的官方规范建议按照以下层级来组织代码，以方便移植到其他编程语言：
symphony/
├── SPEC.md ← 与语言无关的服务规范
├── WORKFLOW.md ← 工作流配置（本地使用）
├── elixir/ ← Elixir/OTP 参考实现
│ ├── lib/ ← 应用源码
│ ├── WORKFLOW.md ← Elixir 专用工作流配置
│ └── README.md
└── .codex/skills/ ← Codex 技能定义（智能体使用）五、WORKFLOW.md：团队与智能体之间的"契约"
WORKFLOW.md 是 Symphony 中最重要的配置文件之一，莫潇羽@源码七号站 认为这也是它设计得最巧妙的部分。它是一个 Markdown 文件，直接存放在代码仓库中，随代码一起进行版本控制。
5.1 文件结构
WORKFLOW.md 由两个部分组成：
YAML 前置元数据（Front Matter）： 包含结构化的配置信息，如任务追踪器设置、工作空间路径、并发限制、沙箱策略和生命周期钩子等。
Markdown 正文： 这就是每次启动编码智能体会话时发送给它的提示词模板。模板中可以使用变量插值（如 {{ issue.identifier }}、{{ issue.title }}、{{ issue.description }}），Symphony 会在启动智能体时自动将这些变量替换为实际的任务信息。
一个完整的 WORKFLOW.md 示例如下：
---
tracker:
kind: linear
project_slug: "my-project"
api_key: $LINEAR_API_KEY
workspace:
root: ~/code/workspaces
hooks:
after_create: |
git clone --depth 1 [email protected]:your-org/your-repo.git .
agent:
max_concurrent_agents: 10
max_turns: 20
codex:
command: codex app-server --model gpt-5.3-codex
approval_policy:
reject:
sandbox_approval: true
rules: true
mcp_elicitations: true
thread_sandbox: workspace-write
---
你正在处理 Linear 任务 {{ issue.identifier }}。
**标题：** {{ issue.title }}
**描述：** {{ issue.description }}
## 工作要求
- 编写整洁、经过充分测试的代码
- 遵循项目现有的代码风格和架构规范
- 确保所有测试通过后再提交 PR
- 在 PR 描述中清楚说明你的改动内容和原因5.2 关键配置字段详解
tracker 部分用于配置任务追踪器的连接信息。kind 指定追踪器类型（目前仅支持 linear），project_slug 是你在 Linear 中项目的唯一标识（可以在 Linear 中右键项目、复制 URL 获得，slug 就是 URL 的一部分），api_key 则是你的 Linear 个人 API 密钥。
workspace 部分配置工作空间的根目录。每当 Symphony 为一个新任务创建工作空间时，都会在这个根目录下创建一个独立的子目录。
hooks 部分定义生命周期钩子。after_create 钩子在工作空间创建后立即执行，通常用来克隆代码仓库到工作空间中。
agent 部分配置智能体的运行参数。max_concurrent_agents 控制最多同时运行多少个智能体，max_turns 控制每个智能体会话的最大轮次数。
codex 部分配置 Codex 的运行方式。command 指定 Codex App-Server 的启动命令，approval_policy 定义审批策略，thread_sandbox 定义沙箱级别。
5.3 为什么要把配置放在仓库中？
这个设计决策背后有深意。将 WORKFLOW.md 放在代码仓库中意味着：
智能体的行为策略与代码一起版本控制。 当你切换到不同的代码分支时，智能体的提示词和运行配置会随之切换。这确保了智能体的行为始终与它正在修改的代码版本保持同步。
团队可以通过 Code Review 来审查智能体策略的变更。 任何对 WORKFLOW.md 的修改都会体现在 Git 的 diff 中，团队成员可以像审查代码一样审查智能体行为的变更。
策略的变更有完整的历史记录。 你可以随时回溯到之前的某个版本，查看当时智能体是在什么样的指令下工作的。
六、Skills 技能系统：智能体的"工具箱"
Symphony 项目中的 .codex/skills/ 目录包含了一组技能定义文件，这些技能就像是智能体的"标准操作手册"。每个技能定义了一个特定操作的标准流程，智能体在执行任务时会按照这些技能的定义来操作。
6.1 内置技能概览
Symphony 目前提供了六个核心技能：
commit 技能： 负责暂存代码变更并撰写符合规范的提交信息。这确保了智能体生成的每一次提交都有清晰、规范的提交记录，方便后续追溯。
push 技能： 在推送代码之前先运行验证（通常是 make all），然后推送分支并创建或更新 GitHub PR。这个技能确保了只有通过基本验证的代码才会被推送到远程仓库。
pull 技能： 负责从远程仓库拉取最新代码，执行快进合并或三方合并，并在必要时解决冲突。这对于长时间运行的任务特别重要，因为在智能体工作期间，其他人可能已经向主分支推送了新的代码。
land 技能： 监控 PR 直到它被合并。如果 CI 失败或者收到代码审查反馈，智能体会根据反馈进行修改。这是整个流程中最关键的技能之一，因为它实现了"闭环"——智能体不仅写代码，还会根据反馈迭代改进。
linear 技能： 通过 linear_graphql 工具执行对 Linear API 的原始 GraphQL 调用，如编辑评论、上传附件等。这让智能体能够直接与任务追踪器交互，更新任务状态和添加备注。
debug 技能： 通过 issue_id 和 session_id 关联日志，帮助定位和排查问题。当某个智能体的运行出现异常时，这个技能可以快速找到相关的日志记录。
6.2 技能的工作方式
这些技能本质上是结构化的 Markdown 文件，包含了详细的操作步骤和注意事项。当 Codex 智能体被分配到一个任务时，它可以读取这些技能文件并按照其中的指引来执行操作。
这种设计的好处在于可扩展性和可定制性。团队可以根据自己的需求修改现有技能或添加新的技能。例如，如果你的项目使用了特定的代码风格检查工具或部署流程，你可以编写相应的技能文件来指导智能体正确地使用这些工具。
七、工作证明（Proof of Work）机制
这是 Symphony 区别于普通 AI 编码工具的一个重要特性。在智能体完成一个任务后，它不是简单地说"我做完了"，而是需要提供一份完整的工作证明，内容包括：
CI 状态报告： 展示持续集成管道的运行结果，包括所有测试是否通过、构建是否成功等。
PR 审查反馈： 如果 PR 收到了代码审查意见，智能体需要展示它是如何处理这些反馈的。
复杂度分析： 对代码变更的复杂度进行评估，帮助审查者快速了解这次变更的影响范围。
变更演示： 甚至可以生成演示视频，直观地展示代码变更带来的效果。
这套机制的核心思想是：如果我们不再逐行审查 AI 写的代码，那我们需要其他方式来确认代码质量。 工作证明就是这个"其他方式"。它让工程师可以在更高层面快速判断一个任务是否真正完成，而不需要逐行阅读每一行代码。
从更宏观的角度看，工作证明机制解决了 AI 编码领域的一个信任问题。当你不再亲自监督编码过程时，你需要一种"可审计"的方式来验证结果。这和传统软件工程中的代码审查并不矛盾，而是在审查之前增加了一个自动化的质量门控。审查者在看到工作证明后，可以更有针对性地关注关键部分，而不是盲目地逐行扫描。
工作证明的另一个重要价值在于可追溯性。每一次智能体的工作都有完整的记录，包括它看到了什么输入、做了什么决策、生成了什么输出、遇到了什么问题又是怎么解决的。这些记录不仅对当前的审查有价值，对于未来的问题排查和流程优化同样重要。当团队发现某类任务的完成质量不够理想时，可以回溯工作证明来分析问题出在哪个环节，然后针对性地优化 WORKFLOW.md 中的提示词或技能定义。
八、为什么选择 Elixir？技术栈的考量
看到 Symphony 的参考实现使用 Elixir 语言，很多人的第一反应可能是：为什么不用更流行的 Python 或 Go？这个选择其实很有讲究。
Elixir 构建在 Erlang 的 BEAM 虚拟机之上，而 BEAM 最初是为电信系统设计的——那种需要 7×24 小时不间断运行、同时处理成千上万个并发连接、单个连接的失败不能影响整个系统的场景。
这恰好与 Symphony 的运行特征高度吻合：
高并发需求： Symphony 可能同时运行几十甚至上百个编码智能体，每个智能体都是一个长时间运行的进程。BEAM 的轻量级进程模型可以轻松处理这种规模的并发。
容错要求： 单个智能体的崩溃不应该影响其他智能体的运行。Erlang/OTP 的监督树（Supervision Tree）机制天然支持这种"让它崩溃，然后自动恢复"的模式。
热代码更新： Elixir 支持在不停止正在运行的智能体的情况下更新代码。这在开发和运维过程中非常有用——你可以修复一个 Bug 或调整配置，而不需要重启整个服务。想象一下，当你发现某个技能定义有问题时，你可以在不中断其他十几个正在运行的智能体的情况下，热更新修复代码并让后续的智能体自动使用新版本的技能。
消息传递模型： BEAM 的进程间通信基于消息传递，没有共享内存。这从根本上避免了多个智能体运行器之间的数据竞争和状态泄漏问题。每个智能体运行在自己的进程中，有自己的内存空间，通过消息与编排器通信。这种设计天然满足了 Symphony 对任务隔离性的要求。
模式匹配与函数式编程： Elixir 的模式匹配语法非常适合处理智能体返回的各种事件类型。在 Symphony 的编排器中，需要根据智能体的不同状态（运行中、已完成、失败、需要重试等）做出不同的响应，Elixir 的模式匹配可以让这段逻辑写得非常清晰和可维护。
Phoenix LiveView 用于可观测性： Elixir 生态中的 Phoenix 框架提供了 LiveView 功能，可以在不编写 JavaScript 的情况下构建实时更新的 Web 界面。Symphony 利用这一特性，为操作人员提供了一个实时刷新的运行状态仪表盘。当你在浏览器中打开仪表盘时，每个智能体的状态变化都会自动推送到页面上，无需手动刷新。
当然，OpenAI 也考虑到了不是所有团队都熟悉 Elixir。这就是为什么他们提供了一份与编程语言无关的 SPEC.md 规范文档。任何开发者都可以用自己熟悉的语言——无论是 Go、Rust、Python 还是 Java——按照这个规范实现自己的 Symphony 版本。
九、一个任务从提交到合并的完整生命周期
为了让你更直观地理解 Symphony 的运作方式，莫潇羽@源码七号站 在这里用一个具体的场景来走一遍完整流程。
假设你的团队正在用 Linear 管理项目，你在看板上创建了一个任务："给用户个人资料页面添加头像上传功能"。
第一步：任务被发现。 Symphony 的轮询循环（Poll Tick）定期查询 Linear API，发现了这个新的候选任务。编排器检查当前运行中的智能体数量，确认还没有达到 max_concurrent_agents 上限，决定调度这个任务。
第二步：创建隔离工作空间。 工作空间管理器在配置的根目录下为这个任务创建了一个专属目录（比如 ~/code/workspaces/PROJ-42/），然后执行 after_create 钩子，自动在这个目录中克隆了项目代码仓库。
第三步：构建提示词。 智能体运行器读取 WORKFLOW.md 文件，将模板中的变量（如 {{ issue.identifier }}、{{ issue.title }}、{{ issue.description }}）替换为实际的任务信息，生成完整的提示词。
第四步：启动编码智能体。 智能体运行器通过 JSON-RPC 协议以 app-server 模式启动 Codex。Codex 接收到提示词后，开始分析任务需求，阅读项目代码结构，规划实现方案。
第五步：智能体独立工作。 Codex 在隔离的工作空间中编写代码、创建测试、运行测试。如果遇到问题，它会根据错误信息自行调试和修复。整个过程中，智能体的运行事件会流式回传给编排器，但不需要人工干预。
第六步：提交并推送。 代码写完并通过本地测试后，智能体使用 commit 技能暂存变更并撰写规范的提交信息，然后使用 push 技能将代码推送到远程仓库并创建 PR。
第七步：提供工作证明。 智能体在 PR 中附上 CI 运行结果、代码变更说明、复杂度分析等工作证明。如果配置了的话，还可以生成变更的演示内容。
第八步：等待审查和合并。 智能体使用 land 技能持续监控 PR 状态。如果 CI 失败了，它会分析失败原因并尝试修复；如果团队成员提出了代码审查意见，它会根据反馈进行迭代修改。当 PR 被批准并通过所有检查后，智能体安全地合并代码。这个过程中最值得关注的是智能体的"自愈"能力——它不是机械地等待人工介入，而是主动分析问题并尝试解决。例如，如果 CI 中的某个集成测试因为网络超时而失败，智能体可能会选择重新运行测试；如果是真正的代码错误导致测试失败，智能体会回到代码中进行修复并重新推送。
第九步：状态更新。 在整个流程的各个节点，智能体通过 linear 技能实时更新 Linear 上对应任务的状态。当工作空间准备好时，任务状态从候选变为进行中；当 PR 创建完成并附上工作证明时，状态变更为 Human Review；当人工审查通过后，状态变为 Merging；最终合并成功后，任务标记为完成。这些状态变更让整个团队都能在 Linear 看板上实时掌握每个任务的进展。
第十步：清理。 任务完成后，Symphony 清理对应的工作空间，释放资源。这一步包括删除临时的工作目录、归档日志文件等。如果清理失败，Symphony 会记录警告但不会影响其他任务的正常运行。
在整个过程中，工程师需要做的只是在 Linear 上审查工作证明和最终的 PR——而不需要坐在智能体旁边盯着它的每一步操作。
十、非标准 Linear 状态配置
Symphony 的工作流依赖于几个在 Linear 中默认不存在的自定义状态。这是新手搭建时容易忽略的一个细节，莫潇羽@源码七号站 在这里特别提醒一下。
你需要在 Linear 中配置以下非标准状态：
Rework： 当智能体的 PR 收到需要修改的审查意见时，任务会被标记为此状态。智能体会自动检测到这个状态变更并重新开始工作。
Human Review： 当智能体完成工作并提供了工作证明后，任务进入此状态，等待人类工程师审查。
Merging： 当审查通过后，任务进入合并状态，智能体执行最终的代码合并操作。
配置方式是在 Linear 中进入 Team Settings → Workflow，添加这些自定义状态。具体的状态名称可以根据你的团队习惯调整，但需要确保 WORKFLOW.md 中的配置与 Linear 中的实际状态名一致。
十一、从零开始搭建 Symphony 环境（详细操作指南）
下面是完整的搭建步骤。需要说明的是，这套指南基于 Elixir 参考实现，如果你打算用其他语言根据 SPEC.md 自行实现，可以跳过 Elixir 相关的安装步骤。
11.1 前置条件
在开始之前，你需要确保以下条件满足：
- 一台运行 Linux 或 macOS 的机器（Windows 用户建议使用 WSL2）
- 拥有一个 Linear 账户，并且已创建好要管理的项目
- 拥有 GitHub 账户（用于 PR 操作）
- 网络能够正常访问 GitHub 和 Linear API
11.2 安装 mise 版本管理器
Symphony 的 Elixir 参考实现推荐使用 mise 来管理 Elixir 和 Erlang 的版本。mise 是一个多语言版本管理工具，类似于 nvm（Node.js）或 pyenv（Python），但支持更多语言。
# 安装 mise
curl https://mise.run | sh
# 将 mise 添加到你的 shell 配置中（以 bash 为例）
echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc
source ~/.bashrc
# 验证安装
mise --version如果你使用的是 zsh，把上面的 ~/.bashrc 替换为 ~/.zshrc。
11.3 克隆仓库并安装依赖
# 克隆 Symphony 仓库
git clone https://github.com/openai/symphony
cd symphony/elixir
# 信任 mise 配置（这会允许 mise 读取项目中的 .mise.toml 配置）
mise trust
# 安装项目指定版本的 Elixir 和 Erlang
mise install
# 验证 Elixir 安装
mise exec -- elixir --version
# 安装 Mix 依赖并编译项目
mise exec -- mix setup
mise exec -- mix build这里需要注意的是，Elixir 的安装可能需要
