从LLM到Math Agent：用工具和验证突破大模型数学推理天花板

如果你已经试过直接让大模型做数学题，大概率见过这种场景：推导过程写得头头是道，步骤一排排整整齐齐，最后一步却算出个负数腿的鸡兔同笼。这不是某个模型特别笨，而是纯LLM做数学的天然天花板——它会“演”过程，但不会“验”结果。作为“AI for Math速成”系列的第四篇，这篇我想认真聊聊从LLM到Agent的转变：为什么单靠对话式推理不行，Agent化之后数学能力会有什么本质变化，以及一个能实际解应用题、算积分、做验证的Math Agent该怎么搭、怎么调、怎么避坑。

这个系列如果你从第一篇跟下来，应该已经接触过数学数据的清洗、Prompt设计、微调这些基础操作。但到了Agent这一步，思路要换一次档：我们不再指望模型“一口说出答案”，而是让它当一个调度者，负责规划、调用工具、观察结果、修正策略。这篇面向的读者很明确——已经会调模型接口、懂一点Python、想在数学场景里把大模型用得更扎实的开发者或教研从业者。我会尽量把每一步背后的理由也讲清楚，不只是给代码。

1. 纯LLM做题的天花板：模型会“演”步骤，但不会“验”结果

1.1 三类数学任务各自失灵的方式

数学题不是铁板一块。我们把常见的数学场景粗略分成三类，看模型直接作答时的表现差异。

第一类是数值计算，比如大数乘法、代入公式求值。这类问题模型经常错在“看似合理的中间步骤”，比如计算过程写得很完整，最后一位小数错了。第二类是符号推导，比如因式分解、求极限、不定积分。模型的表现更像“背题型”——碰到眼熟的模板能模仿出正确结构，但遇到需要多步变换或非标准技巧时，推导链会悄悄断裂。第三类是应用题和证明题，模型能组织语言、列方程、写证明框架，但方程本身设错了或者关键条件看漏，后续每一步都“严谨地错下去”。

我列个简单的对照表，方便你看清楚问题出在哪：

这里有个反直觉的地方：很多数学场景下，模型的能力瓶颈不在“推理”，而在“不可验证”。语言模型是单向生成器，它输出A，不会自动检查A是否真的有外部证据支撑。人类做数学题时会打草稿、会回代、会检查条件，但你在Prompt里写得再用力，模型也只是“模仿草稿”，不是真的在演算。

1.2 我实测下来印象很深的几个翻车案例

我自己拿某几个主流模型做过一批数学测试，挑三个典型例子说给你听。

第一个是求不定积分“x乘以e的x次方”。模型直接答的时候，写出了标准的分部积分公式，中间那步“u=e^x, dv=x dx”被它写反了，最后答案自然错。问题是这个错误隐藏得很深，因为整体叙述非常流畅，你不逐项对都不知道错在哪。第二个是鸡兔同笼的古典变体，模型成功列出了“2x + 4y = 40”这样的方程，解得x=18、y=1，代入验证发现腿数不对，它居然没有察觉。第三个更让我头疼：我让它“检查刚才的答案”，它回复“经检查，推导正确”，但实际上根本就没做任何代入动作。

这些例子的共同点是：模型不是在“算题”，而是在“生成一段像答案的文本”。它没有一条外部回路去确认“这个结果成立吗”。这正是Agent化要补上的核心能力。

1.3 从“生成答案”到“求解问题”：范式转变到底改了什么

Agent化的思路是：别再让LLM直接输出最终答案，而是让它输出“解题计划”和“工具调用指令”。计算交给符号引擎或代码执行器，验证交给数值回代或差分检查，LLM只负责最擅长的部分——理解题意、制定策略、解释中间结果。

这个转变有几个本质差异：

• 生成单元变小：LLM不需要一口气生成完整解答，而是每一步生成“下一步动作”，错误被限制在单步范围内。
• 外部工具提供刚性反馈：计算器算出来的就是事实，模型无法通过“语气自信”来掩盖错误。
• 循环代替单次输出：Plan → Act → Observe → Reflect，观察结果后可以修正计划，这比一次性输出要“抗错”得多。

所以整篇的核心论点很直白：想让AI做好数学，不是换个更大的模型，而是给现在的模型配上一套可校验的工具和循环机制。下面我们把这套机制真正拆开。

2. Math Agent的骨架：不是所有工具都叫工具，关键是可控循环

2.1 最小可用的三层结构

一个能干活、不花哨的Math Agent至少由三层组成。

第一层是大脑，也就是LLM，负责三件事：理解用户的问题、根据当前状态选择工具、解读工具结果并决定下一步。第二层是手，也就是工具集，数学场景下至少要有符号计算、数值计算、代码执行、检索/回代验证这几样。第三层是记事本，也就是记忆，既要保存本次求解的轨迹，比如“上一步已经求了导数，下一步要积分”，也要能访问一些长期知识，比如公式库、题库、错题本。

三层之间最重要的是约束关系：大脑不能跳过工具直接给结论，工具不能自行决定目标，记忆不能无限膨胀。很多失败的Agent就是没管住这三条，最后变成“一个会调API的废话生成器”。

2.2 数学专项工具选型与取舍

数学场景的工具选型，第一原则是“能验证优先”，第二原则是“越可控越好”。

符号计算这块，SymPy是绕不开的选择。它适合做因式分解、化简、求导、积分、解方程等符号层面的操作。注意它返回的结果不一定是“人话”，经常有Piecewise条件表达式、复数主支、未求值的Integral对象，后面我会讲怎么处理这些输出。数值计算我用Python内置的Decimal或mpmath，少用裸浮点，尤其涉及金融应用题或需要精确舍入的场景，浮点误差会让人排查到怀疑人生。

代码执行工具是另一根拐杖。它的价值在于“让算错的过程自己露馅”——写一段Python验证某个恒等式，跑一下，不等于0就是错。但它也是安全风险最高的工具，必须加超时控制和资源限制，只允许在隔离沙箱里跑，不能直接访问宿主机文件。

检索类工具在数学场景容易被忽略。数学问题往往依赖公式库、例题库、定理条件，给模型一个“查公式”的入口，比让它硬背更靠谱。比如遇到泰勒展开的余项条件，模型可能记得模糊，但检索系统能返回教材中的准确定理表述。

我把选型思路总结成下面的表：

选型时不要贪多。刚开始只加“SymPy + 沙箱Python + 简单检索”三件就够，跑通主流程后再按需扩展。工具越多，LLM的选择负担越重，反而容易在“该用哪个工具”上纠结出幻觉。

2.3 规划循环设计：Plan-Act-Reflect

我用一个生活化的类比来解释Agent的核心循环：它不是那种一口气报答案的“速答选手”，而是老老实实在草稿纸上演算的学生。先写下“这一步我打算做什么”，再动笔，做完之后看一眼“结果合不合理”，不合理就划掉重来。这个过程拆成三个明确动作。

Plan阶段，LLM把题目拆成若干可执行步骤，并把每步的预期结果写出来。Act阶段，只执行其中一步，调用一个工具，拿到原始输出。Reflect阶段，对比“实际输出”和“预期结果”，判断是否一致、是否满足目标约束。不一致就回到Plan，换工具或改策略。

这里面的细节很重要：Act阶段必须“只走一步”，不能贪多。很多初版Agent失败的根源，就是LLM在一次回复里同时调用三个工具、做了六步推导，中途某个假设错了，后面全错，而且日志里很难定位。强制单步执行虽然会多消耗几轮交互，但错误范围小、可回滚、可观察，对数学这种“错一步毁所有”的场景特别值得。

我写一个极简的伪代码流程，方便你理解这个循环的骨架：

输入：问题P 状态：求解轨迹T = [] for step in range(MAX_STEPS): 指令 = LLM(系统提示, 工具描述, T, 问题P) if 指令 == "给出最终答案": 答案 = LLM(系统提示, 工具描述, T, "基于以上轨迹给出最终答案") 验证 = 调用验证工具(答案) if 验证通过: 输出答案 break else: T.append("验证未通过，请修正") continue elif 指令 == "调用工具": 结果 = 执行工具(指令.工具名, 指令.参数) T.append("使用了工具" + 指令.工具名 + "得到结果" + 结果) else: T.append("无法识别指令，请重新输出")

这个循环看起来简单，但它已经把“验证不通过就不允许出答案”这个规则硬化到流程里。模型可以说谎，流程不会。下面我们把它写成真正能跑的代码。

3. 快速跑通一个能解应用题的Math Agent：从代码到踩坑

3.1 框架选择和最快路线

做Math Agent的第一件事不是写代码，而是决定“手写ReAct循环还是用现成框架”。

我的建议是：如果目标是快速验证数学场景、理解Agent运行机制，手写一个轻量ReAct循环就够了，300行以内完全可控。现成的Agent编排框架虽然省事，但在数学场景里有个痛点——它对工具返回结果的解析容易“自作聪明”，把SymPy的Piecewise表达式包装成好读的字符串，反而丢失了精确信息。你需要在框架的抽象和数学工具的精确性之间反复横跳，调试成本反而上升。

手写循环的另一个好处是日志完全透明。我能看到每一步模型说了什么、意图是什么、工具返回了什么，排错时一眼就能定位。这对后面要和“验证幻觉”“死循环”作斗争的人来说，极其重要。

环境方面，Python 3.10以上，装上SymPy，以及一个能调用任意兼容GPT接口的模型客户端。不用刻意追求最强模型，中等偏上的模型反而更能暴露Agent设计的问题——因为你会被迫把流程写得更健壮。

3.2 一个真正能跑的核心骨架

我用一段简化代码展示Math Agent的运行逻辑，重点看循环结构、工具注册方式和验证强制规则。

import json import sympy as sp from openai import OpenAI client = OpenAI(base_url="你的模型服务地址", api_key="your-key") # 工具集：符号计算和数值验证，都做成函数 TOOLS = { "sympy_solve": lambda expr: sp.solve(expr), "sympy_integrate": lambda expr, var: sp.integrate(expr, var), "substitute_check": lambda f, val_dict: float(f.subs(val_dict)), } SYSTEM_PROMPT = """ 你是一个数学求解Agent。你必须按照循环工作： 1. 先理解题目，列出已知条件。 2. 每次只做一步，选用一个工具，输出JSON格式动作。 3. 工具结果必须被解释，并追加到轨迹中。 4. 最终答案前必须调用substitute_check或符号验证工具。 5. 如果验证失败，不得给出最终答案，必须继续修正。 输出格式： {"action": "tool", "tool": "工具名", "args": {...}} 或者： {"action": "final", "answer": "最终答案"} """ def run_math_agent(question: str, max_steps: int = 8): trajectory = [] for step in range(max_steps): messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": question}, *trajectory, ] resp = client.chat.completions.create( model="当前使用的模型", messages=messages, temperature=0.0, ) action_text = resp.choices[0].message.content try: action = json.loads(action_text) except Exception: trajectory.append({"role": "assistant", "content": action_text}) trajectory.append({"role": "user", "content": "输出不是合法JSON，请重新输出动作"}) continue if action["action"] == "final": answer = action["answer"] # 强制验证：这里简化成打印提醒，真实场景必须调工具验证 return answer tool_name = action["tool"] args = action["args"] # 把表达式解析成SymPy对象再交给工具 try: expr = sp.sympify(args.get("expr")) if tool_name == "sympy_integrate": result = TOOLS["sympy_integrate"](expr, sp.Symbol(args.get("var", "x"))) result_text = f"不定积分结果: {sp.sstr(result)}" elif tool_name == "sympy_solve": result = TOOLS["sympy_solve"](expr) result_text = f"方程解: {result}" else: result_text = f"未知工具: {tool_name}" except Exception as e: result_text = f"工具执行出错: {e}" trajectory.append({"role": "assistant", "content": action_text}) trajectory.append({"role": "user", "content": f"工具返回: {result_text}"}) return "超过最大步数，未得到最终答案"

这段代码把“模型必须输出JSON动作”和“每次只调一个工具”两件事固定下来了。你跑通第一步后，要做的第一件事不是加花活，而是把日志完整打印出来看，确认每个循环都走得干净利落。

3.3 带符号运算的真实题目走查

我拿一道经典微积分题来走查整个流程，题是“求x·e^x的不定积分”。如果是纯LLM直接答，就是我们前面说的翻车场景；Agent环境下，合理的轨迹应该是这样：

模型先输出计划动作：调用sympy_integrate，参数是“xexp(x)”，变量是x。工具返回“xexp(x) - exp(x) + C”或者SymPy的表达式“x*exp(x) - exp(x)”。模型看到结果后，不会直接给最终答案，而是继续调用substitute_check，在x=1和x=2两个点做数值验证：对结果求导，看是否还原成原函数。求导返回的表达式是x·e^x，和原函数一致，验证通过，才输出最终答案。

整个过程大概5到7轮交互，看起来“绕了远路”，但每一层都有一个外部反馈：积分结果来自符号引擎、导数验证来自数值代入、最终表达来自模型整理。这个“绕远路”恰恰是可靠的代价。

如果题目换成应用题，比如前面说的鸡兔同笼，第一轮模型会调用sympy_solve解方程组，但在这之前它会先列出符号定义：设鸡数为x，兔数为y，列出方程2x + 4y = 总腿数。然后工具返回解，模型再做回代验证：把解代回腿数方程，确认余数为0，才给出最终答案。你会发现，只要流程里嵌入了验证这一步，很多原本会被“自信输出”掩盖的错误，都会在工具层被拦下来。

3.4 Prompt设计里最容易忽略的四个细节

第一，工具描述必须“带场景”。不要只写“sympy_integrate可以对表达式积分”，要写“当你遇到不定积分、定积分或需要求原函数时，使用此工具；不要手动展开分部积分”。模型会按照描述里的场景去匹配问题，带场景的描述能显著降低工具误用率。

第二，要显式禁止“口头验证”。在系统提示里写清楚：“所有验证都必须是真实工具调用，禁止在文本中说‘已验证’或用自然语言推导代替。”这是对抗验证幻觉的最直接手段。

第三，给一个工具返回非预期格式的示例。比如SymPy返回Piecewise时，Prompt里可以加一句：如果工具结果带条件分支，你需要先判断当前问题落在哪个分支，再决定是否继续。没有这句话，模型通常会把所有分支一股脑写进答案。

第四，设置“修正规则”。当工具结果和模型预期不一致时，它应该做什么。我通常写：“如果工具返回空集或错误，不要编造结果，改用另一个工具或重新检查题目条件。”这一步是防止模型“脑补”出工具输出的关键。

4. 数学Agent最容易翻车的四个环节：我的排错记录

4.1 自然语言到符号语言转译歧义

第一个高频翻车点，是把题目里的自然语言条件翻译成符号表达式时出错。模型本身不是完美的“翻译器”，尤其在有歧义的时刻——它容易把“A比B的2倍多3”翻译成“2A = B + 3”，而正确是“A = 2B + 3”。这个错在纯对话模式下很难被发现，因为后续推导会“顺着错误方程走下去”。

我的排查思路是：在工具调用之前，强制模型先输出一段“符号化声明”，也就是把题目的变量定义和方程单独列出，先不急着计算。然后在下一轮让一个校验提示去检查“这个符号化声明是否与题目原文一致”。这样能把翻译错误提前暴露出来，而不是让它潜伏到最终结果。

你可以把这一步理解成“纸质试卷上的‘写出设未知数’”。人类学生考试时也要先设x、列方程，老师批改时会看这一步。Agent也一样，符号化声明必须成为流程中的独立环节，而不是随口一说的过程。

4.2 工具输出与模型认知错位

第二个翻车点，是工具返回了“精确但晦涩”的结果，模型却没看懂。最典型的就是SymPy返回的Piecewise条件表达式。模型可能照抄进答案，导致输出里出现一堆“当n为偶数时……当n为奇数时……”，看似完整，其实用户根本不知道哪个分支适用。

我踩这个坑时，第一反应是让模型“翻译”工具输出，但效果不好，因为模型对数学对象的深层结构理解不够。后来改成双层设计：工具先经过一个“翻译层”，把Piecewise按常规问题条件简化，只保留主分支，附加一个警告字段“存在未显示的条件分支，请确认”。这样模型拿到的输入变干净了，编译负担大幅降低。

另一个办法是写一个二次封装函数，把SymPy的多种返回类型统一成字符串模板。比如积分结果统一成“原函数 = 表达式，C为常数”，方程解统一成“变量 = 解集合”。封装后的输出格式稳定，模型就不会因为格式变化而犯傻。

4.3 规划失控与死循环

第三个问题最常见，也最让人抓狂：Agent陷入死循环。症状有几种——卡在同一步反复调用同一个工具、两个工具之间来回跳、或者一次写一个超长计划然后整段报错。

排查时，我靠的是“慢日志”。每轮交互都记录：模型说了什么、选择了哪个工具、工具返回什么、下一步计划是什么。回看日志会很清楚：如果Agent卡在同一步，说明它对工具结果的解析有问题，没意识到“这个结果已经足够下一步了”；如果两个工具反复跳，说明Prompt里缺少终止条件，它不知道该什么时候收手。

修复手段有两个。硬手段是在循环里加最大步数限制和同工具连续调用次数限制，超过阈值直接结束并返回“求解失败”。软手段是在Prompt里加一条“收敛条件”：当工具返回结果与预期一致，或已获得足够信息推导最终答案时，立即准备最终答案，不要继续调用工具。这两个手段一起上，死循环基本能压到极低概率。

4.4 验证幻觉：模型说“我检查过了”不一定真检查了

第四个坑很隐蔽，也是我认为Math Agent里最需要警惕的。模型经常在轨迹里写“验证通过”“结果正确”，但你去看日志，它压根没有调用过任何验证工具。这是语言模型的“社交本能”——回答问题时倾向于给一个让你满意的收尾，而不是真正跑一遍计算。

要根治这个，必须把验证从“模型的表达”变成“流程的硬性关卡”。我在循环里加了一段强制代码：final动作触发时，自动拦截一次，先调用数值代入或符号求导工具，把验证结果写进轨迹，再放行到最终答案。如果验证失败，自动把“验证失败原因”追加为一条user消息，让模型回去修正，不允许它直接输出。

这种方式会让Agent在逻辑上“没有退路”：你可以不验证，但流程不允许你进入final。从实际效果看，这一步比任何prompt技巧都管用，因为它是代码层面的约束，而不是模型层面的约束。

5. 从单Agent到多Agent协作：数学场景值得上协作吗

5.1 为什么不建议一开始就上多Agent

单Agent跑通之后，你会看到它在一个问题上能稳定工作，但偶尔还是会出错。这时候很多人会想：是不是再加一个Agent来把关更好？我的回答是：先把单Agent的日志调干净，再谈协作。多Agent的调试复杂度不是线性增长，而是指数级——日志变成多份、责任边界变模糊、一个Agent的错误会污染另一个Agent的判断。

数学场景和多Agent协作的匹配度并没有那么高。数学问题是强逻辑链，每一步都有明确的正确性标准，不需要多视角“头脑风暴”，更需要“严格验证”。所以我的建议顺序是：先把工具层做扎实，再把强制验证嵌进流程，最后才考虑用第二个Agent承担“审查”角色。

5.2 生成器与验证器分离的实际做法

如果确实要上协作，最简单的模式是“双Agent”：一个求解者，一个验证者。求解者负责出答案，验证者只看答案和原题，不参与推导，只负责挑错。这本质上是把单Agent里的“验证步骤”抽出来，变成一个独立角色，从而避免“自己解题自己检查”的盲区。

验证者的工具通常包括随机数值代入、符号恒等式检测、边界条件测试。比如求出一个不定积分后，验证者会在多个随机点检查“求导是否还原”，还会测试端点、不连续点等特殊情况。这样独立检查，比求解者自己“口头确认”要可靠得多。

我实测过效果：对于中等难度的符号推导题，双Agent能多拦下相当一部分符号错误。代价是token消耗差不多翻倍，耗时延长一倍多。如果题量比较大，成本会明显上升。

5.3 多轮辩论式协作适合什么数学任务

另一种更花哨的模式是“辩论”：两个Agent各自提出解答，互相指出对方的问题，经过几轮收敛到一个共识。这个方法在开放性问题、需要多角度分析的任务上有效，但在数学场景里，我只推荐用在证明题或开放应用题上。

原因很简单：数学题的正确答案是唯一的，辩论的价值不在“不同观点”，而在“更严格的互相审查”。如果两个Agent对某个符号变换有分歧，它们会各自用工具检查、用定义验证，多轮之后往往能暴露单Agent忽略的边界条件。但对于“2+2等于几”这种问题，上辩论就是纯浪费。

我的建议是：单Agent能解决的，不要上双Agent；双Agent模拟“求解+验证”的，性价比最高；“求解+求解+辩论”的模式，只留给证明题和复杂建模题。多Agent不是目的，它只是“更强验证”的一种实现方式。

6. 成本、评测和真实边界——别把Agent用成“慢速大模型”

6.1 时间与token成本比你想象的高

Agent化之后，一个简单应用题可能要4到8轮工具调用，每轮都带完整的轨迹历史，token消耗通常是直接让模型答题的2到3倍，如果上了双Agent，可能就是5到8倍。这不是吓唬人，而是实际运行时的常态。

有几个降低成本的常用招数。第一，历史轨迹做裁剪，只保留最近的N轮，最早的步骤压缩成一行摘要。第二，工具描述和系统提示尽量模板化，让这部分内容在请求层面保持稳定，方便服务端做前缀缓存。第三，能并行调用的工具就并行调用，比如数值验证要在5个点同时代入，别写成循环串行跑，一次性构造5次代入请求会快很多。

延迟也是问题。交互式Agent做一道题花十几秒很常见，如果应用场景是对拍批改、实时答疑，要提前做预判——要么用更快的小模型处理简单步骤，要么直接提示用户“这道题需要一点时间”。

6.2 一套务实的测评方法：不要只看最终正确率

评估Math Agent不能只看最终答对率，还要看过程质量。我自己的做法是准备20到30道覆盖算术、代数、微积分、应用题的测试题，每题记录五个指标：最终答案是否正确、工具调用是否成功、总轮数、是否出现死循环、验证阶段是否真实调用过工具。

我会把每一题的完整日志存下来，按月比对。重点观察两类指标变化：一是“验证覆盖率”，也就是最终答案前真正发生过工具验证的比例；二是“工具有效率”，也就是工具调用次数中真正帮助推进求解的比例。这两个指标比单看正确率更能反映Agent设计是否健康。

评测过程一定用固定temperature为0，保证可复现。随机性太强的话，你根本分不清是改动生效还是运气波动。

6.3 真实边界在哪，以及我现在的定位思路

最后说点泼冷水的话。Math Agent不是“AI数学家”，它是“有工具的解题器”。遇到题目本身语义模糊、缺少关键条件、或者特殊符号体系没有被工具库覆盖时，它照样会失败。一个Agent真正擅长的是“标准化数学问题”——从教科书、题库、标准考试中抽出来的问题，这类问题条件完备、符号清晰、有明确答案。

我现在的定位思路是：把Agent当“助教”而不是“教授”。它可以快速批改作业、推导常规结论、验证恒等式、生成解析过程，但在面对原创性数学研究、开放探索性问题时，它依然是一个辅助工具，而不是替代品。有了这个预期，你设计系统、评估效果时会更清醒。

如果你是从这个系列一路自己做下来的，我给的最实在的下一步建议是：先把第四节里那四个翻车点的日志排查工具做好，再继续加新功能。比如搭建一个“失败样本自动入库”的小脚本，凡是Agent最终答错或死循环的题目，自动存入错题集。这个错题集会成为你迭代最重要的资产——比任何评测指标都真实。

最后分享一个我个人的习惯：每次改动Agent，我不看一堆指标曲线，而是随机抽出三道曾经错过的题，手动跑一遍，盯日志看它们在哪个环节表现变了。这个习惯帮我躲过很多“指标好看但实际不可用”的坑。Math Agent的工程难点从来不在于“让它聪明一点”，而在于“让它足够稳定、可观测、可解释”——这才是从LLM到Agent那条路真正难走的地方。