几个月前，我一直在琢磨一个问题：现在的语言模型写文档、写代码已经挺像样了，可一旦遇到“给一堆约束条件求最优解”这类正经的数学建模问题，它们就很容易翻车。不是因为模型不够聪明，而是因为数学建模本身就不该靠“想”来完成——它需要把自然语言翻译成数学符号，再把数学符号变成可运行的代码，最后还要让求解器真正跑出数字来。这就是我做MathModelAgent的起点：一个面向数学建模任务的智能体系统，专门干“读题、建模、写代码、算答案、验结果”这条流水线。这篇东西主要是记录我搭建这个Agent时的架构决策、踩过的坑，以及一套可以复现的实操方法。如果你是做AI应用开发的，或者带数学建模竞赛、想用Agent辅助解题的，应该能从中看到不少可以直接抄走的思路。
1. 为什么数学建模成了AI Agent的“天然靶场”
先聊清楚一个前提：数学建模到底难在哪里，以及为什么它的难度分布刚好是通用大模型最不擅长的区域。
1.1 数学建模不是一个“解题”过程，而是一个“工程”过程
很多人以为数学建模就是“解一道应用题”，这是误区。一场正经的建模竞赛或者说一个实际建模任务，通常会拆成这么几步：
- 把现实问题抽象成数学语言，包括决策变量、目标函数、约束条件；
- 判断问题类型，是线性规划、整数规划、动态规划，还是图论、排队论、统计回归；
- 选择合适的求解器或算法，比如单纯形法、分支定界、遗传算法、模拟退火；
- 把模型写成代码并执行，得到数值结果；
- 对结果做敏感性分析、误差估计、模型检验；
- 最后把整个过程用文档呈现出来，保证别人能复现。
这六步里，“抽象成数学语言”和“判断问题类型”需要领域知识，“写代码、执行、检验”需要工程能力。通用大模型单轮对话能做得好的，大概只有第一步的初稿和最后一步的文档润色。中间那几环，尤其是“让代码真的跑出结果且结果合理”，恰恰是它们的老大难。
1.2 “直接给答案”是一条死路
我最早试过用普通对话方式让大模型解一道线性规划题。输入的题目描述很标准，模型也给出了“最优解x=12.5，y=3.2”这样的答案，过程看起来头头是道。但我把目标函数代回去一算，发现它根本不是在题目约束下做的优化——那个数值更像是从训练语料里“顺”出来的。也就是说，模型只是在模仿解题格式，并没有真的执行计算。
这就是我做MathModelAgent的根本动机：不能用语言模型的“记忆”替代求解器的“计算”。凡是涉及数值结果的地方，都必须交给真实的求解引擎去跑，语言模型只负责建模和编排。要让这一点可靠落地，单轮提示词做不到，必须引入Agent式的循环感知和执行。
1.3 为什么Agent形态更适合这个任务
现在的智能体，本质上可以理解为一个“有手有脚”的大模型——它能调用工具、能运行代码、能看到运行结果、能根据结果调整下一步动作。数学建模恰好特别吃这套交互逻辑：
- 建模错了，求解器会报错，Agent能读到错误信息并修改模型；
- 约束漏了，求解结果会明显偏离常识，Agent能通过验证步骤发现问题；
- 算法不收敛，Agent可以换一个求解器策略重跑；
- 反复迭代这个“建模-执行-验证-修复”闭环时，Agent天然比静态对话更有优势。
这也是我把项目命名为MathModelAgent的原因：它不追求让模型“更会做题”，而是把整套建模求解流程变成一条Agent可自主执行的流水线。
2. MathModelAgent的整体架构：教练、工程师与审查员的三角色协作
一个Agent如果什么活儿都自己干，任务复杂一点就会崩。我设计MathModelAgent时采用了一个当前比较主流的范式：多角色协作，每个角色只负责自己擅长的一段，同时通过结构化消息传递上下文。
2.1 三个角色的职责划分
我不想用成套现成框架，直接按实际需求定了三个Agent身份：
| 角色 | 负责内容 | 核心产出 |
|---|---|---|
| Coach（教练） | 理解题目、拆解需求、建立数学模型 | 变量定义、目标函数、约束条件、模型假设 |
| Engineer（工程师） | 把数学模型转成可执行代码，调用求解器 | Python求解脚本、运行结果 |
| Reviewer（审查员） | 检验结果合理性、判断是否满足约束 | 校验报告、修改建议、是否重跑的结论 |
Coach和Engineer之间用一份结构化“建模说明书”衔接，Engineer和Reviewer之间用“求解结果+校验报告”衔接，Reviewer如果发现问题，会带着具体修改建议打回给Engineer或Coach，形成一个迭代闭环。
2.2 协作流程如何设计成状态机
我用的是很朴素的状态机思路，而不是让Agent自由发挥：
COACHING：Coach读取题目，输出建模说明书；CODING：Engineer读取建模说明书，生成求解脚本并执行；VERIFYING：Reviewer检查求解结果，输出校验结论；PATCHING：校验不通过时，根据错误类型回退到第1步或第2步；COMPLETED：校验通过或达到最大迭代轮数，输出最终报告。
这个流程看起来简单，但它有个很关键的好处：每一步的输入输出都有明确的schema，而不是大段自然语言。建模说明书是JSON结构，校验报告也是固定字段，这样Agent之间传递信息时损耗很小，出错也容易定位是哪个环节出了问题。
2.3 为什么不做一个全自动一体化Agent
也许有人会问：直接让一个大模型自动规划、自动调用工具，不是更方便吗？我试过，效果很不稳。一体化Agent面对简单题目还行，一旦题目里同时有多个约束、多种求解策略，它就容易“脚踩西瓜皮”——规划出一堆动作，但动作之间没有清晰依赖关系，最后整个流程失去控制。
拆成三角色之后，每个Agent的上下文窗口里只保留它这个环节需要的信息，比如Engineer不需要阅读原题的十行自然语言背景，只需要建筑模说明书。这样既减少了上下文污染，也让每一环的Prompt可以写得非常聚焦。
3. 核心模块拆解：从自然语言题目到可执行求解代码
这一节是本文的干货重心。我会把Coach和Engineer这两个环节的prompt设计、结构定义、代码生成策略完整拆开讲。
3.1 Coach：让模型按“数学填空”而不是“写作文”的方式理解题目
Coach这个环节最大的难点，是让大模型把一道可能长达上千字的题目，压缩成一个没有歧义的数学模型。我直接放弃了让它自由撰写建模过程的做法，改用带固定字段的“建模说明书”。
建模说明书的JSON结构如下：
{ "problem_type": "integer_linear_programming", "assumptions": ["每个工单只能分配给一个产线"], "sets": ["工单集合 I = {1,2,...,n}", "产线集合 J = {1,2,...,m}"], "parameters": [ {"name": "p_i", "description": "工单i的加工时间", "value_source": "题目表格"}, {"name": "c_j", "description": "产线j的日产能", "value_source": "题目表格"} ], "decision_variables": [ {"name": "x_ij", "type": "binary", "description": "工单i是否分配给产线j"} ], "objective": {"sense": "min", "expression": "sum_{i,j} p_i * x_ij"}, "constraints": [ {"id": "C1", "expression": "sum_j x_ij = 1, for all i", "description": "每个工单必须分配一次"}, {"id": "C2", "expression": "sum_i p_i * x_ij <= c_j, for all j", "description": "产线产能上限"} ] }这其实就是在逼模型做“数学填空”。模型不需要思考怎么把解题过程写得漂亮，只需要把题目里的实体对应到变量、参数、约束上。我在实测中发现，只要题目描述是完整的数据问题，这种结构化的产出质量比自由式建模稳定得多。模型偷懒时，Reviewer也能通过constraints里是不是只有一条“满足所有限制”这种垃圾约束，快速识别出问题。
3.2 Coach的Prompt：强调“先假设、再翻译、不求解”
给Coach写的系统提示词核心规则有三条：
- 在建模说明书的
assumptions里，必须明确写出题面没有直接说明但建模需要的假设，比如“忽略产线切换时间”“物料充足”； - 变量、参数、约束必须能追回到题目原文，不允许凭空造数；
- Coach只输出模型，不输出求解方案，不写代码，不估算结果。
第三条特别重要。我早期版本让Coach偶尔会顺手写一句“最优解预计为xxx”，结果这个数值会污染后面Engineer的判断——求解器明明跑出不同结果，Engineer反而怀疑求解器出了问题。自打严格规定了“建模和求解分离”，这类问题就消失了。
3.3 Engineer：把数学模型翻译成可执行代码
Engineer拿到的输入就是上面这份JSON建模说明书，它需要完成以下几件事：
- 选择求解工具。如果是线性/整数规划，优先用
pulp或ortools；如果是非线性问题，用scipy.optimize；如果是图论问题，用networkx配合算法实现； - 把JSON里的
sets、parameters映射成Python变量； - 把
objective和constraints翻译成求解器API调用； - 如果题目数据是表格形式，生成读取数据的代码；
- 最后把求解结果（目标值、变量取值）序列化成JSON输出。
我给Engineer准备了一个可复用的代码骨架，让它基于骨架填充，而不是每次从头写。骨架大致长这样：
import pulp # 1. 数据加载 # 这里根据具体题目，从JSON参数或外部表格构造数据 # 例如：jobs = [1,2,3], lines = ["A","B"] # 2. 问题定义 prob = pulp.LpProblem("Scheduling", pulp.LpMinimize) # 3. 决策变量 x = pulp.LpVariable.dicts("assign", (jobs, lines), cat="Binary") # 4. 目标函数 prob += pulp.lpSum(p_i[i] * x[i][j] for i in jobs for j in lines), "Objective" # 5. 约束 for i in jobs: prob += pulp.lpSum(x[i][j] for j in lines) == 1, f"Assign_{i}" for j in lines: prob += pulp.lpSum(p_i[i] * x[i][j] for i in jobs) <= capacity[j], f"Capacity_{j}" # 6. 求解 prob.solve()这个骨架存在系统里，Engineer只需要改改动变量定义和约束行的具体表达式。它的好处非常实际：大幅减少了语法错误和API拼写错误。大模型写代码最怕的不是逻辑错，而是用过时的或编造的API签名，给一个固定模板，等于把它的自由度限制在了一个安全范围内。
3.4 生成代码的常见失败模式与对策
Engineer环节我踩过很多坑，最典型的有三种：
- 数据源处理错误：题目给的是Excel或CSV，Engineer经常在读取时把列名搞错。我后来强制要求必须在生成代码前先打印数据表头，并检查关键列是否存在；
- 把约束写成软约束：模型有时候会把“必须”翻译成“尽量”，在代码里写成目标函数里的惩罚项。这会导致结果和原题要求不符。解决方式是使用硬式约束写法
==、<=，并且Reviewer会核对约束条件； - 求解器状态不检查：代码跑完
prob.solve()之后没有检查LpStatus，万一问题无解，结果字段是空的，后面Reviewer根本不知道怎么回事。所以我在骨架里强制加入了状态检查，LpStatus[prob.status] == "Optimal"。
4. 数值可靠性：让Agent“跑数字”而不是“编数字”
数学建模Agent和写代码Agent最大的不同在于：它必须对自己的输出数字负责。这一节我讲两层内容，一是我怎么构建验证机制，二是怎么让验证结果反馈到Agent决策。
4.1 Reviewer的第一道检查：回代约束
Reviewer拿到的求解结果是一组变量值和目标函数值。第一件事，就是把变量值回代到建模说明书的每个约束里去，看看是否违反。
例如上面的例子，Reviewer会检查：
# 伪代码：按建模说明书的constraints逐条验证 for constraint in model_spec["constraints"]: if constraint["id"] == "C1": for i in jobs: assert sum(assignment[i][j] for j in lines) == 1 if constraint["id"] == "C2": for j in lines: assigned_load = sum(p_i[i] * assignment[i][j] for i in jobs) assert assigned_load <= capacity[j]这一步看似多余，其实价值极大。因为语言模型生成的代码即使能跑通，也不代表跑的就是建出来的模型。有时候Engineer会在翻译约束时“手滑”，把<=写成==，导致结果看起来“有值”但模型和说明书不一致。回代验证就是用说明书反查代码，把两层符号翻译之间的偏差兜住。
4.2 Reviewer的第二道检查：量纲和常识合理性
数字正确还不够，还得“合理”。这一层是语言模型相对擅长的，因为它的常识积累比较强。我会让Reviewer执行下面这些启发式检查：
- 变量值是否是预期类型，比如二进制变量是否全部为0或1；
- 目标函数值是否为有限正数（没有NaN或Infinity）；
- 关键结果是否在直觉范围内，比如分配问题的总耗时不应超过所有产线的最大可承受负荷；
- 松弛变量是否为0（对于等式约束而言）。
如果Reviewer发现“结果和常识相悖”，它不需要人类介入，而是回到Coach或者Engineer那一步重新走。
4.3 反馈信息的结构化设计
Reviewer输出的校验结论是MathModelAgent闭环的关键。我的设计是，哪怕校验不通过，也必须返回结构化错误信息，而不是一句“这个结果不太对”：
{ "verdict": "rejected", "reason_code": "CONSTRAINT_VIOLATION", "details": { "constraint_id": "C2", "expected": "sum_i p_i * x_ij <= c_j for all j", "actual": "line B load = 19.5 > capacity = 19.0" }, "suggestion": "检查产能约束是否遗漏了产线B，或将部分负荷转给产线A" }把错误分类成SYNTAX_ERROR、CONSTRAINT_VIOLATION、UNREASONABLE_VALUE、SOLVER_TIMEOUT等类型，Engineer和Coach就能根据错误类型做定向修复，而不是盲目重跑一遍。
5. 一次完整实测：我把MathModelAgent丢到一道生产调度题上
理论讲再多，不如拿一道真实题目走一遍流程。这儿我用一道改造过的生产调度题做演示：三台设备、五个工单、每个工单有加工时间，每台设备有每日可用产能，要求总完成时间最短且每台设备都不得超过产能上限。
5.1 题目输入与Coach的建模输出
题目描述我刻意写得比较啰嗦，包含了不少背景信息，比如“设备A是新引进的，加工速度较快”“工单3来自重要客户，必须当天完成”。Coach的输出里，assumptions明确写出“重要客户单必须分配给任意一台设备并在当天完成”，constraints里则加入了due_date的硬约束，而不是像人类新手一样把它当背景信息忽略掉。
这一轮Coach做得不错，因为提示词里专门有一条：“题目中的关键业务细节如果不能建模，必须在assumptions里说明原因，否则视为遗漏”。
5.2 Engineer执行的第一次求解
Engineer生成的代码跑通了，pulp返回Optimal，目标函数值为36.5小时。表面上一切正常，但Reviewer回代时发现：其中一个工单被切碎了——题目明确说“每个工单只能完整分配给一台设备”，但Engineer把x_ij定义成了连续变量而不是二进制变量，于是求解器给出x_1A=0.7, x_1B=0.3这样“一部分放A，一部分放B”的方案。
这个坑特别典型。模型在阅读建模说明书时把binary这个字段漏掉了，代码里决策变量定义成cat="Continuous"。如果只看目标函数，36.5小时还挺漂亮，但这根本不是题目允许的方案。
5.3 Reviewer如何拦截并触发修复
Reviewer的检查逻辑里有一条专门针对类型违例的规则：当建模说明书声明决策变量为binary但求解结果出现分值时，直接标记reason_code="VARIABLE_TYPE_VIOLATION"，并带着actual数值打回给Engineer。
Engineer收到反馈后，把cat参数改成Binary，重新求解后得到目标函数值38.0小时，各工单分配结果均为整数。Reviewer再跑一轮回代检查，发现全部约束满足，这才放行。
整个过程耗时大约4分钟（算上大模型调用和求解器执行），没有人工修改一行代码。我觉得，这个结果已经能吊打大多数依赖纯对话式AI解题的方式了，因为你得到的每个数字都有求解器和验证逻辑背书，而不是凭空生成的。
5.4 一次实测暴露出的隐性缺陷
虽然最终结果正确，我也发现了Agent的一个倾向：它面对“重要客户工单必须当天完成”这类业务软信息时，如果没被Prompt明确要求，常常会自动用一个较大的惩罚系数塞进目标函数，而不是建模成硬约束。这种处理在数值上可能得到差不多答案，但本质上改变了解的空间。后来我在Coach的说明规范里加了一条“软约束必须显式声明并给出惩罚系数，业务硬要求必须建模为硬约束”，彻底堵住了这个口子。
6. Agent跑偏的常见原因排查：规划失控、约束遗漏与数值幻觉
如果你也想在自己项目里复刻MathModelAgent，或者正在调试类似的建模Agent，下面这几个问题是最高频的，我把排查链路直接写出来。
6.1 规划失控：Agent一步列了20个子任务
症状：Agent生成一个特别长的执行计划，每一步看起来都合理，但真正执行起来不是这步卡住就是那步输出格式对不上。
根因：我一开始允许Coach为整个问题做全局规划，它把读题、清洗数据、建模、写代码、调试、画图、写报告全列进去了，Plan越长，模型自回归的中间错误就越容易累积。
排查链路：
- 检查Agent是否在做“伪规划”——计划文本有，但每个子任务的输入输出没有定义；
- 检查子任务之间是否存在依赖冲突；
- 检查是否有子任务需要上一步的输出，但上一步并没有输出这个字段。
解决方式：把可执行的原子任务控制在6步以内，超出则分成两个阶段，比如先建模，再求解，不要在同一个状态里同时做。这个和人类工作的道理一样，先想清楚模型，再写代码，而不是边写代码边改模型。
6.2 约束遗漏：求解器跑得飞快，结果却违反常识
症状：目标函数值很好，但人工一看就知道结果不对，比如某台设备超负荷。
根因：Coach在建模说明书里漏了约束。多为情况是题目里多条约束藏在长篇背景文字里，模型只抓到了显眼的数字，丢了隐含条件。
排查链路：
- 把题目原文逐句和建模说明书
constraints比对，找出未覆盖的句子； - 检查是否把约束写进了
assumptions而不是constraints——这是很搞笑的错误，模型会把“每个工单只能分配给一台设备”当成“假设”，弄成了默认情况； - 用题目里的极端输入做敏感性测试，比如把所有负荷扔给一台设备，看是否触发约束。
解决方式：在Reviewer校验阶段加入“题目信息覆盖率”检查——让另一个独立的模型实例读原题并把所有数字相关句子转录出来，再和建模说明书的参数、约束列表做比对，检查是否有未建模的数字信息。
6.3 数值幻觉：Agent报告的结果和求解器输出对不上
症状：求解器输出的目标值是38.0，Agent在最终报告里写成了“约40小时”，还附了一段自己脑补的解释。
根因：生成最终报告时，大模型没把求解器输出当作“权威数据”，而是基于自己的语言习惯润色了一遍。这是最危险的数值幻觉，因为答案看起来非常流畅。
排查链路：
- 检查最终报告里每个数字是否都有对应的
evidence字段，指向求解器某一次运行的输出文件； - 检查报告生成的Prompt中是否带了完整的求解结果JSON，如果只带文字版摘要，模型就会自己发挥；
- 检查有没有summary环节——有些模型在中间自己写了一条摘要，后续报告基于摘要生成，于是越传越失真。
解决方式：在最终报告模板里强制使用“变量名-数值-来源”三段式引用，例如“目标函数值38.0小时（来源：run_003.pkl，LpStatus=Optimal）”。只要来源字段缺失，Reviewer直接打回重写。实测下来，这个机制能让数值幻觉降到几乎为零。
6.4 死循环式修复：Agent反复改同一个问题
症状：Agent修完A问题，重新跑又出B问题，再修B问题把A问题又带出来了，然后来回跳，直到跑满最大迭代轮数。
根因：没有记录历史修复记录，每次打回时只反馈当前错误，Agent不记得之前修过什么。
解决方式：在状态机里加一个patch_history字段，所有修复建议都会追加进去。当新错误出现时，先判断它是否和某条历史修复记录相关——如果相关，说明是回归问题，要采取更极端的措施，比如直接重写整个代码模块，而不是打补丁。这招特别管用，因为语言模型倾向于在已有代码上做最小改动，但有时候最小改动就是会引入新bug。
7. 后续扩展与几点实践心得
MathModelAgent目前在我这边已经稳定用于数学建模竞赛辅导和一部分运筹学教学场景。我能明显感觉到，这个项目的上限不在“会不会建模”，而在于能不能把工程校验做扎实。模型能力会不断升级，但“跑数字、验结果、追来源”这套工程作风，是这个系统真正的护城河。
我后续打算扩展几个方向：一是加入多目标优化支持，让Coach直接输出带Pareto前沿分析的建模说明书；二是对接Matplotlib和LaTeX，让Engineer在输出结果时自动生成图表和排版好的公式；三是把Reviewer升级成一个可插拔的差分校验器，用不同求解器跑同一模型对比结果，进一步筛掉求解器层面的数值异常。
最后分享一下我自己最深的经验：做数学建模Agent，不要花太多时间在提示词的艺术性上，要把精力放在输入输出结构定义和验证闭环上。提示词写得再花哨，也不如一份清晰的JSON建模说明书加一个强约束校验器管用。这就像带一个聪明但粗心的实习生——你要做的不是反复叮嘱他小心，而是给他一张足够详细的检查清单和工作模板。
