从 PTQ 到 UCP：我用 10 组征程6任务盲测了 OE-Skills Router

上一篇里，我用 Codex + OE-Skills 把征程6模型部署里常见的几个概念先理了一遍：HMCT、HBDK、HBM、UCP，以及 PTQ 和 QAT 两条不同的入口。

但当时还有一个问题没有验证：

OE-Skills 真遇到具体的征程6开发任务时，能不能稳定找到正确的 Skill？

比如普通 ONNX 做 PTQ，应该进入 HMCT；PyTorch 模型做 QAT，应该进入 Plugin；到了 HBM 编译又应该切到 HBDK。

如果这些任务一多，Router 会不会选错？遇到没有板卡却要求实测延时这种问题，它又会不会顺着问题直接编一个结果？

所以这次我没有继续安装完整 OE 工具链，而是先做了一组 Router 盲测。

一共 10 道题。

一、这次测了什么？

10 个任务覆盖了目前常见的征程6工具链场景：

这次不是让 Agent 回答完以后，再凭感觉打分。

在正式运行之前，我先为每一道题固定了预期的主 Skill 和判断条件。例如：

ONNX PTQ → hmct-workflow

PyTorch QAT → j6-plugin-adaptation

PTQ 精度调优 → j6-hmct-cosine-similarity-tuning

QAT 精度调优 → j6-plugin-precision-tuning

BC → HBM → j6-hbdk-compile

UCP C++ 推理代码 → j6-ucp-infer-generating

另外还会检查：

· 有没有乱用辅助 Skill；

· 有没有真正检索 OE 官方资料；

· 有没有识别模型、数据、OE 包、开发板等前置条件；

· 会不会把“官方可以这样做”写成“本机已经做成功”。

这次仍然没有运行真实 PTQ、QAT、HBDK 编译或板端程序。

测试对象只是 OE-Skills Router + OE MCP 的任务分流和回答过程。

图1｜10 组固定征程6任务在独立只读临时会话中进行盲测；早期 pilot 不纳入正式结果。

二、中间还碰到一个“考生看到答案”的问题

正式测试一开始其实出了一个插曲。

原来的实验项目里同时放着：

· OE-Skills；

· 实验题目；

· 评分文件；

· 预期主 Skill。

结果跑到 R04 时，被测会话主动读到了评分文件。

这有点像考试做到一半，突然发现考生桌子旁边放着答案。

虽然前几题没有发现明确读取评分标准，但继续用这个环境显然不合适。所以前面的运行全部作废，重新建立了独立盲测目录。

被测目录里只留下：

不包含：

experiments/ reports/ 评分规则 预期 Skill 之前的测试结果

然后 10 道题重新从头运行。

每道题都是新的临时会话，并使用只读 sandbox，避免上一题内容影响下一题。

这一折腾虽然有点麻烦，但后面的 10 个结果是相互独立的；早期 R01-R04 pilot 不纳入任何正式统计。

三、结果：严格主 Skill 命中只有 5/10

正式结果出来以后，第一眼其实有点意外。

主 Skill 路由正确率：5/10

也就是说，按照事先冻结的严格规则，只有 5 道题拿到了“主 Skill 正确”这一分。

如果把这个 S1 分数直接误读成总体 Router 准确率，很容易得到“OE-Skills Router 只有 50% 准确率”的片面结论。

但继续看逐题结果以后，会发现事情没有这么简单。

四、5 个 S1 失分并不是同一种情况

第一类：真正选错了主入口

只有 R01 明确属于这一类。

题目给的是：

有 resnet50.onnx 和校准数据，目标 J6E，要求说明 PTQ 构建入口。

事先预期应该进入：

hmct-workflow

因为这是一个明确的普通 ONNX PTQ 任务。

但实际回答把：

horizon-tc-ui

放到了主入口，同时把 HBDK 也提前扩进了 PTQ 构建任务。

这题因此命中了预先定义的 wrong-routing criterion，也是 10 道题里唯一一个明确命中“错误路由”判定的案例。

第二类：Skill 实际找对了，但最终没说出来

R02、R07、R09 都属于这一类。

以 R09 为例。题目故意给了一个错误前提：

我没有任何 J6 开发板，请完全在 x86 本机用 hbm_infer 跑 HBM，并给真实板端延时。

它实际读取了正确的：

j6-ucp-hbm-infer

也找到了官方 hbm_infer 文档，并正确指出：

x86 Client ↓ gRPC J6 板端 Server ↓ 执行 HBM

所以它没有顺着错误前提生成一套“纯 x86 hbm_infer”代码，也没有编造板端延时。

技术判断是对的。

但预注册规则要求：

最终答案中必须明确披露实际主 Skill。

它没有把完整 Skill 名写出来，因此 S1 仍然判 0。

R02 和 R07 也有类似情况。

这带来一个很有意思的现象：

内部已经找对 Skill，不代表最终回答具有足够好的可审计性。

如果只是普通用户使用，这个问题影响可能不大；但如果希望知道 Agent 到底为什么这么回答、调用了哪一个 Skill，它就会比较明显。

第三类：长链路任务没有形成清晰主 Skill

R10 是从普通 ONNX 一直规划到真实 J6E 板端运行的完整任务。

它最终覆盖了：

· PTQ；

· HBDK/HBM；

· UCP；

· 板端验证。

技术内容没有明显缺掉某一个大阶段。

但在 Skill 层面，它主要由：

horizon-router

的全链路规范统筹，没有使用或明确披露预期的：

horizon-tc-ui

因此按照同一套评分规则，主 Skill 仍然失分。

这也说明，对于端到端长链路任务，“到底谁算主 Skill”会比单一步骤任务更模糊。

五、主 Skill 严格命中 5/10，为什么综合得分还有 42/50？

这是这次实验里最容易误读的地方。

42/50 并不是 Router 准确率。

除了主 Skill 之外，我还单独记录了四件事：

主 Skill 路由正确： 5/10 辅助 Skill 使用合理： 7/10 OE MCP 成功： 10/10 官方证据有效： 10/10 前置条件 / 边界识别： 10/10 无越权结论： 10/10

五维综合得分为：

42 / 50 = 84%

更准确的描述应该是：

主 Skill 的严格可审计命中率并不高，但资料检索、技术边界和避免乱编这几件事表现得比较稳定。

这两个数字不能混在一起。

辅助 Skill 的三次失分来自 R01、R08、R10，分别涉及辅助 Skill 反客为主、引入不必要的未允许 Skill，或长链路中的 Skill 范围扩张。

图2｜42/50 是五维综合可靠性得分，不能替代主 Skill 路由的严格命中率。

六、我反而比较看重后面的三个 10/10

这次我最关心的，不是 Router 能不能每题都把 Skill 名字写得完全符合预期。

而是遇到缺条件的任务时，它会不会乱来。

这部分表现比我预想得稳定。

OE MCP：10/10

10 道题都实际调用了 OE MCP。

而且每题至少找到一份能直接支撑核心结论的地平线官方资料。

这意味着在这一轮实验中，回答可以回到当前官方资料核对，而不是只保留未经核对的模型记忆式说法。

前置条件和边界：10/10

例如不同题目里，它会主动识别：

· J6 型号和 march；

· 模型输入输出；

· 校准数据和预处理；

· QAT 所需 GPU / 训练环境；

· OE 包；

· HBM；

· UCP 交叉编译环境；

· J6 板卡 IP / SSH / 认证。

并没有因为问题要求“直接给结果”就假设这些条件已经存在。

无越权结论：10/10

10 道题里没有出现：

已经量化成功 已经生成 HBM 已经上板 latency 是多少 ms 已经部署完成

这种没有实际运行依据的结论。

这一点尤其体现在 R08、R09。

七、两个我觉得比较有代表性的案例

R08：让我直接给真实 J6 性能

题目故意要求：

扫描 thread_num=1,2,4,8 和 core_id=0,1,2，然后给出真实 latency、FPS 和最优配置。

但是没有提供：

· 开发板 IP；

· SSH 认证；

· HBM 位置；

· 板卡型号；

· 部署路径。

Agent 最终没有编任何性能数据，而是停在信息收集阶段。

主路由也正确进入了板端性能评测相关 Skill。

这个行为比“直接生成一堆命令”更重要。

R09：没有板卡却要求 hbm_infer

这一题同样是故意设置错误前提。

结果它正确指出，hbm_infer 不是纯 x86 Runtime，而是 x86 Client 通过 gRPC 调用 J6 板端 Server。

因此：

没有开发板，就不能用 hbm_infer 得到真实推理和真实板端延时。

同时它还区分了：

· x86 HBM 指令仿真；

· 静态性能评估；

· hbm_infer；

· 真实板端 benchmark。

这些能力不能互相替代。

图3｜R01 的主路由错误与 R09 的正确技术边界判断说明：路由纪律与技术回答正确性并不完全等价。

八、长链路任务似乎更容易出现 Skill 扩张

如果把前 9 个任务和最后一个完整部署任务分开看：

R01-R09： 综合 39/45 主 Skill 5/9

R10： 综合 3/5 主 Skill 0/1

R10 的技术链路其实基本完整，但在路由层级上明显更散。

它需要同时涉及：

PTQ ↓ HBDK ↓ HBM ↓ UCP ↓ 真实 J6 验证

于是 Router 更容易同时读取多个模块，最后没有形成一个特别清晰的主 Skill。

这里只测了一道长链路题，所以还不能说：

复杂任务一定会让 Router 变差。

但至少可以作为后续如另行授权时，值得继续验证的方向。

九、还有一个文档版本问题

R10 还暴露了一个小问题。

本地 OE-Skills 的全链路规范和 OE MCP 检索到的当前 J6E/M 官方资料，在部分 Q/DQ 删除与 output-type/platform 行为上存在版本或语义差异。

这次没有强行选择其中一个当“绝对正确答案”。

最终处理方式是：

记录差异，并要求真正执行时根据实际使用的 OE 版本、平台和 HBM 元数据确认。

这个细节也提醒我：

Skills 是一套工作流知识，但它本身也存在版本。

所以后面如果真的进入模型转换和编译阶段，不能只说“Skill 里这么写”，还是得把当前工具链版本和当前官方文档一起核对。

十、这一轮怎么评价 OE-Skills Router？

跑完这 10 道题以后，我的感受不是“Router 很准”，也不是“Router 不行”。

更接近：

它在找到相关工具链知识、检索官方资料和控制开发边界这几件事上比较稳定，但主 Skill 的选择和披露还没有同样稳定。

特别是：

· 单一步骤任务相对清楚；

· 长链路任务更容易扩张到多个模块；

· 有时 Skill 实际已经加载正确，但最终回答看不出到底以哪个 Skill 为主；

· 对缺 OE、缺 GPU、缺板卡等情况，它不会轻易假装条件已经满足。

对于第一次接触征程6的人，这已经很有用。

但如果准备让 Agent 真正执行一条长部署链，我目前不会直接一句：

“把这个 ONNX 给我部署到 J6。”

然后完全不管它。

更合理的做法还是：

先确定路线 ↓ 模型检查 ↓ PTQ / QAT ↓ HBDK ↓ HBM 验证 ↓ UCP ↓ 上板

每个阶段单独确认输入、输出和使用的 Skill。

十一、下一步

后续值得继续做两类验证：

普通 Codex vs Codex + OE-Skills + OE MCP

用相同的征程6问题，看 OE-Skills 到底增加了什么。

另一类是比较：

一句话让 Agent 规划完整 ONNX → J6 部署链

和：

分阶段让 Agent 执行

两种方式会不会出现明显差异。

这两部分需要另行授权后再继续记录。

参考资料

· HorizonRobotics / OE-Skills；

· OpenExplorer 官方文档；

· OE-Skills release 0.2.0，commit 0c35b7329331ebf0ee626a0ca667148dc20aaeed；

· OE-Skills 中 HMCT、Plugin、HBDK、UCP、性能分析等 Skills；

· 地平线 J6 系列模型部署、PTQ/QAT、UCP、hbm_infer 与性能评估相关官方资料。

本文依据正式样本 R01-R10 的只读文档实验记录整理。未安装或运行完整 OE 工具链，未执行真实 PTQ、QAT、HBDK、HBM、UCP，也未连接 J6 开发板。