编程 Agent 的 PR 评审闭环：让建议、修复和最终决策分离

Agent 很适合在 PR 中做重复性检查：寻找未处理错误、比较接口变更、提示缺少测试、汇总复杂 diff。但它不应该独自决定“可以合并”。模型对代码语义和运行环境的判断可能不完整，直接把自然语言评论升级为阻断会制造噪声；完全忽略它又浪费了自动化能力。

关键是把建议、证据和决策分层。Agent 可以提出候选问题，确定性工具负责复现或静态验证，作者负责修复或说明，最终 reviewer 结合风险做合并决定。每一层都保留自己的身份和证据，避免一条模型评论在系统中被误认为事实。

把评论按证据等级输出

一条高质量的 Agent 评论至少包含位置、规则或推理、影响范围、复现方式和置信级别。可以分为三类：已有工具证据的确定问题，如类型检查错误或测试失败；需要人工判断的设计风险，如缓存失效路径；以及低置信建议，如命名或可读性。只有第一类可以自动标记为必须修复，其余必须明确显示为建议。

评论不要只说“可能存在 bug”。更好的格式是：“在 x.ts:42，当输入为空时 parse() 抛异常；新增的测试 case-empty 可复现；建议在边界返回 400。”这样作者能快速确认，reviewer 也能判断 Agent 是否真的理解了变更。

作者或修复 Agent 接收到评论后，不应无限循环修改。每个回合绑定基线提交、评论 ID、允许修改的路径和验证命令。修复后重新运行相关检查，若 diff 超出原问题范围，则回到审阅而不是偷偷扩大变更。这样能避免一个简单 lint 建议引发大规模重构。

对于无法复现的评论，作者应标记原因并附证据，例如调用方已经在更高层校验、该分支受 feature flag 限制、或测试环境缺少依赖。Agent 可以根据新证据重新评估，但不能自行关闭高风险问题。关闭动作和理由需要保留给人类审计。

大型 PR 中，Agent 可能在同一个根因上留下二十条相似评论。合并器应按文件、规则和数据流聚类，优先报告根因和最小复现路径。设置每个 PR 的建议上限和重要性阈值，超过后输出摘要而不是继续刷屏。评审体验变差时，团队会关闭工具，最终失去最有价值的信号。

还要保护敏感信息。Agent 的评论、补丁和日志不应包含 access token、用户数据或内部 URL。把 PR 内容发送给外部模型前，明确仓库允许范围、数据处理政策和脱敏规则；对私有依赖或安全修复采用受控模型或人工流程。

有价值的指标包括：被确认的问题比例、修复后复发率、误报率、从评论到决策的时间、每类规则的覆盖收益。评论数越多不代表质量越高；如果大多数评论被忽略，说明提示、规则或上下文选择需要调整。

上线验证可以选一组已知缺陷 PR 和一组正常 PR。目标是 Agent 能在前者给出可复现证据、在后者保持低噪声。之后再把特定高置信规则接入合并门，而不是一次性让模型控制全部发布流程。

模型、提示词、检索规则和静态分析器升级后，评论风格与覆盖范围都会变化。为审查配置设置版本号，并在灰度仓库或影子模式中比较新旧版本的命中、误报和耗时。不要在全组织 PR 上直接切换一个未经校准的新模型，然后把噪声成本转嫁给开发者。

对每个规则保留停用开关和负责人。当某条规则产生大量无效评论时，可以快速退回建议模式，同时收集样本修复。对安全或数据风险规则，则要求升级前后都使用已知缺陷集验证。这样 AI 评审是一个可运营系统，而非不可解释的旁路意见来源。

每周复盘一次被采纳和被驳回的评论，按规则、仓库和风险等级抽样检查。把被证实的误报转成回归样本，把漏掉的真实缺陷补进测试集，才能让评审质量随项目演进而提升。

复盘报告要包含规则版本、模型版本和触发上下文，避免把环境变化误判为模型能力变化。对误报率突然上升的规则先停止阻断，再定位是上下文缺失、代码模式变化还是提示词回归。