2026 年第二季度，Codex CLI、Claude Code、Cursor 三家在 90 天内不约而同收敛到同一套架构——前台"等待响应"型编码智能体正式退场，取而代之的是**异步后台智能体（background agent）+ 监督循环**模型。它们没有协调，却被同一股力量推到一起：当头部团队的 AI 辅助代码占比冲到 60–75%、PR 周期压到 8 小时以内，瓶颈已经从"模型能力"转移到了"开发者注意力"。释放这层瓶颈的唯一办法，是让一个人同时监督一支智能体舰队。 本文拆解这套**异步监督循环（async supervision loop）**的骨架——事件触发、沙箱执行、检查点汇报、唤醒续跑——并实测三个头部栈的同构之处、四个真正的塌方点，以及"弱模型异步栈打败强模型同步栈"这条反直觉结论背后的机理。 ## 对比表格：四大异步后台栈横评 | 框架/工具 | 异步机制 | 并行度 | 持久化 | 通知语义 | 最适合场景 | |---|---|---|---|---|---| | **Codex CLI Realtime V2**（OpenAI） | 流式进度 + 排队响应 | 单后台任务 | 会话级 | steering 更新不阻塞队列 | 单人/结对，最低迁移摩擦 | | **Claude Code v2.0.64+**（Anthropic） | 异步子智能体 + 唤醒消息 | 多子/父 | 跨父任务存活 | 检查点通知 + cron/webhook routines | PR 中心流、本地优先、数据治理严 | | **Cursor 3 Agents Window** | worktree 并行 + 本地↔云交接 | 最多 8 并行 | 云持久化 | Agents Window 看板 | 多模型 best-of-N、平台团队 | | **Tembo**（编排层） | 事件驱动调度 | 调度多智能体 | 跨事件 | 触发→审计闭环 | 多智能体协调、避免厂商锁定 | > 关键判据不是"SWE-bench 谁更高"，而是**"你的团队监督者-智能体比例是多少"**——异步原语是否匹配这个比例。 ## 深度分析 ### 1. 异步监督循环：从"等待"到"轮询/唤醒"的范式跃迁 前台智能体的契约是 `一个 prompt → 一个 response → 一次等待`。当一次任务需要 8 分钟跑全量测试、再 4 分钟补三个失败用例，开发者盯着 spinner 干等 12 分钟就是纯浪费。后台智能体把这个契约拆碎：**检查点（checkpoint）取代响应（response）**，智能体在沙箱里自己跑，监督者只在关键节点被唤醒。 ```python # 监督循环核心：检查点而非阻塞等待 async def supervise(tasks: list[BackgroundAgent]): while pending(tasks): for t in tasks: msg = await t.poll_or_wakeup() # 唤醒语义，不阻塞 match msg.kind: case "checkpoint": notify(t.id, msg.progress) # 开了 PR / 跑完测试 case "uncertain": await human_input(t, msg.q) # 异步交接，不卡队列 case "done": queue_review(t) # 排队等人工 review case "blocked": escalate(t) # 静默死的反面 await asyncio.sleep(backoff) ``` 三家都落在同一套原语上：**沙箱执行（隔离 worktree/容器）、检查点汇报、唤醒续跑、review 门控**。差别只在持久化半径与并行度。架构上的同构不是巧合，而是"监督者模式"对控制流的强制要求——同步智能体本身就是"活儿"，没法被监督；后台智能体才是"被监督的工人"。 ### 2. Codex CLI Realtime V2：流式进度 + 排队响应 2026 年 4 月发布的 Realtime V2 引入了**在前台响应仍在生成时，流式播报后台智能体进度**的能力。开发者中途输入不会被丢弃，而是作为 steering update 回执确认，**后续响应排队，等当前完成再处理**。这是三家里异步原语最轻的——会话级单任务、不跨会话持久化。 ```bash # Realtime V2：中途 steering 不阻塞，排队等当前响应完成 codex "重构 payment 模块拆出幂等层" # ↳ [bg-task t_42] 流式: 解析 230 个文件... 跑测试... > 用户中途输入: "顺便保留旧 API 兼容" # ↳ ack: 已排队为 steering update #2 ``` 它的优势是**迁移成本最低**：单人开发或结对编程场景，无需重构工作流就能吃到异步红利。代价是会话一关，状态即失——长程任务一旦超时，重新 prefill 整个 monorepo 的 token 成本会再次支付。Codex 全程跑在 OpenAI 云沙箱 + GPT-5.4，对数据驻留敏感的企业是硬伤。 ### 3. Claude Code v2.0.64+：唤醒语义与 routines 调度 Claude Code 的异步走得最深。v2.0.60 让子智能体后台运行、父任务结束后仍存活；**v2.0.64 起后台智能体与 bash 命令异步执行，并向主智能体发"唤醒消息"**。`/tasks` 命令列出所有在跑的后台进程及其 ID、token 用量、进度。更关键的是 3 月的 **routines**：cron 风格定时 + GitHub webhook 触发，跑在 Anthropic 的 Web 基础设施而非本地。 ```yaml # .claude/routines/fix-sentry-error.yml —— 事件触发，跑在云上 trigger: webhook: sentry-on-alert on_event: run: "读 $EVENT.payload 栈帧，定位根因，写修复+回归测试，开 PR" notify: on_checkpoint: [pr_opened, needs_review] # 只在检查点通知 on_uncertain: true # 遇歧义升级，不硬猜 cost_ceil: usd: 5.0 # 每分支花费上限，防跑飞 ``` Claude Code 默认本地执行（Opus 4.7 在 SWE-bench Pro 拿 64.3%），对数据治理严的团队是决定性优势；routines 把"触发-执行-通知"闭环做成了基础设施层。**唤醒语义（wake-up messages）是它区别于另外两家的核心**：不是监督者去轮询，而是智能体在有产出时主动叫醒监督者。 ### 4. Cursor 3 Agents Window：worktree 并行与 best-of-N Cursor 3（2026-04-02）把并行 worktree 执行做成了一等公民 UX。**Agents Window 是独立全屏工作区**，最多 8 个智能体并行跑在本地 worktree、云 VM 或远程 SSH 主机上。杀手锏是 `best-of-N`：同一 prompt 同时派发给 Claude Opus 4.6、GPT-5.4、Gemini 3.1 Pro，三个 worktree 各产 diff，并排比对。还有**本地↔云交接**——本地会话可推到云端断点续跑，云端会话可拉回本地手动编辑。 ```bash # Cursor 3: best-of-N —— 同 prompt 三模型并行，并排挑 diff /best-of-n "重构 payment，拆出 idempotency 层" \ --models opus-4.6,gpt-5.4,gemini-3.1-pro # → worktree-pay-{opus,gpt,gemini} 三份 diff 并排 # ↳ 人工 cherry-pick；冲突 hunk 手动合并（塌方点之一） ``` 云持久化让会话能跨天存活，最接近"一周后仍带着上下文醒来"的愿景。但 best-of-N 的代价在三处暴露：并行分支合并冲突、可观测盲区、成本爆炸（见下文）。 ### 5. 通知阈值困境：静默死 vs 骚扰潮 这是整套范式里**最难的设计决策，也是真正的"税"**。后台智能体必须自行决定何时打断监督者：阈值设太高 → 智能体遇障不喊人，**静默死**，几小时后产出一份基于腐烂上下文的烂 PR；阈值设太低 → 每个不确定都 ping，**骚扰潮**，监督者淹没在通知里，退化成比同步更累的"通知消防员"。 健康曲线不是线性的，而是存在一个窄最优带。两侧都塌：左侧是"看不见的失败"（智能体假装在做），右侧是"看得见的过载"（监督者屏蔽所有通知）。Claude Code 的 `on_uncertain` 升级、`cost_ceil` 上限，本质都是在给智能体装**自我熔断**——知道什么时候该停、什么时候该喊。没有熔断的后台智能体，等于把"自主体跑飞：重试级联 200 倍税"的场景从单任务放大到了 7×24。**通知策略本身就是产品**，谁能把阈值调到窄最优带，谁就赢。 ### 6. 三大塌方点：合并冲突、可观测黑洞、成本失配 后台智能体迟迟无法吞下整条工作流，卡在这三处： **并行分支合并冲突。** Cursor 3 的 best-of-N 在模型产出兼容 diff 时很美，不兼容时监督者得手动 cherry-pick。部分团队反馈：**解并行智能体合并冲突的时间，比并行省下的还多**。并行是省时工具，冲突是反噬工具，净值取决于模型间 diff 的兼容度。 **可观测黑洞。** 同步智能体失败，开发者立刻看到报错；**后台智能体失败，一小时后才收到 Slack 通知，此时上下文已腐烂**，重跑等于从零再来。Claude Code 的 `/tasks` 只是最薄一层。生产部署需要 OpenTelemetry GenAI 语义约定 + New Relic 这类 agentic 可观测平台——这也是它们突然爆热的原因。 **成本失配。** 云后台智能体按 VM-分钟 + 模型 token 双重计费。**best-of-N 跑 8 个智能体 40 分钟，可能比监督者本人时薪还贵**。财务团队开始要求**按分支成本上限（per-branch cost ceiling）**，而 Cursor 的定价页至今没跟上。落地时务必把成本熔断写进编排层，而不是事后算账。 ### 7. 安全与治理：最小权限、强制 review、审计闭环 异步自治放大的安全面，必须用架构性约束兜底，不能靠提示词。四条铁律：**最小权限**——对生产分支只读、仅对 feature 分支写、用每个任务后过期的一次性 token，审计每条智能体 commit；**密钥托管**——云执行的智能体永远不碰生产 secret，用 vault 运行时注入，绝不落配置文件；**强制 review**——任何智能体产物未经至少一人人工批准不得进生产，配合分支保护；**审计闭环**——记录每一次触发、改动、测试、决策，用于调试与合规。 ```yaml # 编排层治理：权限 + review + 审计一体化 when: sentry.alert.severity >= "error" then: agent: claude-code branch: auto-fix/${event.id} permissions: repo: { read: main, write: "auto-fix/*" } # 最小权限 secrets: vault-inject # 不落盘 review_gate: required # 强制人工 audit: [trigger, commits, tests, decisions] # 全留痕 ``` 这套治理是后台智能体从"玩具"到"生产"的分水岭。没有它的 best-of-N，是把一组有写权限的自治体同时放进 8 个 worktree——爆炸半径比单智能体大 8 倍。 ### 8. 变现与训练营评估：监督者能力如何定价 后台智能体的落地账本很硬：**Bug 三联/修复 40–60% MTTR 下降、测试生成 15–25% 覆盖率提升、Review 预处理拦截 30–40% 问题、文档同步准确率 60%→90%**。但 METR 在 2026 年 2 月专门**重做了度量方法**：旧法测单人单任务完成时间，而舰队工作流违反了这两个前提；新法测**舰队产出 ÷ 监督者时间**——这是唯一还能反映真实行为的数。 变现机会不在"教人用 Cursor"，而在**"教监督者编排舰队 + 设熔断阈值 + 建治理闭环"**——这才是稀缺技能。训练营应分四阶段：低风险自动化（依赖更新/lint，1–2 周）→ 事件驱动（接 Sentry/CI/工单，3–6 周）→ 多智能体编排（7–12 周）→ 持续优化（监控 override 率、时延、缺陷率）。**最值钱的认知是那条反直觉结论：异步可成的弱模型栈，一旦团队适应舰队监督，会打败同步的最强模型栈**——"架构胜过能力，前提是能力已过阈值"。 ## Mermaid：异步监督循环架构 ```mermaid flowchart TB subgraph 事件源 E1[Sentry 报警] E2[CI 失败] E3[Linear 工单] E4[Cron 定时] E5[GitHub Webhook] end ORC[编排层 routines/Tembo] subgraph 后台智能体舰队 A1[Agent A · worktree] A2[Agent B · worktree] A3[Agent C · 云 VM] end H[监督者 · 人类] E1 & E2 & E3 & E4 & E5 --> ORC ORC -->|派发+沙箱+vault 注入+cost_ceil| A1 & A2 & A3 A1 -.->|检查点通知| H A2 -.->|不确定 → 异步提问| H A3 -.->|完成 → 排队 review| H A3 -.->|blocked → 升级 熔断| H H -->|steering 更新/批准| A1 & A2 A1 & A2 & A3 -->|开 PR| R[Review 门控] R -->|≥1 人工批准| M[合并] R -.->|审计留痕| LOG[(Audit Log)] ``` ## 推荐方案 - **单人 / 结对编程** → Codex CLI Realtime V2。最低迁移摩擦，流式进度吃到异步红利而不重构工作流。 - **PR 中心流 + 数据治理严** → Claude Code v2.0.64+ + routines。本地优先、唤醒语义最强、cron/webhook 闭环成熟，最适合"智能体开 PR、reviewer 异步接单"。 - **多模型 best-of-N / 平台团队** → Cursor 3 Agents Window。唯一把并行 worktree 与多模型对比做成一等 UX 的，但务必预置合并冲突解决流程与 per-branch 成本上限。 - **多智能体协调、怕锁定** → Tembo 编排层在上，按事件挑最合适的智能体，配强制 review 与审计。 **一句话决策**：别再比 SWE-bench。先问"我的监督者-智能体比例"，再选异步原语匹配它的栈。能力过了阈值之后，**架构决定上限，监督循环决定下限**——而通知阈值与成本熔断，是上下限之间那道最窄的缝。 ## 参考来源 1. [The Background Agent Convergence: Codex, Claude Code, and Cursor Go Async — AgentMarketCap](https://agentmarketcap.ai/blog/2026/06/01/background-agent-execution-pattern-async-convergence) — 三家 90 天内收敛到同一异步架构，含 Codex V2/Claude Code v2.0.64+/Cursor 3 对照与三大塌方点 2. [Background AI Agents in 2026: Code Ships While You Sleep — SigmaJunction](https://sigmajunction.com/blog/background-ai-agents-async-coding-productivity-2026) — 事件驱动/沙箱/检查点架构、五大落地用例及收益数据、四阶段采纳路线 3. [6 Background AI Agents for Async Development — Security Boulevard](https://securityboulevard.com/2026/06/6-background-ai-agents-for-async-development/) — 六大后台智能体横评、定价、SWE-bench 与安全治理 4. [Claude Code Async Workflows Guide](https://claudefa.st/blog/guide/agents/async-workflows) — Claude Code 后台子智能体与并行任务实操 5. [Cursor vs Claude Code vs Codex vs Windsurf 2026 — aitoolsrecap](https://aitoolsrecap.com/Blog/cursor-vs-claude-code-vs-codex-vs-windsurf-2026) — Cursor 后台智能体与 Claude Code 12 小时以上自治会话能力对比 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。