Transcript
00:00:00这是 OpenAI 的 Symphony，一个用于编排长期运行代理的开源工具，它使用
00:00:05现有的问题追踪器（如 Linear）来帮助您的代理在没有任何
00:00:10人类监督的情况下自主完成任务。但为什么代理在使用它之前不需要从头开始构建呢？
00:00:14它是否仅支持 Codex CLI？这是否意味着 OpenAI 将推出更多
00:00:18开源工具？点击订阅，让我们一起一探究竟。
00:00:25Symphony 的出现是因为 OpenAI 遇到了人类注意力瓶颈，这意味着工程师
00:00:30在上下文切换开始负面影响生产力之前，只能同时监督 3 到 5 个 Codex 会话。
00:00:35当然，这无法进行规模化。那么猜猜 OpenAI 是如何解决
00:00:41“代理快、人类管理慢”的问题的？他们裁掉了人类管理员。某种程度上是这样。
00:00:47因为有了 Symphony，人类只需将任务放在看板上，一个新的代理就会被启动来完成该任务，
00:00:52代理只有在需要审查时才会让参与进来。
00:00:55但 Symphony 与 Multica 和 Conductor 等类似工具相比如何呢？那么，
00:00:58观看演示，一切都会变得非常清晰。不过在开始之前，我只想说
00:01:03Symphony 的安装过程是我这辈子见过最诡异的。或者，它也可能是
00:01:07安装某种东西最天才的方式。我们稍后再谈。
00:01:10首先，让我们看一个基础示例。现在 Symphony 正在运行，
00:01:14轮询 Linear 中的任务。在 Linear 中，我将创建一个新问题，
00:01:18内容是使用 TypeScript 和 BUN 构建一个 Hello World 应用。
00:01:22目前 Symphony 还没有配置为处理积压任务。所以我把状态改为“待办”
00:01:27并点击“创建问题”。请记住该任务的 ID，即 SYN7。
00:01:31过了一会儿，Symphony 识别到了该任务的 ID。几秒钟后，
00:01:36我们遇到了一个 GraphQL 验证错误，这不是什么大事，Codex 很容易就能修复它。
00:01:41在那之后，我们可以看到 Codex 已经完成了工作，并将问题状态
00:01:45从“待办”改成了“已完成”，并由 Symphony 在此留下了一条评论。这意味着如果我们去
00:01:49我们的 Symphony 工作区目录（稍后会详细介绍），我们可以看到有一个
00:01:53与我们问题 ID 相同的新工作区。进入该工作区，可以看到为
00:01:58Hello World TypeScript BUN 应用创建的文件列表。如果我们进入 source 目录，
00:02:04可以看到应用的代代码就在这里。这基本上就是 Symphony 的核心概括。
00:02:08现在让我们看看如何设置它。根据这个代码库，有两种方式
00:02:12可以安装 Symphony。选项二是我们习惯的方式：设置 Elixir，
00:02:16克隆代码库，然后构建代码并使用现有的工作流文件运行它。
00:02:20然而选项一可能是最诡异、也可能是最超前的安装方式。
00:02:25你基本上只需给你的编程代理发送这个提示，它就会读取规范文件，
00:02:30该文件长达 2000 多行。但它基本上为你的代理提供了
00:02:34关于如何构建 Symphony 的详细说明，这太疯狂了，因为如果大家都走这条路，
00:02:39没有两个版本的 Symphony 会是一模一样的。有些人的版本可能会有
00:02:43不同的功能和语言，这对于 OpenAI 来说简直是维护和支持的噩梦。
00:02:47但它也有点天才之处，因为如果你构建了自己的 Symphony 版本，
00:02:51你会对它有责任感。你会修复漏洞，添加功能，
00:02:55并实质性地维护它。如果你不想让 Symphony 使用 Linear 或
00:02:59Codex，那全凭你决定。有人构建了在 Charm CLI 上运行的 Go 版本 Symphony，
00:03:04还有人构建了一个由 Claude SDK 驱动的版本。我没那么有创意，
00:03:09所以我把默认提示放入使用 GPT 5.5 Low Effort 的 Codex 中，它给了我一个 Python 版本的
00:03:15Symphony，这很合理，因为大语言模型非常擅长 Python。一旦完成，
00:03:19你需要一个 Linear 个人 API 密钥，你可以从“安全与访问”中获取，
00:03:23点击这里即可创建一个。然后你需要将该密钥添加到你的工作配置文件中，
00:03:28这个文件告诉 Symphony 如何工作，包含一些 YAML 前置数据，
00:03:32其中当然包括 API 密钥、让代理知道何时可以处理任务的激活状态，
00:03:37以及工作区根目录和 Codex 命令，这是 Symphony
00:03:42用来启动编程代理的 shell 命令。下面是发送给编程代理的
00:03:46针对每个问题的 Markdown 提示。如果你感兴趣，可以在 OpenAI 的代码库中访问他们的 workflow.yaml 文件。
00:03:51但就目前而言，这个工作流还不适合真正的项目。假设我想修改
00:03:56我一直在开发的电影仿真应用。我需要添加一个 create-after 钩子，它在
00:04:01Symphony 为问题创建工作区后运行，这个钩子会先将代码库克隆到
00:04:06工作区目录，然后在该库中切出一个新分支。我还添加了一个 run-after
00:04:10钩子，在 Codex 完成问题处理后运行。它会暂存文件，然后
00:04:15创建一个新提交，随后推送分支并使用这些值创建一个新的拉取请求 (PR)。
00:04:20现在如果我使用 UV 运行 Symphony（UV 也被 OpenAI 收购了，那是另一个
00:04:25视频的主题），它正在轮询新问题。如果我创建一个新问题来更新 README，只需
00:04:30在显示批量处理的部分，使用通配符而不是显示多个文件，同样，
00:04:35我会将它从“积压”改为“待办”，然后点击“创建问题”。现在 Symphony 已经识别到了
00:04:40该问题。如果我们查看 Symphony 工作区目录，可以看到有一个匹配
00:04:45我们问题 ID 的新文件夹，其中包含克隆的项目。既然 Symphony 已经完成了
00:04:49问题的处理，它已将状态更改为“已完成”，并创建了一个带有 Linear 工单链接的新 PR
00:04:54以及我要求的具体更改。当然，我可以修改我的 Symphony 代码来添加
00:04:59更好的 PR 描述，并在评论中放入 PR 链接，但我确信这对
00:05:04Codex 来说非常容易。这就是 Symphony 的简要概述。如果你已经熟悉或者在
00:05:08使用 Linear 的公司工作，那么你会对这个界面感到驾轻就熟。如果你是 Codex 用户，
00:05:13你可以使用你已经安装的技能、MCP 工具和插件。我个人不
00:05:18使用 Codex，但我完全能理解 OpenAI 对 Symphony 的愿景。想象一下
00:05:22你有一个开发团队都在用 AI 开发同一个项目。与其让他们各自
00:05:28拥有自己的工作流套件，不如有一个核心代理，具备核心技能、核心
00:05:33工具、核心工作流和插件。每个开发者都可以通过给它
00:05:37分派任务来与之交流，他们可以看到其他人在做什么，使用了哪些提示，并能
00:05:41一眼看出其他功能是否会影响到他们正在开发的功能。尽管
00:05:46很难想出一个完全不触及别人正在开发的代码部分的功能。
00:05:49但尽管 Symphony 很酷，但在我看来，Multica 做得更好，因为它
00:05:54更容易设置、创建和添加不同的代理，你甚至可以安排任务。尽管如此，
00:05:59我完全能看到 Symphony 的一席之地。它就像是 Multica 的基础版本，你可以
00:06:04添加你想要的精确功能，而不是拥有一个为你构建好的产品。所以可以
00:06:08把 Symphony 看作是 Pi 套件，而把 Multica 或 Conductor 等其他工具看作是成衣代码。如果
00:06:13你对 Multica 一无所知，那就看看这个视频，它会带你
00:06:18了解你需要知道的一切。