OpenAI 正在确立 Coding Agents 的默认编排层

✍ AlphaSignal AI🕐 2026-04-29📦 10.9 KB 🟢 已读 𝕏 文章列表

文章介绍了 OpenAI 生态内两个同时发布的开源项目：Symphony 和 ClawSweeper。两者均基于 Codex App Server 这一原始编排层，分别针对 SDLC 的两端（PR 创建与 Issue 维护）提供了参考实现。Symphony 将 Linear 转化为自动化代理系统，提升 PR 吞吐量；ClawSweeper 则能并行运行大量 Codex 实例，自动清理无意义 Issue。文章分析了它们的架构模式、应用场景及局限性。

# How OpenAI Is Setting the Default Orchestration Layer for Coding Agents **作者**: AlphaSignal AI **日期**: 2026-04-27T18:02:02.000Z **来源**: [https://x.com/AlphaSignalAI/status/2049172133578703181](https://x.com/AlphaSignalAI/status/2049172133578703181) ![Image](/doc/1250/image/img_ebcbdc451018.jpg) ## Symphony spawns Codex per Linear ticket. ClawSweeper closes 4,000 issues a day with 50 parallel Codex shards. Both shipped this week, both bind to Codex App Server, both are open source. Symphony lifted PR throughput 500% inside OpenAI. ClawSweeper closed 4,000 issues on day one. Both are open-source Codex fleets that shipped within 48 hours of each other. Both bind to the same primitive: Codex App Server. The orchestration layer for autonomous coding agents now has two reference implementations on opposite ends of the SDLC, and they are both coming out of OpenAI's orbit. > **OpenAI Developers@OpenAIDevs**: [原文链接](https://x.com/OpenAIDevs/status/2048825010371039648) > > What if every open issue had a Codex agent? > That’s the idea behind Symphony, an open-source agent orchestrator for Codex that turns task trackers into always-on systems for agentic work, letting humans focus on review and direction. ## Context Symphony is OpenAI's orchestration spec and reference implementation, announced Apr 27, 2026. It polls a Linear board, creates a workspace per ticket, and runs Codex inside each workspace until the work lands as a reviewed PR. The spec is in SPEC.md, the reference is in Elixir. Apache 2.0, ~17.3K GitHub stars. ClawSweeper is the maintenance counterpart from the OpenClaw foundation, announced two days earlier. It scans every open issue and PR on openclaw/openclaw and openclaw/clawhub, writes one markdown evidence report per item, and closes only when the evidence is overwhelming. MIT, ~1.3K stars. ClawSweeper was built by Peter Steinberger, who joined OpenAI in February and whose OpenClaw foundation is now OpenAI-sponsored. ## The shared pattern Both tools poll a queue, isolate each item in its own execution unit, launch a Codex agent inside, and produce auditable artifacts a human reviews at the end. Symphony's queue is a Linear board. ClawSweeper's queue is a GitHub issue cron. Symphony's isolation unit is a per-issue workspace directory. ClawSweeper's is a CI shard. Both launch codex app-server, the JSON-RPC headless mode that lets Codex run without a terminal. Both keep the human in review-only position. The pattern is the story. ## Symphony Workflow Loader. Reads WORKFLOW.md from the target repo. YAML front-matter sets tracker config, workspace root, hooks, agent concurrency, and Codex command. The Markdown body becomes the per-issue Codex prompt template. Issue Tracker Client. Polls Linear on a configurable cadence. Pulls candidate issues in active states, normalizes them, and hands them to the orchestrator. Orchestrator. Owns dispatch, retry queue, and reconciliation. No persistent database. State recovers from the tracker plus the filesystem on restart. Workspace Manager. Creates a per-issue directory under workspace.root. Runs hooks.after_create (typically git clone) to bootstrap. Cleans up when an issue hits a terminal state. Agent Runner. Launches codex app-server per workspace and streams updates back. Default sandbox is workspace-write. Example config sets max_concurrent_agents to 10 and max_turns to 20. The spec is language-agnostic. Elixir is the reference because Erlang/OTP supervises long-running processes well. ## ClawSweeper Scheduler. Hot and new items are checked hourly with a 5-minute intake window. Items younger than 30 days are checked daily once they leave the hot window. Older inactive issues are checked weekly. The apply lane wakes every 15 minutes. > **Peter Steinberger @steipete**: [原文链接](https://x.com/steipete/status/2047982647264059734) > > Built clawsweeper, which runs 50 codex in parallel around the clock, scans issues/prs deep and closes what is already implemented or what makes no sense. > Closed around 4000 issues today, a few thousand are in the pipeline. (rate limits are rough) Review Lane. Proposal-only, never closes. The planner shards open items into parallel batches (313 items across 100 shards in the latest run, 500-item capacity). Each shard runs Codex with gpt-5.5, high reasoning effort, and a 10-minute per-item timeout. Output is a flat markdown report at records/<repo-slug>/items/<n>.md with decision, evidence, runtime metadata, and a snapshot hash of the GitHub state. Apply Lane. Reads stored reports and mutates GitHub only when the snapshot still matches live state. Closes a maximum of 50 fresh items per checkpoint. If the issue changed since review, apply skips it. Closed reports move to records/<repo-slug>/closed/<n>.md. The safety model is strict. Codex review shards run with all OpenAI and GitHub tokens stripped from the environment, and the GitHub App token only enters the apply and comment-sync jobs. Codex literally cannot push to GitHub even if attacker-controlled issue text compromises a session. OpenClaw itself is model-agnostic and supports Claude, GPT, Gemini, and local models through a unified interface. ClawSweeper exclusively runs Codex. ## How they compare ![Image](/doc/1250/image/img_ef053aa09f9e.jpg) ## Evidence ![Image](/doc/1250/image/img_02bc4233c063.jpg) Symphony's internal experiment came out of OpenAI's Frontier Product Exploration team, which built a production Electron app over five months with zero human-written code. The case study is documented in ZenML's harness engineering write-up. ClawSweeper's dashboard updates live in its README. As of Apr 28, 2026, 12:59 UTC, it shows 7,888 open items under management, 10,353 closed to date, and a 0% close rate on openclaw/openclaw proposals over the last 7 days. The guardrails skew heavily toward keep-open. The only public cost signal is Steinberger's "rate limits are rough." Neither README publishes a per-issue cost figure. ## Limitations Symphony is engineering preview, not a product. The repo banner says so explicitly: "low-key engineering preview for testing in trusted environments." OpenAI confirmed it has no plans to maintain Symphony as a standalone product. Teams adopting it are signing up to fork and harden, not to install. ClawSweeper is hardcoded to two OpenClaw repos. The README, the prompts, and the close categories are tuned to OpenClaw conventions. Forking elsewhere requires rewriting close-condition rules, label protections, and repo profiles. The tool is a reference design for AI-assisted maintenance, not a generic GitHub bot. Both are token-heavy and rate-limit-bound. Symphony runs 10 concurrent workspaces with up to 20 Codex turns each on continuous polling. ClawSweeper runs 50 shards on gpt-5.5 with high reasoning effort. Steinberger flagged rate limits in the announcement. Neither README publishes a /issueor/PR cost figure. So the best recommendation is to clone both this week, run Symphony's Elixir reference against a Linear test project, fork ClawSweeper for one of your noisier repos, and budget for Codex rate-limit headroom before either goes anywhere near production. ## Who benefits and who doesn't These tools fit engineering teams managing high-volume backlogs (over 1,000 open items, over 100 PRs per week), platform teams already standardized on Codex CLI in CI, founders running autonomous-PR experiments who do not want to build orchestration from scratch, and OSS maintainers drowning in stale issues. They do not fit teams without strong CI and harness engineering, teams locked into a tracker other than Linear (Symphony's reference is Linear-only), teams operating on Claude or Gemini infrastructure (the reference fleets are Codex-bound and forks are unofficial), or teams with low-volume backlogs where the orchestration overhead exceeds the human time saved. ## Practitioner implication Production-grade Codex fleet orchestration is now a clone-and-fork problem for engineering platform teams, now that OpenAI has open-sourced both the issue-creation pattern (Symphony) and the issue-closure pattern (ClawSweeper) in MIT and Apache 2.0 form. ## Links - openai/symphony (repo, ~30 min setup for Elixir reference) - openclaw/clawsweeper (repo, ~few hours to fork and adapt) - Symphony SPEC.md (spec, ~25 min read) - Codex App Server docs (docs, ~10 min read) Follow @AlphaSignalAI for more content like this. Subscribe at AlphaSignal.ai for daily AI signals. Read by 280,000+ developers. ## Questions? What is OpenAI Symphony? Symphony is an open-source agent orchestrator from OpenAI that turns a Linear board into a control plane for Codex agents. For every open task, an agent runs in its own workspace and produces a PR with proof of work. Apache 2.0, github.com/openai/symphony. Is Symphony free and open source? Yes. Symphony ships with a language-agnostic SPEC.md and an Elixir reference implementation. OpenAI does not plan to maintain it as a product, and publishes it as a reference and an invitation to fork. What does ClawSweeper do? ClawSweeper is a conservative AI maintenance bot for OpenClaw repositories. It runs around 50 Codex agents in parallel on a cron schedule, writes a markdown evidence report per open item, and closes only when evidence is overwhelming. It closed 4,000 issues on day one. Can Symphony or ClawSweeper run on Claude or Gemini? Not at the reference layer. Both bind to OpenAI's Codex App Server in their official implementations. Community forks like Stokowski (Claude Code) re-implement the spec against other runtimes, but they are unofficial. What's the difference between Symphony and ClawSweeper? Symphony creates new code from tickets. ClawSweeper closes stale tickets. They sit on opposite ends of the SDLC and use the same parallel-Codex pattern. ## 相关链接 - [AlphaSignal AI](https://x.com/AlphaSignalAI) - [@AlphaSignalAI](https://x.com/AlphaSignalAI) - [1.7K](https://x.com/AlphaSignalAI/status/2049172133578703181/analytics) - [Apr 28](https://x.com/OpenAIDevs/status/2048825010371039648) - [946K](https://x.com/OpenAIDevs/status/2048825010371039648/analytics) - [Apr 25](https://x.com/steipete/status/2047982647264059734) - [2.1M](https://x.com/steipete/status/2047982647264059734/analytics) - [openai/symphony](https://github.com/openai/symphony) - [openclaw/clawsweeper](https://github.com/openclaw/clawsweeper) - [Symphony SPEC.md](https://github.com/openai/symphony/blob/main/SPEC.md) - [Codex App Server docs](https://developers.openai.com/codex/app-server/) - [@AlphaSignalAI](https://x.com/AlphaSignalAI) - [AlphaSignal.ai](https://alphasignal.ai/) - [github.com/openai/symphony](https://github.com/openai/symphony) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:01 AM · Apr 29, 2026](https://x.com/AlphaSignalAI/status/2049172133578703181) - [1,776 Views](https://x.com/AlphaSignalAI/status/2049172133578703181/analytics) *导出时间: 2026/4/29 10:10:57* --- # 中文翻译 # OpenAI 如何确立 Coding Agents 的默认编排层 **作者**: AlphaSignal AI **日期**: 2026-04-27T18:02:02.000Z **来源**: [https://x.com/AlphaSignalAI/status/2049172133578703181](https://x.com/AlphaSignalAI/status/2049172133578703181) ![Image](/doc/1250/image/img_ebcbdc451018.jpg) ## Symphony 为每个 Linear 工单生成 Codex 实例。ClawSweeper 利用 50 个并行 Codex 分片每天关闭 4,000 个问题。两者均于本周发布，均绑定到 Codex App Server，且均为开源。 Symphony 将 OpenAI 内部的 PR（拉取请求）吞吐量提升了 500%。 ClawSweeper 在首日关闭了 4,000 个 issue。两者都是开源的 Codex 队列，发布时间前后相差不超过 48 小时。两者都绑定到同一个基础组件：Codex App Server。自主编程代理的编排层现在在 SDLC（软件开发生命周期）的两端都有了参考实现，而且它们都出自 OpenAI 的生态圈。 > **OpenAI Developers@OpenAIDevs**: [原文链接](https://x.com/OpenAIDevs/status/2048825010371039648) > > 如果每个开放的 issue 都有一个 Codex 代理会怎样？ > 这就是 Symphony 背后的理念，它是一个用于 Codex 的开源代理编排器，将任务跟踪器转变为代理工作的常驻系统，让人类专注于审查和方向把控。 ## 背景 Symphony 是 OpenAI 的编排规范和参考实现，于 2026 年 4 月 27 日发布。它会轮询 Linear 看板，为每个工单创建一个工作区，并在每个工作区内运行 Codex，直到工作成果变成经过审查的 PR 为止。规范位于 SPEC.md，参考实现使用 Elixir 编写。采用 Apache 2.0 协议，GitHub 约有 1.73 万星。 ClawSweeper 是来自 OpenClaw 基金会的维护配套工具，于两天前发布。它会扫描 openclaw/openclaw 和 openclaw/clawhub 上的每一个开放 issue 和 PR，为每个项目撰写一份 markdown 证据报告，并且仅在证据确凿时才关闭 issue。采用 MIT 协议，约 1.3 千星。 ClawSweeper 由 Peter Steinberger 构建，他于 2 月加入 OpenAI，其创立的 OpenClaw 基金会现已获得 OpenAI 赞助。 ## 共同模式这两个工具都会轮询一个队列，将每个项目隔离在其独立的执行单元中，在内部启动一个 Codex 代理，并最终生成供人类审查的可审计产物。Symphony 的队列是 Linear 看板。ClawSweeper 的队列是 GitHub issue 的定时任务（cron）。Symphony 的隔离单元是针对每个 issue 的工作区目录。ClawSweeper 的则是 CI 分片。两者都会启动 codex app-server，这是让 Codex 无需终端即可运行的 JSON-RPC 无头模式。两者都将人类限制在仅审查的位置。这种模式就是核心故事。 ## Symphony 工作流加载器。从目标仓库读取 WORKFLOW.md。YAML 前置元数据设置跟踪器配置、工作区根目录、钩子、代理并发数和 Codex 命令。Markdown 正文则成为针对每个 issue 的 Codex 提示词模板。 Issue 跟踪器客户端。以可配置的节奏轮询 Linear。拉取活跃状态下的候选 issue，将其标准化，并将其移交给编排器。编排器。负责调度、重试队列和对账。没有持久化数据库。重启后，状态从跟踪器和文件系统恢复。工作区管理器。在 workspace.root 下为每个 issue 创建目录。运行 hooks.after_create（通常是 git clone）来进行引导。当 issue 达到终态时进行清理。代理运行器。为每个工作区启动 codex app-server 并流式传回更新。默认沙箱是 workspace-write。示例配置将 max_concurrent_agents 设置为 10，将 max_turns 设置为 20。该规范是语言无关的。选择 Elixir 作为参考实现是因为 Erlang/OTP 能很好地监管长时间运行的进程。 ## ClawSweeper 调度器。热门和新的项目每小时检查一次，摄入窗口为 5 分钟。超过 30 天的项目在离开热门窗口后每天检查一次。较旧的非活跃 issue 每周检查一次。应用通道每 15 分钟唤醒一次。 > **Peter Steinberger @steipete**: [原文链接](https://x.com/steipete/status/2047982647264059734) > > 我编写了 clawsweeper，它全天候并行运行 50 个 codex，深度扫描 issue/pr 并关闭已实现或毫无意义的内容。 > 今天关闭了大约 4000 个 issue，还有几千个正在处理中。（配额限制真严苛）审查通道。仅提交提案，永不关闭。规划器将开放项目分片为并行批次（在最新一次运行中，313 个项目分布在 100 个分片中，容量为 500 项）。每个分片运行 Codex，使用 gpt-5.5、高推理强度以及每项 10 分钟的超时时间。输出是一个位于 records/<repo-slug>/items/<n>.md 的平面 markdown 报告，包含决定、证据、运行时元数据和 GitHub 状态的快照哈希。应用通道。读取存储的报告，仅当快照仍与实时状态匹配时才修改 GitHub。每个检查点最多关闭 50 个新项目。如果 issue 自审查以来发生变化，应用会跳过它。已关闭的报告会移至 records/<repo-slug>/closed/<n>.md。安全模型非常严格。Codex 审查分片运行时会剥离环境中所有的 OpenAI 和 GitHub 令牌，GitHub App 令牌仅进入应用和评论同步任务。即使受攻击者控制的 issue 文本破坏了会话，Codex 也完全无法推送到 GitHub。 OpenClaw 本身是模型无关的，通过统一接口支持 Claude、GPT、Gemini 和本地模型。ClawSweeper 专门运行 Codex。 ## 对比 ![Image](/doc/1250/image/img_ef053aa09f9e.jpg) ## 实证 ![Image](/doc/1250/image/img_02bc4233c063.jpg) Symphony 的内部实验出自 OpenAI 的前沿产品探索团队，该团队在五个月内构建了一个生产级的 Electron 应用，编写的人类代码量为零。该案例研究记录在 ZenML 的 harness engineering 文章中。 ClawSweeper 的仪表盘在其 README 中实时更新。截至 2026 年 4 月 28 日 12:59 UTC，它显示管理着 7,888 个开放项目，迄今为止已关闭 10,353 个，过去 7 天内在 openclaw/openclaw 提案上的关闭率为 0%。防护机制严重偏向“保持开放”。唯一公开的成本信号是 Steinberger 提到的“配额限制真严苛”。两个 README 都未公布每个 issue 的成本数据。 ## 局限性 Symphony 是工程预览版，不是产品。仓库横幅明确写着：“用于在受信任环境中测试的低调工程预览版。”OpenAI 确认没有计划将 Symphony 作为独立产品来维护。采用它的团队意味着要 fork 并加固它，而不仅仅是安装它。 ClawSweeper 硬编码绑定到两个 OpenClaw 仓库。README、提示词和关闭类别都是针对 OpenClaw 约定调整的。要在其他地方 fork 需要重写关闭条件规则、标签保护和仓库配置。该工具是 AI 辅助维护的参考设计，而非通用的 GitHub 机器人。两者都消耗大量 token 且受限于速率限制。Symphony 在持续轮询下运行 10 个并发工作区，每个工作区最多执行 20 次 Codex 交互。ClawSweeper 在高推理强度的 gpt-5.5 上运行 50 个分片。Steinberger 在发布公告时强调了速率限制问题。两个 README 都未公布每个 issue 或 PR 的成本数据。因此，最好的建议是本周克隆这两个项目，针对 Linear 测试项目运行 Symphony 的 Elixir 参考实现，为你那些嘈杂的仓库 fork 一份 ClawSweeper，并在考虑投入生产之前为 Codex 的速率限制预留足够的余地。 ## 谁受益，谁不受益这些工具适合管理大量积压工作（超过 1,000 个开放项目，每周超过 100 个 PR）的工程团队、已经将 Codex CLI 标准化到 CI 中的平台团队、不想从零开始构建编排的自主 PR 实验运行者，以及被陈旧 issue 淹没的开源维护者。它们不适合没有强大 CI 和 harness 工程的团队、被锁定在 Linear 以外跟踪器的团队（Symphony 的参考实现仅支持 Linear）、运行在 Claude 或 Gemini 基础设施上的团队（参考队列绑定 Codex，fork 版本是非官方的），或者是积压量较少导致编排开销超过节省的人工时间的团队。 ## 从业者启示既然 OpenAI 已经以 MIT 和 Apache 2.0 协议开源了 issue 创建模式和 issue 关闭模式，那么生产级 Codex 队列编排对于工程平台团队来说，现在已经成为一个克隆和 fork 的问题。 ## 链接 - openai/symphony (仓库，Elixir 参考实现约需 30 分钟设置) - openclaw/clawsweeper (仓库，fork 和适配约需数小时) - Symphony SPEC.md (规范，约需 25 分钟阅读) - Codex App Server 文档 (文档，约需 10 分钟阅读) 关注 @AlphaSignalAI 获取更多此类内容。在 AlphaSignal.ai 订阅以获取每日 AI 信号。拥有 280,000+ 开发者读者。 ## 常见问题 OpenAI Symphony 是什么？Symphony 是 OpenAI 的开源代理编排器，它将 Linear 看板转变为 Codex 代理的控制平面。对于每个开放任务，代理会在自己的工作区中运行并生成包含工作证明的 PR。Apache 2.0 协议，github.com/openai/symphony。 Symphony 是免费且开源的吗？是的。Symphony 附带一个语言无关的 SPEC.md 和一个 Elixir 参考实现。OpenAI 不计划将其作为产品维护，而是作为参考发布并邀请社区 fork。 ClawSweeper 做什么？ClawSweeper 是用于 OpenClaw 仓库的保守型 AI 维护机器人。它按 cron 计划并行运行大约 50 个 Codex 代理，为每个开放项目撰写 markdown 证据报告，并仅在证据确凿时才关闭。它在首日关闭了 4,000 个 issue。 Symphony 或 ClawSweeper 可以在 Claude 或 Gemini 上运行吗？在参考层面上不行。两者的官方实现都绑定到 OpenAI 的 Codex App Server。像 Stokowski (Claude Code) 这样的社区 fork 针对其他运行时重新实现了该规范，但它们是非官方的。 Symphony 和 ClawSweeper 有什么区别？Symphony 根据工单创建新代码。ClawSweeper 关闭陈旧工单。它们位于 SDLC 的两端，并使用相同的并行 Codex 模式。 ## 相关链接 - [AlphaSignal AI](https://x.com/AlphaSignalAI) - [@AlphaSignalAI](https://x.com/AlphaSignalAI) - [1.7K](https://x.com/AlphaSignalAI/status/2049172133578703181/analytics) - [Apr 28](https://x.com/OpenAIDevs/status/2048825010371039648) - [946K](https://x.com/OpenAIDevs/status/2048825010371039648/analytics) - [Apr 25](https://x.com/steipete/status/2047982647264059734) - [2.1M](https://x.com/steipete/status/2047982647264059734/analytics) - [openai/symphony](https://github.com/openai/symphony) - [openclaw/clawsweeper](https://github.com/openclaw/clawsweeper) - [Symphony SPEC.md](https://github.com/openai/symphony/blob/main/SPEC.md) - [Codex App Server docs](https://developers.openai.com/codex/app-server/) - [@AlphaSignalAI](https://x.com/AlphaSignalAI) - [AlphaSignal.ai](https://alphasignal.ai/) - [github.com/openai/symphony](https://github.com/openai/symphony) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:01 AM · Apr 29, 2026](https://x.com/AlphaSignalAI/status/2049172133578703181) - [1,776 Views](https://x.com/AlphaSignalAI/status/2049172133578703181/analytics) *导出时间: 2026/4/29 10:10:57*

🔗 相关文档