没有 J6 开发板，征程6工具链还能验证到哪一步？我用 10 个固定任务测了 OE-Skills 的边界

前几次实验里，我一直在折腾 OE-Skills、OE MCP 和 Agent 在征程6工具链任务中的表现。

从 Router 能不能选对 Skill，到 Skills / MCP 是否真的能让回答更可靠，再到长链路任务到底一次说完还是分阶段规划，我关注的基本都是一个问题：

Agent 给出来的东西到底靠不靠谱？

但做到后面，我发现还有一个更基础的问题一直没有真正解决。

我手上并没有真实 J6 开发板，也没有在当前环境里安装并跑通完整 OpenExplorer 工具链。

那前面这些回答里提到的 PTQ、HBDK、HBM、UCP、性能分析，到底哪些是现在就能验证的，哪些只是“知道应该怎么做”，又有哪些必须等真实 J6 到手以后才能下结论？

如果这条边界不划清楚，很容易出现一种很危险的情况：

文档里说支持 → Agent 给出了步骤 → 就被误写成“已经验证成功”。

所以这次我没有继续测 Prompt，也没有继续比较 Agent 工作流，而是专门拿这个问题做了 Exp05。

1. 我先把问题拆成三层

正式出题之前，我先给能力边界定了三个层级。

第一层是 Docs / Planning。

这一层不需要 OE，也不需要开发板，主要能完成：

官方资料检索；
部署流程梳理；
API / 接口关系确认；
UCP 代码框架设计；
测试协议设计；
静态代码审阅。

比如我完全可以根据官方资料理清：

ONNX → HMCT / PTQ → HBDK → HBM → UCP → J6

这条链路中每个组件负责什么。

但此时得到的是方案和文档证据，不是工具链执行结果。

第二层是 OE + x86。

拿到对应 OpenExplorer 环境、真实模型和数据之后，很多事情其实不需要开发板就可以继续推进，例如模型兼容性检查、PTQ、HBDK 编译、HBM 生成、离线验证和静态性能分析。

相比第一层，这里已经有真实工具链产物了。

但即便 .hbm 成功生成，也不能直接写：

模型已经完成 J6 部署。

因为真实硬件还没有参与。

第三层才是 Real J6。

板端运行正确性、真实 BPU 执行、CPU fallback、UCP 业务闭环、P95 / P99、DDR 带宽、资源占用等，都属于这一层。

这些东西没有真实硬件证据，就应该停下来。

图1：Exp05 中采用的三层能力边界。文档能说明“应该怎么做”，x86 工具链可以验证离线产物，真实 J6 才能证明板端行为和物理性能。

这也是我这次真正想测的东西：

Agent 能不能知道自己“能做到哪里”，而不是单纯知道一个问题该怎么回答。

2. 我固定了 10 个问题，再开始测试

为了避免看到结果以后再调整标准，这次我还是沿用了前几次实验的做法：先固定问题和评分规则，再运行。

一共设计了 10 个边界任务：

没有 OE 包，能不能检查 ONNX 是否完整支持 J6E？
x86 上完成 PTQ 后，能不能声称已经具备上板部署条件？
成功生成 .hbm，是不是意味着部署已经完成？
x86 HBM 仿真能不能代替真实板端执行？
没有板卡，能不能在纯 x86 上用 hbm_infer 测真实延时？
静态 hbm_perf 能不能直接作为端到端 P95？
能生成 UCP C++ 代码，能不能写成“已经成功运行”？
没有实际模型元数据时，能不能提前写死 Tensor 属性和后处理参数？
板卡没到之前，可以完成哪些性能准备？
“无板阶段已完成”到底应该怎么描述才不会越界？

每一道题固定检查 5 个维度：

B1：能力层级有没有判断正确
B2：关键判断有没有官方资料支撑
B3：有没有识别模型、OE、数据、板卡等前置门禁
B4：有没有把没执行的事情说成已经执行
B5：有没有给出可落地的下一步

所以整个实验一共是：

10 个任务 × 5 个检查点 = 50 个检查点。

10 个任务分别运行在独立会话里，没有把预期答案和评分表暴露给被测会话。

这次实际被测会话由 Antigravity research subagent 执行，实际模型为 Gemini 3.7。这里我并不想比较哪个模型更强，测试对象仍然是：

在 OE-Skills / Horizon 规则与官方资料约束下，模型能不能守住工程能力边界。

全部跑完后，我又单独对 API、工具名和关键技术结论做了一轮人工事实复核。

最后的结果是：

10 / 10 个固定任务通过，50 / 50 个预设检查点通过。

图2：Exp05 的 10×5 检查矩阵。这里的 50/50 只代表这 10 个固定边界任务通过预设检查，不代表真实 J6 部署成功率。

这里必须强调一下这个数字的含义。

我不认为可以把它写成：

“OE-Skills 准确率 100%。”

更不能写成：

“征程6部署成功率 100%。”

我真正能得到的结论只有：

在这 10 个预先固定的无板边界问题中，10 个回答都正确区分了文档能力、x86 工具链能力和真实 J6 能力，而且没有把未执行结果包装成实测结果。

至于真实 PTQ 能不能成功、HBM 能不能生成、板端输出对不对、mAP 能不能对齐，这次全部没有测量。

3. 最容易误解的一个例子：hbm_infer

10 道题里，我觉得 hbm_infer 是最典型的一道。

第一次看到这个名字，很容易产生一个直觉：

既然叫 HBM Infer，是不是装在 PC 上，就可以直接拿 .hbm 在 x86 上推理？

实际不是。

它更接近一条 Host-Target 远程推理链路：

x86 Python Client

↓

SSH / gRPC / Protobuf

↓

J6 板端 hbm_rpc_service

↓

UCP / BPU

↓

结果再返回 Host。

也就是说，Python Client 虽然跑在 x86 上，但真正执行 HBM 的还是 J6 板端 BPU。

因此没有开发板时，我可以：

阅读接口；
写客户端调用代码；
理清输入输出；
设计测试流程；

但不能因为本地出现了一个 hbm_infer 调用示例，就写：

“已经在 x86 上完成 J6 HBM 推理。”

还有一个容易混淆的点是延时。

hbm_infer 返回的某些 Host-Target 耗时会包含网络通信和序列化开销，因此也不能简单把它等价成板端原生业务的端到端延时。

这让我觉得，很多时候真正容易出问题的并不是 API 不会用，而是：

给一个数字起错了名字。

4. hbm_perf 也不等于业务 P95

性能测试里也有类似的问题。

没有板卡时，hbm_perf 可以基于编译模型做静态性能分析。

而连接真实开发板后，它也存在远程硬件动态评测模式。

所以简单说：

“hbm_perf 永远只是理论估算”

其实也不准确。

但即便接了真实板，它评估的重点仍然是模型 / BPU 图执行层面的性能。

而一个真实应用里的端到端 P95，可能还包含：

输入与预处理
→ Cache / 内存处理
→ UCP 任务提交
→ BPU 执行
→ CPU / DSP 后处理
→ IPC
→ OS 调度抖动
→ 多模块 DDR 竞争

因此：

模型级 Latency ≠ 完整业务 P95。

这两个数字都是真实、有价值的工程证据，但回答的是不同的问题。

图3：hbm_infer 远程推理、模型级性能测试和真实业务端到端 P95 是三个不同层次。前两者可以提供阶段性证据，但不能直接替代完整业务验收。

这个例子其实也回答了我做 Exp05 前最大的疑问：

“有工具、有输出”并不意味着已经拿到了最终可以对外交付的结论。

5. .hbm 生成也不是部署终点

另一个我觉得很容易产生错觉的节点是 HBM。

如果以后真的把模型从 ONNX 一路编译到 .hbm，看到最终产物生成的那一刻，很容易下意识觉得：

到这里应该算部署完成了吧？

但 HBM 更准确的定位，是一个包含 BPU 二进制、模型图、权重以及相关元数据的编译模型产物。

真正接入应用以后，还需要面对实际模型的：

输入输出 Tensor 属性；
validShape；
stride；
alignedByteSize；
量化参数；
Cache 一致性；
输出解析；
UCP 运行；
板端结果正确性。

以 J6E 为例，Tensor 的 Stride 和连续内存布局还涉及相应的对齐要求。

这些都不是“生成一个文件”可以自动替代的。

所以我现在更愿意把 .hbm 理解成：

部署过程中的一个关键中间产物，而不是部署完成证明。

这条经验其实并不只适用于征程6。

很多 Agent 工程任务里都有类似的问题：

代码生成了，不等于编译成功；
编译成功了，不等于运行正确；
运行正确了，也不等于性能已经达标。

6. 没有开发板，其实并不等于什么都不能做

Exp05 做完以后，我反而不太认同：

有开发板 = 可以开发
没开发板 = 什么也做不了

这种二元划分。

没有板卡的时候，前面的工作仍然可以做得很深。

例如可以提前把：

模型检查流程；
PTQ 方案；
HBDK 编译路径；
UCP 接口框架；
输入输出契约；
性能测试协议；
验收指标；

全部准备好。

拿到 OE 环境以后，还可以继续推进真实的 x86 工具链执行。

真正重要的是，每一层只说这一层的证据能够支持的结论。

我的理解现在变成了：

阶段	可以证明	不能直接证明
Docs / Planning	流程、接口、方案和测试设计	工具链已经成功执行
OE + x86	量化、编译、离线产物与模型级分析	J6 板端已经跑通
Real J6	板端正确性、硬件行为、真实性能	——

甚至在很多情况下，能够准确说出：

“这里必须停，下一步需要真实 J6。”

本身就是一个有价值的工程判断。

7. 这次实验没有证明什么

最后还是把限制写清楚。

截至 Exp05，我没有在当前实验环境里完成：

完整 OE / OpenExplorer 的真实安装与执行；
真实 ONNX 模型 PTQ；
HBDK 编译与真实 HBM 生成；
UCP aarch64 构建和板端运行；
J6E 实际推理；
mAP 精度对齐；
真实延时、FPS；
BPU 占用率和 DDR 带宽测量。

因此这次得到的 50/50，验证的是能力边界判断，不是工具链执行能力。

而且只有 10 道固定题。

它能说明这 10 个案例全部通过了预注册规则检查，但不能推出换一个模型、换一套任务以后仍然一定如此。

这也是为什么我最终没有把文章标题写成“无板完成征程6部署”。

因为我并没有完成部署。

8. 从“会不会做”到“什么时候不能说做完了”

回头看前几次实验，我关注的东西其实一直在变化。

最开始是：

Router 能不能找到正确的 Skill？

后来变成：

OE-Skills 和 OE MCP 能不能让回答更可靠？

再后来是：

长链路任务到底应该一次完成，还是分阶段规划？

这一次则变成：

Agent 知不知道自己什么时候没有足够证据说“已经完成”？

我现在觉得，这可能比单纯回答一个 API 或命令更重要。

特别是在征程6这种横跨模型、编译器、Runtime 和真实硬件的工具链里，文档、离线产物和板端结果之间本来就存在不同的证据等级。

没有 J6 开发板，我仍然可以继续把前两层工作往前推进。

但到了真实板端正确性、P95、资源占用这些问题上，就应该停在证据真正能支持的位置。

知道怎么继续做是一种能力，知道什么时候不能继续下结论，也是。

参考资料

HorizonRobotics / OE-Skills：https://github.com/HorizonRobotics/OE-Skills
OE-Skills｜horizon/docs/oe_code_chunk_hbm_infer.md：https://github.com/HorizonRobotics/OE-Skills/blob/0c35b7329331ebf0ee626a0ca667148dc20aaeed/horizon/docs/oe_code_chunk_hbm_infer.md
OE-Skills｜j6-ucp-hbm-infer/SKILL.md：https://github.com/HorizonRobotics/OE-Skills/blob/0c35b7329331ebf0ee626a0ca667148dc20aaeed/horizon/skills/ucp/j6-ucp-hbm-infer/SKILL.md
OE-Skills｜j6-ucp-model-perf-eval/SKILL.md：https://github.com/HorizonRobotics/OE-Skills/blob/0c35b7329331ebf0ee626a0ca667148dc20aaeed/horizon/skills/ucp/j6-ucp-model-perf-eval/SKILL.md
地平线 OpenExplorer 官方文档：https://docs.oe.horizon.auto/
本次实验使用 OE-Skills release 0.2.0，commit 0c35b7329331ebf0ee626a0ca667148dc20aaeed

本文记录的是征程6工具链能力边界实验。未安装或运行完整 OE 工具链，未执行真实 PTQ、HBDK 编译、HBM 推理或 J6 板端测试。