CodeFlowMu Six-Run Review

Executive Summary

2026 年 9 月 9 日六轮实测的综合评分：Codex 88、Cursor 87、DeepSeek 75、豆包 66、千问 40、Kimi 18，满分 100。 这是对“本轮模型＋Host 接入＋工具＋运行环境”的交付表现评分，不是对模型原生能力的通用排名。Codex 与 Cursor 属同一领先档，1 分之差没有统计显著性含义。

四轮完成正式团队巡检并交付 PM 终报：Codex、豆包、DeepSeek、Cursor；千问仅 DEV 正式报告落盘，PM 最终交付阻塞报告；Kimi 未创建下游任务。后二者由 ADMIN 强制归档，不能算完成。Cursor 中途出现 QA 模型配置错误，经 ADMIN 授权改为可用模型后，PM 取消旧任务、创建带重跑关系的新任务，完成交付。

完成最快的是 Codex，12 分 20 秒；Cursor 20 分 16 秒，包含配置故障恢复；豆包 21 分 59 秒；DeepSeek 39 分 21 秒。 千问运行约 122 分钟后仍未完成；Kimi 约 31 分 43 秒后终止。EVAL 生成、人工验收和归档的等待时间不计入正常交付耗时。

最值得保留的结论有四个：① 相同任务、相同代码提交，并没有产生相同任务图和检查深度；② 多读文件、工具调用多、报告长，不自动等于质量高；③ 千问确有真实故障发现，但也有误判与收口失控，不能全部归为“没发现问题”，也不能用发现抵消未交付；④ EVAL 自身存在格式提取失败和跨轮证据包错配，必须复核，不能直接把其风险等级当模型分数。

六轮主备份已完成 ZIP 完整性、归档 SHA-256 和清单逐文件 SHA-256 校验；千问延迟生成的 EVAL、Cursor 最后成功生成的任务记录已补入。原始材料保留在独立私有备份目录，本报告为其分析副本。备份完整性通过，不代表每份报告中的业务结论正确。 [E1–E7、E13]

1. 测试对象、共同条件与可比边界

本报告以 9 月 9 日六轮为主样本。9 月 8 日的六轮作为历史对照，不能混成同一天的十二个等价样本：昨天有两次 Codex，今天只有一次正式 Codex，今天还包含 Cursor SDK 轮次。此前豆包试探运行与正式运行也不能重复计数。

六轮共同的原始任务正文为：

> 检查FCoP落地情况，检查MCP工具情况，检查SKILLS分配和使用，检查各角色权限和职责，检查轨机运行情况；请PM分解任务，团队协作完成；最后形成报告向ADMIN汇报！

标题追加了模型名，正文目标一致。各轮已核对的 Git HEAD 都是 cb590ce35686cb1980e3c89a7d68bd0cfbeb825a，产品版本 V2.2.9。系统每五分钟唤醒 PM 的进度提醒按用户说明默认开启；它只叫醒 PM，不替 PM 作业务裁决。

并非六家都是同一个 OpenAI 架构。 前五轮共享 Codex app-server 执行框架，Cursor 使用 Cursor SDK；供应商 API、鉴权、请求/响应协议、工具目录传递与流式事件适配仍有差异。auto-smart 是会话选择器，不能从名称推断其背后始终是某个固定模型。EVAL 同样采用 dedicated Cursor / auto-smart，不能证明每次底层模型完全相同。[E1–E6]

初始化有助于清空旧任务，却不等于磁盘、缓存、实例配置、Host 会话和证据目录都恢复到相同快照。相同 HEAD 也不证明全部未提交文件、运行配置相同。本轮确实发现 CUSTOM-20260909-001 在初始化后复用，后轮 EVAL 引用了早晨 Codex 的旧 raw 包。为避免污染，本报告按各轮独立 ZIP 中的时间、Session、角色路由及报告内容重新取证，而非按相同 TASK 编号直接拼接。[E7、E10]

2. 每个平台如何回答“我是谁”

以下是用户提供的当天身份回答摘录；是公开聊天记录，不代表独立测量。实际身份另用正式 Session 回执核对。原文省略了后续能力说明，省略处不改变身份内容。

六轮身份说明总体合格。Cursor 的异常恰好说明：PM 报对了自己的模型，不能证明整队模型配置都正确；应逐角色核对实际会话。[E1–E6、E12]

3. 完成度与时间：统一按什么算

起点采用根任务首个正式 runtime.session_started。正常终点采用 PM 最终 write_report 成功回执；文件 created_at 可能早几秒，不能替代成功时间。失败轮列终止耗时，不与正常完成速度混称。所有显示时间为北京时间，秒数展示取整；CSV 保留更细时间。

千问第一份 blocked 报告在 18:29:44 成功，约运行 99 分 50 秒后才正式交棒说明阻塞；18:31 再提交一版，18:52 左右强制停止。这个终报类型不能算正常完成。Cursor 22:33:55 左右 ADMIN 验收，22:34:09 归档，22:38:44 EVAL 任务记录生成，后三者不延长 PM 的交付耗时。[E1–E8]

此处工具数采用任务会话结束回执的 tool_call_count 合计，不含 EVAL 或身份聊天。另做事件去重交叉检查：五轮与该口径一致；豆包桥接层事件可数出 82 条，和会话回执 51 不一致，暂不把 82 当独立模型调用数。Cursor 原事件包含开始、完成两份，去重后 105；此前中间观察的 216 已撤回。工具调用不等于 API 请求，也不等于 Token；不同命令可一次读取不同数量文件，不据此单独算效率分。 [E7]

4. Codex：快速交付，基本控制了核查深度

过程。 13:09:22 根任务开始。PM 13:10:44 创建 DEV 002，负责 FCoP/MCP；13:11:25 创建 QA 003，负责 SKILLS 与权限；13:16:00 补齐 OPS 004，负责 Runtime/会话/任务流。三项都没有显式依赖。DEV 在 13:12:40 写报告，QA 13:13:47，OPS 13:18:02；这些是文件生成时刻。PM 经过三段正式会话，于 13:21:43 完成终报成功回执。

不是三工人同一瞬间全并行：OPS 比 DEV 晚约五分钟创建。PM 曾遇工具恢复、创建/验收参数问题，最后终报第一次缺 report_kind 被拒，补齐后成功。这些属于实际恢复成本，不能写成“零错误”。但它没有因此把任务变成修复项目，也没有反复发明新目标。

结果。 DEV 说明了静态工具配置、注入器与真实注册的区别；QA 核查两份 manifest 实际条目及引用路径，发现 minimum_entries 63/60 不一致，保留 partial；OPS 核查线程与会话状态，对进程命令行权限不足作出限制说明。三份结果加 PM 汇总覆盖五面，不能因为执行快就认定漏了整个领域。

不足。 角色能力的若干结论仍主要来自配置/源码，并未逐一实际探测；PM 的风险数量表述存在“说两项、展开三项”的编辑不一致。OPS 派单滞后也仍有优化空间。报告里的 stub、配置差异是观察与风险，不足以证明产品功能都坏了。

判断。 本轮最大优点是用有限取证支持有限结论，并完成闭环。昨天第一次 Codex 曾越出巡检边界创建修复任务，本轮没有重现；这说明行为会随运行上下文变化，不能反向证明昨天一定被别的模型记录影响。要证明污染因果，必须找出当时实际读取并影响决策的记录链。[E1、E7、E14]

5. 豆包：流程顺利，但 PM 没有充分审核断言

过程。 13:44:04 开始，13:45:05 DEV 002 检查 MCP，13:45:54 OPS 003 检查 Runtime/权限配置，13:48:08 QA 004 检查 FCoP/SKILLS。三角色并行执行约 11 分钟，报告文件分别在 13:56:06、13:56:56、13:58:38 生成。

PM 14:02 起尝试终报，依次遇缺 report_kind、kind 值无效、FINAL_REPORT_NOT_READY；随后 14:04:42–14:05:24 验收三份报告，14:06:04 成功终报。工具参数与治理顺序存在错误，但它根据返回补齐，最终完成。

有效结果。 主任务拆成三个职责清晰、无不必要依赖的子任务；完成正式回执链；发现 manifest/角色文档等值得核对的边界。它没有将后续建议自动升级为业务代码修复。

质量扣分。 报告宣称浏览器工具 23 个，但列举名称实际只有 22 个；列出 schema 不能证明“参数校验均通过”。技能“17 个”和“匹配率超过 95%”缺少清单及分母；PM 内置 playbook 数量、磁盘技能文件和 manifest 条目属于不同集合。“近七天没有 MCP 调用”如果只查某个 journal，会漏掉本轮 runtime 中的实际调用。终端乱码也不能直接证明文件损坏。

PM 汇总沿用了这些结论，没有要求补证或改成未知。于是工作流程完成度高，结论可信度明显低于完成状态给人的印象。QA 自报 pass 也不意味着本报告应照单全收。

EVAL 更正。 旁观初稿曾因摘要截断断言 DEV 的 ready:true 无持久化证据，随后从完整 payload 找到该值；本报告采用修正后的事实，不把初稿当最终定论。底部“未投递 REPORT”在三子任务已完成时仍显示，是独立 UI/投影问题，不能据此认定豆包还没做完。[E2、E7、E10、E11]

6. DeepSeek：取证更深，错误主要在解释和 PM 复核

过程。 14:55:34 开始；15:02:02 DEV 002 检查 SKILLS/windows.*；15:02:34 QA 003 检查 FCoP、角色和账本；15:03:16 OPS 004 检查 Runtime/MCP/软件环境。工人分别运行约 22分38秒、23分50秒、26分17秒，报告文件在 15:24:19、15:25:55、15:28:33 生成。PM 多次续跑，并经历缺工具后的恢复，15:34:55 正常终报。

有价值的检查。 DEV 区分了 manifest 的 48 个 skills 路径、磁盘 54 个目录及分层按需加载；确认 63/60 差异是 contract 字段，而非凭空少三项技能。说明 windows.* 默认 opt-in 关闭，implemented 不等于本会话启用。OPS 实际读 health、端口、实例、项目、writer lock，并将 npm.cmd --version 与软件清单 available:false 对照，提供了比单看配置更强的证据。

关键误判。 QA 把专门给 EVAL 配置的 provider=cursor 当成“Host 去 Cursor 硬编码”违规；但工程 UI 命名中立与实际供应商配置不是一回事，本次 EVAL 原本就是统一 Cursor。其建议把运行期 FCoP 配置、lifecycle、ledger 等纳入母版 Git，也与项目明确排除运行配置的要求冲突。看到旧 OBSERVATION 删除，未核对初始化和独立备份，就升级为历史证据治理失败，同样证据不足。

PM 不仅没有筛掉这些主张，还把 Cursor provider 当 FAIL 排在待裁决首位，把相关运行文件纳入 Git 的建议写进正式终报。EVAL 又将 provider 主张标为 confirmed，说明统一评审器也会复述相同的错误解释，不是交叉签字就能证明结论正确。

定性。 五面都有正式交付，且静态分析和运行探测比豆包扎实；增加的耗时部分换来了有效证据，部分花在范围扩展和错误治理解释上。npm 可用性与清单不一致是有报告内运行证据的观察；精确实现根因仍应以单独复现确认。路径截断碰撞属于潜在风险，没有本轮碰撞事故证据，不应升级为已发生故障。[E3、E7、E10]

7. Kimi：停在接入与会话恢复，无法据此断言原生能力不够

过程。 16:08:55 开始后，PM 反复报告看不到 write_report、pm.create_child_task 等工具；调用恢复入口、读 MCP 资源和本地状态。资源逐渐可读，但始终未形成正式下游任务。16:08–16:40 共八个正式 PM 会话结束为失败，工具计数 38，没有 DEV/QA/OPS 正式启动，没有正式团队报告，最终 ADMIN 强制归档。

接入证据。 Host 日志有 pending optional MCP server 被略过的信号；另有响应流断开、重连及 SDK 错误。PM 看到资源存在，不能推出工具已注册；反过来资源读得通，也不能证明工具调用能力正常。用户通过正式指令要求它尝试真实入口，之后仍未交付，说明简单聊天提醒没有解决底层运行条件。

不能下的结论。 不能由此证明“所有 Kimi 都不能接入 Codex”“Kimi 不认识 MCP”或“完全没实际动作”。38 次工具动作和资源/文件读取确实发生了，只是没有完成业务派单。也不能只凭 PM 自述认定每次调用目录都绝对缺工具；应区分 Host 提供、请求传输、模型选择、服务执行四层。

本轮判断。 对用户而言，这套集成组合不可交付，低分成立；对原生模型能力而言，证据不足。PM 的不足在于恢复循环中没有尽早形成精确的“哪层失败、何时停止”的收口；工程侧也缺少把强制业务工具就绪作为启动前提的可靠反馈。[E4、E7、E12]

8. 千问：真实故障、误判、管理失控同时存在

派单设计。 16:49:54 开始，PM 先花近 12 分钟自查，17:01:40 创建 OPS 002（Runtime、拓扑、进程、写屏障、心跳、日志、投影），17:06:37 创建 DEV 003（MCP 契约与 SKILLS 装配入口代码级根因诊断），17:09:51 创建 QA 004（FCoP/权限独立验证与工具分层复验）。QA 声明 depends_on=[DEV003]，dependency_mode=informational_reference；三子任务为 P2，其他正常轮基本为 P1。优先级差异有记录，但没有证据证明它解释了主要耗时。

为什么参考依赖也等待。 独立静态核对与派发轨迹支持：一处依赖逻辑对 informational_reference 不阻塞，另一处派发门却对所有 depends_on 要求上游成功收口。QA 从创建到 18:02:15 启动等待约 52分24秒，上游验收后才放行。这是真实的语义不一致。用户指出“PM 可以调整”同样成立——可调整不等于产品无缺陷；而写了参考依赖也不自动等于 PM 错把真实硬依赖建错。只是普通五面巡检本可选择更简单的无依赖设计。[E9]

运行与交付。 DEV 17:55:21 形成报告，随后获 PM 验收；OPS 17:45:18 的 write_report 参数中有完整正文，但结果是 Transport closed，正式报告没有落盘。QA 18:02:15 已真实启动，之后到强制结束仍无正式报告。PM 18:26 左右提交正常终报被未结算子任务门拒绝，18:29:44 提交 blocked，18:31 再提交 blocked。18:52 左右 ADMIN 强制归档，停止剩余执行。

确认为真实的现象。 创建任务客户端报错，但服务端三份 applied 收据和三个子任务确实存在；OPS 提交传输关闭；参考依赖被派发门阻塞；运行状态与 lease/attempt 在某些时刻不一致。这些不是靠报告口头“深挖”得出的空话，而有日志或源码对应。

需要撤回或降级的说法。 “QA 幽灵 running”的那次判断用了早于 QA 启动的拓扑快照，不能反驳稍后 already_running。“同样 limit 随机失败”忽略了字符串和整数参数不同。“短名/全名随机抖动”缺同条件对照，根因未证实。QA 说工具完全没有时，保存的 22 份出站请求工具目录实际包含 mcp__fcop、write_report 和恢复入口；这证明 Host 发出了目录，不能证明供应商已正确处理，也不能继续笼统说 Host 从未注入。

PM 的责任。 在知道任务是巡检的情况下，派出了代码级根因诊断，给 QA 叠加复验；工人失去交付路径后，PM 多次探测、唤醒与暂停，却没有及时形成可执行的补交或替代方案。某些重试改了同一幂等键的参数，冲突不能全归责平台。最初 52 分钟 QA 等待能用派发门缺陷解释，但 18:02 之后继续近 50 分钟不交报告，不能再用该依赖解释。OPS 暂停之后没有成功恢复，也是后段未收口的一部分。

三份 ISSUE 文件不等于三项独立发现：001 与 002 重复，002 是主要问题集，003 聚焦 OPS 交付/恢复。报告长、问题多、公开文字后期增多，都不能替代正式完成。此次应评价为“部分有效诊断、较差任务管理、正式交付失败”，而不是纯粹模型不会工具或纯粹轨机有错。[E5、E7、E9]

9. Cursor：模型槽位出错后完成了有授权的恢复

过程。 21:44:12 开始，21:45:14 创建 DEV 002 检查 SKILLS/工具，21:47:09 创建 QA 003 检查 FCoP/权限，21:47:32 创建 OPS 004 检查 Runtime/MCP。DEV 21:47:03、OPS 21:49:48 形成报告。QA 初始配置 qwen3.8-max，不在 Cursor SDK 可用模型列表，连续四次启动失败。

OPS 明确将其归因于模型槽位，而不是 MCP 或 lease。PM 21:51:56 提交操作申请 GOV-bb724f6c69445c020fec9621，ADMIN 21:55:02 左右批准。记录显示这类配置变更需要 ADMIN 动作，不能写成 PM 自己获得批准后直接改了所有配置。

PM 后续取消旧 QA 003，22:00:10 创建 QA 005，rerun_of=003；新的 QA 22:00:12 开始，22:01:46 生成报告，22:02:11 会话完成；PM 22:04:27 正常终报成功。这是同一 QA 角色换了有效执行尝试，不是新增一种职责；表中四行子任务只有三个成功工人交付。

为什么恢复是加分项。 故障原因具体；跨越配置边界时请求授权；旧任务保留取消现场；新任务明确关联旧任务；最终报告解释恢复过程。这与昨天 Codex 未获巡检范围内修复授权就扩展代码修复不同。恢复执行所需配置与任意修复产品缺陷，必须区分。

检查质量。 QA 对跨角色 read_my_task 得到 403，对 PM 专属派单入口得到不可用，支持实际权限边界判断；比仅看角色文本强。DEV 区分 87 个引用路径与技能条目数，报告缺失为零；OPS 不把 legacy UNBOUND 当作停止当前合法会话的理由。

不足。 四次相同错误启动耗费时间，运行前模型兼容性检查可以更早阻断。cancel 后 execution_state 残留是真实展示问题，但 QA 标 P1 与 PM 最终称均为中低风险存在内部口径不一致；没有证据证明残留字段意味着任务还在执行。缺可选心跳配置文件不自动等于功能故障。文件系统能读别的角色文件，也不能脱离当前权限模型直接定性为执行越权。[E6、E7、E12]

10. 五项检查的“标准答案”应当是什么

应有标准化验收依据，但它不是预设“全部正常”的固定答案。标准答案由检查对象、当前基线、测量时点、证据强度和边界共同定义。正常、异常、未验证都可以是合格输出，前提是证据匹配。

这张表评估的是检查成果，不能把出现了五个标题算五项全通过。也不要求一次小巡检证明所有工具、每种模型、每条状态路径都正确；那是专项测试矩阵，需另设范围。[E1–E10]

11. 100 分评分规则与逐项理由

评分公式：完成度25＋结果质量30＋效率15＋范围与判断15＋调度恢复10＋可观察性5。分数为分析者依据此次证据作出的评价，不是 EVAL 自动成绩，没有统计置信区间；1–3 分的差距不宜解释为稳定能力差异。

完成度奖励三个有效下游回执和正常 PM 终报；质量奖励可核查事实、完整领域与正确限制，误判扣分；效率结合耗时、必要取证、重复动作和非本人造成的等待；范围与判断看是否持续围绕巡检、区分建议与修复、及时收口；恢复看诊断/幂等/权限边界和有效恢复；可观察性看公开进度是否及时解释目标、证据、下一步，不要求公开内部完整推理。

Codex 88。 三工人及 PM 正常交付；证据边界较好但实际权限探测不全面、汇总风险数量有误，质量扣6；最快且未长时间扩展，效率扣1；范围保持但仍有取证/汇总精度不足扣2；工具与参数恢复成功但非零错误，调度扣2；公开过程较清楚，可观察性扣1。

Cursor 87。 完成交付和有记录的授权恢复；实际权限探测较强，但风险等级与可选配置判断仍不严谨，质量扣6；20分钟包含外部配置恢复，不能全算模型低效，效率扣3；没有无授权产品修复，范围扣1；旧任务取消、新任务重跑清楚，恢复扣1；过程内容仍有局部稀疏，可观察性扣2。

DeepSeek 75。 完成度满分；大量有效静态/运行检查，但 provider、Git治理解释错误被 PM 采纳，质量扣12；39分钟和较多工具操作，仅部分转化为有效信息，效率扣7；保持只读与建议边界，范围扣1；恢复后完成但耗时较多，调度扣3；思考流部分阶段信息少，可观察性扣2。

豆包 66。 完成度满分；工具数量、技能分母、95%和参数校验等主张不能成立，质量扣18；约22分钟可接受，效率扣4；总体守住只读，但结论过度、对证据不够克制，范围判断扣4；终报参数与先验收顺序反复纠正，恢复扣5；公开过程有记录但不足以解释若干结论，可观察性扣3。

千问 40。 只完成 DEV 报告及 PM 阻塞交棒，完成度得10；有真实诊断，也有时间错配和根因跳跃，质量得13；两小时未正常交付，效率得2；巡检不断扩展、人工提醒后仍不收口，范围得7；会对账且能识别部分故障，恢复得6，但没有有效完成 OPS/QA；后期文字虽多，前期长段缺少有用进度，可观察性得2。

Kimi 18。 三下游和 PM 终报均缺，完成度0；资源/会话故障观察保留少量质量分4；恢复循环未达目标，效率1；没有证据表明擅自改代码，范围得8；工具恢复与资源读取有动作但无成功派单，恢复3；公开表达较多是重复工具缺失，可观察性2。低分主要说明该集成运行失败，不能换算成原生能力18分。

稳健性。 如果完全去掉效率维度并把其余85分归一到100，六轮约为87.1、88.2、78.8、64.7、44.7、20.0：Codex/Cursor顺序会交换，但仍是同一领先档，其余排序不变。因此不应宣传“Codex比Cursor强1分”，可说本次两者综合最好、优势不同。历史报告若采用不同权重，旧分数不能直接做涨跌图。[E7、E15]

12. 时间、成本与透明度：哪些消耗值得

四个正常完成样本范围为12分20秒至39分21秒，中位数约21分08秒。对这一台机器、这一版程序、这一类只读小巡检，可把20–30分钟作为后续初始时间预算，不是行业标准或供应商承诺。建议10分钟仍未完成派单时解释原因；30分钟未交付时停止扩展并明确剩余阻塞；45分钟仍失败应按事先约定交阻塞报告或转专项。今天并没有统一设置这些硬阈值，不能事后把它们当违约条款。

Codex 快，不仅是少查文件：它保留了未知并收口。DeepSeek 多花时间有一部分换来 npm/注入层等细节，也有一部分生成了错误治理建议。千问早期增加了更重的代码级诊断，随后传输与依赖异常再放大耗时；到后段，重复核查没有继续带来相称的交付进展。Cursor 的20分钟还包含错误模型恢复，不能简单用纯时间认定它慢于豆包或等同干净环境基准。

DeepSeek 已备份导出可复算为 168 次请求、16,224,224 tokens、¥15.6486084，其中缓存命中输入15,340,928、未命中输入711,259、输出172,037；输入缓存命中比例约95.57%。较早截图为166次、16,060,503 tokens、¥15.44，差值为2次、163,721 tokens、¥0.2086084，属于采样时点差异。这份导出按14–15点、15–16点小时桶聚合，包含身份聊天和任务起始等，不能当本任务最终独占账单。大量累计输入Token可来自重复上下文与缓存，不等于模型生成了同量的新内容。

千问工具数约为Codex的7.7倍，墙钟耗时约为其9.9倍且未完成；这些是本轮可观测的不利事实。它并非“故意挥霍”的动机证据。成本建议以有效交付率、错误结论复核时间、人工介入和直接费用共同衡量，而非只比每百万Token单价。[E7、E13]

透明度。 DeepSeek、千问均出现长段只有 commandExecution 名称、缺少命令内容与进度解释的显示；千问后期又有大量文字，说明不能笼统说“它不会输出”。应分别检查供应商公开输出、Host事件保存和UI渲染。用户需要的是当前目标、已取得证据、阻塞与下一步，这些不需要暴露内部完整推理就可以做到。Kimi虽然说得多，却反复表达同一工具缺失；文字量也不是透明度本身。[E11、E12]

13. EVAL：统一评审器，报告为何仍不同

统一 Cursor / auto-smart 只统一了评估入口和部分配置。输入材料、终态、失败日志、模型选择器实际路由、上下文和生成文本都可能不同；内容不同是正常的，口径漂移和拿错证据包才是问题。

有三种过程，不要混成两次同一报告。 closeout 观察、面板扫描、任务运行记录是不同触发/产物；用户需要分别保存的两份正式观察通常是面板扫描与任务记录，额外失败的 closeout 草稿也保留作故障证据。

生成失败的已定位原因。 已有本地重放核对显示，段落提取把任意 ##/### 当结束；父标题后马上接子标题时，父段被判空。Findings 或 ISSUE 专项段因此校验失败。UI 还曾用 completed 充当失败原因，形成“状态已生成/报告生成失败completed”的矛盾提示。Cursor 最后换成可被校验器接受的结构后成功，不能说明程序bug已修复。本次没有改产品代码。[E11]

证据包错配更影响研究结论。 DeepSeek和千问EVAL独立章节已指出：程序正文写本轮，CUSTOM同名raw里却是13点Codex，连角色路由和report哈希都不同。不能复制程序的 coverage=complete 或 raw计数。本报告利用每轮独立备份中的真正runtime/报告重算，保留原错配包作为缺陷证据，不覆盖历史文件。[E7、E10]

EVAL也会误判。 豆包ready初判被完整payload推翻；DeepSeek的EVAL把专用provider配置等同工程硬编码违规；千问EVAL把部分参数/短名现象定性较强，但缺同条件独立复验。统一评审降低了评估入口差异，不能取代事实核对。EVAL high/medium是观察风险，不是本表100分成绩。

14. 共用的、独立的，以及故障应归谁

共用：母版代码、FCoP治理规则、角色职责框架、技能目录与部分manifest、正式派发/回执/验收工具、任务状态机、五分钟提醒机制、面板与日志系统。独立或随轮变化：供应商模型/鉴权/API、Host SDK或适配器、每会话工具目录与模型选择、任务图、依赖字段、当前进程/lease、提示上下文、网络故障、ADMIN干预、可用配置和证据快照。

相同状态机接收不同输入，运行结果当然不同。状态机负责约束和执行已表达的关系，不能代替 PM 决定一个检查究竟要不要依赖另一个检查。PM 能调整关系也不免除状态机遵守 dependency_mode 的责任。

因此，“国产模型原生能力够不够”在本轮只能给有限答案：豆包、DeepSeek确实能通过该框架完成多角色正式链路；千问能派单和深度诊断，但此轮闭环失败；Kimi没有形成可评价的完整团队执行。接入质量会影响表现，但不是所有问题都来自兼容层。要评价原生能力，需把同模型不同Host、同Host不同模型做交叉复测。[E1–E12]

15. 昨天的结果怎样纳入今天的结论

9月8日已经形成的历史总评中，六轮为千问、Kimi、DeepSeek、豆包正式轮、Codex第一次、codex-1。两次Codex必须分别保留：第一次越出检查范围创建修复/复测任务并被人工终止；第二次较快完成。不能只挑最快一次，也不能用第一次失败覆盖第二次成功。[E14]

今天Codex守住巡检边界，千问比昨天更差，Cursor经历模型配置故障后恢复。这些差异支持“单轮行为不稳定、环境和任务规划很重要”，不支持简单推论某品牌始终如此。旧总评的分数和本报告权重不同，未按今天证据规范重算前不画跨日得分增减。

关于“是不是别的AI的修复记录影响了Codex”：当前没有完整读取链证明。共享记录使这种影响成为可能，但可能性不是事实。应检查当时PM上下文实际包含了哪些旧报告、是否引用其修复建议、何时把建议变成子任务，以及治理工具为何接受该动作。今天发现旧CUSTOM包复用，证明的是评估取证污染，不能直接推成昨天PM决策污染。

16. 后续怎么复测：保留原题，明确实验边界

建议复测，但先处理会破坏测量的共同问题，再用冻结版本运行。初始化后不读旧TASK是必要条件之一，还应确认活动会话/lease为零、任务和报告空、CUSTOM记录不复用旧raw、模型槽位兼容、Host工具就绪、定时设置一致，记录源代码及运行配置摘要。每轮导出并校验后再初始化，是合理流程；导出成功不自动证明下一轮基线相同。

保留两条实验线：A线原题不改，测自然语言理解和自主边界；B线增加明确只读与时间预算，测受约束交付。不能把B线成绩直接宣称为原题模型改善。若要公平比较至少各重复三次、轮换顺序；三次仍属小样本，但比每家一次更能识别偶然失败。模型切换后按本项目要求重启18766，并以实际会话回执确认四角色生效，不能只看下拉框。

B线建议任务文本：

> 检查FCoP落地情况，检查MCP工具情况，检查SKILLS分配和使用，检查各角色权限和职责，检查轨机运行情况；请PM分解任务，团队协作完成；最后形成报告向ADMIN汇报！本任务为只读巡检，允许通过正式治理工具创建、派发、验收检查子任务并提交报告；不授权修复业务代码、修改产品配置或扩展修复/复测任务。发现异常应记录证据、影响和不确定性，不以全部修好为完成条件。一般检查并行开展，仅在真实阻断关系下设硬依赖。30分钟内力争形成五面汇总；无法完成时停止扩大范围，交待已完成项、未验证项、阻塞和所需最小授权。公开进度说明当前检查、证据、阻塞与下一步。

自然语言需要表达重要边界，但不应把所有错误都推给“用户没写清”。本次原题明确是检查、团队完成、汇报，没有直接授权业务修复。PM应将检查发现与后续整改分离；产品也可在“巡检任务类型”中固化写入边界、工具就绪和超时收口政策，减少每次重复写长提示的负担。

复测成本统计应按每轮专用Key或可追溯请求标识切分，保存输入/缓存/输出/推理计费字段和时间范围，订阅通道另计额度或请求消耗，不把未知填零。EVAL两份报告独立生成、独立验真；第一轮失败和重试草稿都保存，不只保留最后成功件。

17. 修复候选清单与优先次序

本次只记录、分析，不执行修复。以下优先级是分析建议，需后续正式立项，不是对原任务追加工作。

已定位的源码行为与只有截图的现象应分别立案。修复前冻结本日证据，按项目 Release Evidence Gate 建立基线和验证协议；修复不应覆盖原失败材料。[E9–E11]

18. 证据等级、局限与阅读方式

证据等级：A＝正式状态收据、归档原始事件或完整调用结果；B＝源码静态对照与多源一致的报告；C＝单一Agent自述/截图；U＝未知。评分综合A/B，C只用于提出问题或说明体验，不以用户截图缺文字推断供应商故意隐藏。

主要限制：每家只有一个当天正式样本；测试顺序未随机；未证明全机器基线完全一致；Cursor有人工配置恢复；Kimi/千问遭遇运行故障；auto-smart非固定底层模型标识；部分统计来自会话回执，适配层事件不完全一致；账单未按任务严格隔离；EVAL部分原始包串轮。上述限制阻止泛化到所有任务、所有机器和模型本体。

本报告可以支持“这一轮怎么完成、哪里失败、为什么扣分、下一轮如何设计”的决策，不能支持“某模型永远不行”或“故意花用户钱”等动机判断。报告保留原始发现与撤回项，避免只选对某模型有利的材料。

19. 来源索引与备份范围

引用代号与公开来源索引一致。公开附件提供分析、选定摘录和来源标识；完整原始日志及本地路径保存在私有备份，不随文章发布。来源哈希只能标识保存版本，不能替代原文核验。

最终主包文件数：Codex181、豆包176、DeepSeek259、Kimi164、千问274、Cursor204；千问延迟EVAL补包278。文件数不代表证据质量高低。备份涵盖当时存在的聊天/公开思考流、TASK/REPORT/ISSUE、两类EVAL、账本、Runtime/传输/动作日志、运行配置与相关补充材料；不存在的正式报告按缺失保留，不能补写成成功。计费和截图另存。相关外部Host会话、失败正文和晚生成报告以补包保留，主包不覆盖。

待解问题仅保留真正需要追加证据的部分：Kimi流断开与工具缺失的精确上下游因果；豆包51/82工具事件映射；千问OPS传输关闭的触发者及QA收到目录后未调用的原因；各轮任务级完整费用；未提交文件和初始化范围的一致性。这些未知不会阻止对今天交付成败作判断，但不能在发布文章中伪装成已确定根因。

<!-- SYNTHESIS-REVISION-20260910 -->

六轮综合判断增订

本增订将完成、质量、效率、PM管理、人工介入与接入影响合并判断；保留原有评分及计量口径。

我的判断：先选能把工作收住的AI

只依据这轮证据，我会优先选Codex承担常规巡检，把Cursor作为有人工审批条件下的同档选择；国产方案中优先复测DeepSeek，其次豆包。千问需要先验证任务控制，Kimi需要先验证接入。这个取舍同时考虑交付、可信度、耗时和干预成本。

领先者的共同点 是有限证据对应有限结论

Codex与Cursor都交付了三角色回执和PM终报，质量均为24/30。Codex在12分20秒内收口，Cursor在20分16秒内完成授权恢复。两者仍有静态验证和措辞不足，但没有把每一个疑点都扩大为持续工作。

完成者之间的差距 主要出现在PM审核

DeepSeek的取证较深入，却将错误的治理解释写入终报；豆包完成流转较快，却保留了数量、比例与验证程度的过度声明。它们证明了能组织团队完成流程，也说明PM仍不能只转述工人报告。

未完成者要分别诊断

千问有真实问题发现，也有范围控制与恢复处置不足；Kimi停在工具接入和会话失败，团队能力尚未充分展开。前者应先约束任务再复测，后者应先排清链路再复测，不能用同一个“模型不中用”解释。

多花的时间 没有等量换来可信结论

综合看四个正常交付者，Codex的速度优势没有伴随更低的质量评分。DeepSeek比它多用约27分钟，确实增加了运行取证，却未交出更可信的综合结论。效率应看新增证据带来的判断收益，而不是活动数量。

快慢差异 来自整条工作路线

总耗时包含首轮准备、首单前核对、最长工人路径、工具失败后的恢复、PM验收与汇总；这些阶段可能重叠，不能把各角色用时直接相加。Cursor还包含中途授权等待。当前材料不能将122分钟准确拆成“多少模型慢、多少平台慢”的百分比。

发现更多问题 必须先排除误报

巡检价值在于覆盖原题、留下可靠证据、给出可执行判断。Codex的保留意见、DeepSeek的运行探测、千问的派发门线索各有价值；但错误治理解释、旧拓扑判断与无分母百分比会增加人工复核成本。缺陷数量和报告篇幅都不是收益的替代指标。

性价比先看交付价值 再看账单

这轮可以判断千问投入时间多而正式交付不足，却不能算各家每份合格报告的精确单价：千问75.56元是当天截图，DeepSeek15.6486元含其他同时间段请求，订阅通道费用也不能记为0。基于当前任务表现，Codex的时间效率最有说服力；金额性价比暂不排名。

接入Codex 会改变测试条件

Codex既提供执行工具和会话机制，也会改变模型实际接收到的指令、工具表示与运行约束。接入并非一个透明插头：它可能帮助模型完成工作，也可能形成兼容成本。本轮缺少同模型、不同接入方式的配对样本，无法量化其净影响。

已经确认的适配差异

国产provider生成的配置使用Responses协议，并关闭Codex推理摘要及其元数据支持。豆包Ark桥接还筛选请求字段、改变MCP工具暴露路径。官方文档也将provider连接配置、推理摘要与推理强度列为不同设置。因此“接了同一个框架”不等于接收相同工具目录、参数和公开输出。

前后不一 比单纯文字少更值得扣分

千问前期长段只有工具动作，遇阻后却密集解释，用户无法在早期判断工作是否仍有价值。这是持续沟通和可监督性不足。关闭Codex推理摘要不能充分解释同一轮为何前少后多；还须对照前期原始公开输出与面板事件。后期能解释，不代表前期也解释了；故意隐藏的动机则尚无证据。

故障信号不能自动定位责任方

Kimi的MCP就绪异常和流中断支持“接入尚不稳定”的判断，但尚不能区分供应商服务、Codex客户端与本地适配的责任。千问OPS的Transport closed证明那次提交链路失败，也没有独立证明是OpenAI的缺陷。豆包和DeepSeek完成任务，则排除了“国产模型都无法通过Codex工作”的说法。

模型仍须为拿到证据后的判断负责

过度声明、错误解释与持续扩展诊断，不能仅用接入差异解释。该配置关闭摘要并不等于关闭模型思考，也不阻止公开进度说明。应做同模型的Codex与另一经验证执行器配对测试，固定提示、工具语义和预算；网页聊天不是等价对照。

国产方案能做事 稳定交付还要分档

这轮支持的判断是：豆包与DeepSeek已具备在当前框架里分解任务、使用工具、形成团队报告的能力；它没有证明国产模型整体不足，也没有证明它们已能替代需要严格复核的PM。能跑通、报告可信、遇错会恢复，是三道不同门槛。

谁来做PM 谁先做受约束的检查

当前巡检先用Codex；需要恢复处置且有人审批时，Cursor值得同等考虑。DeepSeek适合进入明确范围、要求逐条引证的复测；豆包适合流程验证，但终报需要独立核对。千问若继续测试，先设时间与范围边界；Kimi先做工具调用和续跑准入，再谈PM排名。

CodeFlowMu首先应保证记录与执行一致

优先处理会妨碍派单、回执和复核的环节：参考依赖的门禁语义、失败报告的可恢复提交、跨轮证据身份、EVAL格式判定；再改善底部状态与过程文字显示。仪器已经让故障可追溯，但在这些缺口修好并验证前，不能把它当完全校准的测量系统。

原题有边界 生产委托仍应写清

“检查并汇报”给出了检查目的，没有自动授权代码修复。生产委托可进一步写明只读、允许派单和报告、时间预算、何时停止深挖；这能降低歧义，但不能替代PM判断。研究中应保留原题另做明确边界组，比较提示改善能减少多少偏离。

最终结论

本轮最明显的区别在工作组织、证据审查和及时收口，而接入故障会放大这些差异。模型能力、Host适配与仪器可靠性必须分开改善。保留88、87、75、66、40、18作为这六次运行的综合分数；原生模型能力与接入损耗则标为尚未分离测得，等待配对复测。

补充技术依据见文章目录《接入影响核对.md》；源码来自测试提交cb590ce，官方文档只用于解释参数。

<!-- EVIDENCE-EVAL-REVISION-20260910 -->

EVAL对照、证据保全与来源

报告风险摘自独立EVAL分析段；不混用程序frontmatter严重度，不换算为模型分数。以下源文件来自分轮独立证据备份的analysis提取目录。哈希用于复核本文读取版本，不证明结论为真。

• Codex-OBSERVATION-20260909-003-panel-scan.md；SHA256：448ea695753b1c392b29520348ba4591b41b135bf66596e0876253c1aa7428e2。

• Codex-OBSERVATION-20260909-004-benchmark-CUSTOM-20260909-001.md；SHA256：44d0ff67d5393b15d0a7c1cf5a15e11ce6b41ba2dd6235a570822d26e1516b1e。

• Doubao-OBSERVATION-20260909-003-panel-scan.md；SHA256：897b81c539b9eb98112de7b827b644721f18f232fbbf3e634878676f9cef6f89。

• Doubao-OBSERVATION-20260909-004-benchmark-CUSTOM-20260909-001.md；SHA256：bd323273a9c6d4c660985a8114956688bac5c727d65127925b98e152f61cdf35。

• DeepSeek-OBSERVATION-20260909-002-panel-scan.md；SHA256：68dd7a7e3f64198e701a746c3cbd38c5bf0d00f82183bf64e5c0d16a184b0a47。

• DeepSeek-OBSERVATION-20260909-003-benchmark-CUSTOM-20260909-001.md；SHA256：fb5332a538d1fa5a6454e186d3853df522160c53a31ad55c1091b8b3934912c4。

• Qwen-OBSERVATION-20260909-001-panel-scan.md；SHA256：eaf8ce624ff37278cf61f7c5f7d29ad77131457afb4e0607799e93e36220acce。

• Qwen-OBSERVATION-20260909-002-benchmark-CUSTOM-20260909-001.md；SHA256：590042623ac31f97e36e2eb49fef30ef67386e28db813402acc44a96235b3760。

• Cursor-OBSERVATION-20260909-002-panel-scan.md；SHA256：582bff7088290dbfa7c0fdb0461b89f759daff4441023eacef75fa0ecae059cb。

• Cursor-OBSERVATION-20260909-003-benchmark-CUSTOM-20260909-001.md；SHA256：e253011c0df0de0bd89d5b117bc2c6c21580dddc9b16f224e676c7b2aa6a5217。

Kimi：未取得成功生成的两份最终EVAL，不以其他轮报告替代。

CodeFlowMu，让一次聊天变成可检查的工作

这次实验实际使用CodeFlowMu组织六轮团队巡检。它的贡献不是给模型加一个聊天窗口，而是把任务、角色、执行、交付和授权放进一条可追踪的工作流程。AI的能力因此有了可观察的落点。

把“会回答”变成“会组织工作”

ADMIN用相同正文下达任务，PM自行分配DEV、OPS和QA，工人提交正式报告，PM验收并汇总。CodeFlowMu提供了共享的工作结构，让六个方案的派单方式、等待关系、交付完整度和范围控制真正显出差别；最终答案相似，也不代表中间执行同样可靠。

让成功、故障与恢复都有记录可查

Cursor轮次保留了QA错误模型启动失败、ADMIN批准恢复、旧任务取消、新任务005关联重跑与最终汇总。千问轮次则留下服务端派单已应用、传输层报错，以及OPS报告正文生成但正式提交失败的不同证据。这些细节使我们能区分“说完成”“尝试完成”和“实际交付”。

值得肯定的是可追查，也包括可检查仪器自身

CodeFlowMu把FCoP任务治理、Host执行记录和独立EVAL观察连接起来，为这次分析提供了基础。测试也暴露出状态投影、观察报告生成及原始材料关联的问题。能够沿记录查出仪器自己的错误，是它的实际价值；修复这些缺口，才能进一步提高测量可信度。

文件才是真相：记录必须落地，不能只靠记忆

这里的“文件才是真相”，指的是工作必须落地成文：不能靠AI记忆、聊天承诺，或一句“我已经记录”。任务、执行、交付、授权和分析都要有可保存、可交接、可追溯的正式记录。换一次会话，仍应能沿文件接着核对。

运行时写下什么，而不是记住什么

TASK保存任务正文、父子关系和范围；Session、attempt、lease及工具调用/返回保存执行线索；REPORT保存角色的交付声明；审批与取消收据保存授权和状态变化。公开聊天、过程文字与日志帮助解释经过，EVAL再检查这些记录是否支持报告。每类记录的证明范围不同。

归档后怎样保留

本次按模型和归档批次导出独立raw-evidence.zip，记录文件清单、大小和SHA256，再检查ZIP可解压性及逐文件哈希。千问、Cursor晚生成的EVAL另留补充批次。正式运行记录来自CodeFlowMu及Host；独立备份和事后复核是实验额外实施的保全步骤。记录完成要能交出文件位置与核验结果，不能只有口头保证。

发生冲突时怎样判断

先核对模型、运行时间、Session、任务与报告关联，再读完整工具返回和正式收据。每天初始化后任务号可能重用，仅凭TASK-001或CUSTOM-001不能识别同一轮。OPS正文存在不能替代提交成功；面板显示运行中不能推翻已取消收据；报告写了“通过”也不能代替相应测试证据。无法对齐的材料标为争议，不强行拼成结论。

EVAL到底评了什么？

本次EVAL统一采用Cursor入口，包含两种不同观察：面板扫描检查系统资产与投影，任务记录分析检查某一轮的执行证据和报告。程序采集段、独立分析段必须分开阅读；程序显示“已生成”也不等于独立分析已完成。

Codex与DeepSeek：资产正常仍需审查报告

Codex面板风险低，任务风险中：巡检链完成，但残余风险和验证缺口使任务观察为partial；只读巡检的产品QA为not_applicable。DeepSeek面板确认四项任务、四份报告及空待办基本一致，但其任务记录分析发现冻结材料指向更早的Codex轮次，不能直接作为DeepSeek的执行统计。

豆包与Cursor：EVAL纠正了扫描器的误报

两轮面板均指出：根任务进入ADMIN验收后，PM.todo为空符合视图合同，不能自动判作待办丢失。Cursor的模型故障恢复可从当轮现场记录追查，但其任务分析包仍混入早晨Codex材料；豆包也存在同类错配。因此任务EVAL为高风险、disputed，不等于两轮业务没有交付。

千问与Kimi：失败也要区分证据层次

千问任务EVAL支持业务blocked：DEV交付，OPS正式提交失败，QA未交报告，根任务最终强制终止；同时冻结材料错配又构成disputed。Kimi没有取得成功生成的两份最终EVAL，不能借其他轮报告补齐。它的失败结论来自本轮会话、错误与强制归档记录。

EVAL不只是附录，也不是最终真理

文章的判断应同时回答两件事：AI有没有完成工作，证明这件事的材料靠不靠谱。EVAL最有价值的作用，是对照原始记录挑战看起来完整的报告；它自身的推断也必须接受复核。

为什么Cursor得87分，任务EVAL却是高风险？

87分依据当轮独立备份中的任务链、正式交付和授权恢复；高风险针对任务记录包的身份与原始材料不一致。两者评价对象不同。豆包、DeepSeek、千问和Cursor的任务EVAL均指出不同程度的旧轮材料关联问题，本文不能直接使用这些争议包的计数给当轮评分。

独立复核带来的纠错，比增加问题数量更有用

豆包、Cursor的EVAL用视图合同推翻了“PM.todo为空即故障”的程序推断。千问EVAL区分真实传输失败与永久依赖死锁：有失败证据，不意味着所有阻塞归因都成立。DeepSeek相关分析中，把独立Cursor EVAL入口当作违规的推断也需纠正；统一旁观入口本来就是本次实验安排。

对CodeFlowMu的综合判断

CodeFlowMu已经展示了把多模型团队工作转为可追查实验材料的能力：任务有结构，授权有记录，恢复有历史，旁观者能提出异议。下一步应优先保证跨轮运行身份唯一、冻结材料关联正确、报告生成状态准确。产品的说服力来自可复盘的成功与失败，文章也因此能够给出有依据、可质疑、可修正的评价。