当昨天的进度本身就是谎言:AI 时代的站会怎么开
团队上午十点开站会。第一位工程师开始汇报他的 Agent 们昨晚完成了什么——只是,早上七点启动的评测套件还没跑完,Agent 凌晨三点开的那个 PR 正在等另一个 Agent 评审、而后者的队列深度无人知晓,长跑的重构 Agent 已经进入第十一个小时(预估是四小时),既没有卡住的信号、也没有健康的信号。昨天的状态既不是"已完成",也不是"进行中"。从会议室里看,昨天的状态根本无从得知。
站会本来是一种为同步人类工作量身定做的同步仪式。每个人做一件事、完成它、睡一觉、第二天早上汇报。工作的最小单位是一个工作日。汇报的最小单位是一个人。节奏匹配的是底层介质。现在这些前提全都不成立了。今天工作的最小单位是一次 Agent 运行,它在你上床前就启动了,可能在会议进行中或会议后三小时收工。汇报的最小单位是一支集群,而不是一 个人。而那个节奏——上午十点准时开始、9 到 15 分钟一轮的轮流播报——是底层介质根本不会按这个频率产出事件的节奏。
轮流播报已经没有答案了
Scrum 的标准问句是"你昨天做了什么、今天打算做什么、有什么阻塞你的"。每一个字都假设工程师就是那个执行者。可当工程师真正的角色是队列管理——启动任务、审查产出、决定哪些合并、哪些重做、哪些放弃——这三个问题没有一个能给出清爽的答案。
"你昨天做了什么"问的是错的形状,因为工程师在任何直接意义上都没有做昨天的工作。他把活儿排了队。Agent 们做了,或者正在做,或者跑了四步就悄悄放弃没举旗。诚实的回答更像是"我排了七次运行;三个落了 PR,两个还在跑,一个在第三步崩了,一个看着像成功但评测套件还没认证"。这是一份组合报告,不是一份个人报告,而站会的格式里根本没有放它的格子。
"你今天打算做什么"问的也是错的形状,因为今天的活儿是由昨天队列里回来的东西决定的。如果三个 Agent 在午饭前完成了重构,今天就是评审合并日。如果其中两个被一个时好时坏的集成测试卡住,今天就是去调试那个测试。如果长跑的迁移 Agent 在第 47 步抛了异常,今天就是去抢救它。工程师没法预先陈述今天的计划,因为今天是 Agent 状态的函数,而站会发生在他还没去看那些状态之前。
"有什么阻塞你的"问的还是错的形状,因为阻塞已经不再是人和人之间的交接。阻塞是一套要跑三小时的评测套件、一份积着十二个待评审 PR 且无人分诊的评审队列、一个被 CAPTCHA 卡了四十分钟的 Agent、一个正在缓慢褐化但 Agent 没意识到的下游 API。这些东西在轮流播报里都不可见。它们住在没人会在上午十点之前打开的仪表盘里。
介质已经动了,仪式还没动
仪式当年是对的,因为它匹配当年的介质。当工作是同步的——敲代码、跑测试、开 PR、拿评审、合并——工作日就是自然的单位,而下班是一条有意义的边界。下班意味着工程师停下了。工程师脑子里的缓存还是热的。他不需要工具来帮自己回忆,就能讲清楚自己做了什么。
异步的 Agent 工作没有这些性质里的任何一条。工作并不会因为工程师下班回家就停下来。工程师脑子里的缓存到上午十点已经凉透了,因为 Agent 们在他不在的十个小时里一直在跑。"昨天的工作"和"今天的工作"之间的边界已经不再是工程师的睡眠周期——它是一道任意切口,切过一条从晚上十一点开始、要到中午才结束的 Agent 运行流。
经验信号在这里很响。即便单兵生成在加速,团队层面的交付反而在变慢。PR 数量翻了将近一倍。评审延迟也按相近的倍率拉长。代码搅动率上升。代价压在了站会本来应该浮现出来的那段管道上——评审、集成、质量——而这些环节已经从人的瓶颈转化成了系统的瓶颈,是站会这种格式没被设计来读的东西。
站会度量的是工程师。需要度量的是工程师所操纵的那个系统:有多少 Agent 在跑、多少卡在评审、多少静默失败、评 测套件积压了多深、最长那个 PR 等了多久、有多少次运行在执行中被遗弃且没有清理。这套仪式汇报的是一种已经迁移到别处的能动性。
队列快照,不是状态汇报
会议室需要做的转变,是从状态汇报转向队列快照。队列快照是一小串数字,描述在飞行中工作的状态,从 Agent 正在写入的那块仪表盘上读取出来——不是由一个根本不在场的人凭记忆复述出来的。
一个跑 Agent 的小团队最少有用的队列快照大约有五个数字。活跃的 Agent 运行,以及它们各自在做哪一类工作——重构、缺陷、特性、评测。等待评审的开放 PR,拆成"可落地"和"需要人判断"两档。过去 24 小时内中途崩掉、且尚未被重试、分诊或注销的运行。评测套件的运行时债务——排队的评测有多少小时、距离下一次发布决策之前还剩多少小时的算力。Agent 计算的预算消耗对比,因为每天 30+ 次运行时,账单本身就是集群健康的真实信号。
这些数字的目的不是穷尽。目的是呈现组合状态——系统内整体发生了什么,而不是每个人各自做了什么。当会议室一起读这份快照时,接下来的对话是分诊,不是叙述。为什么有九个 PR 在等评审?谁来清?为什么过去一天里有四次运行都在第三步崩了——是不是上游坏了?评测队列积了六小时深,我们周五要发布;哪些被砍掉?
这更接近一场事故响应站会,而不是 Scrum 站会。它假设有一个正在做工的系统,以及一屋子在驾驭它的人。它把每日会议当作一次简短、结构化的仪表盘拉取,后面跟着几个只有 人才能做的决定。节奏的问题甚至变成:每天上午十点这个时间对吗——对某些团队来说,每天两次、在长跑的评测批次跑完前后各一次,比在早晨 Agent 队列还没清空之前的一次,更合适。
效能剧场的陷阱
错误的适配方式,恰恰是大多数团队已经在漂向的那种。管理者想找一个数字,就退回到把 Agent 的 PR 吞吐当作效能代理。每位工程师每周的 PR 数变成头条指标。给跑得快的 Agent 当保姆的工程师拿到奖励。设计让集群更健康的系统的工程师——更好的工具、更好的评测、更好的重试逻辑、更好的清理——变得无形。
这是行业早就知道的那种失效模式,只是被加速了。当 PR 是人写的时候,PR 数就已经是工程师价值的烂代理。当 PR 是 Agent 写的时候,它是更烂的代理,因为 Agent 可以被要求开出更多、更小的 PR,边际成本基本为零。数字上去了。它承载的信号下去了。一个季度之内,这个指标就被博弈;两个季度之内,团队已经按错的技能在筛选人。
管理者的问题不是"每个工程师的 Agent 落了多少 PR"。管理者的问题是"生产并评审这些 PR 的那套系统是否健康"。这是两个不同的问题,需要不同的指标。吞吐是集群的属性。健康是集群周围那套系统的属性——评审 SLA、放弃率、卡住运行从出现到分诊的平均耗时、评测套件的新鲜度、每次落地变更的成本。如果站会或它背后的仪表盘没有显示这些,团队就是在汇报影子效能,而真实的工作正在无人观测中劣化。
站会作为 分诊,而不是点名
挺过这次转型的站会不再是轮流播报。它变成一场针对 Agent 工作仪表盘的简短分诊会,议程固定:读一遍快照,点出两到三件不对劲的事,决定谁去追每一件。会议室里工程师的角色,从汇报自己的工作,变成解读系统的状态、并做出系统自己做不了的那些判断。
这之所以管用,是因为它诚实地承认了底层介质。"我昨天做了什么"已经不再有过去那种含义。有的是"自上次会议以来队列发生了什么,我们应该怎么办"。会议室读的那份制品是实时的、共享的。会议室做的那些决定,是关于整个集群的资源分配,而不是关于个人的进度汇报。
早一步做这个转变的团队同时拿到了两样东西。他们把每天那半小时——本来花在叙述仪表盘已经知道的事情上——拿回来了。同时他们抓到了那种轮流播报格式结构上就盲掉的失效模式——被遗弃的运行、评测套件里的静默回归、悄悄涨到三十个 PR 的评审队列、已经飘忽了一周却没人指名的 Agent 基础设施。
那些还在用 2018 年的站会对付 2026 年的底层介质的团队,他们汇报的不是自己的工作。他们在汇报一份关于自己工作的虚构,凭记忆叙述,而真正的工作发生在一个会议室里没人打开过的队列里。仪式完好。它承载的信息不在。第一步不是放弃这场会议——而是把它对准团队今天实际在做的那件事,也就是驾驭一支并非自己写代码的集群,对着一个并非完全由自己控制的时钟,在一种自己仍在学习如何观测的底层介质上。
- https://www.honeycomb.io/blog/standup-meetings-are-dead
- https://www.artisanagility.com/blog/mjd5332lhhzk6qgl4p0qhkdx35eev9
- https://newsletter.eng-leadership.com/p/code-review-is-the-new-bottleneck
- https://getdx.com/blog/ai-productivity-gains-are-10-percent-not-10x
- https://larridin.com/developer-productivity-hub/developer-productivity-benchmarks-2026
- https://arize.com/blog/best-ai-observability-tools-for-autonomous-agents-in-2026/
- https://www.langchain.com/state-of-agent-engineering
- https://martinfowler.com/articles/itsNotJustStandingUp.html
