address-review

分流是一个分类环节：每条发现都必须先确定一种处理方式，之后才能采取行动。

1. 获取评审

评审是一组发现，可能来自人工或其他 Agent，并以文件、PR（或 PR 评论）或会话上下文的形式提供。按以下优先顺序，从第一个可用来源获取：用户指出的来源；本次会话中已有的评审；当前分支对应的开放 PR；否则询问用户。

将每条发现收集到一个列表中。完成标准：来源中的每条发现都已列入列表。

2. 分流每条发现

根据每条发现本身的内容，以及你已掌握的信息来判断。

将每条发现概括为一行，并提供适用的处理方式供用户选择（AskUserQuestion——每个问题对应一条发现，每次调用最多批量处理四个问题）。选择适用的处理方式，并将你推荐的选项放在首位。

• 修复 — 发现有效，应该修复。如果评审建议了修复方案，或你能明确判断出方案，请说明该方案；如果存在多种可行方案，则追问用户选择。
• 不修复 — 发现无效，或你不会对此采取行动。
• 说明 (临时) — 用户想了解此问题；你将阅读代码并作出说明。
• 调查 (临时) — 你将阅读代码，确认问题是否成立。
• 延期 — 发现有效，但将作为单独工作处理（另一个任务或 issue）。

阅读代码以判定某条发现本身就是一种处理方式——它是临时处理方式，需要现在选择，并在第 3 步执行。

完成标准：每条发现都已确定处理方式。

3. 处理每条发现

同时推进两条工作线：

• 前台 — 临时处理方式只会带来理解，不会产生最终结果；需要将其解决：探索代码（每条发现安排一个子 Agent），汇报结果，并与用户重新分流每条发现（如第 2 步所述），将其归入最终处理方式——修复、不修复或延期。
• 后台 — 处理每条与所有待定临时事项均独立的最终发现：实施修复（修复涉及不同代码时，每条发现安排一个子 Agent），或为延期事项创建 issue。随着重新分流得出新的最终处理方式，也要处理这些发现。

完成标准：所有修复均已完成，所有延期事项均已登记。

4. 完成闭环

提交更改。编写总结，为每条发现列出一行，说明其处理方式及已采取的行动。如果评审来自 PR，则推送分支，将总结作为评论发布，并标记评审已解决；否则，将总结告知用户。

最后建议是否需要进行后续评审。完成标准：总结已送达；如果来自 PR，则所有讨论线程均已解决。