Qoder 工程实践：当瓶颈从模型转移到人
当 AI 输出的价值稳定超过 Token 成本之后，瓶颈从模型能力转移到了人的精力。
Peter（OpenClaw作者）一天内提交了 627 次代码——计算一下，一天有 1440 分钟，这意味着每次代码提交间隔平均不到 2.3 分钟。我看到这个数字的第一反应不是佩服，是替他感到累，这一天结束后，他还剩多少判断力？AI 在高速工作，人被绑在旁边陪跑，第二天 Token 得等他缓过来。
我自己在 5 月份完成了 496 次提交，冷静下来想想，这只能说明吞吐变了，无法说明效能是否提升。提交数是过程痕迹，不是价值指标。
每一次工作方式的进化，都在回答同一件事：**怎样用更少的人力在线时间，让更多的 Token 持续流动？**我认为这个问题的答案不是一个更好的 IDE 插件，也不是一个更聪明的模型，是一整套云端持续进化的 Harness 基础设施。
01 从「更快打字」到「任务自主交付」
最开始用 Cursor，效率提升了三到五成。但有一件事始终没变：方向盘在我手里，我不打字，它不动。从 Token 的角度看，每次请求几百到几千 Token，产出是"节省了一些打字时间"。但是人停，Token 停。
茹炳晟有个判断：软件工程过去五十年一直在「管理人的不确定性」，从瀑布到敏捷到 DevOps，本质上都是用方法论管理人，而不是替代人。Copilot 和 Cursor 没有跳出这个范式。给手工匠人换了把更好的锤子，仅此而已。
02 第一次感受到范式变化
真正的体感变化发生在 Opus 4.5 之后。CLI Agent 和之前所有工具都不是一回事。如果说 Cursor 是辅助驾驶，那么 CLI Agent 就是自主执行体。
开始记录数据：分析一个 2400 行的 TypeScript agent-loop 模块，产出完整架构分析报告：276,010 tokens，10 分钟，995 行输出。一个 bug 修复从描述问题到代码提交：60 秒。设计文档深度 review，发现 5 个 Critical 和 8 个 Medium，也就 5 到 6 分钟。
大模型第一次让「用算力换取高阶智能」成为可能。软件工程五十年卡在「高阶认知无法被固化」这个死结上，大模型把它劈开了一道缝。
03 并发的陷阱：Token 在加速，人在崩溃
同时开多个终端执行 Agent，跑多个任务。四个 Agent 并行跑，15 分钟出结果，串行要一小时。产出确实高了，但疲劳感比单线程还严重。注意力在多个上下文之间不停切换，每次切换都有认知成本。
并发没有消灭我的工作。它只是把等待时间换成了调度时间。
Thoughtworks 的 Birgitta Böckeler：Context Engineering 是一个放大器杠杆，放大是双向的，好的工程实践会被放大，坏的结构问题也会被放大。
该问的问题，是「怎么让 Token 消耗得更多，同时减少对人的注意力消耗」。
04 委派：把人压缩到决策位
QoderWork 逐渐成熟后，角色发生了根本性转变：不再是执行者，不再是调度器，而是纯粹的决策者。只做三件事：提需求、审方案、验结果。
三层委派架构：我说一句话，QoderWork 把它精炼成结构化 prompt，Task Agent 在独立上下文里长时间运行，QoderCLI 在独立的 worktree 里把指令翻译成代码。信息逐层精炼，控制权逐层下放。
05 稳定运行靠什么
三层委派不是靠某个 prompt 写得好就能跑起来的，关键是给每一层 Agent 写操作手册——AGENTS.md 里定义职责边界、禁止行为、交付规则，MEMORY.md 记录项目上下文和历史决策，USER.md 记录偏好。
分层管理：什么是全局不变的（项目规范、技术栈约束），什么是会话级的（当前任务目标、验收标准），什么是按需加载的（特定模块的代码结构、历史决策记录）。
06 睡后 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 和业务判断，才有资格进资产池。
Böckeler 讲风险评估有三个维度：概率、影响、可检测性。最后那个最关键。
第二个场景：夜间批量任务。设计文档 review、跨仓库 API 一致性检查、大规模重构影响面分析。杠杆率从 1:N（N 受限于在线小时数）变成接近 1:24。
08 但 Harness 会咬人
Agent 开发 70% 的成本不在 AI 模型推理，在 Harness。Harness 是让非确定性的模型产出被确定性的工程系统约束住的那套东西：Token 编排引擎、安全沙箱、可观测性、状态持久化、错误恢复。
Böckeler：也许未来我们不再靠传统服务模板起步，而是靠 Harness 模板。选技术栈的决策维度可能不再是「React 还是 Vue」，而是「有没有现成的 Harness」。
Sota 模型正在加速进化，已有的 Harness 也在加速过期。每个认真用 Agent 的工程师都得自己搭一套，这事没法规模化。个人可以快，但组织未必有效。
09 Cloud Agents：从个人脚本到平台
平台要托管的是长期任务的可恢复性，不是进程本身。让睡后 Token 可靠运行，需要三件事同时成立：
- Session 不怕断：会话是持久的事件流，和进程是否存活无关
- Sandbox 不怕换：执行环境可替换，失败了重新 provision
- Harness 不怕重启：无状态的大脑，随时可以用 wake(sessionId) 接管
10 手脑分离
Cloud Agents 架构核心是「手脑分离」：Brain 负责推理决策，Hands 负责执行操作，两者独立升级。
- 升级的复利效应：Brain 升级一次，所有用户同步受益，零迁移成本
- 故障隔离：Brain 出问题不影响 Hands 的执行环境
- 资源效率：Brain 计算密集型，Hands IO 密集型，独立伸缩
Harness 的价值在于用确定性的工程系统约束非确定性的模型产出，让 Agent 从「demo 能跑」变成「生产环境可靠」。
11 极简接入：你的代码里没有 AI
Cloud Agents 的接入路径只有五步：获取令牌、创建运行环境、定义 Agent、建立 Session、通过事件流收发消息。Agent 的「智能」写在 API 里，不在你的代码里。
12 Skill as a Service
Cloud Agents 让本地 Skill 变成云端 Service。反复打磨过的最佳实践，通过 Cloud Agents 发布成 API 可调用的服务。团队里任何人都可以通过应用集成调用这个能力。
13 自评估循环
Agent 自动验证输出质量，不满意则自动重试迭代。把风险检测内置到 Agent 运行循环里，而不是依赖人事后检查。
14 更往前一步的思考
有一个粗糙但准确的比喻：以前写代码像手工打铁，每一锤都要精准。现在更像抽卡，单次 Token 成本低到可以大量生成候选，价值来自筛选机制有多严。
AI 把技能门槛压低之后，人的价值没有消失，位置前移了。过去花时间写实现，现在花时间定义问题。所谓「有品味」，在工程现场就是知道什么值得自动化、什么必须挡在合入前、什么叫「这个结果可以用」。
Cloud Agents 要解决的问题是让这种新分工不再是个人实验。平台把复杂度吸收掉之后，开发者可以把注意力放在唯一重要的事上：定义值得解决的问题。睡后 Token 改变的不是作息，是工程分工。