从公开资料看，Symphony 不是一个通用 Agent 框架，也不是一个新的 IDE 代理。它更接近一个长期运行的编排服务：持续轮询工单系统，把每个工单映射为一个隔离工作区中的 Codex 运行单元，并围绕状态、重试、观测与交接建立完整闭环。
WORKFLOW.md，把执行隔离到按工单划分的 workspace，把会话驱动能力交给 codex app-server。OpenAI 在 2026 年 4 月 27 日发布的官方文章中，把 Symphony 定义为一个将项目管理板转化为 coding agents 控制平面的开源规范；其直接动机不是“让代理会写代码”，而是解决人类在多会话监督中的注意力瓶颈。
根据 OpenAI 的文章，交互式 coding agents 在能力提升后，新的瓶颈转移到了工程师的上下文切换成本。工程师往往能同时盯住三到五个会话，但再往上就需要频繁切换终端、反复 nudging、重启停滞任务。Symphony 的核心思路是把监督对象从“一个个会话”改成“一个个任务”。
从公开表述推断，Symphony 的目标不是替代人类判断，而是把人类从会话级别的微观监督中解放出来，转向在任务优先级、验收标准和最终评审层面介入。
README 明确写到 Symphony 最适合运行在已经采用 harness engineering 的代码库中。OpenAI 在 2026 年 2 月 11 日的文章里将这一方法概括为“Humans steer. Agents execute.”，并强调知识必须落在仓库内、验证要可自动执行、代理可读性要优先于传统的人类中心组织方式。
| 观察项 | 截至 2026-05-12 的公开信号 | 含义 |
|---|---|---|
| 仓库描述 | “turns project work into isolated, autonomous implementation runs” | 强调工作编排，而非单次代码生成 |
| 仓库规模 | GitHub 页面显示约 23.4k stars、2.2k forks、12 commits、无 release | 传播热度高，但版本发布仍早期 |
| 文档措辞 | README 与 Elixir README 均提示 preview / prototype / trusted environments | 生产采用需二次加固 |
| 实现形态 | 主仓库核心是 SPEC.md，附带实验性 Elixir/OTP 参考实现 |
OpenAI 希望传播的是模式与接口，而非单一官方守护进程 |
Symphony 的规范把系统拆成六层：策略层、配置层、协调层、执行层、集成层与观测层。这个拆法的重点在于把“任务政策”与“运行机制”分离，从而让不同语言、不同组织都能复刻同一套工作模型。
在规范里，每个 issue 会被归一化成稳定的领域对象，包含标识符、标题、描述、优先级、状态、标签、阻塞关系等信息。Orchestrator 定时轮询 issue tracker，判定哪些任务具备资格进入执行队列，再为其分配唯一工作区和代理运行尝试。
| 设计边界 | Symphony 的选择 | 影响 |
|---|---|---|
| 系统职责 | Scheduler / runner / tracker reader | 保持核心简单，把业务动作下放给代理和仓库技能 |
| 策略来源 | 仓库内 WORKFLOW.md |
流程与代码共同版本化，便于团队自定义 |
| 运行状态 | 内存中维护调度状态，重启恢复依赖 tracker 与文件系统 | 降低持久化复杂度，但不追求分布式强一致 |
| 安全姿态 | 规范不强制唯一审批/沙箱策略 | 可适配不同环境，但需要组织自己补足安全治理 |
| 目标对象 | 长期运行的自动化服务 | 比 CLI 脚本更稳定，也比单次会话更可运维 |
after_create、before_run、after_run、before_remove 等 hook。WORKFLOW.md 渲染成提示词，通过 codex app-server 启动 thread 和 turn。OpenAI 官方文章明确提到，Symphony 让工作从会话和 PR 中解耦。有些 issue 会产生多个 PR，有些 issue 只是调研或分析，并不一定触达代码库。由此可见，Symphony 的上层抽象是deliverable-oriented work，而不是单一代码补丁管线。
Elixir 版本是一个实验性参考实现，但其结构已经相当完整：既有长期运行服务需要的 supervision 风格，也有观测界面、配置解析、路径安全和远端 worker 支持。它说明 OpenAI 并不只是在写 spec，而是在验证 spec 的可操作性。
| 模块 | 职责 | 关键信号 |
|---|---|---|
Orchestrator |
轮询、并发控制、重试、运行态跟踪 | 使用 GenServer；维护 running、claimed、completed、retry_attempts 等状态 |
Workflow / WorkflowStore |
读取并热更新 WORKFLOW.md |
前者解析 YAML front matter；后者缓存 last known good workflow |
Config |
把工作流配置转成 typed settings | 负责 approval policy、sandbox、workspace root、tracker 等语义校验 |
Workspace |
创建与清理 issue 级工作区 | 支持本地与 SSH worker；结合 PathSafety 防止路径逃逸 |
AgentRunner |
为单个 issue 驱动 Codex 多轮执行 | issue 仍活跃时继续 turn，直到达到 max_turns 或任务完成 |
Codex.AppServer |
对接 Codex app-server | 通过 stdio JSON-RPC 2.0 风格消息建立 initialize / thread / turn / tool 调用闭环 |
Linear.Adapter |
对接 Linear GraphQL | 支持候选任务拉取、状态刷新、评论创建、状态迁移 |
StatusDashboard / HttpServer |
人类可观测性 | Phoenix LiveView + JSON API，不把运维信息藏在黑盒里 |
Elixir README 直接给出的理由是 BEAM/OTP 擅长监督长期运行进程，且支持热代码重载，不需要在开发期中断已经运行的子代理。这个选择并非偶然，因为 Symphony 的本质不是一次性 CLI，而是会持续面向“多任务、多重试、可恢复”的服务。
WORKFLOW.md 是真正的策略内核参考实现附带的 WORKFLOW.md 非常关键。它不只写“你是一个代理”，而是定义了 issue 状态机、workpad 规范、PR 反馈处理协议、blocked-access escape hatch、验证规则和 land 流程。这意味着 Symphony 的“聪明”有很大一部分并不在 orchestrator 代码里，而是在仓库版本化的工作约束里。
前置 YAML 定义 tracker 类型、project slug、workspace root、hooks、agent 并发度、Codex 命令、审批策略与沙箱策略。
Markdown body 作为 prompt template，经 Solid 渲染 issue 变量与 attempt 信息，最终决定代理如何操作 Linear、Git、PR 与验证流程。
OpenAI 开发者文档说明，codex app-server 支持基于 JSON-RPC 2.0 风格消息的双向通信，默认传输是 stdio JSONL，同时有 thread/start、thread/resume、turn 事件与 dynamic tool calls。Elixir 参考实现中的 Codex.AppServer 正是围绕这套协议构建：先 initialize，再创建 thread，随后在 turn 中监听消息、处理动态工具调用与审批结果。
| 能力 | 在 App Server 文档中的对应 | 在 Symphony 中的用途 |
|---|---|---|
| 双向协议 | stdio / WebSocket 上的 JSON-RPC 风格通信 |
让 orchestrator 能以进程方式控制会话 |
| Thread 生命周期 | thread/start、thread/resume、thread/read |
让单 issue 任务拥有持续上下文 |
| Turn 事件 | turn/started 等事件流 |
支撑进度观测与多轮继续执行 |
| Dynamic tools | item/tool/call 请求/响应流 |
为 Linear GraphQL 等 repo-local 工具注入调用能力 |
| 审批与沙箱 | approval / sandbox policy 字段 | 决定在可信环境中使用多高自治级别 |
Symphony 的价值是真实的，但价值来自组织能力与仓库治理提升后的复利，而不是把一个仓库 clone 下来就能直接复现。它更像一套 operating model，而不是“拿来即用的自动开发神器”。
WORKFLOW.md 行为契约执行。| 风险面 | 具体体现 | 判断 |
|---|---|---|
| 前提门槛高 | 若仓库缺少高质量文档、自动化验证、可调用工具与清晰状态流，Symphony 会退化为大规模无效自动化 | 这是最大的落地门槛 |
| 安全姿态需自担 | 规范明确不强制统一审批或沙箱 | 企业环境必须自行补上权限、审计和网络隔离 |
| 任务适用性有限 | OpenAI 官方文章明确承认，强判断、强歧义、强策略性工作仍更适合交互式会话 | 不应全盘替代工程师 |
| 实现成熟度早期 | 无正式 release，文档也强调 prototype | 更适合内测、改造和二开 |
| 状态机可能过刚 | 官方文章承认早期把代理当 rigid nodes in a state machine 并不好用，后来转向目标导向 | 说明流程设计要给模型留推理空间 |
最适合的不是“刚开始尝试 AI 编码”的团队，而是已经具备以下条件的团队：任务系统规范、文档在仓库内、CI 足够可靠、验收标准可被代理执行、对 agent-generated code 有审阅与回滚机制。尤其是大型 monorepo、基础设施迁移、批量 routine implementation、跨时区异步协作场景，会更容易体现收益。
如果团队当前仍高度依赖口头知识、零散聊天记录、人工点击验证和模糊需求，那么优先级应先放在补齐 harness，而不是上 Symphony。否则 orchestrator 只会把原本局部的不确定性放大到系统级。
第一步先做 harness engineering：让文档、验证、工具和反馈回路可被代理读取。第二步再把一个低风险项目的 issue 流转接到 Symphony 风格 orchestrator。第三步最后才考虑多仓、多 worker、远程 SSH 与更高自治等级。
| 材料 | 日期/状态 | 用途 |
|---|---|---|
GitHub 仓库主页 openai/symphony |
访问于 2026-05-12 | 核对仓库描述、stars/forks、commit 数、语言占比与 README 摘要 |
SPEC.md |
Draft v1 | 分析规范层职责边界、目标与非目标、核心领域模型和组件划分 |
elixir/README.md 与 elixir/WORKFLOW.md |
主分支当前版本 | 分析运行方式、配置项、状态机约束、提示词策略和依赖栈 |
| Elixir 关键模块源码 | 主分支当前版本 | 分析 orchestrator、workspace、agent runner、workflow store、app-server client 的真实实现 |
| OpenAI 官方文章《An open-source spec for Codex orchestration: Symphony》 | 2026-04-27 | 核对项目背景、价值主张、适用范围与组织收益表述 |
| OpenAI 官方文章《Harness engineering: leveraging Codex in an agent-first world》 | 2026-02-11 | 理解 Symphony 的方法论前置条件 |
| OpenAI 开发者文档《Codex App Server》 | 访问于 2026-05-12 | 核对 stdio / thread / turn / dynamic tools / approval / sandbox 协议能力 |
完