机器人账户与智能体提交该不该单独计数：先定维度，再谈分列

应当分列，但“单独计数”的正确单位不是账户，而是可归因的提交事件。只把账号分成“人”和“机器人”两类，会把“人用 agent 写代码”和“agent 全自动产出”压进同一格，而这两类对提交量、评审负载和代码质量的含义完全不同。

先说明证据边界。GitHub Blog 于 2026 年 10 月 28 日发布的文章，标题称 2026 年提交、推送与覆盖范围创新高，并将其与开发者使用 agents 构建联系起来（The GitHub Blog）。其摘要只提到增长覆盖各行业与各类构建者。本次材料未提供具体数值、分类方法，也未说明该报告是否已将机器人账户或智能体提交分列统计——这些均待核实。因此下文讨论的是计数口径的设计，不是对报告结论的复述。

混算与全拆，各有代价#

混算的问题是总量失去解释力：提交曲线上升，可能主要来自自动化频率提高，而不是参与人数或工作时长增加。全拆的问题相反：把 agent 参与的提交整体划给机器，会系统性低估人类在提示、审阅、修正上的投入，而这段投入恰恰是当前协作模式的主要成本所在。

四个可分离的维度#

四个维度里，账户主体最容易拿到，但它单独使用的解释力最弱。署名证据的可信度取决于项目是否约定并执行了 agent 署名规范；本次材料没有涉及这类规范的存在与普及程度，待核实。

建议的最小计数集合#

• 划分为 human、agent-assisted、automated 三类，互斥且可加总，总和等于原提交总量。
• 先保证“可归因”，再考虑细分。宁可保留一个 unknown 桶，也不要把无法判断的提交硬塞进 human。
• 保存原始事件表，指标按需聚合。分类规则会变，原始记录不会。
• 口径变更与指标发布同步说明，否则跨年对比会变成伪对比。

下面是一段分类判定的设计示意，未执行，也不针对任何真实 API；字段名为占位。

# 设计示意，未执行；不调用真实接口
def classify(commit):
    if commit.account_type in ("Bot", "App"):
        return "automated"
    if has_agent_trailer(commit.message):   # 如 Co-authored-by 中的工具标识
        return "agent-assisted"
    if commit.account_type == "User":
        return "human"
    return "unknown"

这段逻辑的已知缺陷是靠 trailer 判断会漏掉未署名的 agent 输出，从而把部分 agent-assisted 计入 human。任何实现都应把这一漏检率当成口径的一部分披露，而不是默认它为零。

分列之后，哪些指标会变#

活跃贡献者数、人均提交量、提交与合并的比例、评审等待时间，都会随分类规则移动。其中人均提交对分类尤其敏感：如果把 agent-assisted 从分母中剔除，人均值会明显上升，看起来像效率改善，实际只是分母缩小。跨年比较时，至少要说明当年使用的是哪一版分类规则。

结论与待核实项#

该分列，但分列的前提是先定义“归因到谁”。在没有署名规范、也没有平台级产生方式记录的情况下，任何分列结果都带有推断成分，应当连同推断规则一起发布。至于 2026 年的增长中有多少来自自动化提交、机器人账户占比多少，本次材料未提供，不能从标题推断。