workflow_optimization_action_protocol

道-方法 · 道层 skill 全文

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

name: workflow_optimization_action_protocol
type: Workflow（道层 / 优化循环动作纪律）
status: draft (Beta) — 2026-06-16 起草（OR-1/2/3 + 晨间③）；晋级前需在 ≥1 个真实"持续优化"循环里把本 skill 的四条耦合纪律端到端跑通（模型交替 + 兜底 + 对侧审查 + 自调整回看 + 达成度收口），过 landing_gate，证据到 bounded 以上
description: 优化循环的动作纪律（道）。收到一个"持续优化这个系统 / 持续打磨这批 backlog"的循环时，循环的产出质量不来自单个任务做得好，而来自任务之间被施加的四种耦合：按任务类型给对模型（设计/审查/深度判断→强模型，执行/重构→便宜模型）、后一个任务为前一个兜底并核验其运行效果、用对侧模型做 forbidden-read 审查、定期回看跑这个循环的工具自身要不要改；循环的收口信号锚在需求达成度而非任务吞吐量。触发场景：用户说"交替用 GLM/Opus 优化 / 下一个 agent 为上一个兜底 / 做完让另一个模型审查 / 检查 workflow 是否要调整 / 持续优化直到做完"、或一个优化 campaign 是一串相互耦合的任务而非一次性需求。机制全部委托现有 skill，本 skill 只给策略层判断。
created: 2026-06-16
version: 0.1.0 (draft)

优化循环动作纪律（模型交替 / 兜底 / 对侧审查 / workflow 自调整）

一句话

收到一个"持续优化这个系统"的循环时，让它真正在优化、而不是停在"每个任务都很忙但系统没变好"，靠的是任务之间被施加的四种耦合加上一个对的收口信号：按任务类型分模型（不是盲按序号交替）、后一个为前一个兜底并核验其运行效果、用对侧模型做 forbidden-read 审查、定期回看跑这个循环的工具自身要不要改，以及把"做完"定义为需求达成而非任务跑完。

解决的真问题

一个优化 campaign（一串改进系统的任务）天然退化成一组孤立的一次性任务：每个 worker 把自己的事做完就交差，前一个留下的"小尾巴"没人补，同一个模型的盲点一路传下去，跑这个循环的工具自身在别的东西都被优化时悄悄过时，收口时只数"派了几个任务"而不问"需求达成没"。结果是任务流水很高、系统改进很低。本 skill 用四条耦合纪律 + 一个收口信号把孤立任务串成真正在收敛的优化回路。这些纪律直接来自用户对本次 Kimi orchestration 的明确要求（OR-1/2/3 + 晨间③），原本散在一次性 launch prompt 里，不是某次臆测。

何时用 / 不用

用：一个需求是"持续优化 / 持续打磨"型的循环（一串相互耦合的改进任务，不是一个一次性大需求）；用户点名要模型交替、要下一个为上一个兜底、要做完让另一个模型审查、要检查 workflow 自身是否需调整；一个优化 campaign 的收口需要锚在需求达成度而非任务吞吐。

不用：一次性长复杂需求走 workflow_orchestrator_mode（那是单需求的派发/检测/推进机制，本 skill 是施加在一串任务上的策略层，不重复它）；改单个已注册资产走 workflow_tool_skill_evolution（那是单资产更新方法）；trivial 单步任务直接做。判据：这件事是不是"一串相互耦合的优化任务、需要跨任务的兜底和审查"——不是就别套本 skill。

核心纪律（五条，施加在循环的任务之间）

1. 模型按任务类型分配，不盲按序号交替（OR-1）

用户原话"一个任务交给 Opus，下一个交给 GLM"里的"交替"是便宜启发式，底层规则是按任务类型分模型：

• 设计 / 审查 / 深度判断 / 复杂取舍 → 强模型（Opus，channel claude:high）。
• 执行 / 重构 / 机械改动 / 批量文件操作 → 便宜够用的模型（GLM，channel claude-zai:high）。

两个连续任务都是"执行"型时，两个都给 GLM，不为了"交替"而把第二个硬塞给 Opus 烧钱。"交替"在任务类型大致设计/执行相间时自然成立，是手段不是目的。channel→模型映射与全部 worker 跑在 CC 层留痕（OR-5）的约束沿用 workflow_orchestrator_mode 的硬规则，不在此重述。

2. 前后耦合兜底：后一个任务先核验并修补前一个的"小尾巴"，再做自己的（OR-2a）

用户原话："下一个 agent 为上一个兜底（fallback）。后续任务不仅要补足前面的遗留问题，还要检查前序任务的运行效果。"

除了循环的第一个任务，每个派出去的任务有两条额外义务，写进 worker prompt：

1. 核验前序运行效果：不信前序 worker 的自报完成，先独立判它真做完没（过 landing_gate 四条件 + workflow_session_claim_audit 的 claim-vs-reality diff）。没做完就先把它当 gap，不直接做自己的事。
2. 修补前序的小尾巴：前序留下的未尽事宜（partial 完成、漏掉的边界、没接上的消费边）由当前 worker 先补上，再做自己的主任务。

机制委托 orchestrate 派发时带 --prior-phase-id，worker prompt 含"先检查前序做完 + 先定位既有成果"的 landing 三件套（这些在 workflow_orchestrator_mode 已定义）。

和 orchestrator_mode 的区别：orchestrator_mode 把"检查前序做完"当 gate（前序没做完就 block、不 advance）。本纪律把它当 repair action（当前 worker 主动把前序的尾巴补上，不是干等）。这是"兜底"二字的含义——修复，不只是拦截。

3. 对侧模型 forbidden-read 审查（OR-2b）

用户原话："一个模型（如 GLM）完成任务后，应指派另一个模型（如 Opus）对结果进行审查。"

一个任务通过 gate 后，派一个对侧模型（执行者是 GLM 就派 Opus，反之亦然）的审查 worker：

• 对侧模型：用与执行者不同的模型。理由是跨模型审查抗同模型从众偏置（同模型审自己会共享盲点，对侧模型提供真正独立的 variety，Ashby 必要多样性；接 project_subagent_conformity_finding 的"选抗从众模型"防御杠杆）。
• forbidden_read：审查 worker 的 prompt 用 --charter-forbidden-read 排除执行者的自报文件 / 成功叙事，让它独立取证、不复述执行者说法（走 workflow_session_claim_audit 的 forbidden-read 取证纪律）。
• 产出 correct / partial / wrong 判定，非 correct 必附可定位反例（走 workflow_data_check_review 的 partial 定级 + 可定位反例纪律）。

审查发现的问题不丢，进下一轮当 follow-up 任务派出去（接 workflow_orchestrator_mode 的"据可定位 gap 派 follow-up"）。

和 session_claim_audit / data_check_review 的关系：那两个 skill 提供 forbidden-read diff 和 correct/partial/wrong 定级的机制；本纪律提供"总是用对侧模型 + 总是排除执行者叙事"的策略，把机制按优化循环的需要固定下来。

4. workflow 自调整回看（OR-3）

用户原话："检查当前的 workflow 是否需要调整。"调度过程中一并评估 orchestrator 模式 / evolution workflow / 派发工具本身（以及本 skill 自身）要不要改。

触发条件是积累的摩擦信号，不是固定周期：连续多个 worker 撞同一类 hook 劫持 / 权限阻塞 / 模型不匹配 / 检测反复 FLAG，或回看时发现某条纪律在真实运行里从来没起作用，就触发一次自调整回看。

回看判定"工具自身要改"时，这个调整本身又是一个优化项，走 workflow_tool_skill_evolution 的 U0–U8 正常更新流程派 worker 完成——不亲手改（保住编排者的承重墙：主 Agent 不自己实现）。这与 workflow_orchestrator_mode 的"调整工具本身也要派 worker，你不亲自改"一致，本纪律补的是"什么时候该触发这次回看"。

5. 收口信号锚需求达成度，不锚任务吞吐（晨间③）

循环"做完"的判据不是"backlog 每项都派过 worker"，是每项服务的需求被验证达成。每个优化项的 closure 要求核验它真达到了它服务的那条需求（接 workflow_data_check_review 的"审查 claimed-done 工作真没真做对做完，回原始需求"），不是只验"有个 worker 跑过"。循环整体收口时，达成度按需求逐条标注，residual 显式留下，不靠"派完即闭"。

这是 Goodhart 防御：循环被优化的指标是需求达成（outcome），不是任务吞吐（activity）。否则循环会优化"看起来在推进"而非"真的变好"。

边界（不做什么，避免与相邻 skill 重复）

• 不替代 workflow_orchestrator_mode：那是单需求的派发/检测/推进机制（观察→派 worker→检测产物→据剩余推进）。本 skill 是施加在一串优化任务上的策略层（哪个模型 / 要不要兜底 / 要不要对侧审 / 要不要回看自身 / 何时算达成）。机制归 orchestrator_mode + orchestrate 命令，本 skill 只规定策略。
• 不替代 workflow_tool_skill_evolution：那是改单个已注册资产的方法论（三误差信号源 + U0–U8）。本 skill 纪律 4 触发它、委托它，不重写 U0–U8。
• 不替代 workflow_session_claim_audit / workflow_data_check_review：那是 forbidden-read 取证和 correct/partial/wrong 定级的机制。本 skill 纪律 2、3 组合它们 + 加"对侧模型 / 兜底 repair"的策略，不复制机制。
• 不调度执行：道 skill，只给判断。派发 / gate / evolution 的执行在术工具和被委托的道 skill。

验收标准（无上下文 agent 可自判有没有用本 skill 跑对循环）

• 循环里的模型分配是按任务类型（设计/审查→强模型、执行/重构→便宜模型），还是盲按序号交替？两个连续同型任务有没有都给同档？
• 除首任务外，每个 worker 的 prompt 有没有"先核验前序运行效果 + 修补前序小尾巴"的义务（repair action），而不只是 gate 式检查？
• 每个任务过 gate 后有没有派对侧模型、forbidden_read 排除执行者自报的审查 worker，产出 correct/partial/wrong + 可定位反例？
• 有没有在积累摩擦时回看"跑这个循环的工具自身"要不要改，且改动走 tool_skill_evolution 派 worker 而非亲手改？
• 循环收口时锚的是"每项需求达成度逐条核验"，还是"backlog 每项都派过 worker"？

任一条没做，循环就没按本 skill 跑，按 workflow_manage_unexpected 动作阶梯处理，不声称"优化完成"。

配套 skill / 工具（按名引用，道→术联动）

• 委托的道 skill（机制）：workflow_orchestrator_mode（单需求派发/检测/推进，本 skill 的策略由它的 orchestrate 命令执行）、workflow_tool_skill_evolution（纪律 4 的工具自调整走它）、workflow_session_claim_audit（纪律 2、3 的 forbidden-read 取证）、workflow_data_check_review（纪律 2、3 的 correct/partial/wrong 定级 + 回原始需求）、workflow_landing_to_production（landed 四条件）、workflow_solid_decision_review（达成度定级）。
• 委托的术（执行）：orchestrate（tools/orchestrator/，dispatch 的 --channel / --prior-phase-id / --verifier-channel / --charter-forbidden-read 分别兑现模型交替 / 兜底 / 对侧审查）、landing_gate（核验前序运行效果）、phase_skill_trace_runtime（模式B spine，orchestrate 共用）。
• 理论锚：跨模型抗从众（project_subagent_conformity_finding）、Goodhart / 误差信号可操作（project_anti_performative_diligence_methodology、project_open_loop_control_theory）。

诚实 claim ceiling / 缺口

• 证据等级 bounded（draft Beta）：五条纪律逐字抽自用户对本次 Kimi orchestration 的明确要求（OR-1/2/3 + 晨间③）+ 整夜无人值守运行（KIMI_LAUNCH_PROMPT.md §5）的真实做法 + 现有可委托的 primitive。但本 skill 的形态（提成可路由道 skill、带边界与联动边）是新的，未经作为独立 skill 在 ≥1 个完整优化 campaign 上端到端跑通。晋级 production（rules/skills/ 顶层）需 ≥1 个真实循环按本 skill 跑通模型交替 + 兜底 + 对侧审查 + 自调整 + 达成度收口五条、过 landing_gate、人确认、走 workflow_version_evolution，不在纸上拍 solid。
• 已知缺口：①尚无共生确定性检测器（optimization_action_gate 之类），不像相邻 skill 那样配确定层壳 + regulator；按 workflow_landing_to_production 的 DL-02 分步协议，配检测器是 L1 下一步，本轮 scope 不含。②"积累摩擦触发自调整回看"的触发阈值目前靠判断，未量化成机械信号（与多个相邻 skill 的"何时触发"同属未量化项）。③OR-1 的 plan 级模型交替声明（worker_channel 字段）依赖 D-ORCH 方向落地；落地前模型交替靠 CLI --channel 全局切，本 skill 的策略层不受影响。