昨晚刷 GitHub Trending 的时候，看到 OpenAI 悄悄放了一个新仓库—— Symphony。
一天不到，2600 多个 Star。
点进去一看，README 简短得离谱，核心就一句话：
Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding Agents.
翻译成人话就是：你在项目看板上移动一张工单，Symphony 就会自动生成一个 Agent 去写代码、跑测试、提 PR。
不用开终端，不用写提示词，不用盯着 Codex 干活。
你只管拖卡片，Agent 管干活。
等等，这也太爽了吧？
先别急着激动，我仔细扒了一遍它的技术规范和源码，跟你聊聊这东西到底是什么、怎么运作的，以及它跟最近另一个很火的项目 Paperclip 有什么区别。
写在前面：这篇文章基于 Symphony 仓库 2026 年 3 月 4 日的代码。Agent 生态迭代非常快，半个月前的结论可能就过时了，看的时候注意时效。
一、Symphony 到底解决了什么问题
先说背景。
如果你用过 Codex CLI、Claude Code 或者 Cursor Agent，你一定经历过这种场景：
开了一堆终端窗口，每个窗口里跑着一个 Agent，你需要给每个 Agent 写提示词，然后坐在那儿等它干完，检查输出，再手动提交 PR。
一个 Agent 还好。但如果你的项目有 10 个 issue 要处理呢？
你就变成了一个"Agent 保姆"——一边喂提示词，一边盯着它们别翻车。
Symphony 要做的事情，就是把你从"保姆"变成"项目经理"。
核心思路其实不复杂：
你在 Linear（一个项目管理工具，类似 Jira）的看板上创建工单 Symphony 每隔 30 秒轮询一次看板 发现新工单或者工单状态变了，它就自动创建一个隔离的工作空间 在这个工作空间里启动一个 Codex Agent 去干活 Agent 干完了，提 PR、跑 CI、生成 walkthrough 视频 你在看板上审核，觉得没问题，Agent 自动合并 PR
整个过程，你碰的只有 Linear 看板。不用打开 IDE，不用写任何提示词。
这个想法。。。说实话有点性感。
二、技术架构拆解
扒了它的 SPEC.md（技术规范文档，500 多行），我画了一张架构图给你看。
Symphony 的架构分成六层：
策略层（你来定义）：仓库里放一个 WORKFLOW.md 文件，用 YAML 前置元数据 + Markdown 正文的格式，定义 Agent 的行为规则。比如用哪个 Agent、怎么处理工单、提示词模板长什么样。
配置层（解析配置）：读取 WORKFLOW.md 的 YAML 配置，处理环境变量、路径展开、默认值这些事情。支持热更新——改了配置文件不用重启服务。
协调层（核心调度）：这是 Symphony 的大脑。负责轮询看板、判断哪些工单该派活、控制并发数、处理重试和异常恢复。
执行层（干活的）：为每个工单创建一个独立的文件系统工作空间，启动 Codex Agent 子进程，通过 JSON-RPC 协议跟 Agent 通信。
集成层（连接外部）：目前只支持 Linear API，负责拉取工单数据、标准化成统一格式。
可观测层（看日志）：结构化日志输出，可选的状态面板。
说几个我觉得设计得不错的点：
工作空间完全隔离。 每个工单一个目录，Agent 只能在自己的目录里操作。这意味着两个 Agent 不会互相踩到对方的代码。
支持 Hook 机制。after_create、before_run、after_run、before_remove 四个钩子，可以在工作空间创建后拉代码、跑之前装依赖、跑完后清理环境。
状态机设计很克制。 内部只有 Unclaimed → Claimed → Running → RetryQueued → Released 这几个状态，不搞复杂的流程引擎。
重试机制分两种。 Agent 正常完成但工单还没关？1 秒后再检查一次。Agent 挂了？指数退避重试，最长 5 分钟间隔。
不需要数据库。 所有调度状态都在内存里，重启后通过轮询 Linear 和检查文件系统自动恢复。这一点我挺意外的，意味着部署成本非常低。
三、WORKFLOW.md 长什么样
这是 Symphony 里面最关键的文件，直接决定了 Agent 的行为。大概长这样：
---
tracker:
kind:linear
api_key:$LINEAR_API_KEY
project_slug:my-project
active_states:Todo,InProgress
terminal_states:Done,Cancelled
polling:
interval_ms:30000
workspace:
root:~/symphony_workspaces
hooks:
after_create:|
git clone $REPO_URL .
npm install
before_run:|
git fetch origin main
git checkout -b agent/{{issue.identifier}} origin/main
agent:
max_concurrent_agents:5
codex:
command:codexapp-server
turn_timeout_ms:3600000
---
你是一个软件工程师。请根据以下工单完成开发任务。
工单标题：{{issue.title}}
工单描述：{{issue.description}}
工单标签：{{issue.labels|join:", "}}
请完成以下步骤：
1.分析工单需求
2.编写代码实现
3.编写测试
4.提交PR并附上说明
看到没？提示词模板直接写在 Markdown 正文里，用 Liquid 模板语法插入工单变量。
改一下这个文件，所有后续派出的 Agent 就会按新规则干活。不用重启服务，热更新。
这个设计我觉得挺巧的——把"Agent 怎么干活"这件事交给仓库来管，版本可控，团队可协作。
四、最骚的操作：让 Agent 自己去实现 Symphony
README 里有一段话，把我看乐了：
Option 1. Make your own Tell your favorite coding agent to build Symphony in a programming language of your choice: Implement Symphony according to the following spec: https://github.com/openai/symphony/blob/main/SPEC.md
翻译一下：我们不建议你直接用我们的代码，你让 AI 按照我们的规范自己写一个吧。
有网友评论说："我从没见过哪个开源项目跟你说'别用我们的，自己造一个去'"。
这其实挺 OpenAI 风格的。他们之前的 Swarm 项目也是类似的思路——不给你一个生产级的框架，而是给你一个参考实现和一份规范，让你自己做。
官方的参考实现用的是 Elixir 语言（对，就是那个 Erlang VM 上的函数式语言）。96% 的代码是 Elixir，剩下的是 Python。
为什么选 Elixir？可能因为 Elixir 天生擅长处理大量并发进程和容错恢复，非常适合这种"同时管一堆 Agent"的场景。但这也意味着大多数团队可能不太方便直接用。
所以 OpenAI 的意思是：规范才是核心资产，实现你自己来。
五、跟 Paperclip 对比一下
最近还有一个很火的项目叫 Paperclip，1900 多个 Star，定位是"面向无人运营公司的开源编排系统"。
听起来跟 Symphony 有点像？其实差别很大。
我列个表对比一下：
简单来说：
Symphony 是"一群程序员的工头"——只管写代码这件事，但管得很专业。工单来了，分配 Agent，盯着干完，提 PR。
Paperclip 是"一家虚拟公司的 CEO"——不光写代码，还管市场、管设计、管客服。有组织架构，有预算，有治理流程。
如果你只是想让 Agent 自动处理 GitHub Issue，Symphony 更合适。
如果你想搞一个全自动运营的 AI 公司（嗯，没有人类员工的那种），Paperclip 更对口。
不过说真的，Paperclip 那个"零人类公司"的概念。。。我又兴奋又有点慌。
六、Symphony 目前的局限
泼一点冷水。
只支持 Linear。 你用 Jira？GitHub Issues？Trello？不好意思，目前不行。不过 SPEC.md 里设计了 tracker adapter 的抽象层，理论上可以扩展。
只支持 Codex Agent。 想接 Claude Code？Cursor Agent？目前规范里写死了 Codex app-server 协议。当然你可以自己魔改。
还是工程预览版。 README 里明确标了 Warning：这是 "low-key engineering preview for testing in trusted environments"。翻译过来就是：别在生产环境用。
没有 UI。 只有结构化日志和可选的终端状态输出。想看 Dashboard？自己搞。
安全模型依赖外部。 Symphony 自己不做沙箱，Agent 的权限完全取决于你的 Codex 配置和操作系统权限。如果配错了，Agent 理论上可以搞出事情来。
七、这件事的意义
拉远一点看，Symphony 代表了一个很明确的趋势：
开发者的角色正在从"写代码的人"变成"管理 Agent 的人"。
以前的工作流是：产品经理写需求 → 开发者写代码 → 测试 → 部署。
以后的工作流可能是：产品经理在看板创建工单 → 编排系统自动派 Agent → Agent 写代码、跑测试、提 PR → 开发者审核合并。
OpenAI 在 Symphony 的文档里用了一个词叫 "harness engineering"（工程化管理），就是说你的代码仓库需要有足够好的测试、CI、代码规范，Agent 才能顺利干活。
这其实也是对开发者的新要求——你不用亲手写每一行代码了，但你得把"基础设施"搞好。测试覆盖率不够？Agent 写出来的代码没法验证。CI 流程不完善？Agent 提的 PR 没法自动检查。
某种程度上，Symphony 不会让开发者失业，但会让"只会写代码但不会搞工程化"的开发者很难受。
也会让"擅长搞工程化和架构"的开发者如鱼得水。
说到这里，我想到了最近看到的另一个有意思的评论。有人说 OpenAI 和 Anthropic 现在都在用 PHP 生态的命名——Anthropic 的产品叫 Composer，OpenAI 这个叫 Symphony（Symfony 是 PHP 的一个框架）。
哈哈，PHP 才是最好的语言这件事，终于被 AI 公司们认可了？（开个玩笑）
八、想体验的话
如果你确实想试试 Symphony，有两条路：
路线 A：按规范让 AI 造一个
把 SPEC.md 的链接丢给 Claude Code 或者 Codex，让它帮你用 Python/TypeScript/Go 实现一个。这也是 OpenAI 推荐的方式。
路线 B：跑官方的 Elixir 实现
你需要装 Elixir 环境，然后按照 elixir/README.md 的说明配置。需要一个 Linear 账号和 Codex 的 API 访问权限。
不管哪条路，你都需要一个配好测试和 CI 的代码仓库。裸仓库丢进去，Agent 大概率是会翻车的。
