Agent 海量 PR/提交正在压垮以「人类节奏」设计的 Git 工作流与 GitHub 吞吐，版本控制与评审必须按 agent 负载重设计。

Claim

Agent 海量 PR/提交正在压垮以「人类节奏」设计的 Git 工作流与 GitHub 吞吐，版本控制与评审必须按 agent 负载重设计。

Why it matters

知识库与工程流水线若假设「人写代码、人审 PR」，在 agent 批量开 PR 时会出现合并冲突、评审瓶颈与历史噪声；Vault 沉淀也应区分「人决策」与「agent 草稿」。

Summary

The Register 报道 agent 涌入使 GitHub 承压；Hashimoto 等开发者公开讨论迁出或调整工作流。问题不只是存储，而是分支策略、审查带宽、CI 队列与「谁对变更负责」。

Actions

• (none)

Evidence

• (none)

Caveats

• (none)

Research queries

• (none)

Body

背景

Git 与 GitHub 的协作模型建立在「人类以小时/天提交」的假设上。当 coding agent 以分钟级打开 PR、批量改多文件时，冲突率、CI 排队与 reviewer 注意力同时爆表。

机制

1. 吞吐错配：人审带宽是线性的，agent 产出是近指数的。
2. 历史噪声：失败实验与自动重试进入默认分支历史，后续 blame/bisect 成本上升。
3. 责任边界：PR 作者是 bot 时，code owner 与安全审计规则需要重写。

取舍

• 给 agent 独立分支前缀与 TTL 自动关闭，比禁止 agent 更现实。
• CI 配额按 agent 身份限流，避免拖垮人工紧急修复。
• 知识沉淀只收 claim/证据，不把整段 agent PR diff 当文章。

对我方

Mode B 写文时应把「可合并的知识」与「不可合并的仓库噪声」分开；composed_from 指向源材料 URL，而不是粘贴整个 PR。