核心数据与产品定位

OpenAI近期开源了名为Symphony的项目，其GitHub仓库在开源后迅速获得了十五K（15K）的Star数，显示出极高的社区关注度。OpenAI内部披露的数据显示，团队在使用Symphony后，落地的Pull Request（PR）数量增长了百分之五百（500%）。为了直观展示其自动化程度，博主在演示中为自己网站开发一个小功能时，自己敲键盘的次数为零。这三个数字共同构成了OpenAI此次发布的核心叙事：Symphony并非又一个简单的代码生成Agent，而是对项目管理流程的重构，旨在让Agent自主运行任务。

“Symphony不是又造了一个写代码的 agent，而是把管项目这件事重新设计了一遍，留给 agent 自己跑。”

从技术架构上看，Symphony被定义为将项目工作转化为一组互相隔离的自治任务执行。这里强调的三个关键词——隔离、自治、运行——决定了Symphony的本质是一个调度器，而非传统的编码工具。它的工作逻辑是监控Linear看板上的Ticket，当处于“To Do”或“In Progress”状态且没有未关闭的Blocker时，Symphony会派遣一个Agent进入专属Workspace执行任务。Agent的核心代码由OpenAI的Codex App Server提供，而Symphony仅负责调度逻辑，包括谁该跑、跑多久、超时重试策略及收尾工作。

调度机制与核心特性

Symphony的调度机制基于官方文档中定义的Service Spec，其核心特性包括轮询、隔离工作区和智能重试。默认情况下，Symphony每30秒对Linear看板进行一次轮询（Polling），确保新Ticket或状态变更能在半分钟内被捕获。每个Issue都拥有独立的Workspace，这不仅防止了任务间的资源冲突，还允许在任务失败后保留上下文，便于下次从断点继续。

在错误处理方面，Symphony采用了指数退避重试策略，避免因单次失败而彻底阻断任务流程。值得注意的是，Symphony本身不直接修改Linear上的Ticket状态或评论，它只读取状态；是否回复评论或更新状态，由Agent通过工具自行决定。这种设计将Symphony与Codec CI或Clo Code等工具区分开来：后者的入口是终端，用户需主动交互并审查代码；而Symphony的入口是Linear看板，用户只需提交Ticket，Agent自动执行。

“Symphony 它自己不写 ticket，只读 linear 的状态，要不要在 linear 上回复评论修改状态，是 agent 自己用工具去做的。”

这一入口的转变具有深远意义。它意味着非技术人员（如产品经理、设计师、运营）也能通过Linear向项目派活，因为他们只需掌握提Ticket的能力，而无需理解代码细节。Symphony实际上将这些角色转化为Agent的调度者，实现了从“盯着Agent写代码”到“管理项目”的工作流转变。

开源性质与参考实现

OpenAI明确声明，Symphony不是产品，不会作为正式产品进行维护，而是作为展示Codex App Server与Workflow工具结合能力的参考实现开源。该实现基于Alexa框架编写，尽管博主对Alexa并不熟悉，但官方提供了完善的文档，降低了上手难度。Alexa负责轮询Linear寻找适配工作，为每个Issue创建工作区，启动Codex，发送提示词并推动其工作，直到Issue被解决。

要运行Symphony，需要以下关键组件： 1. 代码仓库：Agent需要克隆并修改的目标项目。 2. Linear API Key：用于任务调度和管理的认证。 3. Mise工具：用于管理依赖和运行环境（MacOS可通过brew install mise安装）。

“Symphony 不是产品，OpenAI 自己说不会把它当产品维护。就是放出来给大家看，Codex App Server 接 Workflow 工具能跑成什么样。”

安装过程相对标准化。首先通过Mise安装Alexa，然后克隆Symphony仓库，在Alexa目录下执行一系列配置命令。启动命令为mise exec bin symphony workflow.md，其中workflow.md是关键配置文件，定义了项目Slug、代码仓库URL等参数。若启动时出现风险提示，需添加相应参数以确认知晓潜在风险，因为该实现缺乏常规的安全防护机制。

本地部署与配置详解

在本地运行Symphony需要完成Linear和代码环境的配置。首先，在Linear中创建项目（如“Very Small Woods”），获取项目ID（URL中的部分，如770b6e8）。其次，在Linear账号设置中的“Security and Access”下创建Personal API Key，并将其配置为环境变量。

在代码侧，克隆Symphony仓库后，需修改workflow.md文件。该文件包含两个关键参数： - project_slug：填入Linear项目的ID。 - hooks.after_create.get_clone：填入目标代码仓库的URL，Agent将在处理Issue时克隆此仓库。

“project slug 配置为刚才我们在 linear app 中创建的项目的 ID... hooks 这里的 after create，要克隆一个目录，这个目录呢就是大家的代码仓库的 URL。”

启动Symphony后，它会监听指定的Linear项目，默认每5秒刷新扫描一次。当发现状态为“To Do”的Issue时，Agent会将其状态更新为“In Progress”，并在Linear Issue下发布工作计划和验收标准。整个过程完全自动化，用户无需介入代码编写。

实战演示：自动修复Email链接

博主通过一个具体案例演示了Symphony的工作流程。目标是在其官方网站（Very Small Woods项目）的页脚中，将不可点击的Email地址改为可点击的链接（添加mailto:协议）。

  1. 创建Issue：在Linear中创建Issue，描述需求，状态设为“To Do”，优先级设为“High”，并指派给博主自己。
  2. Agent响应：Symphony在5秒内检测到新Issue，开始处理。在Linear Issue下，Agent发布了包含工作计划、验收标准和验证方法的更新。
  3. 执行与验证：Agent在本地Workspace克隆代码仓库，修改代码（添加mailto:前缀），并尝试编译验证。博主观察到Issue下出现了Token消耗统计，反映了Prompt和对话的开销。

“那究竟这个是怎么工作的呢？我们来看看在本地它得到了一些什么。咱们现在回到另外一个终端，在 code 目录下有个 symphony workspaces，这里面列出了所有 issue 对应的目录。”

处理完成后，Agent在Linear Issue下更新状态。博主检查本地Workspace（如Issue #8对应的目录），发现代码已正确修改，Email链接具备点击功能。尽管过程中出现了一些GET操作的网络错误（博主推测是本地环境或网络问题），但核心功能已实现。这证明了Symphony能够独立完成任务的调度、执行和反馈闭环。

总结与展望

Symphony通过引入Linear作为入口，重构了AI辅助开发的流程。它将开发者从微观的代码审查中解放出来，转向宏观的项目管理。虽然目前Symphony仅是参考实现，存在安全风险且依赖特定框架（Alexa），但其展示的可能性巨大。

对于非技术人员，Symphony降低了参与项目开发的门槛；对于开发者，它自动化了重复性任务。博主在演示中强调，自己敲键盘的次数为零，这不仅是技术的胜利，更是工作流变革的体现。未来，随着Codex App Server的成熟和调度器的优化，Symphony这类工具可能成为软件开发的标配。

“我从盯着 Agent 写代码变成管项目，Agent 自己开工。这一句听起来好像没什么，但你想想这意味着什么？不会写代码的人也能给项目派活。”

Symphony的开源为社区提供了探索AI Agent调度能力的起点。尽管它不是最终产品，但其架构设计和实践案例为构建更智能、更自主的开发工作流提供了宝贵参考。用户可通过配置Linear和代码仓库，快速体验Agent自主完成任务的全过程，感受从“人找活”到“活找人”的转变。