Agent Workflow 全景对比：Claude Code / Codex / Cursor

2026 年上半年，Anthropic、OpenAI、Cursor（Anysphere）几乎同期给出了各自对”任务大到单 Agent 上下文装不下时怎么编排”这个问题的答案，名称各异但解决的是同一类瓶颈：单会话交互式 Agent 遇到大规模、长时程、多阶段任务时如何扩展。本页详细梳理三家的设计思路、机制细节和实际使用心得。

一句话对比

产品/方案	厂商	一句话定位	状态
Dynamic Workflows	Anthropic / Claude Code	Claude 运行时自己写 JS 编排脚本，调度几十到上百个子 Agent 并行执行，会话可离线	2026-05-28 发布，已 GA
Symphony	OpenAI / Codex	开源编排规范，把 Linear 等工单看板变成 Codex Agent 的控制平面，每个工单绑一个持续运行的 Agent	2026-04-27 开源发布
Agents Window / Background Agents	Anysphere / Cursor	IDE 内把 Agent 提升为一等工作区对象，靠 Git worktree/远程/云实例做并行隔离	2026-04 随 Cursor 3.0 发布（前身 Background Agents 2025 年底上线）

三者的核心差异在瓶颈假设不同：Claude Code 认为瓶颈是”单 LLM 上下文扛不住复杂度”，Codex/Symphony 认为瓶颈是”人类盯多个会话的注意力”，Cursor 认为瓶颈是”IDE 交互模型没把 Agent 当一等对象”。

一、Claude Code：Dynamic Workflows

一句话：Claude 根据当前任务，现场写一段 JavaScript 脚本，用这段脚本调度几十到上百个子 Agent 并行干活，最后把结果汇总回来。2026-05-28 发布并已 GA，解决的核心问题是单会话上下文同时扛规划/执行/验证/汇总四种职责导致的三大失效模式：Agentic laziness（偷懒）、Self-preferential bias（自评偏好）、Goal drift（目标漂移）。

机制要点：xhigh effort 推理预算 + 会话中途系统消息动态授权子 Agent；执行分接收计划→分发执行→交叉验证三阶段；支持分类路由/扇出综合/对抗验证/生成过滤/锦标赛/循环直到完成六种可组合编排模式；触发方式为 prompt 关键词（ultracode）/ /effort ultracode 全会话模式 / 内置 /deep-research；同时运行上限约 16 并发、单次总计约 1000 个子 Agent；支持通过 /workflows 面板管理运行、保存为可复用命令并传参。

适合：全仓库 bug 排查、跨数百文件的框架迁移、需要多角度对抗验证的高风险决策、竞态复现、大规模分拣/根因分析、事实核查。不适合：写一个函数、改一个 bug 这类日常小任务，token 消耗反而得不偿失。

详细机制、脚本示例、运行时约束、成本控制、四方定位对照表见 principles 与 claude-code-usage。

二、OpenAI Codex：Symphony

视角转变：从”会话”到”任务”

OpenAI 内部团队此前做过一个实验——用 Codex 生成一个内部工具项目的全部代码，不写一行人工代码，把 Codex 当正式团队成员（记录在此前的 harness engineering 博客里）。这个方法奏效了，但随后撞到新瓶颈：上下文切换。

具体表现：每位工程师要开几个 Codex 会话，分配任务、审查输出、引导 Agent、然后重复。实践中大多数人只能舒服地同时管理 3-5 个会话，超过这个数就会因为频繁切换而痛苦——忘记哪个会话在做什么，在终端间来回跳，把 Agent 拉回正轨，调试卡住的长任务。

OpenAI 的诊断：Agent 本身运行很快，系统瓶颈是人类注意力。相当于组建了一支能力极强的”初级工程师团队”，却让人类工程师做细粒度微观管理——这种模式没法规模化。

解法是视角转变：不再围绕会话和 PR 组织系统，而是围绕交付物（issue、任务、工单、里程碑）组织——这些本就是软件工作流的组织单位。于是设计出 Symphony：让 Agent 不再是被人类临时唤起的工具，而是从任务追踪器里主动拉取工作的持续运行执行者。

核心工作流

把 issue tracker（如 Linear）当作 Agent 的控制平面（control plane），典型流程：

创建 issue
  → Symphony 轮询到可执行任务
  → 为该 issue 创建独立 workspace
  → 启动 Codex agent session（App Server 模式）
  → Agent 阅读任务、修改代码、运行测试
  → 创建或更新 PR
  → 写回任务状态、评论、证据和交付物
  → 人类 review、合并或退回

关键设计点：

每个未关闭 issue 对应一个专属 Agent 工作区，磁盘隔离，避免一个 Agent 的命令影响到 scope 外的代码
Symphony 持续监看任务看板，Agent 崩溃或卡住会被自动重启，新工单出现会被自动接手
工作流定义写在仓库内版本化的 WORKFLOW.md 文件里，团队可以把 Agent 的 prompt 和运行时配置跟代码一起管理，随代码库演进
任务依赖可自然形成 DAG，未阻塞的任务可并行推进——这点和传统 CI”代码提交后自动化”不同，Symphony 更像”issue 创建后自动化”

目标驱动而非死板状态机

Symphony 不是严格的 if/then 状态机，官方强调给 Agent 的是”目标”而不是”僵化的状态转移规则”——具体到怎么完成、中间要不要拆子任务、要不要多轮迭代，由 Agent 自己判断，Symphony 只负责保证”这个目标始终有 Agent 在推进”这一点。

架构（6 组件）

Workflow Loader、Config Layer、Issue Tracker Client、Orchestrator、Workspace Manager、Agent Runner，外加可选的 Status Surface 做可观测性。官方参考实现用 Elixir + BEAM 虚拟机（容错性和高并发是选型理由——单个任务出错或崩溃不影响整体项目进度，还能自动恢复），社区有 Go/Python 等替代实现。开源协议 Apache 2.0，仓库：github.com/openai/symphony。

上手流程（社区实操总结）

安装 Elixir + BEAM，克隆仓库，执行 mix deps.get && mix compile && mix symphony.init
在项目仓库根目录创建 WORKFLOW.md，配置任务触发条件（如 Linear 项目 ID + 标签）、沙箱资源限制（内存/CPU）、验收标准（单测/代码审查/报告）
关联项目管理工具的接口信息
执行 mix symphony.start 启动自主运行，全程无需人工干预
Symphony 自动做成果验证、生成验收报告，通过后自动提交代码

效果与风险

效果：部分团队合并 PR 数在前三周内提升 500%。开源上线后短期内拿下 GitHub 4000+ star。

争议/风险（社区讨论）：支持者认为”终于能摆脱无效监督，专注核心管理”；质疑者认为”AI 自主编码不被实时盯着，迟早出大问题”——核心争议点在于验收环节的自动化程度是否足够可靠，是否会把风险从”写错代码”转移到”验收环节漏判”。

三、Cursor：Agents Window / Background Agents

演进路径

2025 年底先推出 Background Agents：Composer 会话可以在独立进程里运行，不阻塞编辑器，切换到别的项目后再回来查看 diff 即可，是”异步化”的第一步。

2026 年 4 月 Cursor 3.0 更进一步，退役旧版 Composer，推出 Agents Window：核心变化是把 Agent 从”聊天侧边栏里的新奇小工具”提升为一等工作区对象。工作模式从”你写代码，AI 补全建议”转变为”你提需求，Agent 去执行，你审查结果”。

关键特性

多 Agent 并行：Cursor 2.0（2025-10-29）起支持单个 prompt 下最多 8 个 Agent 并行运行，用 Git worktree 或远程机器防止文件冲突，每个 Agent 在自己隔离的代码库副本里操作
/worktree 命令：让 Agent 在隔离的 Git worktree 里工作，主分支不被乱改，对多任务并行至关重要
/best-of-n：多个模型同时跑同一个任务，对比结果选最优（需 Pro 订阅）
Design Mode：浏览器预览页面里直接框选 UI 元素，告诉 Agent “这个按钮改成红色”，不再需要截图-描述-贴代码流程
Await 工具：Agent 执行长任务（跑构建/测试）时可挂起等待，结果出来再继续，不用一直轮询，对接 CI/CD 有用
Sandboxed Terminals：macOS 默认沙箱执行未在白名单的 shell 命令，仅可读写工作区、无网络访问
JetBrains 插件让编排能力扩展到非 VS Code 用户

Worktree + 多 Agent：两层隔离

社区文章反复强调这是两个不同层面的能力，容易被混为一谈：

能力	解决什么问题	类比
Git Worktree	同一仓库多份工作目录，互不干扰（物理隔离，文件系统层面）	两个工位各干各的，不抢同一张桌子
多 Agent 并行	多个 Agent 会话同时跑，各自独立上下文（执行隔离，对话/任务层面）	两个实习生同时接单，各写各的模块

两者配合才能放心让 Agent”放手干”：干砸了直接删 worktree，主分支一行没动。

何时该用 / 何时不该用（社区实战经验）

适合并行（按拆分维度）：

框架迁移（如 Options API → Composition API）——模块间耦合低、迁移模式统一，按 views/ 子目录拆分
批量重命名/路径调整——改动模式重复，按目录或文件类型拆分
多页面 UI 统一改版——页面互不依赖，按 page/route 拆分
实验性架构验证——可能全盘推翻，用独立 worktree 不合并
大仓库多 feature 并行开发——按 feature 模块拆分

不适合：

改 1-2 个文件——开 worktree 比改动本身还重，直接用单 Agent 或 Tab 补全
强耦合公共层重构——多 Agent 必然抢同一文件，改用单 Agent + Plan，或先把公共层抽出来
涉及数据库迁移——并行难以协调执行顺序，改串行 Agent + 严格 Plan
对代码不熟——任务都拆不对，先用 Ask 模式摸底

决策清单（满足 3 条及以上再开多 Agent）：改动涉及 10+ 文件或 3+ 模块；已在 Plan 模式对齐总体方案；任务可按目录/模块切分且无共享文件交叉；已配置 Rules 约束输出风格；预留了合并后的人工 review 时间。

标准工作流（五步）：

Plan 模式对齐迁移模式——千万别跳过，多 Agent 翻车的第一大原因是各 Agent 用了不同的迁移模式/实现风格
按模块/目录拆分任务，为每个任务开一个 worktree + Agent
各 Agent 独立执行、独立提交
严格人工 review 合并前的 diff，避免风格漂移和跨模块冲突
合并，删除已完成的 worktree

实测案例：一次「Options API → Composition API」批量迁移，两个 Agent 并行，核心迁移周期从一周压缩到 2-3 天；但代价也真实——合并冲突、风格不一致、某个 Agent 擅自修改了公共组件，说明并行编排不是零成本的效率倍增，需要配套的 Plan 对齐和人工 review 兜底。

权限与订阅边界（Cursor 3 踩坑点）

自定义 API Key 只能用于 Chat/Ask 模式；Agent、Edit、Tab 自动补全这三个核心功能必须走 Cursor 订阅，无法用自定义 API Key 计费。/best-of-n 同样需要 Pro 订阅。这是不少用户升级 Cursor 3 后踩的第一个坑。

四、三家横向小结

维度	Claude Code Dynamic Workflows	OpenAI Symphony	Cursor Agents Window
瓶颈假设	单 LLM 上下文装不下复杂度	人类监督多会话的注意力	IDE 交互模型没把 Agent 当一等对象
编排主体	Claude 现场生成的 JS 脚本	持续轮询 issue tracker 的独立 Orchestrator 服务	IDE 内置的 Agent 管理层
任务入口	自然语言 prompt（含 `ultracode` 关键词）	Issue tracker（Linear 等）里的工单	Prompt + 手动划分 worktree
隔离方式	独立上下文的子 Agent（逻辑隔离）	每 issue 独立磁盘 workspace	Git worktree（物理隔离）+ 独立会话
规模上限	约 1000 个子 Agent/次，16 并发	受限于 issue tracker 里未关闭任务数	单 prompt 最多 8 个并行 Agent
人类角色	审批关键节点、查看进度	只审 PR/结果，不管任务分派	Plan 对齐 + 合并前 review
落地阶段	已 GA，但仍是”研究预览”级 token 成本	开源规范，官方参考实现是原型级	已 GA，随 IDE 版本迭代

这三套方案都还停留在 agentic-work 框架里”Agentic Workflow”这一层——单个业务流程内怎么让 Agent 自主决策、调用工具、多步推理。往上一层的 Agent Workforce（多 Agent 团队协作）和 Agentic Work（组织级人机协作范式）仍在演化中。

zhaoweiguo 的知识库

目录