多智能体开放世界中的自主数学发现：从博弈到验证的工程实践

如果说大模型已经在代码生成、数学竞赛题解上表现得像一个“解题高手”，那“自主数学发现”就是一个完全不同的游戏：它不给你题目，不告诉你哪里有定理，甚至不保证你正在探索的方向一定有意义。

过去几年，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）这个词借自游戏和人工智能规划领域。在数学发现场景下，它指的是：

• 环境不预设“最终通关目标”；
• 智能体可以自由选择探索方向；
• 环境的状态空间会随探索过程不断扩展；
• 不同智能体看到的环境状态可能不同，但没有统一的“标准答案”。

对应到工程实现，一个开放世界数学环境通常包含四个组成模块：形式化语言、状态空间、动作接口、验证机制。

需要注意的是，这里的“开放世界”不是指自然语言文本构成的知识海洋，而是一个由符号规则定义、但探索边界不固定的结构化环境。这一点决定了我们后面写代码时的核心抽象。

3. 开放世界数学发现环境的总体设计

在设计多智能体系统之前，先想清楚环境接口。一个好的环境设计，应该让智能体不需要关心底层是用的自然语言模型、符号推理引擎还是形式化验证工具，只需要关心“我能做什么动作、动作失败意味着什么”。

那问题来了：怎么让不同技术栈的智能体共享同一个环境？

答案是把“数学对象”和“动作语义”抽象成统一接口。这里给出一个相对精简但可扩展的设计。

3.1 架构划分

整个系统分成四层：

应用层：探索任务定义、结果展示 协作层：生成者、挑战者、裁判的调度逻辑 环境层：数学对象存储、推理规则、验证服务 基础设施层：LLM API、符号计算库、证明工具

每一层职责独立。环境层不关心生成者是 GPT 还是开源模型，也不关心推理是用 Python 的 sympy 还是外部证明器。协作层只关心动作序列和反馈信号。

3.2 状态与消息

系统中最重要的数据结构是两个：

1. Theorem（命题）：描述一个待验证或已验证的数学陈述。
2. 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_factory=list) # 证明步骤 status: VerificationStatus = VerificationStatus.UNVERIFIED dependencies: List[str] = field(default_factory=list) # 依赖的已有定理 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_factory=dict)

这里的关键设计是：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( statement="a + b = b + a", name="加法交换律", statement_type="axiom", status=VerificationStatus.VERIFIED, ), Theorem( statement="a * (b + c) = a*b + a*c", name="分配律", statement_type="axiom", status=VerificationStatus.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, name="proposer"): 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) # 演示：生成 (a+b) + c = a + (b+c) 之类的结合律变形 statement = "(a + b) + c = a + (b + c)" name = f"结合律@round{len(env.exploration_log)}" theorem = Theorem( statement=statement, name=name, statement_type=Theorem_statement_type_CONJECTURE, proof_steps=[ "应用加法公理进行符号整理", "两边展开后逐项对应", ], dependencies=[base.name], created_by=self.name, ) return theorem, "propose new conjecture" def revise(self, theorem: Theorem, feedback: str) -> Theorem: """根据裁判反馈修订命题或证明""" theorem.proof_steps.append(f"revision: {feedback}") return theorem class ChallengerAgent: """挑战者：尝试攻击生成者的命题和证明""" def __init__(self, name="challenger"): 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, name="judge"): 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( sender=proposer.name, receiver=None, msg_type="round_summary", content=f"round {round_idx + 1} result: {result.value}", theorem=theorem, )) 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_rounds=10)

这里有一个细节：在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] 命题返回修改，当前证明步骤数: 3

5.7 代码逻辑解读

这段代码看起来简单，但已经覆盖了多智能体数学发现系统的全部核心流程：

1. Theorem 结构保存了数学对象的状态，状态贯穿整个探索过程；
2. MathEnvironment统一管理定理库和验证机制，任何智能体都不能绕过环境直接修改知识；
3. ProposerAgent承担了探索的功能，它可以选择提出哪种类型的命题；
4. ChallengerAgent的质疑会阻塞“入库”，这保证了系统不会盲目接受未验证结论；
5. 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. 常见问题与排查思路

从很多人的实际实践看，搭建多智能体数学发现系统时，踩坑点往往不在算法，而在架构和接口设计上。下面这些问题是最高频的。

一个特别容易忽视的问题是：验证逻辑的正确性。如果裁判本身的验证规则就是错的，那么整个多智能体系统的输出都会不可信。在设计阶段，应该为验证机制单独编写测试用例，让它先通过已知的“正确命题”和“错误命题”两个集合的检测。

8. 最佳实践与工程建议

8.1 从“可验证”开始，而不是从“聪明”开始

很多团队搭建多智能体数学系统时，第一反应是让生成者变得更聪明——换更大的模型、写更长的提示词。但真正的瓶颈往往在验证端：如果裁判不能可靠判断一个命题的真伪，那么生成者再聪明，产出的结果也只是高质量幻觉。

建议的开发顺序是：

1. 先实现一个可靠的最小验证器（哪怕只能验证等式类命题）；
2. 再接入生成者和挑战者；
3. 让系统在简单领域先跑通“发现-质疑-验证-入库”的循环；
4. 再逐步扩展领域范围。

8.2 日志与可解释性

多智能体系统的最大风险是失去可解释性——多个模型来回交互，最后输出一个结果，但你不知道结果是怎么来的。为了避免这个问题：

• 每一轮探索都必须记录完整的消息流；
• 定理入库时，必须记录所有依赖的定理、证明步骤、挑战者质疑和裁判裁决理由；
• 定期复盘探索日志，检查是否有“假阳性”入库。

8.3 安全与资源控制

调用 LLM 做多轮交互时，token 成本会指数级增长。建议做以下限制：

• 每个探索回合设置最大推理轮数；
• 给propose和challenge调用设置超时时间；
• 使用缓存，避免重复调用相同输入的 LLM 请求；
• 对生成者的输出做基础格式校验，防止无效输出浪费验证资源。

8.4 对抗不是目的，协作才是

需要特别提醒：引入挑战者不是为了“刁难”生成者，而是为了形成一个动态修正的闭环。如果挑战者过于严苛，系统会陷入“永远无法接受新定理”的僵局；如果过于宽松，系统会积累大量未验证结论。裁判的作用就是在这两者之间维护一个动态平衡。

一个更精细的设计是让挑战者的质疑也接受二次评估：不是所有质疑都是有效的。这一点可以在裁判逻辑中增加“质疑有效性判断”分支。

8.5 从单智能体到多智能体的渐进路径

如果你目前还没有多智能体经验，不建议直接上手完整系统。可以按以下渐进路径实践：

1. 先跑通本文的最小示例，理解生成-挑战-裁判循环；
2. 把其中一个角色替换为 LLM API 调用，观察输出变化；
3. 增加一个更复杂的验证规则（比如支持不等式或数论命题）；
4. 再加入第二个生成者，实现多生成者并行探索；
5. 最后接入形式化验证器和持久化存储。

9. 总结与后续学习方向

多智能体环境中的自主数学发现，本质上是一次认知分工的工程化尝试。单模型再强，也无法同时承担“提出新想法”和“严格验证想法”这两个方向相反的任务。而把这两个任务交给不同的智能体，再通过裁判机制仲裁，你会发现系统的整体能力远超任何一个单模型，这背后的原因不是单个模型变强了，而是“发现”的过程从串联变成了多线程协作的过程。

本文给出的最小示例只是这个方向的第一块积木。真正要把系统推进到“能发现新的、有学术价值的数学结论”，还需要在三个方向持续深入：形式化证明工具的深度集成、探索策略的自主进化、以及多智能体之间更高效的通信协议。

如果你打算基于这个框架做你自己的实验，建议你从一个小领域开始，比如群论、布尔代数、或者初等数论。在这些领域里，命题的验证规则相对清晰，生成者和挑战者都能快速沉淀经验。先用最小可行循环跑起来，再逐步放开探索空间，这样你才能真正看清：多智能体什么时候在“真正发现”，什么时候只是在“自说自话”。

收藏这篇文章，作为你构建多智能体数学发现系统的一份脚手架。跑通循环之后，你自然会知道下一步代码该往哪里写。