GitHub 把 Agent 使用数据变成团队反馈循环チャプター1×0:08今天的事件1:03它接进了什么循环2:31指标的边界3:25给团队的三个动作0:004:490:08主持人北京时间今天凌晨,GitHub 发布了 Copilot 使用指标影响仪表盘。它关注的不是「有多少人登录过」,而是团队用到了哪一层能力,这些使用和代码协作结果有什么关系,下一步该把启用工作投向哪里。 仪表盘把参与 Copilot 的人分成几类:代码优先,主要使用代码补全或开发环境里的 Agent 模式;Agent 优先,开始使用云端 Agent、代码审查或命令行 Agent 中的一种;多 Agent,使用两个或更多 GitHub Agent 面,或者使用 Copilot 应用;还有已经分配许可、但没有形成有效参与的用户。 每个阶段会显示每位用户每月平均合并的拉取请求、合并速度中位数、用户数和占比,以及每位用户每天平均代码行数。它还提供一个采纳倍数,把未参与用户和已参与用户的吞吐与速度做比较,并给出六个月趋势和推荐的下一步动作。1:03主持人这条更新把「谁用过」往前推了一步,试着接成一条反馈循环:先观察采用阶段,再看阶段和拉取请求结果的关系,针对团队或代码库做启用动作,下一轮再看阶段和结果有没有变化。 GitHub 早先的更新说明写明,采用阶段按二十八天滚动窗口计算,用户在窗口内至少活跃两天,才会进入参与用户分类。阶段由实际使用过的产品面判定,不是员工自报的标签。它是最近行为的快照,不是永久身份。 七月中旬,GitHub 又开放了按代码库查看的 Copilot 指标。对 coding agent,可以按天看拉取请求的创建和合并;对 code review,可以看被审查的拉取请求,以及按评论类型拆开的建议数量。于是团队可以继续追问:哪些仓库已经进入 Agent 优先,哪些地方建议很多但合并没有跟上,问题究竟在任务适配、审查规则,还是代码库准备度。 从 Loop Engineering 的角度看,仪表盘只是观测层,控制层要把数据变成下一步动作。一个可执行的循环是:按阶段和代码库切片,选一个结果指标,安排一个具体动作,设定观察窗口,再回来看结果。某团队进入 Agent 优先但合并率没有改善时,下一步不应只是催大家多用 Agent,而应检查任务是否适合交给 Agent,失败反馈能否回到下一次执行里。2:31主持人阶段更深,不等于工程质量更高。GitHub 展示的是使用阶段和代码活动、拉取请求结果之间的关系,并没有在这次更新里声称仪表盘能证明 Copilot 导致了速度提升。 平均代码行数不是质量指标。合并速度变快,可能代表协作顺畅,也可能只是变更变小了。拉取请求变多,可能是 Agent 接手了重复劳动,也可能是审查负担增加。采纳倍数适合发现差异,不适合直接做个人排名,更不能当成最终的投入产出比。 还要记住两个口径:阶段基于二十八天滚动窗口,跨月比较时要保留分母和窗口;仪表盘面向有权限的企业管理员和组织所有者,不是单个开发者的 Agent 调试 trace。GitHub 的文档把这套指标放在仪表盘和接口两条路径上,它更像组织级运营数据。3:25主持人第一,把采用阶段和结果指标分开存。阶段回答「用到了哪层能力」,结果回答「交付发生了什么变化」。除了合并请求,还要记录审查返工、失败重试和交付周期,并标明代码库、团队和观察窗口。 第二,把下一步写成可回看的实验,而不是「加强推广」。比如给 Agent 优先团队开放一套任务模板,只观察两到四周的完成率和审查返工率;给代码优先团队做工作流培训,但不要同时更换模型、权限和审查规则。变化因素太多,反馈就无法归因。 第三,加上质量和安全护栏,至少同时看审查发现、回滚、缺陷、敏感代码触达和人工接管。否则系统可能因为产生更多代码而得高分,却把问题推到生产环境。 这次更新真正值得跟进的地方,不是又多了一张管理大屏,而是 Agent 采用被改写成了持续测量、分组、试验和复盘的工程过程。今天别只问团队用了多少 Copilot,还要问:他们处在哪个阶段,哪个代码库的结果最不匹配,二十八天后用什么证据判断下一步真的有效。 今天的 AI Loop Engineering 早报就到这里。我们明早继续。