Issue 背景

你有没有遇到过这种情况：

AI 帮你进行代码审查，一次生成了多条评论。

但是仔细查看后发现：

评论 A：
“这里可能存在空指针风险。”

评论 B：
“这里可能导致 NullPointerException。”

两条评论看起来不同，
实际上表达的是同一个问题。

对于开发者来说，重复提醒不仅增加阅读成本，
还可能让真正重要的问题被忽略。

最近我看到 GitHub 上一个开源项目的 Issue，
讨论的正是 AI Agent 输出近重复评论的问题。

最近我看到一个 GitHub Issue，它讨论的正是 Agent 输出中出现近重复评论的问题。
GitHub 上 alibaba/open-code-review 仓库的 Issue #709 标题为“Near-duplicate comments in json output for agent”，原始地址：https://github.com/alibaba/open-code-review/issues/709

什么是重复评论？

简单理解：

AI Code Review 输出：

评论1：
这里可能存在空指针风险。

评论2：
这个地方可能导致 NullPointerException。

两句话表达的是同一个问题。

如果系统不知道它们相似，
开发者就会看到重复提醒。

已知现象与边界

“近重复”可能指文本相似，也可能指含义接近。输出中可能存在文本或含义接近的评论，但这些评论是否针对同一缺陷，仍需结合复现样例确认。它是否增加阅读成本、造成问题数量误判，也只是可能的影响，不能当作该 Issue 已证实的结果。

可能原因，尚未验证

如果该项目采用常见的模型生成、解析和聚合流程，重复可能出现在多个阶段；现有材料尚不能确认其实际实现。一种可能原因是模型在单次响应中给出相近表述；另一种可能是多轮分析重复覆盖同一区域；也可能是结果聚合时没有合适的幂等约束。以上均为假设，仍需结合源码验证。

为什么 AI Agent 容易产生重复评论？

一种常见情况是：

AI Agent 并不是一次完成全部工作。

它可能经历：

1. 分析代码
2. 生成问题
3. 整理 JSON 输出
4. 合并多个分析结果

如果不同阶段没有统一规则，
同一个问题可能被记录多次。

例如：

第一次分析：
发现 user 参数可能为空。

第二次分析：
发现 user 访问时可能出现空指针。

对于系统来说，这是两条结果；
对于开发者来说，可能只是一个问题。

候选解决思路

可以先区分精确重复与近重复。对精确重复，可考虑规范空白、换行和路径表示，再生成稳定键。对近重复，应先缩小比较范围，再评估文本相似度，避免只因措辞相近就误删不同问题。

若项目输出包含文件路径、代码位置、问题类型和评论正文，可用这些假设字段限定候选范围。例如，只比较同一文件、相邻位置且类型相同的评论。阈值不应预设为“最佳值”，而应通过真实样本评估误删和漏删。

在确认项目处理链路后，可评估是否在结构化字段完成解析和校验之后、输出之前执行去重。这只是候选接入点，不代表仓库已有对应阶段，也不代表方案已经适配。

示例代码，仅展示思路。

comments = get_comments()

groups = group_by(
    file_path,
    line_number
)

for group in groups:
    remove_exact_duplicate(group)
    check_similarity(group)

验证清单

以下均是待执行的验证设计，不是已完成测试：

• 获取 Issue 正文、评论和最小复现输入。
• 检查实际 JSON 字段、生成入口及聚合逻辑。
• 验证完全相同的评论能否稳定识别。
• 检查不同文件中的相似评论是否被误删。
• 检查同一位置的不同风险是否都能保留。
• 用真实样本评估阈值，并确认输出是否需要稳定排序。

总结

AI Code Review 的目标不是生成更多评论，
而是帮助开发者更快发现真正重要的问题。

当 Agent 输出出现重复结果时，
解决方向通常不是简单删除一条评论，
而是理解整个生成链路：

• 评论在哪里产生？
• 多个结果如何合并？
• 如何判断两个问题是否真的相同？

这个 GitHub Issue 提醒我们：

AI Agent 的效果不仅取决于模型能力，
也取决于后面的工程设计。

好的 Agent，需要的不只是生成能力，
还需要结果整理和质量控制能力。