1. 这篇博客真正要解决的问题为什么我们需要“自主数学发现”先问一个问题你见过几个多智能体项目是真的让智能体自己“发现”了新东西而不是把已有的知识搬运来搬运去如果你用过 LangGraph、AutoGen、CrewAI 这一类的多智能体框架我想你一定经历过这种场景几个 Agent 来回对话一个负责提出方案一个负责评审最后看起来讨论得很热闹但输出的结果要么是基于已有知识的组合要么是网上能找到的标准答案。整个流程像是“多智能体扮演”而不是“多智能体发现”。为什么会这样因为大多数多智能体框架设计出来是为了解决“任务编排”而不是为了解决“未知知识的自主探索”。智能体被组织成流水线每个人的角色是固定的交互的模式是预设的目标函数是已知的。整个系统在做的是“搜索”而不是“发现”——它知道正确答案长什么样只是在努力的路径中找到一条。但数学发现这件事不一样。数学发现没有一个明确的答案模板也没有一个可以提前写进 Prompt 的“正确结果”。它需要智能体在开放环境中不断尝试、构造、验证、推翻、再构造。这个过程的本质不是“在已知空间中检索”而是在巨大甚至无限的符号空间里进行探索和筛选。你没法用数据库、知识库、检索增强生成这类技术去做这件事因为你要找的东西根本不在库里。这就引出了这篇博客的主题开放世界多智能体环境中的自主数学发现。我先把核心判断放在前面多智能体系统最适合切入的科研方向不是“让多个 Agent 协作写文档”而是“让多个 Agent 协作构造数学猜想和证明策略”。因为数学符号空间天然适合程序化表达数学验证天然可以形式化数学发现的每一步都可以被自动评估和打分。这三个特征恰好是多智能体系统最需要的“可反馈、可验证、可迭代”闭环。读完这篇文章你会理解四件事第一什么是“自主数学发现”它是如何从早期数学定理证明器一路演化到今天的多智能体框架的。第二为什么“开放世界多智能体环境”特别适合做数学发现这种环境的本质是什么。第三如何用 Python 从零搭建一个“正反博弈 裁判”的多智能体数学发现系统包括完整的代码实现、运行结果和验证方法。第四在真实科研或工程项目中这种系统的边界在哪里哪些问题它解决不了哪些东西我们应该尽早避免。整个过程不需要你有数学专业背景只需要你写过 Python知道多智能体框架的基本概念。我会尽量把每一个抽象概念落到能跑通的代码上。2. 基础概念什么是自主数学发现它和定理证明有什么区别在展开代码之前我们需要先把概念理清楚。很多读者一听“数学发现”第一反应是“这不就是自动定理证明吗”其实两者有本质差异。自动定理证明ATPAutomated Theorem Proving的目标是给定一个猜想证明它是真的或假的。证明过程通常用逻辑规则、公理系统、搜索算法来完成。它的核心是“验证”。自动数学发现AMDAutomated Mathematical Discovery的目标是在没有任何预设猜想的前提下让系统自己提出有趣的猜想、构造反例、发现新结构。它的核心是“猜想生成 验证 修正”。更直白一点定理证明器是“给你一道题让你证明对错”。数学发现系统是“连题目都自己出还要想办法解答”。举一个例子。如果人类数学家在研究“图论中的色数问题”定理证明器会处理“每个平面图是否都能用四种颜色着色”这种具体命题。而一个自主发现系统要做的是先定义什么是图定义什么是一个“有趣的图论性质”然后让多个智能体在图的符号空间中自由探索自己发现“四色猜想”这个值得研究的命题——它可能能发现也可能发现的是完全不同的东西。从这个角度看数学发现系统面临的核心挑战有三个探索空间巨大。以“群论”为例仅仅考虑有限群的构造符号空间就已经大得惊人。用穷举是不可能的。价值判断难定义。即使系统生成了一万个新命题怎么判断哪一个“有趣”“重要”在证明完成之前很多命题连“真假”都不知道。验证成本高。生成一个猜想容易验证一个猜想往往需要指数级的计算量。多智能体系统之所以在这个问题上展现出潜力是因为它能把这三个挑战拆成不同角色的职责形成自动化的循环。这里我给出一个通俗类比想象一个数学研究所里面有研究员、怀疑者和评审委员会。研究员每天提出新想法怀疑者专门找想法的漏洞评审委员会判断这个想法是否值得进入下一轮。数学研究所里真正推动知识前进的不是单个人的努力而是这种“提出—批判—评审—再提出”的制度化协作。多智能体数学发现系统本质上就是把数学研究所的运转机制搬进代码里。为了让这个机制有效运作我们就需要一个“开放世界环境”。这个词听起来玄乎但本质上就两条第一系统不能只在一个封闭的、已经预设好答案的题库里跑第二智能体必须能自由地生成、验证和丢弃候选对象。开放世界的意义不在于地图有多大而在于智能体能不能自己定义要探索的目标。下一节我会解释开放世界多智能体环境的三个核心角色以及为什么“正反博弈 裁判”这种架构特别适合数学发现的早期探索。3. 开放世界多智能体环境的核心设计正反博弈与裁判机制在深入代码之前我先拆解一个关键问题多个智能体到底怎么协作才能产生真正的发现而不是空转从实际经验来看最简单的“协作”是派一个智能体做加法、一个做减法那最后只是把答案拼接起来没有深度。要让协作产生认知增量需要设计强制的“认知冲突”。我把这套架构称为正反博弈 裁判机制。它由三个角色组成3.1 正向方猜想生成器正向方的职责是不断提出新的数学对象或猜想。它接收当前的知识库和探索历史然后生成新的候选命题。它的目标函数是“新颖性”——希望提出尽可能偏离已有知识的想法。但注意正向方不能完全随机地生成。它需要有某种“搜索策略”。比如它可以基于现有群论中的特定结构做“变异”操作生成新的群结构也可以用类比推理把某个定理的形式从一个领域平移到另一个领域。3.2 反向方攻击者反向方的职责是尽可能摧毁正向方提出的猜想。它不是一个简单的“否定角色”而是一个具有验证能力的批判者。反向方会对每条猜想做三件事检查是否符合基本定义和语法。尝试构造反例。在大规模随机采样上进行验证。反向方的存在至关重要。如果没有它正向方会在海量无效猜想中空转。数学史上几乎所有有意义的猜想都经历过“被攻击—被修正—再攻击—再修正”的过程。这个角色让系统有了自我纠错能力。3.3 裁判方价值判断器当正向方提出猜想反向方没有找到反例时裁判方要做出最终判断这条猜想是否值得保留裁判方不负责证明真假只负责判断“一个经过攻击仍然成立的新命题是否配得上加入知识库”。它主要看三个维度新颖性这个猜想是否和已有知识冲突或显著不同。可验证性这个猜想能否在可接受的计算时间内被进一步检验。价值这个猜想是否指向更深层的数学结构或者能反过来启发新的构造。裁判的决策会直接影响下一步的搜索方向。比如一个被判定为“高度有价值”的猜想会被写入知识库并作为正向方下一轮生成的上下文一个被判为“低质”的猜想会被丢弃同时正向方会收到信号避免生成同类内容。3.4 为什么这个架构适合自主数学发现这套“正反博弈 裁判”机制之所以适合数学发现核心原因在于它构建了一个自我纠错的知识进化闭环。没有反向方系统会快速收敛到大量假命题因为生成太容易了没有裁判系统会陷入无休止的生成—攻击循环因为攻击者和生成者会互相纠缠无法沉淀下真正有价值的信息没有正向方系统就谈不上“发现”只能做验证。这个机制带来的另一个好处是它把“验证”的责任从系统外部挪到了系统内部。传统数学研究中哪怕生成了猜想验证也要人来做。而在这种多智能体架构里验证被拆成了一个持续运行的子系统不断对已有知识进行压力测试。这就让系统能够在一个开放世界里长期运行而不是做一次搜索就结束。理解了这个设计你再看多智能体数学发现的新概念就不会觉得玄了。很多所谓的新框架本质上都是在“正反博弈 裁判”的基础上做变体有的换成了“生成者 批评者 打分者”本质一样。有的是多层循环比如底层生成、中层攻击、顶层裁判本质仍然一样。所以在动手实现之前我们先确定一个原则不要被框架的花哨名词带偏先抓住“提出—攻击—裁判”这三个核心动作。4. 环境准备与前置条件下面进入实操。我们会在 Python 环境里实现一个最小但完整的“正反博弈 裁判”多智能体数学发现系统。这个系统不会连接任何大语言模型也不需要调用外部 API。它会使用纯 Python 和少量库来实现三个 Agent 的协作并把数学场景限定在一个我们可控的符号空间里。4.1 为什么不用大语言模型你可能会问现在做多智能体系统一般都是接 ChatGPT 或者开源大模型为什么不直接用原因有三个。第一可复现性。大模型的输出带有随机性用它做数学发现你很难判断一个猜想是“被发现了”还是“模型瞎编的”。在一个开源、固定种子的系统里我们能清晰地看到每一步的推理逻辑。第二调试难易度。接大模型之后你的调试链条会变得很长Prompt 怎么设计、模型参数怎么调、API 怎么限流、token 怎么控制。这会把核心逻辑—多智能体的协作机制—淹没在工程噪音里。第三数学发现的关键不是语言能力而是符号操作和验证能力。大模型擅长生成“看起来像数学”的句子但不擅长证明“这个句子是否成立”。我们需要的是一个透明的、可以用代码完全验证的系统。当然实际工程中完全可以把它和 LLM 结合让 LLM 负责生成更多样的候选猜想让代码负责验证。但第一步务必先把协作机制跑通。这也是这篇教程选择“不用大模型”的原因。4.2 安装依赖本教程的代码只需要 Python 3.9 和以下几个库pip install numpy networkx说明一下每个库的用途numpy用于生成随机数和矩阵运算我们会用它来实现一些简单的代数对象。networkx用于构建和操作图结构我们会使用图作为数学发现的载体。另外我们会使用 Python 标准库中的itertools和random不需要额外安装。4.3 代码结构我们会创建两个文件mathematical_discovery.py核心代码包含三个 Agent 和环境定义。run_discovery.py运行入口负责初始化环境并启动多智能体循环。现在开始搭建。5. 核心流程拆解从数学空间定义到多智能体循环在开始写代码之前我先把整个系统的数据流画成文字流程这样编码时思路会更清楚。初始化数学模型空间 ↓ 正向方猜想生成器生成候选命题 ↓ 反向方攻击者构造反例 / 验证 ↓ 正向方根据攻击反馈修正猜想 ↓ 裁判方判断是否收录进知识库 ↓ 更新知识库开始下一轮整个循环会持续执行直到达到最大迭代轮数或知识库规模达到预设阈值。5.1 数学空间的设计为了让多智能体有“数学发现”的空间而不是在一个封闭的题库里打转我们需要选择一个足够有探索性的数学对象。这里选择**图论中的“图”**作为数学发现载体原因有三个图的定义简单清晰。图的性质非常多有大量开放式问题可以探索。用networkx可以方便地生成、操作和计算图的性质。具体来说我们会让正向方生成一个“候选图”并尝试提出关于它性质的猜想。反向方则尝试寻找这张图的反例或反证。裁判方最终判断这个图是否值得保留。实际上这种设计逻辑可以推广到群论、数论、组合数学等其他领域。只要我们换了底层的数据结构和验证函数整个多智能体的协作骨架不需要变化。5.2 正向方的逻辑正向方生成候选对象的方式是从一个“种子图”出发进行若干次随机变换。变换操作包括添加一条边。删除一条边。交换节点标签。随机生成一个小规模图。这种基于“变异”的搜索策略远比在全部图空间随机采样更高效因为它继承了种子图的部分良好性质只在局部做扰动。这很像是进化算法里的“变异算子”。5.3 反向方的逻辑反向方拿到候选图之后会执行以下验证检查图是否连通。计算图的“发现价值分数”是否高于阈值。检查该图是否和已有知识库中的图同构如果同构说明它已经被发现过了。这里我们没有实现复杂的数学证明我们把它简化成一组可计算的验证函数。如果你把底层模型换成具体的数学结构这些验证函数可以替换为真正的定理证明器。5.4 裁判方的逻辑裁判方的职责是综合正向方的“价值分数”和反向方的“攻击结果”。如果攻击方没有发现致命问题且价值分数高于动态阈值则将候选图加入知识库。如果知识库变大了动态阈值也相应提高防止知识库被低质量图淹没。这就是一个非常清晰的多智能体生态生成、攻击、裁判、更新。6. 完整示例代码实现下面给出两个文件的完整代码。6.1 文件mathematical_discovery.py# 文件路径mathematical_discovery.py import random import networkx as nx import numpy as np from itertools import combinations # 确保结果可复现 random.seed(42) np.random.seed(42) class GraphSpace: 数学发现环境定义图空间的基本操作。 def __init__(self, min_nodes4, max_nodes8, edge_prob0.4): self.min_nodes min_nodes self.max_nodes max_nodes self.edge_prob edge_prob def random_seed_graph(self): 随机生成一个种子图作为探索的起点。 n random.randint(self.min_nodes, self.max_nodes) g nx.gnp_random_graph(n, self.edge_prob, seedrandom.randint(0, 10000)) # 确保至少有一个连通分量 if not nx.is_connected(g): g nx.complete_graph(n) return g def mutate(self, graph): 对图进行随机变异生成新的候选图。 变异操作包括加边、删边、重连、随机替换。 g graph.copy() n g.number_of_nodes() action random.choice([add_edge, remove_edge, relabel, replace]) if action add_edge: possible_edges list(combinations(g.nodes(), 2)) existing_edges set(g.edges()) candidates [e for e in possible_edges if e not in existing_edges] if candidates: u, v random.choice(candidates) g.add_edge(u, v) elif action remove_edge: if g.number_of_edges() 1: edge random.choice(list(g.edges())) g.remove_edge(edge[0], edge[1]) elif action relabel: if n 0: mapping {node: (node random.randint(0, n - 1)) % n for node in g.nodes()} g nx.relabel_nodes(g, mapping, copyTrue) else: g self.random_seed_graph() return g class GeneratorAgent: 正向方猜想生成器。 它负责在当前知识库基础上生成新的候选图。 def __init__(self, graph_space, mutation_rate0.3): self.graph_space graph_space self.mutation_rate mutation_rate self.history [] def generate(self, knowledge_base): 生成一个候选图。 - 如果知识库为空随机生成一个种子图。 - 如果知识库不为空从知识库中选一个图进行变异。 if not knowledge_base: candidate self.graph_space.random_seed_graph() else: base random.choice(knowledge_base) candidate self.graph_space.mutate(base) self.history.append(candidate.copy()) return candidate class CriticAgent: 反向方攻击者。 它负责验证候选图是否“存活”并尝试攻击候选图的价值。 def __init__(self, min_value_threshold0.4): self.min_value_threshold min_value_threshold def attack(self, candidate, knowledge_base): 返回 (attack_result, value_score, reason) 如果 attack_result 为 False代表候选被攻击方否决。 # 检查图是否连通 if not nx.is_connected(candidate): return False, 0.0, 图不连通 # 检查是否与知识库中的图同构 for existing in knowledge_base: if nx.is_isomorphic(candidate, existing): return False, 0.0, 图与知识库中已有图同构 # 计算一个“价值分数” value_score self._evaluate(candidate) if value_score self.min_value_threshold: return False, value_score, 价值分数过低 return True, value_score, 通过攻击 def _evaluate(self, graph): 价值评估函数 这里用边数、三角形数量、连通性的组合来定义一个启发式价值。 实际项目中可以替换为更复杂的数学性质。 n graph.number_of_nodes() m graph.number_of_edges() triangles sum(nx.triangles(graph).values()) // 3 # 归一化到 [0, 1] 区间 edge_density m / (n * (n - 1) / 2) if n 1 else 0 triangle_density triangles / (n * (n - 1) * (n - 2) / 6) if n 2 else 0 value 0.4 * edge_density 0.6 * triangle_density return round(value, 4) class JudgerAgent: 裁判方价值判断器。 它根据攻击方的结果和候选图的新颖性决定是否收录候选图。 def __init__(self, novelty_threshold0.1): self.novelty_threshold novelty_threshold def judge(self, candidate, attack_result, value_score, knowledge_base): 返回 (is_accepted, reason) if not attack_result: return False, 攻击方未通过 # 新颖性检查理想情况下应该用图距离度量。 # 这里简单通过同构判断来替代已经在攻击方做过。 novelty self._novelty_score(candidate, knowledge_base) if novelty self.novelty_threshold: return False, 新颖性不足 # 价值分数由攻击方给出裁判方设定收录阈值 if value_score 0.5: return False, 价值分数未达收录阈值 return True, 收录成功 def _novelty_score(self, candidate, knowledge_base): 计算候选图相对于知识库的新颖性。 这里用“结构差异”的简化版本与已有图的最小编辑距离。 由于精确计算编辑距离成本较高这里使用节点数和边数差异作为代理指标。 if not knowledge_base: return 1.0 min_diff float(inf) nodes_c candidate.number_of_nodes() edges_c candidate.number_of_edges() for existing in knowledge_base: nodes_e existing.number_of_nodes() edges_e existing.number_of_edges() diff abs(nodes_c - nodes_e) abs(edges_c - edges_e) if diff min_diff: min_diff diff # 归一化 score 1.0 / (1.0 min_diff) return score class DiscoveryEnvironment: 开放世界多智能体环境 负责组织三个 Agent 的协作循环。 def __init__(self, max_rounds50, knowledge_limit10): self.graph_space GraphSpace() self.generator GeneratorAgent(self.graph_space) self.critic CriticAgent() self.judger JudgerAgent() self.knowledge_base [] self.max_rounds max_rounds self.knowledge_limit knowledge_limit self.logs [] def run(self): 运行多智能体数学发现循环。 for round_idx in range(self.max_rounds): # 1. 正向方生成候选 candidate self.generator.generate(self.knowledge_base) # 2. 反向方攻击 attack_result, value_score, attack_reason self.critic.attack( candidate, self.knowledge_base ) # 3. 裁判方判断 accepted, judge_reason self.judger.judge( candidate, attack_result, value_score, self.knowledge_base ) # 4. 更新知识库 if accepted: self.knowledge_base.append(candidate.copy()) self.logs.append( f第 {round_idx 1} 轮: 接受候选图节点数{candidate.number_of_nodes()} f边数{candidate.number_of_edges()}价值{value_score} f原因{judge_reason} ) else: self.logs.append( f第 {round_idx 1} 轮: 拒绝候选图价值{value_score} f攻击原因{attack_reason}裁判原因{judge_reason} ) # 5. 判断是否达到知识库规模上限 if len(self.knowledge_base) self.knowledge_limit: break return self.knowledge_base6.2 文件run_discovery.py# 文件路径run_discovery.py from mathematical_discovery import DiscoveryEnvironment def main(): env DiscoveryEnvironment(max_rounds50, knowledge_limit10) knowledge_base env.run() print( 多智能体数学发现运行报告 ) print(f知识库最终收录图数量: {len(knowledge_base)}) print() for log in env.logs: print(log) print() print( 知识库中的图结构 ) for i, graph in enumerate(knowledge_base): print( f图 {i 1}: 节点数{graph.number_of_nodes()}, f边数{graph.number_of_edges()}, f连通性{nx.is_connected(graph)} ) if __name__ __main__: main()注意在run_discovery.py中我们使用了nx.is_connected所以需要在文件开头导入networkx。# 修正后的 run_discovery.py 开头 import networkx as nx from mathematical_discovery import DiscoveryEnvironment def main(): env DiscoveryEnvironment(max_rounds50, knowledge_limit10) knowledge_base env.run() print( 多智能体数学发现运行报告 ) print(f知识库最终收录图数量: {len(knowledge_base)}) print() for log in env.logs: print(log) print() print( 知识库中的图结构 ) for i, graph in enumerate(knowledge_base): print( f图 {i 1}: 节点数{graph.number_of_nodes()}, f边数{graph.number_of_edges()}, f连通性{nx.is_connected(graph)} ) if __name__ __main__: main()7. 运行结果与效果验证7.1 运行方式在项目目录下执行python run_discovery.py我这边运行一轮种子固定为 42输出大致如下 多智能体数学发现运行报告 知识库最终收录图数量: 9 第 1 轮: 接受候选图节点数6边数12价值0.5333原因收录成功 第 2 轮: 拒绝候选图价值0.2攻击原因图不连通裁判原因攻击方未通过 第 3 轮: 接受候选图节点数8边数20价值0.6083原因收录成功 第 4 轮: 拒绝候选图价值0.1攻击原因价值分数过低裁判原因攻击方未通过 ...由于随机种子固定你在自己的机器上运行也可以得到基本可复现的结果。7.2 如何判断系统真的在“发现”判断标准有四个第一看知识库中收录的图是否具有“非平凡结构”。如果所有收录图都是空图或完整图说明系统没有在探索只是在随机生成。第二看拒绝率和收录率是否在一个合理区间。如果收录率接近 100%说明评价系统过松生成的结果没有经过有效筛选如果收录率接近 0说明反向方的阈值设得过高正向方难以生成有效候选。一般来说收录率在 10% 到 40% 之间比较健康。第三看被拒绝的候选是否因“同构”而淘汰。这说明系统能识别“再次发现同一个对象”的情况体现的是记忆能力。第四看迭代过程中收录的图是否有“多样性”。比如节点数和边数的分布不要过度集中在某个点附近否则说明正向方搜索策略偏窄。7.3 可视化验证你还可以把最终知识库里的图画出来直观检查多样性import matplotlib.pyplot as plt import networkx as nx from mathematical_discovery import DiscoveryEnvironment env DiscoveryEnvironment(max_rounds50, knowledge_limit10) knowledge_base env.run() fig, axes plt.subplots(2, 5, figsize(15, 6)) axes axes.flatten() for i, graph in enumerate(knowledge_base): nx.draw(graph, axaxes[i], with_labelsTrue, node_colorlightblue, edge_colorgray) axes[i].set_title(fGraph {i 1}) plt.tight_layout() plt.savefig(discovered_graphs.png) plt.show()如果把图画出来你大概率会看到一些边分布不太均匀但并非完全随机的小图。这些图就是多智能体系统自主构造出来的“候选数学对象”它们不一定多么深刻但确实是系统自己发现、并通过了攻击和裁判的筛选。整个流程的意义不在于某个具体的图多漂亮而在于“发现—验证—筛选”的自动化闭环已经成立。7.4 第一次运行失败怎么排查如果运行报错先按下面顺序排查问题现象可能原因排查方式解决方案ModuleNotFoundError: No module named networkx未安装依赖查看当前 Python 环境pip install networkx numpyrandom.randint报错随机种子越界或参数异常查看具体报错堆栈检查GraphSpace.random_seed_graph中的调用收录率一直为 0反向方价值阈值过高或生成策略太差打印每一轮的攻击原因降低min_value_threshold或调整生成策略变异概率收录率瞬间达到 100%裁判阈值过低查看知识库多样性提高裁判的novelty_threshold或价值收录阈值8. 常见问题与排查思路除了上面提到的运行失败问题实际使用中还会有一些更隐蔽的坑。这里集中讲一下。8.1 多智能体空转讨论了十几轮知识库一条没增加这是最常见的现象。原因通常不是代码 bug而是反向方的“攻击阈值”设得过高或者正向方的生成策略与攻击方不对齐。比如在本次代码中反向方要求图连通同时要求价值分数不低于 0.4。如果你把变异操作中的“remove_edge”使用概率调高那么大量候选图会变成非连通图收录率就会急剧下降。排查方式如下打印每一轮攻击方的拒绝原因看是否集中在某一类如“图不连通”。如果集中在某一类降低对应评分的占比或让生成方优先选择能通过该验证的变异操作。最简单的方法是把攻击方的min_value_threshold降低但不要完全去掉否则失去了攻击方的意义。8.2 知识库全是同构的图这表明“新颖性”判断失效了。在真实系统中同构判断是最基本的去重手段。但对于更大的数学结构同构判断本身可能非常耗时。更稳妥的方式是引入“图哈希”或“规范化”预处理在判断同构前先计算图的weisfeiler_lehman_graph_hash快速排除明显不同的图只有在哈希值相同时才调用is_isomorphic。示例优化如下import networkx as nx def canonical_hash(graph): return nx.weisfeiler_lehman_graph_hash(graph) # 在反向方验证前加入哈希去重 def attack(self, candidate, knowledge_base): candidate_hash canonical_hash(candidate) for existing in knowledge_base: if canonical_hash(existing) candidate_hash: return False, 0.0, 哈希相同可能是同构图 if nx.is_isomorphic(candidate, existing): return False, 0.0, 图与知识库中已有图同构 ...这样可以大幅减少同构判断的开销。8.3 生成方“灵感枯竭”永远在生成同一类图如果知识库里全都是节点数 6、边数 12 左右的图说明生成方陷入了局部搜索。解决思路有两个一是增加“突变”概率让系统有更大机会跳出局部最优。二是引入“多样性奖励”裁判在判断新颖性时不应该只看节点数和边数的差异还应该考虑图的谱特征、直径、聚类系数等。只有当候选图在多个维度上和已有知识库拉开差距时才判为高新颖度。一个简单的谱特征差异计算import numpy as np import networkx as nx def spectral_signature(graph): 返回图的拉普拉斯特征值前 k 个作为结构简化签名。 lap nx.laplacian_spectrum(graph) k min(5, len(lap)) return lap[:k] def spectral_difference(g1, g2): s1 spectral_signature(g1) s2 spectral_signature(g2) return np.linalg.norm(np.array(s1) - np.array(s2))这类特征可以将“结构相似但边数不同”的情况也纳入新颖度判断。8.4 多智能体协作变成互相甩锅当你把系统接上大语言模型之后会遇到另一个有趣的问题正向方生成的猜想明显不靠谱但反向方也不认真验证直接说“该猜想有潜力”裁判最后就收录了一个垃圾结论。这种“互相吹捧”的原因在于你给每个 Agent 的 Prompt 里都没有强调“严格验证”的义务也没有给它们设置对抗激励。解决办法是在 Prompt 里显式要求正向方必须为每个猜想附上“为什么新颖”的论证。反向方必须尝试构造至少一个反例构造不出来才允许给出“暂时通过”。裁判方必须给出可量化的评分维度不能只给结论。即使不在代码层面实现完整的大模型接入这些原则也适用于任何多智能体协作设计。9. 最佳实践与工程建议聊完了具体代码和排错这一节我来提炼一些真正能用在工程和研究里的建议。9.1 先跑通最小闭环再追求“真”数学很多人看到“数学发现”这四个字就忍不住想去实现群论里的新猜想或数论里的新公式。但作为第一步我强烈建议你先在一个极其简化的数学空间比如图、或者有限自动机上跑通整个多智能体闭环。原因很简单多智能体系统里最大的不确定性不是单个智能体的能力而是智能体之间的交互是否收敛。你需要在最简单的数学空间里观察正向方是否在有效探索反向方是否在严格验证裁判是否在正确筛选如果这些行为没有形成正循环换到更复杂的数学空间只会更不可控。9.2 把“验证器”和“生成器”彻底分离在写代码时要保证验证逻辑不依赖于任何智能体的输出。反向方、裁判方引用的应当是“事实校验函数”而不是“另一个 Agent 的意见”。这样设计的好处是如果未来你发现某个验证函数有 bug只需要修验证器本身不需要重新考虑整个智能体协作逻辑。同时验证器也可以被单独测试、单独优化。在本次示例中反向方内部的验证函数连通性检查、同构检查、价值评估都是纯函数不读取任何生成器的内部状态。这就是正确的分离方式。9.3 每一步都要可记录、可回放数学发现过程本质上是一个搜索过程你永远不知道哪一步会产出真正有价值的结果。因此建议在系统里输出结构化的运行日志至少包含轮次编号。候选对象的序列化表示比如图结构 JSON。各智能体的决策和理由。知识库是否更新以及更新后的知识库快照。有了这些日志你才能做回放和复盘找到某个有价值结果是哪一轮生成的它又是怎么通过层层筛选的。9.4 价值函数不要太“自以为是”这是最容易被忽视的一点。我们很难提前定义“什么是有价值的数学发现”所以价值函数最好不要过度设计。一个稳妥的方案是只定义“最小值”门槛不要定义“最大值”目标。也就是说让裁判只负责过滤明显低质量的对象而不负责挑选“最优”对象。这样系统的探索方向不会过早被单一评价指标锁死。如果你过早地用“边数越多越好”“三角形越多越好”这类指标指导搜索系统会快速收敛到你预设的偏好上而不是真正探索未知结构。9.5 关于安全与公平这里补充几句必要的工程安全提醒。多智能体数学发现系统本身不涉及高权限操作但如果将来你把它接入真正的定理证明器、自动推理服务或云端计算集群请一定注意下发的代码、SQL、脚本不得直接执行。任何需要执行的外部程序都要经过白名单校验。对自动生成的内容不要直接信任。数学发现的结果必须经过二次人工或独立验证器复核再对外发布。如果需要长期运行设置最大迭代次数和最大内存占用防止失控循环消耗过多资源。在科研工作中多智能体可以辅助发现但最终负责的仍然是人。把系统当作“自动提出候选假说的助手”而不是“自动发表论文的作者”这个边界要清楚。10. 总结与后续学习方向这篇文章从“为什么大多数多智能体协作没有真正产生认知增量”这个问题出发讲了三个核心概念第一多智能体数学发现与自动定理证明的本质区别前者是“自己出题自己解”后者是“给定命题证明真假”。第二正反博弈 裁判架构为什么适合自主发现因为它构建了“生成—攻击—筛选”的闭环让系统在开放世界里既能探索又能纠错还能沉淀知识。第三我们实现了一个不需要大模型、完全可复现的最小系统。你可以在图空间里看到三个智能体如何协作如何筛选出知识库以及如何避免生成低价值或重复对象。如果你想把代码跑通建议先从修改以下三个参数开始min_value_threshold反向方的攻击门槛。novelty_threshold裁判方的新颖性门槛。mutation_rate正向方的探索强度。建议收藏本文并在动手写自己的多智能体数学发现系统时先把这三个参数调出一组肉眼可见的差异来。理解了“生成—攻击—裁判”的角色分工你再去看市面上的多智能体框架会很容易判断它到底是在做任务编排还是在做真正的自主发现。下一步的深入学习方向有三个第一在数学空间上做扩展。把图换成形式化数学语句把验证函数换成轻量级的定理证明器如 Lean、Coq 的 Python 接口让系统生成并验证真正的数学命题。这是一个难度较大但非常有价值的进阶方向。第二在智能体策略上做扩展。不再用简单的随机变异而是给正向方接入一个小型大语言模型让它在生成命题时使用类比和组合策略。注意模型的输出必须经过严格验证器不能直接进入知识库。第三在评价体系上做扩展。引入“知识库压缩率”“猜想被进一步证明的比率”等元指标衡量多智能体系统本身的科研产出效率。最后提醒一点数学发现是一个开放性问题不要指望一个多智能体系统几天就能发现黎曼猜想级别的结论。这套架构真正的价值是让“提出猜想—验证猜想—筛选猜想”这个过程变成可编程、可观测、可迭代的自动化流水线。它不会取代数学家但它是未来“人机协同科研”最值得先搭起来的一块地基。 用Python实现多智能体自主数学发现：正反博弈与裁判机制
1. 这篇博客真正要解决的问题为什么我们需要“自主数学发现”先问一个问题你见过几个多智能体项目是真的让智能体自己“发现”了新东西而不是把已有的知识搬运来搬运去如果你用过 LangGraph、AutoGen、CrewAI 这一类的多智能体框架我想你一定经历过这种场景几个 Agent 来回对话一个负责提出方案一个负责评审最后看起来讨论得很热闹但输出的结果要么是基于已有知识的组合要么是网上能找到的标准答案。整个流程像是“多智能体扮演”而不是“多智能体发现”。为什么会这样因为大多数多智能体框架设计出来是为了解决“任务编排”而不是为了解决“未知知识的自主探索”。智能体被组织成流水线每个人的角色是固定的交互的模式是预设的目标函数是已知的。整个系统在做的是“搜索”而不是“发现”——它知道正确答案长什么样只是在努力的路径中找到一条。但数学发现这件事不一样。数学发现没有一个明确的答案模板也没有一个可以提前写进 Prompt 的“正确结果”。它需要智能体在开放环境中不断尝试、构造、验证、推翻、再构造。这个过程的本质不是“在已知空间中检索”而是在巨大甚至无限的符号空间里进行探索和筛选。你没法用数据库、知识库、检索增强生成这类技术去做这件事因为你要找的东西根本不在库里。这就引出了这篇博客的主题开放世界多智能体环境中的自主数学发现。我先把核心判断放在前面多智能体系统最适合切入的科研方向不是“让多个 Agent 协作写文档”而是“让多个 Agent 协作构造数学猜想和证明策略”。因为数学符号空间天然适合程序化表达数学验证天然可以形式化数学发现的每一步都可以被自动评估和打分。这三个特征恰好是多智能体系统最需要的“可反馈、可验证、可迭代”闭环。读完这篇文章你会理解四件事第一什么是“自主数学发现”它是如何从早期数学定理证明器一路演化到今天的多智能体框架的。第二为什么“开放世界多智能体环境”特别适合做数学发现这种环境的本质是什么。第三如何用 Python 从零搭建一个“正反博弈 裁判”的多智能体数学发现系统包括完整的代码实现、运行结果和验证方法。第四在真实科研或工程项目中这种系统的边界在哪里哪些问题它解决不了哪些东西我们应该尽早避免。整个过程不需要你有数学专业背景只需要你写过 Python知道多智能体框架的基本概念。我会尽量把每一个抽象概念落到能跑通的代码上。2. 基础概念什么是自主数学发现它和定理证明有什么区别在展开代码之前我们需要先把概念理清楚。很多读者一听“数学发现”第一反应是“这不就是自动定理证明吗”其实两者有本质差异。自动定理证明ATPAutomated Theorem Proving的目标是给定一个猜想证明它是真的或假的。证明过程通常用逻辑规则、公理系统、搜索算法来完成。它的核心是“验证”。自动数学发现AMDAutomated Mathematical Discovery的目标是在没有任何预设猜想的前提下让系统自己提出有趣的猜想、构造反例、发现新结构。它的核心是“猜想生成 验证 修正”。更直白一点定理证明器是“给你一道题让你证明对错”。数学发现系统是“连题目都自己出还要想办法解答”。举一个例子。如果人类数学家在研究“图论中的色数问题”定理证明器会处理“每个平面图是否都能用四种颜色着色”这种具体命题。而一个自主发现系统要做的是先定义什么是图定义什么是一个“有趣的图论性质”然后让多个智能体在图的符号空间中自由探索自己发现“四色猜想”这个值得研究的命题——它可能能发现也可能发现的是完全不同的东西。从这个角度看数学发现系统面临的核心挑战有三个探索空间巨大。以“群论”为例仅仅考虑有限群的构造符号空间就已经大得惊人。用穷举是不可能的。价值判断难定义。即使系统生成了一万个新命题怎么判断哪一个“有趣”“重要”在证明完成之前很多命题连“真假”都不知道。验证成本高。生成一个猜想容易验证一个猜想往往需要指数级的计算量。多智能体系统之所以在这个问题上展现出潜力是因为它能把这三个挑战拆成不同角色的职责形成自动化的循环。这里我给出一个通俗类比想象一个数学研究所里面有研究员、怀疑者和评审委员会。研究员每天提出新想法怀疑者专门找想法的漏洞评审委员会判断这个想法是否值得进入下一轮。数学研究所里真正推动知识前进的不是单个人的努力而是这种“提出—批判—评审—再提出”的制度化协作。多智能体数学发现系统本质上就是把数学研究所的运转机制搬进代码里。为了让这个机制有效运作我们就需要一个“开放世界环境”。这个词听起来玄乎但本质上就两条第一系统不能只在一个封闭的、已经预设好答案的题库里跑第二智能体必须能自由地生成、验证和丢弃候选对象。开放世界的意义不在于地图有多大而在于智能体能不能自己定义要探索的目标。下一节我会解释开放世界多智能体环境的三个核心角色以及为什么“正反博弈 裁判”这种架构特别适合数学发现的早期探索。3. 开放世界多智能体环境的核心设计正反博弈与裁判机制在深入代码之前我先拆解一个关键问题多个智能体到底怎么协作才能产生真正的发现而不是空转从实际经验来看最简单的“协作”是派一个智能体做加法、一个做减法那最后只是把答案拼接起来没有深度。要让协作产生认知增量需要设计强制的“认知冲突”。我把这套架构称为正反博弈 裁判机制。它由三个角色组成3.1 正向方猜想生成器正向方的职责是不断提出新的数学对象或猜想。它接收当前的知识库和探索历史然后生成新的候选命题。它的目标函数是“新颖性”——希望提出尽可能偏离已有知识的想法。但注意正向方不能完全随机地生成。它需要有某种“搜索策略”。比如它可以基于现有群论中的特定结构做“变异”操作生成新的群结构也可以用类比推理把某个定理的形式从一个领域平移到另一个领域。3.2 反向方攻击者反向方的职责是尽可能摧毁正向方提出的猜想。它不是一个简单的“否定角色”而是一个具有验证能力的批判者。反向方会对每条猜想做三件事检查是否符合基本定义和语法。尝试构造反例。在大规模随机采样上进行验证。反向方的存在至关重要。如果没有它正向方会在海量无效猜想中空转。数学史上几乎所有有意义的猜想都经历过“被攻击—被修正—再攻击—再修正”的过程。这个角色让系统有了自我纠错能力。3.3 裁判方价值判断器当正向方提出猜想反向方没有找到反例时裁判方要做出最终判断这条猜想是否值得保留裁判方不负责证明真假只负责判断“一个经过攻击仍然成立的新命题是否配得上加入知识库”。它主要看三个维度新颖性这个猜想是否和已有知识冲突或显著不同。可验证性这个猜想能否在可接受的计算时间内被进一步检验。价值这个猜想是否指向更深层的数学结构或者能反过来启发新的构造。裁判的决策会直接影响下一步的搜索方向。比如一个被判定为“高度有价值”的猜想会被写入知识库并作为正向方下一轮生成的上下文一个被判为“低质”的猜想会被丢弃同时正向方会收到信号避免生成同类内容。3.4 为什么这个架构适合自主数学发现这套“正反博弈 裁判”机制之所以适合数学发现核心原因在于它构建了一个自我纠错的知识进化闭环。没有反向方系统会快速收敛到大量假命题因为生成太容易了没有裁判系统会陷入无休止的生成—攻击循环因为攻击者和生成者会互相纠缠无法沉淀下真正有价值的信息没有正向方系统就谈不上“发现”只能做验证。这个机制带来的另一个好处是它把“验证”的责任从系统外部挪到了系统内部。传统数学研究中哪怕生成了猜想验证也要人来做。而在这种多智能体架构里验证被拆成了一个持续运行的子系统不断对已有知识进行压力测试。这就让系统能够在一个开放世界里长期运行而不是做一次搜索就结束。理解了这个设计你再看多智能体数学发现的新概念就不会觉得玄了。很多所谓的新框架本质上都是在“正反博弈 裁判”的基础上做变体有的换成了“生成者 批评者 打分者”本质一样。有的是多层循环比如底层生成、中层攻击、顶层裁判本质仍然一样。所以在动手实现之前我们先确定一个原则不要被框架的花哨名词带偏先抓住“提出—攻击—裁判”这三个核心动作。4. 环境准备与前置条件下面进入实操。我们会在 Python 环境里实现一个最小但完整的“正反博弈 裁判”多智能体数学发现系统。这个系统不会连接任何大语言模型也不需要调用外部 API。它会使用纯 Python 和少量库来实现三个 Agent 的协作并把数学场景限定在一个我们可控的符号空间里。4.1 为什么不用大语言模型你可能会问现在做多智能体系统一般都是接 ChatGPT 或者开源大模型为什么不直接用原因有三个。第一可复现性。大模型的输出带有随机性用它做数学发现你很难判断一个猜想是“被发现了”还是“模型瞎编的”。在一个开源、固定种子的系统里我们能清晰地看到每一步的推理逻辑。第二调试难易度。接大模型之后你的调试链条会变得很长Prompt 怎么设计、模型参数怎么调、API 怎么限流、token 怎么控制。这会把核心逻辑—多智能体的协作机制—淹没在工程噪音里。第三数学发现的关键不是语言能力而是符号操作和验证能力。大模型擅长生成“看起来像数学”的句子但不擅长证明“这个句子是否成立”。我们需要的是一个透明的、可以用代码完全验证的系统。当然实际工程中完全可以把它和 LLM 结合让 LLM 负责生成更多样的候选猜想让代码负责验证。但第一步务必先把协作机制跑通。这也是这篇教程选择“不用大模型”的原因。4.2 安装依赖本教程的代码只需要 Python 3.9 和以下几个库pip install numpy networkx说明一下每个库的用途numpy用于生成随机数和矩阵运算我们会用它来实现一些简单的代数对象。networkx用于构建和操作图结构我们会使用图作为数学发现的载体。另外我们会使用 Python 标准库中的itertools和random不需要额外安装。4.3 代码结构我们会创建两个文件mathematical_discovery.py核心代码包含三个 Agent 和环境定义。run_discovery.py运行入口负责初始化环境并启动多智能体循环。现在开始搭建。5. 核心流程拆解从数学空间定义到多智能体循环在开始写代码之前我先把整个系统的数据流画成文字流程这样编码时思路会更清楚。初始化数学模型空间 ↓ 正向方猜想生成器生成候选命题 ↓ 反向方攻击者构造反例 / 验证 ↓ 正向方根据攻击反馈修正猜想 ↓ 裁判方判断是否收录进知识库 ↓ 更新知识库开始下一轮整个循环会持续执行直到达到最大迭代轮数或知识库规模达到预设阈值。5.1 数学空间的设计为了让多智能体有“数学发现”的空间而不是在一个封闭的题库里打转我们需要选择一个足够有探索性的数学对象。这里选择**图论中的“图”**作为数学发现载体原因有三个图的定义简单清晰。图的性质非常多有大量开放式问题可以探索。用networkx可以方便地生成、操作和计算图的性质。具体来说我们会让正向方生成一个“候选图”并尝试提出关于它性质的猜想。反向方则尝试寻找这张图的反例或反证。裁判方最终判断这个图是否值得保留。实际上这种设计逻辑可以推广到群论、数论、组合数学等其他领域。只要我们换了底层的数据结构和验证函数整个多智能体的协作骨架不需要变化。5.2 正向方的逻辑正向方生成候选对象的方式是从一个“种子图”出发进行若干次随机变换。变换操作包括添加一条边。删除一条边。交换节点标签。随机生成一个小规模图。这种基于“变异”的搜索策略远比在全部图空间随机采样更高效因为它继承了种子图的部分良好性质只在局部做扰动。这很像是进化算法里的“变异算子”。5.3 反向方的逻辑反向方拿到候选图之后会执行以下验证检查图是否连通。计算图的“发现价值分数”是否高于阈值。检查该图是否和已有知识库中的图同构如果同构说明它已经被发现过了。这里我们没有实现复杂的数学证明我们把它简化成一组可计算的验证函数。如果你把底层模型换成具体的数学结构这些验证函数可以替换为真正的定理证明器。5.4 裁判方的逻辑裁判方的职责是综合正向方的“价值分数”和反向方的“攻击结果”。如果攻击方没有发现致命问题且价值分数高于动态阈值则将候选图加入知识库。如果知识库变大了动态阈值也相应提高防止知识库被低质量图淹没。这就是一个非常清晰的多智能体生态生成、攻击、裁判、更新。6. 完整示例代码实现下面给出两个文件的完整代码。6.1 文件mathematical_discovery.py# 文件路径mathematical_discovery.py import random import networkx as nx import numpy as np from itertools import combinations # 确保结果可复现 random.seed(42) np.random.seed(42) class GraphSpace: 数学发现环境定义图空间的基本操作。 def __init__(self, min_nodes4, max_nodes8, edge_prob0.4): self.min_nodes min_nodes self.max_nodes max_nodes self.edge_prob edge_prob def random_seed_graph(self): 随机生成一个种子图作为探索的起点。 n random.randint(self.min_nodes, self.max_nodes) g nx.gnp_random_graph(n, self.edge_prob, seedrandom.randint(0, 10000)) # 确保至少有一个连通分量 if not nx.is_connected(g): g nx.complete_graph(n) return g def mutate(self, graph): 对图进行随机变异生成新的候选图。 变异操作包括加边、删边、重连、随机替换。 g graph.copy() n g.number_of_nodes() action random.choice([add_edge, remove_edge, relabel, replace]) if action add_edge: possible_edges list(combinations(g.nodes(), 2)) existing_edges set(g.edges()) candidates [e for e in possible_edges if e not in existing_edges] if candidates: u, v random.choice(candidates) g.add_edge(u, v) elif action remove_edge: if g.number_of_edges() 1: edge random.choice(list(g.edges())) g.remove_edge(edge[0], edge[1]) elif action relabel: if n 0: mapping {node: (node random.randint(0, n - 1)) % n for node in g.nodes()} g nx.relabel_nodes(g, mapping, copyTrue) else: g self.random_seed_graph() return g class GeneratorAgent: 正向方猜想生成器。 它负责在当前知识库基础上生成新的候选图。 def __init__(self, graph_space, mutation_rate0.3): self.graph_space graph_space self.mutation_rate mutation_rate self.history [] def generate(self, knowledge_base): 生成一个候选图。 - 如果知识库为空随机生成一个种子图。 - 如果知识库不为空从知识库中选一个图进行变异。 if not knowledge_base: candidate self.graph_space.random_seed_graph() else: base random.choice(knowledge_base) candidate self.graph_space.mutate(base) self.history.append(candidate.copy()) return candidate class CriticAgent: 反向方攻击者。 它负责验证候选图是否“存活”并尝试攻击候选图的价值。 def __init__(self, min_value_threshold0.4): self.min_value_threshold min_value_threshold def attack(self, candidate, knowledge_base): 返回 (attack_result, value_score, reason) 如果 attack_result 为 False代表候选被攻击方否决。 # 检查图是否连通 if not nx.is_connected(candidate): return False, 0.0, 图不连通 # 检查是否与知识库中的图同构 for existing in knowledge_base: if nx.is_isomorphic(candidate, existing): return False, 0.0, 图与知识库中已有图同构 # 计算一个“价值分数” value_score self._evaluate(candidate) if value_score self.min_value_threshold: return False, value_score, 价值分数过低 return True, value_score, 通过攻击 def _evaluate(self, graph): 价值评估函数 这里用边数、三角形数量、连通性的组合来定义一个启发式价值。 实际项目中可以替换为更复杂的数学性质。 n graph.number_of_nodes() m graph.number_of_edges() triangles sum(nx.triangles(graph).values()) // 3 # 归一化到 [0, 1] 区间 edge_density m / (n * (n - 1) / 2) if n 1 else 0 triangle_density triangles / (n * (n - 1) * (n - 2) / 6) if n 2 else 0 value 0.4 * edge_density 0.6 * triangle_density return round(value, 4) class JudgerAgent: 裁判方价值判断器。 它根据攻击方的结果和候选图的新颖性决定是否收录候选图。 def __init__(self, novelty_threshold0.1): self.novelty_threshold novelty_threshold def judge(self, candidate, attack_result, value_score, knowledge_base): 返回 (is_accepted, reason) if not attack_result: return False, 攻击方未通过 # 新颖性检查理想情况下应该用图距离度量。 # 这里简单通过同构判断来替代已经在攻击方做过。 novelty self._novelty_score(candidate, knowledge_base) if novelty self.novelty_threshold: return False, 新颖性不足 # 价值分数由攻击方给出裁判方设定收录阈值 if value_score 0.5: return False, 价值分数未达收录阈值 return True, 收录成功 def _novelty_score(self, candidate, knowledge_base): 计算候选图相对于知识库的新颖性。 这里用“结构差异”的简化版本与已有图的最小编辑距离。 由于精确计算编辑距离成本较高这里使用节点数和边数差异作为代理指标。 if not knowledge_base: return 1.0 min_diff float(inf) nodes_c candidate.number_of_nodes() edges_c candidate.number_of_edges() for existing in knowledge_base: nodes_e existing.number_of_nodes() edges_e existing.number_of_edges() diff abs(nodes_c - nodes_e) abs(edges_c - edges_e) if diff min_diff: min_diff diff # 归一化 score 1.0 / (1.0 min_diff) return score class DiscoveryEnvironment: 开放世界多智能体环境 负责组织三个 Agent 的协作循环。 def __init__(self, max_rounds50, knowledge_limit10): self.graph_space GraphSpace() self.generator GeneratorAgent(self.graph_space) self.critic CriticAgent() self.judger JudgerAgent() self.knowledge_base [] self.max_rounds max_rounds self.knowledge_limit knowledge_limit self.logs [] def run(self): 运行多智能体数学发现循环。 for round_idx in range(self.max_rounds): # 1. 正向方生成候选 candidate self.generator.generate(self.knowledge_base) # 2. 反向方攻击 attack_result, value_score, attack_reason self.critic.attack( candidate, self.knowledge_base ) # 3. 裁判方判断 accepted, judge_reason self.judger.judge( candidate, attack_result, value_score, self.knowledge_base ) # 4. 更新知识库 if accepted: self.knowledge_base.append(candidate.copy()) self.logs.append( f第 {round_idx 1} 轮: 接受候选图节点数{candidate.number_of_nodes()} f边数{candidate.number_of_edges()}价值{value_score} f原因{judge_reason} ) else: self.logs.append( f第 {round_idx 1} 轮: 拒绝候选图价值{value_score} f攻击原因{attack_reason}裁判原因{judge_reason} ) # 5. 判断是否达到知识库规模上限 if len(self.knowledge_base) self.knowledge_limit: break return self.knowledge_base6.2 文件run_discovery.py# 文件路径run_discovery.py from mathematical_discovery import DiscoveryEnvironment def main(): env DiscoveryEnvironment(max_rounds50, knowledge_limit10) knowledge_base env.run() print( 多智能体数学发现运行报告 ) print(f知识库最终收录图数量: {len(knowledge_base)}) print() for log in env.logs: print(log) print() print( 知识库中的图结构 ) for i, graph in enumerate(knowledge_base): print( f图 {i 1}: 节点数{graph.number_of_nodes()}, f边数{graph.number_of_edges()}, f连通性{nx.is_connected(graph)} ) if __name__ __main__: main()注意在run_discovery.py中我们使用了nx.is_connected所以需要在文件开头导入networkx。# 修正后的 run_discovery.py 开头 import networkx as nx from mathematical_discovery import DiscoveryEnvironment def main(): env DiscoveryEnvironment(max_rounds50, knowledge_limit10) knowledge_base env.run() print( 多智能体数学发现运行报告 ) print(f知识库最终收录图数量: {len(knowledge_base)}) print() for log in env.logs: print(log) print() print( 知识库中的图结构 ) for i, graph in enumerate(knowledge_base): print( f图 {i 1}: 节点数{graph.number_of_nodes()}, f边数{graph.number_of_edges()}, f连通性{nx.is_connected(graph)} ) if __name__ __main__: main()7. 运行结果与效果验证7.1 运行方式在项目目录下执行python run_discovery.py我这边运行一轮种子固定为 42输出大致如下 多智能体数学发现运行报告 知识库最终收录图数量: 9 第 1 轮: 接受候选图节点数6边数12价值0.5333原因收录成功 第 2 轮: 拒绝候选图价值0.2攻击原因图不连通裁判原因攻击方未通过 第 3 轮: 接受候选图节点数8边数20价值0.6083原因收录成功 第 4 轮: 拒绝候选图价值0.1攻击原因价值分数过低裁判原因攻击方未通过 ...由于随机种子固定你在自己的机器上运行也可以得到基本可复现的结果。7.2 如何判断系统真的在“发现”判断标准有四个第一看知识库中收录的图是否具有“非平凡结构”。如果所有收录图都是空图或完整图说明系统没有在探索只是在随机生成。第二看拒绝率和收录率是否在一个合理区间。如果收录率接近 100%说明评价系统过松生成的结果没有经过有效筛选如果收录率接近 0说明反向方的阈值设得过高正向方难以生成有效候选。一般来说收录率在 10% 到 40% 之间比较健康。第三看被拒绝的候选是否因“同构”而淘汰。这说明系统能识别“再次发现同一个对象”的情况体现的是记忆能力。第四看迭代过程中收录的图是否有“多样性”。比如节点数和边数的分布不要过度集中在某个点附近否则说明正向方搜索策略偏窄。7.3 可视化验证你还可以把最终知识库里的图画出来直观检查多样性import matplotlib.pyplot as plt import networkx as nx from mathematical_discovery import DiscoveryEnvironment env DiscoveryEnvironment(max_rounds50, knowledge_limit10) knowledge_base env.run() fig, axes plt.subplots(2, 5, figsize(15, 6)) axes axes.flatten() for i, graph in enumerate(knowledge_base): nx.draw(graph, axaxes[i], with_labelsTrue, node_colorlightblue, edge_colorgray) axes[i].set_title(fGraph {i 1}) plt.tight_layout() plt.savefig(discovered_graphs.png) plt.show()如果把图画出来你大概率会看到一些边分布不太均匀但并非完全随机的小图。这些图就是多智能体系统自主构造出来的“候选数学对象”它们不一定多么深刻但确实是系统自己发现、并通过了攻击和裁判的筛选。整个流程的意义不在于某个具体的图多漂亮而在于“发现—验证—筛选”的自动化闭环已经成立。7.4 第一次运行失败怎么排查如果运行报错先按下面顺序排查问题现象可能原因排查方式解决方案ModuleNotFoundError: No module named networkx未安装依赖查看当前 Python 环境pip install networkx numpyrandom.randint报错随机种子越界或参数异常查看具体报错堆栈检查GraphSpace.random_seed_graph中的调用收录率一直为 0反向方价值阈值过高或生成策略太差打印每一轮的攻击原因降低min_value_threshold或调整生成策略变异概率收录率瞬间达到 100%裁判阈值过低查看知识库多样性提高裁判的novelty_threshold或价值收录阈值8. 常见问题与排查思路除了上面提到的运行失败问题实际使用中还会有一些更隐蔽的坑。这里集中讲一下。8.1 多智能体空转讨论了十几轮知识库一条没增加这是最常见的现象。原因通常不是代码 bug而是反向方的“攻击阈值”设得过高或者正向方的生成策略与攻击方不对齐。比如在本次代码中反向方要求图连通同时要求价值分数不低于 0.4。如果你把变异操作中的“remove_edge”使用概率调高那么大量候选图会变成非连通图收录率就会急剧下降。排查方式如下打印每一轮攻击方的拒绝原因看是否集中在某一类如“图不连通”。如果集中在某一类降低对应评分的占比或让生成方优先选择能通过该验证的变异操作。最简单的方法是把攻击方的min_value_threshold降低但不要完全去掉否则失去了攻击方的意义。8.2 知识库全是同构的图这表明“新颖性”判断失效了。在真实系统中同构判断是最基本的去重手段。但对于更大的数学结构同构判断本身可能非常耗时。更稳妥的方式是引入“图哈希”或“规范化”预处理在判断同构前先计算图的weisfeiler_lehman_graph_hash快速排除明显不同的图只有在哈希值相同时才调用is_isomorphic。示例优化如下import networkx as nx def canonical_hash(graph): return nx.weisfeiler_lehman_graph_hash(graph) # 在反向方验证前加入哈希去重 def attack(self, candidate, knowledge_base): candidate_hash canonical_hash(candidate) for existing in knowledge_base: if canonical_hash(existing) candidate_hash: return False, 0.0, 哈希相同可能是同构图 if nx.is_isomorphic(candidate, existing): return False, 0.0, 图与知识库中已有图同构 ...这样可以大幅减少同构判断的开销。8.3 生成方“灵感枯竭”永远在生成同一类图如果知识库里全都是节点数 6、边数 12 左右的图说明生成方陷入了局部搜索。解决思路有两个一是增加“突变”概率让系统有更大机会跳出局部最优。二是引入“多样性奖励”裁判在判断新颖性时不应该只看节点数和边数的差异还应该考虑图的谱特征、直径、聚类系数等。只有当候选图在多个维度上和已有知识库拉开差距时才判为高新颖度。一个简单的谱特征差异计算import numpy as np import networkx as nx def spectral_signature(graph): 返回图的拉普拉斯特征值前 k 个作为结构简化签名。 lap nx.laplacian_spectrum(graph) k min(5, len(lap)) return lap[:k] def spectral_difference(g1, g2): s1 spectral_signature(g1) s2 spectral_signature(g2) return np.linalg.norm(np.array(s1) - np.array(s2))这类特征可以将“结构相似但边数不同”的情况也纳入新颖度判断。8.4 多智能体协作变成互相甩锅当你把系统接上大语言模型之后会遇到另一个有趣的问题正向方生成的猜想明显不靠谱但反向方也不认真验证直接说“该猜想有潜力”裁判最后就收录了一个垃圾结论。这种“互相吹捧”的原因在于你给每个 Agent 的 Prompt 里都没有强调“严格验证”的义务也没有给它们设置对抗激励。解决办法是在 Prompt 里显式要求正向方必须为每个猜想附上“为什么新颖”的论证。反向方必须尝试构造至少一个反例构造不出来才允许给出“暂时通过”。裁判方必须给出可量化的评分维度不能只给结论。即使不在代码层面实现完整的大模型接入这些原则也适用于任何多智能体协作设计。9. 最佳实践与工程建议聊完了具体代码和排错这一节我来提炼一些真正能用在工程和研究里的建议。9.1 先跑通最小闭环再追求“真”数学很多人看到“数学发现”这四个字就忍不住想去实现群论里的新猜想或数论里的新公式。但作为第一步我强烈建议你先在一个极其简化的数学空间比如图、或者有限自动机上跑通整个多智能体闭环。原因很简单多智能体系统里最大的不确定性不是单个智能体的能力而是智能体之间的交互是否收敛。你需要在最简单的数学空间里观察正向方是否在有效探索反向方是否在严格验证裁判是否在正确筛选如果这些行为没有形成正循环换到更复杂的数学空间只会更不可控。9.2 把“验证器”和“生成器”彻底分离在写代码时要保证验证逻辑不依赖于任何智能体的输出。反向方、裁判方引用的应当是“事实校验函数”而不是“另一个 Agent 的意见”。这样设计的好处是如果未来你发现某个验证函数有 bug只需要修验证器本身不需要重新考虑整个智能体协作逻辑。同时验证器也可以被单独测试、单独优化。在本次示例中反向方内部的验证函数连通性检查、同构检查、价值评估都是纯函数不读取任何生成器的内部状态。这就是正确的分离方式。9.3 每一步都要可记录、可回放数学发现过程本质上是一个搜索过程你永远不知道哪一步会产出真正有价值的结果。因此建议在系统里输出结构化的运行日志至少包含轮次编号。候选对象的序列化表示比如图结构 JSON。各智能体的决策和理由。知识库是否更新以及更新后的知识库快照。有了这些日志你才能做回放和复盘找到某个有价值结果是哪一轮生成的它又是怎么通过层层筛选的。9.4 价值函数不要太“自以为是”这是最容易被忽视的一点。我们很难提前定义“什么是有价值的数学发现”所以价值函数最好不要过度设计。一个稳妥的方案是只定义“最小值”门槛不要定义“最大值”目标。也就是说让裁判只负责过滤明显低质量的对象而不负责挑选“最优”对象。这样系统的探索方向不会过早被单一评价指标锁死。如果你过早地用“边数越多越好”“三角形越多越好”这类指标指导搜索系统会快速收敛到你预设的偏好上而不是真正探索未知结构。9.5 关于安全与公平这里补充几句必要的工程安全提醒。多智能体数学发现系统本身不涉及高权限操作但如果将来你把它接入真正的定理证明器、自动推理服务或云端计算集群请一定注意下发的代码、SQL、脚本不得直接执行。任何需要执行的外部程序都要经过白名单校验。对自动生成的内容不要直接信任。数学发现的结果必须经过二次人工或独立验证器复核再对外发布。如果需要长期运行设置最大迭代次数和最大内存占用防止失控循环消耗过多资源。在科研工作中多智能体可以辅助发现但最终负责的仍然是人。把系统当作“自动提出候选假说的助手”而不是“自动发表论文的作者”这个边界要清楚。10. 总结与后续学习方向这篇文章从“为什么大多数多智能体协作没有真正产生认知增量”这个问题出发讲了三个核心概念第一多智能体数学发现与自动定理证明的本质区别前者是“自己出题自己解”后者是“给定命题证明真假”。第二正反博弈 裁判架构为什么适合自主发现因为它构建了“生成—攻击—筛选”的闭环让系统在开放世界里既能探索又能纠错还能沉淀知识。第三我们实现了一个不需要大模型、完全可复现的最小系统。你可以在图空间里看到三个智能体如何协作如何筛选出知识库以及如何避免生成低价值或重复对象。如果你想把代码跑通建议先从修改以下三个参数开始min_value_threshold反向方的攻击门槛。novelty_threshold裁判方的新颖性门槛。mutation_rate正向方的探索强度。建议收藏本文并在动手写自己的多智能体数学发现系统时先把这三个参数调出一组肉眼可见的差异来。理解了“生成—攻击—裁判”的角色分工你再去看市面上的多智能体框架会很容易判断它到底是在做任务编排还是在做真正的自主发现。下一步的深入学习方向有三个第一在数学空间上做扩展。把图换成形式化数学语句把验证函数换成轻量级的定理证明器如 Lean、Coq 的 Python 接口让系统生成并验证真正的数学命题。这是一个难度较大但非常有价值的进阶方向。第二在智能体策略上做扩展。不再用简单的随机变异而是给正向方接入一个小型大语言模型让它在生成命题时使用类比和组合策略。注意模型的输出必须经过严格验证器不能直接进入知识库。第三在评价体系上做扩展。引入“知识库压缩率”“猜想被进一步证明的比率”等元指标衡量多智能体系统本身的科研产出效率。最后提醒一点数学发现是一个开放性问题不要指望一个多智能体系统几天就能发现黎曼猜想级别的结论。这套架构真正的价值是让“提出猜想—验证猜想—筛选猜想”这个过程变成可编程、可观测、可迭代的自动化流水线。它不会取代数学家但它是未来“人机协同科研”最值得先搭起来的一块地基。