大家好，我是小莫特。今天聊一个 OpenAI 刚开源的东西 Symphony。在开始前，我们先来看三个数字。第一个数字十五 K，Symphony 仓库开源到现在，GitHub 星星已经突破了十五 K。第二个，百分之五百，OpenAI自己披露，内部用上 Symphony 的团队落地的 PR 数量涨了五倍。
第三个数字零，我接下来录屏里给我自己的网站做了一个小功能，在这个功能开发中，我自己敲键盘的次数是零。这三个数字摆在一起，基本就是 OpenAI 这次想讲的故事，不是又造了一个写代码的 agent，而是把管项目这件事重新设计了一遍，留给 agent 自己跑。Symphony 到底是什么呢？咱们来到官方代码仓库。
官方的定义是把项目工作变成一组互相隔离的自治的任务执行。注意三个词：隔离、自治、运行。这三个词决定了 Symphony 不是一个写代码的工具，而是一个调度器。它的工作方式是这样的。你的 Linear 看板上每一张 Ticket Symphony 都会去看一眼，处于 To Do 或 In Progress 状态。
又没有未关闭的 blocker，它就会派一个 agent 进去干。这个 agent 跑在自己专属的 workspace，代码本体跑的是 OpenAI 的 Codex App Server。Sifonny 自己只负责调度，谁该跑、跑多久、超时怎么重试、跑完怎么收尾，在官方代码仓库有这么一份文档 spec，这是 Sifonny 的服务规范。
我读了一遍，其中有几个关键点，咱们拎出来单独的聊一聊。第一个是轮询，也就是 polling，轮询默认三十秒一次。Linear看板上有新卡，状态变了，三十秒内Symphony就会注意到。每个issue有自己的工作区，也就是Workspace。不会互相打架，跑完一次还会保留下来，下次同一个 issue 再跑可以接着用。
失败后会有指数退避重试，不会一次失败就彻底挡平。Symphony 它自己不写 ticket，只读 linear 的状态，要不要在 linear 上回复评论修改状态，是 agent 自己用工具去做的。那这跟我们已经在用的 Codec CI 或 Clo Code 有什么不一样呢？差别就一个，谁是入口？Codec CI、Clo Code 这种入口是终端，我打开它，我跟他说，帮我修改这个文件，他写我审。
Symphony 把入口换成了 Linear 看板，我只管在 Linear 上提 ticket，Agent 自己去检。我从盯着 Agent 写代码变成管项目，Agent 自己开工。Symphony把入口换成了Linear看板，我只管在Linear上提ticket，agent自己去检。我从盯着agent写代码变成管项目，agent自己开工。
这一句听起来好像没什么，但你想想这意味着什么？不会写代码的人也能给项目派活，产品经理、设计师、运营，只要会在Linear上提ticket。他们就在调度 agent。最后还有一件事得说清楚：Symphony 不是产品，OpenAI 自己说不会把它当产品维护。就是放出来给大家看，Codex App Server 接 Workflow 工具能跑成什么样。
在 Symphony 代码仓库还开源出来一个参考实现，这个实现是基于 Alexa 写的，这个选择还是令我满意外的，至少我并不熟悉 Alexa。但这个参考实现还是提供了非常完善的文档，帮助我快速的上手。听了一番我的介绍，恐怕还是蛮抽象的。那咱们来实际的安装操作一下，看看它的体验究竟是什么样的。咱们根据 Alexa 的 README 文档来完成操作，在这里有一个非常简明的安装配置手册。
也介绍了他是如何工作的。他会轮询Linear去寻找可以适合自己的工作，为每个issue创建工作区，启动Codex，发送提示词给Codex，推动Codex不断的工作，直到issue成功被解决。在这里面呢，咱们就需要几样东西。首先呢，是代码仓库。这是你要让 Symphony 工作的地方。另一个呢，就是 Linear 的 API key。
在目前的这个实现中，用到了 Linear 作为一个任务的调度和管理的系统。在此之前，首先呢是需要完成一系列依赖的安装，因为 Electra。所以呢，咱们需要用到一个叫 mice 的管理工具，在官方网站这里有非常详细的安装方式，根据不同的操作系统，大家选择对应的安装方式完成安装。比如在 Mac OS，咱们就用 brew install mice。
接下来参考文档的后续步骤，逐一的运行。可以通过 mice exec alexa version 来查看安装版本。在克隆 Symphony 代码仓库，在 Alexa 目录中运行如下一系列命令，完成安装与配置。最后这条命令，mouse exec bin symphony workflow. dot md，就是运行 symphony 的一条命令。
我们先来看看，在我本地已经运行起来的这么一个 symphony 环境，配合 linear，它是怎么工作的。我在当前的终端已经运行了 symphony。它监听的或对接的项目呢，是 Linnea 上的这个 Very Small Wood 项目。它会每隔五秒钟刷新扫描一次，它可以做的工作。在 Linnea 这一侧，我创建了个项目叫 Very Small Wood。
通过 URL，大家应该能看到 770b6e8 这个 ID 或者这个项目呢，正是目前咱们在终端这里监听的项目。它每隔五秒扫描一次。当咱们希望通过 Symphony 来协调调度工作的执行，我们通过 Issue 来追踪。那现在呢，就来创建一个 Issue，来看看效果。当前管理的项目呢，是我的这个官方网站。
我尝试让他帮我完成一个简单的工作吧。在页角这里有一个email。这是联系方式，但是呢不能点击。在网站上常见的电子邮件呈现方式呢，是可以通过点击自动打开，比如邮件的应用，快速的来编写邮件。那我希望在这里做一番改进。我现在就回到 Linear，希望更新一下在页脚中的 email，让它可以点击。我将它状态切换到 To Do，优先级呢切换到 High。
我可以将它指派给我自己。创建issue，这个issue创建后，我们赶紧回到终端这里。很快，通过扫描，他发现到了这个新的issue，目前处于to do状态，这是他可以进行处理的。那他现在就要开始处理这个issue，我们给他一些时间来完成操作。我们回到Linear。点开这个 issue，能够看到这个 issue 底下呢，已经做了许多的更新。
这个更新呢，是一个 Codex 的工作计划版，包含了工作计划以及验收的标准。最后呢是如何验证？花了一些时间，它完成了这个任务的执行。那在这里呢有一个 token 的进与出的统计数据，这个呢大概就反映了在这个任务执行中它的对话、它的提示词究竟的开销是什么样的。那我现在回到 Linear 这边来看看 issue 的更新情况。
那究竟这个是怎么工作的呢？我们来看看在本地它得到了一些什么。咱们现在回到另外一个终端，在 code 目录下有个 symphony workspaces，这里面列出了所有 issue 对应的目录。刚才工作的应该是八号。实际上呢，他就是将 very small old 我这个个人的网站的项目克隆到了 workspaces 底下，在这里面他会做对应的代码修改。
如果需要呢，我们可以来到这个目录，手动的在这里运行个人的站点，看看他的修改情况。在验证是否修改是我们期望的。那目前这个 issue 的执行呢？我们来看看最下方它的记录，这里面就有一系列它的处理情况。处理到最后呢，它有一个 confusion 的信息点，看起来在整个的执行中 get
的操作有一些问题，我不确定是不是我本地的这个环境的配置或者当前的网络存在一些问题，这个呢在视频后我会来检查一下，看得出来它主要的改动呢就是添加了 mail to 这个前缀或者这个协议的标识符。
使得电子邮件可以点击，那这当然是一个正确的改进或者修复。这就是我们如何在本地运行 Symphony，并且基于 Linear 来做任务的协调。本地的执行呢，会用到 Codex。那大家可能好奇该怎么配置，那我们现在快速的就过一遍安装与配置。首先，大家在 Linear 完成注册与登录。在这里呢，我已经创建了一个项目，叫 Very Small Woods。
在项目这里，大家可以点击加号创建一个新的项目，比如我取名 Experiment。这个项目呢会有一个 ID，当我们点击这个项目的时候呢，在浏览器的地址栏就有这个 ID。这个ID是我们在后续配置中会用到的。另一方面，我们需要配置Linear的API
Key。在个人账号这里，来到Settings，应该有Security and Access这个菜单，点击它，在下方创建一个自己的Personal API Key。
在Linear侧的配置就完成了。在咱们自己电脑上，我们现在做一些配置。安装配置过程呢，我们参考 Symphony 中 Alexa 的文档。接下来就是克隆 Symphony 这个代码仓库。再来到 Symphony Alexa 目录，我已经完成了克隆，后续的命令我也已经都执行过了，大家可以逐一的执行。最后这条命令，mis exec bin Symphony 这个呢就是启动 Symphony 的命令。
我回到刚才运行的这个终端，将它停掉，可以来看看整个的命令的情况。bin Symphony 这表示运行 Symphony，但是呢需要给它一个 workflow 的 MD 文件，这个文件在哪里呢？我们马上介绍。在文档中并没有添加我们后面提供的这个参数。那如果大家在运行同样命令时出现错误呢？它会有提示。那么我遇到提示就是将这个选项添加上。
这表示我已经明白这个运行呢会存在风险，它并没有通常需要的这种安全的防护，这样呢就启动了在本地运行的 Alexa 实现，也就是说运行了 Symphony。那在这里面会提供的 Workflow MD 文件是什么呢？这就很关键了。我们依然回到 Alexa 的文档这里。要提供一个 workflow.md 文件，这个文件呢是你想要它工作的项目中配置的 workflow 文件。
那我在这里提供的呢，就是 very small woods 项目下的 workflow.md。在 Alexa 模块下会有 workflow.md 文件，这是一个类似于模板的文件，我们可以打开看看它的内容。在这里面包含了一系列我们可以配置的参数。那作为初次使用或体验呢，我们只需要关注两个参数就好，一个是 project log。
一个呢是 hooks 这里的 get clone 命令，做一番简单的介绍。project slug 配置为刚才我们在 linear app 中创建的项目的 ID，也就是咱们刚才创建项目的 URL 中的这部分。另一个呢就是 hooks 这里的 after create，要克隆一个目录，这个目录呢就是大家的代码仓库的 URL。
比如，现在如果我想要他帮助我来做 Symphony 这个项目的开发和管理呢，我就将这个 URL 交给他。他的工作原理是，在每个 issue 处理中，会在 Symphony Workspace 克隆这个代码仓库，完成必要的操作。比如修改代码、编译，确保一切正常，然后更新咱们在 Linen 上的 issue。
现在我们就来看看我在这里命令中提供的 workflow.md 文件。来到本地的 VS Code，我打开的就是 workflow.md。这个 workflow.md 是我在 Very Small Woods 这个项目中。复制粘贴后做的修改，project slug 设置为了这么一个字符串，我是从 linear app 中复制粘贴过来的。
另一个很重要的就 after create 这个后面 get clone，克隆的就是这么一个代码仓库。在启动 symphony 之前呢，我们还需要配置 linear 的 API key。我现在在环境变量中已经配置了 linear API key，这个呢是在视频分享前我已经创建并且添加到这里的。到此，我们就已经完成了必要的准备工作。
通过 mice exec symfony 命令启动它就好。在这个命令中，我们给到了这个 workflow 的 md 文件。那现在大家就可以在自己的 linear 项目中创建 issue。项目这里呢，点击 issues 可以创建一个新的 issue。这也是在项目中的第一个。可以根据自己的需要来决定将状态切换成什么，比如切换到 to do。
表示这个 issue 呢，已经可以开始工作了。自己本地运行的 Symphony 的 agent 就会将这个 issue 取下来，看看是否能做。再根据需要将它切换到比如 in progress 状态进行工作，并随时的在底下做更新、做笔记。好了，这就是咱们今天分享主要内容。那大家觉得这套任务的调度编排体验是否能够满足自己的工作和学习的需要呢？
大家是否已经开始使用 Symphony？也欢迎大家在评论区给我们留言。那今天的分享就到这里，我们下期再见吧。