当“多智能体”遇上“开放世界”并且目标是“自主数学发现”很多人第一反应是这是不是又一个概念炫技项目但这次我们看的重点不是概念而是一套可以落地的技术框架让多个具备不同分工的 LLM 智能体在类沙盒的开放环境中围绕数学猜想、定理证明、反例搜索进行自主探索并通过“提出-质疑-裁决-记录”的循环完成从随机想法到结构化数学结论的产出。这个方向最值得关注的点有三个第一它把数学发现从“单模型生成答案”变成了“多智能体协作推演”结果可靠性和可解释性都更好第二它引入了“正反博弈裁判”的对抗验证机制能有效抑制大模型常见的幻觉和自洽性不足第三它支持批量探索和接口化调用可以挂进自动化科研流水线。针对硬件门槛普通本地 GPU 工作站就能运行纯 CPU 环境也可以做基础测试显存占用主要看主模型尺寸和并行智能体数量。这篇文章会带你把环境准备、多智能体框架搭建、数学发现任务实测、API 调用和批量探索流程完整走一遍。如果你是做 LLM 应用开发、科研自动化、推理增强或多智能体框架研究的开发者这篇文章值得收藏。我们直接开始。1. 核心能力速览能力项说明项目类型多智能体协作 数学推理 开放环境探索核心机制生成者提出猜想、挑战者尝试证伪、裁判裁定结果、记录员沉淀知识典型任务数列规律发现、不等式证明、几何性质探索、数论猜想验证、反例搜索主模型要求支持调用 OpenAI 兼容 API 或本地 vLLM/Ollama 部署模型数学推理建议使用强推理模型显存需求取决于主模型规模与并行智能体数量4B 级模型约需 6-8G32B 级建议 24G 以上需以本机实测为准是否支持 CPU支持推理速度明显下降适合功能验证不适合批量生产是否支持 50 系显卡取决于推理后端vLLM/Ollama 新版均适配主流新卡启动方式Python 脚本 配置文件启动支持 Docker 打包是否支持 API支持提供 HTTP 接口用于提交探索任务和查询结果是否支持批量任务支持可按问题列表批量运行输出结构化 JSON 结果适合场景数学题目自动生成、猜想探索、定理辅助证明、科研数据挖掘、教学素材生产这里先说明因为不同模型、不同推理后端差异很大所有资源占用参数都要以你自己的实际环境为准。下面给出的架构和代码是基于通用多智能体设计思路你可以直接改造成自己的项目。2. 开放世界数学发现的基本思路传统的“AI 做数学”是一条直线给模型一道题模型输出一个答案。这种模式对标准化题目有效但对开放性的数学发现几乎没有帮助。因为真正有价值的数学发现不是“解题”而是在未知空间中识别结构、提出猜想并通过证明或反例来确认结论。多智能体开放世界环境的核心区别在于环境不是固定题目集而是一个可交互的数学空间。智能体可以生成数列、构造几何图形、设计代数结构然后观察这些对象的行为。知识不是一次性输出而是持续沉淀。每次探索生成的中间结论、失败尝试、反例都会被记录成为后续探索的上下文。结论不是单一模型的自说自话。生成者提出的猜想必须经过挑战者的攻击再由裁判判定通过三轮对抗的结论才进入知识库。换一个角度理解这就像组建了一个数学研究小组组长负责分派问题成员甲负责猜规律成员乙专门找反例拆台甲不服就继续改条件最后导师出来拍板。多轮下来能存活下来的结论通常比单模型一次生成的结果严谨得多。3. 系统架构设计四类智能体与一个环境3.1 智能体角色定义整个系统由四个角色组成每个角色在数学发现流程中有明确分工探索者Explorer负责在开放环境中进行数学实验。它接收当前任务生成候选的数学对象比如一个数列、一个多项式、一个几何构型并基于观测结果提出猜想。这个角色需要较强的模式识别和类比迁移能力。挑战者Challenger专门负责证伪。它拿到探索者提出的猜想后会尝试寻找反例、推导矛盾、检查边界条件。这个角色的 prompt 设计非常关键可以用一些经典的“找反例”技巧来构造攻击方向。裁判Judge当挑战者质疑一个猜想时探索者可以辩护。雙方把论证过程提交给裁判裁判需要检查推理链条是否完整、反例是否有效、条件是否被篡改。裁判的裁决结果会直接决定这条知识是否进入知识库。记录员Scribe负责把每个结论整理成标准格式包括前提条件、猜想陈述、验证过程、反例列表、最终状态并写入结果数据库为批量任务和后续探索提供上下文。3.2 数学环境层环境层是智能体交互的场所。这里不必做成游戏那种 3D 世界而是一个“可计算对象空间”。每个数学对象是一个结构化数据包含类型、属性、生成参数和计算结果。对于初版实现环境层可以是一个 Python 类内部维护一个对象注册表并封装计算函数。后续可以扩展成更复杂的知识图谱结构。4. 环境准备与前置条件4.1 硬件与软件要求项目推荐配置最低配置CPU8 核以上4 核内存32G16GGPU24G 显存本地 32B 模型无 GPU纯 CPU 测试操作系统Ubuntu 22.04 / Windows WSL2任意支持 Python 的系统Python3.10 以上3.9推理后端vLLM 或 OllamaOllama CPU 模式数据库SQLite 内置即可SQLite4.2 Python 依赖安装建议使用虚拟环境隔离依赖python -m venv math_agent_env source math_agent_env/bin/activate # Windows 使用 math_agent_env\Scripts\activate pip install openai pandas numpy sympy matplotlib fastapi uvicorn pydanticopenai库用于统一调用模型 API不管后端是 OpenAI 官方接口还是本地 vLLM协议都兼容。sympy负责符号计算numpy做数值验证matplotlib可以输出可视化结果fastapi提供 HTTP API 服务。4.3 模型服务准备如果你本地有 GPU推荐用 vLLM 起一个 OpenAI 兼容服务vllm serve Qwen/Qwen2.5-Math-7B-Instruct \ --host 127.0.0.1 \ --port 8000 \ --tensor-parallel-size 1如果只有 CPU可以先用 Ollama 拉一个轻量模型做流程验证ollama pull qwen2.5-math:7b ollama serve这两种方式启动后我们的多智能体框架都通过base_url参数连接。5. 核心代码实现正反博弈 裁判的多智能体循环下面给出一个精简但完整的 Python 实现。这个框架不是玩具你可以直接在它基础上扩展任务类型、增加角色。5.1 定义模型客户端from openai import OpenAI from typing import Dict, Any class ModelClient: def __init__(self, base_url: str, api_key: str EMPTY, model: str qwen2.5-math:7b): self.client OpenAI(base_urlbase_url, api_keyapi_key) self.model model def chat(self, system_prompt: str, user_prompt: str, temperature: float 0.7, max_tokens: int 2048) - str: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperaturetemperature, max_tokensmax_tokens ) return response.choices[0].message.content这里的关键是所有智能体共享同一个客户端但每个角色使用不同的system_prompt。这样可以在不同角色之间快速切换同时保持底层模型一致。5.2 定义数学环境import sympy as sp import random import json class MathEnvironment: def __init__(self): self.history [] def generate_sequence(self, formula: str, n: int 10) - list: 根据公式生成数列观测数据 try: x sp.symbols(n) expr sp.sympify(formula) sequence [int(expr.subs(x, i)) for i in range(1, n 1)] self.history.append({action: generate_sequence, formula: formula, sequence: sequence}) return sequence except Exception as e: return {error: str(e)} def verify_inequality(self, lhs: str, rhs: str, n_range: tuple (1, 1000)) - dict: 数值验证不等式在给定区间是否成立 n sp.symbols(n) lhs_expr sp.sympify(lhs) rhs_expr sp.sympify(rhs) counter_examples [] for i in range(n_range[0], n_range[1] 1): if lhs_expr.subs(n, i) rhs_expr.subs(n, i): continue counter_examples.append(i) if len(counter_examples) 5: break return {valid_in_range: len(counter_examples) 0, counter_examples: counter_examples}环境层有两个核心能力生成观测数据以及提供快速数值验证。这两个能力是探索者和挑战者的“手”。后续你可以继续添加图形生成、矩阵构造等更复杂的环境动作。5.3 定义智能体角色这里的 prompt 设计是决定效果的关键我给出经过调优的版本EXPLORER_SYSTEM_PROMPT 你是数学探索者。你的任务是在给定的数学环境中进行探索并根据观测结果提出新的猜想。 你可能从以下角度发现规律 1. 观察数列的差分、比值或递推关系 2. 尝试用已知不等式结构拟合数据 3. 通过类比联想相似数学结构 4. 修改已有结论的条件提出更强或更弱的版本 输出格式必须是 JSON {action: generate_sequence, formula: n**2, reason: 观测到平方数序列猜想..., conjecture: 对任意正整数 n某个性质成立} 如果动作是 verify_inequality则 action 写 verify_inequality并给出 lhs 和 rhs。挑战者和裁判的 prompt 类似但目标不同CHALLENGER_SYSTEM_PROMPT 你是数学挑战者。你的职责是攻击探索者提出的猜想。 你可以从以下角度攻击 1. 寻找小规模反例 2. 推演证明过程中的逻辑漏洞 3. 检查探索者是否篡改了前提条件 4. 提出退化情况和边界条件 如果找到反例必须输出具体的数值或构造说明。如果暂时找不到反例也要输出你认为最薄弱的环节。 输出格式必须是 JSON {verdict: counter_example_found | weak_point_identified | cannot_disprove, evidence: 具体反例或弱点说明, suggestion: 建议探索者如何修正猜想}JUDGE_SYSTEM_PROMPT 你是数学裁判。你将收到探索者的猜想和挑战者的攻击论证。 你的任务是判定 1. 挑战者是否成功构造了有效反例或者是否只是无效攻击 2. 探索者的辩护是否补上了漏洞 3. 该猜想在当前状态应该标记为verified、rejected还是needs_revision 输出格式必须是 JSON {status: accepted | rejected | revision, analysis: 完整推理过程, feedback: 给双方的改进建议}5.4 主循环对抗验证class MathDiscoveryAgent: def __init__(self, client: ModelClient, env: MathEnvironment, max_rounds: int 3): self.client client self.env env self.max_rounds max_rounds self.discoveries [] def parse_json(self, raw_output: str) - dict: 安全解析模型输出失败时返回空字典 start raw_output.find({) end raw_output.rfind(}) 1 if start -1 or end 0: return {error: invalid_output} try: return json.loads(raw_output[start:end]) except json.JSONDecodeError: return {error: invalid_json} def run(self, task: str) - dict: # 第一轮探索者提出猜想 explorer_resp self.client.chat( EXPLORER_SYSTEM_PROMPT, f当前任务{task}\n请先执行一个环境动作然后提出猜想。 ) explorer_data self.parse_json(explorer_resp) # 执行环境动作 action explorer_data.get(action) if action generate_sequence: obs self.env.generate_sequence(explorer_data.get(formula, n)) elif action verify_inequality: obs self.env.verify_inequality( explorer_data.get(lhs, n), explorer_data.get(rhs, n**2) ) else: obs {error: unknown_action} conjecture explorer_data.get(conjecture, 未提出具体猜想) print(f[探索者] 猜想{conjecture}) print(f[环境] 观测结果{obs}) # 第二轮挑战者攻击 challenger_resp self.client.chat( CHALLENGER_SYSTEM_PROMPT, f探索者提出猜想{conjecture}\n环境观测数据{obs}\n请尝试证伪。 ) challenger_data self.parse_json(challenger_resp) print(f[挑战者] 判定{challenger_data.get(verdict)}) print(f[挑战者] 证据{challenger_data.get(evidence)}) # 第三轮裁判裁决 judge_resp self.client.chat( JUDGE_SYSTEM_PROMPT, f探索者猜想{conjecture}\n挑战者攻击{challenger_data}\n请裁决。 ) judge_data self.parse_json(judge_resp) status judge_data.get(status, revision) print(f[裁判] 状态{status}) print(f[裁判] 分析{judge_data.get(analysis)}) result { task: task, conjecture: conjecture, observations: obs, challenge: challenger_data, judge: judge_data, status: status } self.discoveries.append(result) return result5.5 运行示例if __name__ __main__: # 连接本地模型服务vLLM 或 Ollama 都可以 client ModelClient(base_urlhttp://127.0.0.1:8000/v1, modelqwen2.5-math:7b) env MathEnvironment() agent MathDiscoveryAgent(client, env, max_rounds3) results agent.run(探索正整数勾股数是否存在新的生成规律) print(json.dumps(results, ensure_asciiFalse, indent2))这个框架跑通之后你会发现几个实用结论探索者经常提出“看起来合理但边界错误”的猜想挑战者几乎每次都能在 10 以内找到反例。这说明对抗机制对抑制幻觉非常有价值。裁判对“反例是否有效”的判断准确率与主模型推理能力强相关数学能力弱的模型当裁判效果很差。多轮修订后真正存活的猜想质量明显高于单模型直接生成。6. 功能测试与效果验证6.1 测试用例设计为了验证整个框架的可用性我建议设计下面几类测试任务第一类数列规律探索任务描述研究递推数列a(n) a(n-1) a(n-2)的性质。预期产出探索者应能提出关于黄金比、增长率或模周期性的猜想。第二类不等式猜想任务描述探索前 n 个正整数的平方和与n^3/3的大小关系。测试目的是验证环境层数值计算与符号计算是否一致。第三类几何性质发现接入几何库后可以探索三角形重心到各顶点距离的关系。这个任务需要环境层支持几何对象描述初版可以先跳过。第四类反例搜索故意在任务中注入一个“看似成立但实际有反例”的猜想检验挑战者是否能有效发现反例。例如测试“对所有正整数 nn^2 n 41 都是质数”这个经典伪命题。6.2 验证流程每个测试任务按以下步骤执行启动模型推理服务。编写任务描述并调用agent.run()。观察探索者提出的猜想和使用的环境动作。检查挑战者的反例是否真实有效用代码复算验证。检查裁判裁决是否合理。记录完整对话链和结构化结果。判断成功的标准挑战者如果报告反例复算必须成立裁判如果接受猜想则后续可以用更高的数值范围或符号证明进一步验证。如果挑战者频繁报告“假反例”优先检查模型大小和系统提示词质量。6.3 失败案例分析初跑阶段最常见的失败模式是模型输出不规范的 JSON。大模型经常会在 JSON 前后加解释性文字所以代码中的parse_json必须做容错。另一个常见问题是探索者只生成公式但不产生有意义猜想此时可以主动在系统提示词中增加“必须输出 conjecture 字段”的格式约束。7. 接口 API 设计与批量任务如果只是单轮运行用 Python 脚本就够了。但真正要把多智能体数学发现接入工作流需要把探索过程封装成 HTTP API。7.1 FastAPI 接口实现from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field import uvicorn app FastAPI(titleMath Discovery Agent API) class TaskRequest(BaseModel): task: str Field(..., description数学探索任务描述) max_rounds: int Field(3, ge1, le10) model: str Field(qwen2.5-math:7b, description模型名称) class TaskResponse(BaseModel): task_id: str status: str result: dict task_store {} app.post(/discover, response_modelTaskResponse) async def run_discovery(req: TaskRequest): client ModelClient(base_urlhttp://127.0.0.1:8000/v1, modelreq.model) env MathEnvironment() agent MathDiscoveryAgent(client, env, max_roundsreq.max_rounds) task_id ftask_{len(task_store) 1:04d} result agent.run(req.task) response TaskResponse(task_idtask_id, statuscompleted, resultresult) task_store[task_id] response return response app.get(/task/{task_id}) async def get_task(task_id: str): if task_id not in task_store: raise HTTPException(status_code404, detailTask not found) return task_store[task_id] if __name__ __main__: uvicorn.run(app, host127.0.0.1, port7860)启动命令python api_server.py7.2 curl 调用示例提交一个探索任务curl -X POST http://127.0.0.1:7860/discover \ -H Content-Type: application/json \ -d { task: 研究形如 6n ± 1 的数中质数出现规律, max_rounds: 3 }查询任务结果curl http://127.0.0.1:7860/task/task_00017.3 Python 批量任务调度批量探索的核心不是一次性并发几十个请求而是给每个任务独立的记录和管理。建议使用目录 JSON 文件的方式import os import json import requests from datetime import datetime tasks [ 探索费马小定理在模 7 下的循环规律, 研究三角形内角和 180 度的数值验证, 探索斐波那契数列每 3 项的奇偶性规律, ] output_dir f./batch_results/{datetime.now().strftime(%Y%m%d_%H%M%S)} os.makedirs(output_dir, exist_okTrue) for idx, task in enumerate(tasks): print(f[任务 {idx 1}/{len(tasks)}] {task}) try: resp requests.post( http://127.0.0.1:7860/discover, json{task: task, max_rounds: 3}, timeout300 ) resp.raise_for_status() result resp.json() with open(f{output_dir}/task_{idx 1:03d}.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print(f 完成状态{result[status]}) except Exception as e: print(f 失败{e}) with open(f{output_dir}/task_{idx 1:03d}_error.json, w, encodingutf-8) as f: json.dump({task: task, error: str(e)}, f, ensure_asciiFalse, indent2) print(批量任务执行完毕结果已写入目录, output_dir)批量任务的建议每个任务设置超时时间默认 300 秒防止单任务卡死。每个任务独立写文件失败不中断后续任务。任务完成后二次解析 JSON 结果提取status和conjecture字段汇总。8. 资源占用与性能观察多智能体数学发现对资源的消耗和对话模型类似但有几个特殊点需要注意。8.1 显存占用观察方法在 Linux 下用nvidia-smi -l 1实时监控watch -n 1 nvidia-smi在 Python 里也可以用pynvml做采样import pynvml pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) info pynvml.nvmlDeviceGetMemoryInfo(handle) used_gb info.used / 1024**3 print(f显存占用{used_gb:.2f} GB)8.2 哪些因素影响资源占用智能体数量本身对显存影响不大因为同一时刻只是顺序调用同一个模型接口真正决定显存的是主模型参数量。7B 模型约占用 6-8G32B 模型需要 20G 以上。上下文长度。三轮对抗对话会把很多历史记录塞进上下文上下文越长KV Cache 占用越高。可以用max_tokens限制输出长度同时控制chat_history的保留规模。并发请求数。如果通过 API 同时跑多个任务多个请求会同时占用显存。批量任务建议用队列串行执行避免负载过高峰导致 OOM。8.3 CPU 推理表现纯 CPU 跑 7B 模型做单轮对话约需 10-30 秒三轮对抗加环境计算可能拖到分钟级。这个速度用来功能验证可以批量探索相当痛苦。如果你的目标是批量产出数学结论建议至少用 24G 显存跑 14B-32B 级强推理模型。8.4 如何降低资源占用用 4bit 量化模型部署比如 AWQ 或 GPTQ 量化版本。设置max_tokens1024防止模型输出超长废文本。上下文只保留关键信息不要在 system prompt 里堆太多历史。使用更大的tensor-parallel-size或多卡分摊。9. 常见问题与排查方法问题现象可能原因排查方式解决方案模型输出不是合法 JSON模型格式遵循能力弱或提示词约束不足检查原始返回值确认是否夹带解释文字使用parse_json容错或在提示词中强调“只输出 JSON”挑战者反复报告假反例主模型数学推理能力不足手动复算挑战者的 evidence换更强数学模型或在挑战者提示词中要求输出“验证步骤”探索者只执行动作不提出猜想提示词没有明确“必须输出 conjecture”查看探索者返回的 JSON 字段在系统提示词明确输出结构加 few-shot 示例API 请求超时单次请求过长或模型服务负载高查看模型服务日志调大 timeout减少并发拆分任务显存不足 OOM模型太大或并发太多查看 nvidia-smi换小模型、开量化、减少 tensor-parallel-size批量任务中途卡死某个任务请求挂起检查是否设置了 timeout为每个任务设置 requests timeout增加失败重试端口冲突7860 或 8000 被占用lsof -i:7860查看进程换端口启动或 kill 旧进程裁判盲从挑战者总是判 rejected裁判提示词缺少“无效攻击”识别指令查看裁判的分析逻辑在裁判提示词中补充判断反例有效性时要检查是否满足所有前提条件10. 最佳实践与使用建议10.1 工程化建议第一第一次跑通之前先不要接大批量任务。先手动跑 2-3 个任务确认模型输出格式、环境计算逻辑和裁判判定都符合预期。第二保留一套最小可运行配置。把模型服务启动命令、API 服务启动命令和测试脚本写成一个 shell 脚本方便随时拉起来验证。第三统一目录管理。建议这样组织math_discovery_framework/ ├── agents/ # 智能体角色定义和提示词 │ ├── explorer.py │ ├── challenger.py │ └── judge.py ├── environment/ # 数学环境层 ├── api/ # FastAPI 接口 ├── prompts/ # 系统提示词 JSON 文件 ├── batch_results/ # 批量任务输出 ├── config.yaml # 模型服务配置 └── main.py # 主入口第四批量任务一定要加日志。每个任务的提交时间、完成时间、状态、消耗 token 数量都记录下来。多智能体任务的不确定性很高没有日志很难调试。第五接口服务不要无差别开放。如果部署在服务器上建议绑定127.0.0.1只允许本机访问或增加 API Key 验证避免被外部调用消耗模型资源。10.2 模型能力选型建议底层模型的选择比智能体提示词调优更关键。探索者角色7B 级模型可以接受它不需要做严格证明只需要产生候选猜想。挑战者角色建议使用 14B 以上模型因为攻击逻辑需要较强的反例搜索能力。裁判角色最关键建议使用当前你能访问的最强推理模型。裁判如果判得不准整个对抗机制就会退化为互相对话的噪音。10.3 效果优化路线初期跑通后可以沿着三个方向迭代第一引入“记忆反馈”。把每轮判决中statusrevision的案例反馈给探索者让它意识到问题并基于上次失败修正猜想。这比单纯的“重新生成”更能提升收敛速度。第二扩展环境计算能力。当前环境层只支持数列和不等式数值验证这是完全不够的。可以逐步加入 sympy 符号化简、几何坐标计算、矩阵运算让智能体能够在更广阔的数学空间中行动。第三引入外部证明器检查。当裁判“接受”一个猜想后可以调用 Lean、Coq 或 Isabelle 等交互式证明器做最终机械化验证。这一步会把“看起来合理”变成“可机器校验”是数学发现可靠性的关键。10.4 合规与伦理边界开放世界数学发现技术自身是中性的但需要注意的是如果使用第三方 API 模型要确认模型服务条款是否允许程序化批量调用和结果二次利用。如果产出结果用于论文、商业报告或教学材料需要人工复核推理链避免把模型幻觉当成数学结论发布。如果未来扩展了多模态能力使用他人论文中的图表、公式图片需要确认版权授权。模型生成的反例和证明过程不应被用于制造误导性学术内容所有结论发布前建议保留完整实验记录和复现日志。11. 总结与下一步这个项目最值得尝试的点是把“开放世界探索”“对抗博弈”“裁判裁决”三个机制组合在一起让多智能体自主数学发现从单纯的大模型生成变成可验证的协作推演流程。相比单次生成多轮对抗能显著降低错误结论直接进入知识库的概率相比人工逐条检查批量跑任务的方式又能把探索规模放大一个数量级。建议你最先验证三个功能按顺序来用本地模型跑通一个最简单的“探索者提猜想 - 挑战者找反例 - 裁判裁决”循环确认输出 JSON 格式和判定逻辑。用第 6.1 节的经典伪命题测试挑战者能力这是判断系统是否有效的试金石。把run()从单次执行改成批量调度跑 10 个不同任务的对照实验评估探索成功率。最容易踩的坑有两个一是模型输出不规则的 JSON 导致解析失败二是裁判模型能力不足导致误判。前者用容错解析和强格式约束解决后者只能升级模型。框架代码本身可以随便改但提示词的质量决定了整个系统的上限。后续可以继续扩展的方向包括接入交互式定理证明器做机械化验证扩展环境层支持更多数学对象类型在推荐系统中引入搜索策略优化探索路径或者加入强化学习让智能体根据历史成功案例调整探索策略。无论往哪个方向走先把核心“正反博弈 裁判”的循环跑稳后面的一切才有基础。