夜雨聆风OpenAI 在 4 月底开源了一个叫 Symphony 的项目。官方文章里有个很抓人的数字：采用 Symphony 后，部分团队前三周 landed PR 数量增加了 500%。
这个数字很容易让人误会成多 Agent 自动写代码，效率直接起飞。源码读下来，我的感觉要冷一点。Symphony 真正有意思的地方，是它把 coding agent 放进了工程团队已经在用的工作系统里：工单、状态、blocker、workspace、CI、review、merge。
它是什么
README 里对 Symphony 的描述很直接：它把项目工作变成隔离的、自治的 implementation runs，让团队管理 work，而不是监督 coding agents。
这里的关键词是 work。过去我们使用 Codex、Claude Code、OpenCode 时，常见方式是开一个终端，丢一个任务进去，然后人盯着它跑。等它停了，人再判断下一步。一个人同时盯三五个 session，马上就会被上下文切换拖垮。
Symphony 换了一个组织方式。它让 Linear 这样的项目管理工具变成控制面。每个 issue 是一个工作单元，状态决定是否启动，blocker 决定是否跳过，workspace 决定执行边界，Human Review 决定什么时候交给人。
这就是它和很多多 Agent 框架的差别。LangGraph 关注 stateful graph runtime，AutoGen 关注 agent conversation patterns，CrewAI 关注 Flows 和 Crews。Symphony 更窄，也更工程化。它关心真实 repo 里的工单怎么被持续分发、执行、重试和交接。
架构
源码里最重要的入口是 SPEC.md，不是某个算法实现。它把 Symphony 定义成一个长驻服务：持续读 issue tracker，为每个 issue 创建独立 workspace，在 workspace 里启动 coding agent session。
整个实现可以拆成几层。
WORKFLOW.md 是第一层。它前半部分是 YAML 配置，写 tracker、polling、workspace、hooks、agent、codex 等参数；后半部分是 Markdown prompt，直接变成 Codex 执行 issue 时的规则。
WorkflowStore 每秒检查这个文件。如果 reload 成功，就替换当前 workflow；如果写坏了 YAML，它会保留上一份可用配置。这种小设计很实际，长驻服务最怕配置热更新时把自己弄挂。
调度层是 orchestrator.ex。它是一个 OTP GenServer，维护 running、claimed、completed、retry_attempts、token totals、rate limit 等运行态。每次 tick 到来，它会刷新配置、拉 Linear issue、按优先级排序，再检查状态、blocker、并发槽、worker 槽，决定哪些 issue 可以 dispatch。
执行层由 workspace.ex、agent_runner.ex 和 codex/app_server.ex 组成。每个 issue 先创建或复用一个 workspace。新 workspace 会跑 after_create hook，比如 clone repo、安装依赖。之后 AgentRunner 在这个目录里启动 Codex app-server。
Codex app-server 这层很关键。Symphony 没有简单 shell 一次 prompt，它会完成 initialize、thread/start、turn/start，然后持续读 JSON 事件流。tool call、approval request、turn completed、turn failed、token 统计，都会被接回 Orchestrator。
源码里最值得看的几块
orchestrator.ex 里有个很清晰的 dispatch gate。一个 issue 要被分发，必须是 active state，没有未完成 blocker，没有被 claimed，没有正在 running，还有全局并发、状态级并发、worker 并发容量。
这个 gate 看着朴素，其实很重要。Agent 工程最怕能跑就跑。如果 blocker 没处理、状态不对、并发没有上限，Agent 数量越多，混乱越快。
agent_runner.ex 里还有一个细节：一个 issue 不只跑一轮。Codex turn 正常结束后，Runner 会重新拉 issue state。如果 issue 仍然 active，并且没超过 agent.max_turns，它会在同一个 app-server session 里继续下一轮。续跑 prompt 会提醒它从当前 workspace 和 workpad state 继续，不要重复已经完成的调查和验证。
这比简单 retry 要细。正常 turn 结束不等于工作完成，issue state 才是外部真相来源。
workspace.ex 负责隔离。它把 issue identifier 变成安全目录名，保证本地 workspace 在配置的 root 下，避免路径逃逸。远程 worker 走 SSH，也会在远端创建目录、跑 hook、启动 Codex。
dynamic_tool.ex 目前只提供一个工具：linear_graphql。这让 Codex 在执行过程中可以用 Symphony 配好的 Linear auth 做原始 GraphQL 调用。也就是说，调度器只注入能力，具体怎么维护 workpad、怎么写 comment、怎么更新状态，主要由 workflow prompt 和 repo skills 负责。
和其他工具差在哪
LangGraph 是更通用的 agent runtime。它适合你自己设计 graph、state、checkpoint、人类介入和长期记忆。Symphony 没有给你一个通用 graph 编排器，它直接把问题限定在工程任务队列。
AutoGen 更偏多 Agent 对话结构。两个 agent 怎么聊，多个 agent 怎么分工，谁当 speaker，这些是 AutoGen 的经典场景。Symphony 的并发主要来自多个 issue 独立运行，不是一个任务里一群角色互相开会。
CrewAI 更适合业务自动化。Flow 管状态，Crew 管角色协作。它可以做研究、销售、运营、报告流程。Symphony 更贴近工程现场：工单、workspace、Codex、PR、review、merge。
OpenHands 是完整 coding agent 平台，可以直接作为会写代码的 agent 使用。Symphony 不替代 coding agent，它调用 Codex。它解决的是另一层问题：一堆工单怎么被持续派发给 agent，失败怎么重试，状态怎么回收，人怎么审。
Claude Code Action、OpenCode GitHub Action 这种路径安装更快，适合在 GitHub issue 或 PR 评论里触发一次 job。Symphony 的思路更像一个常驻 daemon。它会持续盯项目 board，管理多个 issue 的生命周期。
怎么落地
README 里有一句前提：Symphony works best in codebases that have adopted harness engineering。这个前提不能跳过。
如果一个 repo 没有稳定测试，没有可信 CI，issue 描述含糊，review 规则也不清楚，Symphony 只会把问题并发放大。Agent 能自动执行 shell，能改代码，能写 comment，甚至可能推动 PR 流转。没有 harness，这就是风险放大器。
真正想试 Symphony，先把几件事整理好。
测试和 CI 要能给出明确反馈。Agent 做完事后，需要一个可以信任的验证信号。
issue 状态机要清楚。哪些状态可以启动，哪些状态必须人工 review，哪些状态是 terminal，blocker 如何表达，这些都要提前定好。
WORKFLOW.md 要写成工程契约，而不是写成愿望清单。里面应该明确状态迁移、workpad、验证、PR review、merge gate、失败处理。
权限要收紧。默认示例里 approval_policy: never，thread_sandbox: workspace-write，这在 trusted environment 可以实验，普通团队照搬会很危险。Linear token、GitHub token、repo secret、SSH worker、hooks 都要按最小权限重新设计。
观测也要补齐。至少要知道哪个 issue 在跑，跑在哪个 workspace，最后一个 Codex 事件是什么，token 和 rate limit 怎样，失败原因是什么，什么时候重试。
我怎么看
Symphony 的价值不在另一个 Agent 框架。它更像一个信号：AI coding 的竞争正在从单次生成能力，往工程工作系统迁移。
当 coding agent 能完成越来越多 routine implementation 后，团队会遇到新问题：谁来分发任务，谁来判断 ready，谁来管理上下文，谁来收敛失败，谁来保证审查，谁来留下审计轨迹。
Symphony 给出的答案很工程化：让 issue tracker 做控制面，让 workspace 做隔离边界，让 WORKFLOW.md 做版本化契约，让 Codex app-server 做执行协议，让 dashboard/API 提供最低限度的运行观测。
它现在还不适合当作低门槛产品直接推广。官方自己也说这是 engineering preview，Elixir 实现是 prototype。真正可借鉴的是这套抽象。
总结
Symphony 源码读完，我更愿意把它看成 OpenAI 对 coding-agent 组织方式的一次公开样板。
它提醒我们一件事：Agent 真正进入团队，不会停在聊天框和终端里。它需要接入 issue、workspace、CI、review、merge、follow-up issue 这条链路。
对工程团队来说，下一步不是马上复制 Symphony。更现实的路径是先把 harness 做扎实，把 issue 状态机和验证信号整理清楚，再考虑 unattended orchestration。否则 agent 并发越多，返工越多。
参考资料：OpenAI Symphony 官方文章、openai/symphony GitHub 仓库、Codex app-server 文档、LangGraph / AutoGen / CrewAI / OpenHands / Claude Code Action / OpenCode 官方文档。
