OE-Skills 和 OE MCP 能让征程6工具链回答更可靠吗？我做了 30 次对照实验

上一篇里，我用 10 组固定的征程6任务盲测了 OE-Skills Router。

那一轮回答了一个问题：面对 ONNX PTQ、PyTorch QAT、HBDK/HBM 编译、UCP 推理和真实板端性能请求时，Router 能不能把任务送到合适的 Skill，同时守住“没有 OE、没有 J6 板卡就不能假装已经跑通”的边界。

但还有一个更直接的问题没有回答：

**如果把同一组征程6问题交给普通 Codex、只加载 OE-Skills 的 Codex，以及同时加载 OE-Skills 和 OE MCP 的 Codex，结果到底有什么差别？**

直觉上，工具越全，答案应该越好。

这次的结果没有这么简单。

## 一、为什么这次要拆成三组？

如果只比较：

普通 Codex

和

Codex + OE-Skills + OE MCP

即使结果有差异，也很难知道提升到底来自哪里。

OE-Skills 主要提供任务路由、工作流和约束；OE MCP 主要负责检索当前地平线官方资料。它们不是同一种能力。

所以这次把实验拆成三组：

| 组别 | 环境 |

|---|---|

| A | 普通 Codex：没有项目 OE-Skills，没有 OE MCP |

| C | OE-Skills + OE MCP：既加载 Skills，也启用项目隔离的 OE MCP |

三组使用相同模型、相同 reasoning effort 和完全相同的题目。

每一道题都使用新的只读临时会话，不共享上一题的上下文，也看不到评分规则和其他组回答。

图1｜10 组征程6任务分别进入普通 Codex、OE-Skills only 和 OE-Skills + OE MCP，最终形成 30 份独立回答。

## 二、固定的还是那 10 类征程6任务

为了能和上一篇形成连续实验，这次仍然使用 10 类固定任务：

1. 普通 ONNX 做 PTQ，并解释 HBM 是否等于部署完成；

2. PyTorch 模型走 QAT；

3. 训练正常、从 export 到 HBM 开始掉点；

4. QAT loss 发散和 NaN；

7. 区分静态性能、仿真和真实板端性能；

8. 缺少 IP、认证和模型路径却要求真实 J6 性能；

9. 缺少真实 I/O 时规划 UCP C++ 推理程序；

10. 从 ONNX 一直规划到 J6E 板端闭环。

这次仍然没有安装或运行完整 OE 工具链，也没有连接 J6 开发板。

三组回答的都是方案和文档问题，不是量化、编译或板端实测。

## 三、评分不再只看“Skill 名字对不对”

Phase 2 主要研究 Router，因此对主 Skill 的选择和披露要求很严格。

Phase 3 要比较普通 Codex 和两种 OE 条件，普通 Codex 本来就没有 Skill slug。继续把“有没有写出 Skill 名称”作为评分项并不公平。

所以这次统一改成五个维度，每项 0～2 分：

| 维度 | 检查内容 |

|---|---|

| D1 工具链路线 | PTQ/QAT/HBDK/UCP/板端阶段是否放对位置 |

| D2 技术完整性 | 步骤、产物和验证门槛是否完整 |

| D3 官方证据 | 是否给出可追溯、能支撑结论的地平线资料 |

| D4 前置条件与边界 | 是否识别 OE、模型数据、板卡和权限等条件 |

| D5 无幻觉与无越权 | 是否把未执行内容误写成已经成功 |

每组 10 道题，满分 100。

这里要先强调：

## 四、结果：A 和 B 都是 90，C 是 83

最终结果如下：

| 组别 | 总分 | D1 路线 | D2 完整性 | D3 证据 | D4 边界 | D5 无越权 |

|---|---:|---:|---:|---:|---:|---:|

| A 普通 Codex | **90/100** | 17/20 | 18/20 | 18/20 | 19/20 | 18/20 |

| B OE-Skills only | **90/100** | 20/20 | 19/20 | 12/20 | 20/20 | 19/20 |

| C OE-Skills + OE MCP | **83/100** | 17/20 | 18/20 | 11/20 | 19/20 | 18/20 |

图2｜三组综合得分并没有随工具数量单调上升；Skills-only 的路线得分最高，而 Full 组没有把 MCP 检索优势稳定转化成最终可审计证据。

第一眼看到这个结果，很容易写成：

“普通 Codex 和 Skills-only 一样，加载 MCP 反而更差。”

但这句话过于简单，也会掩盖真正有价值的差异。

## 五、Skills 真正增加的是“路线纪律”

如果只看 D1 工具链路线：

- A：17/20，路线完整正确 8/10；

- B：20/20，路线完整正确 10/10；

- C：17/20，路线完整正确 8/10。

B 组虽然总分和 A 组相同，但它在 10 道题里都符合预注册的征程6工具链路线。

比如：

- ONNX + 校准数据 → HMCT / PTQ；

- PyTorch 训练链路 → Horizon Plugin / QAT；

- 训练侧正常、部署阶段掉点 → Plugin consistency debug；

这说明 OE-Skills 的作用不一定是让每一段回答都比普通模型更长，而是让 Agent 更稳定地遵守工具链分工。

对于征程6这种包含 HMCT、Plugin、HBDK、HBM、UCP 多个阶段的任务，这种路线约束是有价值的。

## 六、为什么 Full 组反而在 Q01 走偏了？

最关键的案例是 Q01：普通 ONNX + 代表性校准数据，目标 J6E，要求说明 PTQ 到部署产物的路线。

预注册规则把主路线冻结为：

ONNX + calibration data

→ HMCT / PTQ

→ HBDK

→ HBM

→ UCP 与真实板端验证

B 组按这个路线回答，因此 D1 得到满分。

这里不能简单说：

问题在于两套资料描述的是不同抽象层级：

- OE-Skills 的 HMCT workflow 强调“这道 ONNX + 校准数据任务首先属于哪个业务模块”；

Router 实验考的是前者，但 C 组被后者带走，最后没有保留 HMCT/PTQ 的主模块地位。

所以这更准确地说是：

**Skill 路由语义与集成 CLI 语义发生了作用域冲突。**

这也是 Full 组总分下降的最大来源之一。

## 七、MCP 91/91 次成功，为什么证据分只有 11/20？

C 组并不是每一题都调用了 OE MCP。

实际情况是：

- MCP 调用覆盖：8/10 题；

- 已调用会话成功：8/8；

- 工具调用：91/91 次成功；

- Q07、Q08 只读取了本地官方 Skill，没有调用 MCP。

从工具层看，MCP 本身运行得很稳定。

但 D3 评分看的是最终回答里有没有留下可审计证据，例如：

- 官方文档标题；

- URL；

- Doc ID；

- 明确的本地官方资料路径；

- 资料如何支撑当前结论。

很多 C 组回答内部查了不少文档，最后只写成：

“已通过 OE MCP 核实。”

或者只列出 Skill 名称，没有把真正命中的文档标题和标识写出来。

这就出现了一个很有意思的差别：

**检索成功，是 Agent 的内部过程；证据可审计，才是最终回答的外部质量。**

如果检索结果没有进入最终答案，读者无法判断它具体参考了什么，评分自然不会因为后台调用次数多就自动增加。

图3｜Router、MCP 和最终回答分别负责路线、资料和证据表达；任意一层缺少作用域消解或引用落盘，都可能让“工具调用成功”无法转化为可靠答案。

## 八、这次连评分器也需要被审计

30 份回答收齐以后，我先把 A/B/C 组名隐藏，随机改成 X1/X2/X3，再交给独立评分会话按冻结规则统一评分。

但盲评分本身也出了一次错。

在 Q08 里，B/C 回答都写到：已经只读检查工作区，没有发现板卡配置、模型和运行环境。

盲评分器只看到最终回答，没有看到原始工具日志，于是把这些话误判成“伪造执行”，分别给了 6/10 和 5/10。

实际 JSON 日志可以直接证明这些只读命令确实执行过。

因此我没有覆盖原始盲评分，而是单独保存证据裁决：

- B/Q08：6 → 9；

- C/Q08：5 → 9；

- 其他 28 份回答不改。

这件事让我觉得，Agent 实验里不能只审计“被测 Agent”，评分 Agent 同样需要保留原始记录。

否则评分器的一次事实误判，也可能被包装成一个看起来很精确的总分。

## 九、三组各自强在哪里？

### A：普通 Codex

优点是回答完整，很多题还能给出公开官方链接，因此 D3 得分最高。

但在 Q01 的工具链主入口以及 Q02 的 march 确认上，缺少 Skills 提供的路线约束。

### B：OE-Skills only

最大的优势是路线最稳定：D1 20/20，D4 20/20。

缺点是很多回答只引用本地 Skill，没有把具体文档标题、URL 或 Doc ID 写出来，因此证据分不高。

### C：OE-Skills + OE MCP

它能检索更深、更具体的官方资料和版本差异。

但它没有自动解决“集成 CLI 与业务 Skill 谁是主入口”的冲突，也没有保证检索结果最终被写成可审计引用。

所以这次不能得出：

“工具越多，答案一定越好。”

更准确的说法是：

**工具提供能力，工作流决定这些能力能不能被正确使用。**

## 十、如果真要让 Agent 处理征程6任务，我会加四条规则

经过这三轮实验，我更愿意采用下面的顺序：

第一，Router 先确定任务属于 HMCT、Plugin、HBDK、UCP 还是性能工具。

第二，Skill 固定当前阶段的职责、输入输出和停止条件。

第三，OE MCP 只负责核实当前版本的 API、参数、默认行为和差异，不自动取代 Skill 的任务边界。

第四，最终回答必须披露：使用了什么 Skill、检索了什么官方资料、哪里存在冲突、哪些内容没有执行。

可以简化成：

任务

→ Router 确定模块

→ Skill 约束工作流

→ MCP 核实版本与文档

→ 冲突消解

→ 引用落盘

→ 明确未验证边界

对于普通 ONNX 到 J6 的长链路，也不应该一句话直接跳到“生成 HBM”。

还是应该分阶段确认：

浮点模型与数据

→ HMCT / PTQ

→ 量化精度

→ HBDK / HBM

→ 静态与一致性检查

→ UCP 应用

→ 真实 J6 输出、精度和性能闭环

## 十一、这次实验能说明什么，不能说明什么？

可以说明的是：

- 在这 10 道固定征程6任务里，OE-Skills only 的路线一致性最好；

- OE MCP 的连接和检索很稳定，但调用成功不等于最终答案证据完整；

- Skills 与当前官方集成文档之间可能出现作用域或版本语义差异；

- 没有 OE 和板卡时，三组基本都能避免伪造量化、HBM 和真实板端性能结果。

不能说明的是：

- OE-Skills 在所有征程6任务上都优于或不优于普通 Codex；

- OE MCP 会普遍降低回答质量；

- 90/100、83/100 是 Router 准确率；

- 这次已经跑通真实 PTQ、QAT、HBDK、HBM、UCP 或 J6 板端部署。

样本只有 10 道题，结论还绑定 OE-Skills 0.2.0、本次 Codex 模型和当前官方资料窗口。

所以我更愿意把这篇的结论写成：

**在征程6工具链任务中，OE-Skills 能改善路线纪律；OE MCP 能增加官方资料能力，但只有完成冲突消解和证据披露，检索能力才会真正变成回答质量。**

## 参考资料

- 本文正式样本：Q01–Q10 × A/B/C，共 30 份独立只读回答

本文只记录征程6工具链文档与方案回答实验。未安装或运行完整 OE 工具链，未执行真实量化、训练、编译、HBM 推理或 J6 板端测试。