这是2026年的第23篇文章

本文阅读时间：约15分钟

引言

当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上的规划，已经上线。自己和外部团队都在上面跑真实业务。前面提到的那个"多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改变的不是作息，是工程分工。人负责价值、边界和验收，平台负责把长任务稳定地跑完。