北京
作者 ｜ 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/
声明：本文由 InfoQ 翻译，未经许可禁止转载。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
