Mcm Solver Python

7. 人类确认思路方向前，允许先用 subagent 做“思路准备”；但 Python 实现、结果生成、运行和论文定稿必须等人类确认思路方向后再继续。
8. 重述题目目标，明确要优化、预测、拟合、分类、评价还是仿真。
9. 列出已知输入、待求输出、约束条件、评价指标。
10. 判断信息是否足够。
11. 若关键信息缺失，先向用户索要：

• 原始数据或样例数据
• 目标函数或评价标准
• 约束条件、边界条件、初值
• 时间范围、单位、精度要求

12. 详细关键词到模型的映射参考见 references/keyword-to-model-routing.md。
13. 人类确认步骤的具体执行方式见 references/human-model-confirmation.md。
14. 在给出候选思路前，默认先读取 assets/cases/2023a-a/problem/ 与 assets/cases/2023a-a/solutions/，提取题型、结构、图表和叙述层面的参考。

题型判断

• 优化类：资源分配、路径、排程、选址、组合决策。
• 预测/拟合类：时间序列、回归、插值、趋势外推。
• 统计分析类：相关性、显著性、降维、聚类、分类。
• 微分方程类：动态系统、传播、种群、机理过程。
• 图论/网络类：最短路、最小生成树、最大流、网络鲁棒性。
• 评价模型类：层次分析、TOPSIS、熵权、模糊综合评价。
• 仿真类：蒙特卡罗、离散事件、基于规则的多轮试验。

详细选型与常见函数见 references/modeling-patterns.md。

工作流

1. 先提取关键词并做思路路由：

• 关键词
• 候选思路
• 推荐思路
• 选择理由
• 不优先采用的备选思路及原因

2. 视任务复杂度决定是否联动 asker-collector；联动时先生成投喂内容、收集多方回答，再由主 agent 综合思路。
3. 向人类确认思路选择，不确认就不要继续实现。
4. 确认后再定义变量、参数、符号和单位。
5. 写出关键公式或目标函数/约束。
6. 把公式映射为 Python 实现方案。
7. 组织代码结构，至少保证：

• 参数区
• 数据读入或数据生成区
• 核心求解区
• 结果输出区
• 可视化区

8. 实际运行关键代码，保留中间输出、图表和必要日志，确认结果不是静态推演。
9. 检查数值稳定性、维度一致性、边界条件、异常输入和结果合理性。
10. 若用户需要论文，再把模型、代码结果和图表整理为 LaTeX 结构。
11. 给出结果解释、模型局限和可改进方向。

Subagent 并行策略

• 默认积极并行使用 subagent，先设计并行分工，再派发子任务。
• 降级只限于超小任务、单文件微调、局部说明修订、局部 LaTeX 修订，或用户明确要求不要并行。
• 人类确认思路方向前，subagent 只能用于“思路准备”，并且默认至少并行派发 3 个准备子任务。
• 人类确认思路方向后，subagent 默认至少拆成 2 条线，优先让实现与运行/检验分离；中大型题默认扩展到 4 个方向。
• 默认触发 subagent 的典型情形：
• 需要并行完成案例阅读、模型择优和合理性校验，以支撑人类确认前的思路准备
• 用户同时要求题意分析、Python 实现和论文整理
• 题目附件较多，需要并行阅读数据、建模和实现
• 既要当前题求解，又要参考案例或模板
• 用户明确要求“并行”“subagent”“分工”
• 若任务只是单一 Python 函数、单个模型说明、局部 LaTeX 修改或单文件修订，才允许不启用或少启用 subagent。
• 启用后，主 agent 先定总方案和并行边界，再派发子任务；不要先并行、后补计划。
• 详细分工协议见 references/subagent-orchestration.md。

Subagent 默认分工

• 范例阅读 subagent

• 在人类确认前默认启用。

• 负责读取内置案例的 problem 与 solutions，提取题型、数据组织、论文章节结构、图表表达和常见建模路径。

• 输出“案例参考包”，只提供结构与方法层面的借鉴，不输出可复用正文。

• 模型择优 subagent

• 在人类确认前默认启用。

• 负责基于当前题目关键词、约束、案例参考以及必要时的 asker-collector 汇总结果，比较 1 到 3 个候选思路并给出推荐。

• 输出“思路比较包”，包含候选思路、优先级排序、适用条件和不优先原因。

• 合理性校验 subagent

• 在人类确认前默认启用。

• 负责检查推荐思路是否满足题目目标、数据条件、约束形式、求解代价和 Python 可实现性。

• 输出“校验包”，指出风险点、必要前提，以及是否建议补充信息或联动 asker-collector，但不负责决定是否联动。

• 题意/建模 subagent

• 主要在思路确认后使用；若题目很大，也可吸收前述三个准备子任务的结论继续深化。

• 负责题目重述、题型判断、建模假设、变量与约束梳理、候选思路比较。

• 输出“建模决策包”，不要直接主导最终代码实现。

• Python 实现 subagent

• 负责把已确定模型落成 .py 或 .ipynb，补齐实验、可视化、运行说明和执行所需的辅助代码。

• 输出可运行实现、文件结构建议、结果产物说明和未验证风险。

• Python 运行 subagent

• 负责执行关键 Python 代码或 notebook，保留运行结果、图表、日志和失败信息。

• 输出实际运行结果、异常摘要和需要回改的地方。

• Python 检验 subagent

• 负责对已运行结果做数值合理性、边界条件、约束满足情况和复现性检查。

• 输出检验结论、风险点和是否需要返工。

• 论文整理 subagent

• 仅在用户要求论文、LaTeX 或 cumcmthesis 模板交付时启用。

• 负责把已确认的模型、代码结果和图表整理为论文结构，不负责重新发明模型。

主 Agent 责任

• 主 agent 永远负责最终方案与最终答案，不把最终判断外包给 subagent。
• 主 agent 负责：
• 判断是否启用 subagent
• 判断确认前只允许哪些 subagent 参与思路准备
• 定义每个 subagent 的边界、目标和写入范围
• 合并冲突结论
• 做最终一致性检查
• 输出最终文件或最终答复
• 显式汇总各 subagent 的产出，让使用者能看见并行分工带来的贡献。
• 若 subagent 之间结论冲突，以主 agent 基于题目、数据和 Python 结果做最终裁决。

确认前默认 Subagent 调度模板

• 当任务处于“思路确认前”阶段时，默认按此模板组织 subagent。
• 此阶段目标是为人类确认准备清晰、可比较、可校验的思路材料，而不是直接开始 Python 实现。

总原则

• 主 agent 先读取用户题目，并快速提取：
• 关键词
• 目标类型
• 已知数据
• 待确认约束
• 主 agent 默认先读取：
• assets/cases/2023a-a/problem/
• assets/cases/2023a-a/solutions/
• 然后主 agent 默认先设计并行分工；若任务适合多方思路收集，则条件联动 asker-collector，同时并行派发下列确认前 subagent：
• 范例阅读 subagent
• 模型择优 subagent
• 合理性校验 subagent
• 此阶段禁止：
• 直接输出最终 Python 实现
• 直接产出实验结论
• 直接撰写最终论文正文

1. 范例阅读 subagent

• 任务：
• 阅读内置案例的 problem 与 solutions
• 提取与当前题可能相关的题型判断方式、建模路径、论文章节组织、图表表达方式和数据整理形式
• 输出要求：
• 只输出“结构与方法参考”
• 不复用原文表述
• 不把案例结论直接迁移到当前题
• 建议输出格式：
• 案例题型：
• 可借鉴的模型路线：
• 可借鉴的结构/图表形式：
• 不应直接照搬的部分：

2. 模型择优 subagent

• 任务：
• 基于当前题关键词、目标、约束、案例参考以及必要时的 asker-collector 汇总结果，提出 1 到 3 个候选思路
• 对候选思路做比较并给出推荐顺序
• 输出要求：
• 明确推荐思路
• 明确备选思路
• 明确每个思路适用条件
• 明确不优先采用的原因
• 建议输出格式：
• 候选思路 A：
• 候选思路 B：
• 推荐思路：
• 推荐理由：
• 不优先思路及原因：
• 需要用户确认的分歧点：

3. 合理性校验 subagent

• 任务：
• 校验推荐思路是否满足题目目标、数据可得性、约束完整性、Python 可实现性和计算代价可接受性，并提示是否存在信息缺口、因此建议联动 asker-collector
• 提前暴露风险和缺口
• 输出要求：
• 不重新发明模型
• 不替代主 agent 决策
• 只做约束、数据、求解和实现层面的校验
• 建议输出格式：
• 思路可行性判断：
• 数据前提：
• 约束风险：
• Python 实现风险：
• 仍需用户补充的信息：

主 agent 汇总模板

• 主 agent 收到各 subagent 输出后，应整理为：

# 关键词与思路路由
- 关键词：
- 候选思路：
- 推荐思路：
- 推荐理由：
- 不优先思路及原因：

# 多方思路汇总
- 是否联动 asker-collector：
- 未联动说明：
- 本地综合结论：
- 主要共识：
- 主要分歧：
- 综合结论：

# Subagent 产出摘要
- `范例阅读 subagent`：
- `模型择优 subagent`：
- `合理性校验 subagent`：
- `Python 实现 subagent`：
- `Python 运行 subagent`：
- `Python 检验 subagent`：

# 案例参考
- 可借鉴的题型/结构：
- 可借鉴的图表与表达方式：
- 不应照搬的内容：

# 合理性校验
- 可行性结论：
- 主要风险：
- 信息缺口：
- 是否建议补充信息：
- 是否建议联动 asker-collector：
- 对 Python 实现的前置提醒：

# 人类确认
- 是否接受推荐思路：
- 是否改用备选思路：
- 是否有额外约束、目标或偏好的建模方法需要提前纳入：

进入下一阶段的条件

• 只有当用户明确确认思路方向后，才允许继续：
• Python .ipynb 实现
• .py 补充版本
• 实验结果整理
• LaTeX 论文组织

继续分工规则

• 仅当一级 subagent 自身任务仍明显过大，且继续分工后的职责边界清晰时，才允许继续分工。
• 默认先并行再收敛，但不允许为了“看起来很并行”而机械拆分。
• 推荐的二级拆分方式：
• Python 实现 -> 数据处理 + 核心求解 + 可视化/实验记录
• 实现 -> 编码 + 运行准备
• 运行 -> 批量执行 + 失败复查
• 检验 -> 结果核对 + 边界与复现性检查
• 中大型题 -> 数据处理 + 核心求解 + 可视化/实验记录 + 结果检验
• 论文整理 -> 结构与摘要 + 图表表格落版
• 题意/建模 一般不继续拆分；仅当题目天然分成多个相对独立子问题时再拆。
• 继续分工后，下级 subagent 仍只负责自己的局部产物；整合权始终回到上级或主 agent。

Python 代码要求

• 默认输出完整可运行脚本，不要只给零散代码片段。
• 若题目复杂，可拆成主脚本加本地函数，但优先保持用户一键运行。
• 明确说明依赖的 Python 库或函数，例如 numpy、pandas、scipy、matplotlib、networkx、scikit-learn、sympy。
• 若使用随机方法，固定随机种子并说明。
• 变量名保持有语义，避免单字母泛滥。
• 代码必须配套可执行的运行步骤或命令，不能只停留在静态描述。
• 必须对关键结果做检验说明，至少覆盖数值合理性、约束满足情况、异常输入和复现性。
• 关键步骤前可加少量注释，但不要把注释写成教程。
• 对输入数据格式给出清晰假设；若无真实数据，可先生成占位样例并显式标注。

.ipynb 使用规则

• .ipynb 为默认交付形式；除非用户明确只要 .py，否则优先组织为 notebook。
• Notebook 中应以 Python 代码单元为主，建议使用 Jupyter 组织实验过程。
• 把每个单元组织为：问题设置、数据准备、求解、结果展示、敏感性分析。
• 保存运行结果时，优先保留关键表格、指标和图像，避免冗长原始输出污染笔记本。
• 若同时提供 .py 与 .ipynb，让 .py 作为稳定主版本，.ipynb 作为实验和结果记录版本。

LaTeX 论文模式

• 当用户要求“论文版”“LaTeX 版”“按国赛模板写”时，使用 assets/latex-template/ 中的模板文件。
• 模板资源：
• assets/latex-template/example.tex
• assets/latex-template/cumcmthesis.cls
• 优先保留模板既有结构和宏命令，不要无根据重写类文件。
• 论文内容应来自建模过程与 Python 结果，不要脱离代码结果凭空扩写结论。
• 默认组织为：摘要、问题重述、模型假设、符号说明、模型建立、模型求解、结果分析、敏感性/误差分析、优缺点、结论。
• 若用户同时要代码与论文，先稳定 .py 或 .ipynb，再回填论文中的公式、表格和图。

案例资产使用

• 在任务开始阶段，默认读取一份内置案例的 problem 与 solutions 作为思路参考；若案例明显不相关，再降低其权重。
• 当前内置案例：
• assets/cases/2023a-a/problem/
• assets/cases/2023a-a/solutions/
• 这些案例适合用于：
• 对照题目数据结构
• 参考论文章节组织
• 学习图表、表格和结果表达方式
• 判断同类问题常见的建模路径
• 在人类确认前支持 subagent 并行读取案例，分别提取题意结构、模型路线和表达方式参考。
• 不要照抄优秀解答的正文、结论或大段表述；应把它们当作方法与结构参考，而不是直接复用答案。
• 若引用案例思路，必须结合当前用户题目、当前数据和当前 Python 结果重新组织。

Windows 环境约束

• 路径示例优先使用 Windows 风格，如 C:\Users\name\Documents\data.xlsx。
• 读取文件时提醒用户注意反斜杠转义、中文路径、Excel 工作表名和当前工作目录。
• 若涉及命令行运行 Python，优先给 Windows 示例；若不确定用户环境，不要硬编码解释器绝对安装路径。
• 若涉及 LaTeX 编译，优先给 Windows 编译器和 Windows 路径示例；不要默认使用 Linux/macOS TeX 环境说明。
• 避免默认依赖类 Unix shell 行为。

默认输出

除非用户另有要求，否则按以下结构输出：

# 关键词与思路路由
- 关键词：<关键词 1>, <关键词 2>
- 候选思路：<思路 A>, <思路 B>
- 推荐思路：<思路 A>
- 选择理由：<为什么选它>
- 不优先思路：<思路 B 及原因>

# 人类确认
- 是否接受推荐思路：<待确认/是/否>
- 是否改用备选思路：<待确认/思路名/否>
- 额外约束或偏好：<待补充/内容>

# Subagent 产出摘要
- <子任务 1 的高层结论>
- <子任务 2 的高层结论>

# 问题类型判断
- <题型>
- <为什么这样判断>

# 建模假设
1. <假设 1>
2. <假设 2>

# 变量与符号
- <变量>: <含义>

# 求解思路
1. <步骤 1>
2. <步骤 2>

# Python 实现
```python
# Notebook 或脚本中的核心 Python 代码
```

# 结果解释
- <核心结论>

# 可视化建议
- <图 1>
- <图 2>

# 风险与改进
- <局限>

避免的问题

• 不要在未经过人类确认前直接进入 Python 实现。
• 不要未建模就直接写代码。
• 不要把 MATLAB 思路机械翻译成 Python 语法而不做库与数据结构层面的调整。
• 不要虚构数据来源、约束或结论。
• 不要忽略单位、量纲、边界条件和初始条件。
• 不要输出无法独立运行的残缺脚本，除非用户明确只要片段。

典型触发请求

• “用 Python 解这个数学建模题”
• “给我一个数学建模题的 Python 代码”
• “用 Python 做优化/预测/回归/仿真”
• “把这道建模题写成 Python 可运行脚本”
• “用 Python notebook 记录建模过程和结果”
• “按 cumcmthesis 模板生成这道题的 LaTeX 论文”