智谱经常发鸡蛋又限制并发，反手开发个编排skill全部吃掉 V1.3

送3亿夜间token还限制子对话并发，可恶！反手让它自己开发一个skill，绕过主对话并发限制。居然可行，16路并发。每次送几亿每次都能给它用完。skill放在后面了，截止目前已经开发到了1.3版。

送的GLM 5.3 Flash 3亿词元按照官方闲时价格约合人民币120元左右，厂商看起来给的多，然而：

1. 只能晚上11点至次日9点使用。
2. 现在并行4、5个主对话就会碰到并发限制，一般人就算10个小时一直用也不太可能用完。 一想到自己通宵一晚上反撸了厂商大几十块，精神顿时愉悦了。

然而真的是熬夜的罪魁祸首啊，现在玩儿这些交互式的Harness有点像当年学生时代通宵玩策略游戏，UI、动效体验又好，新鲜感很多，即时反馈强的一批。

嘿嘿嘿嘿，ChatGPT+Zcode+DSH 全程并行。一晚上电脑风冷呼呼作响，内存吃满。实测用了此skill大概6个多小时就能把3亿词元全部用掉。

后台还有UU远程操作另外两台电脑里的antigravity（主要是谷歌AI Pro太便宜了，Magpie反代出来有封号风险只好每台设备分别登录一个）。

今年双11过得很寡淡，俺还是商家呢，如果老妈不提醒的话，都没意识到已经到了促销节了。

唯一想买的就是Macbook Pro M6，看了下，优惠完还是得1万4，生产力工具放纵一下？但一想到自己同时用8台电脑，再买除了能并行更多任务也没啥太大价值。

智谱Zcode Harness最大并发skill，复制保存为skill.md文件即可

name: dwf-max-orchestration description: 大规模多路并发编排的实测配方与上限纪律（CreateWorkflow fan-out）。当对话需要超过 3 路并行子代理、要测或用并发上限、要把批量任务最大化编排运筹、或需要可复制的计时/参考值对照/峰值并发/改并发配方时使用。必须先加载官方 dynamic-workflows skill——本 skill 是它的实测补充，不替代其编写合同。 version: 1.3.0
dwf-max-orchestration：多路并发编排的实测配方与纪律
本 skill 是官方 dynamic-workflows 的实测补充层：官方 skill 定义"怎么写对"（编译合同与拓扑判断）， 本 skill 提供"怎么打满"（本机已验证的并发上限数据、可复制配方、护栏纪律）。

版本与变更记录（SSOT：本文件；交接词只作入口）
v1.3.0（2026-11-13）：新增"夜间赶工模式"职责分层节（主对话=编排/裁决/汇总，细节下沉——单路串行 workflow 也优于主对话裸奔；例外三条；Cron 巡检）；事实表 +2（动态并发数=runtime 自适应放行上限 1↔天花板浮动；编排态主对话抗中断=调用形态+损失结构机理，非系统特殊保护）；陷阱 +2；交接词 +第7点。依据：四工头 run 面板对照 + HT#89 生产 3/3 爬行交付 + 飞书工头细节活被停对照。
v1.2.0（2026-11-12）：新增"状态自检"配方（GetWorkflowRun health 行为金标准 + 处置矩阵）与"黄点机理"事实行（rate_limited 爬行≠暂停死亡）；纪律 8（限流窗口内不新发大 fan-out、提 max_concurrency 无效、CreateWorkflow 必传 name）；陷阱 +1；交接词 +第6点。实例：三 run 同窗 concurrency=1/16 (rate_limited) 爬行判读。同日补：纪律 9（会话词元定时失效前先阶段性回写 GitHub + 定时自动化续任）+ 陷阱 +1。
v1.1.0（2026-11-12）：新增"主会话强制暂停"机理行与持续限流窗口实测（一句轻量提问也被拦）；纪律 6（fan-out 后冷却 + report 回收 + 持续窗口处置）、纪律 7（路内按需选档）；陷阱表 +2；frontmatter 加 version；新增交接词节。
v1.0.0（2026-11-12）：初版——已验证事实表、6 配方（只读时钟 / N路fan-out / node oracle / 峰值扫描 / amend 探测 / 报告回收）、纪律清单、陷阱速查。
先决（不可跳过）
先用 Skill 工具加载官方 dynamic-workflows。本 skill 的所有脚本片段仍受其合同约束： §16 facade、phase 阶段、类型化 ask<T>、Date.now() 禁令等以官方为准。
下表数字是 2026-11-12 在 Start Plan / GLM-5.3-Flash 上实测的。配额与限流策略会变； 复测很便宜（见"上限探测"配方，≈0 token）。
已验证事实（截至 2026-11-12）
事实	实测值	证据
Agent tool 直接并行	约 2-3 个即被拒 → 大 fan-out 一律走 CreateWorkflow	2026-11-12 前实测
16 路真实并行	peak_concurrent=16（区间扫描），启动离散仅 163ms，wall 129.5s vs 串行和 1438.3s（11.1×），16/16 成功	HT-ZCODE-DWF-LIMIT-20261112 @ dwfrun-e148049f
max_concurrency=24	配置层接受（启动回执原文 "At most 24 subagents run at once"），2 路缓存回放 ≈0 token	HT-ZCODE-DWF-CANARY-20261112-CONC24-PROBE @ dwfrun-bb632702
>16 的实际并行度	未测——不要把"24 被接受"外推成"24 路真并行"	—
Flash$max 单路微任务耗时	2 路无争抢 28.7/61.9s；16 路争抢下单路 23.2~129.5s	同上两次实验
模型路由	account:bigmodel-start-plan/GLM-5.3-Flash$max（档位 low/high/max，$max=最高思考）	ListModels
provider 限流语义	限流/过载/网络错误由 runtime 无限自适应重试，不进脚本；确定性错误（配额 cap、sign-in 过期）→ run 停为 stopped(provider)	官方合同 §16.3
主会话强制暂停（新机理）	主会话模型与子代理共用同一账户配额：大 fan-out 结束后账户在限流窗口内，主会话轮可被"系统繁忙"拒绝，自动重试打满后交互轮被强制停止——workflow run 不受影响（台账 12/12 completed）。实测：16 路 ≈266k tokens/2min 后主会话连续被拦；当日累计高消耗后一句轻量提问也被拦（限流窗口可为持续型，非仅瞬态）	2026-11-12 Start Plan 横幅截图 ×3 + 运行台账
黄点机理（running 却近乎不动）	spent_tokens=0/停滞 + 子代理 waiting for a slot + health 行 concurrency=1/16 (rate_limited) 三联征＝限流窗口内以 1/16 爬行，活着非暂停；possibly_interrupted=true 只是跨会话读取的常态注记，非死亡判定；限流时瓶颈在 provider，提 max_concurrency 无效	2026-11-12 三 run 同窗实例（GetWorkflowRun health 行）
动态并发数（面板"最大并发数"浮动）	运行面板显示的"最大并发数"＝runtime 自适应的当前放行上限，随 provider 配额浮动（实测 1→2→3；HT#89 生产 run health 长期 concurrency=1~3/16 (rate_limited)）——配置的 16 只是天花板；限流时压到 1、窗口打开自动回升，无需人工干预	2026-11-13 四工头 run 面板（千牛/微信/OCR/runner 均"最大并发数 1"仍持续推进）+ HT#89 dwfrun-c237b79f
编排态主对话抗中断（Human 观察）	机理＝调用形态改变+损失结构改变，非系统特殊保护：①run 在跑时主对话大多空闲等待（零调用=零暴露面）；②唤醒轮（发 run/收通知/裁决）少而小，单轮存活率高；③即使某轮被停，run 状态在 runtime 手里（journal+report 落盘）零实质损失。对照：主对话亲自干细节活=长轮大调用，被停即全轮作废	2026-11-12~13 对照：飞书工头改 build_oci.py 中途被停 vs 三工头 workflow 爬行持续推进；HT#89 主会话停两次、workflow 3/3 交付
配方库（复制即用，均已实测编译通过）
1. 只读时钟（脚本内禁 Date.now()）

ts
// epoch 毫秒；node 子进程读取，单次精度 ±0.1~0.3s，时长按同法相减有小幅高估
async function clockNow(): Promise<number> {
  const r = await world.run("node", ["-e", "process.stdout.write(String(new Date().getTime()))"]);
  const v = Number(r.stdout.trim());
  return Number.isFinite(v) ? v : -1;
}
2. N 路同时 fan-out（每路独立 agent + 计时 + 随到随报）

ts
phase("N路同时发起");
const records: LaneRecord[] = await Promise.all(
  Array.from({ length: N }, (_, i) => {
    const ag = agent(`并发路-${i}`, { system: PERSONA, budget: { webSearch: 0 } }); // 计算名必须唯一
    return (async () => {
      const startedMs = await clockNow();
      let ok = true;
      let error = "";
      let result: LaneResult | null = null;
      try {
        result = await ag.ask<LaneResult>(`第 ${i} 路任务…只返回 JSON。`);
      } catch (e) {
        ok = false;
        error = String(e); // 只捕逻辑/校验失败；provider 错误本就到不了脚本
      }
      const endedMs = await clockNow();
      const rec: LaneRecord = { lane: i, ok, error, result, startedMs, endedMs, durationMs: endedMs - startedMs };
      report(rec); // 随到随报：中途失败也能回收已完成的路
      return rec;
    })();
  }),
);
要点：phase 标记放外层，绝不放进 map 回调；纯推理路用 persona 文字禁工具 + budget:{webSearch:0} 双保险封死；ask<T> 带 JSDoc 字段注释。

3. node 确定性参考值（Oracle）+ 全等校验

ts
const oracleRun = await world.run("node", ["-e", "process.stdout.write(JSON.stringify({expected:…}))"]);
const oracle = JSON.parse(oracleRun.stdout.trim()) as { expected: number[] };
// 逐路全等比对 value/nonce；绝不把期望值写进路内 prompt（否则考题作废）
十进制精确和用 BigInt 缩放（(2500n+7n)/1000n+余数补零），字符串去重用 Array.from(new Set(ids))， 大数一律按字符串处理（2^53+1 转数字即失真）。

4. 实测峰值并发（区间扫描）

ts
const events = records.flatMap((r) => [{ t: r.startedMs, d: 1 }, { t: r.endedMs, d: -1 }]);
events.sort((x, y) => (x.t - y.t) || (x.d - y.d)); // 同刻先减后加：相接不算重叠
let cur = 0;
let peak = 0;
for (const e of events) { cur += e.d; if (cur > peak) peak = cur; }
并发成立的硬证据：wall_ms ≪ serial_sum_ms（并行加速比 = serial/wall），start_spread_ms 小。 反"缓存复用"旁证：各路 end 时钟值互不相同 → 每次时钟读取是真执行。

5. 上限探测 / 改并发（≈0 token）
在途 run 提速：AmendWorkflow(run_id, max_concurrency=N)（仅这两个字段）→ 原地改，不停不重跑。
已完成 run 探测配置接受性：同样只传 run_id + max_concurrency → 新 run 从缓存回放， ≈0 token 即返回；被拒则保留原始错误，什么都不创建。
权威值看启动回执原文（"At most N subagents run at once"）。陷阱：脚本 return 里的 max_concurrency 字段是脚本常量，settings-only amend 后仍是旧值——回执才是运行真相。
提值时传 name 改显示名，避免与原 run 混淆。
6. 报告与回收
report(rec) 随到随报（失败也能送达）；终值 return 用 report shape： conclusion / findings / verified / notCovered。
verified 只写真正决定结果的检查（如"node oracle 全等比对"）；没测的写进 notCovered。
7. 状态自检（黄点 / 疑似卡死的三步判读）

text
① ListWorkflowRuns → 看四列：status / spent_tokens / possibly_interrupted / updated_at。
② GetWorkflowRun(run_id) → 金标准是 health 行：concurrency=X/16 (rate_limited since …)、
   subagents 的 executing / waiting for a slot、last_progress、stalled、consecutive_failures。
③ 按处置矩阵行动：
   - rate_limited + waiting for a slot + last_progress 新鲜 → 活着在等 provider 配额：
     等窗口，不要停、也不要提并发（瓶颈在 provider，max_concurrency 无效）；
   - running 但 last_progress 很旧 + stalled=yes → 查 hole/channel（GetWorkflowRun 列 pendingQuestions）；
   - stopped(provider) → 修因（配额窗口/sign-in）后 ResumeWorkflowRun；
   - stopped(user) → 先问人再 Resume；
   - possibly_interrupted=true → 跨会话读取的常态注记；结合 health 判断，owning 进程真退出才 ResumeWorkflowRun。
判读实例（2026-11-12）：三个 run 同窗齐显 concurrency=1/16 (rate_limited)，两个 spent_tokens=0、 一个 8.68M，子代理 waiting for a slot 2min+——全部活着（last_progress 1~2.5min、stalled=no）， 黄点＝限流爬行，不是暂停死亡。

纪律清单（真实优先）
不假称任何未执行的事："草稿已建"≠"已执行"；"配置接受 N"≠"N 路真并行"；终态以完成通知/GetWorkflowRun 为准。
先 2 路 smoke，后大 fan-out：新拓扑先用 2 路验证（成本≈0），再放大到 16 路。
provider 确定性错误原样保留并停步（配额拒绝、并发拒绝），不重试放大；已知重置时间的 usage cap 由 runtime 自动恢复。
评估 wall 用 serial_sum/加速比，别用单路时长——并发争抢会把单路时长拉长数倍（见事实表）。
结果对照一律走确定性 Oracle，不采信模型自评。
fan-out 后给主会话冷却 1-2 分钟再回重交互；fan-out 进行中主会话只做轻编排（发 run、收通知）。 主会话被"系统繁忙"强制暂停时工作流照常完成——产物靠 report() 随到随报，交互轮停了也零丢失。 若一句轻量提问也被拦（"已工作几秒"即弹横幅）＝账户进入持续限流窗口：停止主会话重推理， 等 ≥10-30 分钟或切 Flash 窗口期/换载体，工作转在途 workflow 与闲时队列；勿连环重发加剧限流。
路内按需选档：persona 支持 model 字段（同 provider 加 $level）——trivial 路用 $low/$high， 重路才 $max。16 路全 $max 是压测行为（≈266k tokens/2min）；生产分层可显著降低账户限流压力。
限流窗口内不新发大 fan-out，也不白提 max_concurrency——瓶颈在 provider 配额：新 run 会以 1/16 爬行空占队列，config 并发再高也吃不到；窗口内让在途 run 爬完或转闲时队列。 台账卫生：CreateWorkflow 必传 name——不传则 label 取脚本片段（实例："interface BuildResult {"），台账不可读。
会话词元定时失效前（实例：09:00 批量失效）：先做阶段性 GitHub 回写（checkpoint 写明在途 run id、脚本路径、Resume 指令与验收步骤），让恢复者从最近 durable 点续跑；再配一次性定时自动化在失效后自动续任。产物靠 report() 已随到随报，不怕会话死。
夜间赶工模式（限流时段的职责分层，2026-11-13 定案）
依据：主对话单轮＝一次有界重试的模型调用链，被"系统繁忙"打断即全轮作废；workflow runtime＝无界 自适应重试 + 动态并发（1/16 也持续推进）。生产实证：HT#89 三路 BUILD 爬行下 3/3 交付、主会话停两次零伤亡。

主对话只做三类事：①编排（写脚本、发 run、AmendWorkflow）；②裁决（escalation / Human gate / 验收取舍）； ③汇总（读通知、回执、对账）——每轮短平快。
细节活一律下沉：文件编辑、命令链、取证复算、对照修复——单路串行 workflow 也优于主对话裸奔 （runtime 拥有重试权）；单路启动开销换"被打断不丢、不复活失败"。范例：OCR 工头 ARCH-1 设计切片 （单作者五件套 → 冷读评审 fresh eyes → 修订终推，三阶段单链）。
仍留主对话的例外：真·单轮小活（<1 分钟，被停重发损失≈0）；需要 Human 连续供凭据/知情同意的 gate （凭据走工单不走 ask 文本；决策可走 subagent escalation→ResolveWorkflowQuestion）；刻意串行的保管链 （WAL 成对/SHA 台账——放单路 workflow 享受重试，不并行）。
保活巡检：夜间无人值守配 Cron（*/20 * * * *）对在途 run 做"状态自检"三步体检，checkpoint 落 owner issue，词元失效自停（CronPauseSelf）——HT#89 既有实践。
成本取舍：夜间第一目标是"持续推进"不是"省 token"；workflow 化的 session 开销是保险费， 路内 
l
o
w
/
low/high 选档纪律照常适用。
陷阱速查
写法	后果
脚本里调用 Date.now()/Math.random()/fetch/fs	编译失败（node -e 的字符串参数里可用）
循环内字面量重名 agent	编译失败；必须 agent(`路-${i}`)
phase 标记写进 map 回调	每次重入计一轮；标记只放外层/stage 头
join（Promise.all）处不写注释	后人分不清 barrier 还是习惯
把可调常量插进 ask 文本	amend 时清空下游缓存，全量重跑
只看 return 里的 max_concurrency 字段	settings-only amend 后是旧值；权威在启动回执
把"24 被接受"当"24 路已验证"	>16 实际并行度未测，外推即造假
大 fan-out 后立刻在主会话做重推理	同账户限流窗口内，主会话轮被"系统繁忙"强制暂停（自动重试有上限）；workflow 不受影响，冷却后重发即可
16 路全 $max 跑 trivial 任务	无谓烧 ~266k tokens/2min，把账户推进限流窗口；按路选档
轻量轮次被"系统繁忙"拦后连环重发	加剧限流、延长窗口；正确动作=停重推理 ≥10-30min，工作转 workflow/闲时队列
CreateWorkflow 不传 name	run label 取 script 代码片段（"interface BuildResult {"），台账/会话列表不可读
把 rate_limited 爬行当卡死去停 run	run 活着、last_progress 新鲜、stalled=no；停了反而丢在途工作，等窗口即可
会话词元定时失效前不回写 GH	恢复者只能从旧 checkpoint 重推；正确动作=死前 checkpoint（run id+脚本路径+Resume 指令）+ 定时续任
夜间赶工让主对话亲自干细节活	长轮大调用被停即全轮作废（实例：飞书工头改 build_oci.py 中途被停）；细节下沉单路 workflow，主对话只做编排/裁决/汇总
把编排态主对话"没被停"当成系统特殊保护	是调用形态（少而小）+损失结构（状态在 runtime）的复合结果，不是免疫；轻轮照样会被拦，重发即可

交接词（复制给任何新会话的工头；v1.1.0 起随 skill 维护）

本机已装用户级编排 skill（所有会话可见）。开工前：
1. 先用 Skill 工具加载官方 dynamic-workflows（编写合同），再加载 dwf-max-orchestration（实测补充层）；未自动触发就显式调用 /dwf-max-orchestration。
2. 版本核对：读 【替换你自己的路径】SKILL.md 头部 version 与"版本与变更记录"——文件是 SSOT，本交接词只是入口、可能滞后。
3. 并发口径（2026-11-12 实测）：CreateWorkflow 16 路真并行 PASS（peak16，加速 11.1×，Flash$max）；max_concurrency=24 配置接受但 >16 实际并行未测，超 16 先按 skill"上限探测"配方实弹复测；Agent tool 后台 ≈2，只放辅助小任务。
4. 防强制暂停：主会话与子代理共用账户配额——fan-out 后冷却再回重交互；一句轻量话也被拦＝持续限流窗口，停主会话重推理 ≥10-30 分钟，工作转在途 workflow/闲时队列；产物一律 report() 随到随报。
5. 纪律：真实优先（草稿≠已执行、配置接受≠真并行、provider 拒绝保留原错停步）；结果对照走 node 确定性 oracle；路内按 $low/$high/$max 选档，勿全 $max。
6. 状态判读：黄点/零进度先跑 skill"状态自检"三步看 GetWorkflowRun health 行——rate_limited=活着爬行，别乱停；限流窗口内提 max_concurrency 无效、不新发大 fan-out。
7. 夜间赶工模式：主对话只做编排/裁决/汇总，细节活下沉 workflow（单路串行也行