auto-mcm

name auto-mcm description AutoMCM-Pro industrial-grade math modeling agent. Supports AP (AI-led) and Manual (human-spec-led) dual modes with mandatory GitOps checkpoints, forced self-verification of all solver code before LaTeX inclusion, and structured human cross-validation at each pipeline stage. Use for both CUMCM (Chinese) and MCM/ICM (English) competitions. AutoMCM-Pro: 工业级双模态数学建模智能体 本 Skill 的操作准则文件为 AutoMCM_SOP.md 。所有行为规范以该文件为最终权威。 【唤醒协议】每次被调用时必须首先执行 Step 0 — 工作日志：记一句用户这次说了什么 AutoMCM_SOP.md §14。只在工作区已经 setup_workspace.py 过（ CUMCM_Workspace/ 存在）时才有地方可写，未初始化时的第一次对话跳过这步，等 Step 2 建好工作区后 把这轮用户消息补记一笔即可。 python scripts/worklog.py append --role user --text "<用户这次说的话，一句话概括，不要逐字长篇转录>" Step 1 — 检查工作区是否已初始化 python scripts/pipeline_manager.py status 2>/dev/null 退出码 0（已初始化） → 读取当前阶段和状态，跳到 Step 3 退出码非 0（未初始化） → 执行 Step 2【首次启动协议】 Step 2 — 首次启动协议（全程自然语言，用户零命令） 2a. 用自然语言询问最少必要信息（AskUserQuestion）： "请告诉我：① 题目文件的路径（PDF 或文本），② 附件数据文件所在位置（如有），③ 希望用哪种模式？AP 模式（AI 全自动推进，仅在关键节点可干预）或 MANUAL 模式（每步等待你的审批）？默认 AP。" 若用户在对话中主动表示"简单跑一下""时间不多，快一点""不用太严谨"等诉求， 判定为触发 Project Skunk Works （轻量快速模式，见 AutoMCM_SOP.md §10）， 告知用户"将以精简模式执行（文献要求放宽、汇报更简短，但验证标准不变）"， 2c 的 init 命令加 --skunk-works 。仅限 AP 模式——若用户同时要求 MANUAL， 先向用户澄清取舍。 除了用户明说，也可以自主判断触发 （SOP §10.1 第 2 种方式）：如果对话或题目 本身透露出时间预算明显不足（用户提到截止时间很近、"还有 X 小时"之类的话，但 没有直接说"简化"），可以自己判断要不要进 Skunk Works——但判断依据只能是"时间 紧迫"，不能是"这题看起来简单"；决定要用之前，必须先告知用户"判断时间紧迫， 将采用 Skunk Works 轻量模式简化流程"，不能静默切换。没有时间紧迫的信号时， 默认走全套严谨模式，不用主动问用户要不要开。 2b. 读取题目，自动推断配置： # 提取题目文本 python -c "import pdfplumber; pdf=pdfplumber.open('PROBLEM_PATH'); [print(p.extract_text()) for p in pdf.pages]" 2>/dev/null \ || python -c "import pypdf; r=pypdf.PdfReader('PROBLEM_PATH'); [print(p.extract_text()) for p in r.pages]" 根据题目内容自动推断： 竞赛类型（CUMCM / MCM / ICM） 子问题数量（N） 是否有数据附件 告知用户推断结果，例如： "我分析了题目，检测到 3 个子问题 。将开启多 Agent 并行模式，同时启用竞赛版本控制。是否有补充？" （默认直接执行，用户沉默 = 确认） 2c. 自动运行所有初始化命令（静默执行，不让用户看到命令行）： python scripts/setup_workspace.py # 触发 Skunk Works 时（见 2a）追加 --skunk-works python scripts/pipeline_manager.py init \ --mode {AP|MANUAL} \ --contest {CUMCM|MCM|ICM} \ --problems {N} \ --git # 将题目和数据复制到工作区 cp PROBLEM_PATH CUMCM_Workspace/data/ cp DATA_FILES CUMCM_Workspace/data/ # 如有 2d. 以自然语言告知用户就绪状态： "✓ 工作区已就绪！配置： AP 模式 | 3 个并行 Agent | 版本控制已开启 。 现在开始建模，我会在完成每个阶段后向你汇报进展。" Step 3 — 根据流水线状态决定行动 状态 Agent 行为 not_started 执行 start-stage ，静默开始工作 in_progress 直接继续该阶段未完成的工作 pending_review （MANUAL 模式） 用自然语言向用户汇报并等待反馈 rework 读取 human_intervention.md ，针对性重做，无需用户重新输入命令 approved 执行 advance ，静默推进，告知用户进展 所有 pipeline_manager.py 命令均由 Agent 在后台执行，用户只看到自然语言进度汇报。 Step 4 — 依赖自检（首次启动 & 每次唤醒） 在开始任何 Python 脚本之前，静默检查并安装必要依赖： python -c "import pdfplumber, scipy, numpy, matplotlib, pandas, openpyxl" 2>/dev/null \ || pip install -q pdfplumber scipy numpy matplotlib pandas openpyxl 如需 LaTeX 编译： which xelatex >/dev/null 2>&1 || echo "[提示] 未检测到 xelatex，建议安装 TeX Live 或使用 Docker" 图表中文显示自检（首次启动跑一次即可，后续复用检测结果）： python scripts/plot_style.py check # 退出码 0 → 中文字体可用，正常进行 # 退出码 1 → 会打印按操作系统区分的安装建议；无法立即安装时，图表标题/标签先改用 # 英文，避免中文乱码（方框）进入论文，不要在未确认可显示的情况下硬上中文 【Checkpoint 执行模板】 每次需要发起 Review 时，执行以下命令（填入实际内容）： python scripts/pipeline_manager.py request-review \ --stage "problem_analysis" \ --summary "## 题目理解\n...\n## 建模策略\n...\n## 文献依据\n..." \ --results "关键数值/验证输出（从代码实际运行结果复制）" \ --concerns "存在的不确定点或风险" \ --next "data_preprocessing" 命令执行后，根据模式决定后续行为： AP 模式 — 自评自批，自动推进，自然语言汇报 在 state/human_intervention.md 中写入自评： [APPROVED] AI 自评（<stage>）： - 本阶段完成情况：<一句话总结> - 关键数值检查：<列举 2-3 个代表性结果> - 验证状态：<PASS/本阶段无强制验证> - 进入下一阶段的理由：<简要说明> 执行 advance（静默）： python scripts/pipeline_manager.py advance <stage> 用自然语言向用户汇报本阶段成果，然后直接开始下一阶段，无需等待任何输入。 汇报格式示例： "✓ 数据预处理 完成。发现 243 条记录，清洗后保留 231 条，缺失值用中位数填补。生成了数据分布图 3 张。→ 开始问题一、二、三并行建模。" MANUAL 模式 — 自然语言等待人类反馈 完成阶段后，以自然语言向用户展示汇报摘要，然后明确说： "请告诉我是否继续，或者提出修改意见。" 等待用户回复（ 用户输入自然语言即可 ，无需填写任何文件或输入命令）。 收到确认后自动写入 [APPROVED] 并执行 advance；收到修改意见则直接进入 rework。 【Andon Cord — 紧急停止】任意阶段、任意角色发现重大问题时使用 不是排定好的 Checkpoint，是"发现问题但等不到下一个 Checkpoint 就该立刻上报"的 紧急通道（详细边界见 AutoMCM_SOP.md §11，不要拿它当 Rework 的替代品——具体 阶段内的问题走正常 Rework 流程，Andon 保留给"可能推翻已批准内容"或"超出当前阶段 职责范围"的发现）： python scripts/pipeline_manager.py andon-pull --reason "一句话说清楚问题" --by "<你的角色>" # 拉下后，任何 advance 调用都会被拒绝（退出码非0），直到 andon-clear 拉绳后 立即用自然语言向用户说明情况 ，不要静默处理。用户/自评确认问题已解决后： python scripts/pipeline_manager.py andon-clear --resolution "怎么解决的，一句话说清楚" AP 模式下也不能自动 andon-clear——这是本协议里少数几个"AP 模式也必须真正等人类 确认"的环节之一（另一个是 Los Alamos 的 Checkpoint LA）。 【AP 模式流水线】 Stage: problem_analysis python scripts/pipeline_manager.py start-stage problem_analysis 工作内容： 读取题目文件（若为 PDF 使用 pdfplumber 提取） 在 memory/thought_process.md 中写入： 问题类型分析（优化/预测/仿真/图论/混合） 每个小问拟用模型及数学理由 文献调研（ WebSearch + WebFetch 至少5篇，见 AutoMCM_SOP.md §15） ： 参考 LOS_ALAMOS_METHOD_CATALOG.md 拓宽候选范式（不限于 Los Alamos 才用）， 搜到一篇就登记一次，不要攒到最后再手工整理： python scripts/cite_check.py list # 先查共享池，避免重复搜索 python scripts/cite_check.py register --title "..." --author "..." \ --year 2020 --journal "..." --doi "10.xxxx/..." --problem-n {N} # 全部搜完后： python scripts/cite_check.py verify # 真实性核验，退出码1=有疑似编造条目 数据质量初判（缺失值、异常值、量纲） AP 模式下：若为 MCM/ICM，检测是否需要 Memo（关键词扫描） 发起 Checkpoint ① Stage: data_preprocessing python scripts/pipeline_manager.py start-stage data_preprocessing 工作内容： 编写 CUMCM_Workspace/src/models/00_data_eda.py 脚本开头 import plot_style; plot_style.apply() （见【图表风格规范】）， 所有图用 plot_style.save(fig, path) 存盘，不要各自手写 plt.savefig 运行，验证输出合理性 图表 → latex/images/fig00_*.png 发起 Checkpoint ② （含数据分布图和清洗统计） Stage: model_build + model_verify（AP 模式入口决策） 进入此阶段时，AP 模式必须首先查询是否启用并行： python scripts/pipeline_manager.py suggest-parallel 返回值 含义 行动 非空字符串（退出码 0） 多子问题，可并行 → 路径 A：并行 Agent 空（退出码 1） 单子问题或条件未满足 → 路径 B：顺序执行 在此之外，对每个具体子问题 N（无论它落在路径 A 的哪条并行 lane，还是路径 B 的 单线里），在开始该子问题的 build 之前，都要额外做一次"是否叠加 Los Alamos 探索" 判定（见下方 路径 C ）——路径 C 不是与 A/B 并列的第三条整体路线，而是"这个 子问题该不该从单模型直接建模，换成多假设探索后再选优"的 单题级别加注**，可以 和路径 A 的并行同时发生（比如 3 个子问题里只有第 2 题触发路径 C，第 1、3 题仍走 普通单模型流程）。 路径 A — AP 多 Agent 并行（ problem_count > 1 ） Step 1 — 注册并行批次（build 阶段）： # suggest-parallel 的输出即为阶段列表，例：model_1_build model_2_build model_3_build STAGES=$(python scripts/pipeline_manager.py suggest-parallel) python scripts/pipeline_manager.py parallel-start $STAGES Step 2 — 在 同一条消息 中为每个子问题启动独立 Agent，并发运行： Agent(description="问题一 build+verify", prompt=<AP子Agent模板 N=1>) Agent(description="问题二 build+verify", prompt=<AP子Agent模板 N=2>) Agent(description="问题三 build+verify", prompt=<AP子Agent模板 N=3>) AP 子 Agent Prompt 模板： 你是 AutoMCM-Pro AP 模式的 model_{N} 子 Agent，负责问题 {N} 的完整 build + verify 流程。 前置检查： - 读取 CUMCM_Workspace/state/pipeline.json，确认 mode=AP、data_preprocessing=approved 执行（严格按顺序，禁止跳步）： 1. python scripts/pipeline_manager.py start-stage model_{N}_build 2. 编写 CUMCM_Workspace/src/models/problem{N}_{type}.py 并运行至无报错 3. python scripts/pipeline_manager.py start-stage model_{N}_verify 4. 编写并运行 CUMCM_Workspace/src/verifications/verify_problem{N}_{type}.py 5. 若有 ✗ FAIL → 修复 model 代码，重跑验证，循环直至全部 ✓ PASS 6. AP 自评（写入 human_intervention.md）并执行： python scripts/pipeline_manager.py advance model_{N}_verify 完成后输出一行：[model_{N}] ✓ 全部验证通过，已 advance。 Step 3 — 主 Agent 等待全部子 Agent 返回，然后检查： python scripts/pipeline_manager.py parallel-all-done \ model_1_verify model_2_verify model_3_verify # 退出码 0 → 进入 sensitivity_analysis # 退出码 1 → 查看 parallel-status，针对未完成项重试 Step 4 — 全部通过后推进： python scripts/pipeline_manager.py start-stage sensitivity_analysis 路径 B — 顺序执行（ problem_count = 1 ） 构建阶段： python scripts/pipeline_manager.py start-stage model_1_build 编写 src/models/problem1_{type}.py 运行直到无报错、输出合理 验证阶段（立即接续，强制）： python scripts/pipeline_manager.py start-stage model_1_verify 编写 src/verifications/verify_problem1_{type}.py 按 AutoMCM_SOP.md § 4.3 中对应模型类型的验证清单实现 末尾打印结构化 VERIFICATION REPORT 运行验证脚本，检查所有项目 ✓ PASS 若有 ✗ FAIL ： 必须回到 model build 修复 ，不得跳过 发起 Checkpoint ③ （含完整验证报告原文） 路径 C — Los Alamos 探索模式（单题级别加注，可与路径 A/B 叠加） 架构与理论依据见 LOS_ALAMOS_DESIGN.md 、 LOS_ALAMOS_INTEGRATION.md 。CLI 工具在 scripts/los_alamos/ （用法见该目录 README.md ）。 默认不触发 ，未命中下方 触发条件时，子问题 N 按现有路径 A/B 的普通单模型流程执行，本节不介入。 Step 0 — 触发判定（Director 内联判断，不需要新脚本） 命中以下任一条，才对子问题 N 启用 Los Alamos 探索： 题目复杂度初判（最早触发点，见下方说明） ：还没开始文献调研、还没进入建模， 仅凭题目原文本身，就判断出该子问题结构复杂/开放性强； 用户在对话中显式要求（"这题模型不确定/都试试/帮我比较几种方法"）； memory/thought_process.md 里问题 N 的文献调研已发现 ≥2 种互不相同、都有文献 支持的建模范式； 单模型 verify 通过但灵敏度分析显示解对假设高度敏感（首次建模验证边际信号）； 题目原文对问题 N 出现"比较不同方法""讨论优缺点"等字样； 剩余时间预算充足（用户告知或 pipeline.json 有截止日期字段时距今 > 48h）。 命中则继续 Step 1；未命中，直接按普通单模型流程处理问题 N（见路径 A/B 原有步骤）。 六条触发源检查时机不互斥—— 最早在 problem_analysis 阶段（Checkpoint① 之后） 就该做一次"题目复杂度初判" ，不要等到 data_preprocessing/文献调研阶段才第一次 评估；后续阶段（文献调研、首次验证）浮现的证据依然可以补触发，不要因为 problem_analysis 时判断"暂不需要"就关闭这个窗口。 "题目复杂度初判"怎么判断 ：不是凭感觉，看题目本身是否呈现以下任一客观特征—— 要求"设计方案""提出并论证策略"而非单一确定性计算；在多个目标间权衡（覆盖率 vs 成本 vs 可行性这类）；结果对不确定量的建模方式选择很敏感；该类问题存在业界公认 的至少两种不同技术路线（如精确算法 vs 启发式算法）。命中越早发现越好，因为 Los Alamos 是叠加层，早触发不影响后续正常推进，晚触发则要接受已经做掉的工作 无法回溯利用范式比较的收益。 贯穿 Step 3~9 的一条规则：决策前先查树，不要只靠自己的叙述记忆判断。 hypothesis_tree.py 不是只写不读的审计日志——是否要继续展开、要不要合并/回溯、 决赛圈还剩哪些候选没决出胜负，这类判断点动手前先跑一次： python scripts/los_alamos/hypothesis_tree.py status --problem-n {N} 拿到当前物化视图（前沿 / 决赛圈 / 已剪枝归档）的真实状态再决定下一步，而不是 凭记忆猜"现在应该还有哪几个分支在跑"——分支数量一多、跨越多轮 build/verify/ 红队之后，叙述记忆很容易跟实际状态脱节， status 是唯一权威来源。 Step 1 — Alsos 冷启动普查（spawn 一次性子 Agent） Agent(description="问题N Alsos 文献普查", prompt=<Alsos 普查 Prompt 模板>) Alsos 普查 Prompt 模板： 你是问题 {N} 的 Alsos 情报组，任务是做一次结构化文献普查，不建模、不下结论。 1. 用抽象化关键词（不要直接粘贴题目原文，遵守 SOP S3）检索该题型的已有解法， 目标 ≥8 篇跨越不同范式的文献。 2. **对照 `LOS_ALAMOS_METHOD_CATALOG.md` 自查**：题目所属的大类（优化/预测/ 评价/仿真/分类/网络）里，清单上列出但纯文献检索没搜到的候选范式，针对性补 一轮检索——这一步是为了防止文献普查只找到"最常见"的范式、漏掉同样适用但 不那么显眼的技术路线，不是要凑齐清单上所有条目。 3. 对识别出的每个建模范式，写一条结构化记录（paradigm_id 格式 PM-P{N}-序号）： name / typical_assumptions / strengths / weaknesses / applicable_when / citations / maps_to_division（T=解析理论 / E=数值仿真 / O=元启发式 / CM=数据驱动， 若都不像就留空，不必强行归类）。 4. 把结构化列表写入 CUMCM_Workspace/memory/paradigm_pool_{N}.json（JSON 数组）， 人类可读版写入 memory/literature_survey_{N}.md；**每篇引用同时用 `scripts/cite_check.py register --problem-n {N} ...`（见 SOP §15）登记进共享 引用池，不要只写进 JSON 就算了——`quality_gate.py lit` 认的是登记+核验过的 citations.bib，不是 paradigm_pool_{N}.json 里的自由文本**。 5. 完成后输出一行：[Alsos-P{N}] ✓ 普查完成，发现 {paradigm_count} 种范式， 分歧点：<一句话>。 Step 2 — 冻结范围锚点与评分标准 mkdir -p CUMCM_Workspace/state cat > CUMCM_Workspace/state/scope_anchor_{N}.md << 'EOF' # 问题 {N} 范围锚点（冻结于 Los Alamos 探索开始时，非 Checkpoint LA 不得修改） ## 这个子问题到底在问什么 <一段话复述题目对问题 N 的要求> ## 已确认的假设（探索开始前） <列出 problem_analysis 阶段已写入 thought_process.md 的假设> EOF 同时确定决赛圈的量化评分标准（Track 1 会用到的 criteria 清单，例如 鲁棒性/残差/参数个数/求解耗时），先写死，不得在裁决快出结果时现改。 Step 3 — 展开第一层分支（不 spawn Agent，Director 自己内联判断 + 记账） 参考 paradigm_pool_{N}.json ，选真有文献支持、互不相同的范式登记为节点（不要求 T/E/O/CM 四个全上）—— 分支数量不是固定 2~3 个，是时间预算的函数 ：时间紧迫 （或已判定 Skunk Works）就收敛到 2 个最有希望的；时间预算充足（同 §9.2/§13 用 的 48h 默认阈值）应该尽量多展开到 3~4 个，覆盖不同大类（比如优化类 + 预测类/ 评价类各一个），而不是止步于最先想到的两个—— LOS_ALAMOS_METHOD_CATALOG.md 就是为了让这一步有更宽的候选池，不要因为"想到两个就够用了"而提前收窄。 python scripts/los_alamos/hypothesis_tree.py expand --problem-n {N} \