阿里 Qoder 工程师亲述：当 Token 不再稀缺，瓶颈怎么跑到了「人」身上？

Sun, 14 Jun 2026 09:00:00 +0800

最近 BestBlogs 上有一篇文章冲到了 91 分的高位，作者是阿里技术的工程师，主题是「Qoder 工程实践：当瓶颈从模型转移到人」。这篇文章和我之前在选题阶段分享的内容高度一致，但它把整段演进路径讲透了。

如果只看结论，工程界会把它当成又一个「AI 编程进阶指南」。但如果顺着作者的演进路径读，会发现一个反直觉的事实：当 AI 越来越便宜、越来越能干时，最先撑不住的反而是资深工程师自己。

这篇文章想做的，不是重复作者的演进路径，而是把那个反直觉的事实拆开，并补充三个关键判断：

为什么「Token 加速，人反而崩溃」是 2026 年 AI 编程的隐藏天花板？
「手脑分离」Cloud Agents 平台的设计哲学为什么比 Claude Code Dynamic Workflows 更接地气？
三个工程约束（Session 可恢复 + Sandbox 可替换 + Harness 无状态）为什么是「睡后 Token 持续流动」的硬性前提？

下面进入正文。

一、阿里 Qoder 的演进路径：从 Cursor 到 Cloud Agents

阿里 Qoder 团队的演进路径，恰好覆盖了过去 18 个月 AI 编程工具的主流形态。

1. 阶段一：Cursor 辅助打字（人在回路）

这是 2024 年的标准形态。开发者在编辑器里写代码，AI 辅助补全、生成小段函数、改写注释。人在每一个 token 上做决策，AI 只是更聪明的自动补全（autocomplete）。

这个阶段的瓶颈模型很清楚：模型越强，写得越快。瓶颈在模型的代码能力上。

2. 阶段二：CLI Agent 自主执行（人去监督）

到了 2025 年，Claude Code、Codex、Aider 这类 CLI Agent（命令行智能体）开始普及。开发者不再一行行写代码，而是给 Agent 一个目标，让它自主完成多步骤任务。Agent 自己读仓库、写代码、跑命令、提 PR。

这个阶段的人机分工变了：人是 supervisor（监督者），Agent 是执行者。Agent 越强，单任务的产出越高。

3. 阶段三：多终端并发（Token 在加速，人开始崩溃）

到了 2025 年底到 2026 年初，资深工程师开始尝试「多终端并发」：同时开 5 个、10 个 Agent 终端，让不同的 Agent 跑不同的子任务。

这本来应该是产能爆炸的时刻。但阿里的工程师在文章里直接说了一句关键的话：

“Token 在加速，人反而开始崩溃。”

为什么崩溃？因为多终端并发的真实体验是：1 个人盯 5 个 Agent 的体验，远差于 1 个人盯 1 个 Agent。Agent 的产出虽然在指数级上升，但人作为 supervisor 的注意力带宽（attention bandwidth）是恒定的，你不比别人多一对眼睛，也不比别人多 8 小时工作时间。

瓶颈模型在这个阶段发生了根本性的转移：从模型能力，转移到了人的注意力。

4. 阶段四：「手脑分离」Cloud Agents 平台

阿里 Qoder 团队给出的解法是「手脑分离」。

所谓「手」，是执行：写代码、跑命令、读文件、提 PR。所谓「脑」，是判断：设计架构、决定边界、验证结果、定义意图。

过去的 AI 编程模式里，人既要当「脑」又要当「手」：一边设计任务，一边盯 Agent 执行，一边验证结果。Agent 一多，「脑」就开始分心，「手」就开始混乱。

「手脑分离」的模式是：人专注「脑」，只做架构设计、意图表达、关键验证；「手」交给 Cloud Agents 平台全权处理。Cloud Agents 平台在背后 24 小时跑，把「手」的工作做完，人只在关键节点介入。

这种模式的关键不是「让 Agent 更强」，而是「让人的注意力回到真正稀缺的事上」。

二、Token 不再稀缺，但注意力稀缺

「Token 不再稀缺」这句话放在 2024 年听起来像笑话，但放到 2026 年是事实。

按公开数据，主流模型 API 价格在过去 18 个月下降了 60-80%。GPT-5.5、Gemini 3.1 Pro、Claude Opus 4.8 的每百万 token 输出价格都已经压到 10-20 美元区间。一个标准 AI 编程任务消耗的 token 成本，从 2024 年的几美元，下降到了 2026 年的几美分。

但「人的注意力稀缺」这件事没有变化。一个资深工程师的有效深度工作时间（deep work），一天也就 4-6 小时。AI 可以 24 小时跑，人不行。

阿里 Qoder 文章里那句「Token 在加速，人反而开始崩溃」，本质是在说：当一种生产要素的成本下降 80%，而另一种生产要素的成本不变，整个系统的瓶颈就会自动转移到后者身上。

这件事在很多行业都发生过。比如：

算力价格下降后，数据中心的瓶颈转移到了电力和散热
存储价格下降后，云服务的瓶颈转移到了网络带宽
Token 价格下降后，AI 编程的瓶颈转移到了人的注意力

每一轮成本下降，都会暴露下一层瓶颈。

三、「手脑分离」的设计哲学

「手脑分离」不是一个工程术语，它是一种对「人在 AI 时代应该做什么」的重新定义。

1. 过去：人既是 architect 又是 operator

在传统软件工程里，一个人既是 architect（架构师）又是 operator（操作员）。架构设计、模块拆分、接口定义由同一个人完成，这个人还要负责具体的写代码、跑测试、修 bug。

这个模式在 AI 时代变得不合理了，因为 AI 在「operator」这件事上的能力是指数级上升的。让一个资深工程师同时当 architect 和 operator，等于让梅西去守门。

2. 现在：人只做 architect，Agent 负责 operator

「手脑分离」模式下，资深工程师的角色被重新定义为：intent designer + final reviewer（意图设计者 + 最终评审者）。

intent designer 负责定义任务的目标、约束、边界，告诉 Agent “我要一个支持 OAuth 2.0 的登录模块，输入输出契约是 X，错误处理按 Y 标准”。 final reviewer 负责在 Agent 完成之后做关键路径的最终验证：读代码、跑测试、确认行为是否符合预期。

中间的「执行」全交给 Agent。

3. Cloud Agents 平台的核心特征

阿里 Qoder 团队的 Cloud Agents 平台有几个值得注意的特征：

Agent 是常驻的，不是临时的：用户下班后，Agent 继续跑，第二天上班看结果
任务是可以累积的：Agent 在跑的过程中，把中间成果保存到云端，换个 Agent 接续也能继续
人是异步参与的：人不需要实时盯 Agent，只在关键节点（设计、验证）介入

这些特征和 Claude Code Dynamic Workflows 的「同步编排」模式形成对照。Dynamic Workflows 是「人下令、Agent 同步执行、人等结果」，Cloud Agents 是「人下令、Agent 异步执行、人在任意时间介入」。

两者适用场景不同：Dynamic Workflows 适合需要强反馈回路的复杂任务，Cloud Agents 适合可以后台跑、不需要实时干预的任务。

四、三个工程约束：睡后 Token 持续流动的硬性前提

阿里 Qoder 团队在文章里给出了一个非常具体的结论：让「睡后 Token 持续流动」需要 Session 可恢复、Sandbox 可替换、Harness 无状态三者同时成立。

这三个约束缺一不可，是 Cloud Agents 平台的底层架构要求。下面拆开讲。

1. Session 可恢复

含义：Agent 在执行过程中，可能因为各种原因（网络断、Token 用完、上下文超限、机器重启）中断。中断之后，重新启动一个新的 Agent 接续，必须能从中断点继续，而不是从零开始。

为什么重要：Agent 跑的任务通常跨几个小时甚至几天。如果不能恢复，每次中断就意味着之前的工作全部作废，Token 浪费且任务无法完成。

实现要点：把 Agent 的中间状态（思考链、工具调用记录、文件变更历史）持久化到云端，让任何后续 Agent 都能读取。

2. Sandbox 可替换

含义：Agent 的执行环境（沙箱，sandbox）可替换，可以是本地 Docker 容器、远程虚拟机、临时云函数，不同 Agent 任务可以跑在不同的沙箱里。

为什么重要：单个沙箱的资源有限，而且有崩溃风险。任务能切换沙箱，意味着 Agent 不会因为「我这台机器满了」或「这台机器挂了」而失败。

实现要点：把 Agent 的所有依赖（代码、配置、运行时环境）都容器化或脚本化，让新沙箱能在几分钟内复现完整环境。

3. Harness 无状态

含义：Harness（包裹 Agent 的运行时框架）本身不持有状态，所有状态都在外部存储（云端数据库、对象存储）。Harness 进程可以随时重启、迁移、扩容，不影响 Agent 任务的连续性。

为什么重要：如果 Harness 持有状态，那每次 Harness 重启都会打断 Agent 任务。把状态外置后，Harness 变成「无状态服务」，可以随时扩容、迁移、替换。

实现要点：Harness 只做调度、分发、监控的逻辑层，所有持久化数据走外部存储。

三个约束的关系

这三个约束不是独立的，它们形成一个闭环：

Session 可恢复保证任务不丢失
Sandbox 可替换保证执行不中断
Harness 无状态保证调度不卡顿

三者同时成立，「睡后 Token 持续流动」才有可能：Token 才能在你睡觉的时候继续被消耗、被产出价值。

如果只满足其中 1-2 个，Cloud Agents 平台就会在某个边缘场景崩塌。这也是为什么国内大厂做 Cloud Agents 的进展普遍慢于国际厂商。这三个工程约束背后，是对云原生架构、状态管理、容器编排的深度积累。

五、Skill 沉淀的复利效应

阿里 Qoder 文章里还有一个容易被忽略的论点：个人沉淀的 Skill 从本地脚本变成团队可订阅的云端服务，才是真正的效率复利。

1. 个人时代的 Skill

2024-2025 年，每个 AI 编程重度用户都有自己的「Skill 库」：自己写的 prompt 模板、自己调的 IDE 配置、自己总结的 Claude Code 技巧。这些 Skill 沉淀在本地，只能自己用。

2. 团队时代的 Skill

到了 Cloud Agents 时代，Skill 必须从本地迁移到云端，成为团队可订阅的服务。

举例：你在 Qoder 平台上调好了一个「自动重构遗留代码」的 Agent 配置，沉淀为一个 Skill。这个 Skill 应该可以被团队成员一键订阅，他们不需要自己调，直接用你调好的版本。

更进一步，这个 Skill 应该可以被组织级订阅，整个部门、整个公司都能用。当某个工程师调出一个特别好的 Skill，所有相关项目都能立刻受益。

3. 复利的来源

Skill 沉淀的复利，来自于乘数效应：

个人 Skill 的价值 = 1 个人的效率提升
团队 Skill 的价值 = N 个人的效率提升 + Skill 之间的组合复用
组织 Skill 的价值 = 整个公司的 AI 编程基线被抬高

阿里 Qoder 团队的判断是：当 Skill 沉淀到云端变成可订阅服务，AI 编程的效率复利才真正开始。之前的「Skill」只是个人玩具，之后的「Skill」是组织资产。

这件事和软件工程史上「代码复用」的演进路径很像，从个人函数库，到团队共享库，到开源组件库。Skill 沉淀正在走同样的路。

六、对比 Claude Code Dynamic Workflows：两条路

阿里 Qoder 的「手脑分离」Cloud Agents 平台，和 Anthropic 6 月 2 日发布的 Claude Code Dynamic Workflows，是两种不同的 AI 编程组织模式。

1. Dynamic Workflows：临时组织

Anthropic 的 Dynamic Workflows 是「按任务临时组建组织」。每次跑一个 workflow，Claude 现场生成一段 JavaScript 脚本，编排多个 subagent 并行处理任务。

适合场景：单次、复杂、需要强反馈回路的任务。比如代码审计、大型迁移、跨系统的研究。

2. Cloud Agents：常驻异步

阿里 Qoder 的 Cloud Agents 是「常驻异步执行」。Agent 是平台上的常驻服务，用户提交任务后，Agent 在后台异步执行，人在任意时间介入。

适合场景：长周期、不需要实时反馈的任务。比如批量代码生成、自动化重构、夜间构建。

3. 两者不冲突，是互补

这两种模式不冲突，更可能是互补关系。Dynamic Workflows 解决「这一次任务的最优执行」，Cloud Agents 解决「这一类任务的持续执行」。

未来成熟的 AI 编程平台，大概率会同时提供这两种能力：Dynamic Workflows 跑一次性任务，Cloud Agents 跑持续性任务。阿里 Qoder 在国内走通了 Cloud Agents 这条路，Anthropic 在国际走通了 Dynamic Workflows 那条路。

对中国开发者来说，Qoder 的路径可能更接地气：阿里大厂内部对云原生、容器编排、状态管理的积累是国内最深的，他们踩过的坑、总结的工程约束，是中国其他公司可以直接复用的经验。

结尾：当瓶颈转移到人，工程师的角色怎么变

回到文章开头的问题：当 Token 不再稀缺，瓶颈怎么跑到了「人」身上？

阿里 Qoder 团队的回答是：不是瓶颈跑到了人身上，而是「人」的定义变了。

过去的「人」是 architect + operator 的复合体，既要想又要做。AI 时代，operator 被 Agent 接管，「人」只剩 architect。这不是降级，是聚焦，人终于可以只做最稀缺的事：判断、定义、验证。

这件事对工程师的实际影响是：未来 12-24 个月，最值钱的工程师不是 prompt 写得最花哨的，而是「架构判断力」最强、「意图定义能力」最清晰的。

技术细节可以交给 Agent，但「这个任务到底要不要做」「这件事到底值不值得做」「这个方案到底对不对」，这些判断仍然只能由人来做。

阿里 Qoder 文章的真正价值，不是给出了「手脑分离」这个具体方案，而是把 AI 编程的瓶颈转移讲清楚了：当一种生产要素的成本归零，下一种瓶颈就会自动暴露。2024 年瓶颈是模型，2025 年瓶颈是工具，2026 年瓶颈是人的注意力。

下一个问题更尖锐：当注意力瓶颈被 Cloud Agents 解决之后，下一个瓶颈是什么？

我没有答案。但阿里 Qoder 这篇文章，至少让我们看清了从 2024 到 2026 这三年的瓶颈迁移路径。

参考来源

阿里 Qoder Cloud Agents 上线：全托管 Agent 平台，上线周期从 30 天缩至 1 天 - 玉米小站（2026-05-28 阿里智能引擎团队发布 Cloud Agents 的详细报道）
阿里 Qoder 推出全托管平台 Cloud Agents，实现 AI Agent 一天内快速上线 - AIBase（同期媒体报道）
Qoder Cloud Agents 概览 - Qoder 官方文档（Agent / Environment / Session / Event 概念定义）
Cloud Agent SDK 文档 - Qoder 官方（Session 复用 + SSE 事件流的实现细节）

以上来源用于了解阿里 Qoder 团队 2026 年 5 月发布的 Cloud Agents 产品形态（Agent + Environment + Session + Skills + MCP 协议 + SSE 事件流）。本文中关于「手脑分离」「Session 可恢复 + Sandbox 可替换 + Harness 无状态三约束」「Skill 沉淀从本地脚本到团队可订阅云端服务」等论点，是作者基于公开产品文档做的工程层推演，不等同于阿里 Qoder 内部官方表述。

具体细节（Cursor → CLI Agent → 多终端 → Cloud Agents 的演进时间线、三个工程约束的命名）可能与阿里 Qoder 团队内部最新实践存在出入，请以阿里官方发布为准。

阿里Qoder on 奇诺分享 | 重在分享