Symphony: Codex 编排的开源规范

概述

Symphony 是一个开源规范，定义了如何使用问题追踪器（issue tracker）作为控制平面来编排编程代理（coding agents）。它使每个开放的任务都能分配到一个专用的代理工作区，该工作区会持续运行直到任务完成，从而减少了对单个 Codex 会话的人工监督需求。

技术规范

Symphony 规范是一个单一的 SPEC.md 文件，描述了一个与语言无关的服务。它概述了核心组件，如工作流加载器、问题追踪器客户端、编排器、工作区管理器、代理运行器以及可选的状态表面。实现必须遵守安全不变性：代理仅在每个问题的专用工作区路径内运行，工作区密钥被清洗为 [A-Za-z0-9._-]，且工作区路径保持在配置的根目录内。

工作流定义 (WORKFLOW.md)

每个仓库通过添加一个包含 YAML front matter 和提示词模板的 WORKFLOW.md 文件来采用 Symphony。Front matter 声明了追踪器类型（目前为 linear）、轮询间隔、工作区根目录、钩子（hooks）以及代理/Codex 设置。提示词模板接收规范化的问题对象和一个可选的 attempt 变量，从而允许为首次运行、后续运行和重试提供不同的指令。

编排机制

Symphony 按固定频率轮询追踪器，在全局和每个状态的并发限制内分发工作，并维护内存中的运行时状态。它在每次轮询时协调正在运行的代理，通过可配置的超时检测停滞，并使用指数退避机制重试失败的尝试。成功的运行可能会在工作流定义的分发状态（例如 Human Review）结束，而不是要求追踪器达到终止状态。

实现与采用

参考实现使用 Elixir 编写，选择它是因其并发原语，但该规范刻意保持极简，以便代理可以用任何语言实现 Symphony。OpenAI 在内部使用了 Symphony，并观察到在某些团队中，前三周内成功合并的 pull requests 增加了 500%。开源后，截至 4 月 23 日，该仓库已获得超过 15K 个 GitHub stars，Linear 的创始人也注意到发布后创建的工作区数量激增。

影响与未来工作

通过将代理视为目标驱动的工作者而非微观管理的会话，Symphony 将瓶颈从编写代码转向了管理代理工作。团队现在可以廉价地提交推测性任务，让代理探索想法，并将人力集中在更难的探索性问题上。OpenAI 将 Symphony 定位为参考实现，并鼓励开发者将他们的编程代理指向该规范和仓库，以为他们自己的环境构建定制版本。