OpenAI 开源了一个叫 Symphony 的东西。23.2K star，Apache 2.0 协议，但只有 12 次 commit。
README 的第一句话就够直接：
Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents.
翻译过来就是：别再盯着你的编码 Agent 看它干活了。把工作丢进去，让 Agent 自己跑，你只看结果。
它到底是什么
Symphony 不是又一个 coding agent。它是一个规范——定义了「如何把项目工作拆成隔离的、自主的执行单元」，以及一个 Elixir 写的参考实现。
它的 demo 场景是这样的：Symphony 监控一个 Linear 看板，发现有新的 task，自动 spawn 一个 Agent 来处理。Agent 完成工作后提供「工作证明」：CI 状态、PR review 反馈、复杂度分析、walkthrough 视频。如果团队接受这个结果，Agent 就安全地 merge PR。工程师不需要监督 Codex，他们在更高层面管理工作。
这跟 Codex 的关系是：Codex 是干活的工人，Symphony 是项目经理。
仓库里有一个 SPEC.md，把 Symphony 的服务规范写得清清楚楚。甚至安装方式也很有趣——官方推荐的方式是让你的 coding agent 读 spec 然后自己实现：
Implement Symphony according to the following spec:
https://github.com/openai/symphony/blob/main/SPEC.md
这个 meta 程度有点高：让 AI 读规范实现 AI 管理系统。
只有 12 次 commit，重要吗？
不重要。原因很简单：
第一，这是一个 spec-first 项目。 核心价值在 SPEC.md 里，不在代码里。OpenAI 开源的是「怎么做」的思路，不是一个成熟产品。
第二，参考实现是 Elixir 写的。 选 Elixir 不是偶然——它的并发模型天生适合这种多 Agent 协调场景。但 Elixir 的开发者基数小，所以参考实现的代码量不大也不意外。
第三，2 个月前创建，2 周前有最后一次 commit。 说明这个项目在内部可能已经跑了一段时间，现在拿出来看看社区反应。
我关注的几个点
「harness engineering」是什么？ README 提到 Symphony works best in codebases that have adopted "harness engineering"。这个概念我之前没怎么见过，SPEC 里应该有详细定义。本质上是一种让代码库「可被 Agent 操作」的工程实践——写好测试、定义好边界、让自动化有据可依。
安全边界在哪？ README 明确说这是「low-key engineering preview for testing in trusted environments」。也就是说，别把它直接跑在生产环境、连到你的主代码库上。信任边界是个大问题——让 Agent 自主 merge PR，出了 bug 谁负责？
和 Cursor Agent、Claude Code 的竞争关系？ Cursor 和 Anthropic 都在做 autonomous coding，但它们的思路是「产品化」——打包成一个你可以直接用的东西。OpenAI 走的是「标准化」路线——定义规范，让别人实现。两条路各有优劣。标准化如果能成为行业共识，OpenAI 就掌握了话语权。但如果没人跟着走，spec 就是文档而已。
这个信号意味着什么
OpenAI 把 Symphony 开源，传递了一个信号：他们认为「管理 Agent」会成为一个独立的工程问题，而不是 coding agent 产品里的一个小功能。
如果这个判断是对的，接下来会有更多公司开始关注「Agent orchestration」这个赛道——不是做更好的 coding agent，而是做「让 coding agent 团队协作」的中间层。
我会继续跟这个 spec 的演进。如果 v2 版能明确 harness engineering 的定义、给出更多语言的参考实现，那 Symphony 可能就真的是下一个行业标准的前身。
主要来源：
- openai/symphony — 官方仓库
- SPEC.md — 服务规范文档