1. 项目概述当AI学会“左右互搏”来解数学题最近在AI圈子里“Agentic”智能体化和“Neurosymbolic”神经符号这两个词的热度是越来越高。简单来说这代表了一种新的AI研究范式不再是让一个单一的、庞大的模型去“蛮干”而是让多个具备不同“思维模式”的智能体Agent协同工作把神经网络的直觉感知能力和符号逻辑的严谨推理能力结合起来。这听起来有点像武侠小说里的“左右互搏”让感性的右脑和理性的左脑一起上阵。而我们这个项目就是把这个听起来很前沿的理念实实在在地用到了一个非常经典的数学领域——组合设计Combinatorial Design上并且用Lean 4这个形式化验证工具作为最终的“裁判”和“记录员”。组合设计是什么你可以把它想象成一种高级的“编排艺术”。比如学校要组织一场循环赛有7支队伍要求每支队伍每天只打一场比赛并且任何两支队伍在整个赛程中只相遇一次。怎么排这个赛程表这就是一个典型的组合设计问题具体来说是“斯坦纳三元系”问题。这类问题在实验设计、编码理论、网络调度等领域有着极其重要的应用。传统上解决这类问题要么靠数学家精巧的构造性证明要么靠计算机进行穷举搜索两者都有其局限性。我们这个项目的核心目标就是探索如何让大语言模型LLM驱动的智能体模仿数学家“发现”和“验证”组合设计的过程。我们不是简单地让LLM去“猜”一个解而是设计了一个多智能体协作框架一个“直觉型”智能体负责提出大胆的猜想和构造思路发挥神经网络的联想能力一个“严谨型”智能体负责用逻辑规则去检验和修正这些猜想发挥符号系统的推理能力它们相互辩论、相互完善。最后所有达成一致的、正确的推导步骤都会被翻译成Lean 4的代码形成一个可以被机器百分百验证的、无可争议的数学证明。这不仅仅是解决了一个具体的数学问题更是一次对AI如何实现真正“推理”和“发现”的方法论探索。它展示了如何将LLM的创造力引导到严谨的数学框架内为未来AI辅助数学研究、甚至进行自主科学发现提供了一个可复现的案例。接下来我就把这个项目的设计思路、实现细节、踩过的坑以及背后的思考毫无保留地分享给大家。2. 核心架构设计构建一个“辩论式”智能体协作系统整个系统的设计灵感来源于数学研究中的常见场景灵感迸发猜想与严格验证证明的反复循环。我们摒弃了让单个LLM“既当运动员又当裁判”的做法而是将其拆解为两个角色分明、能力互补的智能体。2.1 双智能体角色定义与分工我们设计了两个核心智能体猜想家Conjecturer和检验者Verifier。它们的职责和“性格”截然不同。猜想家智能体由一个大语言模型例如GPT-4、Claude 3或开源的DeepSeek驱动。它的核心任务是“发散思维”。输入当前要解决的组合设计问题的形式化描述例如“构造一个阶数为v7的斯坦纳三元系S(2,3,7)”以及当前已部分构建的结构或之前失败的尝试历史。处理它利用LLM在大量数学文本和代码上训练出的模式识别能力进行类比联想。它可能会说“这看起来很像一个有限射影平面的结构也许我们可以从Fano平面7个点的最小射影平面入手尝试将其解释为一个三元系。” 或者它会提出一个具体的构造算法“尝试用模运算的方法以模7的剩余类为基础生成所有形如{i, i1, i3}的三元组。”输出一个具体的、用自然语言或类伪代码描述的构造猜想以及一段解释其为何可能可行的“直觉性”论证。检验者智能体则是一个神经符号混合体。它同样有一个LLM作为“解析器”但背后连接着一个符号推理引擎我们集成了一个简单的定理证明器如Z3或直接调用Lean的API进行小范围检查。输入猜想家提出的构造猜想。处理解析与形式化其内部的LLM首先将猜想家的自然语言描述翻译成精确的、无歧义的逻辑断言或数据结构定义。这是关键一步任何模糊性都必须在这里被消除。符号验证将这些形式化的断言喂给符号推理引擎。引擎会检查该构造是否满足组合设计的所有公理如每对元素恰好同时出现在一个三元组中。对于小型实例它可能进行穷举检查对于有参数的猜想它可能尝试进行符号推导。输出一个明确的验证结果“通过”、“失败”或“条件性通过”。如果失败必须提供反例或指出违反的公理。例如检验者可能回复“你提出的模7构造方案中元素对(1, 4)同时出现在三元组{1,2,4}和{1,4,5}中违反了‘每对元素恰好出现一次’的规则。”这两个智能体被放置在一个迭代辩论循环中。猜想家提出想法检验者挑刺。如果被驳回检验者的反馈反例会成为猜想家下一轮思考的重要输入驱动它修正猜想。这个过程循环往复直到检验者给出“通过”的判决或者循环次数达到上限。2.2 Lean 4作为“终审法庭”与知识锚点为什么选择Lean 4因为它不是普通的编程语言而是一个依赖类型的形式化证明语言。在Lean里写一段代码就是构建一个证明类型检查器就是最严格的法官。任何逻辑跳跃、未声明的假设都逃不过它的审查。在我们的系统中Lean 4扮演两个核心角色最终验证器当双智能体协作产出一个“通过”的构造方案后我们需要生成一个Lean 4定理theorem及其证明proof。这个证明会详细描述该组合设计对象的构造过程并证明它满足所有性质。Lean内核会对整个证明链进行终极验证确保从基础公理到最终结论每一步都滴水不漏。这相当于为AI的发现过程提供了一个数学上的“公证”。交互式反馈源在智能体协作的中间阶段我们也可以让Lean提供轻量级反馈。例如猜想家生成一段Lean代码片段后可以立即运行Lean检查是否有语法错误或简单的类型错误。这比等待完整的符号验证更快能快速纠正低级错误引导LLM写出更正确的形式化表述。更重要的是Lean及其庞大的数学库Mathlib为我们的智能体提供了一个精确的、结构化的知识库。我们可以让智能体在提出猜想时引用Mathlib中已有的定义和定理如Finset,Setoid, 组合设计的基本定义design等这极大地提升了猜想的质量和可验证性。它让AI的“思考”扎根于坚实的数学基础之上而不是在模糊的自然语言概念中飘荡。2.3 协作流程与通信协议整个系统的运行流程是一个标准的多轮对话循环但带有强烈的目标导向初始化用户输入一个组合设计问题P。系统初始化猜想家和检验者并将P传递给猜想家。猜想生成轮猜想家基于P和历史对话生成一个猜想C_i和解释E_i。检验轮检验者接收C_i。其LLM解析器先将C_i形式化为F_i然后符号引擎验证F_i。产生结果R_i通过/失败反馈Fb_i。判决与迭代若R_i为“通过”流程进入证明生成阶段。若R_i为“失败”系统将(C_i, R_i, Fb_i)追加到对话历史中然后将该历史和原问题P一起作为新的输入发送给猜想家启动下一轮回到步骤2。提示词会强调“你之前的猜想C_i因Fb_i被驳回。请分析这个反例修正你的思路提出一个新的猜想。”证明生成阶段一旦猜想C_k被检验通过一个专门的证明编写智能体可由检验者或一个第三方智能体担任被激活。它利用整个对话历史特别是被验证通过的构造步骤编写出完整的Lean 4证明代码。随后调用Lean进行编译验证。输出最终输出两份成果一份是人类可读的、包含迭代历史的发现过程叙述一份是机器可验证的、纯净的Lean 4证明文件。这个协议的关键在于反馈Fb_i必须是具体、可操作的。模糊的“这不对”毫无帮助。“元素对(x, y)在多个块中出现”这样的反馈才能引导LLM进行有针对性的修正。3. 关键技术实现与工具链搭建理论设计得再漂亮落地时全是细节。这一部分我带你看看我们具体是怎么搭起这个系统的以及其中那些容易踩坑的地方。3.1 LLM的选型与提示词工程LLM是整个系统的“大脑”其选择和质量直接决定了智能体的表现。选型考量闭源 vs 开源像GPT-4、Claude 3这样的闭源模型在复杂推理和遵循指令方面表现卓越是快速验证想法原型的利器。但考虑到成本、可控性和数据隐私长期来看需要探索开源模型。我们试验了DeepSeek-Coder、CodeLlama和MathCoder等专门在代码和数学数据上微调过的模型。发现它们在代码生成上不错但在深度的、多步的数学类比推理上与顶级闭源模型仍有差距。关键能力对于猜想家我们需要强大的类比推理和创造性思维能力。对于检验者中的解析器我们需要极致的精确性和指令遵循能力确保翻译无歧义。我们最终为猜想家选择了创造性更强的Claude 3为检验者解析器选择了更严谨的GPT-4。提示词设计是灵魂。绝不能简单地说“你是一个数学助手”。我们的提示词是高度结构化、包含角色、规则和示例的“剧本”。猜想家提示词核心要素你是一位富有创造力的组合数学家。你的目标是为组合设计问题提出新颖的构造猜想。 问题{problem_statement} 历史对话最新在最前 {history} --- 规则 1. 你的输出必须是纯粹的猜想和解释不要包含验证步骤。 2. 猜想应尽可能具体可以是算法描述、数学公式或结构类比。 3. 如果历史中有反馈你必须直接回应它解释你如何根据反馈改进了猜想。 4. 优先考虑使用Mathlib中已有的概念如Finset, Set, design。 --- 示例对于另一个问题 用户构造一个4阶完全图K_4的边着色使得任意两条相邻边颜色不同且使用颜色最少。 助理猜想家猜想K_4的边可以用3种颜色着色。构造方法将四个顶点标号为0,1,2,3。对于边(i,j)其颜色定义为 (ij) mod 3。这是一种可能的循环着色方案。 --- 现在请基于当前问题和历史提出你的下一个猜想。这个提示词明确了角色、任务提供了上下文历史规定了输出格式并给出了一个类似任务的示例Few-shot Learning极大地稳定了输出质量。检验者解析器提示词核心要素你是一个严格的数学逻辑翻译器。你的任务是将自然语言描述的数学猜想转化为精确的、可被符号引擎验证的断言。 猜想{conjecture} --- 规则 1. 输出必须是单一的、无嵌套的JSON对象。 2. JSON格式{objects: [对象1定义, 对象2定义...], properties: [需要验证的性质1, 性质2...]} 3. 定义必须使用标准的集合论和逻辑符号∈, ⊆, ∀, ∃, ∧, ∨, →。 4. 所有涉及的对象如集合、函数必须显式声明其域和陪域。 --- 示例 输入猜想“集合{1,2,3}的所有2-子集构成的集合。” 输出{objects: [Let A {1, 2, 3}, Let B { {1,2}, {1,3}, {2,3} }], properties: [B { S | S ⊆ A ∧ |S| 2 }]} --- 现在请翻译给定的猜想。通过强制JSON输出和严格的形式化要求我们最大限度地减少了LLM的“自由发挥”得到了结构化的、可供下游符号引擎消费的数据。3.2 符号推理引擎的轻量化集成我们并不需要实现一个能证明一切的全能定理证明器。对于组合设计验证很多情况下是检查一个有限结构是否满足若干条公理。这本质上是模型检测问题。我们的策略是分层验证轻量级快速检查针对小型实例如果猜想描述的是一个具体的小型设计比如v15我们直接用Python生成这个结构如所有三元组的列表然后编写简单的脚本检查公理。例如检查“每对点恰好出现一次”就计算所有点对的出现次数。这速度极快能立刻给LLM反馈。中等规模或参数化检查对于参数化的猜想如“对所有形如v6k1的整数存在…”我们集成Z3或SymPy这样的约束求解器/符号计算库。我们将组合设计的公理编码为约束条件然后让求解器去寻找一个解验证存在性或证明无解。虽然不能处理非常复杂的数学归纳但对于许多组合构造这已经非常强大。终极验证接口对于所有通过前两步检查的猜想其最终证明都会导向Lean。我们实现了一个简单的Lean服务器客户端。证明编写智能体生成的Lean代码会通过这个客户端发送到本地运行的Lean服务进行批处理编译。lean --make MyProof.lean如果编译成功返回0则证明有效如果失败编译器的错误信息会作为反馈返回给智能体进行修正。注意直接让LLM生成大段Lean证明成功率很低。我们的策略是“分而治之”先让智能体用自然语言写出证明大纲然后将大纲分解成一个个独立的引理Lemma再为每个引理分别生成Lean证明。最后用have和calc等策略将它们组合起来。这大大降低了单次生成的难度。3.3 迭代循环中的状态管理与反思机制多轮对话中状态管理至关重要。我们不能让LLM忘记过去。我们维护的核心状态包括完整对话历史所有轮次的(猜想 检验结果 反馈)三元组。已验证的子目标在探索过程中可能先验证了某个构造满足部分性质例如所有块的大小正确。这些已验证的子目标会被缓存后续猜想可以在此基础上构建避免重复验证。失败模式库记录常见的失败原因如“某对点出现次数1”“某个块大小不对”。当新的失败出现时系统可以提示LLM“注意这看起来是‘点对重复’类错误请重点检查你构造的对称性。”此外我们引入了反思机制。在连续多次失败如5次后系统不会直接进入下一轮而是会触发一个“元认知”提示要求猜想家智能体暂停提出新猜想而是分析历史失败记录总结规律调整自己的问题解决策略。例如回顾你最近5次失败的猜想。它们被驳回的主要原因都集中在“点对重复”上。这表明你当前的构造方法可能缺乏某种整体对称性。请暂时停止提出具体猜想而是思考在组合设计理论中有哪些常见的对称构造方法如循环群作用、有限域上的运算可以避免这种重复请列出两到三种高阶策略然后再应用其中一种策略来生成下一个具体猜想。这种强制性的“停下来想一想”能有效打破LLM在低效模式中的循环引导它进行策略层面的提升模仿了人类研究者遇到瓶颈时的思考方式。4. 实战案例构造S(2,3,7)斯坦纳三元系光说不练假把式。让我们看一个完整的、简化的运行实例目标是构造最小的非平凡斯坦纳三元系S(2,3,7)即7个点每3个点组成一个块每对点恰好出现在一个块中共有7个块。初始状态问题P: “构造一个斯坦纳三元系S(2,3,7)即一个点集V|V|7和一系列三元组块的集合B满足∀v∈V, 包含v的块数相同且∀{x,y}⊆V, 存在唯一b∈B使得{x,y}⊆b。”历史: []空第一轮猜想家基于对有限射影平面的联想“猜想这个三元系同构于Fano平面。构造令点集V {0,1,2,3,4,5,6}。块集合B为{0,1,3}, {1,2,4}, {2,3,5}, {3,4,6}, {4,5,0}, {5,6,1}, {6,0,2}。这是一种模7的循环构造。”检验者解析器将猜想形式化为V {0,...,6};B [列表上述7个集合]; 待验证性质1. B中每个集合大小为3。2. 任意两个不同点i, j在B中恰好同时出现一次。符号引擎快速Python脚本检查性质1通过。检查性质2时发现点对(0,1)出现在块{0,1,3}中但点对(0,1)没有出现在其他块等等检查发现(0,1)只出现了一次很好。继续检查所有点对… 发现点对(0,2)出现在块{6,0,2}中也只出现一次。… 检查所有21个点对全部恰好出现一次。结果通过。系统判决第一轮就通过了进入证明生成阶段。证明生成阶段证明编写智能体接收通过的构造和完整历史。它生成Lean代码框架import Mathlib.Combinatorics.Design open Finset -- 定义点集和块集 def points : Finset ℕ : {0, 1, 2, 3, 4, 5, 6} def blocks : Finset (Finset ℕ) : {{0,1,3}, {1,2,4}, {2,3,5}, {3,4,6}, {4,5,0}, {5,6,1}, {6,0,2}} -- 证明这是一个设计 theorem fano_is_steiner : Design points blocks 2 3 : by -- 需要证明两点 -- 1. 所有块的大小都是3 (trivial由blocks定义可知) -- 2. 任意2-子集点对恰好被一个块包含 -- 我们可以通过穷举来证明因为集合很小 apply Design.mk · intro b hb simp [blocks, Finset.mem_filter] at hb -- 这里需要证明b的势为3实际上blocks中的每个集合显式是3个元素 -- 一种方法是直接decide所有情况 fin_cases hb ; decide · intro p hp -- p是points的一个2-子集 have : p ⊆ points : hp.1 -- 穷举points的所有2-子集检查每个是否在恰好一个块中 -- 由于对称性可以简化证明但这里为清晰起见我们使用计算证明 simp [points] at hp -- 将p的具体值枚举出来然后检查 fin_cases hp ; -- 这会生成所有21种情况 simp [blocks, Design.incidence_set] -- 每个case后需要证明该点对只出现在一个特定的块中 -- 这里需要具体的证明脚本略去细节...Lean验证将上述代码补充完整细节后提交给Lean。Lean的类型检查器会逐行验证。decide和simp等策略可以自动处理有限的枚举情况。编译成功定理fano_is_steiner被正式验证。输出发现过程叙述“系统在第一轮即由猜想家智能体基于Fano平面的类比成功提出了S(2,3,7)的一个模7循环构造。经检验者验证该构造满足斯坦纳三元系的所有公理。”可验证证明完整的Lean代码文件fano_steiner.lean。这个案例虽然简单但完整展示了从问题输入、智能体协作、验证到形式化证明生成的闭环。对于更复杂的设计迭代轮数会显著增加但框架是通用的。5. 遇到的挑战、解决方案与未来展望在实际构建和测试这个系统的过程中我们遇到了不少预料之中和预料之外的困难。5.1 主要挑战与应对策略LLM的“幻觉”与不稳定性这是最大的挑战。猜想家经常会提出看似合理、但完全错误的数学类比或者检验者的解析器会错误地形式化一个正确的猜想。解决方案强化提示词约束如前所述使用严格的输出格式JSON、角色扮演和少样本示例。验证前置在猜想家输出后、正式提交检验前增加一个“合理性自检”步骤。让同一个LLM或另一个小模型快速评估猜想是否明显违背已知数学常识例如提出一个v6的S(2,3,6)而众所周知这是不存在的。这可以过滤掉一部分低级错误。多数投票与集成对于关键步骤如解析让多个LLM实例如GPT-4、Claude 3同时进行选择输出最一致或置信度最高的结果。符号验证的规模限制穷举验证只适用于小型实例。对于参数化猜想或稍大点的实例符号引擎如Z3可能面临状态爆炸或者根本无法表达复杂的组合存在性命题。解决方案分层抽象不要求一次性验证完整构造。先验证构造方法的关键引理例如“按此规则生成的集合其大小是3”。验证通过后再在Lean中以此引理为基础进行完整证明。与Lean深度集成直接将验证任务转化为在Lean中证明一个更简单的辅助定理lemma。让Lean的自动化策略auto,omega,linarith或可调用的小型决策过程decide来完成验证。这样验证本身也成了形式化证明的一部分。证明生成的巨大鸿沟让LLM直接从自然语言猜想生成完整的、正确的Lean证明难度极高。解决方案采用“人类指导的交互式证明生成”。我们不完全自动化而是让系统在生成证明大纲和关键步骤后允许人类专家介入提供一些高级的证明策略tactic提示或者帮助分解子目标。系统记录这些交互用于微调LLM或作为后续类似问题的参考。这更像是一个“AI辅助证明编写器”而非全自动证明生成器。5.2 性能优化与工程实践缓存对已验证过的子目标、常见的LLM响应进行缓存避免重复计算和API调用显著降低成本和时间。异步与流式处理将猜想生成、解析、验证等步骤设计为异步流水线。当猜想家在思考下一个猜想时检验者可以并行验证上一个猜想提升系统吞吐量。成本控制使用混合模型策略。轻量级的反思、总结任务使用便宜的小模型如GPT-3.5关键性的猜想生成和解析使用能力强的大模型。精确记录每个任务的Token消耗设置预算上限。5.3 未来方向与扩展思考这个案例只是一个起点。这套“Agentic Neurosymbolic Collaboration”的框架有巨大的扩展潜力更复杂的数学领域从组合设计扩展到图论、数论、多项式代数等领域。关键在于为这些领域构建丰富的、形式化的“背景知识库”如扩展Mathlib的使用范围并设计领域特定的提示词模板和验证策略。更多样化的智能体角色除了猜想家和检验者可以引入推广者尝试将特定构造推广到更一般的情形、反驳者专门寻找反例或证明不可能性、简化者优化已有的复杂构造等。形成一个更丰富的“研讨班”式多智能体系统。从验证到发现目前系统主要解决“构造验证”问题。下一步是挑战“猜想提出”本身。例如给定一个组合设计族让智能体协作去发现其中未知的不变量、对称性甚至提出新的、有趣的猜想供人类数学家研究。教育应用这个系统可以作为一个交互式的“数学研究训练模拟器”。学生可以提出自己的构造思路由检验者智能体指出逻辑漏洞由猜想家智能体提供启发性的类比从而在互动中深入学习数学证明的严谨性和创造性。回过头看这个项目的最大价值不在于它解决了某个特定的数学问题S(2,3,7)的构造早已为人所知而在于它成功地将前沿的AI智能体技术与严谨的数学形式化验证连接起来搭建了一条从模糊的直觉灵感到精确的逻辑验证再到最终可存档、可复现的形式化证明的可行路径。它证明了通过精心的架构设计我们可以让大语言模型这种“统计关联大师”在符号逻辑的框架内有效地工作发挥其创造力同时用严格的规则来约束和引导它。在实际操作中最深的体会是提示词工程和系统流程设计其重要性不亚于模型本身。一个鲁棒的、能处理错误和反馈循环的流程远比一个强大的但孤立的模型要有用得多。同时永远不要指望AI一步到位。将大问题分解成小步骤在每个步骤上设立清晰的、可验证的里程碑让AI和符号工具各司其职才是让这类复杂系统跑起来的关键。 多智能体协作与形式化验证：AI解决组合设计问题的实践探索
1. 项目概述当AI学会“左右互搏”来解数学题最近在AI圈子里“Agentic”智能体化和“Neurosymbolic”神经符号这两个词的热度是越来越高。简单来说这代表了一种新的AI研究范式不再是让一个单一的、庞大的模型去“蛮干”而是让多个具备不同“思维模式”的智能体Agent协同工作把神经网络的直觉感知能力和符号逻辑的严谨推理能力结合起来。这听起来有点像武侠小说里的“左右互搏”让感性的右脑和理性的左脑一起上阵。而我们这个项目就是把这个听起来很前沿的理念实实在在地用到了一个非常经典的数学领域——组合设计Combinatorial Design上并且用Lean 4这个形式化验证工具作为最终的“裁判”和“记录员”。组合设计是什么你可以把它想象成一种高级的“编排艺术”。比如学校要组织一场循环赛有7支队伍要求每支队伍每天只打一场比赛并且任何两支队伍在整个赛程中只相遇一次。怎么排这个赛程表这就是一个典型的组合设计问题具体来说是“斯坦纳三元系”问题。这类问题在实验设计、编码理论、网络调度等领域有着极其重要的应用。传统上解决这类问题要么靠数学家精巧的构造性证明要么靠计算机进行穷举搜索两者都有其局限性。我们这个项目的核心目标就是探索如何让大语言模型LLM驱动的智能体模仿数学家“发现”和“验证”组合设计的过程。我们不是简单地让LLM去“猜”一个解而是设计了一个多智能体协作框架一个“直觉型”智能体负责提出大胆的猜想和构造思路发挥神经网络的联想能力一个“严谨型”智能体负责用逻辑规则去检验和修正这些猜想发挥符号系统的推理能力它们相互辩论、相互完善。最后所有达成一致的、正确的推导步骤都会被翻译成Lean 4的代码形成一个可以被机器百分百验证的、无可争议的数学证明。这不仅仅是解决了一个具体的数学问题更是一次对AI如何实现真正“推理”和“发现”的方法论探索。它展示了如何将LLM的创造力引导到严谨的数学框架内为未来AI辅助数学研究、甚至进行自主科学发现提供了一个可复现的案例。接下来我就把这个项目的设计思路、实现细节、踩过的坑以及背后的思考毫无保留地分享给大家。2. 核心架构设计构建一个“辩论式”智能体协作系统整个系统的设计灵感来源于数学研究中的常见场景灵感迸发猜想与严格验证证明的反复循环。我们摒弃了让单个LLM“既当运动员又当裁判”的做法而是将其拆解为两个角色分明、能力互补的智能体。2.1 双智能体角色定义与分工我们设计了两个核心智能体猜想家Conjecturer和检验者Verifier。它们的职责和“性格”截然不同。猜想家智能体由一个大语言模型例如GPT-4、Claude 3或开源的DeepSeek驱动。它的核心任务是“发散思维”。输入当前要解决的组合设计问题的形式化描述例如“构造一个阶数为v7的斯坦纳三元系S(2,3,7)”以及当前已部分构建的结构或之前失败的尝试历史。处理它利用LLM在大量数学文本和代码上训练出的模式识别能力进行类比联想。它可能会说“这看起来很像一个有限射影平面的结构也许我们可以从Fano平面7个点的最小射影平面入手尝试将其解释为一个三元系。” 或者它会提出一个具体的构造算法“尝试用模运算的方法以模7的剩余类为基础生成所有形如{i, i1, i3}的三元组。”输出一个具体的、用自然语言或类伪代码描述的构造猜想以及一段解释其为何可能可行的“直觉性”论证。检验者智能体则是一个神经符号混合体。它同样有一个LLM作为“解析器”但背后连接着一个符号推理引擎我们集成了一个简单的定理证明器如Z3或直接调用Lean的API进行小范围检查。输入猜想家提出的构造猜想。处理解析与形式化其内部的LLM首先将猜想家的自然语言描述翻译成精确的、无歧义的逻辑断言或数据结构定义。这是关键一步任何模糊性都必须在这里被消除。符号验证将这些形式化的断言喂给符号推理引擎。引擎会检查该构造是否满足组合设计的所有公理如每对元素恰好同时出现在一个三元组中。对于小型实例它可能进行穷举检查对于有参数的猜想它可能尝试进行符号推导。输出一个明确的验证结果“通过”、“失败”或“条件性通过”。如果失败必须提供反例或指出违反的公理。例如检验者可能回复“你提出的模7构造方案中元素对(1, 4)同时出现在三元组{1,2,4}和{1,4,5}中违反了‘每对元素恰好出现一次’的规则。”这两个智能体被放置在一个迭代辩论循环中。猜想家提出想法检验者挑刺。如果被驳回检验者的反馈反例会成为猜想家下一轮思考的重要输入驱动它修正猜想。这个过程循环往复直到检验者给出“通过”的判决或者循环次数达到上限。2.2 Lean 4作为“终审法庭”与知识锚点为什么选择Lean 4因为它不是普通的编程语言而是一个依赖类型的形式化证明语言。在Lean里写一段代码就是构建一个证明类型检查器就是最严格的法官。任何逻辑跳跃、未声明的假设都逃不过它的审查。在我们的系统中Lean 4扮演两个核心角色最终验证器当双智能体协作产出一个“通过”的构造方案后我们需要生成一个Lean 4定理theorem及其证明proof。这个证明会详细描述该组合设计对象的构造过程并证明它满足所有性质。Lean内核会对整个证明链进行终极验证确保从基础公理到最终结论每一步都滴水不漏。这相当于为AI的发现过程提供了一个数学上的“公证”。交互式反馈源在智能体协作的中间阶段我们也可以让Lean提供轻量级反馈。例如猜想家生成一段Lean代码片段后可以立即运行Lean检查是否有语法错误或简单的类型错误。这比等待完整的符号验证更快能快速纠正低级错误引导LLM写出更正确的形式化表述。更重要的是Lean及其庞大的数学库Mathlib为我们的智能体提供了一个精确的、结构化的知识库。我们可以让智能体在提出猜想时引用Mathlib中已有的定义和定理如Finset,Setoid, 组合设计的基本定义design等这极大地提升了猜想的质量和可验证性。它让AI的“思考”扎根于坚实的数学基础之上而不是在模糊的自然语言概念中飘荡。2.3 协作流程与通信协议整个系统的运行流程是一个标准的多轮对话循环但带有强烈的目标导向初始化用户输入一个组合设计问题P。系统初始化猜想家和检验者并将P传递给猜想家。猜想生成轮猜想家基于P和历史对话生成一个猜想C_i和解释E_i。检验轮检验者接收C_i。其LLM解析器先将C_i形式化为F_i然后符号引擎验证F_i。产生结果R_i通过/失败反馈Fb_i。判决与迭代若R_i为“通过”流程进入证明生成阶段。若R_i为“失败”系统将(C_i, R_i, Fb_i)追加到对话历史中然后将该历史和原问题P一起作为新的输入发送给猜想家启动下一轮回到步骤2。提示词会强调“你之前的猜想C_i因Fb_i被驳回。请分析这个反例修正你的思路提出一个新的猜想。”证明生成阶段一旦猜想C_k被检验通过一个专门的证明编写智能体可由检验者或一个第三方智能体担任被激活。它利用整个对话历史特别是被验证通过的构造步骤编写出完整的Lean 4证明代码。随后调用Lean进行编译验证。输出最终输出两份成果一份是人类可读的、包含迭代历史的发现过程叙述一份是机器可验证的、纯净的Lean 4证明文件。这个协议的关键在于反馈Fb_i必须是具体、可操作的。模糊的“这不对”毫无帮助。“元素对(x, y)在多个块中出现”这样的反馈才能引导LLM进行有针对性的修正。3. 关键技术实现与工具链搭建理论设计得再漂亮落地时全是细节。这一部分我带你看看我们具体是怎么搭起这个系统的以及其中那些容易踩坑的地方。3.1 LLM的选型与提示词工程LLM是整个系统的“大脑”其选择和质量直接决定了智能体的表现。选型考量闭源 vs 开源像GPT-4、Claude 3这样的闭源模型在复杂推理和遵循指令方面表现卓越是快速验证想法原型的利器。但考虑到成本、可控性和数据隐私长期来看需要探索开源模型。我们试验了DeepSeek-Coder、CodeLlama和MathCoder等专门在代码和数学数据上微调过的模型。发现它们在代码生成上不错但在深度的、多步的数学类比推理上与顶级闭源模型仍有差距。关键能力对于猜想家我们需要强大的类比推理和创造性思维能力。对于检验者中的解析器我们需要极致的精确性和指令遵循能力确保翻译无歧义。我们最终为猜想家选择了创造性更强的Claude 3为检验者解析器选择了更严谨的GPT-4。提示词设计是灵魂。绝不能简单地说“你是一个数学助手”。我们的提示词是高度结构化、包含角色、规则和示例的“剧本”。猜想家提示词核心要素你是一位富有创造力的组合数学家。你的目标是为组合设计问题提出新颖的构造猜想。 问题{problem_statement} 历史对话最新在最前 {history} --- 规则 1. 你的输出必须是纯粹的猜想和解释不要包含验证步骤。 2. 猜想应尽可能具体可以是算法描述、数学公式或结构类比。 3. 如果历史中有反馈你必须直接回应它解释你如何根据反馈改进了猜想。 4. 优先考虑使用Mathlib中已有的概念如Finset, Set, design。 --- 示例对于另一个问题 用户构造一个4阶完全图K_4的边着色使得任意两条相邻边颜色不同且使用颜色最少。 助理猜想家猜想K_4的边可以用3种颜色着色。构造方法将四个顶点标号为0,1,2,3。对于边(i,j)其颜色定义为 (ij) mod 3。这是一种可能的循环着色方案。 --- 现在请基于当前问题和历史提出你的下一个猜想。这个提示词明确了角色、任务提供了上下文历史规定了输出格式并给出了一个类似任务的示例Few-shot Learning极大地稳定了输出质量。检验者解析器提示词核心要素你是一个严格的数学逻辑翻译器。你的任务是将自然语言描述的数学猜想转化为精确的、可被符号引擎验证的断言。 猜想{conjecture} --- 规则 1. 输出必须是单一的、无嵌套的JSON对象。 2. JSON格式{objects: [对象1定义, 对象2定义...], properties: [需要验证的性质1, 性质2...]} 3. 定义必须使用标准的集合论和逻辑符号∈, ⊆, ∀, ∃, ∧, ∨, →。 4. 所有涉及的对象如集合、函数必须显式声明其域和陪域。 --- 示例 输入猜想“集合{1,2,3}的所有2-子集构成的集合。” 输出{objects: [Let A {1, 2, 3}, Let B { {1,2}, {1,3}, {2,3} }], properties: [B { S | S ⊆ A ∧ |S| 2 }]} --- 现在请翻译给定的猜想。通过强制JSON输出和严格的形式化要求我们最大限度地减少了LLM的“自由发挥”得到了结构化的、可供下游符号引擎消费的数据。3.2 符号推理引擎的轻量化集成我们并不需要实现一个能证明一切的全能定理证明器。对于组合设计验证很多情况下是检查一个有限结构是否满足若干条公理。这本质上是模型检测问题。我们的策略是分层验证轻量级快速检查针对小型实例如果猜想描述的是一个具体的小型设计比如v15我们直接用Python生成这个结构如所有三元组的列表然后编写简单的脚本检查公理。例如检查“每对点恰好出现一次”就计算所有点对的出现次数。这速度极快能立刻给LLM反馈。中等规模或参数化检查对于参数化的猜想如“对所有形如v6k1的整数存在…”我们集成Z3或SymPy这样的约束求解器/符号计算库。我们将组合设计的公理编码为约束条件然后让求解器去寻找一个解验证存在性或证明无解。虽然不能处理非常复杂的数学归纳但对于许多组合构造这已经非常强大。终极验证接口对于所有通过前两步检查的猜想其最终证明都会导向Lean。我们实现了一个简单的Lean服务器客户端。证明编写智能体生成的Lean代码会通过这个客户端发送到本地运行的Lean服务进行批处理编译。lean --make MyProof.lean如果编译成功返回0则证明有效如果失败编译器的错误信息会作为反馈返回给智能体进行修正。注意直接让LLM生成大段Lean证明成功率很低。我们的策略是“分而治之”先让智能体用自然语言写出证明大纲然后将大纲分解成一个个独立的引理Lemma再为每个引理分别生成Lean证明。最后用have和calc等策略将它们组合起来。这大大降低了单次生成的难度。3.3 迭代循环中的状态管理与反思机制多轮对话中状态管理至关重要。我们不能让LLM忘记过去。我们维护的核心状态包括完整对话历史所有轮次的(猜想 检验结果 反馈)三元组。已验证的子目标在探索过程中可能先验证了某个构造满足部分性质例如所有块的大小正确。这些已验证的子目标会被缓存后续猜想可以在此基础上构建避免重复验证。失败模式库记录常见的失败原因如“某对点出现次数1”“某个块大小不对”。当新的失败出现时系统可以提示LLM“注意这看起来是‘点对重复’类错误请重点检查你构造的对称性。”此外我们引入了反思机制。在连续多次失败如5次后系统不会直接进入下一轮而是会触发一个“元认知”提示要求猜想家智能体暂停提出新猜想而是分析历史失败记录总结规律调整自己的问题解决策略。例如回顾你最近5次失败的猜想。它们被驳回的主要原因都集中在“点对重复”上。这表明你当前的构造方法可能缺乏某种整体对称性。请暂时停止提出具体猜想而是思考在组合设计理论中有哪些常见的对称构造方法如循环群作用、有限域上的运算可以避免这种重复请列出两到三种高阶策略然后再应用其中一种策略来生成下一个具体猜想。这种强制性的“停下来想一想”能有效打破LLM在低效模式中的循环引导它进行策略层面的提升模仿了人类研究者遇到瓶颈时的思考方式。4. 实战案例构造S(2,3,7)斯坦纳三元系光说不练假把式。让我们看一个完整的、简化的运行实例目标是构造最小的非平凡斯坦纳三元系S(2,3,7)即7个点每3个点组成一个块每对点恰好出现在一个块中共有7个块。初始状态问题P: “构造一个斯坦纳三元系S(2,3,7)即一个点集V|V|7和一系列三元组块的集合B满足∀v∈V, 包含v的块数相同且∀{x,y}⊆V, 存在唯一b∈B使得{x,y}⊆b。”历史: []空第一轮猜想家基于对有限射影平面的联想“猜想这个三元系同构于Fano平面。构造令点集V {0,1,2,3,4,5,6}。块集合B为{0,1,3}, {1,2,4}, {2,3,5}, {3,4,6}, {4,5,0}, {5,6,1}, {6,0,2}。这是一种模7的循环构造。”检验者解析器将猜想形式化为V {0,...,6};B [列表上述7个集合]; 待验证性质1. B中每个集合大小为3。2. 任意两个不同点i, j在B中恰好同时出现一次。符号引擎快速Python脚本检查性质1通过。检查性质2时发现点对(0,1)出现在块{0,1,3}中但点对(0,1)没有出现在其他块等等检查发现(0,1)只出现了一次很好。继续检查所有点对… 发现点对(0,2)出现在块{6,0,2}中也只出现一次。… 检查所有21个点对全部恰好出现一次。结果通过。系统判决第一轮就通过了进入证明生成阶段。证明生成阶段证明编写智能体接收通过的构造和完整历史。它生成Lean代码框架import Mathlib.Combinatorics.Design open Finset -- 定义点集和块集 def points : Finset ℕ : {0, 1, 2, 3, 4, 5, 6} def blocks : Finset (Finset ℕ) : {{0,1,3}, {1,2,4}, {2,3,5}, {3,4,6}, {4,5,0}, {5,6,1}, {6,0,2}} -- 证明这是一个设计 theorem fano_is_steiner : Design points blocks 2 3 : by -- 需要证明两点 -- 1. 所有块的大小都是3 (trivial由blocks定义可知) -- 2. 任意2-子集点对恰好被一个块包含 -- 我们可以通过穷举来证明因为集合很小 apply Design.mk · intro b hb simp [blocks, Finset.mem_filter] at hb -- 这里需要证明b的势为3实际上blocks中的每个集合显式是3个元素 -- 一种方法是直接decide所有情况 fin_cases hb ; decide · intro p hp -- p是points的一个2-子集 have : p ⊆ points : hp.1 -- 穷举points的所有2-子集检查每个是否在恰好一个块中 -- 由于对称性可以简化证明但这里为清晰起见我们使用计算证明 simp [points] at hp -- 将p的具体值枚举出来然后检查 fin_cases hp ; -- 这会生成所有21种情况 simp [blocks, Design.incidence_set] -- 每个case后需要证明该点对只出现在一个特定的块中 -- 这里需要具体的证明脚本略去细节...Lean验证将上述代码补充完整细节后提交给Lean。Lean的类型检查器会逐行验证。decide和simp等策略可以自动处理有限的枚举情况。编译成功定理fano_is_steiner被正式验证。输出发现过程叙述“系统在第一轮即由猜想家智能体基于Fano平面的类比成功提出了S(2,3,7)的一个模7循环构造。经检验者验证该构造满足斯坦纳三元系的所有公理。”可验证证明完整的Lean代码文件fano_steiner.lean。这个案例虽然简单但完整展示了从问题输入、智能体协作、验证到形式化证明生成的闭环。对于更复杂的设计迭代轮数会显著增加但框架是通用的。5. 遇到的挑战、解决方案与未来展望在实际构建和测试这个系统的过程中我们遇到了不少预料之中和预料之外的困难。5.1 主要挑战与应对策略LLM的“幻觉”与不稳定性这是最大的挑战。猜想家经常会提出看似合理、但完全错误的数学类比或者检验者的解析器会错误地形式化一个正确的猜想。解决方案强化提示词约束如前所述使用严格的输出格式JSON、角色扮演和少样本示例。验证前置在猜想家输出后、正式提交检验前增加一个“合理性自检”步骤。让同一个LLM或另一个小模型快速评估猜想是否明显违背已知数学常识例如提出一个v6的S(2,3,6)而众所周知这是不存在的。这可以过滤掉一部分低级错误。多数投票与集成对于关键步骤如解析让多个LLM实例如GPT-4、Claude 3同时进行选择输出最一致或置信度最高的结果。符号验证的规模限制穷举验证只适用于小型实例。对于参数化猜想或稍大点的实例符号引擎如Z3可能面临状态爆炸或者根本无法表达复杂的组合存在性命题。解决方案分层抽象不要求一次性验证完整构造。先验证构造方法的关键引理例如“按此规则生成的集合其大小是3”。验证通过后再在Lean中以此引理为基础进行完整证明。与Lean深度集成直接将验证任务转化为在Lean中证明一个更简单的辅助定理lemma。让Lean的自动化策略auto,omega,linarith或可调用的小型决策过程decide来完成验证。这样验证本身也成了形式化证明的一部分。证明生成的巨大鸿沟让LLM直接从自然语言猜想生成完整的、正确的Lean证明难度极高。解决方案采用“人类指导的交互式证明生成”。我们不完全自动化而是让系统在生成证明大纲和关键步骤后允许人类专家介入提供一些高级的证明策略tactic提示或者帮助分解子目标。系统记录这些交互用于微调LLM或作为后续类似问题的参考。这更像是一个“AI辅助证明编写器”而非全自动证明生成器。5.2 性能优化与工程实践缓存对已验证过的子目标、常见的LLM响应进行缓存避免重复计算和API调用显著降低成本和时间。异步与流式处理将猜想生成、解析、验证等步骤设计为异步流水线。当猜想家在思考下一个猜想时检验者可以并行验证上一个猜想提升系统吞吐量。成本控制使用混合模型策略。轻量级的反思、总结任务使用便宜的小模型如GPT-3.5关键性的猜想生成和解析使用能力强的大模型。精确记录每个任务的Token消耗设置预算上限。5.3 未来方向与扩展思考这个案例只是一个起点。这套“Agentic Neurosymbolic Collaboration”的框架有巨大的扩展潜力更复杂的数学领域从组合设计扩展到图论、数论、多项式代数等领域。关键在于为这些领域构建丰富的、形式化的“背景知识库”如扩展Mathlib的使用范围并设计领域特定的提示词模板和验证策略。更多样化的智能体角色除了猜想家和检验者可以引入推广者尝试将特定构造推广到更一般的情形、反驳者专门寻找反例或证明不可能性、简化者优化已有的复杂构造等。形成一个更丰富的“研讨班”式多智能体系统。从验证到发现目前系统主要解决“构造验证”问题。下一步是挑战“猜想提出”本身。例如给定一个组合设计族让智能体协作去发现其中未知的不变量、对称性甚至提出新的、有趣的猜想供人类数学家研究。教育应用这个系统可以作为一个交互式的“数学研究训练模拟器”。学生可以提出自己的构造思路由检验者智能体指出逻辑漏洞由猜想家智能体提供启发性的类比从而在互动中深入学习数学证明的严谨性和创造性。回过头看这个项目的最大价值不在于它解决了某个特定的数学问题S(2,3,7)的构造早已为人所知而在于它成功地将前沿的AI智能体技术与严谨的数学形式化验证连接起来搭建了一条从模糊的直觉灵感到精确的逻辑验证再到最终可存档、可复现的形式化证明的可行路径。它证明了通过精心的架构设计我们可以让大语言模型这种“统计关联大师”在符号逻辑的框架内有效地工作发挥其创造力同时用严格的规则来约束和引导它。在实际操作中最深的体会是提示词工程和系统流程设计其重要性不亚于模型本身。一个鲁棒的、能处理错误和反馈循环的流程远比一个强大的但孤立的模型要有用得多。同时永远不要指望AI一步到位。将大问题分解成小步骤在每个步骤上设立清晰的、可验证的里程碑让AI和符号工具各司其职才是让这类复杂系统跑起来的关键。