workflow_complexity_drift_detection

道-方法 · 道层 skill 全文

本页是 <code>rules/skills/drafts/workflow_complexity_drift_detection.md</code> 的逐字投影（仅隐私清洗，零改写）。

复杂情况漂移检测与防御判断（道 skill，draft）

元数据

• 类型：Draft Workflow（道层，给 judgment，不调度执行）
• 适用场景：复杂任务执行中（需求多 / 数据密集且相近 / 单目标但路径复杂 / context 被背景污染），要给某个具体失败模式建一个能拦下它的检测门，或判断一个已有检测器的误差信号够不够格。
• 证据：bounded。两个真实 oracle 上各验证过一个检测器：F2 数字溯源（DD2525 295/600，确定性判别 6/6 + 可操作性 3/3）、F5 越界套规则（019e6345 把 enum 译成中文当分类标签，判别 5/5 + 可操作性 6/6）。跨两个失败模式复用成立；未跨 oracle 泛化、未在 live agent loop 内验证。
• 参考实例：adhoc_jobs/complexity_defense_method_20260602/detectors/f2_number_traceability/（crisp 信号）与同级 detectors/f5_boundary_rule/（soft 边界），各含 SPEC + fixtures + run_oracle + VALIDATION 全套。
• 日期：2026-06-02。

目标（一句话）

复杂情况下 agent 会锚错、无证据编结论、淹掉原作者思路、静默简化、越界套规则、漏关注点、记错数据。这个 skill 给的判断是：何时该部署检测门，以及一个检测器的误差信号怎样才算有效——可复现地判别、能定位缺陷、由第二个独立 agent 产出、用硬负样本证明不是橡皮图章。

它是「分阶段注入 / 运行期漂移检测」这一支柱的道。另两支柱各有道 skill：需求冻结走 workflow_requirement_decomposition_core，sub-agent 拆分与差异化注入走 workflow_unit_decomposition_and_context_injection。

边界（不做什么）

• 不替代需求分析（R1）或 unit 拆分（R3），它们各有道 skill。
• 不做 draft→production 的晋级判定（那是 workflow_landing_to_production），但两者的判据有交集：晋级门也要求「确定性 oracle 返回可定位反例 + 独立 verifier」。
• 不是一个 live-loop 系统。当前验证停在 artifact 级离线检测（喂产物 + source bundle，可离线复跑），不是 token 流实时拦截。
• 具体检测器（术）住在自己的目录里，本 skill 按名引用，不内联实现。

何时部署检测门：机械困惑度量（先数，别靠语感）

对任务机械计数，超阈值才上检测器 + 拆分，否则单遍即可：

• 同单位数字密度：同一单位的数字扎堆（多个「秒」「%」「条」），是编结论 / 漏数据的高发区。
• 跨域数：任务横跨几个领域（每个领域有自己的术语和不变量）。
• 等权需求条数：要同时满足几条不可互相吃掉的需求。

三项任一明显偏高 → HIGH → 部署对症检测器 + 按扰动熵拆单焦点切片。这一步本身就是「分析」，最好和「规划」分到不同 agent（边分析边规划是多焦点任务，会退化）。本 skill 诞生的任务自测就是 HIGH（数字扎堆 + 跨 6 域 + 7 条等权需求），于是走了 PROMOTE-ONE 收窄，是这条规则的第一个实例。

验收标准：一个检测器何时算「有效」（可测，逐条证）

一个检测器通过下面全部才支持 bounded 声明。任一不过，就还不算挡得住对应失败模式。

• V1 确定性判别力：存在 ≥1 真实 positive oracle 判 FLAG、≥1 negative control 判 PASS，二者由确定性外壳（无 LLM）判出、可复现（同输入同输出，exit code 反映）。可达强度随失败模式的信号清晰度分两档：crisp-signal 模式（如 F2 的算术 reconciliation 在不在）确定性壳能强判别、边界清晰；soft-boundary 模式（如 F5 同一个词「指数级」既是数学叙述又是 enum 标签）确定性壳只能用启发式语境标记做 candidate 收窄，二元判别主要落在 regulator（V3）身上。后者要如实标成「壳收窄 + regulator 判别」，不要假装壳能 crisp 判软边界。
• V2 硬负样本：至少一个 negative 保留 positive 的表面触发特征（同样的方向词 / 同样的数字），但因 trace 在场被清除。证明判别靠机制（trace 在不在），不是靠「这句恰好没触发」。没有 V2，judgment 会被「flag everything」蒙混过去。
• V3 可操作误差信号：对被 flag 的 claim，输出能定位缺陷的反例——每个量的 path:line / § 来源、正确的 reconciliation、具体 defect 类型——而不是「这很复杂」。判据：1-bit 的「有错」约等于无信号；要给出能让作者直接改的那条。
• V4 第二独立 agent：产出误差信号的 regulator 只见被 flag 的 claim + source bundle（forbidden_read 屏蔽作者推理与产物其余部分）。自己审自己不算。
• V5 通用谓词：检测逻辑是 general pattern，oracle 的具体值不进谓词。fixtures 是测试，不是 spec。硬编码具体值 = overfit。
• V6 诚实边界：通过 V1-V5 只支持「单检测器 × 验证过的 oracle」的 bounded 声明。跨 oracle 泛化、live-loop 验证、跨模型稳定，各自要另证，不许顺带声称。

方法论建议（怎么建，可按情况调整）

• 混合形态：确定性外壳（承载 V1/V2 判别，通用谓词）+ 第二 agent regulator（承载 V3 可操作性，喂 source bundle）。把可复现的判别和易漂移的 LLM 判断分开，是这套能稳的原因。
• 症状专一：一个失败模式一个检测器（F2 数字溯源、F5 越界套规则、F4 需求掉落……）。别指望一个通用检测器盖所有漂移；通用谓词指「在一个失败模式内不绑死具体值」，不是「一个检测器管所有模式」。
• trace 算多种形式：判「有没有溯源」时，path:line / § 锚点和就地 reconciliation（写出推导 / 算术恒等式 / 分解）都算 trace。只认 anchor 会误伤正确的就地推导（见陷阱 T2）。
• 综合不投票：多个判断收口时走可验证综合，不靠投票（对不可验证判断投票约 89% 从众）。regulator 的裁定要可机械核对（指向 source 行），不是多数表决。

已知陷阱（都来自 F2 这一个真实 slice）

• T1 不核验就信 oracle 描述：本 slice 的「session 开始 40 秒内写出 295<600」核验下来不成立——Cursor sqlite 只存 user 消息，错误其实在更早 session 写的 artifact 里、被粘回来更正。先独立核验 oracle，它会改检测器形态（这里从「live replay」改成「artifact 级离线判定」，反而更干净）。
• T2 naive「无 path:line 就拦」会误伤就地 reconciliation 的正确文本：更正版里有的段落没有 path:line、只有 295+295+10=600，却是对的。判别必须认 trace-in-any-form（anchor 或 reconciliation），否则正确文本被误报、判别力崩。
• T3 没有硬负样本，「flag everything」看起来像能用：橡皮图章会冒充检测力（参考 UCR 语义判官只出 1-2/3、sub-agent 4 报 1 真的 over-recall）。必须有 V2 那种保留触发特征但应 PASS 的负样本。
• T4 把 oracle 具体值硬编码进谓词 = overfit：实现通用谓词，用 fixtures 验证，不是为 fixtures 定制。
• T5 不信 builder 自报：实现交出去（Codex）后，它报 PASS 不作数。亲自重跑 + 亲读代码，才查得出有没有硬编码、regulator 隔离成不成立。完成判断必须过确定性外部检查或第二独立 agent。
• T6 把软边界失败模式当 crisp 模式建：F5（越界翻译）里同一个词「指数级」既是数学叙述又是 enum 标签，确定性壳只能用启发式语境标记近似，真正的边界判别靠 regulator 用「规则 + 规则自带判据」做。先判失败模式是 crisp 信号（壳承载判别）还是 soft 边界（壳收窄 + regulator 承载判别），再决定两者各担多少，并在 VALIDATION 里如实标 V1 的档位。

输出规格

检测器自带一个目录，含：

• SPEC.md：实现设计（检测谓词 + regulator 接口 + verdict 语义）。
• fixtures/：oracle ——≥1 真实 positive + ≥1 硬 negative（V2）+ source_bundle（regulator 唯一可见的 source 上下文）。
• 验证 harness（如 run_oracle.py）：断言确定性判别（exit code 反映 V1/V2），regulator raw 输出落 log 供人亲判 V3，不让 harness 自己给可操作性判 pass/fail。
• VALIDATION.md：bounded 声明 + 亲读亲跑记录 + 诚实残差。

regulator 后端按名引用 cli_agent 路由（第二 agent 的 LLM 通道），路径查 tools/INDEX.md。

跨域根与联系

• 可操作误差信号必须「具体反例、可定位」：来自可验证 checkpoint 实验（1-bit「有错」≈无信号）。
• regulator 必须是第二个 agent：来自开环控制（缺误差信号是支点，调控者不能是被调者自己）。
• 综合不投票：来自从众调研（可验证综合跨 harness 零从众）。
• 何时部署的复杂度门：来自需求锚定充分性架构（把无界 context 锚成有界覆盖义务）。
• 配合：第二 agent 注入纪律 → workflow_unit_decomposition_and_context_injection；检测器输出的 claim 分级 → workflow_solid_decision_review；oracle / 硬负样本 / mutation guard 设计 → workflow_real_task_test_case_design；推到 production / 判是否真 landed → workflow_landing_to_production。