本文作者：泮圣伟

引言

当 AI 输出的价值稳定超过 Token 成本之后，瓶颈从模型能力转移到了人的精力。

这个认知改变了我过去半年的工作方式，这种改变的发生不是渐变式的，是某天突然看清楚了。Peter（OpenClaw作者） 一天内提交了 627 次代码——计算一下，一天有 1440 分钟，这意味着每次代码提交间隔平均不到 2.3 分钟。我看到这个数字的第一反应不是佩服，是替他感到累，这一天结束后，他还剩多少判断力？AI 在高速工作，人被绑在旁边陪跑，第二天 Token 得等他缓过来。

我自己在 5 月份完成了 496 次提交，冷静下来想想，这只能说明吞吐变了，无法说明效能是否提升。提交数是过程痕迹，不是价值指标，能留下来的指标应该是：多少问题被识别，多少候选改动被挡在合入前，多少经过验证后稳妥进了主干。

每一次工作方式的进化，都在回答同一件事：**怎样用更少的人力在线时间，让更多的 Token 持续流动？**我认为这个问题的答案不是一个更好的 IDE 插件，也不是一个更聪明的模型，是一整套云端持续进化的 Harness 基础设施。但在讲那个思考结论之前，我想先走一遍到达它的路。

关于 AI Coding 这件事，每过两个月我都有新的认知，每次都以为到顶了，却每次都被更深的瓶颈卡住。

01 从「更快打字」到「任务自主交付」

最开始和大多数人一样，我用 Cursor 一个 AI Coding 的 IDE。它的体验确实好，写几个字母就能直接补出一整行；写个函数签名，实现自己填上来。效率大概提升了三到五成。但有一件事始终没变：方向盘在我手里，我不打字，它不动。

从 Token 的角度看，每次请求几百到几千 Token，产出是"节省了一些打字时间"。但是人停，Token 停。

茹炳晟有个判断我觉得很准：软件工程过去五十年一直在「管理人的不确定性」，从瀑布到敏捷到 DevOps，本质上都是用方法论管理人，而不是替代人。按这个框架看，Copilot 和 Cursor 没有跳出这个范式。它们让人打字更快，但人依然是主回路中的执行主体。给手工匠人换了把更好的锤子，仅此而已。

Vibe Coding 也一样，用自然语言描述需求让 AI 生成代码，兴奋感是真的，但做的是功能和界面，驱动应用运行的 engine 难以实现，80% 项目时间依然消耗在非业务核心的基建搭建上。

02 第一次感受到范式变化

真正的体感变化发生在 Opus 4.5 之后。

当我第一次在终端里启动 CLI Agent，几分钟内就意识到，这和之前所有工具都不是一回事。如果说 Cursor 是辅助驾驶，我踩油门它帮修正方向，那么 CLI Agent 就是自主执行体，我说去哪，它自己找路、绕障碍、停车入库。第一次用它完成一个完整任务：我花 30 秒写了一段需求，它花 60 秒读懂项目结构，然后用 5 分钟完成了我预估需要半天的改动。代码对了，测试过了，风格和项目一致。

我开始记录数据：分析一个 2400 行的 TypeScript agent-loop 模块，产出完整架构分析报告：276,010 tokens，10 分钟，995 行输出。一个 bug 修复从描述问题到代码提交：60 秒。设计文档深度 review，发现 5 个 Critical 和 8 个 Medium，也就 5 到 6 分钟的时间。

这些数字拼在一起，第一次有了「超级个体」的感觉。一个人在一天内完成需求拆解、代码修改、设计文档、review、测试、提交 CR，全流程跑完。

这里发生的事情是什么？大模型第一次让「用算力换取高阶智能」成为可能。不是换低阶的，「温度高了关阀门」那种负反馈回路，而是「理解代码库结构、推理架构问题、生成符合规范的实现」这种过去只有人脑才能做的事。软件工程五十年卡在「高阶认知无法被固化」这个死结上，大模型把它劈开了一道缝。

但天花板很快出现。一个终端同时只能做一件事。分析大项目需要 10 到 15 分钟，这段时间手是闲的，注意力却被钉在这个进程上。

03 并发的陷阱：Token 在加速，人在崩溃

解法看起来直接：同时开多个终端执行Agent，跑多个任务。

我用 tmux 管理多个 workspace。一个在分析 170 个配置项，另一个在做消息队列分析（最终产出 530 行报告），第三个在做遥测审计。四个 Agent 并行跑，15 分钟出结果，串行要一小时。产出确实高了，但一天下来的疲劳感比单线程还严重。其实原因不复杂，注意力在多个上下文之间不停切换，每次切换都有认知成本，更要命的是每个 prompt 都得我自己写。三条并行线意味着三份 prompt 要构思，三组结果要判读，三次后续决策要做，Token 在高效工作，人反而成了瓶颈。

并发没有消灭我的工作。它只是把等待时间换成了调度时间。

Thoughtworks 的 Birgitta Böckeler 在 QCon 纽约讲了一个我很认同的观点：Context Engineering 是一个放大器杠杆，放大是双向的，好的工程实践会被放大，坏的结构问题也会被放大。回头看我的并发阶段，我其实在做最原始的 Context Engineering，手动给每个终端写 prompt、手动管理上下文、手动判断什么信息该喂进去。这个过程吃掉了我大部分精力，而 Agent 收到的 context 质量也不稳定。好的 prompt 能产出惊人的结果，坏的 prompt 产出的东西需要更多精力去 review。

这时，一个转折出现了：我一直在想「怎么让自己更快」，但人的注意力带宽是硬上限，快不到哪去。该问的问题，是「怎么让 Token 消耗得更多，同时减少对人的注意力消耗」。

04 委派：把人压缩到决策位

随着 QoderWork 自身逐渐成熟，用户反馈也持续验证了这条路的可行性。我们开始用自己的工具做更深入的实践。Dogfooding 到极致之后，我的角色发生了一次根本性的转变：不再是执行者，不再是调度器，而是纯粹的决策者。只做三件事：提需求、审方案、验结果。

架构长这样：我说一句话，QoderWork 把它精炼成结构化 prompt，Task Agent 在独立上下文里长时间运行，QoderCLI 在独立的 worktree 里把指令翻译成代码。每一层只管自己的事，信息逐层精炼，控制权逐层下放。

下面是几个真实例子。

1. “把 Vaults API 实现了”，QoderWork 收到后精炼成结构化 prompt：9 个规格锚点（文件路径、接口命名、错误码体系、事务边界、并发策略），加密方案要求，参考代码路径，验收标准，约两三百字。下层 Agent 收到更具体的指令：各层需要创建哪些文件、接口签名、数据模型、错误处理策略。一句自然语言，经过两次精炼，变成可执行的代码级指令。

2. “分析一下 qodercli 的 agent loop 能不能抽成无状态 SDK”，QoderWork 自己写 prompt、启动 workspace、发命令、轮询状态、提取报告、汇报结论。276K tokens，10 分钟，近千行分析。我花了 30 秒读结论，做了一个"可行，继续推进"的决策，下一步交付我的就是运行测试通过的可以直接合并的代码 CR。

05 稳定运行靠什么

三层委派不是靠某个 prompt 写得好就能跑起来的，关键是给每一层 Agent 写操作手册——AGENTS.md 里定义职责边界、禁止行为、交付规则，MEMORY.md 记录项目上下文和历史决策，USER.md 记录我的偏好。这些文件构成 Agent 的长期记忆，不需要每次对话重新交代背景。

这本质上是 Context Engineering 的落地。和一年前把一个 rules file 全量塞给 Agent 不同，现在的做法是分层管理：什么是全局不变的（项目规范、技术栈约束），什么是会话级的（当前任务目标、验收标准），什么是按需加载的（特定模块的代码结构、历史决策记录）。Agent 不需要在 session 开始时把所有信息塞进去，按需获取，逐层精炼。

还有一个被低估的优势：Agent 可以零成本从现有代码库获取上下文。以前加一个人到团队，几周才能搞清楚代码结构。Agent 读取上下文是无损的，"多加一个 Agent"不会带来人月神话里的沟通开销。

算是一个彩蛋，回看来时路可以发现：Qoder 从 IDE 到推出 Quest 模型，到专家团模式，再到最近 Qoder IDE 1.0 升级成 Desktop，产品路径侧面契合了我们在 AI Coding 探索过程中的实践与产品化沉淀。每一次产品形态的演进，背后都对应着我们自己踩过的某个阶段的瓶颈和解法。

06 睡后 Token：瓶颈的真正转移

三层委派解决了「我在线时如何高效花 Token」。但一个更根本的问题思考浮上来：Token 为什么要等我在线？Token 产出的价值如果持续高于成本，凌晨三点跑和下午三点跑，价值一样。区别只是凌晨三点我在睡觉，凌晨的 Token 应该还会更便宜一些。

睡后 Token 的核心设计是：把输入、边界、验证、回收全部提前想好，让 Token 在我离线时继续产出候选结果，第二天早上交给人做价值判断。计价单位是「有多少结果进入了判断流程」，不是「烧了多少 Token」。

07 634 进，12 出

第一个落地场景是 QoderWork 的 issue 自动处理。上周的数据漏斗：输入 634 个 issue，系统筛出 190 个有效缺陷，自动生成修复代码并提交 CR：25 个，经人工 review 后合入：12 个。634 进，12 出。漏斗的价值不在于生成了 25 个 CR，在于 622 个没进主干。Agent 生成的每个 CR 先按负债处理，只有通过测试、review 和业务判断，才有资格进资产池。无人值守工作流的安全阀靠的是验收口设计足够严，Agent 够不够聪明反而次要。

Böckeler 讲风险评估有三个维度：概率、影响、可检测性。最后那个最关键，你能不能发现它出了错？这是让 Agent 自主运行的前提。我的答案是可以，但前提是「可检测性」要设计进工作流里，不是事后补。

第二个场景：夜间批量任务。设计文档 review、跨仓库 API 一致性检查、大规模重构影响面分析。需要大量 Token 但不需要实时决策的工作，全部排在晚上 11 点后执行，第二天早上报告在等我。

杠杆率变了，以前是 1:N，N 受限于我在线多少小时。现在接近 1:24。

08 但 Harness 会咬人

需要注意的是，「睡后 Token」要可靠运行，远不是「写几个 cron job」那么简单。

我的自动化脚本变成了一只需要照料的宠物：终端不能死，容器不能挂，上下文不能丢，凭证不能泄露。任何一个进程挂掉，整个工作流断了。我花了大量时间照料它，debug 失败的 session、重建挂掉的进程、追踪丢失的上下文。

这就是越来越多人开始意识到的：Agent 开发 70% 的成本不在 AI 模型推理，在 Harness。Harness 是什么？是让非确定性的模型产出被确定性的工程系统约束住的那套东西：Token 编排引擎、安全沙箱、可观测性、状态持久化、错误恢复。少了哪一块，Agent 都没法在生产环境里可靠运行。

Böckeler 有个判断我觉得会成真：也许未来我们不再靠传统服务模板起步，而是靠 Harness 模板。选技术栈的决策维度可能不再是「React 还是 Vue」，而是「有没有现成的 Harness」。

我在 AGENTS.md 里写的每一条规则，都是一个关于「模型暂时还不会做什么」的假设。模型会进步，假设会过期。个人脚手架是临时 Harness，生命周期跟着模型能力变，没有稳定接口，无法传承。我们可以看到一个观点，Sota 模型正在加速进化，已有的 Harness 也在加速过期。每个认真用 Agent 的工程师都得自己搭一套，这事没法规模化。个人可以快，但组织未必有效。

09 Cloud Agents：从个人脚本到平台

平台要托管的到底是什么？想清楚上面这些之后，答案已经浮出水面：平台要托管的是长期任务的可恢复性，不是进程本身。让睡后 Token 可靠运行，需要三件事同时成立：

• Session 不怕断：会话是持久的事件流，和进程是否存活无关。状态落在事件流里，不藏在进程里。一个任务可以在任何时间暂停、任何时间恢复。

• Sandbox 不怕换：执行环境可替换，失败了重新 provision，不需要手动恢复。对有合规需求的企业，支持 Self Hosted 自托管，数据不出沙箱。

• Harness 不怕重启：无状态的大脑，随时可以用 wake(sessionId) 接管。不依赖某台机器、某个进程、某个开发者的本地环境。

这就是我们在做的 Qoder Cloud Agents。我前几个月手搓的调度、恢复、隔离、验收逻辑，变成平台替开发者解决的基础设施。而构建 Cloud Agents 本身，也是在深度使用我们自己打磨的 Harness，更少的人、更短的周期、更高效的 Token 消耗，产出却更大，这件事本身就是最好的实验验证。

10 手脑分离

Cloud Agents 的架构核心是「手脑分离」：Brain 负责推理决策，Hands 负责执行操作，两者独立升级。这个设计不只是架构上的整洁，它解决了几个实际问题。

• 第一个是升级的复利效应：Brain 升级一次，所有用户同步受益，零迁移成本。传统 SaaS 升级需要客户跟着改代码、改配置、做兼容。在 AI 领域尤其痛苦，因为模型迭代速度远快于应用适配速度。Cloud Agents 的 API 是稳定的，接入后随着平台能力提升，接入方的智能自动进化，零改代码。你今天接入的 Agent 能力是一个水平，三个月后同样的 API 调用，背后的 Brain 已经更强了，你什么都不用做。

• 第二个是故障隔离：Brain 出问题不影响 Hands 的执行环境，Sandbox 崩溃不会污染推理状态。两者通过事件流通信，任何一侧重启都不会导致整个任务丢失。这对长程任务尤其关键，一个跑了两小时的代码重构任务，不会因为执行环境的一次 OOM 而从头来过。

• 第三个是资源效率：Brain 是计算密集型的（大量 Token 推理），Hands 是 IO 密集型的（文件操作、网络请求、命令执行）。分离之后可以独立伸缩，高峰期多给 Brain 算力，不需要同比例扩容 Sandbox。借助 RocketMQ LiteTopic 能力，单集群 Brain 足以支撑万级别的并发推理。

所以它不是 API wrapper，API wrapper 只是把模型能力透传出去。Harness 的价值在于用确定性的工程系统约束非确定性的模型产出，让 Agent 从「demo 能跑」变成「生产环境可靠」。

11 极简接入：你的代码里没有 AI

说了这么多架构，我们需要思考一个很自然的问题：接进去到底要写多少代码？答案可能出乎意料。

Cloud Agents 的接入路径只有五步：获取令牌、创建运行环境、定义 Agent、建立 Session、通过事件流收发消息。你写的全部代码都是编排逻辑：session 怎么建、消息往哪发、事件流怎么消费。Agent 的「智能」写在 API 里，不在你的代码里。你在 API 里定义 Agent 的职责、工作流程、输出格式，平台负责把这些指令变成可靠的执行。你的后端服务就是一个管道，不做意图识别、不做对话管理、不做任何"聪明"的事。

我们内部做过一个验证：一天之内跑通了一个 6 Agent 协同系统。前台分诊 Agent 做意图路由，5 个专科 Agent 各管各的领域，跨 session 通过 Memory Store 共享上下文。从第一行代码到浏览器里看到完整交互，开发者没碰过 Agent Loop、没管过沙箱容器的生命周期、没处理过长连接保活。写的全是业务：谁的 session 该创建、挂什么数据、前端状态机怎么流转。

从 demo 到生产的增量也不在 Agent 层，加用户认证、加数据持久化、加部署上线，都是标准的业务开发。Agent 的运行不需要你操心，那是平台的事。

这才是「70% 成本在 Harness」这个判断的另一面：当平台把 Harness 吸收掉之后，开发者写 AI 应用的体验，跟写普通 Web 应用没有本质区别。区别只在于你多了一个超级能干的后端——它会推理、会使用工具、会自主决策，而你要做的只是告诉它"做什么"和"做到什么程度算好"。

12 Skill as a Service

这是让我最兴奋的场景。

回顾前面的进化路径，我在三层委派阶段积累了大量 Skills，比如 「如何做设计文档 review 并产出结构化报告」、「如何分析一个模块能否抽成 SDK」、「如何从 issue 到修复代码再到 CR 提交的全流程」。反复打磨、验证过的最佳实践。

问题是这些 Skill 活在我的本地环境里，只有我能用。团队里其他人想用同样的能力，得自己从头摸索。每个厨师都得自己研发菜谱，明明隔壁桌已经做出了满分红烧肉。

Cloud Agents 让本地 Skill 变成云端 Service。我打磨好一个 Skill（比如“代码安全审计”），通过 Cloud Agents 发布成 API 可调用的服务。团队里任何人，甚至是不懂技术的产品经理、设计也都可以通过应用集成调用这个能力。

这里的想象空间很大：资深 SRE 积累的「线上故障诊断 Skill」服务化给整个 on-call 团队；安全专家打磨的「漏洞扫描 Skill」嵌入所有项目的 CI 流水线；架构师沉淀的"API 设计 review Skill"在每个 PR 提交时自动执行。个人经验不再锁在某个人的电脑里，变成组织级的可复用能力。这是 B2B2C 逻辑的具体体现：C 端用户直接收获深度打磨过的 Agent 能力红利，不需要自己成为 Agent 专家。

Qoder 和 QoderWork 里内置了 Cloud Agents Skills，用户可以直接让 Qoder 帮忙快速创建 Agent、编排多 Agent 协同、完成一整个端到端的任务流：不需要离开编辑器，不需要手动调 API。我们把「如何用好 Cloud Agents」这件事本身也封装成了 Skill，然后让工具替你执行。

13 自评估循环

还有一个被低估的能力。Agent 自动验证输出质量，不满意则自动重试迭代。我在「634 进 12 出」那个案例里手动设计的验收漏斗，在 Cloud Agents 里变成了内置能力。Agent 完成任务后自评估：结果是否符合预期？有没有遗漏的边界情况？测试是否通过？不满意就自主重试，直到达标或者明确报告"这个问题超出我的能力"。

把风险检测内置到 Agent 运行循环里，而不是依赖人事后检查。

14 已经在跑了

Cloud Agents 不是 PPT 上的规划，https://qoder.com/cloud/agents 已经上线，我们自己和外部团队都在上面跑真实业务。前面提到的那个「多 Agent 分诊系统一天跑通」不是假想实验，是真实跑出来的。目前已经有不少团队在用它做客服自动化、代码审计、文档生成、数据分析等场景，我们也在持续征集落地案例，如果你有跑通的场景，欢迎来聊。

更让我兴奋的是接下来的演进方向，几个我认为较为核心的能力：多 Agent 并行协作支持中，意味着前面讲的「并发瓶颈」可以被平台级解决；Dream & Memory 让 Agent 跨 session 保留记忆已经支持，长期任务不再每次从头交代背景；Self-Hosted 自托管沙箱让强合规行业（金融、政务）包括集团环境也能用起来，数据不出企业网络；再往后是 Browser Use/Computer Use，可以让 Agent 直接操作浏览器和桌面界面，能处理的场景边界再扩一圈。

平台在以天为单位迭代。这才是做基础设施和做个人脚本的根本区别：你的 Harness 在持续进化，而你什么都不用改。

15 更往前一步的思考

回到最开始。Peter 一天 627 次提交，那天他把自己钉在了屏幕前。我现在的工作方式是另一种分工，不写每一行代码，不调试每一个 bug，不盯着每一个终端。但我在做另一件事：定义问题、压缩上下文、设置验收口。每天开始前想清楚：今天的 Token 应该产出什么结果，什么标准算做好，哪些可以自动合入，哪些必须人工判断。

有一个粗糙但准确的比喻：以前写代码像手工打铁，每一锤都要精准，靠经验和专注。现在更像抽卡，单次 Token 成本低到可以大量生成候选，价值来自筛选机制有多严，而不是每张卡生成得多精良。不是效率提升，是生产方式变了。AI 把技能门槛压低之后，人的价值没有消失，位置前移了。过去花时间写实现，现在花时间定义问题。所谓「有品味」，在工程现场就是知道什么值得自动化、什么必须挡在合入前、什么叫「这个结果可以用」。

Cloud Agents 要解决的问题是让这种新分工不再是个人实验，不需要每个团队自己搭 Harness，不需要每个工程师变成 Agent 运维专家。平台把复杂度吸收掉之后，开发者可以把注意力放在唯一重要的事上：定义值得解决的问题。睡后 Token 改变的不是作息，是工程分工。人负责价值、边界和验收，平台负责把长任务稳定地跑完。