人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载导读本文基于 oh-my-openagent 仓库中telemetry-parallel-latency-v2证据链的最终一环——verify-t8-repair.md——系统拆解一套完整的对抗性验证Adversarial Verification方法论当一个 Agent 任务宣称修复了仪表盘缺陷后独立的验证会话如何不信任任何转述、从零开始重新推导每一条结论最终给出confirmed裁决。读者将掌握四类可迁移的验证技术像素级矛盾核查在渲染图中验证文案一致性、三层次语义保持审计代理值 / 下界 / 直接测量三类指标不被拍平、页面高度独立测量与压力测试避免无数据态正常、有数据态裁脚的隐性回归、以及第一手管道验证不读代码注释直接跑真实流水线并核对哈希。这套方法对任何数据驱动看板 Agent 自动生成的工程质量保障都有直接参考价值。1. 背景todo 8 的两轮往返——从needs-fix到confirmed1.1 todo 8 做了什么todo 8见 task-8.md在仓库外的本地 skill 目录~/.agents/skills/omo-native-telemetry/中完成了三项改动文件改动templates/unified_model.py新增PARALLELISM_COLS13 列、hms()时长格式化、build_parallelism()视图模型并把plm接入build_modeltemplates/build_unified.py新增.g21卡片对原生工具调用并行度 eval 分桶/数据质量body{height}从 2580px 调至 3060pxSKILL.md事件 schema 从 7 个扩到 8 个新增parallelism_summary完整文档块与测量而非猜测的高度测量流程核心目标是给 OmO 的遥测看板增加一张原生工具调用并行度卡片它基于parallelism_summary事件用实测定时戳的跨度Σdᵢ − span直接测量并行带来的时间节省而不是沿用上一张卡片同秒派发推定为下界的间接估计。1.2 第一次验证needs-fix独立的验证会话 verify-t8.md 对 todo 8 的数据路径全部复核通过13/13 列映射、零None渲染、诚实标签、sum/sum 比率但拒绝confirmed给出两个缺陷DEFECT-1阻塞build_unified.py:188在병렬 실행 × 캐시卡片上仍渲染일반 툴콜/eval 병렬도는 여전히 미계측工具调用/eval 并行度仍未埋点而这句文案上方约 600px 处就是新加的、恰好测量该项的卡片——同一张图里两句互相矛盾的话。作者改对了 SKILL.md 里的对应句子却漏掉了像素。DEFECT-2证据准确性task-8 证据文件 Risks 第 1 条声称run_dashboard.py仍硬编码--window-size1080,2150、会静默产出被裁掉 910px 的 PNG。但验证者 grep 发现2150出现 0 次高度早已改为从生成的 CSS 中解析line 59并传给 Chromeline 68实跑--no-upload输出render_height: 3060。证据文件记录了一个与现状不符的事实。1.3 修复与再验证本文主体作者修复了 DEFECT-1替换矛盾文案保留三层语义与 DEFECT-2划线标注而非删除风险记录随后进入本文关联文档 verify-t8-repair.md 所记录的独立再验证。验证会话坚持一条原则每一条结论都亲手重新推导不读任务 transcript。最终裁决confirmed置信度 0.92。2. 像素级矛盾核查矛盾真的从画面里消失了2.1 验证设计不信任转述重建全部状态验证者没有使用作者的临时目录作者已删除而是自己重新跑了一遍完整链路$ cd ~/.agents/skills/omo-native-telemetry/scripts python3 fetch_data.py /tmp/av8-data ... 41 json files, real 0m7.911s, FETCH_EXIT0 $ cat /tmp/av8-data/parallelism.json [[0, null, null, null, null, null, null, null, null, null, null, null, null]] $ cat /tmp/av8-data/parallelism_daily.json [] $ uv run --with numpy --with polars --with scipy python3 growth_analysis.py /tmp/av8-data PARALLEL x CACHE (users delegs3, n433): rho0.197 p4e-05 | cache 87.0% vs 82.7% OK growth_stats.json written GROWTH_EXIT0注意两个关键数据形态parallelism.json在无数据时返回的是[[0, null × 12]]——一行全 null而不是空数组。这是代码特意防御的一行 null 陷阱见 task-8.md 中build_parallelism()的sessions门控。验证者同时构造了自己的合成数据412 会话、9,134 次往返、4.812e6 ms 模型节省等覆盖有数据的更高状态。2.2 三层证据链源码 grep → 双态渲染 → 像素读取$ python3 build_unified.py /tmp/av8-data - html written 12604 $ python3 build_unified.py /tmp/av8-synth - html written 12522 $ grep -c 미계측 /tmp/av8-data/index_unified.html /tmp/av8-synth/index_unified.html /tmp/av8-data/index_unified.html:0 /tmp/av8-synth/index_unified.html:0 $ grep -rn 미계측 ~/.agents/skills/omo-native-telemetry/ 排除 __pycache__ (no matches, exit 1) $ grep -c 미계측 templates/build_unified.py 0随后验证者在像素里读取了覆盖三张卡片的裁剪图CSS y 1330–2440 区间병렬 실행 × 캐시卡片的脚注逐字为이 카드의 병렬도는 위임 배치 비율 대리치 · 바로 아래 절감치도 위임 배치만의 하한이고, 일반 툴콜/eval 병렬도는 맨 아래 실측 스팬 카드에서 직접 측정本卡并行度是委托批次占比的代理值紧邻下方的节省值也只是委托批次的下界通用工具调用/eval 并行度在底部实测定时戳卡片中直接测量。新卡片标题在合成数据态换行为两行모델 추정 절감1.3시간· 라운드트립 9,134회。底部.g3行与页脚两行在 3060px 画布内完整绘制、下方留白。结论미계측从模板、SKILL.md 与两份渲染 HTML 中同时消失矛盾在像素层面真实消除且是独立验证而非转述。3. 语义保真代理值 / 下界 / 直接测量三 claim 未被拍平修复最容易犯的错是把矛盾句改成一句模糊的废话——用含糊换取一致。验证者专门审计了这一点确认作者用删除精度的方式买修复Claim屏幕上出现的位置原文措辞PROXY代理值병렬 실행 × 캐시脚注이 카드의 병렬도는 위임 배치 비율대리치LOWER BOUND下界同一脚注 新卡脚注바로 아래 절감치도 위임 배치만의하한 / 위 카드의 위임 배치 절감은 동일초 디스패치로 추정한하한DIRECT MEASUREMENT直接测量同一脚注 新卡脚注일반 툴콜/eval 병렬도는 맨 아래 실측 스팬 카드에서직접 측정 / 이 카드는 툴콜별 실측 시각으로 계산한직접 측정치三个术语대리치 / 하한 / 직접 측정치两两不同且两张脚注反向互相引用无论读者先落到哪张卡都能学到同一个层级关系。SKILL.md 的散文同样保留了三分法——line 94-96 讲 proxyline 114 强制要求标注 Always label this a LOWER BOUNDline 116-118 说明 the DIRECT measurement counterpart ... not a proxy。这个三分法不是文案修辞它对应仓库中的真实计算路径详见第 6 节委托批次占比卡来自batch_size_bucket交叉分析代理指标、同秒派发节省卡是显式下界、而parallelism_summary卡片基于 savings-math.ts 中的跨度公式做直接测量。三层各司其职语义精确到不会被误读为同一个东西的三种说法。4. 高度测量3060px 是否真的安全——独立测量与压力测试4.1 为什么不能直接看截图判断CSS 是height:3060px; overflow:hidden——窗口被裁剪后超出的内容根本不会露出破绽。验证者先把自己的探针 HTML 改成height:4200px; overflow:visible仅探针副本原始文件未动再以 DPR 1 渲染从底部逐行扫描与画布背景色(245,244,237)不同的最后一行$ CHROME --headlessnew --disable-gpu --hide-scrollbars --force-device-scale-factor1 \ --window-size1080,4200 --screenshot/tmp/av8-probe-{data,synth}.png \ file:///tmp/av8-{data,synth}/probe_unified.html data: image 1080x4200 bg(245,244,237) last_non_bg_row2988 content_bottom2989 synth: image 1080x4200 bg(245,244,237) last_non_bg_row3036 content_bottom3037状态作者声称验证者实测匹配无数据29882988最后非背景行精确有数据合成30363036最后非背景行精确最终交付渲染body{height}:3060、DPR 2扫描结果无数据态内容底部 CSS 2981.5余量 78.5px、有数据态 3029.5余量 30.5px。作者声称 79.0 / 31.0验证者得到 78.5 / 30.5——差异仅半像素扫描粒度同一测量。3060 覆盖更高的有数据态剩余约 24 行余量。4.2 压力测试用极端值验证不可达与其猜测 31px 余量够不够验证者直接强迫标题生长# 10 位数字的往返次数 headline: 모델 추정 절감 i1.3시간/i · 라운드트립 9,876,543,210회 extreme-long-number state: content_bottom3037 (3060 slack 23) # 所有字段同时灌入荒谬量级 headline: 모델 추정 절감 i277,777.8시간/i · 라운드트립 9,876,543,210회 eval 버킷 i222,222,221개/i absurd-max state: content_bottom3037 (3060 slack 23)两个极端都停在 3037仅比真实的有数据态高一像素。原因有两层标题被卡片宽度限制在最多两行换行hms()把所有时长压缩为至多{n,.1f}시간的形式见 task-8.md 中的hms()实现秒级{s:,.1f}초、分级{s/60:,.1f}분、小时级{s/3600:,.1f}시간任何可达的数据值都不可能让标题长出第三行。作为对照验证者还人为注入第三行标题测量如果发生会怎样3-line headline: content_bottom3085 vs 3060 - CLIPS by 25结论非常精确更长且真实的数据标题不会裁剪数据路径产生不了第三行但更长的文案编辑人工给标题或副行加约一行文字会裁掉约 25px。因此 31px 余量对数据变化是充分的、对未来文案编辑是偏薄的——这正是作者证据文件中风险 #2 的内容且已指向下一位编辑者重新测量的流程。可接受而非缺陷。5.run_dashboard.py第一手验证不止是看代码DEFECT-2 的修复主张是run_dashboard.py已改为从 CSS 解析高度。验证者没有停在读代码而是做了三层独立确认5.1 哈希钉住版本$ shasum -a 1 ~/.agents/skills/omo-native-telemetry/scripts/run_dashboard.py 45157b5b266c48e79e0c593cf128e7f35cdba363 run_dashboard.py # 与钉住的 sha1 一致 所有运行结束后再次校验仍为 45157b5b... — 未被动过5.2 源码路径逐行读取$ grep -c 2150 run_dashboard.py 0 $ grep -n window-size\|height run_dashboard.py 59: m re.search(rbody\s*\{[^}]*?height:(\d)px, html) 61: fail(render_height, 1, fno body height found in {datadir}/index_unified.html) 62: height int(m.group(1)) 63: out[render_height] height 68: f--force-device-scale-factor2 --window-size1080,{height} 流程一目了然line 58 读取 HTML → line 59 正则解析高度 → line 60-61 解析失败时fail()直接报错没有静默回退常量→ line 62 赋值 → line 63 导出到 JSON → line 68 插值进 Chrome 的--window-size。5.3 真实流水线实跑禁用上传$ python3 run_dashboard.py --data-dir /tmp/av8-pipe --no-upload { data_dir: /tmp/av8-pipe, channel: 1492525609778417834, ts: 2026-08-16T18:19:100900, queries: 41, stats: { n_users: 683, gini: 0.743, top10_share: 57.8, parallel_cache_rho: 0.198, parallel_cache_p: 3e-05, lift_top: {label: 턴 50 실행, rr: 2.3, ret_did: 88.1, ret_not: 38.4} }, render_height: 3060, png: /tmp/av8-pipe/dash_unified.png, discord: { skipped: true } } PIPELINE_EXIT0 $ sips -g pixelWidth -g pixelHeight /tmp/av8-pipe/dash_unified.png pixelWidth: 2160 pixelHeight: 6120 # 3060 x 2DPR 2——匹配 CSS而非过时的 2150那会是 4300render_height: 3060、EXIT0、sha1 未变——三项全部第一手确认。至此DEFECT-2 所担心的Discord 管道静默投递被裁剪 PNG在今天的代码状态下不会发生。6. 无附带损伤数据路径仍然成立修复不能只修表面。验证者对先前验证verify-t8已确认的数据路径做了回归确认确保修文案没有碰坏算数据。6.1 13/13 列映射依旧精确验证者通过解析fetch_data.py中的真实查询而非读散文推导出列映射query columns: 13 0 sessions 4 waves_multi 8 incomplete_calls 12 upper_bound_saved_ms_ref 1 saved_round_trips 5 joined_calls 9 clock_anomalies 2 modeled_saved_ms 6 eval_only_waves 10 dropped_calls 3 waves_total 7 mixed_waves 11 measured_turn_ms PARALLELISM_COLS: 13 MATCH: True13/13、顺序完全一致、与unified_model.PARALLELISM_COLS位置一一对应。PARALLELISM_COLS的这 13 个字段对应parallelism聚合查询的 13 个sum()列sessions为count()其余为各指标累加注意查询比任务简报列的 11 个多出尾部两个measured_turn_ms与upper_bound_saved_ms_ref——从源码读而非从简报猜这正是读源码纠正规格的典型例子。6.2 零渲染None/null/NaN$ grep -io none\|null\|nan\|undefined /tmp/av8-{data,synth}/index_unified.html | sort | uniq -c 1 none (每个文件各 1 处) $ grep -o .\{30\}none.\{30\} ... 633.5,76.2 640.0,76.9 fillnone stroke#141413 stroke-widt唯一命中是迷你趋势图 SVG 的fillnone属性——不是渲染文本。验证者肉眼检视的裁剪图里None/null/NaN字形为零。这与build_parallelism()的门控逻辑互为印证sessions 0时返回{has_data: False}占位对象任何None都无法进入格式化路径。6.3 诚实标签仍然在屏标题明示模型估计모델 추정 절감 1.3시간 副行측정된 벽시계 시간이 아니라모델 추정치 第 3 行턴 측정시간 대비모델 추정절감上界从不做标题仅以 kvrow 상한 참고치 (상한, 헤드라인 아님)5.4시간出现在副卡eval 桶保持独立行eval 단독 웨이브 1,842개、eval 혼합 웨이브 963개各自成行绝不并入waves_total51,204或joined_calls21,940。6.4 仓库未被触碰所有运行前后git status --short均为空——本裁决文件是唯一新增。7. 源码级原理这三层指标在仓库里如何计算看板文案的三分法代理 / 下界 / 直接测量在 oh-my-openagent 仓库源码中各有对应实现均位于 packages/omo-senpi/src/components/telemetry/。理解这些实现才能理解验证者为何把语义保留当作硬性验收项。7.1 直接测量modeledWallclockSavedMs Σdᵢ − spansavings-math.ts 的文件头注释直接解释了为什么不能用max(duration)重叠波并不保证同时启动链式波A 0-5B 4-9C 8-12现实中耗时 12ms跨度公式报告节省 2ms而max变体报告 9ms——4.5 倍夸大。真正同时的批次spanMs max(duration)诚实的批次数字不变。实现上modeledWallClockSavedMs返回带label: modeled的类型第 31-34 行定义了ModeledSavedMs/UpperBoundSavedMs两个不同标签的返回类型upperBoundSavedMs只走(N-1) * mean并标记为upper_bound——类型层面就杜绝了把上界当测量值传递。7.2 波的定义与并发度区间图连通分量 sweep-linewave-assembler.ts 定义了波波 区间图连通分量groupIntoWavesline 102-119按startMs排序后合并所有区间重叠的调用链式执行A 与 B 重叠、B 与 C 重叠、A 与 C 不重叠仍算一个波spanMs maxEnd − minStartline 130正是节省公式需要的真实流逝窗口savedRoundTrips用maxConcurrency而非N−1链式波有 3 个调用但从不并发超过 2只省 1 次往返sweepMaxConcurrencyline 139-154用起止边界排序做 sweep-line 求峰值并发——这正是 SKILL.md 文档中sweep-linemaxConcurrencynotN−1的源码出处MAX_TRACKED_CALLS 2000line 16进行中调用与已完成配对之和的上限超限的 start 记入droppedCalls——这就是看板上드롭 콜计数器的来源也解释了드롭 콜은 세션 상한 초과 때만 발생的注释。7.3 eval 分桶为什么是分桶而不是过滤eval-classifier.ts 的头注释说明了设计决策把 eval 调用从混合波中剔除后重算剩余部分会缩小波跨度、虚增表观节省实测1.20s 被报成 0.70s所以mixed波单独记录绝不并入non_eval。实现上classifyWaveBucket按工具名eval、codemode、code_mode把波分为eval_only/non_eval/mixed三类WAVE_SIZE_BUCKET_MAXIMA [1,2,3,4,8,16,32]line 32构成 8 桶位置直方图。SKILL.md 文档中还记录了直方图的 64 字符截断隐患带标签形式最坏 69 字符会被静默截断位置形式 39 字符安全——这些细节都被第一次验证逐条对照过源码见 verify-t8.md 第 7 节。8. 证据诚实性风险如何被记录而非抹除验证者专门审计了证据文件本身的态度——因为 DEFECT-2 本身就是证据文件记录了一个假事实。task-8.md 的 Risks 第 1 条现在被~~删除线~~划掉并就地注解而非删除RESOLVED — no longer a risk.已解决——不再是风险。本文件首次撰写时该缺陷真实存在。它被交给独立通道、在那里修复、并已验证……记录而非删除好让历史保持诚实。关键点在于原始缺陷文本包括当时错误的--window-size1080,2150和静默投递被裁剪 PNG的后果推演在删除线下仍然可读。验证者确认声明的序列发现 → 当时真实 → 独立通道 → 修复 → 验证与其在 §5 独立确认的事实完全吻合——没有任何内容被悄悄擦除。这是对抗性验证的一个容易被忽略的维度证据文件的可审计性本身就是验收项。一个把已发现的风险改成从未存在的证据链会让后续所有读者失去对历史判断的信任。9. 验证工程的其他实践细节9.1 非阻塞观察Not blockersSKILL.md:199 携带过期的示例数字2967px empty vs 3021px populated是重开前的旧值与证据表中的 2974/3022 都不符。但该条目的规范性内容——populated 比 empty 高所以要测量最高的变体——仍然成立2988 3036且 line 194 的已发布常量unified is now 3060正确。属于文档小瑕疵不影响任何渲染。约 31px 的有数据态余量对文案编辑偏薄对数据变化充分§4.2 已证明。已记录为作者证据中的风险 #2并指向重测流程。两条均非待验证修复的缺陷因此不阻塞confirmed。这个区分blocker vs non-blocker是验证裁决质量的关键观察到的每个异常都要记录但只有影响正确性的才阻断。9.2 清理收据与进程卫生删除本会话创建的全部/tmp目录与探针 PNGav8-data、av8-synth、av8-long、av8-max、av8-pipe、av8-crops及 5 张 probe PNG所有会话前已存在的/tmp条目原样保留刻意保留仓库外 QA 目录~/.agents/skills/omo-native-telemetry/.qa/verify-t8-repair/的四张裁剪图保证裁决中引用的路径可解析Headless Chrome 全部为一次性--screenshot调用清理后pgrep -f Google Chrome.*headless返回空用户会话前启动的交互式 Chromepid 39647保持不动。9.3 可复用的验证命令清单这套验证沉淀为可直接复用的命令序列适用于任何HTML 模板 Chrome 无头截图 像素检查类看板# 1. 取数无数据态天然是 [[0, null × 12]] python3 fetch_data.py dir # 2. 增长分析 uv run --with numpy --with polars --with scipy python3 growth_analysis.py dir # 3. 构建统一 HTML python3 build_unified.py dir # 4. 探针渲染oversized 窗口 overflow:visible底部逐行扫描 CHROME --headlessnew --disable-gpu --hide-scrollbars --force-device-scale-factor1 \ --window-size1080,4200 --screenshotprobe.png file://.../probe_unified.html # 5. 交付渲染DPR 2 目标高度 CHROME --headlessnew --disable-gpu --hide-scrollbars --force-device-scale-factor2 \ --window-size1080,3060 --screenshotdash.png file://.../index_unified.html # 6. 渲染文本卫生门禁唯一命中应为 SVG fillnone grep -io none\|null\|nan\|undefined index_unified.html | sort | uniq -c # 7. 真实管道禁用上传 python3 run_dashboard.py --data-dir dir --no-upload10. 最终裁决与结论AdversarialVerify verdict: confirmed evidence: see Commands run below — every claim re-derived first-hand, not read from the transcript repro: n/a (no defect found; the two residual observations in Non-blocking observations are documentation-only and already recorded in the authors own risk list) confidence: 0.92todo 8 重开的两个缺陷被判定真实且完整修复미계측矛盾从模板、SKILL.md、两份渲染 HTML 中同时消失——验证者用自己在自己渲染上的 grep 覆盖三张卡片的像素读取独立确认三张卡片的表述互相一致且代理 / 下界 / 直接测量的三分语义用三个不同术语保留未被拍平。run_dashboard.pysha145157b5b266c48e79e0c593cf128e7f35cdba363未变、2150出现 0 次、line 59 解析高度、line 68 传入 Chrome、实跑--no-upload报告render_height: 3060且 EXIT0、PNG 2160x6120。高度2988 / 3036 精确复现3060 覆盖更高的有数据态31px 薄余量在全部可达数据极端下幸存。证据诚实性证据文件注解而非抹除过期风险陈述真实时序。无附带损伤13/13 列映射、零渲染None/null、诚实标签在屏完好、eval 桶保持独立行、仓库未被触碰。结语这套方法论对 OmO 工程质量的意义回顾整条证据链task-8 → verify-t8needs-fix→ 修复 → verify-t8-repairconfirmed最值得复用的不是任何一条命令而是三个贯穿始终的态度不信任转述验证者拒绝从 transcript 读取结论全部亲手重建数据、渲染、测量发现 DEFECT-1 靠的是看像素而非看代码发现 DEFECT-2 靠的是跑真实管道而非读风险清单。用测量替代猜测31px 余量够不够不是观点问题而是注入极端值 扫底部行 测量第三行代价的实验问题3060 的高度决策建立在无数据态 2988 与有数据态 3036 两个实测数字之上。历史诚实优先风险记录划线保留、缺陷如实标注、清理有收据——证据链的可审计性与数据正确性同等重要。对于 oh-my-openagent 这样依赖Agent 自动产出 → 看板聚合遥测 → 人工/机器复核闭环的项目verify-t8-repair.md提供了一份完整的对抗性验证范本从像素到源码、从数据到证据、从测量到裁决每一环都有第一手依据。读者可以顺着 evidence 目录 继续阅读 task-8 的完整实现与第一轮验证记录或进入 telemetry 源码 逐一核对本文引用的公式与常量。赞分享人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载相关推荐oh-my-openagent 并行延迟遥测的对抗性验证parallelism_summary 会话级发射的注册顺序约束与变异测试oh my openagent 并行延迟遥测的对抗性验证 parallelism_summary 会话级发射的注册顺序约束与变异测试 本文围绕 oh my o人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排遥测仪表盘对抗性验证实战omo-senpi 原生工具调用并行度卡片如何从 needs-fix 走到 confirmed遥测仪表盘对抗性验证实战omo senpi 原生工具调用并行度卡片如何从 needs fix 走到 confirmed 本文以 oh my openagent人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排OmO 并发波组装器Concurrency Wave Assembler对抗性复核实录MAX_TRACKED_CALLS 内存闸门修复的独立验证OmO 并发波组装器Concurrency Wave Assembler对抗性复核实录 MAX_TRACKED_CALLS 内存闸门修复的独立验证 本篇指人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考