oh-my-hermes 并行评估（Parallel Evals）机制：审查与验证为何交叉检查？完整指南

oh-my-hermes 并行评估Parallel Evals机制审查与验证为何交叉检查完整指南【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermesoh-my-hermes是一款为 Hermes Agent 打造的一体化插件All in one plugin把编码智能、长期记忆系统与模型优化的工作流封装包整合在一起。它的并行评估Parallel Evals机制让多个 AI 工作泳道同时开工并用审查 验证交叉检查保证并行结果真实可信。本文带你从零理解这套机制为什么并行需要交叉检查、它如何防止两个泳道改坏同一个文件、以及验证证据链是怎么闭环的。什么是并行评估Parallel Evals在 oh-my-hermes 中ultrawork缩写ulw是并行评估的执行引擎它把一个已接受的实施计划拆分成互不重叠的并行泳道lanes每个泳道都自带验收标准、验证命令和负责人。官方把它概括为 ULW 行为三件套之一——todo init、阶段清单、parallel evals并行评估单元OMHs ULW behaviors (todo init, phase checklists,parallel evals, interjection-resume) live in skill contracts and prepared handoffs, so they apply identically to every lane regardless of which model the chain routed there. ——MODEL_OPTI.md简单说并行评估 多个评估单元同时跑每个单元独立产出最后统一汇合验证。它不是让多个模型同时回答再投票而是一条条有边界、有验收标准的真实工作流。并行之前先划边界泳道拆分四步法 交叉检查的前提是各查各的、互不干扰。ulw-work技能规定了并行的准入条件见 skills/ulw-work/SKILL.md1️⃣ 泳道必须互斥DisjointThe work touches the same files or invariants in ways that need one owner —— 需要单一负责人的工作禁止并行。规则原文Do not run two concurrently runnable lanes with overlapping write scopes; a shared file requires an ordering edge or one owner.即两条并发泳道不能写同一范围共享文件必须串行化或归一个主人。2️⃣ 每条泳道四要素齐全每条泳道必须挂上验收标准acceptance criteria、验证命令verification command、工人协议、审查负责人。缺一项就不允许派发。3️⃣ 依赖拓扑先行裁决先裁决dependency_topology共享不变量的工作收敛到单一负责人可拆分但有序的单位加无环依赖边独立单位组成依赖就绪的并行前沿。完整纪律见 skills/ulw-work/references/dependency-topology.md。4️⃣ 路由后才派发Hermes 原生泳道在派发前必须用omh_delegate_route指定模型与推理档位标注为 inherit 的未路由波次视为无效。上图是一个真实的 ultrawork 并行会话研究泳道Lane R1/R2与实现泳道并行推进底部 HUD 实时显示各泳道的模型、token 用量与运行状态——每个并行评估单元都看得见、算得清。交叉检查审查与验证为什么必须互相核对这是整套机制的精髓也是新手最容易忽视的一环。并行带来速度也带来两类新风险泳道自报完成但没验证以及下游轻信上游的结论。oh-my-hermes 用三条规则交叉堵死️ 验证汇流Verification Fan-inEnd every code-changing run with averification fan-in that depends on all producer lanes, runs the repositorys real test/build command, and reports captured binary pass/fail output;downstream consumers re-check upstream claims before trusting them.翻译过来所有会改代码的运行结尾必须有一个依赖全部生产者泳道的验证汇流节点跑仓库里真实的测试/构建命令只汇报通过/失败这种二元输出下游消费者在信任上游声明之前必须先复核上游的声明。这就是交叉检查——不是审查方单方面下结论而是验证方拿着真实命令的输出反过来核对审查方的说法。 有界验证Bounded Verification既不少验也不狂验MODEL_OPTI.md 指出Agent 失败的两种主导模式正好相反——跳过验证和在验证上打转。OMH 用一条有界规则同时反制恰好一次完整验证既是下限不许跳过也是上限标准通过后禁止再验最多两轮修复再验证仍不过就如实汇报失败的标准项审查角色单位另有两条上限阻塞绑定验收标准最多两轮审查。⚖️ 审查是门不是摆设ulw-work明确规定Run code-review as agateafter implementation evidence exists;review preparation alone is not review evidence.审查是实施证据出现之后的门禁仅仅准备好审查不等于审查证据。审查方与验证方各自留痕、互相引用任何一环只写已准备、未观察prepared_not_observed都会被如实标注而不是被当成完成。证据链从派发到交付谁说的都算数吗交叉检查之所以可信是因为每一环都有可观察证据。skills/ulw-work/SKILL.md 的完成清单要求证据环节要求派发前泳道已路由、验证命令已附、风险扫描omh handoff-risk-scan --strict通过运行中Worker ACK、dispatch、result 状态可查阻塞泳道保持 blocked/not_observed审查后集成验证必须在泳道结果之后运行才能宣称完成交付时用户真实界面被实际演练过QA 资源有清理回执收尾时结尾必须是观察到的omh_run_summary耗时/token或明确的 not_available 声明——绝不允许模型估算数字注意最后一条连花了多少 token都只认宿主实际记账模型自报的数字一律不算。这与交叉检查是同一种哲学——任何声明都要有外部可核对的证据背书。右侧控制平面日志完整记录了 ultrawork 的一次运行轨迹verify outputs→verify success→handoff_prepare→deliver all_nodes_complete——验证、审查、交付逐条落盘交叉检查过程全程可回溯。泳道看板并行状态一屏看全并行评估的另一半是看得见。oh-my-hermes 的 HUD 看板把每条泳道做成独立泳道行模型、推理档位、token、缓存命中率、turn 数一目了然阻塞的泳道会标成红色不会假装在跑。这正是交叉检查的延伸状态本身也要交叉核对——HUD 显示running不代表泳道真的 ACK 了技能文档要求不要读出沉默即停滞的节点要检查返回输出。总结交叉检查是并行的安全带 回到标题的问题——审查与验证为何交叉检查一句话并行让自报完成的成本变低而交叉检查让虚假完成的代价变高。oh-my-hermes 的并行评估机制由四层组成拆得开泳道互斥 依赖无环从结构上避免写冲突验得准恰好一次有界验证 全量生产者的验证汇流审得真审查是证据之后的门禁准备不等于证据留得住派发、ACK、审查、CI、合并每环留痕数字只认宿主记账。想深入这套机制建议按顺序阅读skills/ulw-work/SKILL.md —— 并行泳道与验证汇流的完整纪律skills/ulw-work/references/dependency-topology.md —— 依赖拓扑裁决方法MODEL_OPTI.md —— 有界验证、模型校准与基准测量的来龙去脉docs/WORKFLOWS.md —— 全工作流总览理解并行的关键是快但让它敢快的恰恰是那份多一层核对的谨慎。【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考