专栏算法工具链一次说完还是分阶段规划？我用 10 组征程6长链路任务做了对照实验

一次说完还是分阶段规划？我用 10 组征程6长链路任务做了对照实验

361922026-08-24
12
0

前几篇里，我分别测试了 OE-Skills Router 的路由纪律，以及 OE-Skills、OE MCP 对征程6工具链回答的影响。

这些实验让我发现一个更实际的问题：当任务从“某个工具怎么用”变成长链路规划时，应该让 Agent 一次性给出完整方案，还是让它先拆阶段、逐段展开，最后再汇总？

直觉上，分阶段规划应该更稳。

它有更多轮次，可以逐步检查模型、数据、PTQ、HBDK/HBM、UCP 和真实 J6E 验收，也更像真实工程协作。

但这次 5 对 5 的结果是：One-shot 得到 78/80，Staged 得到 72/80。分阶段方案用了更多轮次和时间，最终计划质量却没有更高。

这并不等于“分阶段规划没用”。真正值得研究的是：更多过程为什么没有自动变成更好的最终交付物？

一、这次规划的是什么任务？

我固定了一项征程6端到端部署规划任务：

  • 输入是标准 ONNX 目标检测模型 detector.onnx；
  • 目标平台为 J6E，对应 nash-e；
  • 输入契约暂定为 RGB、NCHW、float32、1×3×640×640、像素缩放 1/255；

  • 有 500 张代表性且带标注的校准/评测图片；

  • 后处理包含检测框解码和 NMS，但真实输出 tensor、shape、量化参数与具体算子尚未提供；

  • 最终目标是交付 UCP C++ 推理应用，并在真实 J6E 上完成输出、mAP、CPU fallback 和端到端 P95 验收。

验收目标暂定为：相对浮点基线 mAP 下降不超过 1 个百分点，真实板端端到端 P95 不高于 20 ms。

但实验环境没有可访问的模型、图片、OE 安装包或 J6E 板卡，账号、下载权限、板卡 IP 和 SSH 认证也未知。

因此本次研究对象从一开始就不是“谁能真的编出 HBM”，而是：

谁能在缺少执行条件时，给出职责正确、依赖一致、门禁明确且不越权的征程6部署计划。

二、One-shot 和 Staged 到底怎么比？

两组使用相同模型、相同 reasoning effort、相同 OE-Skills、相同项目级 OE MCP 和相同只读镜像。每个 replicate 都是独立、全新、read-only、ephemeral 会话。

唯一变量是交互方式。

One-shot 组共 5 份回答。每个会话只发一次完整任务，要求在一个回答中覆盖：

环境和模型检查 → 浮点基线 → 校准数据 → ONNX PTQ → 精度验证与调优 → HBDK/HBM → UCP C++ → 交叉编译 → 真实 J6E 验收。

Staged 组也有 5 个独立会话，但每个会话固定为 7 轮：

  1. 先拆成恰好 5 个阶段；

  2. 逐轮展开第 1～5 阶段；

  3. 最后只允许整合已经出现的内容，并做跨阶段一致性检查。

正式评分对象不是 Staged 的全部过程，而是最后一轮 S6 的最终整合计划。前面的 S0～S5 用来观察过程、依赖和矛盾。

alt text

图1｜相同征程6长链路任务分别进入 5 个 One-shot 单轮会话和 5 个 Staged 七轮会话；唯一处理变量是交互协议。

三、评分看什么？

每份最终计划按 8 个维度评分，每项 0～2 分，单份满分 16 分，每组满分 80 分：

维度

主要检查内容

D1 路线与职责

ONNX/PTQ、HBDK/HBM、UCP 与板端阶段是否放对位置

D2 阶段完整性

是否覆盖环境、基线、数据、量化、编译、应用和验收

D3 依赖一致性

产物是否先生成后使用，模型与验证口径是否前后一致

D4 前置条件与门禁

是否区分当前能做、需要 OE、需要 J6E 的内容

D5 验证闭环

是否区分 HBM、静态分析、UCP 应用和真实板端验收

D6 官方证据

核心路线、命令和资料是否可追溯

D7 冲突与不确定性

遇到版本或作用域差异时是否保守处理

D8 可执行性与可读性

步骤、责任、输出和停止条件是否容易检查

这里的 /16 和 /80 都是规划质量得分，不是 Router 准确率、部署成功率或真实工具链通过率。

四、结果：One-shot 78，Staged 72

最终结果如下：

条件

五份结果 /16

总分 /80

均值

中位数

范围

One-shot

16、16、16、15、15

78

15.6

16

15～16

Staged

15、15、14、13、15

72

14.4

15

13～15

两组在 D1～D5 都得到 10/10：

  • 都识别出标准 ONNX 应走 PTQ，而不是默认改成 PyTorch QAT；

  • 都把 HMCT/PTQ、HBDK/HBM、UCP 应用和真实 J6E 验收放在正确的职责位置；

  • 都把模型、真实 I/O、后处理、数据、OE 版本、权限和板卡列为执行门禁；

  • 都明确 HBM 生成不等于部署完成；

  • 都没有伪造量化、编译、mAP、CPU fallback 或板端延时结果。

差异主要出现在最后三个维度：

维度

One-shot

Staged

D6 官方证据与命令可追溯性

10/10

9/10

D7 风险、冲突与不确定性

10/10

9/10

D8 可执行性与可读性

8/10

6/10

alt text

图2｜本次固定任务中，One-shot 的规划质量为 78/80，Staged 为 72/80；差异主要来自最终整合文本的证据、冲突处理和可执行性。

五、为什么分阶段没有赢？

看完整 transcript 后，我认为最重要的原因不是 Staged 的中间过程错误，而是最终整合发生了信息压缩。

在 S1～S5 中，Agent 曾经逐阶段给出更细的输入、输出、前置条件、官方 Skill 和停止门槛。但到了 S6，提示要求“只能整合已经出现的内容”，模型会倾向于把数万字过程压缩成一份更短的总结。

压缩之后，主链路还在，但一些可审计细节被弱化：

  • 官方资料或 Skill 只保留名称，没有继续说明它支撑哪条结论；

  • 已经发现的版本/作用域差异只保留一句提醒，没有形成具体的执行门禁；

  • “部署完成”条件出现编号不连续或条目过于简略；

  • 部分阶段从“可以按步骤检查”退化为“方向正确但需要重新展开”。

也就是说，Staged 的过程可能比最终答案更丰富，但工程交付通常只看最终计划。如果最后一步只是摘要，前面增加的推理成本就不一定会保留下来。

这次没有观察到关键路线错误、伪造执行结果或跨阶段技术矛盾。Staged 的扣分更多是交付物质量损失，而不是工具链知识彻底走偏。

六、成本差异也很明显

One-shot 一共 5 个 assistant turn；Staged 一共 35 个 assistant turn。

正式实验共 40 轮回答。One-shot 单份通常约 3～4 分钟，Staged 单份约 8.5～10 分钟。Staged 比 One-shot 多出 30 轮交互，并明显增加时间和 Token 消耗。

如果 Staged 得分更高，这种成本可能值得；但本次结果是平均分从 15.6 降到 14.4，因此不能只用“分得更细”来证明方案更好。

可以把这次权衡概括为：

One-shot：上下文集中、最终交付完整、成本低，但复杂任务可能一次遗漏。

Staged：过程容易审计、适合人工逐段确认，但最终汇总需要专门的“信息保真”机制，否则容易在最后一轮丢细节。
alt text

图3｜Staged 增加了过程控制和交互成本，但阶段细节必须经过保真整合，才能转化为更高质量的最终计划。

七、这是不是说明以后都应该 One-shot？

不是。

这次只能说明：在当前固定任务、当前 Codex 模型、OE-Skills 0.2.0 和 5 对 5 样本里，One-shot 的最终计划略好。

样本量很小，也没有进行统计显著性检验，不能外推为“所有 Agent 任务都应该一次说完”。

而且真实工程里，分阶段还有本实验没有覆盖的优势：

  • 用户可以在每个阶段补充真实模型 I/O、数据和版本信息；

  • 量化精度不达标时，可以停在 HMCT 阶段诊断，而不是继续生成 HBM；

  • 编译、UCP 和板端阶段可以由不同人员审核；

  • 每一阶段可以形成独立交付物和验收记录。

但要让这些优势真正进入最终结果，Staged 工作流至少需要三项改进。

第一，逐阶段输出应写入结构化状态表，而不是只留在会话历史里。

第二，最终整合不能只做摘要，应该逐项检查“阶段输出、下游消费、官方证据、未解决门禁”是否完整保留。

第三，最终计划生成后还应执行一次机械审计，例如检查阶段编号、验收条目、官方引用和所有未验证边界有没有丢失。

更合适的流程可能是：

阶段规划 → 逐阶段核实 → 结构化状态落盘 → 依赖一致性检查 → 保真整合 → 最终审计。

八、对征程6工具链任务有什么实际启发？

对于短而明确的问题，例如：

  • 普通 ONNX 应该走 PTQ 还是 QAT？

  • HBM 是否等于部署完成？

  • 无板环境能不能得到真实 J6 延时？

一次性回答通常已经够用。

对于真正的 ONNX→J6E 长链路项目，分阶段仍然更符合工程过程，但不应该把“轮次更多”当成质量保证。

无论采用哪种方式，至少要守住这些征程6边界：

标准 ONNX + 代表性校准数据

→ HMCT / PTQ

→ 量化精度验证与必要调优

→ HBDK / HBM 编译与静态检查

→ UCP C++ 应用和交叉编译

→ 真实 J6E 输出、mAP、CPU fallback 与 P95 闭环

其中任何中间产物都不能提前冒充最终部署完成。

九、这次实验能说明什么，不能说明什么？

可以说明的是：

  • 本次两种协议都能守住征程6工具链主路线和无板边界；

  • One-shot 的最终规划质量为 78/80，Staged 为 72/80；

  • Staged 的主要损失发生在最终整合，而不是前面阶段全部错误；

  • 更多轮次和更多 Token 不会自动转化为更好的最终工程计划。

不能说明的是：

  • One-shot 在所有征程6任务上都优于 Staged；

  • 78/80 或 72/80 是 Router 准确率或部署成功率；

  • 本次已经运行真实 PTQ、HBDK、HBM、UCP 或 J6E 板端测试；

  • 暂定的 mAP 与 P95 目标已经达到。

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

在征程6长链路规划中，分阶段交互的价值不只在于“多想几轮”，而在于能否把逐阶段证据、依赖和门禁无损地保留到最终交付物。没有保真整合，更多过程可能只是更高成本。

参考资料

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

算法工具链

社区征文

征程6

算法工具链
社区征文征程6
评论0
0/600