realseaberry AutoMCM-Pro：Codex CLI 绑定
这是 AutoMCM-Pro 协议在 OpenAI Codex CLI 上的运行时绑定（Binding），不是另一套
独立协议。 行为规范权威来源仍是仓库根目录的 AutoMCM_SOP.md（工具无关，原样
复用）；可选探索层见 LOS_ALAMOS_DESIGN.md。Claude Code 绑定是
.claude/skills/auto-mcm/SKILL.md，DeepSeek Harness 绑定是
.dsh/skills/auto-mcm/SKILL.md——三份文件描述同一套流程，只是把"怎么调用工具"
换成各自 runtime 的实际工具，流程逻辑、Checkpoint 规则、质量门控、Prompt 内容
不应该在几份文件间产生分歧。完整背景见
CODEX_INTEGRATION.md。
【触发时的依赖安装询问】
每个新的 Codex 会话首次触发本 Skill 时，先询问用户是否安装核心 Python 建模依赖
（pdfplumber、scipy、numpy、matplotlib、pandas、openpyxl），以及是否准备可选的
LeanGate / Lean 4。不得预扫描或静默安装；用户同意后才调用
bash install.sh --with-python-deps 和/或 --with-lean。拒绝后同一会话不重复询问。
非交互执行无法取得回答时，显示问题并暂停，不得把沉默当作同意。
【与其他 runtime 最大的差异：Codex 只给模型一个"代码模式"工具，实测确认】
这不是源码调研的推测，是实跑一次任务、解压
~/.codex/sessions/**/rollout-*.jsonl 核对过的：Codex 模型端 function-calling
只看得到一个叫 exec 的顶层工具，参数是一段 JavaScript 代码；
tools.exec_command({cmd, workdir, ...}) 是这段 JS 代码内部能调用的异步
函数，不是模型能单独调用的顶层工具。也就是说，Bash/Read（文本）在 Codex
上都是：模型写一段 JS，里面调用 tools.exec_command({cmd: "..."})，再用
text(r.output) 把结果吐出来——不是直接的 {"tool": "exec_command", "cmd": "..."} 这种扁平 function call。
实测时甚至连读 SKILL.md 本身也是这样做的：模型用
tools.exec_command({cmd: "sed -n '1,240p' .agents/skills/auto-mcm/SKILL.md"})
直接读档，没有专门的 skill 载入工具——这点跟 opencode/dsh 都不一样（它们有
独立的 skill 工具）。
这件事对 AutoMCM-Pro 反而是天然契合——本项目的流水线绝大部分工作本来就是
"用 bash 调 Python 脚本"，很少直接依赖结构化文件工具，翻译成 Codex 的
JS-in-exec 模式没有额外损失。
【工具映射表】
| Claude Code | Codex 工具 | 说明 |
|---|---|---|
Bash |
顶层工具 exec（参数是一段 JS），内部调 tools.exec_command({cmd,...}) |
✅ 实测确认（喚醒協議 Step 1 跑通）。万能工具：跑 Python 脚本、cat 读文件、rg/grep/find 搜索、curl 抓网页，本文件后续所有"执行 python scripts/..."都是这个模式，不是直接的扁平 function call |
Read |
同上，exec 里的 JS 调 tools.exec_command({cmd: "cat ..."}) |
✅ 实测确认（读 SKILL.md 本身就是这么做的） |
Read（图片） |
view_image |
专用图片查看工具，读图表/PDF 截图用它，不要用 cat |
Write/Edit |
apply_patch |
结构化 diff 应用工具，写/改模型代码、.tex 文件优先用它（比 shell heredoc 更可靠地保留缩进/编码） |
Glob/Grep |
exec_command 里 rg/find |
没有专用搜索工具 |
TodoWrite |
update_plan |
语义对应 |
AskUserQuestion |
请求用户输入的工具（模块 request_user_input，确切工具名未逐字核对，见下方核验清单） |
语义对应 |
Agent(description, prompt) |
多代理协同工具家族（模块 multi_agents/multi_agents_v2，确切工具名未逐字核对） |
Codex 有原生多代理能力，但这次没有把确切的工具调用 schema 读完，接入前务必先跑一个最小测试确认参数格式 |
WebSearch/WebFetch |
没有确认到的第一方工具 | 见下方【已知能力缺口】 |
上表里 exec_command/apply_patch/view_image/update_plan 四个工具名是从
codex-rs/core/src/tools/handlers/ 源码里的 ToolName::plain(...) 字面量直接
核对过的（不是猜的）；request_user_input、multi_agents/multi_agents_v2 是
从模块/文件命名推断，没有找到对应的字符串字面量，接入前务必先用一个最简单的
任务实测一次，确认真实暴露给模型的工具名。
【已知能力缺口：网络搜索】
Codex 核心代码里没找到独立的 web_search/web_fetch 工具（dsh/opencode 都有，
Codex 没有内置）。看到的只有 MCP（Model Context Protocol）相关模块，猜测 Codex
把网络检索能力交给用户自行配置的 MCP server，而不是内置。这意味着：
AutoMCM_SOP.md里"文献调研至少 5 篇"这条硬性要求，在 Codex 上落地前必须先 确认有可用的网络检索能力（配置一个 MCP 网络搜索 server，或者退化成exec_command里curl调用一个你自己有权限的搜索 API）；- 若确认没有任何网络检索能力，不要静默跳过文献调研——按
AutoMCM_SOP.md第 7 节"禁止静默跳过验证失败"的同一精神，在 Checkpoint①里如实告知用户"当前 环境无网络检索工具，本阶段建模假设未经文献交叉验证"，让人类决定要不要补充 MCP 配置或人工提供文献。 - 同样的缺口也影响
AutoMCM_SOP.md§18"画图前先查领域惯例"——判断某类问题的 常规可视化形式本质上也是一次网络检索。不要因为查不到就直接静默退化成随手 选个图表类型：先按上面同一套办法确认有没有可用的检索能力；确实没有的话， 在thought_process.md里如实记录"当前环境无网络检索工具，图表形式选择依据 建模者常识判断、未经领域惯例检索确认"，而不是不留痕迹地直接画图。
【运行方式】（Codex 特有）
codex # 交互式
codex exec "task" # 单次任务模式，类似 claude --print / dsh --profile headless
Skill 发现路径是 .agents/skills/auto-mcm/SKILL.md（仓库根向上找 .git，Codex
官方文档确认），显式调用用 $auto-mcm，或让模型按 description 隐式匹配。
【流水线执行】
阶段定义、状态机、Checkpoint 编号（①~⑤）、质量门控（quality_gate.py）、
Los Alamos 探索层（路径 C）、图表风格规范（plot_style.py）、Andon 紧急停止
（pipeline_manager.py andon-pull/andon-clear/andon-status）、Go/No-Go 发射前检查
（quality_gate.py launch-check，final_compile 前强制）、Skunk Works 轻量模式
（pipeline_manager.py init --skunk-works）、Track2 的 RAND Delphi 多轮收敛
（adjudicate.py delphi-summary）、Kaizen 质量打磨循环
（pipeline_manager.py kaizen-assess/kaizen-round-start/kaizen-status）、工作日志
（worklog.py append/tail，单文件简体中文完整记录，唤醒协议 Step 0）、文献引用
真实性核验+共享池（cite_check.py register/verify/list/export-bibitems）、写作
风格打磨（style_check.py scan，latex_draft 固有规范非可选 addon）、官方格式
合规（quality_gate.py anon-check、ai_usage_doc.py generate/cite-format/ mcm-entry、compile_pdf.py 编译后页数提醒，AutoMCM_SOP.md §17）、画图前先查
领域惯例（AutoMCM_SOP.md §18）全部内容
与 Claude Code 版本一致，见
.claude/skills/auto-mcm/SKILL.md 对应小节（标题相同），
按上方【工具映射表】替换调用方式：
- 子 Agent 调用：原文里每个
Agent(description=..., prompt=<模板>)，改为 Codex 的多代理工具调用，prompt字段内容完全不变（先按【已知能力缺口】小节的 提醒实测确认参数格式，再套用到 Los Alamos 路径 C 的四套 Prompt 模板） - 人类确认环节：
ask_user_question换成 Codex 的用户输入请求工具 - 文件读写：模型代码/验证脚本/LaTeX 文件优先用
apply_patch，图表结果查看用view_image scripts/*.py系列命令（pipeline_manager.py/quality_gate.py/los_alamos/*.py/plot_style.py）完全不变，全部通过exec_command调用
【安全规程】
AutoMCM_SOP.md 的 S1~S5 原样适用。S3（外部服务调用告知）在 Codex 上尤其重要——
既然网络检索要靠用户自配的 MCP server，调用前更要做好关键词抽象化，不要把题目
原文整段发给一个你不确定信任边界的外部 MCP server。
【LeanGate：可选 Lean 形式化验证门禁】
LeanGate 默认关闭；行为规范见 AutoMCM_SOP.md §19。Codex 通过 exec 内的
tools.exec_command 调用共享命令：
python scripts/leangate.py doctor
python scripts/leangate.py --workspace CUMCM_Workspace init --policy selected
python scripts/leangate.py --workspace CUMCM_Workspace status --problem-n 1
python scripts/leangate.py --workspace CUMCM_Workspace verify --problem-n 1
python scripts/quality_gate.py formal --problem-n 1
LeanGate 启用后，离开 problem_analysis 前必须逐问题登记适用性并执行
leangate.py seal-assessment；安全边界、整数可行性、守恒、不变量、递推、收敛、
求解器证书或决策关键结论必须用 --risk-category 标注，自动成为 mandatory。
不得直接编辑 claims.json 或报告来制造 PASS。任何输入变化后重新执行语义审查、冻结
与验证；Lean FAIL、UNKNOWN、STALE 或 Python FAIL 都是 NO-GO。
LeanGate 启用后的 model_N_verify 推进必须传入工作区内真实验证脚本：
pipeline_manager.py advance model_N_verify --verify-script CUMCM_Workspace/src/verifications/verify_*.py。
required claim 还必须使用人类文件中的 [APPROVED LeanGate ...] 与 [REQUIRED LeanGate ...] 标记。