Qoder 工程实践：当瓶颈从模型转移到人
编译摘要
1. 浓缩
-
核心结论1: 当 AI 输出价值稳定超过 Token 成本后，瓶颈从模型能力转移到人的注意力带宽——"人停 Token 停"是根本约束
- 关键证据: Peter（OpenClaw）一天 627 次提交，每次间隔不到 2.3 分钟——人被绑在旁边陪跑
- 关键证据: 4 个 Agent 并行跑，产出高了但疲劳感比单线程还严重——"并发没有消灭工作，只是把等待时间换成了调度时间"
-
核心结论2: 工作方式的进化路径是 Cursor（更快打字）→ CLI Agent（自主执行）→ 并发 Agent（调度时间吞噬收益）→ 三层委派（人压缩到决策位）→ 睡后 Token（离线产出候选结果）
- 关键证据: 三层委派架构：自然语言 → QoderWork 精炼为结构化 prompt → Task Agent → QoderCLI 在独立 worktree 执行
- 关键证据: 634 issue 进 → 190 有效缺陷 → 25 CR → 12 合入。漏斗价值在于 622 个没进主干
-
核心结论3: Agent 开发 70% 的成本在 Harness 而非模型推理；个人 Harness 无法规模化，需要平台吸收复杂度——"睡后 Token 改变的不是作息，是工程分工"
- 关键证据: Cloud Agents 手脑分离架构——Brain（计算密集/推理）和 Hands（IO 密集/执行）独立升级、故障隔离、资源独立伸缩
- 关键证据: "634 进 12 出"的验收漏斗——Agent 生成的 CR 先按负债处理，只有通过测试、review 和业务判断才进资产池
2. 质疑
- 关于"70% 在 Harness"的质疑: 这个比例缺乏严格的数据支撑，更像是一手经验的定性判断。不同场景（简单 CRUD vs 复杂架构重构）的 Harness 占比可能差异很大
- 关于"睡后 Token"的质疑: 夜间批量任务的安全前提是"验收口设计足够严"，但文章只给出了一个场景的数据（634 进 12 出）。在更复杂的重构任务中，自动化验收的可靠性存疑
- 关于 Qoder Cloud Agents 的质疑: 文章有产品推广性质，"一天跑通 6 Agent 协同系统"的案例缺少生产验证数据（延迟、成本、长期稳定性）
3. 对标
- 跨域关联1: "睡后 Token"类似量化交易中的离线回测——策略在离线环境生成候选，人在开盘前做最终筛选
- 跨域关联2: "634 进 12 出"的漏斗类似 spam filter 设计哲学——宁可漏过（人工补做），不可放过（坏代码进主干）
- 跨域关联3: 三层委派（自然语言→结构化 prompt→执行）类似编译器流水线——源码→IR→机器码，每层抽象降低下一层的复杂度
- 跨域关联4: Böckeler 的风险三维度（概率、影响、可检测性）与 FMEA（故障模式与影响分析）方法论高度一致