Codex接入影响：本轮综合判断的补充依据
本次核对为只读分析，没有改变产品代码、运行配置或重跑付费API任务。分清三层：代码确实设置了什么、本轮实际发生了什么、这些事实足以解释什么。
1. 测试基线中存在的适配
采用 git show cb590ce:<path> 读取测试提交，避免用后来本地工作树推断旧行为。完整SHA为 cb590ce35686cb1980e3c89a7d68bd0cfbeb825a。
• packages/codeflowmu-runtime/src/registry/CodexCliAdapter.ts：buildCodexCliConfig 为自定义provider生成 wire_api="responses"、model_reasoning_summary="none"、model_supports_reasoning_summaries=false；buildCodexAppServerArgs 的省略工具命名空间分支另关闭原生工具暴露，调用位置由 useArkBridge 决定。团队协作继续走FCoP治理工具，不等于整个团队功能被关闭。
• packages/codeflowmu-runtime/src/registry/ArkResponsesBridge.ts：按Ark支持字段规范化请求、工具和历史消息。这个桥接只可作为豆包路径证据，不能声称Kimi、千问、DeepSeek都经过它。
• packages/codeflowmu-runtime/src/session/CodexFcopToolBridge.ts：提供 action=list/call 形式的治理工具入口，按真实工具清单及角色许可转发。资源目录可读不等于工具入口已经暴露。
OpenAI配置参考说明：推理摘要设置可关闭摘要；是否发送推理元数据与推理强度另列。自定义provider配置说明连接由URL、协议和认证等配置决定。这些官方文档用于解释概念，不将当前文档当成历史会话故障的直接证据。
2. 能确认的影响与尚未确认的原因
| 观察 | 支持的判断 | 不能据此断言 |
|---|---|---|
| 自定义provider关闭Codex推理摘要 | 摘要呈现条件与订阅Codex不同 | 模型停止思考；模型无法输出公开进度 |
| 千问前期动作多、后期解释多 | 过程透明度不连续，用户难以及时监督与止损 | 前期故意隐藏；前期确有文字被吞掉 |
| Kimi的MCP就绪异常、响应流断开、8个PM失败会话 | 本轮接入及恢复链没有提供可交付的运行 | 根因已精确落在OpenAI、Moonshot或某一个适配函数 |
| 豆包和DeepSeek经Codex完成团队链 | 该框架并非普遍阻止国产模型协作 | 两家已不存在兼容损耗；所有国产模型都可稳定工作 |
| 千问OPS报告提交返回Transport closed | 该次正式提交失败，正文存在不等于落账 | 所有迟延都来自Codex；PM后续处置没有问题 |
用户指出的是前后不一，并非单纯文字少。固定配置关闭摘要不足以单独解释同一轮不同时段的行为差异。应按前期/后期时间窗，匹配公开输出、SDK事件与面板呈现。前期没有提供及时目标、结果、阻塞和下一步，就构成可监督性缺陷；有无故意的动机不在当前证据可判范围。
3. 对综合评分的影响
分数保持Codex 88、Cursor 87、DeepSeek 75、豆包66、千问40、Kimi18。其对象始终是六次集成运行：用户实际收到的交付、等待和可观察程度。本次增加的是解释边界，不把原分数包装成纯模型能力分。
可观察性低分不能直接归到供应商故意隐藏。Kimi的18分也不能当作其原生能力只有18分。若要分离模型能力与框架影响，需要同模型、同任务、同工具语义的执行器对照；当前六轮不支持接入损耗百分比。
4. 建议的配对复测
1. 固定模型ID、推理配置、提示与角色合同、文件快照、工具schema、预算及初始会话；逐角色核对，不仅核对PM。
2. A组走当前Codex路径；B组走另一已验证执行器或供应商原生工具执行路径。不能用普通网页聊天对照多Agent正式任务。
3. 两组先完成相同的列工具、读文件、调用带参数工具、写报告、恢复会话探针；通过后再做原始团队巡检。
4. 分别记录首个有效派单、工具失败与重试、报告落账、公开进度间隔、人工介入和正常交付耗时。顺序轮换，至少各做三次；这是后续建议，尚未执行。
5. 若A失败B成功，首先定位差异链路；若两组都偏离，检查模型理解与提示合同；若两组都因相同FCoP门禁失败，检查仪器。仍须具体证据才能确定责任，不能只凭对照结果命名根因。