代码审查

找出会影响用户结果的真实问题，并核实证据。仅要求 review 时交付发现，不直接修改代码。

梳理需求与改动

触发 review 后，主 Agent 先整理清楚本次改动要解决什么问题、预期行为是什么，以及要审查的范围，作为交给审查者的共同背景：

• 用户原始需求、后续确认的调整、验收条件与项目规则。
• 目标仓库与工作区、本次改动范围及对应版本，明确是工作区改动、某个提交、分支差异还是 PR，并提供可读取的 diff。
• 必要的原始材料，如问题复现条件、相关输入与检查结果。

背景应足以让未参与实现的审查者自行判断，不夹带主 Agent 的实现推理、原因猜测或正确性结论。

交给独立 Agent 审查

主 Agent 将上述背景交给独立的审查 Agent。默认使用一个；用户要求多个时并行审查，指定数量时按指定数量执行，未指定数量时按改动范围安排。多个审查者使用相同的需求与目标版本，可分别关注需求实现、调用链与回归风险，独立形成发现后再汇总。

审查 Agent 使用独立上下文，不继承主 Agent 的完整对话和实现过程，自行读取代码并判断。使用当前环境提供的委派能力，不限定客户端、模型、工具名称或调用参数。