--- title: "Qoder 工程实践：当瓶颈从模型转移到人" source_url: "https://mp.weixin.qq.com/s/eqXwBatW2CzcAPXO9m3T3w" source: wechat ingested: 2026-07-05T04:04:24Z sha256: 58a675679bad73964db425fb541012df0192ae48af50f7adbe73e5bb7d092cbb vxc: 64 stars: 4 _provider: deepseek --- # Qoder 工程实践：当瓶颈从模型转移到人 --- source: wechat source_url: https://mp.weixin.qq.com/s/eqXwBatW2CzcAPXO9m3T3w ingested: 2026-07-05 source_published: 2026年6月12日 17:55 --- # Qoder 工程实践：当瓶颈从模型转移到人 这是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 上的规划，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 改变的不是作息，是工程分工。人负责价值、边界和验收，平台负责把长任务稳定地跑完。 欢迎留言一起参与讨论~