如果一个AI系统告诉你，它发现了一个可能改写教科书的新数学规律，你的第一反应是什么？大概率是怀疑。但如果这个AI不是单独给出答案，而是内部先有一群Agent互相攻击——一个Agent提出规律，另一个Agent拼命找反例，最后还有裁判Agent决定是否相信——你会不会觉得它比那种一次性输出结论的聊天框更可信一些？这是多智能体系统在数学发现领域最值得关注的变化：它不再试图用一次推理说服你，而是把数学发现包装成一个可监督、可反驳、可裁判的工程过程。
过去一段时间，很多人讨论AI证明数学定理的能力，但我更关心的其实是另一件事：AI能不能改变“数学共识”的形成方式。传统数学共识靠的是论文、同行评审、人类直觉和漫长的验证周期；而一个由多个Agent组成的系统，可以在极短时间内对一个假设做内部对抗、反例搜索和裁决，并把结论和证据一起交给人类。这会压缩掉大量“看起来合理但其实是错的”中间结论，从而改变我们筛选数学假设的效率。
当然，多智能体不是银弹。如果只是让几个LLM互相聊天，最后裁判也是同一个模型，那系统幻觉并不会消失，只会被包装得更圆润。关键是机制设计：必须有正反博弈，必须有独立的裁判标准，必须允许“拒绝”而不是让Agent一直互相客气。这也是本文要展开的重点。
我会先讲清楚为什么数学发现适合多智能体，再分析“正反博弈+裁判”这个模式为什么比单纯协作更可靠，然后给出一个可以运行的Python实现。通过这个Demo，你可以看到Agent如何提出候选公式、如何被反例否决、最终如何形成裁决。整套代码不依赖外部大模型API，也不需要GPU，用普通Python环境就能跑。
1. 这篇文章真正要解决的问题
1.1 数学发现为什么需要一套新的工程流程
数学发现有一个天然难题：候选命题空间几乎是无限的，但人类能观察到的证据往往是有限的。你看到一串数列前几项，想要推出通项公式，可能同时存在无数个公式能在这些点上成立。传统做法是靠数学家直觉去“猜”一个最自然的规则，然后用证明去锁定它。可一旦候选公式数量变大，或者问题本身足够陌生，人类直觉就可能成为瓶颈。
另一个痛点来自大模型的普及。现在很多AI系统已经能读懂数学题，也能生成看起来像模像样的证明过程。但单Agent模型很容易在一本正经的推理链条中隐藏一个关键错误，而且它自己很难发现这个错误。原因在于，当你让同一个模型同时担任“出题者”和“验题者”时，它往往会倾向于维护自己刚刚提出的结论，而不是认真寻找漏洞。这种自我确认偏差，是AI做数学发现时最危险的问题。
多智能体系统之所以值得关注，是因为它把“一个人同时做几件事”变成了“几个人分别负责一件事”。提出者只负责提假设，反驳者只负责找反例，裁判只负责下结论。每个角色目标单一，行为更容易被监控，也更容易被工程化。它解决的核心问题不是“谁能写出更漂亮的证明”，而是“如何让系统内建一个可执行的纠错机制”，避免错误假设在无人质疑的情况下被当作结论。
1.2 什么样的读者最应该关注这套方法
如果你正在做Agent应用开发，尤其是想让多个Agent协作完成复杂任务，这篇文章会给你一个数学场景下的参考实现。如果你在关注AI4Science，你会看到AI参与科学研究时，不只是用更大算力做模拟，还可以通过对抗博弈来筛选假设。如果你只是想了解“多智能体到底能做什么”，那本文的核心机制——正反博弈加裁判——会比单纯的“多Agent聊天”更有启发。
2. 多智能体数学发现的核心概念与适用场景
2.1 从“单Agent答题”到“多Agent共识”
先解释两个词。自主智能体通常指一个能感知环境、制定计划、调用工具并执行动作的AI程序。在数学发现场景里，它可以表现为一个负责提出公式的规则生成器，也可以表现为一个负责搜索反例的枚举程序。这里的“自主”不是说它完全没有人工参与，而是说它在具体任务闭环里不需要人类每一步都干预。
多智能体数学发现，就是让多个具有不同分工的Agent围绕同一个数学问题协作。它们之间不再是人机对话，而是Agent与Agent之间交换消息，比如“我提出一个候选公式”“我在n=7找到了反例”“我接受这个结论”。这比单个Agent做端到端对话更稳定，因为系统可以把错误暴露在中间环节，而不是让错误藏在最终答案里。
下面这张表可以直观看出差别：
| 模式 | 典型做法 | 纠错能力 | 适合场景 |
|---|---|---|---|
| 单Agent直接回答 | 输入问题，输出答案 | 弱，容易自我确认偏差 | 简单问题、快速原型 |
| 多Agent协作 | 多个Agent分工，流程化处理 | 中，依赖流程设计 | 工具调用、长链路任务 |
| 正反博弈+裁判 | 提出者、反驳者、裁判三方交互 | 强，内建对抗检验 | 数学发现、科学假设筛选、复杂决策 |
正反博弈加裁判不是让Agent互相攻击，而是让“提出假设”和“否定假设”成为两条独立路径。提出者不需要害怕找反例，反驳者也不需要对任何假设客气，裁判则按照预设规则给出最终裁决。这样的结构很契合数学场景，因为数学命题是高度可证伪的：一个反例就足以推翻一个全称命题，不需要你论证“它不美”或“它不够自然”。
2.2 数学发现中的“共识”指什么
这里的“共识”需要解释清楚。数学上真正被广泛接受的定理，必须有严格证明。但在探索阶段，研究社区经常会出现“暂时相信某个猜想成立”的状态，比如许多数值实验支持某个猜想，但还没有人给出证明。这种状态其实就是一种共识雏形：大家默认它大概率成立，并以此为基础继续推进。
AI系统可以挑战这种共识。当人类基于有限证据相信某个公式时，多智能体系统可以扩大搜索范围，寻找一个反例来否定它；也可以提出一个更简单或更通用的替代公式，然后在更大样本上验证。换句话说，它不一定能代替人类写出证明，但它可以在“共识尚未形成”或“共识开始固化”的时候，充当一个高速、可复现的质疑者。
2.3 这套方法不适合做什么
需要强调边界。多智能体数学发现并不等同于自动定理证明。它擅长的是“提出假设、搜索反例、筛选候选规则”，而不是在公理体系内构造一步步的形式化证明。如果你想用Lean、Coq等证明助手完成定理证明，那是另一条技术路线。更准确地说，多智能体系统可以作为定理证明的前置环节，帮人类缩小搜索范围；但它给出的结果，必须经过严格证明才能成为数学共识。
3. 为什么“正反博弈+裁判”机制是关键
3.1 单Agent的自评为什么不可靠
很多人会让模型“再检查一遍自己的答案”，这种做法在简单场景下有效，但在复杂数学推理中效果有限。因为同一个模型内部的注意力偏差是结构性的：它生成公式时已经形成了一种“结论倾向”，让它在同一上下文中审视同一个结论时，很容易忽略掉微弱但有决定性意义的反例。这里真正容易踩坑的地方是，你以为模型在做批判性思考，其实它只是在用更高置信度复述之前的推理路径。
正反博弈的价值，在于把“自我批评”转成“外部攻击”。提出者不知道反驳者会从哪里下手，反驳者也没有维护提出者面子的动机。两者使用的策略甚至可以是完全不同的：提出者依赖归纳和类比，反驳者依赖枚举和穷举。当两种不同搜索策略互相碰撞时，错误更容易暴露出来。
3.2 裁判存在的意义
有人可能会问，既然两个Agent已经在辩论了，为什么还要一个裁判？因为在对抗结构里，双方都可能出现极端情况：提出者生成大量无用假设，反驳者为了“赢”而吹毛求疵，或者双方陷入无休止的争吵。裁判的作用是定义停止条件、判断证据强度、给出可解释的结论。它不一定比提出者更聪明，但它是流程的管理者。
裁判Agent需要一套明确的裁决标准。在数学发现场景中，标准通常包括：候选规则是否匹配已知数据、是否通过更大范围的反例搜索、是否与现有共识库冲突。如果规则通过验证，但与共识库不同，裁判应当标记为“潜在共识挑战”，并提醒人工介入；如果规则被反例否定，裁判必须明确记录反例位置，而不是简单丢弃。这样，整个系统的决策才能回溯。
3.3 数学命题的“可证伪性”让对抗特别高效
数学命题和开放式问答不同。开放问答的“正确答案”可能很模糊，但一个全称数学命题只要找到一个反例就能被否定。这种二值判定天然适合对抗式搜索。提出者说“这个公式对所有正整数成立”，反驳者只需要找到n=7成立不了，问题就结束了。这种“一票否决”机制让Agent之间的信息传递效率非常高，也更容易落地成代码。
因此，面向数学发现的多智能体系统，核心不是让Agent学会更多数学知识，而是构建一个“提出—反驳—裁决”的循环。这个循环每执行一次，候选假设空间就会收缩一圈，最终留下的规则会更可靠。
4. 环境准备与前置条件
4.1 运行环境与目录结构
本文的示例代码使用纯Python标准库，不需要安装任何第三方依赖。建议Python版本在3.9以上，因为代码用到了dataclass、类型注解等特性。操作系统不限，Windows、macOS、Linux都可以。如果你希望后续把Proposer或Judge替换成真实大模型API，再根据你选择的服务接入对应SDK。
建议工程目录如下：
math-agent-demo/ ├── multi_agent_math.py ├── requirements.txt └── README.md其中multi_agent_math.py是核心代码，requirements.txt用于说明依赖情况。实际运行只需要一个Python文件。
4.2 依赖说明
由于演示优先考虑可复现性，核心代码不依赖外部库。requirements.txt可以写成下面这样：
# 核心演示只需要 Python 3.9+ 标准库 # 如果后续要接入大模型 API，请根据你的服务端 SDK 调整依赖 # openai>=1.0.0在实际项目中，如果你想用真实LLM替换规则生成器，再安装对应的SDK即可。但要注意，外部API会带来网络延迟、调用成本和密钥管理问题。建议先把规则版本跑通，再考虑扩展。
5. 完整示例：Python实现正反博弈+裁判的多智能体数学探索
5.1 示例目标
假设我们观察到一个数列的前6项是[1.0, 4.0, 9.0, 16.0, 25.0, 36.0]，也就是n^2的前6项。但系统不知道真实规则，它只知道这些有限数据。现在，多个Agent要通过“提出假设、搜索反例、裁判裁决”的方式，找出一个合理的通项公式。
这里我故意设置了一个干扰规则：一个多项式P(n) = n^2 + (n-1)(n-2)(n-3)(n-4)(n-5)(n-6)。它在n=1到6时和n^2完全一致，但到了n=7就立刻出现巨大偏差。这类“有限前缀拟合”规则是数学发现里最典型的陷阱，也最能体现反例搜索的价值。
5.2 核心代码实现
将下面的代码保存为multi_agent_math.py。
# 文件路径：math-agent-demo/multi_agent_math.py """ 正反博弈 + 裁判的多智能体数学发现演示 运行： python multi_agent_math.py """ from __future__ import annotations from dataclasses import dataclass from typing import Callable, List, Optional # ---------- 基础数据结构 ---------- @dataclass class CandidateRule: """一条由 Proposer 提出的候选数学规则。""" name: str description: str predict: Callable[[int], float] @dataclass class RefutationReport: """Refuter 对候选规则进行反例搜索后的结果。""" status: str # SUPPORT / REJECT checked_until: int # 检查到第几个 n counterexample: Optional[int] = None # 如果找到反例，记录 n @dataclass class Verdict: """裁判的最终决策。""" decision: str # ACCEPT / REJECT reason: str # ---------- 候选规则库 ---------- def make_interpolation_rule() -> CandidateRule: """ 一个干扰规则：它在前 6 项上看起来和 n^2 完全一样。 但因为在后面加了一个高阶扰动项，从 n=7 开始会迅速偏离。 """ def predict(n: int) -> float: return n ** 2 + (n - 1) * (n - 2) * (n - 3) * (n - 4) * (n - 5) * (n - 6) return CandidateRule( name="interpolation_square", description="n^2 加上一个只在 n>=7 生效的高阶扰动项", predict=predict, ) def make_square_rule() -> CandidateRule: def predict(n: int) -> float: return n ** 2 return CandidateRule( name="square", description="a_n = n^2", predict=predict, ) def make_cube_rule() -> CandidateRule: def predict(n: int) -> float: return n ** 3 return CandidateRule( name="cube", description="a_n = n^3", predict=predict, ) # ---------- 提出者 Agent ---------- class ProposerAgent: def __init__(self): # 这里用一个固定队列模拟 Agent 的“知识库”。 # 实际项目可以替换为 LLM 或规则生成器，每次返回一个新的候选公式。 self.queue = [ make_interpolation_rule(), make_square_rule(), make_cube_rule(), ] self.index = 0 def propose(self) -> CandidateRule: if self.index >= len(self.queue): raise RuntimeError("没有更多候选规则") rule = self.queue[self.index] self.index += 1 return rule # ---------- 反驳者 Agent ---------- class RefuterAgent: def __init__(self, target_fn: Callable[[int], float], search_limit: int = 100): self.target_fn = target_fn self.search_limit = search_limit def verify(self, rule: CandidateRule, known_terms: List[float]) -> RefutationReport: # 第一步：检查候选规则是否匹配已知前缀 for n, expected in enumerate(known_terms, start=1): if abs(rule.predict(n) - expected) > 1e-9: return RefutationReport( status="REJECT", checked_until=n, counterexample=n, ) # 第二步：在更大范围搜索反例 for n in range(len(known_terms) + 1, self.search_limit + 1): actual = self.target_fn(n) predicted = rule.predict(n) if abs(predicted - actual) > 1e-9: return RefutationReport( status="REJECT", checked_until=n, counterexample=n, ) return RefutationReport( status="SUPPORT", checked_until=self.search_limit, counterexample=None, ) # ---------- 裁判 Agent ---------- class JudgeAgent: def __init__(self, consensus_rules: List[str]): self.consensus_rules = consensus_rules def adjudicate(self, rule: CandidateRule, report: RefutationReport) -> Verdict: if report.status == "REJECT": return Verdict( decision="REJECT", reason=f"找到反例：a_{report.counterexample} 与目标不一致", ) if rule.name in self.consensus_rules: return Verdict( decision="ACCEPT", reason="该规则通过反例搜索，且与现有共识一致", ) return Verdict( decision="ACCEPT", reason="该规则通过反例搜索，但与现有共识不同，需要人工复核", ) # ---------- 主流程 ---------- def main(): # 目标序列：a_n = n^2 def target_fn(n: int) -> float: return n **
