Symphony 是 OpenAI 出的一个「把项目工作变成隔离、自主的实现运行」的编排服务规范与参考实现。它是一个长期运行的守护进程：持续从 issue tracker（当前规范以 Linear 为例）读取工作，为每个 issue 建独立工作区，并在其中拉起一个编码 agent（Codex）会话自主完成任务，agent 给出 CI 状态、PR 评审、复杂度分析、讲解视频等「工作证明」，被接受后安全合入 PR——让团队「管理工作」而非「盯着编码 agent」。值得注意的是，仓库的核心交付物是一份 2169 行的 SPEC.md 规范，鼓励你让自己的编码 agent 按规范实现；Elixir 版只是实验性参考实现。Apache-2.0，明确标注为「低调的工程预览」，仅供可信环境测试。
来源：README/SPEC.md 第1节 Problem Statement；GitHub openai/symphony，desc 查看 GitHub 仓库 →短时间内冲到 2.4 万星、2401 fork，最直接的原因是它出自 OpenAI 官方、且配了博客（open-source Codex orchestration），自带巨大关注度。更深一层，它代表了 OpenAI 推的「harness engineering → 管理工作而非监督 agent」这条叙事的下一步，并用一种少见的方式呈现：仓库主体是规范 + 让 agent 自己实现，而非一个现成产品。这种「spec 优先」的姿态本身就是话题，加上 Codex 自主跑 Linear 工单的演示，传播力很强。
来源：GitHub 24,418 stars / 2,401 forks，created 2026-02-26；README harness engineering 链接/demo按固定节奏轮询 issue tracker，挑选活跃状态的工单，以有界并发分派；为每个 issue 建确定性的独立工作区并跨运行保留，在其中跑编码 agent 自主实现，工单状态变得不合格时停止对应运行。
来源：SPEC 1/2 Goals、8 Polling/Scheduling；README demo把运行策略（agent 提示词、运行时设置、工单处理与交接规则）放进仓库的 WORKFLOW.md，随代码版本化；Workflow Loader 解析其 YAML front matter + 提示词模板，Config 层做带默认值与环境变量间接引用的类型化校验。
来源：SPEC 5 Workflow Specification、6 Configurationorchestrator 持有单一权威运行时状态，管理 issue 编排状态、run attempt 生命周期、转移触发、幂等与恢复规则；含指数退避重试、活跃运行对账、启动时终态工作区清理，可在无持久数据库下靠 tracker/文件系统驱动重启恢复。
来源：SPEC 7 State Machine、8.4/8.5 Retry/ReconciliationWorkspace Manager 把 issue 映射到工作区路径、保证 agent 命令只在 per-issue 目录内执行、跑生命周期 hook；Agent Runner 定义启动契约、会话启动职责、流式回合处理、上行运行时事件、审批/工具调用/用户输入策略与超时错误映射，是接入编码 agent 的标准接口。
来源：SPEC 9 Workspace Management、10 Agent Runner ProtocolSymphony 把系统分成策略/配置/协调/执行/集成/可观测六层以便移植；仓库提供完整 SPEC.md，可直接让编码 agent「按此规范实现」，也提供 Elixir 实验参考实现，二者解耦。
来源：SPEC 3.2 Abstraction Levels；README Option 1/2Symphony 的真正核心是规范而非代码：SPEC.md 定义了八大组件——Workflow Loader、Config Layer、Issue Tracker Client（Linear 适配）、Orchestrator（轮询/分派/重试/对账）、Workspace Manager（工作区生命周期与安全不变量）、Agent Runner（编码 agent 接入协议）、可选 Status Surface、Logging——并刻意把边界划清：Symphony 只是「调度器/运行器 + tracker 读取器」，工单写入（状态流转、评论、PR 链接）由编码 agent 用其工具完成；成功运行可停在工作流定义的交接态（如 Human Review）而非必须 Done。架构按六层（策略/配置/协调/执行/集成/可观测）组织以利移植。参考实现用 Elixir 写：基于 Phoenix/LiveView + Bandit（Web/状态面）、req（HTTP）、yaml_elixir 解析 WORKFLOW.md、solid 渲染提示词模板、ecto 建模，编译为 escript CLI；这套技术栈天然契合「长期运行、并发、容错」的守护进程定位。它不要求持久数据库，运行时状态主要在内存，靠 tracker + 文件系统恢复。
来源：SPEC 3 System Overview/边界说明；elixir/mix.exs deps（phoenix/bandit/req/yaml_elixir/solid/ecto）中心为项目本体，内环 = 核心功能模块，外环 = 关键技术依赖；按 deep.json 中的 core_features 与 tech_stack.key_deps 自动生成
bandit (HTTP server)phoenix / phoenix_live_viewreq (HTTP client)yaml_elixir (解析 WORKFLOW.md)solid (Liquid 提示词模板)ectoescript CLI适合：①已经在做 harness engineering、希望把「盯 agent 干活」升级为「管理工单流」的工程团队；②想要把 Linear 工单自动派给 Codex 自主实现、并以 CI/PR 评审/复杂度/讲解视频作为验收证据的团队；③想研究 OpenAI 对「spec 优先 + agent 自实现」这套方法论的人，或想按规范用自己喜欢的语言移植一套编排器的开发者。不适合：想要开箱即用产品、富 Web 控制台或多租户控制面的人（明确是 Non-Goal），以及不接受在可信环境跑自主 agent、对沙箱/审批要求严格却期望框架内建强管控的团队。
来源：SPEC 2.2 Non-Goals/README Requirements，结合定位推断仓库无正式 GitHub Release，以规范 + 参考实现的形式持续维护，主分支活跃（最近 push 2026-05-20）。整体定位为工程预览（engineering preview），规范版本当前以 Linear 作为 tracker 示例。
来源：GitHub 无 releases；pushed_at 2026-05-20；README/SPEC 版本说明Symphony 与其说是一个工具，不如说是 OpenAI 对「agent 时代如何组织工程工作」的一份观点声明：把开发从「监督 agent」抬升到「管理工单流」，并用一份相当严谨的规范把编排器该有的状态机、并发、安全和 agent 接入协议讲清楚，再大方地说「你让 agent 照着实现就行」。作为方法论与规范，它很有学习和移植价值；但作为可用系统，它仍是工程预览、前置门槛高、安全管控靠自负、参考实现只有 Elixir 且只接 Linear。适合走在 harness engineering 前沿、用 Codex 的团队认真研究和小范围试验，普通团队短期内更可能从它的 SPEC 思路而非现成代码中获益。
来源：综合 README/SPEC 定位与边界、elixir 实现、发布状态的事实判断Symphony 是 OpenAI 出的一个「把项目工作变成隔离、自主的实现运行」的编排服务规范与参考实现。它是一个长期运行的守护进程：持续从 issue tracker（当前规范以 Linear 为例）读取工作，为每个 issue 建独立工作区，并在其中拉起一个编码 agent（Codex）会话自主完成任务，agent 给出 CI 状态、PR 评审、复杂度分析、讲解视频等「工作证明」，被接受后安全合入…
symphony 的核心功能包括：工单驱动的自主实现守护进程、WORKFLOW.md 仓库内策略契约、编排状态机 + 恢复与对账、工作区安全隔离 + Agent Runner 协议、规范优先、可移植到任意语言。
短时间内冲到 2.4 万星、2401 fork，最直接的原因是它出自 OpenAI 官方、且配了博客（open-source Codex orchestration），自带巨大关注度。更深一层，它代表了 OpenAI 推的「harness engineering → 管理工作而非监督 agent」这条叙事的下一步，并用一种少见的方式呈现：仓库主体是规范 + 让 agent 自己实现，而非一个现成产品。
适合：①已经在做 harness engineering、希望把「盯 agent 干活」升级为「管理工单流」的工程团队；②想要把 Linear 工单自动派给 Codex 自主实现、并以 CI/PR 评审/复杂度/讲解视频作为验收证据的团队；③想研究 OpenAI 对「spec 优先 + agent 自实现」这套方法论的人，或想按规范用自己喜欢的语言移植一套编排器的开发者。