如果说大模型已经在代码生成、数学竞赛题解上表现得像一个“解题高手”那“自主数学发现”就是一个完全不同的游戏它不给你题目不告诉你哪里有定理甚至不保证你正在探索的方向一定有意义。过去几年AI 在数学上最出圈的成果基本集中在“解已知难题”和“验证已有证明”两条线上。而“发现”这件事比如从一组公理出发找到一条新的定理或者在一个开放的数系里发现未被记录的运算规律仍然是数学家和 AI 研究者共同面对的高难度课题。这里有一个关键判断单智能体的数学推理模型本质上是在做“沿着已有知识向前推一步”的搜索而真正的数学发现需要多个智能体在开放环境里彼此质疑、互相修正、持续迭代。换句话说自主数学发现不是一个推理问题而是一个多智能体协作与对抗问题。这篇文章会围绕“开放世界多智能体环境中的自主数学发现”这个主题展开讲清楚三件事第一为什么数学发现适合用多智能体架构而不是更大的单模型 第二如何设计一个“开放世界”式的数学探索环境让智能体不是只在固定数据集上做题 第三怎么用“正反博弈 裁判”的模式把“发现”变成可验证、可追溯、可迭代的工程流程。如果你正在研究多智能体系统、LLM Agent 的落地场景或者对“AI 如何辅助数学研究”感兴趣这篇文章会给你一个可以直接参考的架构思路以及一份能跑通的最小示例代码。1. 这篇文章真正要解决的问题在开始写代码之前先回答一个更根本的问题为什么“让 AI 做数学题”和“让 AI 发现数学”差了十万八千里普通的数学解题比如让模型解一道微分方程、证明一个给定的不等式本质上是一个有明确终点的搜索问题。模型知道目标是什么也知道什么算做对了。哪怕过程很曲折最终的验证成本很低——重新算一遍或者让另一个模型检查证明就能判断对错。数学发现则是另一回事。它的典型特征是目标未知。你不知道这个方向能不能走通甚至不知道“发现一个定理”这个行为本身应该用什么奖励函数来驱动。验证困难。一条新命题可能既不是显然正确也不是显然错误。它需要被证明而证明过程本身可能又会产生新的未解问题。价值需要外部评判。一个数学结论的价值不只在于“真”还在于它是否深刻、是否有用、是否能关联到其他数学分支。在这种场景下单个模型的推理能力再强也只是一个“思考者”。它无法解决“这个想法靠不靠谱”“这个证明有没有漏洞”“这个方向和已有理论能不能接上”这些需要多视角验证的问题。这正是多智能体架构进入的时机。所以本文真正要解决的问题可以概括成一句如何在开放式的数学探索任务中用多个智能体的对抗、合作和评判替代人类数学家在纸面上的反复推演从而让“数学发现”从一次性推理变为可持续扩展的分布式认知过程。读完这篇文章你会掌握一个开放世界数学探索环境的最小设计框架生成者、挑战者、裁判三角色构成的协作博弈架构在 Python 中搭建这种多智能体系统的最小示例判断系统是否“真的在发现数学”而不是在“自说自话”的评估方案。2. 基础概念与核心原理2.1 什么是自主数学发现自主数学发现Autonomous Mathematical Discovery可以理解为机器在一个形式化的数学环境中自主地提出命题、构造证明、验证结论并将新结论纳入自己的知识库继续推进后续探索。这个定义里最关键的词是“自主”。这意味着系统不能依赖人类给它布置具体题目。它的输入是公理系统、已有的定理库和推理规则输出则是新发现的定理、证明以及探索日志。与经典的自动定理证明ATP不同自主数学发现强调的不是“证明一个给定定理”而是“决定研究什么”。后者更像科学家的工作模式先猜想再验证然后修正循环往复。2.2 为什么需要多智能体数学发现天然是一个多视角工作。一个数学家提出猜想时通常会对“这个猜想对不对”有强烈的直觉判断但要让这个猜想成为定理需要有人严格证明而证明本身又经常需要另一个数学家来审阅找其中的漏洞。这种分工可以用三种智能体来模拟生成者Proposer / Generator负责提出新命题、给出证明草图、构造反例。它倾向于大胆探索产出方向性想法。挑战者Challenger / Critic负责攻击生成者的结论。它尝试找反例、找证明漏洞、检查边界条件。它的职责是让系统不轻易满足于“看起来对”。裁判Judge / Verifier在生成者和挑战者无法达成一致时做出裁决。它维护一个“已确认知识库”判定哪些结论可以被接受哪些需要打回重来。这个三角色结构就是“正反博弈 裁判”的核心含义。它和单纯让多个模型投票选答案的做法有本质差别投票只是在多个候选中选一个而博弈过程会产生新的候选、修正旧的候选是一个动态演化的过程。2.3 什么是“开放世界”环境开放世界Open World这个词借自游戏和人工智能规划领域。在数学发现场景下它指的是环境不预设“最终通关目标”智能体可以自由选择探索方向环境的状态空间会随探索过程不断扩展不同智能体看到的环境状态可能不同但没有统一的“标准答案”。对应到工程实现一个开放世界数学环境通常包含四个组成模块形式化语言、状态空间、动作接口、验证机制。模块作用数学发现场景中的体现形式化语言定义命题、证明、对象的标准语法一阶逻辑、类型论、或定义好的 Python 表达式语法状态空间记录当前已知的定理、定义、对象一个定理库、一组公理、已证明的引理动作接口智能体与环境的交互方式提出命题、提交证明、申请验证、查询已有定理验证机制确认一个结论是否成立手工编写的模型检查器、或形式化证明工具需要注意的是这里的“开放世界”不是指自然语言文本构成的知识海洋而是一个由符号规则定义、但探索边界不固定的结构化环境。这一点决定了我们后面写代码时的核心抽象。3. 开放世界数学发现环境的总体设计在设计多智能体系统之前先想清楚环境接口。一个好的环境设计应该让智能体不需要关心底层是用的自然语言模型、符号推理引擎还是形式化验证工具只需要关心“我能做什么动作、动作失败意味着什么”。那问题来了怎么让不同技术栈的智能体共享同一个环境答案是把“数学对象”和“动作语义”抽象成统一接口。这里给出一个相对精简但可扩展的设计。3.1 架构划分整个系统分成四层应用层探索任务定义、结果展示 协作层生成者、挑战者、裁判的调度逻辑 环境层数学对象存储、推理规则、验证服务 基础设施层LLM API、符号计算库、证明工具每一层职责独立。环境层不关心生成者是 GPT 还是开源模型也不关心推理是用 Python 的 sympy 还是外部证明器。协作层只关心动作序列和反馈信号。3.2 状态与消息系统中最重要的数据结构是两个Theorem命题描述一个待验证或已验证的数学陈述。Message消息智能体之间的通信单元包含发送者、接收者或广播、内容类型命题、证明、质疑、裁决、附件。这两个结构要能放进 JSON 或者 Python 字典里才能在智能体之间传递。具体定义在后面代码中给出。3.3 动作接口开放世界环境向智能体暴露的动作接口至少应该包括以下几类propose(statement)提出一个新命题。submit_proof(statement, proof_steps)为一个命题提交证明过程。challenge(statement, reason)对一个命题发起质疑理由可以是反例、证明漏洞、或者边界条件未覆盖。query_theorems(keyword)查询已知定理库。accept(revision)接受某条结论将它加入定理库。reject(reason)拒绝某条结论。动作本身是抽象的具体实现可以对接不同后端。4. 基于“正反博弈 裁判”的多智能体协作机制把上述环境设计落实到协作层接下来给出最核心的机制生成者、挑战者、裁判之间的博弈循环。4.1 角色定义生成者Proposer生成者的职能是发现。它的输入是当前定理库中的已有结论、公理集合、以及探索历史输出是一个新的命题和一个尽量完整的论证。在实际实现中生成者可以由一个大语言模型承担也可以用符号搜索算法加上 LLM 辅助。在本文的示例里为了照顾可读性我用一个模拟函数代表生成者内部的推理过程真正使用时替换为模型调用即可。挑战者Challenger挑战者的职能是证伪。它会仔细检查生成者提交的证明寻找逻辑跳跃、未讨论的边界条件、以及可能存在的反例。这里有一个容易被忽视的设计点挑战者不能只做“对/错”二分类判断它应该输出“质疑理由”。这些理由会成为生成者进行修正的依据。如果挑战者只会说“你错了”生成者无法迭代改进。裁判Judge裁判的职责是仲裁。当生成者和挑战者相持不下时裁判根据代码逻辑、形式化工具结果以及自身推理给出“接受 / 拒绝 / 返回修改”三种裁决。裁判必须被设计成“最谨慎”的角色。它的判断不应该基于概率感觉而应该尽量依赖可计算的验证过程。如果条件允许裁判应该调用形式化验证工具Lean、Isabelle 等做最终确认。在最小示例中我用一个“验证规则表”来模拟形式化验证。4.2 博弈循环一次完整的探索循环如下1. 环境初始化加载公理集与初始定理库。 2. 生成者根据当前定理库提出新命题 P并提交证明草案 D。 3. 挑战者审查 P 和 D - 若没有发现漏洞返回“未发现反例” - 若发现漏洞返回质疑理由。 4. 裁判评估争议 - 若挑战者未发现漏洞且程序 / 规则验证通过接受 P 进入定理库 - 若证明草案存在可修复漏洞将草案返回给生成者修改 - 若证明存在根本性错误拒绝 P并记录失败经验。 5. 将本轮结果写回“经验池”供下一轮生成者参考。 6. 重复 2-5直到达到迭代轮数上限或满足停止条件。这个循环本身很直观但工程实现里有三个关键细节。第一个细节是状态同步。多智能体系统运行在异步环境中生成者可能在挑战者还没审查完成时就提交了下一个命题。解决方法是引入“回合制”状态机每一轮只有一个生成命题在流程中流转挑战者和裁判完成后才进入下一轮。想提升吞吐量的话可以在后续改成流水线式并行但第一步不要这样做。第二个细节是上下文隔离。每个智能体应该只看它需要的信息。生成者不需要看到挑战者给出的所有质疑历史只需要看到被裁判“审核通过”的修正意见裁判则不应该被生成者的原始 prompt 干扰它只依据形式化验证结果做判断。第三个细节是失败信息的利用。被裁判拒绝的命题不要直接丢弃。把失败原因整理成“负向知识”让生成者在后续探索中避开同样的错误。5. 完整示例Python 实现一个最小多智能体数学发现系统下面进入代码部分。这个示例的目标不是做一个可以真正发现数学定理的完整系统那需要接入形式化证明器和更强的推理引擎而是把上面的设计思路变成可运行、可修改的骨架代码。5.1 环境与依赖示例使用 Python 3.9核心依赖如下需要安装的库 - sympy符号计算与表达式验证 - pydantic数据模型定义可选但推荐 - openai / 或者其他 LLM SDK如果要接入真实模型版本以实际环境为准本文示例的重点是架构思路不是绑定某个具体 SDK。5.2 数据模型定义先定义最基本的数学对象和消息结构。# 文件路径models.py from dataclasses import dataclass, field from enum import Enum from typing import List, Optional class StatementType(str, Enum): AXIOM axiom # 公理 LEMMA lemma # 引理 THEOREM theorem # 定理 CONJECTURE conjecture # 猜想 class VerificationStatus(str, Enum): UNVERIFIED unverified VERIFIED verified REJECTED rejected NEEDS_REVISION needs_revision dataclass class Theorem: 数学命题的容器 statement: str # 命题的数学表达式/描述 name: str # 命题名称 statement_type: StatementType StatementType.CONJECTURE proof_steps: List[str] field(default_factorylist) # 证明步骤 status: VerificationStatus VerificationStatus.UNVERIFIED dependencies: List[str] field(default_factorylist) # 依赖的已有定理 created_by: str system dataclass class Message: 智能体间通信消息 sender: str # 发送者角色proposer / challenger / judge receiver: Optional[str] # 接收者None 表示广播 msg_type: str # propose / proof / challenge / verdict content: str # 消息内容 theorem: Optional[Theorem] None # 关联的命题对象 metadata: dict field(default_factorydict)这里的关键设计是Theorem和Message都保持为纯数据对象不包含逻辑。所有验证逻辑都放在环境类中避免智能体绕过规则直接修改定理库。5.3 环境类定理库与验证规则环境类负责维护定理库并提供动作接口。# 文件路径environment.py from typing import List, Dict, Optional from models import Theorem, Message, VerificationStatus import sympy class MathEnvironment: 开放世界数学环境维护定理库提供验证接口 def __init__(self): self.theorems: Dict[str, Theorem] {} self.axioms: List[Theorem] [] self.exploration_log: List[Message] [] self._init_axioms() def _init_axioms(self): 初始化一组基础公理这里以算术为例 axioms [ Theorem( statementa b b a, name加法交换律, statement_typeaxiom, statusVerificationStatus.VERIFIED, ), Theorem( statementa * (b c) a*b a*c, name分配律, statement_typeaxiom, statusVerificationStatus.VERIFIED, ), ] for ax in axioms: self.theorems[ax.name] ax self.axioms.append(ax) def add_theorem(self, theorem: Theorem) - bool: 将验证通过的定理加入定理库 if theorem.name in self.theorems: return False self.theorems[theorem.name] theorem return True def query_theorems(self, keyword: str) - List[Theorem]: 按关键词检索已有定理 return [t for t in self.theorems.values() if keyword in t.statement] def log_message(self, msg: Message): self.exploration_log.append(msg) def verify_by_sympy(self, statement: str) - bool: 用符号计算验证一个等式的正确性 try: left, right statement.split() left_expr sympy.sympify(left.strip()) right_expr sympy.sympify(right.strip()) return sympy.simplify(left_expr - right_expr) 0 except Exception: return False def check_proof(self, theorem: Theorem) - VerificationStatus: 裁判调用此方法做最终验证。 这里演示两种验证方式 1. 如果命题可以直接用 sympy 验证比如等式直接验证 2. 否则检查证明步骤数量是否大于 0并检查依赖是否存在。 if in theorem.statement: if self.verify_by_sympy(theorem.statement): theorem.status VerificationStatus.VERIFIED return VerificationStatus.VERIFIED else: theorem.status VerificationStatus.REJECTED return VerificationStatus.REJECTED if len(theorem.proof_steps) 0: theorem.status VerificationStatus.REJECTED return VerificationStatus.REJECTED for dep in theorem.dependencies: if dep not in self.theorems: theorem.status VerificationStatus.REJECTED return VerificationStatus.REJECTED theorem.status VerificationStatus.VERIFIED return VerificationStatus.VERIFIED这里需要注意verify_by_sympy只适合验证等式类命题真实场景要接入更通用的验证后端。check_proof的“证明步骤数 0”判断只是一个占位逻辑实际项目中应当用形式化验证器或规则引擎替代。5.4 生成者、挑战者、裁判实现现在实现三个角色的核心逻辑。为了让示例不依赖外部 LLM API也便于读者直接运行这里用“模拟思考”的方式替代真实的模型调用。接入真实模型时只需要替换_generate_candidate、_review_candidate、_decide这三个函数的内部实现。# 文件路径agents.py import random from typing import Optional, Tuple from models import Theorem, Message, VerificationStatus class ProposerAgent: 生成者提出新命题和证明草案 def __init__(self, nameproposer): self.name name def propose(self, env) - Tuple[Theorem, str]: 根据当前定理库生成一个新命题。 这里用一个简单的规则生成恒等式作为演示。 existing list(env.theorems.values()) if not existing: return None, no theorems available # 从已有公理中随机选一条做简单变形 base random.choice(env.axioms) # 演示生成 (ab) c a (bc) 之类的结合律变形 statement (a b) c a (b c) name f结合律round{len(env.exploration_log)} theorem Theorem( statementstatement, namename, statement_typeTheorem_statement_type_CONJECTURE, proof_steps[ 应用加法公理进行符号整理, 两边展开后逐项对应, ], dependencies[base.name], created_byself.name, ) return theorem, propose new conjecture def revise(self, theorem: Theorem, feedback: str) - Theorem: 根据裁判反馈修订命题或证明 theorem.proof_steps.append(frevision: {feedback}) return theorem class ChallengerAgent: 挑战者尝试攻击生成者的命题和证明 def __init__(self, namechallenger): self.name name def challenge(self, env, theorem: Theorem) - Optional[str]: 检查命题的证明。 返回 None 表示没有发现问题返回字符串表示质疑原因。 # 演示逻辑如果证明步骤太少直接质疑 if len(theorem.proof_steps) 1: return proof steps is empty, cannot verify if theorem.statement_type conjecture: # 模拟概率性质疑特定情况下返回边界条件问题 if random.random() 0.3: return missing discussion of zero divisor case return None class JudgeAgent: 裁判最终裁决 def __init__(self, namejudge): self.name name def decide(self, env, theorem: Theorem, challenge_reason: Optional[str]) - VerificationStatus: # 先执行环境验证 env_status env.check_proof(theorem) if env_status VerificationStatus.REJECTED: return VerificationStatus.REJECTED if challenge_reason: # 有挑战质疑且环境验证未通过 - 返回修改 theorem.status VerificationStatus.NEEDS_REVISION return VerificationStatus.NEEDS_REVISION theorem.status VerificationStatus.VERIFIED return VerificationStatus.VERIFIED上段代码中有意保留了Theorem_statement_type_CONJECTURE这个占位写法实际运行请改为conjecture或StatementType.CONJECTURE避免直接复制时因名称错误导致编译失败。5.5 主循环把三个角色串起来下面的运行脚本把环境、三 Agent 放进一个回合制循环中。# 文件路径main.py from environment import MathEnvironment from agents import ProposerAgent, ChallengerAgent, JudgeAgent from models import Message, VerificationStatus def run_exploration(max_rounds: int 10): env MathEnvironment() proposer ProposerAgent() challenger ChallengerAgent() judge JudgeAgent() for round_idx in range(max_rounds): print(f\n Round {round_idx 1} ) # 1. 生成者提出命题 theorem, meta proposer.propose(env) if theorem is None: print(No theorem proposed, stop.) break print(f[Proposer] 提出命题: {theorem.name}) print(f statement: {theorem.statement}) # 2. 挑战者质疑 challenge_reason challenger.challenge(env, theorem) if challenge_reason: print(f[Challenger] 发起质疑: {challenge_reason}) else: print([Challenger] 未发现明显漏洞) # 3. 裁判裁决 result judge.decide(env, theorem, challenge_reason) print(f[Judge] 裁决结果: {result.value}) if result VerificationStatus.VERIFIED: env.add_theorem(theorem) print(f[System] 新定理已入库: {theorem.name}) elif result VerificationStatus.NEEDS_REVISION: revised proposer.revise(theorem, challenge_reason or unknown feedback) print(f[System] 命题返回修改当前证明步骤数: {len(revised.proof_steps)}) # 4. 记录日志 env.log_message(Message( senderproposer.name, receiverNone, msg_typeround_summary, contentfround {round_idx 1} result: {result.value}, theoremtheorem, )) print(\n 探索结束 ) print(f定理库中共有 {len(env.theorems)} 条定理/公理。) print(定理列表:) for name, t in env.theorems.items(): print(f - {name}: {t.statement}) if __name__ __main__: random_seed 0 import random random.seed(random_seed) run_exploration(max_rounds10)这里有一个细节在main.py中通过random.seed固定随机种子是为了让读者每次运行得到一致的结果。真实场景中不要固定种子因为探索的多样性本身就是系统能力的一部分。5.6 运行方式python main.py预期输出大致如下 Round 1 [Proposer] 提出命题: 结合律round0 statement: (a b) c a (b c) [Challenger] 未发现明显漏洞 [Judge] 裁决结果: verified [System] 新定理已入库: 结合律round0 Round 2 [Proposer] 提出命题: 结合律round1 statement: (a b) c a (b c) [Challenger] 发起质疑: missing discussion of zero divisor case [Judge] 裁决结果: needs_revision [System] 命题返回修改当前证明步骤数: 35.7 代码逻辑解读这段代码看起来简单但已经覆盖了多智能体数学发现系统的全部核心流程Theorem 结构保存了数学对象的状态状态贯穿整个探索过程MathEnvironment统一管理定理库和验证机制任何智能体都不能绕过环境直接修改知识ProposerAgent承担了探索的功能它可以选择提出哪种类型的命题ChallengerAgent的质疑会阻塞“入库”这保证了系统不会盲目接受未验证结论JudgeAgent的裁决是流程出口它把环境验证结果和挑战者意见综合起来。6. 从最小示例到真实系统的几个关键扩展最小示例演示的是流程但离“真实可用”还有一段距离。下面列出几个最重要的扩展方向。6.1 替换真实 LLM 作为生成者与挑战者在agents.py中propose函数目前是一个固定规则生成器。换成 LLM 时你必须设计好提示词让模型基于环境中的定理库状态输出新命题。一个推荐的提示词模板你是数学探索系统中的生成者。以下是当前已知定理 {theorems} 请提出一个新的、有研究价值的数学命题。要求 1. 命题不能与已知定理冲突 2. 命题必须有明确的证明思路 3. 用格式输出PROPOSITION: 表达式; PROOF_STEPS: 步骤1|步骤2|...挑战者的提示词模板则相反重点要求它找反例和漏洞。6.2 接入形式化验证器JudgeAgent.decide中目前调用env.check_proof使用的是 sympy 符号验证和规则检查。真实场景里裁判应当接入 Lean 4、Isabelle 或 Coq 等证明助手让机器可读的形式化证明成为最终判决依据。这一替换的工程量不小但架构上是清晰的check_proof保持接口不变内部实现改为调用形式化验证器。环境层对上层透明智能体不需要感知验证后端的变化。6.3 引入探索策略与记忆当前生成者每次随机选择一条公理做变形没有任何探索策略。真实系统需要维护一个“兴趣地图”哪些方向已经探索过是否有产出哪些领域连续多轮没有产出需要多样性惩罚哪些失败经验值得保存避免后续重复踩坑这些逻辑可以放在一个额外的MemoryModule中在proposer.propose被调用前注入上下文。7. 常见问题与排查思路从很多人的实际实践看搭建多智能体数学发现系统时踩坑点往往不在算法而在架构和接口设计上。下面这些问题是最高频的。问题现象可能原因排查方式解决方案运行时报Theorem_statement_type_CONJECTURE不存在示例代码中的占位符未替换查看报错行确认名称错误替换为StatementType.CONJECTURE或字符串conjecture生成的命题全是重复的随机种子固定且规则库太小检查random.seed和规则列表去掉固定种子增加规则生成模板数量挑战者从不质疑任何命题质疑触发概率设置过低或规则过于严格加入日志观察触发条件在挑战逻辑中增加更多检查规则裁判错误地将错误命题加入定理库验证逻辑覆盖不足sympy 验证只在等式命题上生效构造反例测试check_proof扩展check_proof增加规则验证和依赖检查智能体间消息丢失使用了简单的内存日志没有持久化检查exploration_log是否完整引入消息队列或数据库持久化一个特别容易忽视的问题是验证逻辑的正确性。如果裁判本身的验证规则就是错的那么整个多智能体系统的输出都会不可信。在设计阶段应该为验证机制单独编写测试用例让它先通过已知的“正确命题”和“错误命题”两个集合的检测。8. 最佳实践与工程建议8.1 从“可验证”开始而不是从“聪明”开始很多团队搭建多智能体数学系统时第一反应是让生成者变得更聪明——换更大的模型、写更长的提示词。但真正的瓶颈往往在验证端如果裁判不能可靠判断一个命题的真伪那么生成者再聪明产出的结果也只是高质量幻觉。建议的开发顺序是先实现一个可靠的最小验证器哪怕只能验证等式类命题再接入生成者和挑战者让系统在简单领域先跑通“发现-质疑-验证-入库”的循环再逐步扩展领域范围。8.2 日志与可解释性多智能体系统的最大风险是失去可解释性——多个模型来回交互最后输出一个结果但你不知道结果是怎么来的。为了避免这个问题每一轮探索都必须记录完整的消息流定理入库时必须记录所有依赖的定理、证明步骤、挑战者质疑和裁判裁决理由定期复盘探索日志检查是否有“假阳性”入库。8.3 安全与资源控制调用 LLM 做多轮交互时token 成本会指数级增长。建议做以下限制每个探索回合设置最大推理轮数给propose和challenge调用设置超时时间使用缓存避免重复调用相同输入的 LLM 请求对生成者的输出做基础格式校验防止无效输出浪费验证资源。8.4 对抗不是目的协作才是需要特别提醒引入挑战者不是为了“刁难”生成者而是为了形成一个动态修正的闭环。如果挑战者过于严苛系统会陷入“永远无法接受新定理”的僵局如果过于宽松系统会积累大量未验证结论。裁判的作用就是在这两者之间维护一个动态平衡。一个更精细的设计是让挑战者的质疑也接受二次评估不是所有质疑都是有效的。这一点可以在裁判逻辑中增加“质疑有效性判断”分支。8.5 从单智能体到多智能体的渐进路径如果你目前还没有多智能体经验不建议直接上手完整系统。可以按以下渐进路径实践先跑通本文的最小示例理解生成-挑战-裁判循环把其中一个角色替换为 LLM API 调用观察输出变化增加一个更复杂的验证规则比如支持不等式或数论命题再加入第二个生成者实现多生成者并行探索最后接入形式化验证器和持久化存储。9. 总结与后续学习方向多智能体环境中的自主数学发现本质上是一次认知分工的工程化尝试。单模型再强也无法同时承担“提出新想法”和“严格验证想法”这两个方向相反的任务。而把这两个任务交给不同的智能体再通过裁判机制仲裁你会发现系统的整体能力远超任何一个单模型这背后的原因不是单个模型变强了而是“发现”的过程从串联变成了多线程协作的过程。本文给出的最小示例只是这个方向的第一块积木。真正要把系统推进到“能发现新的、有学术价值的数学结论”还需要在三个方向持续深入形式化证明工具的深度集成、探索策略的自主进化、以及多智能体之间更高效的通信协议。如果你打算基于这个框架做你自己的实验建议你从一个小领域开始比如群论、布尔代数、或者初等数论。在这些领域里命题的验证规则相对清晰生成者和挑战者都能快速沉淀经验。先用最小可行循环跑起来再逐步放开探索空间这样你才能真正看清多智能体什么时候在“真正发现”什么时候只是在“自说自话”。收藏这篇文章作为你构建多智能体数学发现系统的一份脚手架。跑通循环之后你自然会知道下一步代码该往哪里写。 多智能体开放世界中的自主数学发现：从博弈到验证的工程实践
如果说大模型已经在代码生成、数学竞赛题解上表现得像一个“解题高手”那“自主数学发现”就是一个完全不同的游戏它不给你题目不告诉你哪里有定理甚至不保证你正在探索的方向一定有意义。过去几年AI 在数学上最出圈的成果基本集中在“解已知难题”和“验证已有证明”两条线上。而“发现”这件事比如从一组公理出发找到一条新的定理或者在一个开放的数系里发现未被记录的运算规律仍然是数学家和 AI 研究者共同面对的高难度课题。这里有一个关键判断单智能体的数学推理模型本质上是在做“沿着已有知识向前推一步”的搜索而真正的数学发现需要多个智能体在开放环境里彼此质疑、互相修正、持续迭代。换句话说自主数学发现不是一个推理问题而是一个多智能体协作与对抗问题。这篇文章会围绕“开放世界多智能体环境中的自主数学发现”这个主题展开讲清楚三件事第一为什么数学发现适合用多智能体架构而不是更大的单模型 第二如何设计一个“开放世界”式的数学探索环境让智能体不是只在固定数据集上做题 第三怎么用“正反博弈 裁判”的模式把“发现”变成可验证、可追溯、可迭代的工程流程。如果你正在研究多智能体系统、LLM Agent 的落地场景或者对“AI 如何辅助数学研究”感兴趣这篇文章会给你一个可以直接参考的架构思路以及一份能跑通的最小示例代码。1. 这篇文章真正要解决的问题在开始写代码之前先回答一个更根本的问题为什么“让 AI 做数学题”和“让 AI 发现数学”差了十万八千里普通的数学解题比如让模型解一道微分方程、证明一个给定的不等式本质上是一个有明确终点的搜索问题。模型知道目标是什么也知道什么算做对了。哪怕过程很曲折最终的验证成本很低——重新算一遍或者让另一个模型检查证明就能判断对错。数学发现则是另一回事。它的典型特征是目标未知。你不知道这个方向能不能走通甚至不知道“发现一个定理”这个行为本身应该用什么奖励函数来驱动。验证困难。一条新命题可能既不是显然正确也不是显然错误。它需要被证明而证明过程本身可能又会产生新的未解问题。价值需要外部评判。一个数学结论的价值不只在于“真”还在于它是否深刻、是否有用、是否能关联到其他数学分支。在这种场景下单个模型的推理能力再强也只是一个“思考者”。它无法解决“这个想法靠不靠谱”“这个证明有没有漏洞”“这个方向和已有理论能不能接上”这些需要多视角验证的问题。这正是多智能体架构进入的时机。所以本文真正要解决的问题可以概括成一句如何在开放式的数学探索任务中用多个智能体的对抗、合作和评判替代人类数学家在纸面上的反复推演从而让“数学发现”从一次性推理变为可持续扩展的分布式认知过程。读完这篇文章你会掌握一个开放世界数学探索环境的最小设计框架生成者、挑战者、裁判三角色构成的协作博弈架构在 Python 中搭建这种多智能体系统的最小示例判断系统是否“真的在发现数学”而不是在“自说自话”的评估方案。2. 基础概念与核心原理2.1 什么是自主数学发现自主数学发现Autonomous Mathematical Discovery可以理解为机器在一个形式化的数学环境中自主地提出命题、构造证明、验证结论并将新结论纳入自己的知识库继续推进后续探索。这个定义里最关键的词是“自主”。这意味着系统不能依赖人类给它布置具体题目。它的输入是公理系统、已有的定理库和推理规则输出则是新发现的定理、证明以及探索日志。与经典的自动定理证明ATP不同自主数学发现强调的不是“证明一个给定定理”而是“决定研究什么”。后者更像科学家的工作模式先猜想再验证然后修正循环往复。2.2 为什么需要多智能体数学发现天然是一个多视角工作。一个数学家提出猜想时通常会对“这个猜想对不对”有强烈的直觉判断但要让这个猜想成为定理需要有人严格证明而证明本身又经常需要另一个数学家来审阅找其中的漏洞。这种分工可以用三种智能体来模拟生成者Proposer / Generator负责提出新命题、给出证明草图、构造反例。它倾向于大胆探索产出方向性想法。挑战者Challenger / Critic负责攻击生成者的结论。它尝试找反例、找证明漏洞、检查边界条件。它的职责是让系统不轻易满足于“看起来对”。裁判Judge / Verifier在生成者和挑战者无法达成一致时做出裁决。它维护一个“已确认知识库”判定哪些结论可以被接受哪些需要打回重来。这个三角色结构就是“正反博弈 裁判”的核心含义。它和单纯让多个模型投票选答案的做法有本质差别投票只是在多个候选中选一个而博弈过程会产生新的候选、修正旧的候选是一个动态演化的过程。2.3 什么是“开放世界”环境开放世界Open World这个词借自游戏和人工智能规划领域。在数学发现场景下它指的是环境不预设“最终通关目标”智能体可以自由选择探索方向环境的状态空间会随探索过程不断扩展不同智能体看到的环境状态可能不同但没有统一的“标准答案”。对应到工程实现一个开放世界数学环境通常包含四个组成模块形式化语言、状态空间、动作接口、验证机制。模块作用数学发现场景中的体现形式化语言定义命题、证明、对象的标准语法一阶逻辑、类型论、或定义好的 Python 表达式语法状态空间记录当前已知的定理、定义、对象一个定理库、一组公理、已证明的引理动作接口智能体与环境的交互方式提出命题、提交证明、申请验证、查询已有定理验证机制确认一个结论是否成立手工编写的模型检查器、或形式化证明工具需要注意的是这里的“开放世界”不是指自然语言文本构成的知识海洋而是一个由符号规则定义、但探索边界不固定的结构化环境。这一点决定了我们后面写代码时的核心抽象。3. 开放世界数学发现环境的总体设计在设计多智能体系统之前先想清楚环境接口。一个好的环境设计应该让智能体不需要关心底层是用的自然语言模型、符号推理引擎还是形式化验证工具只需要关心“我能做什么动作、动作失败意味着什么”。那问题来了怎么让不同技术栈的智能体共享同一个环境答案是把“数学对象”和“动作语义”抽象成统一接口。这里给出一个相对精简但可扩展的设计。3.1 架构划分整个系统分成四层应用层探索任务定义、结果展示 协作层生成者、挑战者、裁判的调度逻辑 环境层数学对象存储、推理规则、验证服务 基础设施层LLM API、符号计算库、证明工具每一层职责独立。环境层不关心生成者是 GPT 还是开源模型也不关心推理是用 Python 的 sympy 还是外部证明器。协作层只关心动作序列和反馈信号。3.2 状态与消息系统中最重要的数据结构是两个Theorem命题描述一个待验证或已验证的数学陈述。Message消息智能体之间的通信单元包含发送者、接收者或广播、内容类型命题、证明、质疑、裁决、附件。这两个结构要能放进 JSON 或者 Python 字典里才能在智能体之间传递。具体定义在后面代码中给出。3.3 动作接口开放世界环境向智能体暴露的动作接口至少应该包括以下几类propose(statement)提出一个新命题。submit_proof(statement, proof_steps)为一个命题提交证明过程。challenge(statement, reason)对一个命题发起质疑理由可以是反例、证明漏洞、或者边界条件未覆盖。query_theorems(keyword)查询已知定理库。accept(revision)接受某条结论将它加入定理库。reject(reason)拒绝某条结论。动作本身是抽象的具体实现可以对接不同后端。4. 基于“正反博弈 裁判”的多智能体协作机制把上述环境设计落实到协作层接下来给出最核心的机制生成者、挑战者、裁判之间的博弈循环。4.1 角色定义生成者Proposer生成者的职能是发现。它的输入是当前定理库中的已有结论、公理集合、以及探索历史输出是一个新的命题和一个尽量完整的论证。在实际实现中生成者可以由一个大语言模型承担也可以用符号搜索算法加上 LLM 辅助。在本文的示例里为了照顾可读性我用一个模拟函数代表生成者内部的推理过程真正使用时替换为模型调用即可。挑战者Challenger挑战者的职能是证伪。它会仔细检查生成者提交的证明寻找逻辑跳跃、未讨论的边界条件、以及可能存在的反例。这里有一个容易被忽视的设计点挑战者不能只做“对/错”二分类判断它应该输出“质疑理由”。这些理由会成为生成者进行修正的依据。如果挑战者只会说“你错了”生成者无法迭代改进。裁判Judge裁判的职责是仲裁。当生成者和挑战者相持不下时裁判根据代码逻辑、形式化工具结果以及自身推理给出“接受 / 拒绝 / 返回修改”三种裁决。裁判必须被设计成“最谨慎”的角色。它的判断不应该基于概率感觉而应该尽量依赖可计算的验证过程。如果条件允许裁判应该调用形式化验证工具Lean、Isabelle 等做最终确认。在最小示例中我用一个“验证规则表”来模拟形式化验证。4.2 博弈循环一次完整的探索循环如下1. 环境初始化加载公理集与初始定理库。 2. 生成者根据当前定理库提出新命题 P并提交证明草案 D。 3. 挑战者审查 P 和 D - 若没有发现漏洞返回“未发现反例” - 若发现漏洞返回质疑理由。 4. 裁判评估争议 - 若挑战者未发现漏洞且程序 / 规则验证通过接受 P 进入定理库 - 若证明草案存在可修复漏洞将草案返回给生成者修改 - 若证明存在根本性错误拒绝 P并记录失败经验。 5. 将本轮结果写回“经验池”供下一轮生成者参考。 6. 重复 2-5直到达到迭代轮数上限或满足停止条件。这个循环本身很直观但工程实现里有三个关键细节。第一个细节是状态同步。多智能体系统运行在异步环境中生成者可能在挑战者还没审查完成时就提交了下一个命题。解决方法是引入“回合制”状态机每一轮只有一个生成命题在流程中流转挑战者和裁判完成后才进入下一轮。想提升吞吐量的话可以在后续改成流水线式并行但第一步不要这样做。第二个细节是上下文隔离。每个智能体应该只看它需要的信息。生成者不需要看到挑战者给出的所有质疑历史只需要看到被裁判“审核通过”的修正意见裁判则不应该被生成者的原始 prompt 干扰它只依据形式化验证结果做判断。第三个细节是失败信息的利用。被裁判拒绝的命题不要直接丢弃。把失败原因整理成“负向知识”让生成者在后续探索中避开同样的错误。5. 完整示例Python 实现一个最小多智能体数学发现系统下面进入代码部分。这个示例的目标不是做一个可以真正发现数学定理的完整系统那需要接入形式化证明器和更强的推理引擎而是把上面的设计思路变成可运行、可修改的骨架代码。5.1 环境与依赖示例使用 Python 3.9核心依赖如下需要安装的库 - sympy符号计算与表达式验证 - pydantic数据模型定义可选但推荐 - openai / 或者其他 LLM SDK如果要接入真实模型版本以实际环境为准本文示例的重点是架构思路不是绑定某个具体 SDK。5.2 数据模型定义先定义最基本的数学对象和消息结构。# 文件路径models.py from dataclasses import dataclass, field from enum import Enum from typing import List, Optional class StatementType(str, Enum): AXIOM axiom # 公理 LEMMA lemma # 引理 THEOREM theorem # 定理 CONJECTURE conjecture # 猜想 class VerificationStatus(str, Enum): UNVERIFIED unverified VERIFIED verified REJECTED rejected NEEDS_REVISION needs_revision dataclass class Theorem: 数学命题的容器 statement: str # 命题的数学表达式/描述 name: str # 命题名称 statement_type: StatementType StatementType.CONJECTURE proof_steps: List[str] field(default_factorylist) # 证明步骤 status: VerificationStatus VerificationStatus.UNVERIFIED dependencies: List[str] field(default_factorylist) # 依赖的已有定理 created_by: str system dataclass class Message: 智能体间通信消息 sender: str # 发送者角色proposer / challenger / judge receiver: Optional[str] # 接收者None 表示广播 msg_type: str # propose / proof / challenge / verdict content: str # 消息内容 theorem: Optional[Theorem] None # 关联的命题对象 metadata: dict field(default_factorydict)这里的关键设计是Theorem和Message都保持为纯数据对象不包含逻辑。所有验证逻辑都放在环境类中避免智能体绕过规则直接修改定理库。5.3 环境类定理库与验证规则环境类负责维护定理库并提供动作接口。# 文件路径environment.py from typing import List, Dict, Optional from models import Theorem, Message, VerificationStatus import sympy class MathEnvironment: 开放世界数学环境维护定理库提供验证接口 def __init__(self): self.theorems: Dict[str, Theorem] {} self.axioms: List[Theorem] [] self.exploration_log: List[Message] [] self._init_axioms() def _init_axioms(self): 初始化一组基础公理这里以算术为例 axioms [ Theorem( statementa b b a, name加法交换律, statement_typeaxiom, statusVerificationStatus.VERIFIED, ), Theorem( statementa * (b c) a*b a*c, name分配律, statement_typeaxiom, statusVerificationStatus.VERIFIED, ), ] for ax in axioms: self.theorems[ax.name] ax self.axioms.append(ax) def add_theorem(self, theorem: Theorem) - bool: 将验证通过的定理加入定理库 if theorem.name in self.theorems: return False self.theorems[theorem.name] theorem return True def query_theorems(self, keyword: str) - List[Theorem]: 按关键词检索已有定理 return [t for t in self.theorems.values() if keyword in t.statement] def log_message(self, msg: Message): self.exploration_log.append(msg) def verify_by_sympy(self, statement: str) - bool: 用符号计算验证一个等式的正确性 try: left, right statement.split() left_expr sympy.sympify(left.strip()) right_expr sympy.sympify(right.strip()) return sympy.simplify(left_expr - right_expr) 0 except Exception: return False def check_proof(self, theorem: Theorem) - VerificationStatus: 裁判调用此方法做最终验证。 这里演示两种验证方式 1. 如果命题可以直接用 sympy 验证比如等式直接验证 2. 否则检查证明步骤数量是否大于 0并检查依赖是否存在。 if in theorem.statement: if self.verify_by_sympy(theorem.statement): theorem.status VerificationStatus.VERIFIED return VerificationStatus.VERIFIED else: theorem.status VerificationStatus.REJECTED return VerificationStatus.REJECTED if len(theorem.proof_steps) 0: theorem.status VerificationStatus.REJECTED return VerificationStatus.REJECTED for dep in theorem.dependencies: if dep not in self.theorems: theorem.status VerificationStatus.REJECTED return VerificationStatus.REJECTED theorem.status VerificationStatus.VERIFIED return VerificationStatus.VERIFIED这里需要注意verify_by_sympy只适合验证等式类命题真实场景要接入更通用的验证后端。check_proof的“证明步骤数 0”判断只是一个占位逻辑实际项目中应当用形式化验证器或规则引擎替代。5.4 生成者、挑战者、裁判实现现在实现三个角色的核心逻辑。为了让示例不依赖外部 LLM API也便于读者直接运行这里用“模拟思考”的方式替代真实的模型调用。接入真实模型时只需要替换_generate_candidate、_review_candidate、_decide这三个函数的内部实现。# 文件路径agents.py import random from typing import Optional, Tuple from models import Theorem, Message, VerificationStatus class ProposerAgent: 生成者提出新命题和证明草案 def __init__(self, nameproposer): self.name name def propose(self, env) - Tuple[Theorem, str]: 根据当前定理库生成一个新命题。 这里用一个简单的规则生成恒等式作为演示。 existing list(env.theorems.values()) if not existing: return None, no theorems available # 从已有公理中随机选一条做简单变形 base random.choice(env.axioms) # 演示生成 (ab) c a (bc) 之类的结合律变形 statement (a b) c a (b c) name f结合律round{len(env.exploration_log)} theorem Theorem( statementstatement, namename, statement_typeTheorem_statement_type_CONJECTURE, proof_steps[ 应用加法公理进行符号整理, 两边展开后逐项对应, ], dependencies[base.name], created_byself.name, ) return theorem, propose new conjecture def revise(self, theorem: Theorem, feedback: str) - Theorem: 根据裁判反馈修订命题或证明 theorem.proof_steps.append(frevision: {feedback}) return theorem class ChallengerAgent: 挑战者尝试攻击生成者的命题和证明 def __init__(self, namechallenger): self.name name def challenge(self, env, theorem: Theorem) - Optional[str]: 检查命题的证明。 返回 None 表示没有发现问题返回字符串表示质疑原因。 # 演示逻辑如果证明步骤太少直接质疑 if len(theorem.proof_steps) 1: return proof steps is empty, cannot verify if theorem.statement_type conjecture: # 模拟概率性质疑特定情况下返回边界条件问题 if random.random() 0.3: return missing discussion of zero divisor case return None class JudgeAgent: 裁判最终裁决 def __init__(self, namejudge): self.name name def decide(self, env, theorem: Theorem, challenge_reason: Optional[str]) - VerificationStatus: # 先执行环境验证 env_status env.check_proof(theorem) if env_status VerificationStatus.REJECTED: return VerificationStatus.REJECTED if challenge_reason: # 有挑战质疑且环境验证未通过 - 返回修改 theorem.status VerificationStatus.NEEDS_REVISION return VerificationStatus.NEEDS_REVISION theorem.status VerificationStatus.VERIFIED return VerificationStatus.VERIFIED上段代码中有意保留了Theorem_statement_type_CONJECTURE这个占位写法实际运行请改为conjecture或StatementType.CONJECTURE避免直接复制时因名称错误导致编译失败。5.5 主循环把三个角色串起来下面的运行脚本把环境、三 Agent 放进一个回合制循环中。# 文件路径main.py from environment import MathEnvironment from agents import ProposerAgent, ChallengerAgent, JudgeAgent from models import Message, VerificationStatus def run_exploration(max_rounds: int 10): env MathEnvironment() proposer ProposerAgent() challenger ChallengerAgent() judge JudgeAgent() for round_idx in range(max_rounds): print(f\n Round {round_idx 1} ) # 1. 生成者提出命题 theorem, meta proposer.propose(env) if theorem is None: print(No theorem proposed, stop.) break print(f[Proposer] 提出命题: {theorem.name}) print(f statement: {theorem.statement}) # 2. 挑战者质疑 challenge_reason challenger.challenge(env, theorem) if challenge_reason: print(f[Challenger] 发起质疑: {challenge_reason}) else: print([Challenger] 未发现明显漏洞) # 3. 裁判裁决 result judge.decide(env, theorem, challenge_reason) print(f[Judge] 裁决结果: {result.value}) if result VerificationStatus.VERIFIED: env.add_theorem(theorem) print(f[System] 新定理已入库: {theorem.name}) elif result VerificationStatus.NEEDS_REVISION: revised proposer.revise(theorem, challenge_reason or unknown feedback) print(f[System] 命题返回修改当前证明步骤数: {len(revised.proof_steps)}) # 4. 记录日志 env.log_message(Message( senderproposer.name, receiverNone, msg_typeround_summary, contentfround {round_idx 1} result: {result.value}, theoremtheorem, )) print(\n 探索结束 ) print(f定理库中共有 {len(env.theorems)} 条定理/公理。) print(定理列表:) for name, t in env.theorems.items(): print(f - {name}: {t.statement}) if __name__ __main__: random_seed 0 import random random.seed(random_seed) run_exploration(max_rounds10)这里有一个细节在main.py中通过random.seed固定随机种子是为了让读者每次运行得到一致的结果。真实场景中不要固定种子因为探索的多样性本身就是系统能力的一部分。5.6 运行方式python main.py预期输出大致如下 Round 1 [Proposer] 提出命题: 结合律round0 statement: (a b) c a (b c) [Challenger] 未发现明显漏洞 [Judge] 裁决结果: verified [System] 新定理已入库: 结合律round0 Round 2 [Proposer] 提出命题: 结合律round1 statement: (a b) c a (b c) [Challenger] 发起质疑: missing discussion of zero divisor case [Judge] 裁决结果: needs_revision [System] 命题返回修改当前证明步骤数: 35.7 代码逻辑解读这段代码看起来简单但已经覆盖了多智能体数学发现系统的全部核心流程Theorem 结构保存了数学对象的状态状态贯穿整个探索过程MathEnvironment统一管理定理库和验证机制任何智能体都不能绕过环境直接修改知识ProposerAgent承担了探索的功能它可以选择提出哪种类型的命题ChallengerAgent的质疑会阻塞“入库”这保证了系统不会盲目接受未验证结论JudgeAgent的裁决是流程出口它把环境验证结果和挑战者意见综合起来。6. 从最小示例到真实系统的几个关键扩展最小示例演示的是流程但离“真实可用”还有一段距离。下面列出几个最重要的扩展方向。6.1 替换真实 LLM 作为生成者与挑战者在agents.py中propose函数目前是一个固定规则生成器。换成 LLM 时你必须设计好提示词让模型基于环境中的定理库状态输出新命题。一个推荐的提示词模板你是数学探索系统中的生成者。以下是当前已知定理 {theorems} 请提出一个新的、有研究价值的数学命题。要求 1. 命题不能与已知定理冲突 2. 命题必须有明确的证明思路 3. 用格式输出PROPOSITION: 表达式; PROOF_STEPS: 步骤1|步骤2|...挑战者的提示词模板则相反重点要求它找反例和漏洞。6.2 接入形式化验证器JudgeAgent.decide中目前调用env.check_proof使用的是 sympy 符号验证和规则检查。真实场景里裁判应当接入 Lean 4、Isabelle 或 Coq 等证明助手让机器可读的形式化证明成为最终判决依据。这一替换的工程量不小但架构上是清晰的check_proof保持接口不变内部实现改为调用形式化验证器。环境层对上层透明智能体不需要感知验证后端的变化。6.3 引入探索策略与记忆当前生成者每次随机选择一条公理做变形没有任何探索策略。真实系统需要维护一个“兴趣地图”哪些方向已经探索过是否有产出哪些领域连续多轮没有产出需要多样性惩罚哪些失败经验值得保存避免后续重复踩坑这些逻辑可以放在一个额外的MemoryModule中在proposer.propose被调用前注入上下文。7. 常见问题与排查思路从很多人的实际实践看搭建多智能体数学发现系统时踩坑点往往不在算法而在架构和接口设计上。下面这些问题是最高频的。问题现象可能原因排查方式解决方案运行时报Theorem_statement_type_CONJECTURE不存在示例代码中的占位符未替换查看报错行确认名称错误替换为StatementType.CONJECTURE或字符串conjecture生成的命题全是重复的随机种子固定且规则库太小检查random.seed和规则列表去掉固定种子增加规则生成模板数量挑战者从不质疑任何命题质疑触发概率设置过低或规则过于严格加入日志观察触发条件在挑战逻辑中增加更多检查规则裁判错误地将错误命题加入定理库验证逻辑覆盖不足sympy 验证只在等式命题上生效构造反例测试check_proof扩展check_proof增加规则验证和依赖检查智能体间消息丢失使用了简单的内存日志没有持久化检查exploration_log是否完整引入消息队列或数据库持久化一个特别容易忽视的问题是验证逻辑的正确性。如果裁判本身的验证规则就是错的那么整个多智能体系统的输出都会不可信。在设计阶段应该为验证机制单独编写测试用例让它先通过已知的“正确命题”和“错误命题”两个集合的检测。8. 最佳实践与工程建议8.1 从“可验证”开始而不是从“聪明”开始很多团队搭建多智能体数学系统时第一反应是让生成者变得更聪明——换更大的模型、写更长的提示词。但真正的瓶颈往往在验证端如果裁判不能可靠判断一个命题的真伪那么生成者再聪明产出的结果也只是高质量幻觉。建议的开发顺序是先实现一个可靠的最小验证器哪怕只能验证等式类命题再接入生成者和挑战者让系统在简单领域先跑通“发现-质疑-验证-入库”的循环再逐步扩展领域范围。8.2 日志与可解释性多智能体系统的最大风险是失去可解释性——多个模型来回交互最后输出一个结果但你不知道结果是怎么来的。为了避免这个问题每一轮探索都必须记录完整的消息流定理入库时必须记录所有依赖的定理、证明步骤、挑战者质疑和裁判裁决理由定期复盘探索日志检查是否有“假阳性”入库。8.3 安全与资源控制调用 LLM 做多轮交互时token 成本会指数级增长。建议做以下限制每个探索回合设置最大推理轮数给propose和challenge调用设置超时时间使用缓存避免重复调用相同输入的 LLM 请求对生成者的输出做基础格式校验防止无效输出浪费验证资源。8.4 对抗不是目的协作才是需要特别提醒引入挑战者不是为了“刁难”生成者而是为了形成一个动态修正的闭环。如果挑战者过于严苛系统会陷入“永远无法接受新定理”的僵局如果过于宽松系统会积累大量未验证结论。裁判的作用就是在这两者之间维护一个动态平衡。一个更精细的设计是让挑战者的质疑也接受二次评估不是所有质疑都是有效的。这一点可以在裁判逻辑中增加“质疑有效性判断”分支。8.5 从单智能体到多智能体的渐进路径如果你目前还没有多智能体经验不建议直接上手完整系统。可以按以下渐进路径实践先跑通本文的最小示例理解生成-挑战-裁判循环把其中一个角色替换为 LLM API 调用观察输出变化增加一个更复杂的验证规则比如支持不等式或数论命题再加入第二个生成者实现多生成者并行探索最后接入形式化验证器和持久化存储。9. 总结与后续学习方向多智能体环境中的自主数学发现本质上是一次认知分工的工程化尝试。单模型再强也无法同时承担“提出新想法”和“严格验证想法”这两个方向相反的任务。而把这两个任务交给不同的智能体再通过裁判机制仲裁你会发现系统的整体能力远超任何一个单模型这背后的原因不是单个模型变强了而是“发现”的过程从串联变成了多线程协作的过程。本文给出的最小示例只是这个方向的第一块积木。真正要把系统推进到“能发现新的、有学术价值的数学结论”还需要在三个方向持续深入形式化证明工具的深度集成、探索策略的自主进化、以及多智能体之间更高效的通信协议。如果你打算基于这个框架做你自己的实验建议你从一个小领域开始比如群论、布尔代数、或者初等数论。在这些领域里命题的验证规则相对清晰生成者和挑战者都能快速沉淀经验。先用最小可行循环跑起来再逐步放开探索空间这样你才能真正看清多智能体什么时候在“真正发现”什么时候只是在“自说自话”。收藏这篇文章作为你构建多智能体数学发现系统的一份脚手架。跑通循环之后你自然会知道下一步代码该往哪里写。