workflow_long_multi_provider_run_protocol

Z3 全文↑ Z2 条目

道-方法 · 道层 skill 全文

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

时点提示：本页是仓内文件 rules/skills/drafts/workflow_long_multi_provider_run_protocol.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

报告元数据（frontmatter）

name: workflow_long_multi_provider_run_protocol
description: 长、多 provider（≥3）、涉及模型降级/额度受限/fallback/转向的运行（如多轮 buildout orchestration）的准备+执行纪律框架。把"每个 run 都不同的目标/输入/输出/provider 组合/降级场景"当变量、把"5 目标模型必调到、撞墙→等待→探测恢复→继续、session 状态查怎么跑非查产物、fallback 作参考但缺的目标模型必须补、GOAL 翻译忠实、检查结论回写"当跨 run 不变量沉淀。触发：要跑或要复盘一个长多 provider 运行、要防它再碰到额度降级/GOAL 翻译/检查不回写这类坑。
type: Workflow（道层 / 准备+执行纪律框架）
tier: 道
status: draft (Beta) — 2026-06-30 由 optimization domain 6 轮 run 复盘沉淀（源 V4_SKILL_DRAFT + I/J/K/L）。晋级前需：① PROMOTE-ONE 的 goal_fidelity_gate 已落地（确定层 GF2 在 r004 真实 GOAL 上 FLAG + 负对照 PASS，2026-06-30）——剩 GF4 regulator 的可定位反例待 codex:high 通道真实跑一次；② 本 skill 在 ≥1 次真实长多 provider 运行里被路由使用并留 receipt；证据到 bounded 以上再考虑摘 Beta。
created: 2026-06-30
version: 0.2.0 (draft) — 2026-07-03 Y 级更新（使用者无需改动：纯新增章节 + 证据升级，既有纪律/参数不变）：Run3 campaign 给准备纪律 2（恢复探测协议）补上首次真实运行验证（4 轮 5h 窗全记录），新增「5h 滚动窗实测行为模型」节 + CC headless 挂死修复参考；0.1.0 为 2026-06-30 初版
design_source: adhoc_jobs/context_infra_base_tooling_buildout_20260615/alldomain_design_optimization_20260620/audits/session_1e4fad1e_20260628/（SYNTHESIS_V4_SKILL_DRAFT + I_MODEL_DEGRADATION_QUOTA_METHOD + J_FALLBACK_UTILIZATION_METHOD + K_VARIABLE_INVARIANT_SKILL_DESIGN + L_RECOVERY_PROBE_PROTOCOL）

长多 provider 运行：准备+执行纪律

目标（一句话）

给一个长、多 provider、会撞额度/降级的运行，把"每次都变的部分"留给运行时填充，把"跨 run 不变的准备纪律 + 执行纪律"一次性钉住，让下一次运行不再重蹈 6 轮 buildout 踩过的坑（GOAL 把需求译丢、撞墙后没等没探测就降级、完成判据查产物在不在而非怎么跑、fallback 冒充目标模型、检查结论没回写）。

何时用 / 不用

用：要跑或要复盘一个运行，且它同时满足"长（跨多 phase/多天）"+"多 provider（≥3 个目标模型）"+"会遇到模型降级/额度受限/fallback/中途转向"。典型是多轮 orchestration buildout。

不用：单 provider 的短任务；不涉及额度/降级的一次性任务。这套纪律对它们是负担。

变 vs 不变（先认清哪些该留给运行时、哪些该钉死）

变（运行时填充，不进本 skill 的硬约束）：每个 run 的具体目标（设计/impl-prep/代码实现）、输入侧（设计阶段读需求+意义+书籍；实现阶段加 Harness Reference discovery + 真实代码 surface）、输出形态、provider 组合与档位、具体失败类型（429/529/subprocess_error/Not-logged-in/hang）、降级时机、per-route 基线、后端混跑与 fallback 链配置。

不变（本 skill 钉死的纪律）：见下面道层。

道层：判断纪律（What）

准备时（6 项；标【硬】= 不可让渡，标【建议】= 可按情况调）

【硬】模型身份预检：对每个目标模型做 no-fallback probe，记 modelUsage sidecar / stderr banner，区分"route 级"证据 vs "modelUsage 级"证据。Non-Transfer Rule：P1 阶段证到的 CONFIRMED 不自动传递到后面的工作 cell，每个 cell 自带身份证据。
【硬】额度基线 + 恢复探测协议：区分三种失败并各配策略——quota 耗尽→等待+主动探测恢复；rate-limit→cooldown+同 route 顺序重试；瞬时 infra 失败→修超时+重试。不靠订阅 UI 判断额度。恢复探测的具体机制（探测间隔/内容/恢复条件/恢复后动作）是 6 轮 run 落实最差的一块，语义设计见 L_RECOVERY_PROBE_PROTOCOL（退避 t0=5min×2 封顶 60min、双探确认、24h 升 await_user、登录失效 10min×2h 阈值）。
【硬】fallback 利用策略：fallback 产出作参考保留、不当废品；但目标模型缺的必须由目标模型本身补上，不让 fallback 顶替。substitute 产出保留并标 superseded、标"不可顶替目标模型"，目标模型恢复后 native rerun 补上。fallback 链末尾若落到 Opus（claude:high）冒充原 lane，硬阻断。
【硬】GOAL/GUIDE 翻译忠实度：用户每条显性要求逐条映射成 GOAL + GUIDE 的显式条目；举例不当穷举（"如 phase、skill、trace 等" 不能译成"恰好这三块"）；"执行方式不变"不当 batch；GOAL 与 GUIDE 不许互相矛盾。发布前独立 verifier 逐条核对给可定位反例，不通过不许派发。（这条防的是 6 轮里最承重的失效，见已知陷阱 T1/T2。）
【建议】转向旧约束继承：用户中途改主意时，新 GOAL 与旧需求全集逐条对账产"转向对账表"，旧 standing 硬约束默认继承除非明确废止（防 r004 把"13 域全派"这条旧硬约束在转向到"代码实现"时丢掉）。
【建议】过程/机制盲区扫描（5 维度）：准备检查清单除了查"结果维度"（13 域/provider 身份/检查机制），固定加查"过程维度"——GOAL 翻译忠实度 / gate 判据层级（telemetry 非 artifact）/ 检查回写闭环 / 执行粒度 / GOAL↔GUIDE 一致性，各带机械判据。

执行中（7 项）

【硬】session 状态查"怎么跑"非"产物在不在"：进程树 / 产物运动 / result telemetry / fresh probe 判 completion。zero-byte+长时长=stall，三条件（zero-byte + 超 per-route 基线 2-3 倍 + 进程树无活动）并行才判卡住。执行者不能当自己的完成 oracle。
【硬】modelUsage 非 route 级：is_error=true / tier=null / 0-turn / 0-cost 的 cell 不能当真调用（r005 反模式：生成器脚本 0-turn 产 72 文件冒充 provider 跑过）。
【硬】目标模型补缺闭环：detect 缺 → wait/poll 恢复 → 目标模型 rerun → 5 项机械验证（is_error/tier_used/model_observed/exit/markers）→ supersede substitute（不删）。
【硬】检查→修正回写闭环：检查结论作为 run 的强制修正门，run 的 claim 函数式依赖检查结论（检查判 NOT_PROVEN → run claim 上限自动降级，不许 run 自选）。防 r005 的"sub-agent 14:38 已判 NOT_PROVEN，COMPLETION_AUDIT 19:00 仍标 COMPLETE"。
【硬】claim ceiling 诚实封顶 + provider 身份证明：per-cell modelUsage/turns>0/route banner 才算调到，不靠文件存在。Non-Transfer Rule 强制每 cell 自带证据。
【建议】持续推进，触边界才停：<3 模型可用 / 需用户裁定 / 要做 live 变更，这三类才停；额度不够可减模型（用户许可范围内）+ 汇报，不静默接受 substitute 为最终。
【硬】设计先于代码：代码切片需用户显式授权。

验收标准（无上下文 agent 可自判：一次运行有没有遵守本纪律）

逐条可机械或半机械核：

AC1 身份证据到 cell 级：随机抽 3 个工作 cell，每个有 modelUsage/turns/banner 证据（非只 route 级、非 0-turn/0-cost）。抽到纯 route 级或 0-turn 当"调到"= FAIL。
AC2 GOAL 逐条映射存在：有一份"用户要求 → GOAL → GUIDE"三列对照表，且独立 verifier 核过"举例没当穷举 / 执行方式没被改成 batch / GOAL↔GUIDE 不矛盾"，给过可定位反例。无对照表或无独立核 = FAIL。
AC3 撞墙后有等待+探测记录：任一目标模型撞额度时，台账里有"等待→探测→恢复→续跑"的时间戳记录（非直接 drop 或静默降级）。直接 drop 无探测 = FAIL（除非用户当次许可减模型且已汇报）。
AC4 补缺闭环可核：被 substitute 顶替过的目标模型，恢复后有 native rerun + 5 项机械验证 + substitute 标 superseded（保留不删）。substitute 当最终交付 = FAIL。
AC5 检查结论已回写：准备/中途的检查若判某 run 部分/未证，该 run 的最终 claim 上限不高于检查结论。检查判 NOT_PROVEN 而 run 仍标 COMPLETE = FAIL。
AC6 claim 诚实：最终 claim 不超过最弱证据类（路由 workflow_solid_decision_review 定级）。

术层：检测器（How）

5 个对症检测器，按 workflow_complexity_drift_detection V1-V6（确定层壳 + 第二 agent regulator 给可定位反例）+ workflow_landing_to_production DL-02 分步落地。PROMOTE-ONE：goal_fidelity_gate 已落地（2026-06-30），tools/goal_fidelity_gate/check.py（726 行，GF1-GF3 确定层 + GF4 regulator 复用共享 regulator_adapter）。真实落地证据：对 r004 GOAL.md（已直证翻译失真）跑出 FLAG（GF2 抓到"如…等"被收成封闭穷举），无开放枚举的负对照跑出 PASS，证明会判别非"FLAG 一切"假门（tools/goal_fidelity_gate/LANDING_TEST.md）。诚实封顶：确定层 GF2 已验，GF4 codex:high regulator 接线就绪但本次未触发、其"可定位反例"待真实跑一次。其余 4 门记 backlog。

goal_fidelity_gate（PROMOTE-ONE，防 GOAL 翻译失真）：输入用户要求集 + GOAL + GUIDE，确定层壳核"三列对照表在场 + 每条用户硬要求有 GOAL 条目"，regulator（codex:high，forbidden_read 含派发者成功叙事）判"举例有没有被当穷举 / '执行方式不变' 有没有被违反 / GOAL↔GUIDE 一致"，给可定位反例，不通过不许派发。对应 AC2。
session_liveness_gate（backlog，用户#1关注点的运行时面）：运行时探活 + 卡住三条件检测 + 额度恢复探测台账核验 + 目标模型补缺闭环追踪。语义层设计已成型 = L_RECOVERY_PROBE_PROTOCOL；它是运行时监控而非静态产物 gate，落地形态是接进运行壳 + 台账可机械核（对应 AC3/AC4），列为 PROMOTE-ONE 之后的下一个。
check_writeback_gate（backlog，防检查不回写）：检查结论作为强制修正门，run claim 函数式依赖检查结论。对应 AC5。扩展 workflow_session_claim_audit 的"回写半"。
pivot_inheritance_gate（backlog，防转向丢旧约束）：转向时新 GOAL 与旧需求全集对账产转向对账表，旧 standing 默认继承。并入 workflow_requirement_intake。
lessons_accumulation_gate（backlog，防教训不累积）：每个 run 被 audit 查出的问题落 append-only 教训库，下个 run GOAL 必检带机械检测。活体证据：06-20 salience-drift 诊断未固化成门 → r004 GOAL 翻译层复发。

5h 滚动窗实测行为模型（Run3 实战沉淀，2026-07-03）

来源：buildout Run3 campaign（2026-07-02~03）经历 4 轮 Codex 5h 窗耗尽-恢复完整周期，等待→探测→恢复→续跑全程台账在 adhoc_jobs/context_infra_base_tooling_buildout_20260615/Run3/logs/dispatch_log.md。这是准备纪律 2（恢复探测协议）的首次真实运行验证。

耗尽形态：不是同时死，是各 lane 在各自下一个 turn 边界逐个撞墙（在飞 turn 不受影响继续跑完，实测有 lane 在耗尽后骑行 2 小时+并在撞墙前关域）。含义：耗尽事件后不要立刻杀活 lane，让它们骑到墙点能多收单元。
恢复形态：滴灌，非阶跃。窗口重置后容量渐进释放，准入按请求体量：tiny ephemeral 探针先通过，20KB 中量级随后，小上下文 session（~300 事件）再后，大上下文 resume（1300+ 事件）最后。实测同一时刻 290 事件的 resume 通过而 555 事件的被拒。含义：恢复后按上下文体量从小到大排复活序，让小 lane 先干活，大 lane 等口径。
重置时间讯息不可信：报错里的"try again at X"字符串可能陈旧（窗口滚动后仍显示旧时间）且有时区歧义。机械探针优先于时间预测：探针梯度 = tiny ephemeral（分钟级验证"有没有恢复"）→ 20KB 中量级（验证"有没有实用口径"）→ 真实 resume（终验），15-20min 节律循环，探通哪级做哪级的事。
失败复活要区分探针成功与复活成功：探针通过≠大上下文能进。复活后必须核「目标 lane 日志事件数在增长且尾部无 usage limit」，只看 resume 命令不报错会漏判（实测 resume 起 turn 后在首个 turn.failed 才暴露拒绝）。
CC headless 挂死修复参考（跨 run 复用）：--dangerously-skip-permissions 在 CLI 2.1.197 headless -p 下全后端挂死（native/zai/kimi/ollama-glm 一致，--permission-mode bypassPermissions/dontAsk 同挂）；wrapper 通道的通路是伪 TTY：script -q /dev/null 包裹 + cat prompt | 管道喂入 + 从 TTY transcript 抽取 JSON，落地在 tools/cli_agent/router.py（commit d0a71ebd2，含 possible_permission_flag_hang 专属 error_kind 防误诊为 provider 故障）；原生 claude 通道伪 TTY JSON 不可解析、未修，池内绕开。
provider 诊断分层法：先 raw HTTPS 直打端点（curl 级），再测 CLI 层。端点 200 OK 而 CLI 挂 = CLI 层问题，别动 key/配额/沙箱（实例：zai/kimi 端点全程健康 <2s，"provider 全坏"实为 CLI flag 挂死）。stderr 的「claude.ai connectors are disabled…」是良性横幅，成功失败都打印，禁止当失败信号。

与现有 skill 的关系（不替代，只填缺口 + 叠加）

最相关：workflow_optimization_action_protocol（策略层模型交替/兜底/对侧审查/需求达成度收口）。本 skill 是准备+执行纪律框架，叠加用。
机制委托：workflow_orchestrator_mode（派发）、workflow_session_claim_audit（取证；check_writeback_gate 扩展其回写半）、workflow_phase_framework（控制回路母体；GOAL 忠实度是其充分性误差信号的一个子项）、workflow_complexity_drift_detection（检测器 V1-V6）、workflow_landing_to_production（DL-02 晋级）、workflow_requirement_analysis_quality（GOAL 逐条映射＝需求覆盖在派发侧的延伸）。
本 skill 只填 5 个无/半覆盖缺口（GOAL 翻译 / 检查回写 / 转向继承 / 过程盲区 / 教训累积），不重写上面任何一个。

已知陷阱（全部来自 optimization domain 6 轮真实运行，非预测）

陷阱	真实表现	应对
T1 举例当穷举	用户 B2 说"如 phase、skill、trace 等"+"整体"，r004 `GOAL.md:11` 写成恰好这 3 块、丢"等"和 13 域	准备纪律 4 + goal_fidelity_gate；举例标记必须保留开放性
T2 执行方式不变当 batch	用户 B6 说"执行方式本身保持不变"（per-domain-per-provider），r005 `EXECUTION_GUIDE` 引入 provider batch、实跑 batch 覆盖 12 域	准备纪律 4 + goal_fidelity_gate；执行方式变更须显式授权
T3 目录标签≠真实模型	r004 GLM lane fallback 到 Kimi，PROPOSAL 头部仍标"GLM 5.2"，artifact-exists gate 放过	执行纪律 2/5；身份查 router.log/modelUsage 非文件标签
T4 完成判据查产物在不在	r005 COMPLETION_AUDIT 用"零缺失文件"判 5 lane PASS，实际 2 lane route FAIL + 2 lane 0-turn/0-cost	执行纪律 1/2；查"怎么跑"非"在不在"
T5 检查没回写	sub-agent 14:38 判 NOT_PROVEN，COMPLETION_AUDIT 19:00 仍标 COMPLETE（晚 5h、同 session 信息没回写）	执行纪律 4 + check_writeback_gate
T6 撞墙不等待不探测	quota 耗尽时实际都是 drop provider+caveat / 降级 medium / substitute，"主动等待刷新+探测恢复"6 轮里始终无系统机制	准备纪律 2 + L_RECOVERY_PROBE_PROTOCOL；这条是用户最核心关注点

诚实 claim ceiling / 缺口

证据等级 bounded：本 skill 是从 6 轮真实 run 的实证（好/差做法都有 file:line）沉淀的设计框架，不是已验证 skill。
5 个检测器目前只有 goal_fidelity_gate 是 PROMOTE-ONE 落地目标，其余 4 个是 backlog、尚未实现；机械判据基于实证推断，未真实跑出硬负样本验证。
准备纪律 2 的"额度主动退避探测"：原为零运行实证的设计推断，2026-07-03 起升级为 bounded——Run3 campaign 真实跑通 4 轮完整的耗尽→等待→梯度探测→恢复→复活周期（含 1 次探针假阳性的纠偏），实测参数=15-20min 探针节律 + tiny/20KB/真实 resume 三级梯度（见「5h 滚动窗实测行为模型」节）。原设计的 5min×2 封顶 60min 退避参数未按原样使用，24h 升 await_user 未触发（最长停摆 ~3h），跨 provider 泛化仍未证。
codex-019f008b assistant 侧的 GOAL 翻译过程已 DIRECT 直证（RETRO_VERIFY_3_ROOTCAUSE1_DIRECT.md）：该 session 本身就是翻译层（apply_patch 在内写盘 r004/r005/r006 的 GOAL/GUIDE），T1（举例→穷举，丢"等"）与 T2（执行方式不变→batch，机制是 GUIDE 偷偷把 GOAL 的 per-domain 松绑成"provider batch 覆盖前 12 域"）两端都在 assistant 可见 artifact 里、且 assistant 事后自认；唯动机层因 160 条 reasoning 全加密不可读。故 T1/T2「翻译在派发层发生」由 bounded 升到 DIRECT（动机层除外），goal_fidelity_gate 的对症性由此坐实。

可用资源

配套检测器：goal_fidelity_gate（PROMOTE-ONE，落地中）、session_liveness_gate / check_writeback_gate / pivot_inheritance_gate / lessons_accumulation_gate（backlog）。工具路径查 tools/INDEX.md。
恢复探测语义层设计：L_RECOVERY_PROBE_PROTOCOL.md（design_source 目录内）。
6 轮 run 实证：I_MODEL_DEGRADATION_QUOTA_METHOD / J_FALLBACK_UTILIZATION_METHOD / K_VARIABLE_INVARIANT_SKILL_DESIGN（design_source 目录内）。
道层母体：workflow_phase_framework（充分性控制回路）、workflow_optimization_action_protocol（优化循环动作纪律）。

← 返回道层 skill 索引 · 返回方法论区