Gemini 2.5 Pro + Agent = IMO 金牌：Actor-Critic Workflow

LaTeX 源码 · 备用 PDF · 观看视频

字段	内容
作者/整理	基于公开课程资料整理
来源	五道口纳什
日期	2025

工作背景与核心发现

令人振奋的结果

本期介绍了一篇对作者启发极大的工作：原生 Gemini 2.5 Pro（非 DeepMind 官方 tune 过的版本）通过精心设计的 Agent Workflow，求解了 IMO 2025 六道题中的前五道，达到人类金牌水平。

核心发现

关键词是 capable——模型本身有能力解决这些极其困难的数学问题，此前表现不佳是因为没有通过合适的 Workflow 来最大化激发模型的潜力。这对 Agent 设计的启示是巨大的。

本章小结

这一工作证明了 Agent Workflow 设计的重要性：同样的模型，不同的 Workflow 可以带来质的飞跃。

完整 Workflow 流程

六步流程

Step 1：初始求解——基于 Prompt 和 Gemini 2.5 Pro 产生一个初始解
Step 2：Self-Improvement——共享 Step 1 的上下文，继续 refine（因为 Step 1 可能因 Thinking Budget 耗尽而仓促结束）
Step 3：Verification——对 Step 2 的解进行验证，输出 verdict（有效/无效）和 bug report
Step 4：Bug Report——提取具体的错误位置和原因
Step 5：Correction——基于 bug report 修正 solution
Step 6：循环——Step 3-5 不断循环

终止条件

接受：某个 solution 连续 5 次通过 verification \(\rightarrow\) 认为解决了问题
拒绝：循环 10 次仍未通过 \(\rightarrow\) 放弃当前方向，重新 sample

Evaluator-Optimizer 模式

与 Building Effective Agents 中的经典模式对应

这个 Workflow 本质是 Evaluator-Optimizer 模式：

Generator（生成器）产生 solution
Evaluator（评估器）验证并给出 feedback
接受则输出，拒绝则基于 feedback 重新生成

初始解质量的决定性作用

成功的关键在于初始解

如果 Step 2 生成的初始解与正确解有较大的 overlap，那么经过后续的验证-修正循环大概率能最终 solve 问题。但如果初始解的方向就是错的（偏差太远），后续的纠正大概率救不回来。

本章小结

整个 Workflow 是一个标准的 Generate-Verify-Correct 迭代循环，终止条件基于连续通过/失败次数的计数。

Step 1 Prompt 分析：生成初始解

Prompt 结构

Step 1 的 System Prompt 是一个标准的结构化 Markdown 文本，分为三部分：

核心指令：
严谨性至关重要（IMO 大部分是证明题，最终判据是逻辑严谨性）
诚实对待结果——不要硬凹（避免 Reward Hacking）
全文使用 LaTeX
输出格式（Adaptive Prompt）：
Summary：包含 Verdict（是否找到完整方案）和方法概述
Detailed Solution：详细的解决方案
Self-Verification 指令

输出格式的设计意图

Verdict 用于分支判断

Summary 中的 Verdict 不仅是信息展示，更是后续 Workflow 的分支判断依据——如果 Verdict 为 false（未找到完整解），则跳过后续验证，直接重新 sample。Detailed Solution 则送入 Verification 环节。

本文代码使用正则表达式提取这些结构化输出（而非结构化输出 API），因为 Gemini 2.5 Pro 的指令遵循能力足够强。

Step 2：Self-Improvement

Step 2 与 Step 1 共享上下文。其 Prompt 很简单：“你有一个机会改进你的结果——仔细 review 你的 solution，纠正错误，填充 justification gap。”

引入 Step 2 的原因是 Step 1 中 Thinking Budget（32768 tokens）可能被打满，模型被迫仓促结束思考。Step 2 给予模型继续思考的机会。

本章小结

Prompt 设计的精髓在于：结构化输出为后续 Workflow 的分支判断和数据流向提供了基础。

Verification Prompt 分析

Verifier 的角色与指令

Verification 的 System Prompt 同样是结构化 Markdown，包含：

角色扮演：你是卓越的数学家，IMO 级别严谨的审阅人
核心说明：你仅仅是 Verifier，不是 Solver——不要尝试纠正错误或填充 gap，只需 step by step 验证
问题分类：
Critical Error：严重逻辑错误（如 \(A > B, C > D\) 推出 \(A-C > B-D\)）
Gap：跳步、逻辑断裂
输出格式：Summary（含 Verdict：valid/invalid）+ List of Findings（bug report）+ Detailed Verification Log

Verifier 不应尝试解题

Verification Prompt 明确要求 Verifier 不要尝试纠正错误或填充 gap，只做验证。这种角色分离是 Workflow 设计的关键——Generator 和 Verifier 各司其职。

本章小结

Verification Prompt 通过严格的角色定义和结构化输出格式，确保 Verifier 只做验证、不做求解，其输出的 Verdict 和 Bug Report 驱动后续的 Correction 和循环终止判断。

Correction 与迭代循环

Correction 环节

当 Verifier 判定 solution 无效时，提取 bug report 送入 Correction 环节：

输入：原始问题 + 当前 solution + bug report
Prompt：“Below is a bug report. If you agree with it, fix the issues. Your output should follow the system prompt instructions.”
输出：修正后的新 solution

完整迭代流程

以第一道题为例：

初始探索：Step 1 + Step 2 生成初始解
验证：Verifier 判定 No（有 bug）
纠正：基于 bug report 生成新解 \(\rightarrow\) 验证 No \(\rightarrow\) 纠正 \(\rightarrow\) 验证 No
第 4 次纠正后通过验证：correct count = 1
连续验证通过 5 次，最终接受
共经历 8 次迭代，外部循环仅 1 次 run

本章小结

整个迭代循环展示了 Actor-Critic 模式的强大：即使初始解有多处错误，通过反复的验证-纠正循环，最终可以收敛到正确解。

Gemini API 使用注意事项

技术细节

Gemini API 的角色是 system / user / model（而非 system / user / assistant）
Thinking 输出是 summarize 后的结果，不是原生的 thinking 过程
Thinking Budget 设置为 32768 tokens，但实际有时会达到 34000+（控制不严格）
由于 Thinking 过程很长（数万 token），使用 HTTP Request 容易超时，建议使用 SDK + Streaming

总结与延伸

Generate-Verify-Correct 循环是一个强大且通用的 Workflow 模式，本文在 IMO 问题上的成功验证了其有效性。
初始解质量决定成败：如果初始解方向正确（与标准解有较大 overlap），后续循环大概率能修正细节；如果方向错误，则难以纠正。
Prompt 设计是 Workflow 的灵魂：结构化的输出格式为自动化的分支判断和数据流转提供了基础。
角色分离：Generator 只管生成，Verifier 只管验证，Corrector 只管修正——各司其职是 Multi-Agent 设计的核心原则。
Agent 设计的价值：同样的模型（Gemini 2.5 Pro），通过 Workflow 设计可以从"做不出"变为"金牌水平"。