为什么 OpenAI 开发了 Symphony 并免费开源

하이라이트

• Symphony 解决了工程师在上下文切换影响生产力前只能同时监督 3 到 5 个 Codex 会话的注意力瓶颈。

• 系统通过轮询 Linear 中的任务 ID（如 SYN7）并自动将状态从“待办”更改为“已完成”来独立执行任务。

• 安装方式包含向编程代理发送一份超过 2000 行的规范文件，由代理根据指令自行构建出 Python 或 Go 等不同语言版本的 Symphony。

• 工作流配置文件 workflow.yaml 通过 YAML 前置数据管理 API 密钥、激活状态、工作区根目录以及 Codex 启动命令。

• 通过设置 create-after 和 run-after 钩子，Symphony 可以实现自动克隆代码库、切换分支、提交代码并推送拉取请求 (PR)。

타임라인

1. 00:00 - 01:09

   解决人类注意力瓶颈的自动化方案

   人工管理代理的速度跟不上代理本身的执行速度，导致开发规模无法扩大。Symphony 的设计核心在于移除持续的人工监督，利用看板系统作为人机协作的缓冲带。这种模式将人类的角色从“操作员”转变为“审查者”，从而提升整体产出效率。

   • 单个工程师在生产力受损前只能同时管理 3 到 5 个 Codex 会话。
   • Symphony 允许人类仅在看板上投放任务，随后由系统自动启动代理完成工作。
   • 代理仅在需要人工审查的特定环节才会介入并通知人类。
2. 01:10 - 02:08

   基于 Linear 任务追踪的自动化工作流演示

   在实际操作中，当 Linear 上的任务状态切换为“待办”时，Symphony 会立即介入。即便遇到代码错误，Codex 也会尝试自我修复并更新任务状态。最终产出的文件结构清晰地组织在对应的工作区内，并由代理留下执行反馈评论。

   • 系统持续轮询 Linear 中的任务，并在识别到特定 ID 后开始构建 TypeScript 和 BUN 应用。
   • Codex 在处理过程中能自主识别并修复 GraphQL 验证错误等技术故障。
   • 任务完成后，Symphony 会自动创建以任务 ID 命名的工作区目录并存储生成的源代码。
3. 02:09 - 03:52

   基于提示词的分布式安装与构建方式

   这种“诡异”的安装方式实际上赋予了用户对工具的责任感。由于每个人的实现版本可能在语言和功能上有所不同，它既是维护的挑战，也是定制化的机会。大语言模型在 Python 上的强势表现使其成为构建此类自动化工具的首选目标语言。

   • 除了传统的 Elixir 克隆安装，用户可以通过向代理发送 2000 行规范文件来生成自定义版本。
   • 这种灵活的构建方式允许用户根据偏好生成 Python、Go 或基于不同 SDK（如 Claude）的 Symphony。
   • 配置文件需要 Linear API 密钥以及定义代理行为的 Markdown 提示词模版。
4. 03:53 - 06:21

   高级钩子配置与团队协作愿景

   通过扩展工作流，Symphony 能够处理真实的工程项目而不仅仅是简单的文件生成。它将整个团队的 AI 交互透明化，让每个开发者都能观察到他人的提示词和任务进度。这种中心化的代理模式旨在解决多人协作中可能出现的代码冲突和逻辑重叠问题。

   • create-after 和 run-after 钩子支持克隆代码、创建分支、暂存文件以及推送 PR 等复杂 Git 操作。
   • Symphony 作为一个核心代理，为团队提供统一的技能、工具集和工作流，避免工作流碎片化。
   • 虽然 Multica 在设置便捷性和任务调度上更具优势，但 Symphony 提供了类似硬件套件的高自由度定制空间。