提议者-审核者范式包含哪两种机制？
- 来源: 用独立的第二视角检验第一视角的产出;
- 事前审批: 在工具执行前，一个模型负责提议行动（Proposer），另一个独立的模型负责审查并批准（Reviewer）——就像银行的经办、审核双签制度，转账指令须经两道签字才能生效;
- 事后验证: 在操作完成后，由审核视角检验结果的正确性;
- 前提: 输入验证与权限控制之外，不可逆的关键操作还需要更智能的审查机制，见 执行工具的安全分层;
两个模型应如何搭配？
- 家族: 提议模型和审批模型应来自不同的家族（如 GPT 系列和 Claude 系列），以引入认知多样性——不同知识背景与思维习惯的模型不太可能在同一个地方犯同样的错;
- 反例: 同家族模型（如都是 GPT）训练数据和偏好相似，容易在相同场景下犯相同错误;
- 能力: 两者应处于相似的能力水平，审批模型才能理解提议模型的思考；相差过大反而不可靠（如 Haiku 审查 Opus 的输出，审查者跟不上被审者）;
- 理想配对: 能力相近但训练偏好不同，例如 Claude Opus 5 与 GPT-5.6 Sol 互审，或 Kimi K3 与 DeepSeek V4 Pro 互审;
提示词设计要注意什么？
- 一致: 两个模型的底层规则和约束必须完全一致，上下文也需要一致，否则会互相扯皮、陷入僵局;
- 差异: 关注点应有所差异——提议模型强调行动导向和任务完成，审批模型强调风险控制和规则遵守;
审批拒绝后应如何处理？
- 做法: 不应简单重试，而应把拒绝理由作为工具调用结果加入 Agent 的轨迹;
- 视角: 从提议模型的视角看，审批拒绝就像一次工具调用失败返回了错误信息和修正建议;
- 依据: Agent 已经具备处理工具失败的能力，审批机制只是一个新的输入源;
事前审批适合哪些操作？
- 判据: 任何不可逆的、影响重大的操作都可从事前审批中受益;
- 例子: 收费、发送通知和邮件、修改关键配置、创建外部资源;
- 共同特征: 操作后果持久、错误成本高昂，值得投入额外的计算资源进行审查;
- 优化: 风险分级审批（高风险操作总是需要审批，低风险的直接执行）；无法确定时升级至人工审核;
事后验证的关键是什么？
- 要诀: 模态切换——不是让第二个模型重读相同的内容再审一遍，而是在不同的模态下检验结果;
- 例子: Agent 生成基于代码的文档后，将其渲染为视觉输出再检查排版是否正确；修改配置文件后，在沙盒中实际运行验证配置是否生效;
- 依据: 不同的模态提供互补的验证视角，单一模态的审查很容易陷入相同的盲区;