如果你关心大模型怎么真正参与数学研究而不是只做会算题的聊天机器人那“开放世界多智能体环境中的自主数学发现”这个方向值得关注。它的核心不是让 AI 做几道竞赛题而是搭建一个可扩展的数学对象空间放进多个智能体让它们自己观察对象、提出猜想、构造证明、寻找反例并把验证通过的结论沉淀成知识库。整套系统通常由探索智能体、猜想生成器、证明验证器、反例搜索器和任务调度器等模块组成可以理解为 AI for Math 与多智能体框架的一个交叉实验环境。本文会围绕这套架构拆开讲多智能体系统里有哪些常见交互模式开放世界环境怎么设计自主数学发现闭环怎么跑通本地部署需要准备什么前置条件服务怎么启动接口和批量任务怎么调以及资源占用和常见排障怎么处理。适合正在做自动定理证明、AI4Math、多智能体协作、数学教学智能体的研究者与开发者对想评估“如何把业务工具集成进多智能体系统”的工程师也有参考价值。1. 核心能力速览下面用一张表快速判断这套系统的能力边界注意其中有部分指标取决于具体实现需要按实际框架确认不能套用单一数字。能力项说明项目定位面向数学发现的开放世界多智能体研究与实验框架核心任务在开放数学对象空间中自主生成并验证猜想、定理主要组件探索智能体、猜想生成智能体、证明引擎、反例搜索器、知识库、任务调度器多智能体交互模式共享黑板模式、直接消息模式、层级管理模式、市场竞争模式另有协作/对抗/辩论/分层等目标协同视角证明后端Lean / Coq / Isabelle / SymPy / SMT Solver具体取决于所选后端推理模型云端大模型或本地开源模型均可按资源和合规要求选择推荐硬件符号计算可用 CPULLM 推理和长上下文探索建议使用 GPU显存占用取决于 LLM 参数规模、上下文长度、并发智能体数量需实测启动方式命令行 / API 服务 / Docker按具体实现而定批量任务通常可以通过任务队列批量提交探索和证明任务需按实现确认适合读者AI4Math、自动定理证明、多智能体系统研究人员与开发者从这张表能看出这个方向的价值不在单一模型而在“环境 智能体 验证工具”的组合。即使只用开源模型只要把 SymPy、Lean 或 SMT Solver 接进去系统也可以完成不少数学验证工作。2. 适用场景与使用边界这类系统适合三类场景第一面向数学定理或猜想做自动化探索把大模型当作“敢于提出新命题的助手”人工再对关键结论做复核第二验证多智能体框架本身的调度能力比如不同角色如何在共享环境中协作完成复杂任务第三数学教育场景中生成可供讨论的猜想、反例和推导路径。它的边界也很清楚不能用作生产环境的数学计算工具不能替代正式论文中的证明审查更不能把模型生成的“看起来很流畅的证明”直接当作可靠结论。数学系统里稍有不慎就会引入错误LLM 会在符号替换、量词顺序、边界条件上犯低级错误。因此系统内必须保留独立的验证环节要么接形式化证明器要么用符号计算或数值反例搜索做交叉验证。涉及版权材料、他人研究成果、未公开数据时必须确认授权。凡是自动生成并可能对外发布的数学结论至少要经过人工复核并保留完整的实验日志。3. 开放世界多智能体数学发现的整体架构3.1 数学对象空间“开放世界”在数学场景里不是指游戏地图而是指一个可以动态扩展的对象集合。例如数论空间可以包含整数、素数、同余类、数论函数代数空间可以包含群、环、域、子结构几何空间可以包含点、线、三角形、圆、变换关系。对象本身要有统一的表示方式比如 JSON 或可序列化的结构体同时要给每个对象记录属性方便智能体查询。实现时可以按域划分命名空间{ domain: number_theory, objects: [ { name: prime_sequence, type: sequence, properties: { first: 2, limit: 1000 } }, { name: coprime_pair, type: relation, properties: { min: 1, max: 100 } } ] }这样的对象空间不是静态数据库而应该允许智能体运行过程中动态注册新对象。比如一个智能体通过变换构造出新序列就可以把新序列写入知识库供后续探索使用。这就是“开放世界”和固定题库的最大区别。3.2 智能体角色划分通常可以把智能体分成五类角色探索者负责生成新的数学对象、改变对象属性、组合已有结构。猜想生成者根据对象属性之间的关系用大模型生成候选命题。证明者把候选命题输入证明后端尝试构造证明。批判者 / 反例搜索者专门寻找候选命题的反例和边界问题。管理者汇总各角色结果更新知识库判断是否进入下一轮。角色之间通过调度器协调。调度器不一定要很复杂关键是定义清楚输入输出协议。智能体返回的内容应该结构化例如候选命题、置信度、证明步骤、反例描述等。只有这样后续验证模块和知识库才能准确消费输出。3.3 环境接口与工具集成多智能体系统要接入各种数学工具比如 SymPy、Lean、SMT Solver、Wolfram 语义接口等。每个工具可以抽象成“工具函数”由某个智能体或验证模块调用。开放世界的“开放”正体现在这里只要定义好接口就能把工具动态注册进环境。一个典型接口定义class ToolRegistry: def __init__(self): self.tools {} def register(self, name, fn, description): self.tools[name] { fn: fn, description: description } def call(self, name, *args, **kwargs): if name not in self.tools: raise KeyError(fTool {name} not registered) return self.tools[name][fn](*args, **kwargs)这样一来任何业务工具都可以通过注册函数接入系统核心逻辑不需要改动。3.4 知识库与记忆知识库是整套系统最重要的部分存储已证明的定理、失败尝试、反例记录和探索历史。对数学发现来说“失败路径”同样有参考价值它能让后续智能体避免重复搜索无效区域。知识库可以由向量数据库或普通 JSON 文件实现量小的时候直接维护列表即可。每一次验证都建议记录结构化日志{ id: exp_20250601_001, statement: 对于任意素数 p2p^2-1 能被 8 整除, status: verified, proof_backend: sympy, evidence: mod_analysis, creator_agent: explorer_03, created_at: 2025-06-01T10:00:00Z }有了这样的记录系统才能追溯某个结论是谁在什么时候提出的、用什么后端验证的、验证过程是否完整。3.5 任务调度器调度器负责把“探索-猜想-证明-批判”循环拆成可并行执行的任务。探索阶段可以先并行跑多组随机构建猜想生成阶段可以基于不同上下文采样验证阶段要保证证明工具调用是串行或限流的避免同时启动太多符号计算进程导致内存被打满。调度器本身适合用一个消息队列后端使用 Redis、RabbitMQ 或本地任务队列库都可以。后面的批量任务章节还会展开。4. 多智能体交互模式与任务分工多智能体系统里交互模式决定了智能体之间怎么共享信息、怎么裁决冲突、怎么传递任务。从工程实现角度看常见归为四种模式。4.1 共享黑板模式所有智能体读写同一个公共知识库或黑板区域。探索者写入新对象猜想生成者读取并生成命题验证者把验证结果写回。这种模式实现简单适合研究探索型场景缺点是在智能体很多时会产生竞争写、信息噪音大。4.2 直接消息模式一个智能体向指定智能体发送消息直接请求协作或发送验证任务。比如猜想生成者把候选命题发给证明者证明者返回“已验证”或“找到反例”。这种模式适合构造明确的流水线但需要定义消息格式和超时重试策略。4.3 层级管理模式主控智能体负责任务拆解和结果汇总子智能体执行具体子任务。比如主控发现“需要证明一个关于素数间隔的猜想”就把任务拆成“生成候选规律”“用符号计算检查”“搜索反例”三部分分别下发给三个子智能体。优点是任务边界清楚缺点是主控容易成为瓶颈需要设计好队列和超时。4.4 市场竞争模式多个智能体针对同一命题并行生成候选证明或候选方案由验证器或评委智能体打分选出最优结果。这种模式适合“一个问题多条证明路径”的情况能提高容错性但会成倍增加算力消耗。从目标协同的角度又可以把交互模式分为协作式、对抗式、辩论式、分层式。比如猜想生成者和反例搜索者之间就是对抗式一个在努力构造命题一个在努力拆穿命题这种对抗往往比单智能体自问自答更可靠。多智能体系统集成外部工具时无论接入什么资源流程都差不多定义接口注册工具写清楚工具的使用说明再把工具调用结果加进智能体的上下文或知识库。这也是把各种业务能力接进多智能体系统的通用路径。5. 环境准备与前置条件5.1 通用软件准备虽然不同实现的具体命令不同但一套典型环境如下conda create -n math-agent python3.10 -y conda activate math-agent pip install numpy sympy requests pydantic pydantic-settings openai如果使用 Lean 作为证明后端官方一般通过 elan 安装# 以 Lean4 为例实际版本以官方文档为准 elan default leanprover/lean4:stable如果想用本地大模型做智能体推理还需要安装对应推理框架。常用选择包括 llama.cpp、Ollama 或 vLLM具体取决于显存和项目依赖。5.2 硬件与系统检查清单GPU本地推理建议至少一张支持 CUDA 的显卡纯符号计算可以只用 CPU。显存取决于模型参数量、量化位数、并发请求数和上下文长度应该按实际模型测试。内存符号计算和定理证明器相对吃内存建议 16GB 起步。磁盘代码、模型、知识库和日志会占用空间建议预留足够余量。端口调度器、WebUI、API 服务各自占用端口通常 8000-9000 段容易冲突需要检查。系统检查示例nvidia-smi python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count())如果不存在 GPU也可以用 CPU 模式跑通验证闭环只是 LLM 推理速度会明显下降。6. 安装部署与启动方式由于具体项目命令不同下面给出一套通用启动思路路径、端口和服务名都需要按实际项目替换。6.1 配置文件准备先把 LLM 服务和证明后端信息写进配置例如.env文件LLM_API_KEYyour_api_key LLM_BASE_URLhttps://your-endpoint.example.com/v1 LLM_MODELqwen2.5-72b-instruct PROOF_BACKENDsympy KNOWLEDGE_DB_PATH./knowledge.json SCHEDULER_PORT8000注意云端模型接口与本地模型接口通常兼容 OpenAI 风格但字段可能不同要按实际服务文档调整。6.2 启动主服务一般可以用命令行启动调度器和 API 服务python scheduler.py --port 8000 --config .env看到类似Uvicorn running on http://127.0.0.1:8000的日志说明服务已启动。如果日志提示端口被占用可以换端口python scheduler.py --port 8001 --config .env6.3 Docker 方式如果项目提供 Dockerfile可以通过 compose 组织多个服务docker compose up -d docker compose logs -f多智能体系统经常需要同时启动模型服务、调度器、知识库用 Docker Compose 更方便。但要注意容器是否映射了 GPUDocker Desktop 和 Linux 原生的配置方式不同。7. 自主数学发现流程功能测试与效果验证7.1 测试目标部署完成后先不要急着跑大规模探索而是用最小任务验证闭环。判断标准是系统能否在给定数学域中生成候选命题并给出可追踪的验证结果。7.2 测试一对象空间初始化测试目的确认开放世界环境能创建数学对象并写入知识库。操作步骤向服务提交一个create_domain请求创建“数论”域里面包含素数序列和同余关系随后查询知识库确认对象存在。输入示例curl -X POST http://127.0.0.1:8000/domain \ -H Content-Type: application/json \ -d { domain: number_theory, objects: [ {name: prime_sequence, type: sequence}, {name: modular_relation, type: relation} ] }预期结果返回domain_id并且后续查询能列出这两个对象。7.3 测试二猜想生成测试目的验证智能体能否基于当前对象空间生成候选数学命题。操作步骤调用“autodiscover”接口输入少量对象和约束条件让猜想生成智能体返回候选命题列表。import requests import json url http://127.0.0.1:8000/autodiscover payload { domain: number_theory, seed_objects: [prime_sequence], num_candidates: 5, max_steps: 20 } resp requests.post(url, jsonpayload, timeout300) print(resp.status_code) print(json.dumps(resp.json(), ensure_asciiFalse, indent2))预期结果返回多个候选命题每个命题包含statement和creator_agent字段。如果候选命题是空列表重点检查 LLM 输入上下文是否太短或者对象空间里是否缺少可组合的关系。7.4 测试三证明与反例验证测试目的确认候选命题能进入验证后端并返回 verified / rejected 状态。操作步骤手动提交一条已知正确的命题和一条可能错误的命题看验证器是否能区分。比如提交“对于任意素数 pp^2 - 1 能被 8 整除”这类边界条件容易出错的命题验证器应该能识别 p2 时的特殊情况。更可靠的方法是同时启用反例搜索器让它在给定范围内随机搜索反例。预期结果验证结果包含三种状态verified、rejected、unknown。如果闭环里没有rejected说明验证器可能太弱需要检查证明后端是否正确返回。7.5 测试四多智能体协作闭环测试目的验证多轮迭代中智能体之间能接力工作。操作步骤先运行探索者生成一批新对象再把新对象作为输入运行猜想生成者和批判者最后检查知识库是否新增了被 verified 的命题。这个测试是整套系统最关键的一步。它可以发现消息传递断裂、上下文过长、角色职责交叉的问题。建议开始时只启动 2 个智能体逐步增加便于定位瓶颈。8. 接口 API 与批量任务调度多智能体数学发现系统的接口可以从两部分看一部分是给上层用户使用的发现服务 API另一部分是内部智能体之间的工具调用 API。下面重点看前者。8.1 核心接口示例典型的发现服务可以提供一个/discover接口用于提交探索任务curl -X POST http://127.0.0.1:8000/discover \ -H Content-Type: application/json \ -d { domain: number_theory, seed_objects: [prime_sequence, modular_relation], num_candidates: 10, max_steps: 50, verify_backend: sympy }如果任务运行时间较长建议接口设计为异步模式先返回task_id再通过查询接口获取结果curl http://127.0.0.1:8000/task/task_12345异步模式对批量任务很重要。数学证明和反例搜索可能运行几十秒甚至几分钟同步等待容易超时。8.2 批量任务调度批量任务可以按 JSONL 文件组织每一行代表一个独立探索任务{domain: number_theory, seed_objects: [prime_sequence], num_candidates: 5} {domain: group_theory, seed_objects: [cyclic_group], num_candidates: 8} {domain: geometry, seed_objects: [triangle, circle], num_candidates: 6}调度器读入后按行创建任务放到队列中执行。设计时重点注意三件事失败重试、日志记录、资源限流。一个简单的 Python 批量提交脚本import requests import json tasks [ {domain: number_theory, prompt: 探索相邻素数之间的间隔规律}, {domain: number_theory, prompt: 探索欧拉函数 φ(n) 的取值分布} ] for task in tasks: resp requests.post( http://127.0.0.1:8000/discover, jsontask, timeout3600 ) print(resp.status_code, resp.json())如果任务量大建议先本地存一份提交记录避免服务重启后丢失进度。9. 资源占用与性能观察这类系统的资源占用主要来自三个部分大模型推理、符号计算或定理证明器、智能体上下文管理。9.1 大模型推理显存本地推理时用nvidia-smi观察显存watch -n 1 nvidia-smi显存占用主要取决于模型参数量、量化精度、批量推理并发数和上下文长度。并发智能体数量越多显存压力越大。要控制显存可以优先考虑三个方法模型量化、限制上下文长度、减少并发 Agent 数量。如果模型服务独立部署在另一台机器调度器本身的显存占用可以忽略。9.2 CPU 与符号计算SymPy、SMT Solver、Lean 这类工具主要跑 CPU。当系统批量验证大量命题时CPU 占用会快速上升。如果发现机器同时跑多个证明进程导致内存不足应该给验证模块加一个进程池限制比如最多同时跑 4 个验证任务。9.3 性能观察指标建议收集四个指标每个探索任务的耗时。每个候选命题的验证耗时。智能体上下文 token 消耗。知识库中 verified / rejected 命题的比例。这些指标可以帮助判断系统是否在“真正推进数学对象空间”还是“不断重复已有结论”。如果 verified 命题大量重复就说明探索策略缺少多样性需要在提示词中加入“避开已有结论”的约束或者扩大对象组合空间。10. 常见问题与排查方法问题现象可能原因排查方式解决方案服务启动后页面或接口打不开端口被占用或服务进程未完全启动检查日志和端口监听状态换端口或清理残留进程依赖安装失败Python 版本不匹配或包名冲突查看 pip 错误日志确认 Python 版本新建 conda 环境后重装依赖模型文件缺失没有下载完整模型或路径配置错误检查模型目录和配置中的模型路径按官方文档重新下载模型并核对路径CUDA 不可用显卡驱动版本过旧或 PyTorch 与 CUDA 不匹配运行nvidia-smi和 PyTorch 自检命令更新驱动重装对应 CUDA 版本 PyTorchLLM 调用超时模型服务负载过高或上下文过长查看模型服务日志减小上下文窗口、降低并发、开启异步任务候选命题大量重复提示词不够多样或对象空间过小检查本轮探索对象是否冲突增加新对象类型加入重复抑制约束验证器几乎全部返回 unknown证明后端接入失败或命题形式不被支持单独测试证明后端简化命题格式补充证明后端适配层批量任务卡住队列消费异常或任务依赖缺失查看调度器日志中的任务状态增加任务超时和失败重试机制内存持续增长日志和知识库无限累积查看进程内存占用定期清理中间结果将日志滚动写入文件结果不可复现随机种子未固定或上下文有状态对比两次运行日志固定随机种子增加实验版本号排障第一原则先看日志再改代码。多智能体系统往往有多个进程崩溃可能发生在调度器、模型服务或验证后端任意一层只有日志能准确定位。11. 最佳实践与合规边界第一先跑最小闭环。不要一开始就堆二十个智能体、开很强的模型。先在小型数学域上验证“探索-猜想-验证-入库”链路确认知识库能正确更新再逐步扩大规模。第二保留一套最小可运行配置。把命令、配置、所用模型版本、随机种子一并记录方便以后复现实验。数学发现最怕不可复现任何结论必须能通过同一套流程重新得到。第三模型、输入素材、输出结果和日志分目录管理。按日期和实验版本建目录不要让模型文件和实验数据混在一起避免覆盖。第四接口服务要限制访问范围。如果开放网络访问可能被任意调用产生大量无用探索任务甚至耗尽资源。建议默认绑定127.0.0.1需要外部访问时通过网关做鉴权和限流。第五批量任务要有日志和失败重试。每批任务提交前先记录任务清单任务失败后重试不超过三次重试仍失败则标记为失败不混入结果。第六涉及人脸、声音、版权素材时确认授权。虽然数学发现系统不一定直接处理这些内容但只要开放世界允许导入外部工具或素材就必须遵守数据来源和使用的合规要求。第七自动生成的数学结论不能直接发布。模型生成的证明步骤要经过证明后端或人工复核不能只看“模型认为是对的”就作为事实输出。学术场景中更要注意标注哪些结论是自动生成、哪些经过人工验证。12. 总结与下一步这个方向最值得尝试的点是让大模型跳出“单轮解题”的限制在开放数学空间中形成可持续推进的探索闭环。最先应该验证的功能不是模型能不能解复杂题目而是能不能在一个很小的数论或代数域里连续产生新的候选命题并让验证器正确区分对错。最容易踩的坑是把多智能体系统搭得很庞大却忽略了验证后端和知识库这两个真正决定数学可靠性的环节。后续可以扩展的方向很多接入更完整的 Lean 形式化库让验证结果可以直接变成形式化证明引入自动定理证明器作为第三验证者用强化学习优化探索策略把知识库换成图数据库让智能体看到概念之间的推导关系甚至把智能体产生的候选命题交给社区或人工数学家审核形成人机协作的数学探索平台。如果只是想快速评估效果建议先用一个小型数学域配一个开源模型再加上 SymPy 验证把整套链路跑通再决定是否需要上 Lean 和更大的 GPU 集群。系统的价值不只是生成命题而是让每个命题都有可靠验证、完整日志和可复现的探索路径。