睡后 Token 与 Cloud Agents:AI Coding 的工程分工
AI Coding 的早期问题通常是模型能力不足。补全不稳定、上下文短、工具调用弱,开发者只能把模型当作更快的搜索框或更会改局部代码的副驾。
这类问题正在退到后面。模型输出的边际价值一旦稳定超过 token 成本,真正稀缺的东西就变成了人的在线注意力:谁来持续拆任务、喂上下文、看日志、判断结果、处理失败、决定哪些改动能进入主干。
“睡后 Token”描述的不是熬夜让模型跑得久一点,而是一种工程分工的变化:人提前定义目标、边界和验收口,Agent 在人离线时持续生成候选结果,等人回来时只处理已经被筛过一轮的判断对象。
瓶颈从模型转到人
过去讨论 AI Coding,经常把问题压成一句话:模型够不够聪明。
这个问题仍然重要,但它不再解释全部差异。两个团队使用同等能力的模型,一个只能做单文件补全,另一个可以稳定跑完多仓库修改、自动验证、失败回收和审查流转,差距主要不在模型本身,而在模型外面那层工程系统。
AI Coding 的生产率瓶颈大致经历了几个阶段。
| 阶段 | 典型形态 | 主要瓶颈 | 工程含义 |
|---|---|---|---|
| IDE 辅助驾驶 | 补全、局部改写、问答 | 人不动,token 就停 | 模型像更锋利的工具 |
| CLI Agent | 端到端执行一个任务 | 单任务串行 | Agent 开始接管闭环 |
| 多终端并发 | 多个 Agent 并行跑 | 人的调度成本 | 等待减少,判读变重 |
| 三层委派 | 需求精炼、任务执行、代码落地分层 | 人仍需在线调度 | 人被压到决策位 |
| 睡后 Token | 离线产出候选结果 | 验证与回收机制 | 人只处理筛选后的结果 |
| Cloud Agents | 云端托管 Agent Harness | 平台可靠性 | 长任务被基础设施承载 |
这条路径有一个共同趋势:人逐渐退出“每一步都在场”的执行位置,转到定义问题、设置约束、验收结果的位置。token 的价值不再由“调用了多少”衡量,而由“有多少结果进入了可靠判断流程”衡量。
提交数不是价值指标
Agent 很容易制造看起来热闹的过程痕迹:提交、分支、日志、草稿、代码块、issue 评论、自动生成的分析报告。它们都可能有用,但都不是最终价值。
更稳的指标是漏斗。
一个健康的 AI Coding 工作流应该回答几类问题:
| 问题 | 价值判断 |
|---|---|
| 多少候选问题被识别出来 | 发现能力 |
| 多少候选被验证为有效 | 初筛能力 |
| 多少改动通过自动验证 | 工程约束能力 |
| 多少结果通过人工审查 | 质量判断能力 |
| 多少改动最终进入主干 | 业务可用能力 |
这个漏斗里,被挡住的候选同样有价值。一个自动化系统如果把数百个候选压成十几个可审查结果,它的贡献包含两部分:合入的少数改动,以及没有被推给主干和审查者的大量低质量改动。
Agent 产出默认应该先按负债处理。只有通过测试、review、业务判断和回滚预案之后,它才变成资产。
睡后 Token 的核心是提前收口
让 Agent 离线长跑并不难。难的是让它在没有人盯着的情况下不乱跑、不越界、不把错误结果堆成垃圾场。
睡后 Token 需要提前固定四件事。
| 设计项 | 作用 |
|---|---|
| 输入 | 明确任务、资料、仓库范围和上下文入口 |
| 边界 | 限制可修改文件、可运行命令、网络与权限 |
| 验证 | 让 lint、build、test、smoke check 自动拦截坏结果 |
| 回收 | 产出结构化报告、diff、失败原因和下一步建议 |
没有这四件事,离线长跑只是把人工等待换成事后清理。任务跑得越久,失败面越大,读日志和回滚的成本也越高。
睡后 Token 最要紧的地方在于:人不在场时,系统仍然知道什么算可接受结果。问题也因此从 prompt 写法推到了 Harness Engineering。
Harness 才是长任务的承重层
Agent Harness 是模型外面的运行时底座。它负责 token 编排、工具调用、沙箱、状态、日志、权限、恢复和验证。模型决定下一步想做什么,Harness 决定这一步能不能安全、可观测、可恢复地发生。
把长任务交给 Agent 后,Harness 至少要承担这些能力。
| 能力 | 没有它时的后果 |
|---|---|
| 状态持久化 | 进程断了,任务上下文丢失 |
| 沙箱隔离 | 一次错误命令污染本地或生产环境 |
| 可观测性 | 无法解释 Agent 到底做了什么 |
| 验证门禁 | 错误代码以“已完成”的姿态流入审查 |
| 失败恢复 | 一次 flaky 依赖或环境错误让整轮任务报废 |
| 产物归档 | 人回来后只能面对散落的日志和 diff |
个人脚手架可以很快搭出来:几个 shell 脚本、几个 prompt 模板、一个工作区约定、一些手动检查命令。它的好处是贴手,坏处是难复用、难审计、难交接。
组织级 AI Coding 不能长期依赖每个工程师自己的临时脚手架。模型迭代越快,个人 Harness 过期越快;个人越会调,组织越难复用。Cloud Agents 的价值就在这里:把本地经验变成可部署、可观测、可恢复的公共能力。
Cloud Agents 的三个分离
Cloud Agents 不能只理解成“把本地 CLI 搬到远端机器”。它要解决的是长任务的生命周期管理。
第一层分离是 Brain 和 Hands。
Brain 负责推理、规划、判断和重试策略。Hands 负责执行命令、读写文件、调用工具、跑验证。Brain 可以升级模型和策略,Hands 可以替换沙箱和执行环境。两者通过事件流通信,而不是把所有状态塞进一个本地进程。
第二层分离是 Session 和 Process。
进程会退出,网络会断开,容器会重建,但任务不应该跟着消失。Session 应该落在事件流和持久化状态里。只要 session id 还在,新的执行进程就能接管任务,继续从可恢复点往下跑。
第三层分离是 Skill 和个人电脑。
本地打磨出来的诊断套路、审查规则、迁移流程和验证脚本,如果只能存在于某台机器上,它只是个人效率工具。把它发布成可调用的服务之后,才可能变成团队能力:故障诊断可以进入 on-call 流程,安全扫描可以进入 CI,API 设计审查可以进入每个 PR。
可检测性先于自治
Agent 自主运行的风险不能只看“出错概率”。还要看“出错影响”和“能不能被发现”。
| 维度 | 典型问题 |
|---|---|
| 概率 | Agent 多大概率做错 |
| 影响 | 做错之后会破坏什么 |
| 可检测性 | 做错之后系统能否及时发现 |
高概率、低影响、强可检测的任务,可以大胆自动化。低概率、高影响、弱可检测的任务,反而应该收紧权限,把 Agent 放在建议位或候选位。
很多 AI Coding 事故不是因为模型完全不会做,而是因为系统没有把“发现错误”的能力设计进去。验证如果只是事后人工抽查,长任务就无法放心离线运行。验证必须进入 Agent Loop:每次改动之后自动运行最小验证,失败就回读错误、修复、重试;连续失败再升级给人。
工程分工的变化
传统开发里,代码是主要劳动成果。AI Coding 之后,代码更像中间产物,真正稀缺的东西变成了问题定义、上下文压缩、边界设置和验收标准。
人的价值位置前移了。
| 旧位置 | 新位置 |
|---|---|
| 手写每个实现细节 | 定义什么结果值得实现 |
| 手动跑每个验证命令 | 设计哪些验证必须阻塞 |
| 手动排查每次失败 | 规定失败如何归因和恢复 |
| 靠经验记住项目坑点 | 把坑点写进仓库和 Harness |
| 审所有输出 | 审被筛过的候选结果 |
开发者价值没有下降,变化的是价值重心。会写代码仍然重要;知道哪些东西可以交给 Agent,哪些东西必须被挡住,什么样的结果才算可以进入主干,会变得更重要。
模式速查表
| 听到的需求 | 对应模式 | 实施要点 |
|---|---|---|
| 想让 Agent 夜间跑任务 | 睡后 Token | 先定义输入、边界、验证和回收 |
| 多个 Agent 并行后人看不过来 | 漏斗治理 | 用自动验证和结构化报告压缩候选 |
| 本地脚手架越来越多 | Harness 产品化 | 把脚本、规则、权限和状态收进运行时 |
| Agent 常常改对一半 | 验证内嵌 | 每轮改动后自动跑最小验证 |
| 团队无法复用个人经验 | Skill as a Service | 把可迁移流程发布成可调用能力 |
睡后 Token 改变的是工程分工。人负责价值、边界和验收;平台负责把长任务稳定地跑完;Agent 在被约束的空间里持续生成候选结果。
