企业官网建设流程全解析

• 人工智能
• AI Agent
• 代码智能体
• 多智能体
• MCP Clients
• Agent 编排

导读

本文以 oh-my-openagent 仓库内.omo/evidence/telemetry-parallel-latency-v2/verify-t1-t3.md为核心，完整还原一次"独立对抗性验证"（adversarial verification）的全过程：验证者不参与实现、只读代码与测试、用变异测试（mutation testing）与对抗输入去攻击两个新交付的遥测模块——todo 1 的并发波组装器（wave-assembler）与 todo 3 的 eval 三桶分类器（eval-classifier）。你将从中掌握：区间图波分组与扫描线最大并发度的实现原理、MAX_TRACKED_CALLS内存守卫为何会在并发到达序下失效以及如何修复、eval/mixed/non_eval 三桶分类为何禁止"剥离 eval 后重算"、以及一套可复制的"验收标准 + 变异探针 + 证据复现 + 仓库规范"验证清单，可直接迁移到你自己的功能评审流程中。

一、背景：telemetry-parallel-latency 计划与"对抗性验证"角色

在 oh-my-openagent 的 omo-senpi 包中，telemetry-parallel-latency是一组关于并行工具调用延迟/节省时间度量的遥测改造任务（todo 1～8）。其中：

• todo 1交付并发波组装器，负责把工具的 start/end 观测配对并聚合成"波"（wave）；
• todo 3交付 eval 三桶分类器，负责把波划分为eval_only/non_eval/mixed三桶，供下游并行度与节省时间指标只消费non_eval桶。

verify-t1-t3.md这份文档的角色是独立对抗性验证者（independent adversarial verifier）：既没有实现任何一个 todo，也没有修改任何源码或测试文件——所有变异操作都发生在/tmp下的临时副本上，验证后即删除，仓库中只新增了这一份验证报告本身。它针对两个提交b8078d13a（todo 1）与279a2c674（todo 3）分别给出裁决：

• Todo 1：needs-fix（需要修复）——七个验收标准中六个通过，但标准 (f) 的MAX_TRACKED_CALLS内存守卫在"所有 start 先于所有 end 到达"的并发序下失效；
• Todo 3：confirmed（确认通过）——六个验收标准全部独立复现成立，七个变异全部被杀死。

这种"实现者写证据、验证者独立复验、必要时打回修复"的双层流程，正是.omo/evidence/目录下多份verify-*.md报告的统一模式，本文聚焦于 t1/t3 这一对最典型的案例。

二、Todo 1：并发波组装器——把时间重叠的调用聚合成"波"

2.1 核心数据结构

实现位于 wave-assembler.ts。它接收带时间戳的观测记录（ToolExecutionObservation），按toolCallId配对成PairedToolCall，再按时间重叠分组为ConcurrencyWave：

export const MAX_TRACKED_CALLS = 2000 export type ToolExecutionObservation = { readonly kind: "start" | "end" readonly toolCallId: string readonly toolName: string readonly atMs: number } export type PairedToolCall = { readonly toolCallId: string readonly toolName: string readonly startMs: number readonly endMs: number } export type ConcurrencyWave = { readonly calls: readonly PairedToolCall[] readonly spanMs: number // = maxEnd - minStart readonly maxConcurrency: number }

一个值得注意的接口事实（来自 task-1.md 的记录）：senpi 事件形状ToolExecutionStartEvent/ToolExecutionEndEvent本身没有时间戳字段，因此本模块接收的是"已经由订阅者盖章到达时间"的ToolExecutionObservation，而不是原始事件——这是 todo 4 接线时必须遵守的前提。

2.2 分组算法：区间图连通分量，而不是"回合"

模块头注释与实现都强调一个关键决策：波是区间图（interval graph）的连通分量。一个调用只要与波内任何一个已有调用的[startMs, endMs]区间重叠，就加入该波，因此链式执行（A 与 B 重叠、B 与 C 重叠、A 与 C 不重叠）仍然归为一个波。groupIntoWaves先按startMs排序，再用一个reach = max(endMs)的游标判断是否开新波：

function groupIntoWaves(calls: readonly PairedToolCall[]): readonly ConcurrencyWave[] { const ordered = [...calls].sort(byStartThenEnd) const waves: ConcurrencyWave[] = [] let current: PairedToolCall[] = [] let reach = Number.NEGATIVE_INFINITY for (const call of ordered) { if (current.length > 0 && call.startMs > reach) { waves.push(buildWave(current)) current = [] reach = Number.NEGATIVE_INFINITY } current.push(call) reach = Math.max(reach, call.endMs) } if (current.length > 0) waves.push(buildWave(current)) return waves }

每个波上报两个派生量，二者都是后续节省时间公式（savings-math.ts）的输入：

• spanMs = maxEnd - minStart：波的真实墙钟跨度。之所以不用"最长的单次调用时长"max(duration)，是因为链式波下max(duration)会高估窗口——链式 A(0-5) B(4-9) C(8-12) 实际耗时 12ms，若按max(d)只有 5ms，两种公式得出的节省时间相差 4.5 倍（12-2=10 vs 9，文档中明确记为 4.5x-inflation guard）；
• maxConcurrency：用扫描线（sweepline）在 start/end 边界上累加 delta 得到峰值，同时刻的 end 先于 start 应用，因此首尾相接（一个 100ms 结束、另一个 100ms 开始）的调用不会虚增并发度：

function sweepMaxConcurrency(calls: readonly PairedToolCall[]): number { const boundaries: { atMs: number; delta: number }[] = [] for (const call of calls) { boundaries.push({ atMs: call.startMs, delta: 1 }) boundaries.push({ atMs: call.endMs, delta: -1 }) } boundaries.sort((left, right) => left.atMs - right.atMs || left.delta - right.delta) let active = 0 let peak = 0 for (const boundary of boundaries) { active += boundary.delta peak = Math.max(peak, active) } return peak }

2.3 验收标准：7 项全表

验证文档针对 todo 1 逐条复现了实现者声称的验收标准（用例 a～g），每个标准都给出了"判定性观测"与杀死它的变异编号：

2.4 被抓住的缺陷：内存守卫在"并发到达序"下失效（needs-fix）

这是整个验证报告最有价值的部分。原始实现（提交b8078d13a）的容量守卫只检查paired.length：

wave-assembler.ts:69用paired.length >= MAX_TRACKED_CALLS做门槛，但每个调用的详情先累积在pending（:73），而pending没有任何上限。

由于一个 start 只有在它的 end 到达后才会变成paired条目，所以对于"5000 个 start 先全部到达、5000 个 end 随后到达"这种恰好是遥测要测量的全并行形态，paired.length一直是 0，pending无限增长，droppedCalls恒为 0。实测：5000 starts + 5000 ends 得到tracked=5000, dropped=0，而声明的上限是 2000；2500 个无 end 的 start 则让 2500 个条目常驻内存。

这直接违反了 todo 1 声明的 MUST-NOT（"不要无限增长数组……超过MAX_TRACKED_CALLS = 2000时只保留计数器、丢弃详情"）。验收标准 (f) 之所以看起来通过，只是因为它的夹具恰好把所有 start/end 严格交错排列——这是旧守卫唯一"碰巧有效"的到达序。验证者给出的修复建议是：门槛改为paired.length + pending.size，并给pending的插入加界，同时补一个"所有 start 都在 end 之前"的 (f) 变体。

2.5 修复落地与再验证

该缺陷在后续提交791437517（fix(omo-senpi): bound wave assembler tracking across pending observations）中修复，当前仓库源码 wave-assembler.ts 的第 75 行即是修复后的门槛：

if (observation.kind === "start") { counters.observedCalls += 1 if (paired.length + pending.size >= MAX_TRACKED_CALLS) { counters.droppedCalls += 1 continue } pending.set(observation.toolCallId, { toolName: observation.toolName, startMs: observation.atMs }) continue }

其正确性论证是：start 在配对时从pending迁入paired，因此paired.length + pending.size在迁移前后是不变量，任意交错下总和单调有界。这一论证经受住了 verify-t1-repair.md 的独立再验证：

• 三个声称的数值形状全部精确复现：5000+5000 →tracked=2000, dropped=3000；2500 无 end →incomplete=2000, dropped=500；2010 交错 →tracked=2000, dropped=10，且accountedFor = paired + incomplete + dropped == observed在三者中都成立；
• 六种手工对抗到达序 + 400 次确定性 LCG 随机交错（每次 2500~4500 条观测、62% start 偏置、随机序 end）：最坏驻留详情恒等于 2000，boundBreaks=0, invariantBreaks=0，验证者未能构造出反例；
• RED 重建为真：用git show b8078d13a拉出旧门模块指向当前测试文件，精确复现11 pass / 2 fail、Expected: 2000, Received: 2500，证明两条新增测试真实钉住了缺陷，RED 不是伪造的；
• 指标逻辑零回归：链式波仍为waves=1 span=12 maxConcurrency=2；把spanMs变异为max(endMs - startMs)仍被两个测试捕获（Expected: 12, Received: 5），说明修复没有削弱 span 守卫。

对应地，当前仓库的 wave-assembler.test.ts 已包含 13 个测试，其中专门新增了"所有 start 先于 end 且超上限"（trackedCalls === MAX_TRACKED_CALLS）与"超上限的无配对 start"（incomplete === MAX_TRACKED_CALLS且paired + incomplete + dropped === total）两条用例；且git diff证实原有交错夹具零删除行，两个到达序都被套件覆盖。

2.6 对抗类别排查（todo 1）

验证者对四类系统性风险逐项排查：

• 陈旧状态（stale state）：排除。assembleWaves是纯函数，pending、paired、counters每次调用独立分配；连续两次组装互不共享——第一次会话含孤儿后，第二次的counters.incomplete === 0。
• 畸形输入：不抛异常。九条恶意记录（undefined、{}、裸字符串、数组、数字、NaN/Infinity/负时间戳、非字符串与空toolCallId）得到threw=no, malformed=7，只有唯一一对合法调用进入指标；拒绝发生在解析边界（parseObservation校验kind、toolCallId、toolName、atMs四项），坏值到不了算术层。
• 误导性成功输出：未发现。每条断言都对比手算字面量，而非从被测模块重新推导的值；(f) 是唯一的薄弱点——它并非同义反复，但其夹具形状恰好是缺陷守卫唯一能工作的到达序。
• 重复 id：配对后复用同一toolCallId会产出两条独立的配对调用（paired=2, waves=2），行为合理且不污染计数器。

2.7 一个被记录为"第四汇"的精度修正

再验证还发现一个实现者未声明的细节：完整的计数不变量应为paired + incomplete + dropped + clockAnomalies == observed——时钟异常调用从pending中移除、不进paired、只落在clockAnomalies，因此它是第四个计数汇。这是既有行为、且每个调用仍被某个计数器记录，属精度修正而非缺陷。

三、Todo 3：eval 三桶分类器——禁止"剥离 eval 后重算"

3.1 三桶契约：为什么mixed绝不能折叠进non_eval

实现位于 eval-classifier.ts。每个波恰好归入一个桶：

• non_eval—— 波内没有任何调用是 eval/代码执行工具；
• eval_only—— 波内所有调用都是 eval；
• mixed—— 两者都有。

契约的硬性要求是：并行度与节省时间指标只读non_eval桶；mixed波不允许"剥离 eval 调用后折叠回non_eval"。模块头注释给出了实测依据：把 eval 调用从混合波中剔除并重算剩余部分，会缩小波的 span 与并发度、虚增表面节省（实测：真实节省 1.20s 被报成 0.70s）。eval_only波完全排除在并行度指标之外，只在自己的字段里上报数量与总时长。

3.2 eval 工具名匹配：规范化 + 后缀匹配，拒绝误报

isEvalToolName复用了 omo-native-tools.ts（约 182-190 行）的规范化/后缀匹配器，对eval、codemode、code_mode三个名字做小写、去空白、-→_，然后精确匹配或_/://后缀匹配：

function matchesToolName(toolName: string, expected: string): boolean { const normalized = normalizeToolName(toolName) const suffix = normalizeToolName(expected) return normalized === suffix || normalized.endsWith(`_${suffix}`) || normalized.endsWith(`:${suffix}`) || normalized.endsWith(`/${suffix}`) } function normalizeToolName(toolName: string): string { return toolName.trim().toLowerCase().replaceAll("-", "_") }

几个设计细节值得注意：

• code_mode在名单中，是为了让code-mode这种拼写经规范化后能真正命中；单靠codemode匹配不到它；
• 裸ln故意不在名单里——它是过时的历史别名，有误报风险；
• 只有工具名称被读取，模块内不接触任何 cell 源码、参数或结果（隐私面最小化）。

直连探针证实：isEvalToolName("evaluate_foo") === false（后缀匹配不会命中evaluate_foo），而code-mode、mcp:eval、server/eval、tool_eval全部为 true。若把后缀匹配器换成朴素includes，evaluate_foo就会产生误报——这正是变异 N4 所钉住的回归点。

3.3 验收标准：6 项全表

non_eval聚合计数器包含四个字段：wavesTotal、wavesMulti（size > 1 的波数）、joinedCalls（波内调用总数）、waveSizeHistogram——后者是一个无标签的位置编码字符串，分桶上限为[1, 2, 3, 4, 8, 16, 32]，共 8 桶：

const WAVE_SIZE_BUCKET_MAXIMA = [1, 2, 3, 4, 8, 16, 32] as const const HISTOGRAM_BUCKET_COUNT = WAVE_SIZE_BUCKET_MAXIMA.length + 1

例如 8 个大小分别为 1/2/3/4/6/12/20/40 的波编码为"1:1:1:1:1:1:1:1"，字符串内不出现=（变异 N6 就是把它改成带标签编码而失败）。以MAX_TRACKED_CALLS = 2000为上限，8 桶每桶最多 4 位数字加 7 个冒号，最坏 39 字符，远低于 64 字符截断线，不存在溢出截断风险。

3.4 变异证明：守卫非同义反复

验证者准备了 7 个针对性变异（N1～N7），全部在/tmp/mut3-*临时副本上执行：

结论：每个验收标准至少被一个针对性变异杀死，文件中不存在同义反复断言。特别地，(f) 同时断言"与独立构造的 non_eval-only 控制组相等"和硬编码绝对值，因此不可能通过从被测输出反推期望值来蒙混过关。这一机制与 task-3.md 中记录的"把summarizeWaveBuckets变异为 mixed 落入 non_eval"的 RED 捕获（7 pass / 3 fail，Expected: 1, Received: 2）互相印证。

3.5 对抗类别排查（todo 3）

• 陈旧状态：排除。只导出纯函数，直方图数组每次调用分配；同一输入汇总两次深度相等，空输入返回全零"0:0:0:0:0:0:0:0"。
• 畸形输入：不抛、不误分类。空波、空名与纯空白名、unicode（코드）、全角Ｅｖａｌ、大小写混合EVAL、带空白eval全部被处理：空波归类non_eval且贡献 0 个 joined calls、不进任何直方图桶；全角Ｅｖａｌ小写化后不等于 ASCIIeval，正确地不被当作 eval。spanMs: NaN被durationOf的Number.isFinite守卫吸收（evalOnlyDurationMs=0，直方图完好）。
• 一个边界缺口（记录为笔记，非阻断）：summarizeWaveBuckets([{toolNames: null, spanMs: NaN}])会抛TypeError。但该输入只能通过破坏模块自身的 TypeScript 契约到达，其唯一预期生产者是 todo 1 的类型化PairedToolCall[]，计划与验收标准都不要求在这个内部接缝处防御；若未来 todo 4/6 从原始事件负载直接喂入，则必须在彼处加守卫。
• 误导性成功输出：无。(f) 的控制组来自独立的字面量数组，而非污染结果。
• 隐私：只有toolNames与spanMs穿过 API 表面，不接受、不存储任何参数、结果或 cell 源码。

四、证据复现：验证者的"数字审计"表

两份实现者证据（task-1.md / task-3.md）中的每一个数字，验证者都独立复跑验证：

最终结论：两份证据文件引用的每个数字都可复现，未发现任何不可复现的数字；唯一需要限定的是 task-1 的 (f) 行——数字本身真实，但它没有证明计划要求的不变量。

五、仓库规范与范围保真检查（diff-only）

验证文档还把这次评审当作一次"约定合规审计"：

• given/when/then 命名：rg "Arrange|Act:|Assert"零匹配；wave-assembler.test.ts使用嵌套describe("#given")/describe("#when")/test("#then")，eval-classifier.test.ts使用单行#given … #when … #then标题（第三种变体，仅作风格备注，非违规）；
• 无as any：四个文件中零出现；测试用as readonly unknown[]/as readonly ToolExecutionObservation[]喂入故意敌对的输入，属窄化转换而非any；
• 无@ts-ignore/@ts-expect-error：零匹配；
• kebab-case 文件名：wave-assembler.ts、eval-classifier.ts及其测试文件全部合规；
• 无万能 util/helper 文件名：两个模块都以单一职责命名；
• 无 emoji、无 em dash（U+2014/U+2013）：四个文件中均为 0；
• 纯 LOC < 250：wave-assembler.ts151、wave-assembler.test.ts171、eval-classifier.ts91、eval-classifier.test.ts95（修复后经 verify-t1-repair.md 复核仍为 157/204，均低于 250 上限）。

范围保真（scope fidelity）：两个提交合计恰好新增六个文件、修改零个：

A .omo/evidence/telemetry-parallel-latency-v2/task-1.md A packages/omo-senpi/src/components/telemetry/wave-assembler.test.ts A packages/omo-senpi/src/components/telemetry/wave-assembler.ts A .omo/evidence/telemetry-parallel-latency-v2/task-3.md A packages/omo-senpi/src/components/telemetry/eval-classifier.test.ts A packages/omo-senpi/src/components/telemetry/eval-classifier.ts

对两个提交的文件清单做禁止路径 grep（telemetry-core、omo-codex、omo-opencode、plugin/extensions、turn_completed）零匹配；字符串turn_completed在两个 diff 中出现 0 次。没有新增 barrel 导出——与"todo 4 负责接线"的分工一致。当前仓库的 omo-native-parallel.ts 正是 todo 4 交付的消费方，印证了这一接口接缝的存在。

六、复现与运行指南

两个模块当前都在仓库内，可直接在本仓库复现全部测试（需要 bun 运行时）：

# todo 1 波组装器：13 个用例（含两条容量守卫用例） bun test packages/omo-senpi/src/components/telemetry/wave-assembler.test.ts # todo 3 eval 三桶分类器：10 个用例 bun test packages/omo-senpi/src/components/telemetry/eval-classifier.test.ts # 整个 telemetry 组件套件（回归检查） bun test packages/omo-senpi/src/components/telemetry/ # 类型检查（tsgo 前端） bun run --cwd packages/omo-senpi typecheck

想亲手复现"缺陷被修复"的对比实验，可参考 verify-t1-repair.md 的做法：git show拉出旧门版本，把当前测试文件指向它，即可看到11 pass / 2 fail、Expected: 2000, Received: 2500的 RED；将变异（如把spanMs: maxEnd - minStart改成max(endMs - startMs)）施加到临时副本上再跑测试，即可验证测试的非同义反复性。所有变异实验请在临时副本中进行，不要改动仓库内的跟踪文件。

七、总结：从 needs-fix 到 confirmed 的完整闭环

• Todo 1（needs-fix → confirmed）：七个验收标准全部被非同义反复的测试钉住，六个成立；但标准 (f) 的MAX_TRACKED_CALLS内存守卫只对交错到达序成立——并发到达序下上限从不触发，5000 次调用对抗声明的 2000 上限被全部驻留，违反了 todo 的 MUST-NOT。修复（paired.length + pending.size门槛 + 两条新用例）后，经 6 种手工对抗到达序与 400 次随机交错的独立再验证，最坏驻留恒为 2000、零越界、零不变量破坏。当前仓库源码 wave-assembler.ts 即为修复后状态，可直接阅读核验。
• Todo 3（confirmed）：六个验收标准在独立探针下全部成立，七个变异全部杀死断言；范围、规范、证据数字全部干净。唯一遗留是一个toolNames: null时的TypeError，仅能通过破坏模块 TypeScript 契约在内部接缝到达，计划未要求在此防御。

这份验证报告的价值不在于"抓到一个 bug"，而在于示范了一套可迁移的质量流程：验收标准与手算字面量一一对应、每个标准至少被一个针对性变异钉死、每个声称的数字独立复跑、对抗类别系统性排查、范围与仓库规范按 diff 审计。当你的功能涉及内存守卫、聚合统计或"不得折叠"的语义约束时，这套"实现者证据 + 独立对抗验证"的双层评审，是让needs-fix在合并前就被发现、而非上线后才被监控报警的最短路径。

• 人工智能
• AI Agent
• 代码智能体
• 多智能体
• MCP Clients
• Agent 编排