OpenAI 开源 Symphony SPEC:用任务看板编排多个编码智能体

OpenAI 开源 Symphony SPEC,用任务看板协调多个编码智能体,降低人工管理多会话的负担。

原文标题:OpenAI 开源 Symphony:面向自主编码智能体编排的 SPEC 规范文档

原文作者:AI前线

冷月清谈:

OpenAI 开源了 Symphony 的 SPEC 规范文档和参考实现,目标是缓解开发者同时管理多个编码智能体时的注意力瓶颈。传统方式下,工程师需要在多个 Codex 会话之间切换,分配任务、检查进度、处理停滞与失败,管理三到五个会话后就容易失控。Symphony 改用问题追踪器、任务看板、工单和里程碑作为控制平面,把工作组织成可调度的任务流,并持续监控每个任务是否有智能体在推进。若智能体崩溃或停滞,系统会重启;若出现新任务,也会自动接收并安排执行。它还支持让智能体先分析代码库、生成方案并拆分任务,或在发现重构机会时创建新问题,但这些问题仍需人工审核后才会执行。OpenAI 强调 Symphony 不是独立产品,而是一份可供团队定制编排器的 SPEC.md,参考实现使用 Elixir 构建。

怜星夜思:

1、如果把 issue 看板当成 AI 编程的“控制台”,会不会比直接盯着聊天窗口更靠谱?
2、多智能体自动拆任务、自动提新 issue,人工只负责审核,这种模式会提高效率还是制造更多噪音?
3、Symphony 这种编排器最适合什么团队?小团队有必要上吗?
4、文章里说智能体犯错成本会降低,你认同吗?AI 写错代码真的只是“驳回”这么简单吗?

原文内容

作者 | Sergio De Simone
译者 | 明知山

OpenAI Symphony 是一个智能体编排器,它使用项目管理工具(如问题追踪器)作为控制平面来协调多个编码智能体。开发者不再需要管理交互式编码会话,Symphony 会将各项任务分配给专门的智能体来自主完成工作。任务完成后,由人工负责审查产出结果。

OpenAI 的工程师们创建 Symphony 是为了解决他们在使用更原始的工作流程时遇到的“人类注意力”瓶颈:

每位工程师都会打开几个 Codex 会话,分配任务、审查输出、引导智能体,然后重复这一过程。事实上,多数人同时管理三至五个会话后,就会因频繁切换上下文倍感吃力。

超过这个数量后,工程师很难记住每个会话在做什么、监控停滞的智能体,也无法在脑中清晰梳理各项正在推进的工作。

因此,Symphony 不再围绕单个编码会话(每个会话的目标都是在人工明确监督下最终合并代码拉取请求)来组织工作,而是将项目里的问题、任务、工单与里程碑等核心交付物,作为工作流的搭建单元。

Symphony 会持续监控任务看板,确保每个进行中的任务都有对应的智能体持续运行直至完成。如果智能体崩溃或停滞,Symphony 会重启它。如果出现新工作,Symphony 会接收并开始推进工作。

在这种模式下,智能体的工作不再与 PR 绑定。一个问题可以指示智能体分析代码库并生成实现方案,然后将其分解为 Symphony 可以跨智能体调度的任务树。同样,如果智能体发现可优化或重构的地方,它可以自主创建新问题。这两类场景中,依旧需要人工开发者审核生成的问题,审核完成后再由 Symphony 下发执行。

这种方法的主要优势在于,智能体犯错的成本显著降低,因为主要工作变成了审查已完成的工作并决定是否驳回。

Symphony 的另一个显著特点是,它并非一个复杂的监督系统,而是一份 SPEC.md 文件,描述了问题及解决方案,每个组织都可以用它来创建自己的编排器。其参考实现使用 Elixir 构建,因为 Elixir “在编排与管控并发进程方面具备十分完善的基础能力”。

最后值得注意的是,OpenAI 并未将 Symphony 定位为一个独立产品,它只是一个参考实现,开发者可以根据自己的场景和代码库进行调整和定制。

查看英文原文

https://www.infoq.com/news/2026/05/openai-symphony-agents/

会议推荐

企业级 Agent 落地,绕不开 4 个真实的工程问题!如何在 Agent 安全性和可用性之间找到平衡点?Agent 需要什么样的记忆系统才能真正理解上下文?如何通过算法压榨实现智力增量与成本控制的极致平衡?多 Agent 协作,如何做到可观测、可治理、可控制?6.26-27 AICon 上海站,国内头部公司的 Agent 实践,一次说透。

今日荐文

图片
你也「在看」吗?👇

我不太同意“只是驳回”这个说法。AI 写错代码可能污染分支、浪费 CI 资源、误导后续任务,甚至生成看起来很合理但其实很危险的实现。成本降低的前提是隔离环境、测试、权限控制都做得好。

这事要分层看。语法错误、测试不过这种低级问题,驳回确实简单;但如果是业务逻辑理解错了,审查的人还得重新读需求、读代码,可能比自己写还累。所以 Symphony 解决的是调度问题,不是质量问题的万能药。

2 个赞

我个人比较期待这个模式。以前最烦的是自己脑子里开了十几个线程:这个 bug 谁修、那个重构要不要做、PR 卡在哪。AI 能先把任务拆出来,人再决定做不做,至少比一堆想法烂在聊天记录里强。

3 个赞

关于“看板 vs 聊天窗口”,我站看板。聊天窗口像临时工位,干完就散;issue 像施工图纸,谁来接手都能看懂。不过前提是 issue 写得足够清楚,不然 AI 也是照着糊涂账干活。

2 个赞

这个问题我有点保留。看板确实更适合管理多任务,但编码过程里很多上下文是在对话中逐步澄清的。完全切到 issue,可能会牺牲一些灵活性。比较理想的方式应该是:聊天用于探索,issue 用于执行和验收。

3 个赞