OpenAI开源Symphony:给每一个任务配一个永不下班的AI员工 ✍ 向阳乔木🕐 2026-04-29📦 13.1 KB 🟢 已读 𝕏 文章列表 OpenAI开源了Symphony项目,旨在解决AI Agent规模化管理的瓶颈。该系统将Linear任务看板转化为AI控制中枢,为每个活跃任务分配独立的Agent持续工作,直至交付。文章详细阐述了其架构、工作流及“管理任务而非Agent”的核心理念,标志着软件开发经济学在AI时代的变革。 OpenAISymphonyCodexAI AgentLinearDevOps自动化工程效能开源 # OpenAI开源Symphony:给每一个任务配一个永不下班的 AI员工 **作者**: 向阳乔木 **日期**: 2026-04-29T13:42:38.000Z **来源**: [https://x.com/vista8/status/2049484504444834126](https://x.com/vista8/status/2049484504444834126) ---  OpenAI 最近开源了一个叫 Symphony 的项目。 > https://github.com/openai/symphony 感觉是给AI Agent用的任务管理系统,OpenAI 内部与Linear整合,大大提升了人管理Agent的能力,目前已经有1.8w Star。 好像跟一个X友做的产品很像?让AI翻译介绍下: ## 从一个激进的实验说起 六个月前,OpenAI 内部一个团队做了个当时看起来很激进的决定:仓库里不允许有任何人类写的代码。 每一行,都必须由 Codex 生成。 > Codex 是 OpenAI 的 AI 编程助手,可以理解需求、读懂代码库、自主完成编程任务。 他们重新设计了整个工程流程,大量投入自动化测试和防护机制,把 Codex 当成真正的团队成员。 他们把这套方法叫做"harness engineering"(脚手架工程),并专门写了一篇博客记录这段历程。 结果确实跑通了。 但随即撞上了下一个瓶颈:上下文切换。 ## 真正的瓶颈是人的注意力 每个工程师同时开几个 Codex 会话,分配任务,审查输出,调整方向,循环往复。 实际操作下来,大多数人同时管理三到五个会话还算舒适,超过这个数字,效率就开始下降。 忘了哪个会话在做什么,在几个终端之间来回跳,调试卡在一半的长任务…… AI 跑得很快,但系统的瓶颈是人的注意力。 他们意识到,自己其实是雇了一批极其能干的初级工程师,然后让人类工程师去微观管理他们。 这显然没法规模化。 ## 换一个视角 问题出在思路上。 他们一直在优化"编程会话"和"合并 PR",但这些只是手段。 > PR(Pull Request):工程师完成一段代码后,向主代码库提交合并请求,等待审查和合入。 软件开发真正围绕的是可交付物:issues(问题单)、任务、里程碑。 所以他们问了自己一个问题:如果不直接监督 AI,而是让 AI 自己从任务追踪系统里拉取工作,会怎样? 这个想法变成了 Symphony。 ## Symphony 是什么 一句话:把项目管理看板变成 AI 编码代理的控制中枢。 他们用的是 Linear,一款工程团队常用的任务管理工具。 每一个打开的任务,都会自动分配一个 AI 代理。 代理持续运行,直到任务完成。人类只需要审查结果。 具体来说,每个 Linear issue 对应一个独立的Agent工作空间。 Symphony 持续监视任务看板,确保每个活跃任务都有Agent在跑。 Agent崩溃了,自动重启;有新任务进来,自动接手。  整个工作流用 Linear 的状态来驱动,像一台状态机: > Todo(待办)→ In Progress(进行中)→ Human Review(人工审查)→ Done(完成) AI 代理在这些状态之间流转,人类在"Human Review"节点介入。  ## 几个让人印象深刻的细节 任务粒度可以很大 不再局限于"改一个函数"这种小粒度。 可以让代理先分析整个代码库、Slack 记录或 Notion 文档,产出实现方案,再自动拆解成一棵任务树,按依赖关系并行执行。 他们用了一个词叫 DAG(有向无环图,Directed Acyclic Graph),本质就是一张"哪些任务依赖哪些任务"的执行顺序图,确保代理不会乱序执行。 比如他们做过一个真实案例:先完成从 Webpack 到 Vite 的迁移,再升级 React。 Agent自己识别了这个依赖关系,等 Vite 迁移完成后才开始升级 React,完全符合预期。 Agent会自己创建任务 在实现过程中,Agent如果发现了性能问题、重构机会或者更好的架构方案,会直接在 Linear 里开新 ticket,供人类评估和排期。 很多后续任务也会被代理接手执行。 从手机上也能工作 因为编排器跑在开发服务器(devbox)上,从不睡觉,有个工程师在信号很差的小屋里,用手机 Linear App 提了三个重要改动,Agent照样接手执行了。 数据很直接 部分团队在前三周,合并的 PR 数量增长了 500%。 Linear 创始人 Karri Saarinen 也公开提到,Symphony 发布后,Linear 上新建工作区的数量出现了明显峰值。 ## 它的核心是一个 Markdown 文件 这是 Symphony 最有意思的设计决策之一。 打开 Symphony 的代码仓库,会发现它本质上就是一个 SPEC.md,一份对问题和解决方案的定义文档,而不是一个复杂的监控系统。 他们定义好问题,给出高层次的指引,然后把这份规范扔给 Codex,让 Codex 来实现它。 参考实现选了 Elixir,一门相对小众的编程语言,但在并发(同时处理大量任务)和进程监督方面有非常好的原语(基础构建块)。 选它的理由也很直接:当代码成本趋近于零,终于可以为了语言的优势本身来选语言,而不是为了招人方便。 Codex 一次性就把 Elixir 实现写出来了。 为了打磨规范本身,他们又让 Codex 用 TypeScript、Go、Rust、Java、Python 各实现了一遍,用这些实现来发现规范里的歧义和可以简化的地方。 每种语言都成功了。 ## 工作流也被文档化了 这里有个值得单独说的转变。 以前,工程师们有一套隐性的工作流程:接到任务,切出分支,把任务标记为进行中,提 PR,移到 Review 状态,附上演示视频……这些步骤人人都懂,但从来没有被正式写下来。 现在,这套流程被写进了 WORKFLOW.md,Symphony 确保 AI 代理遵循它。 以前是人类遵循隐性规范,现在是把规范显式化,让 AI 来遵循。 这个文件还有一个重要特性:热重载。 修改 WORKFLOW.md 后,Symphony 会自动检测变化,无需重启,直接把新配置应用到后续任务上。 如果以后想让代理在完成工作后附上自我反思,只需要在 WORKFLOW.md 里加一行,Symphony 就会引导Agent执行这一步。 ## Symphony 的技术架构(不想看可以跳过) Symphony 的内部由几个核心组件构成,理解它们有助于明白整个系统为什么可靠: Orchestrator(编排器):整个系统的大脑,唯一有权修改调度状态的组件。 它负责轮询任务、决定哪些任务该启动、重试或停止,并追踪所有正在运行的代理状态。 Workspace Manager(工作空间管理器):每个任务都有自己独立的文件目录,Agent 只能在自己的目录里操作,不会互相干扰。这是一个重要的安全边界。 Agent Runner(执行器):负责启动 Codex 进程,把任务提示词传给它,然后把执行结果反馈给编排器。 Issue Tracker Client(任务追踪客户端):负责和 Linear 通信,拉取任务列表,同步状态变化。 整个系统的并发控制也很细致,可以设置全局最大并发代理数(默认 10 个),也可以针对特定状态的任务单独限制并发数。 重试机制用的是指数退避(exponential backoff):第一次失败等 10 秒,第二次等 20 秒,第三次等 40 秒,以此类推,最长不超过 5 分钟。 正常完成后的续跑检查只等 1 秒。  ## 一个重要的架构选择:App Server 模式 Symphony 使用了 Codex 的 App Server 模式,一种内置的无头(headless)运行模式。 > 无头(headless):没有图形界面,完全通过程序接口控制,适合自动化场景。 这种模式通过 JSON-RPC(一种轻量级的远程调用协议,用 JSON 格式传递指令和结果)以编程方式控制 Codex,比如启动一个对话线程、触发一个执行轮次、读取执行结果。 比通过 CLI 命令行或 tmux 会话操控 Codex 方便和可扩展得多。 另一个安全细节:为了避免把 Linear 的访问令牌(API token,相当于访问密码)直接暴露给Sub Agent,他们用动态工具调用(dynamic tool calls)的方式,封装了一个叫 linear_graphql 的函数。 代理可以通过这个函数对 Linear 执行任意查询,但永远接触不到原始 token。 ## 遇到的新问题 当然,这种工作方式也有代价,他们没有回避这一点。 从实时干预Agent,变成在任务层面分配工作,意味着失去了随时纠偏的能力。 有时候Agent会完全跑偏,产出的东西完全不对路。 但他们的应对方式很有意思:不是手动修补结果,而是补充防护机制和技能,让Agent下次能自己成功。 这倒逼他们持续完善系统,加入了端到端测试、通过 Chrome DevTools 驱动浏览器、管理 QA 冒烟测试等新能力,还大幅改善了文档质量。 还有一个认知上的转变:不能把Agent当成状态机里的僵硬节点。 早期版本只让 Codex 实现任务,这太局限了。 Codex 完全有能力同时管理多个 PR、读取 CI(持续集成,自动化测试和构建流程)日志、处理代码审查反馈。 > CI(Continuous Integration,持续集成):每次代码提交后自动运行测试,确保新代码不破坏已有功能。 所以他们最终的方向是:给Agent目标,而不是给它严格的状态转换规则。 就像一个好的管理者,给直接下属分配目标,而不是每一步都手把手指导。 给它工具,给它上下文,让它自己想办法。 不是所有任务都适合 Symphony 的工作方式。 涉及模糊问题或需要强判断力的工作,工程师还是会直接用交互式 Codex 会话。 实际上,这些往往也是工程师最感兴趣、最享受的任务。 ## 用 Symphony 来构建 Symphony 这个细节值得单独说一下。 Symphony 基本功能跑通之后,他们就开始用 Symphony 来开发 Symphony 本身。 当他们在内部演示这个系统,看到它自主管理任务、并附上功能演示视频作为工作证明时,反应非常热烈。Symphony 的内部项目频道迅速增长,各个团队开始自发使用它。 在 OpenAI,内部产品市场契合度(PMF)是对外发布的前提条件。 基于内部的使用情况,他们决定把 Symphony 分享给外部世界。 ## OpenAI 不打算把它做成产品 这个项目开源后,三周内获得了超过 15,000 个 GitHub Star。 社区已经有人做了各种移植版本: - 有人用 Go 语言加上 Charm CLI 的终端 UI 做了一个版本 - 有人把它改造成支持 Anthropic 的 Claude Code,并支持 GitHub Issues,还做成了 Homebrew 可以直接安装 - 有人用 Claude Code 重新实现了整套规范,取名 hatice 但 OpenAI 明确说了:不打算把 Symphony 作为独立产品来维护。 它是一个参考实现,一个演示 Codex App Server 能力的例子。 核心思路很简单: > 对每一个打开的任务,保证有一个Agent在它自己的工作空间里持续运行。 他们希望大家把自己喜欢的编码代理指向这份规范,构建适合自己环境的版本。 门槛其实出奇地低,直接把规范扔给 Codex,让它帮你实现一个就行。 ## 值得思考的地方 Symphony 解决的问题,表面上是"怎么让更多 AI 并行工作",但更深层的变化是:当代码的边际成本趋近于零,整个软件开发的经济学都变了。 每次改动的感知成本下降,意味着大家开始愿意做以前觉得"不值得"的事:试一个想法,探索一次重构,验证一个假设,不满意就扔掉。 参与工作的人也变了。 产品经理和设计师可以直接向 Symphony 提需求,不需要懂代码,不需要管理 AI 会话,描述功能,然后收到一个包含视频演示的审查包。 在大型 monorepo(单一代码仓库,把所有项目代码放在一个仓库里管理)里,Symphony 还承担了"最后一公里"的工作:监视 CI 状态,需要时自动 rebase(同步最新代码),解决冲突,重试不稳定的检查项,把改动一路护送进主分支,不需要人类盯着。 随着模型越来越强,能解决的问题越来越大,其他公司的瓶颈也会从"写代码"转向"管理 AI 工作"。 Symphony 提供的,是一种思路:不要管理Agent,管理任务就够了。 > 官方原文:https://openai.com/index/open-source-codex-orchestration-symphony/ ## 相关链接 - [向阳乔木](https://x.com/vista8) - [@vista8](https://x.com/vista8) - [https://github.com/openai/symphony](https://github.com/openai/symphony) - [https://openai.com/index/open-source-codex-orchestration-symphony/](https://openai.com/index/open-source-codex-orchestration-symphony/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [9:42 PM · Apr 29, 2026](https://x.com/vista8/status/2049484504444834126) - [1,094 Views](https://x.com/vista8/status/2049484504444834126/analytics) --- *导出时间: 2026/4/29 22:22:11*
O OpenAI 正在确立 Coding Agents 的默认编排层 文章介绍了 OpenAI 生态内两个同时发布的开源项目:Symphony 和 ClawSweeper。两者均基于 Codex App Server 这一原始编排层,分别针对 SDLC 的两端(PR 创建与 Issue 维护)提供了参考实现。Symphony 将 Linear 转化为自动化代理系统,提升 PR 吞吐量;ClawSweeper 则能并行运行大量 Codex 实例,自动清理无意义 Issue。文章分析了它们的架构模式、应用场景及局限性。 技术 › Agent ✍ AlphaSignal AI🕐 2026-04-29 OpenAICodexCoding AgentOrchestrationSymphonyClawSweeperDevOpsLLM自动化开源
T The guide to software factories 本文介绍了软件开发从交互式编码代理向云端软件工厂的转变。软件工厂通过自动化SDLC(软件开发生命周期)的各个环节,减少人为差异,最大化软件输出,并提升安全性与合规性。文章阐述了软件工厂的概念、工作流程及其核心组件,包括云运行时、沙箱等,旨在帮助工程领导理解如何部署这一系统以解决当前交互式代理的成本和治理问题。 技术 › DevOps ✍ Zach Lloyd🕐 2026-07-15 软件工厂SDLCAI自动化云开发DevOpsClaudeCodex工程效能
全 全网 Codex Skill 指南:精选资源与安装教程 本文系统梳理了 Codex 的 Skill 生态,指出安装核心 Skill(如 create-plan、gh-fix-ci)是将其从聊天机器人升级为工程团队的关键。文章汇总了必 Star 的官方与社区仓库,按场景(规划、CI/CD、测试、前端等)分类精选了神级 Skill,并提供了保姆级的安装与调用教程,最后分享了自定义 Skill 及进阶组合玩法,帮助开发者最大化利用 AI 编程工具。 技术 › Codex ✍ AYi🕐 2026-06-17 CodexOpenAIAIEngineeringSkill教程DevOpsCI/CD自动化工具效率编程助手
C Codex CLI /goal 模式详解:OpenAI 官方 Ralph Loop 的自主迭代引擎 文章详细介绍了 OpenAI 在 Codex CLI v0.128.0 中引入的实验性功能 /goal。该功能基于 Ralph Loop 理念,使 Codex 能从单次对话转变为自主规划、持续迭代、自我修正的代理,直至完成高层次目标。文章对比了 /goal 模式与正常模式的区别,列举了适用场景如长周期重构和无人值守开发,并指出该模式能显著提升任务完成度和工程质量,但需注意 Token 消耗。 技术 › Codex ✍ 雪踏乌云🕐 2026-05-03 OpenAICodexAgent开发工具自动化Ralph LoopCLIAI编程迭代DevOps
C Codex 实测:7 个并行 25 分钟干完 3 天活 文章对比了作者每月 $600 的 AI 编程工具开销,重点评测了 OpenAI 的 Codex。结论显示,Codex 在资源消耗上远低于 Claude Code,且支持多路并行,大幅提升效率。作者详细介绍了安装配置、权限管理、任务分配策略及 Superpowers 等实用工具,指出除了爬虫逆向外,Codex 已完全具备平替 CC 的能力。 技术 › 工具与效率 ✍ 百年 AI×出海🕐 2026-05-03 AI编程CodexClaude Code工作流自动化效能提升DevOpsOpenAIGPT-5.5
H Harness Engineering: 从执行者到系统架构师 本文提出了“驾驭工程(Harness Engineering)”的概念,指出在 AI Agent 时代,工程师的角色正从代码执行者转变为系统设计者。文章总结了 OpenAI、Anthropic 等公司实战中的 5 个核心思维模式,包括人类掌舵、修系统不修结果、环境外部化、生成与评估分离以及框架做减法。同时,文章给出了 6 条实用启示,强调搭建工作环境的重要性优于单纯选择模型,并指出掌控 AI 记忆是未来的护城河。 技术 › Harness Engineering ✍ Yanhua🕐 2026-04-15 AI Agent系统架构工作流OpenAIAnthropic思维模型自动化DevOps
如 如何基于 Codex 构建自我改进的外联系统 本文介绍了如何利用 Codex 构建一个自我改进的外联系统。通过将市场反馈记录为内存文件,Codex 自动评估并修改评分规则和话术配置,提交优化建议供人工审核,从而实现 GTM 策略的持续迭代与优化。 技术 › Codex ✍ Nicolas Finet🕐 2026-07-20 CodexAgent自我改进自动化GTMDevOps外联系统
拼 拼贴动画 B-roll Skill 正式开源 作者开源了一款基于 Codex 的拼贴动画 B-roll 生成 Skill。该工具可将口播文稿转化为黑白半调风格的 B-roll 视频,采用三重 QA 机制节省成本。目前仅支持 Codex,后续更新将增加定制化角色功能。 技术 › Skill ✍ 狗哥笔记🕐 2026-07-19 开源视频生成AI自动化CodexGeminiB-roll
B Building a Self-Improving, AI-Native Company 文章介绍了Deel如何构建自我改进的AI系统。通过Bug Hunter和Deel Code两个Agent,系统自动在真实客户环境中发现漏洞、编写修复代码并验证结果。人只负责最终审批,将工程师移至决策环节,实现软件闭环自我进化。 技术 › Agent ✍ Dan Westgarth🕐 2026-07-16 AI Agent自动化软件测试闭环系统LLMDevOps代码修复
W WorkBuddy 无痛发 X 长文流水线搭建 文章介绍了如何基于 WorkBuddy 搭建一条自动发布 X(Twitter)长文的流水线。该流程解耦了特定客户端依赖,使用 Node.js 脚本直连 Buffer 和 Typefully API,实现了从素材抓取、摘要生成、配图制作到自动排期发布的全自动化,并重点解决了非交互 shell 环境变量配置及超时等问题。 技术 › Agent ✍ 码良🕐 2026-07-15 WorkBuddy自动化流水线TypefullyBufferCodexSKILL.mdDevOpsAI
C Codex神级插件分类指南 本文深入解析Codex插件生态,将其分为上下文接入、沟通协作、工程研发、运行部署等8大类,并指导如何根据能力边界和实际工作流选择优先级最高的插件。 技术 › Codex ✍ SakuAI🕐 2026-07-14 Codex插件AI Agent工作流自动化开发工具
O OpenAI 重大更新:终结对话时代,打造 AI 工程团队 文章详细解读了 OpenAI 的最新更新,包括 GPT-5.6 模型家族的发布、GPT-Live 全双工语音交互的引入,以及 ChatGPT Work 和 Codex 的深度整合。核心观点是 ChatGPT 正从单一的问答机器人进化为包含规划、多代理协作、代码执行和语音交互的“AI 工程工作台”。文章还针对 Codex 用户提供了模型选择建议。 技术 › OpenAI ✍ Rachel🕐 2026-07-13 OpenAIGPT-5.6CodexAI AgentGPT-LiveChatGPT Work多模态语音交互工程自动化