智能体框架如何赋能大语言模型进行形式化数学证明

1. 项目概述：当大语言模型遇上形式化数学

最近在AI和形式化验证的交叉领域，一个名为“LEAP”的项目引起了我的注意。这个标题“LEMP: Supercharging LLMs for Formal Mathematics with Agentic Frameworks”本身就充满了信息量。简单来说，它探讨的是如何利用一种名为“智能体框架”的架构，来“超级充电”大语言模型，使其在形式化数学这个公认的硬核领域里，从“能说会道”的聊天伙伴，变成能真正“动手干活”的证明助手。

形式化数学是什么？你可以把它想象成用计算机能严格理解的“代码”来书写数学。我们平时在纸上写的证明，充满了“显然”、“易得”这样的人类直觉跳跃，但计算机无法理解这些模糊性。形式化证明要求每一步推导都基于明确的公理和推理规则，精确到每一个逻辑连接词。这既是数学严谨性的终极体现，也是一个极其繁琐、对人力消耗巨大的工程。而大语言模型，比如我们熟知的GPT、Claude等，在理解和生成自然语言、代码方面展现了惊人能力，但在需要绝对精确和长链条、结构化推理的形式化数学面前，常常显得力不从心——它们可能会“幻觉”出看似合理但逻辑错误的步骤，或者无法在漫长的证明中保持前后一致。

“LEAP”项目的核心洞察就在于，单靠一个“大模型”单打独斗是不行的。它需要被重新组织，赋予一个更强大的协作系统。这就是“智能体框架”的用武之地。这个框架不是简单地让模型一次性生成整个证明，而是将其能力分解、协调，模拟一个数学家或证明工程师的思考和工作流程：先理解问题，再制定策略，然后尝试各种战术，遇到错误时能回溯反思，最终一步步构建出完整的、机器可验证的证明。这就像给一个博学但有时会走神的天才学生配了一个严谨的教练、一个细心的书记员和一个不知疲倦的检验员组成的团队。

这个方向的价值巨大。它不仅能加速数学研究本身（例如，帮助数学家验证复杂猜想或探索新的证明路径），更是通向更可靠、可解释的AI系统的重要一步。如果AI能在数学这种纯粹的逻辑世界里证明自己，那么将其能力迁移到软件验证、硬件设计、安全协议分析等需要极高可靠性的工程领域，前景将不可限量。接下来，我将深入拆解LEAP这类项目背后的设计思路、核心技术点以及在实际操作中可能遇到的挑战。

2. 核心架构：智能体框架如何为LLM赋能

传统的LLM应用在形式化数学上，通常采用“提示-补全”的单次交互模式。你给模型一个定理陈述，让它生成一段形式化证明代码。这种方法在简单例子上可能奏效，但对于复杂问题，失败率极高。原因在于，证明过程本质上是搜索和规划：在一个巨大的、由公理和引理构成的可能性空间中，找到一条从假设到结论的路径。这需要试错、回溯和策略调整。

智能体框架的引入，正是为了系统化地管理这个搜索和规划过程。我们可以把LEAP的架构想象成一个微型的、专为数学证明定制的“操作系统”。

2.1 智能体角色分工与协作机制

一个典型的用于形式化数学的智能体框架会包含几种核心角色，它们各司其职，通过一个中央调度器或共享工作空间进行协作：

1. 问题理解与形式化代理：它的任务是将用自然语言或非严格数学语言描述的问题，转化为形式化系统（如Lean、Coq、Isabelle/HOL）能接受的精确陈述。这需要模型深刻理解数学语义和形式化语法。例如，把“证明勾股定理”转化为theorem pythagorean (a b c : ℝ) (h : a^2 + b^2 = c^2) : ...。这个代理的成功与否，直接决定了整个任务的起点是否正确。

2. 策略规划代理：这是证明过程的“指挥官”。它不直接生成具体的证明步骤，而是制定高层策略。例如，面对一个要证明的命题，它可能决定：“这是一个关于自然数的等式，尝试使用数学归纳法”，或者“这个结论是另一个已知定理的直接推论，尝试应用那个定理”。它会将高层策略分解为一系列子目标（subgoals）。

3. 战术执行代理：这是在一线“干活”的代理。它接收策略规划代理产生的子目标，并尝试使用形式化系统提供的具体“战术”来完成它。在Lean中，这可能包括apply,rewrite,induction,simp等命令。这个代理需要精通目标系统的证明语言和标准库。

4. 状态验证与回溯代理：这是质量的“守门员”。每当战术执行代理完成一步，这个代理就检查当前的证明状态：是否产生了错误？子目标是否被正确消解？证明是否出现了逻辑循环？一旦检测到问题，它会触发回溯机制，通知策略规划代理“此路不通，需要调整策略”，或者让战术执行代理尝试另一种方法。

5. 引理检索与知识管理代理：数学证明严重依赖已有的知识库。这个代理负责从形式化数学库（如Mathlib）中检索可能相关的定义、定理和引理。它需要理解当前证明的上下文，并能够进行语义搜索，而不仅仅是关键词匹配。例如，当证明涉及“连续函数”时，它能自动联想到中值定理、极值定理等。

这些代理并非一定是完全独立的模型实例。更多时候，它们共享同一个LLM基座，但通过精心设计的系统提示词和上下文管理，让同一个模型在不同阶段扮演不同的角色，专注于特定的任务。协作机制通常基于“循环”或“事件驱动”：中央协调器维护一个待处理目标栈和当前证明状态，依次或根据条件激活不同的代理，推动证明状态向前演进。

2.2 框架的核心组件：记忆、工具与评估

除了角色分工，一个强大的智能体框架还依赖于几个关键组件：

• 工作记忆：这是整个证明过程的“黑板”。它持久化存储着：原始问题、当前证明目标、已完成的证明步骤、尝试过的策略及其结果（成功或失败）、从知识库检索到的相关引理。工作记忆使得智能体能够进行长程推理，避免重复劳动和循环论证。它通常以结构化的形式（如JSON或图结构）存在，方便不同代理读写。

• 工具调用能力：智能体不能只靠“空想”。它们必须能调用外部工具来获取信息或执行计算。最重要的工具包括：

  • 形式化证明检查器：如Lean服务器、Coq的coqc。这是终极裁判。任何生成的证明代码都必须提交给它进行验证。工具调用的返回状态（成功/错误及错误信息）是驱动智能体决策的关键反馈。
  • 符号计算引擎：如SymPy、Wolfram Engine。用于化简复杂的代数表达式、求解方程、进行符号积分微分，为证明提供中间计算支持。
  • 定理/引理数据库查询接口：用于与Mathlib等大型形式化库交互。

• 评估与奖励函数：在证明搜索中，需要评估当前状态的好坏，以指导搜索方向。一个简单的奖励是：距离最终证明完成还有多少子目标？更复杂的评估可能包括：当前证明的简洁度、是否使用了更优雅的引理、证明步骤的泛化能力等。在基于强化学习的框架中，这个奖励函数用于训练策略模型。

实操心得：设计系统提示词是关键让同一个LLM在不同代理角色间切换，高度依赖于系统提示词的设计。你需要为每个角色编写清晰、具体、包含范例的提示词。例如，给“战术执行代理”的提示词应该像这样：“你是一个Lean专家。当前证明目标是：⊢ a + b = b + a。可用的上下文有：交换律定理add_comm。请生成1-3条最可能解决此目标的Lean战术命令。只输出命令，不要解释。” 提示词的质量直接决定了代理的“专业程度”。

3. 实现流程：从定理陈述到机器验证证明

理解了架构，我们来看一个简化的、基于LEAP理念的端到端实现流程。假设我们要在Lean4中证明一个简单命题：对于所有自然数n， n ≤ n * n （当n≥1时）。当然，这个命题很简单，但流程适用于更复杂的问题。

3.1 阶段一：初始化与问题载入

首先，用户输入自然语言描述：“证明对于所有大于等于1的自然数n，有n ≤ n * n。”

1. 问题理解代理被激活。它分析句子，识别关键成分：量词（∀）、变量（n）、定义域（ℕ, n ≥ 1）、关系（≤）、运算（*）。然后，它将其转化为Lean的初步形式化陈述。它可能会生成多个候选，比如：

   theorem nat_le_square (n : ℕ) (h : 1 ≤ n) : n ≤ n * n := by -- 证明体待填充

   或者更精确地利用Nat.succ_le_of_lt等。代理会将这个初步形式化陈述连同原始问题一起存入工作记忆。

2. 初始验证：框架自动调用Lean服务器，检查这个定理陈述的语法是否正确，类型是否有效。如果报错（比如h的类型不对），则触发回溯，要求问题理解代理重新生成。

3.2 阶段二：策略规划与迭代证明

假设初始陈述通过了语法检查，证明目标n ≤ n * n被放入目标栈。

1. 策略规划代理查看当前目标n ≤ n * n和上下文(n : ℕ) (h : 1 ≤ n)。它可能会推理：“这是一个关于自然数的不等式证明。已知n≥1。结论是n ≤ nn。对于n≥1，nn ≥ n 是直观的。可以考虑使用数学归纳法，或者利用已有的引理如Nat.mul_le_mul。” 它制定一个初步策略：“尝试使用induction' n进行归纳证明，同时处理基础情况n=1和归纳步骤。” 这个策略被分解为子任务：a) 证明基础情况 (n=1)。 b) 证明归纳步骤（假设对于k成立，证明对于k+1成立）。

2. 战术执行代理（处理基础情况）被分配子目标1 ≤ 1 * 1。它检索工作记忆和知识库，发现1 * 1计算为1，所以目标是1 ≤ 1。它知道le_rfl或Nat.le_refl 1可以证明自反性。于是它生成：

   rw [mul_one] -- 将1*1化简为1 exact Nat.le_refl 1

   或者更简洁地simp。它执行这个代码片段（通过调用Lean检查器）。

3. 状态验证代理接收到Lean检查器的返回：成功。于是基础情况被标记为完成，工作记忆更新。

4. 战术执行代理（处理归纳步骤）现在面对更复杂的子目标。假设归纳假设是IH : k ≤ k * k，需要证明k+1 ≤ (k+1)*(k+1)。它可能需要展开乘法(k+1)*(k+1) = k*k + 2*k + 1，然后利用归纳假设和h : 1 ≤ k（实际上在归纳步骤中k≥1）进行不等式推导。这个过程可能需要多次尝试：

   • 尝试一：直接simp [Nat.succ_mul, Nat.mul_succ]展开，但得到的表达式可能很复杂。
   • 尝试二：策略规划代理介入，建议“尝试将目标k+1 ≤ (k+1)*(k+1)与k ≤ k*k联系起来，利用Nat.succ_le_succ和乘法单调性”。
   • 战术执行代理根据新策略，生成利用Nat.mul_le_mul_left或Nat.mul_le_mul_right等引理的代码。

   这个过程可能循环多次，每次尝试的结果（成功或错误信息）都被记录到工作记忆中，避免重复尝试错误路径。

3.3 阶段三：验证、优化与输出

1. 最终验证：当所有子目标都被消解，一个完整的by块代码就生成了。框架会最后一次调用Lean检查器，对整个定理进行完整编译验证。只有得到“无错误”的返回，才认为证明成功。

2. 证明优化（可选）：在获得一个可验证的证明后，可以启动一个“优化代理”，尝试简化证明。例如，用更高效的linarith战术替代一长串的apply和exact，或者寻找更短的证明版本。这通过让模型在已验证的证明上进行重构来实现。

3. 输出：最终，框架输出机器可验证的Lean代码，以及一个人类可读的证明过程摘要，说明使用了哪些主要策略和关键引理。

整个流程高度依赖LLM对数学内容、形式化语法以及当前证明状态的理解能力。工作记忆的维护和智能体间的有效通信是流程顺畅的关键。

4. 关键技术挑战与应对策略

将LLM与智能体框架结合用于形式化数学，尽管前景广阔，但实践中布满荆棘。以下是我认为的几个核心挑战及潜在的解决思路。

4.1 挑战一：LLM的“幻觉”与形式化严谨性的根本矛盾

这是最根本的挑战。LLM基于概率生成，其目标是产生“看似合理”的文本，而形式化证明要求100%的逻辑正确。LLM可能会“自信地”生成一个错误的引理名称，或者一个类型不匹配的表达式。

• 应对策略：
  • 即时验证，快速回溯：这是智能体框架的核心价值。每一个战术步骤、每一个引理应用，都必须立即通过证明检查器验证。一旦失败，错误信息必须被精准地反馈给相关代理（通常是战术执行或规划代理），触发回溯并尝试其他路径。错误信息是宝贵的训练数据。
  • 工具强制约束：尽可能让智能体通过工具调用来获取知识，而不是依赖其内部记忆。例如，当需要某个引理时，代理应该调用“引理检索工具”从正式库中搜索，而不是自己“编造”一个。这大大减少了幻觉空间。
  • 细化动作空间：与其让模型直接生成一大段证明代码，不如限制其动作空间。例如，在一个给定的证明状态下，只允许模型从10个最相关的标准战术中选择一个，或者从检索到的5个引理中选择一个应用。这降低了生成错误语法结构的可能性。

4.2 挑战二：长程依赖与上下文管理

数学证明往往很长，后面的步骤严重依赖前面定义的概念和已证明的引理。LLM有限的上下文窗口（如128K）可能无法容纳整个证明过程和历史。

• 应对策略：
  • 分层抽象的工作记忆：工作记忆不应是简单的对话历史堆砌。它应该是结构化的，记录证明的目标栈、已证引理的关键标识、重要的中间假设等。当与LLM交互时，可以动态生成一个摘要或当前焦点视图，只包含与下一步决策最相关的信息，而不是全部历史。
  • 模块化证明：鼓励智能体将大定理分解成一系列独立的引理（lemma）。每个引理的证明相对短小，可以独立验证。这样，在证明主定理时，上下文只需要引用这些引理的名称，而不需要其具体证明过程。这模仿了人类数学家写论文的方式。
  • 向量检索记忆：将历史证明步骤、定义、定理都嵌入成向量。当处于某个证明状态时，从向量库中检索最相关的片段，注入上下文。这类似于“长期记忆”机制。

4.3 挑战三：搜索空间爆炸与规划效率

即使是一个中等难度的定理，可能的证明路径组合也是天文数字。穷举搜索不可行。

• 应对策略：
  • 基于语言的启发式搜索：利用LLM本身的推理能力作为启发式函数。策略规划代理在每一步评估不同策略的“前景”，优先探索那些用自然语言描述“看起来更有希望”的路径。这比纯粹的随机搜索或宽度优先搜索更高效。
  • 模仿学习与数据驱动：在已有的形式化数学库（如Mathlib）上训练模型。这些库包含了人类编写的优秀证明。模型可以学习人类在特定情境下偏好使用的战术和策略，形成“直觉”。这本质上是让模型模仿专家的证明风格。
  • 强化学习微调：将证明过程建模为马尔可夫决策过程：状态是当前证明目标，动作是应用一个战术，奖励是最终完成证明（+1）或步数惩罚。通过在大量定理上训练，让模型学会选择能更快导向成功证明的动作。Google的“AlphaGeometry”就在几何证明中成功应用了类似思想。

4.4 挑战四：形式化系统与库的专门知识

Lean、Coq等系统有自己复杂的语法、类型系统和庞大但可能不完整的标准库。LLM需要掌握这些专门知识。

• 应对策略：
  • 领域自适应预训练与微调：在大量形式化代码（如Mathlib的全部源文件）上继续预训练或进行指令微调。让模型深度掌握特定系统的语法、惯用法和常用定理。目前已有诸如ProofNet、LeanDojo等专门的数据集和基准测试来推动这方面工作。
  • 动态知识检索集成：如前所述，将检索增强生成（RAG）深度整合到框架中。代理在需要时，实时从形式化库的文档和源代码中检索相关片段。这保证了知识的准确性和时效性（随着库的更新而更新）。

注意事项：不要低估工程复杂性构建这样一个系统，其难点不仅在于AI算法本身，更在于复杂的软件工程。你需要管理多个代理的并发或交替执行、维护一致且高效的工作记忆、设计稳健的错误处理和超时机制、与外部工具（Lean服务器）进行稳定通信。系统架构的清晰度和模块化至关重要，否则调试将是一场噩梦。建议从实现一个简单的、单代理的“验证循环”开始，再逐步增加代理角色和复杂性。

5. 实践工具链与开发环境搭建

如果你想亲手尝试构建或实验类似LEAP的智能体框架，以下是一个可行的工具链和起步建议。

5.1 核心组件选型

1. 大语言模型：

   • 首选：开源可微调模型。如CodeLlama（70B）、DeepSeek-Coder、Qwen-Coder。开源模型允许你在本地部署，进行领域特定微调，且没有调用频率限制。对于证明任务，代码能力强的模型是基础。
   • 备选：高性能闭源API。如GPT-4、Claude 3 Opus。它们的推理能力更强，尤其擅长理解复杂指令。但成本高、延迟大，且不适合需要频繁迭代调优的研究。可用于原型验证或作为“高级规划器”。

2. 形式化证明系统：

   • Lean 4 + Mathlib：目前最活跃、社区最大的形式化数学库。Mathlib涵盖了从基础代数到前沿数学的庞大内容，是绝佳的实验场。Lean 4的服务器模式提供了良好的LSP支持，便于程序化交互。
   • Coq：历史更悠久，在程序验证领域有深厚基础。生态系统成熟，但库的规模和组织方式与Mathlib不同。
   • Isabelle/HOL：以强大的自动化工具（如Sledgehammer）闻名。对于探索LLM与自动化工具的结合很有价值。

   对于新手，推荐从Lean 4开始，因为其现代的设计、活跃的社区和丰富的教程资源。

3. 编程语言与框架：

   • Python：无疑是粘合一切的首选。丰富的AI库（Transformers, vLLM, LangChain, LlamaIndex）和网络库。
   • 交互驱动库：
     • lean-dojo：一个专为与Lean交互而设计的Python工具包。它提供了编程方式启动Lean环境、发送命令、获取证明状态和错误信息的接口，是构建证明智能体的基石。
     • pycoq/serapi：用于与Coq交互的类似工具。
   • 智能体框架基础：你可以从零开始构建，也可以利用现有框架简化：
     • LangChain / LangGraph：提供了构建多智能体工作流的基础设施，如状态管理、工具调用、智能体路由。适合快速搭建原型。
     • AutoGen：微软推出的多智能体对话框架，支持定义角色、注册函数（工具），能很好地模拟代理间的对话与协作。
     • 简单脚本：对于研究核心算法，有时一个精心设计的、带循环和状态管理的Python脚本反而更直接可控。

5.2 最小可行系统搭建步骤

以下是一个基于Lean 4和Python的最小可行验证环境的搭建思路：

1. 环境准备：

   # 1. 安装Lean 4 # 参考官方指南 https://lean-lang.org/lean4/doc/setup.html # 例如使用elan（Lean版本管理器） curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | sh # 2. 创建并进入一个项目目录 mkdir leap_experiment && cd leap_experiment lake init leap_experiment # 3. 安装Python依赖（假设使用venv） python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows pip install openai lean-dojo langchain

2. 核心交互循环实现： 创建一个simple_agent.py，实现一个最基本的“提议-验证”循环。

   import subprocess import json from openai import OpenAI # 或使用本地模型 class SimpleProverAgent: def __init__(self, model_api): self.model_api = model_api self.lean_file = "test.lean" self._init_lean_file() def _init_lean_file(self): # 写入定理陈述和初始证明骨架 with open(self.lean_file, 'w') as f: f.write("""

import Mathlib theorem my_theorem (n : ℕ) (h : 1 ≤ n) : n ≤ n * n := by -- 证明将由智能体填充 """)

def get_current_state(self): """读取当前Lean文件的最后几行（证明体部分）""" with open(self.lean_file, 'r') as f: lines = f.readlines() # 简单实现：返回最后5行作为上下文 return "".join(lines[-5:]) if len(lines) >=5 else "".join(lines) def run_lean_check(self): """调用lake build检查当前文件""" try: result = subprocess.run( ["lake", "build"], cwd=".", # 项目根目录 capture_output=True, text=True, timeout=10 ) return result.returncode == 0, result.stdout, result.stderr except subprocess.TimeoutExpired: return False, "", "Timeout" def propose_step(self, current_state): """调用LLM，基于当前状态提议下一步战术""" prompt = f""" 你是一个Lean 4证明助手。当前证明状态如下： ``` {current_state} ``` 请生成**一条**最可能推进证明的Lean战术命令（如`induction n`, `apply ...`, `simp at *`等）。 只输出这一条命令，不要任何其他解释。 """ # 调用LLM API（此处为示例，需替换为实际调用） response = self.model_api.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": prompt}], temperature=0.1 # 低温度以保证确定性 ) proposed_tactic = response.choices[0].message.content.strip() return proposed_tactic def execute_step(self, tactic): """将提议的战术写入文件，并验证""" # 读取文件，找到`by`块内的位置，插入战术 with open(self.lean_file, 'r') as f: content = f.read() # 这里需要更精细的解析来定位插入点。简单示例：追加到证明体末尾的注释前 if " -- 证明将由智能体填充" in content: new_content = content.replace(" -- 证明将由智能体填充", f" {tactic}\n -- 证明将由智能体填充") else: # 否则追加到文件末尾 new_content = content + f"\n {tactic}" with open(self.lean_file, 'w') as f: f.write(new_content) # 运行检查 success, stdout, stderr = self.run_lean_check() if not success: # 回滚：移除最后添加的战术行 with open(self.lean_file, 'w') as f: f.write(content) # 写回旧内容 print(f"步骤失败，已回滚。错误：{stderr}") return False, stderr return True, "" def run(self, max_steps=20): for step in range(max_steps): state = self.get_current_state() print(f"步骤 {step+1}, 当前状态预览:\n{state}") tactic = self.propose_step(state) print(f"提议战术: {tactic}") success, error = self.execute_step(tactic) if success: print("战术成功应用。") # 检查定理是否已完全证明（简单方法：检查错误输出中是否包含‘goals accomplished’） if "goals accomplished" in error or step > 15: # 简单启发式 print("证明可能已完成！") break else: print(f"战术应用失败: {error}") # 可以在这里引入更复杂的回溯逻辑 break final_success, _, _ = self.run_lean_check() if final_success: print("\n定理证明成功！") with open(self.lean_file, 'r') as f: print("最终证明：") print(f.read()) else: print("\n证明未能在限定步骤内完成。") # 使用示例 if __name__ == "__main__": client = OpenAI(api_key="your-api-key") # 或初始化本地模型 agent = SimpleProverAgent(client) agent.run() ```

这个最小系统仅仅实现了“单代理提议-验证”循环，缺少规划、回溯、多代理协作等高级功能，但它揭示了最核心的交互模式：LLM提议动作，形式化验证器提供即时反馈。在此基础上，你可以逐步引入更复杂的组件。

6. 评估、局限与未来展望

如何衡量一个像LEAP这样的系统是否成功？不仅仅是看它证明了几个定理，更需要一套科学的评估体系。

6.1 评估基准与方法

1. 基准测试集：使用公开的形式化数学基准，如：

   • MiniF2F：涵盖了高中数学竞赛题到本科数学问题的形式化转换版本。
   • ProofNet：一个专门为评估LLM在形式化数学中表现而构建的数据集。
   • Mathlib的Archive/目录：包含大量具有挑战性的、已形式化的定理，可以作为测试目标。
   • IMO Grand Challenge：国际数学奥林匹克问题的形式化版本，是终极测试场。

2. 评估指标：

   • 通过率：在基准测试集上，系统能自动完成证明的题目比例。这是最直接的指标。
   • 证明长度/时间：与人类编写的参考证明相比，系统生成的证明步骤数（或Lean代码行数）以及搜索证明所花费的CPU时间。
   • 搜索效率：平均每个成功证明需要尝试多少次战术（验证调用）。这反映了智能体规划的有效性。
   • 泛化能力：在训练集上未见过的定理类型上的表现。
   • 人类干预度：为了完成一个证明，需要人类提供提示或修正的次数。理想的系统应该需要零干预。

6.2 当前局限与待解难题

尽管前景光明，但我们必须清醒认识当前的局限：

• 领域通用性差：在一个形式化系统（如Lean）上训练或调优的模型，很难直接迁移到另一个系统（如Coq）。知识和技能高度特定于系统。
• 对大型库的依赖：系统的表现严重依赖于底层形式化数学库（如Mathlib）的完备性和组织方式。证明一个定理往往需要调用库中特定的引理，如果库缺少某个关键环节，系统可能无法绕行。
• 创造性不足：目前的系统更擅长组合已知的战术和引理，或者模仿已有证明。在需要真正创造性洞察、引入全新辅助构造或定义的关键步骤上，仍然乏力。它们更像是“证明搜索引擎”，而非“数学发明家”。
• 资源消耗大：运行大型LLM、频繁调用证明检查器（尤其是对于复杂目标）需要大量的计算资源。这使得快速迭代和探索成本高昂。

6.3 未来发展方向

1. 神经符号结合：将神经网络的模式匹配、联想能力与符号推理引擎的精确性、可解释性深度结合。例如，用LLM生成证明草图或策略建议，然后用传统的自动定理证明器（如E, Vampire）或SMT求解器来填充细节、验证子目标。
2. 代码与自然语言联合训练：训练能够无缝理解自然语言数学描述、非形式化证明、形式化代码以及它们之间对应关系的统一模型。这需要构建更大规模、更高质量的对齐数据集。
3. 交互式证明助手：未来的系统可能不是全自动的，而是作为“副驾驶”与数学家协同工作。它能理解人类的证明意图，自动完成繁琐的细节填充，在人类卡住时提供可行的下一步建议，并实时检查错误。这可能是短期内最具实用价值的落地形态。
4. 自我改进与课程学习：让系统能够在证明过程中从自己的错误中学习（通过强化学习），或者按照从易到难的“课程”顺序学习定理，逐步构建更复杂的推理能力。

在我个人看来，LEAP所代表的智能体框架方向，是将LLM从“语言艺术家”转变为“逻辑工程师”的关键一步。它不再追求模型一次性输出完美答案，而是设计一个能让模型持续思考、试错、验证的理性环境。这条路虽然艰难，但每一步进展，都让我们离构建出真正可靠、能进行深度推理的AI系统更近一步。对于开发者而言，现在入手这个领域，不仅是在探索AI的前沿，更是在亲身参与塑造未来科研与工程的基础设施。从搭建一个最简单的“提议-验证”循环开始，你就能亲身体验到让机器理解数学之美与严谨性的挑战与乐趣。