OpenAI 公开 62 页核心手稿这件事最近在数学界和 AI 圈都引起了不小的讨论。比起“AI 又刷榜了”这种新闻式结论我更关心的是手稿里到底写了什么AI 是怎么一步步处理这些顶级难题的以及作为普通开发者我们能不能借鉴这套思路在自己的数学计算、公式推导、算法验证场景里复现类似的能力这篇文章不打算做成新闻复述而是把手稿事件拆成技术问题来讲先梳理事件脉络和“菲尔兹奖级难题”到底意味着什么再深入拆解大模型做数学推理的底层逻辑最后给出一套可运行的数学 Agent 工程示例包含代码、配置、验证流程和常见坑点。如果你平时用 AI 做数据分析、算法推导、论文复现或者正在研究 Agent 工作流这篇文章会比较对胃口。1. 背景与核心概念1.1 OpenAI 核心手稿是什么根据公开报道OpenAI 发布了一份约 62 页的技术手稿内容围绕 AI 在高级数学推理上的能力展开。手稿的核心信息是AI 系统在一批数学难题上取得了突破性进展其中一部分问题被认为具有“菲尔兹奖级”难度。菲尔兹奖是数学界最高荣誉之一每四年颁发一次授予 40 岁以下青年数学家。能在菲尔兹奖级别的问题上取得进展意味着 AI 不再只是处理“鸡兔同笼”这类规则明确的题目而是开始触及人类数学研究的边界。需要说明的是“菲尔兹奖级”并不等于“已经获得菲尔兹奖”。它更合理的理解是这些问题的难度和研究价值达到了该级别AI 对其中一部分问题提出了新的解法路径或实质性突破。至于这些问题是否经过同行评审、是否被学术界正式认可还需要等待后续验证。1.2 什么是“十大菲尔兹奖级难题”公开报道中提到“连破十大难题”这里的“十大”实际上是一个泛指而非严格的学术分类。数学界真正有明确定义的难题清单包括千年大奖问题Millennium Prize Problems共 7 个每个悬赏 100 万美元。希尔伯特 23 问题Hilberts 23 Problems1900 年提出的 23 个核心问题。各国数学会或研究机构发布的开放问题列表。AI 解出的“十大难题”更可能是从这些经典问题中挑选出来的、适合用计算和推理方法攻克的子问题而不是把黎曼猜想、P/NP 问题全部解决。这种区分很重要否则容易对 AI 能力产生不切实际的预期。1.3 为什么这件事值得开发者关注我们容易觉得“数学难题离工程太远”。但实际上AI 能在数学推理上取得进展直接影响了三个工程方向第一AI 的推理能力决定了它能不能处理多步骤、长链条的逻辑任务。过去大模型擅长生成文本但经常在 5 步以上的逻辑推导中出错。数学推理恰好是最严格的逻辑测试。第二数学 Agent 的工作流可以被迁移。AI 解决数学问题时的“假设生成 形式化验证 反例搜索 结果修正”流程和代码调试、系统故障排查、算法设计的工作流高度相似。第三AI 辅助数学研究正在成为新的生产力工具。无论是自动生成证明思路、辅助符号计算还是快速搜索反例都能显著降低数学和算法研究的时间成本。2. 事件脉络与关键技术点2.1 手稿公开的学术意义公开手稿本身是一个值得肯定的动作。AI 研究有一个常见问题只公布“我们解出来了”但不公布“我们怎么解出来的”。这使得外界无法判断结果是真实突破还是偶然巧合。OpenAI 的做法是把推理过程、实验设计、失败案例、局限性全部写进 62 页手稿。这种透明度对学术研究非常重要因为数学是一个极度依赖“可验证性”的学科。如果 AI 给出的证明无法被独立验证那么即使结论正确也缺乏学术价值。从工程视角看这种“手稿式复盘”也值得开发者学习。我们在做技术方案时如果把“调试过程”“失败路径”“边界条件”一起记录下来整个团队的可维护性会好得多。2.2 AI 解数学题的核心技术路径根据目前公开的信息AI 解决高级数学问题通常遵循以下技术路径第一步是问题理解与形式化。把自然语言描述的数学问题转换成形式化语言。这里的“形式化”意味着每个符号、每个逻辑关系都有严格定义不能有歧义。Lean、Coq 等证明助手是常用的形式化工具。第二步是假设空间搜索。大模型基于已有的数学知识生成若干候选解题方向。这个过程类似程序员在 Stack Overflow 上找思路不一定第一个方向就对但需要快速枚举。第三步是自动验证与反例搜索。对每个候选结论利用符号计算工具和证明助手进行验证。如果某个假设被反例推翻就返回第二步重新生成。第四步是人工专家审阅。AI 的推理链最后仍需要数学专家确认避免“形式上正确、实质上无意义”的证明。这条路径最大的特点是“人在环上”而不是“AI 全自动”。手稿中强调的也应该是人类专家和 AI 协作的过程。2.3 为什么数学是 AI 推理的“最佳试验场”数学是一个适合测试 AI 推理能力的领域原因有三点数学有绝对正确性。一个证明要么对要么错不存在“大概对”。数学问题可以被形式化验证。Lean、Coq 等工具可以自动检查证明的正确性。数学难题的复杂度可控。难题虽然难但拆解后的子问题往往可以在有限步骤内验证。这些特性让数学成为大模型推理能力的“体检报告”。如果 AI 能在数学上表现稳定那么在代码生成、逻辑设计、数据分析等场景中其可靠性也更值得期待。3. 大模型数学推理能力拆解3.1 大模型并不是真的“会算”先说一个比较容易误解的地方大模型本质上是一个基于概率的文本生成系统。它并不是在 CPU 上执行数学运算而是在“预测下一个 Token”的过程中通过大量训练数据学到了数学符号和逻辑关系的统计规律。这带来一个结果对于已经见过的题目它可以“背诵”出答案对于没有见过的新题它需要“推理”。两者的分界线并不清晰导致大模型在数学题上经常出现“看起来很有道理结果完全错误”的情况。所以在使用大模型做数学推理时必须把它当作“假设生成器”而不是“答案生成器”。真正的计算和验证工作应该交给符号计算库和证明助手。3.2 Token 级推理与思维链现代大模型在数学推理上的进步主要来自“思维链”技术的应用。简单来说思维链就是让模型在给出答案前先生成中间推理步骤。这种设计思路和人类解数学题一致先写“因为……所以……”再跳到下一步而不是直接蹦答案。对模型来说中间步骤给了它更多“思考”空间也更容易在长链条推理中保持逻辑一致。但思维链不是万能的。当步骤超过一定数量后模型还是会“遗忘”前面的条件或者产生幻觉编造出不存在的定理。因此在实际工程中长推导必须分段验证而不是相信一整条完整的思维链。3.3 搜索与验证AI 解决难题的隐藏王牌公开手稿透露的一个更重要的方向是AI 不再只是“生成答案”而是结合了搜索和验证机制。搜索指的是在证明空间中尝试不同的推理路径。验证指的是每一步推导都用自动化工具检查。这两者的结合使得 AI 能够“尝试许多条路然后选择被验证通过的那条”。这种模式在代码领域其实已经成熟了类似“生成测试用例 运行测试 修正代码”的 TDD 循环。数学 Agent 就是把这个循环搬到了数学领域。4. 实战搭建一个数学问题研究 Agent4.1 环境准备与版本说明为了让你能直观感受“假设生成 符号验证”这套流程这里提供一个最小可运行的数学 Agent 示例。环境建议操作系统Windows / macOS / Linux 均可Python 版本3.9 及以上依赖库openai、sympy、python-dotenv安装命令pip install openai sympy python-dotenv说明openai 库的版本会持续更新不同版本的 API 调用方式略有不同。本文以 openai 库的通用调用接口为例重点是演示工作流不是绑定某个特定版本。如果你使用的是其他大模型 API只要它兼容 OpenAI 接口协议示例代码的调整成本会很低。4.2 创建项目结构建议按下面的目录结构组织文件math-agent/ ├── .env ├── solver.py ├── verify.py └── main.py.env存放 API 密钥solver.py负责调用大模型生成解题思路verify.py负责用符号计算验证结果main.py串起整个流程。4.3 配置环境变量在.env文件中填入你的 API Key 和模型名称OPENAI_API_KEYsk-你的密钥 OPENAI_MODELgpt-4o注意API Key 是敏感信息不要提交到 Git 仓库。建议在.gitignore中加入.env文件。获取 API Key 的官方途径是 OpenAI 开发者平台在账号后台创建密钥即可。不要把密钥硬编码在代码中更不要分享给他人。4.4 编写核心代码先看solver.py。它的作用是把数学问题发送给大模型要求模型给出分步推理而不仅仅是最终答案。# 文件路径math-agent/solver.py import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) def generate_solution(problem: str) - str: prompt f 你是一位数学研究助理。请解决下面的问题并给出分步推理过程。 要求 1. 先重述问题确认你理解了题目。 2. 列出所有已知条件和目标。 3. 给出每一步推导并说明使用的定理或公式。 4. 如果某个步骤存在不确定性请明确标注。 5. 最后给出结论并说明结论的适用范围。 问题如下 {problem} try: response client.chat.completions.create( modelos.getenv(OPENAI_MODEL), messages[ {role: system, content: 你是一个严谨的数学推理助手注重可验证性和逻辑完整性。}, {role: user, content: prompt}, ], temperature0.2, max_tokens2000, ) return response.choices[0].message.content except Exception as e: return f调用模型时发生错误{e} if __name__ __main__: demo_problem 证明对于任意正整数 nn^2 与 n 的奇偶性相同。 print(generate_solution(demo_problem))这里的temperature0.2很重要。数学推理需要确定性过高的 temperature 会让模型给出各种奇怪的推导方向。我们鼓励模型在“候选思路生成”阶段有创造性但在“直接解题”阶段保持低温度。再看verify.py。它的作用是使用 sympy 对问题的结论进行符号验证。以“n^2 与 n 的奇偶性相同”为例可以构造一个简单的验证脚本。# 文件路径math-agent/verify.py import sympy as sp def check_parity_property(): n sp.Symbol(n, integerTrue, positiveTrue) # 判断 n^2 和 n 的奇偶性是否相同 # 方法验证 n^2 - n 是否为偶数 expr n**2 - n # 化简表达式看是否能被 2 整除 # 注意这里使用 sympy 的简化逻辑演示用 try: simplified sp.simplify(expr) print(fn^2 - n 的化简结果{simplified}) # n^2 - n n(n-1)两个连续整数乘积必为偶数 # 这是一个恒等式不依赖 n 的具体取值 print(结论n^2 - n n(n-1)两个连续整数乘积一定是偶数。) print(因此 n^2 与 n 的奇偶性相同。) except Exception as e: print(f验证过程中出现错误{e}) if __name__ __main__: check_parity_property()这个例子比较简单但已经能体现“大模型生成思路符号计算库做验证”的核心模式。在真实的高级难题中验证环节会使用 Lean、Coq 或更复杂的自定义验证器而不是 sympy 就能解决的。4.5 串联完整流程在main.py中我们把两个模块串起来# 文件路径math-agent/main.py from solver import generate_solution from verify import check_parity_property def main(): problem 证明对于任意正整数 nn^2 与 n 的奇偶性相同。 print( * 40) print(第一步调用大模型生成推理过程) print( * 40) solution generate_solution(problem) print(solution) print(\n * 40) print(第二步使用符号计算验证关键结论) print( * 40) check_parity_property() if __name__ __main__: main()运行python main.py预期输出分两部分大模型给出的文字推理以及 sympy 验证的结论。这里的关键不是让大模型自己“证明”正确而是让验证器确认结论。4.6 扩展到更难的问题如果你想把这套工作流扩展到更复杂的数学问题上核心改动在验证器层面。大模型的部分可以保持相对通用但验证器必须针对具体问题定制。一个可复用的流程可以是用大模型生成候选定理和证明思路。将数学问题形式化为 Lean 语言。用 Lean 验证器检查证明是否通过。如果 Lean 报错把错误信息反馈给大模型让它修改证明。循环执行直到验证器通过或达到最大迭代次数。这种循环就是 OpenAI 手稿中强调的“搜索 验证”思想的一个简化实现。5. 常见问题与排查思路5.1 模型输出的数学推导看起来正确但实际是错的这是最常见的问题。原因是模型擅长模仿正确的推导风格但不保证每一步都真实有效。排查思路不要只读推导过程要逐行用验证器检查。把大模型输出中的“关键结论”单独提出来用 sympy、Mathematica 或 Lean 验证。如果验证失败检查是哪一步开始出现逻辑断裂把这个错误反馈给模型并要求修正。5.2 模型在长推导中“忘记”前置条件当推导步骤超过一定数量时模型可能忽略前面已经设定的条件导致结论适用范围扩大。解决方案将问题拆分成多个子目标每个子目标单独调用一次模型。在每一步 prompt 中重复完整的问题和当前已知条件减少“遗忘”概率。显式要求模型在每一步都引用前置条件例如“根据条件 (1) 和 (2)可得……”。5.3 API 调用被限流或超时原因可能是请求频率过高或者单次请求 token 数设置过大。解决方案在代码中加入 retry 机制遇到限流错误后等待一段时间重试。降低max_tokens或使用流式输出。设置合理的并发数不要一次性发送大量请求。下面是一个简单的重试示例import time from openai import OpenAI client OpenAI() def call_with_retry(prompt, max_retries3): for attempt in range(max_retries): try: response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], max_tokens1000, ) return response.choices[0].message.content except Exception as e: print(f第 {attempt 1} 次调用失败{e}) if attempt max_retries - 1: time.sleep(2 ** attempt) return None5.4 验证器报错但不确定是模型问题还是验证器问题这种情况经常出现在自定义验证器不完善的时候。排查思路先用一个已知正确的数学结论测试验证器本身。如果验证器能通过正确答案说明问题出在模型输出。如果验证器连正确答案都报错说明是验证器的逻辑或语法有问题需要先修复验证器。5.5 模型生成的“候选思路”过于发散当 temperature 设置过高时模型会生成创新但难以验证的思路。解决方案把温度降低到 0.2 以下。在 prompt 中限制候选思路数量要求“只给出优先度最高的两条路径”。采用“多模型投票”策略让多个模型分别推理选择结果一致的方案。6. 最佳实践与工程建议6.1 明确 AI 的定位假设生成器而非答案机在整套数学 Agent 工作流中AI 最擅长的是“提出可能正确的假设”和“生成待验证的证明路径”。一旦涉及到精确计算、逻辑穷举、反例搜索应该交给传统算法和验证工具。这套分工既发挥了模型的长处也规避了模型的短板。6.2 验证器是系统的核心不是附属品如果验证器不完善整个 Agent 的可信度都会崩塌。建议在编写验证器时做到验证器必须足够严格不接受“看起来正确”的推导。对每个验证规则编写测试用例确保验证器本身可信。在验证失败时记录具体失败原因方便反馈给模型修正。6.3 保留完整日志与轨迹数学 Agent 的调试非常依赖完整轨迹。建议记录每次模型请求的 prompt 和 output。验证器的检查和报错信息。每次迭代修改了哪些内容。最终被验证通过的是哪条证明路径。这些日志既方便复现结果也是判断“AI 是否真的解决了问题”的重要依据。6.4 设置合理的安全边界这里的“安全”指两方面。一是数据安全不要轻易把未公开的科研数据发送给外部 API二是内容安全对模型的输出保持批评态度不能盲目相信 AI 声称的“已证明”。在处理涉及版权、专利、学术成果归属的实际项目时还应该遵守相关法律法规并保留人工专家的最终审阅权。AI 的推断不能替代正式学术评审。6.5 从小问题开始逐步扩大范围不要一上来就尝试让 AI 解决“黎曼猜想”。正确的方式是从“可验证、有难度、但研究边界清晰”的问题入手。建议路线先做中学数学题的自动化推导。再做本科数学课本中的经典定理证明。然后尝试公开论文中已经证明的引理。最后才探索“研究级”的新问题。每一步都比前一步增加一点“不确定性”但至少验证器可以兜底。7. 下一步学习方向如果这篇文章的内容让你对 AI 数学推理产生了兴趣下一步可以按下面几个方向深入。第一个方向是学习证明助手 Lean。OpenAI 手稿中提到的方法论大量依赖形式化验证而 Lean 是目前最活跃的证明助手之一。掌握 Lean 的基本语法你就能把自己关心的数学命题转换成机器可验证的代码。第二个方向是研究 Agent 的搜索策略。单纯调用一次大模型往往不够真正的数学 Agent 会像下棋一样搜索多条证明路径。你可以从最简单的“深度优先搜索 验证剪枝”开始逐步加入更复杂的启发式策略。第三个方向是关于“Reasoning Models”的资料。OpenAI 后续发布的多款推理模型在处理数学、编程、逻辑推理上都有针对性优化。不同模型的 API 参数和调用方式存在差异使用时需要以官方文档为准。最后我想说一句AI 破解数学难题并不是要取代数学家而是为数学家提供一套“高速试错 自动验证”的辅助工具。对于开发者来说这套“生成假设、自动验证、失败反馈、循环迭代”的范式也完全可以迁移到代码重构、系统调优、故障排查等日常工作中。技术更新很快但“严谨验证、动态修正”这个核心思路不会过时。
