批量任务执行 · 并发限流与断点【律令·本地零联网】
批量执行器：一批清单批量执行，单条失败不拖垮整批；执行前默认只预览，支持并发执行、限流、熔断与任务队列式的断点续跑。
免费 · 开源许可 BUSL-1.1 · 本地执行，安装后不产生任何外部网络请求
去安装 →这个技能做什么
本地运行，零网络、免 API Key、数据不出电脑。 四项诚实承诺：① 算不出就说算不出，绝不编造数字；② 高危动作强制人工确认；③ 幂等断点，绝不重复副作用；④ 全程留痕可审计。
批量任务
子命令
| 子命令 | 作用 |
|---|---|
plan | 解析清单生成批次计划（不执行） |
run | 执行（默认预览，--yes 才真跑） |
status | 看批次状态 |
report | 出批次汇总报告 |
retry-failed | 导出失败项清单 |
工作流建议
- 先 plan 再 run：
plan阶段核对total与preview，total不对说明清单解析有问题（表头没跳掉、编码不对），这时候改比跑一半再改便宜得多。 - 第一次跑必须不带
--yes：先看预览，确认命令模板拼对了（尤其含空格路径与中文 key）。 - 按场景定
--max-fail：外部依赖不稳时设小一点快速熔断；批量回填这类已知会有坏数据的设大一点跑完。熔断不是失败，剩余项还是 pending。 - 交付时要说清楚：
- 报「成功 N 失败 M」时，M>0 必须一并给出失败原因（
fail_samples或 report 里的失败清单）； - 若是熔断退出的，必须说明「剩余 K 项未执行」，不能只说「跑完了」；
- 导出重跑清单时提醒用户先看失败原因，别原样重跑。
自检清单
plan的total与清单实际条数（去掉表头/注释/重复后）一致吗？- 第一次执行是否先看过 preview / dry-run？
- 若
circuit_broken非空，交付时是否说明了剩余未执行项数？ failed > 0时是否给出了失败原因与retry-failed清单？- 含特殊字符的 key 是否触发了
warn_shell_meta，是否有意忽略？
---
批量任务 · 律令科技（深圳）有限公司 (@lexord-technology) · Proprietary · © 2026
与相邻技能的关系
本包只做自己职责范围内的事，遇到下列情形直接转给兄弟技能：
| 用户要做的事 | 转交给 | 转交话术 |
|---|---|---|
| 单条失败要重试 | retry-guard | 「重试策略交给 retry-guard」 |
| 整批中断要续跑 | resume-runner | 「断点恢复交给 resume-runner」 |
| 要定时跑 | schedule-runner | 「定时交给 schedule-runner」 |
| 批量执行的是桌面流程 | rpa-flow | 「流程编排交给 rpa-flow」 |
反向边界：执行前默认只预览，确认后才跑；单条失败不拖垮整批；支持并发、限流、熔断。
你是一个批处理调度员：把一份清单丢给一句话命令，一条一条（或几条几条）跑完，同时保证「单条失败不拖垮整批、跑之前先让你看清楚要跑什么」。核心原则：默认只预览、失败要有熔断而不是硬撑、跑完必须能说清哪几条没成功。
标签
批量执行批量任务断点续跑并发执行任务队列
安装方式
- 打开 SkillHub 上的技能页，点击安装；
- 技能文件落在本机技能目录，SKILL.md 全文可在安装前预览；
- 在你的 Agent 里直接说出使用场景即可触发，例如「批量任务、批量执行、批处理」。
network: none，运行过程中不发起任何外部网络请求，也不上传你的文件与数据。你可以断网运行来验证这一点。同类技能
常见问题
按真实会被问到的顺序排。每条答案都给得出可核对的依据——触发词、文件名、路径、源码，全部来自技能包里的真实内容，不是宣传话术。
批量任务执行 · 并发限流与断点 能帮我做什么？
批量执行器：一批清单批量执行，单条失败不拖垮整批；执行前默认只预览，支持并发执行、限流、熔断与任务队列式的断点续跑。
常见的触发场景有：批量任务、批量执行、批处理。
完整说明、版本记录和安装方式在 SkillHub 上的「批量任务执行 · 并发限流与断点」页面。
具体能做哪几件事？
按包内文档「核心能力（全部实测通过）」，它做这几件事：
- 总计：8 项
- 成功：6 失败：2 待办：0 运行中：0
- 完成率：75.0%
- 累计耗时：8.26s
它明确不做什么？什么情况该转给别的技能？
本包只做职责范围内的事。下面这些情况它会明确转给兄弟技能，而不是硬做：
- 单条失败要重试 → 转给 retry-guard
- 整批中断要续跑 → 转给 resume-runner
- 要定时跑 → 转给 schedule-runner
- 批量执行的是桌面流程 → 转给 rpa-flow
反向边界：执行前默认只预览，确认后才跑；单条失败不拖垮整批；支持并发、限流、熔断。
用之前得注意什么？有什么红线？
每次执行前要过的自检项：
- plan 的 total 与清单实际条数（去掉表头/注释/重复后）一致吗？
- 第一次执行是否先看过 preview / dry-run？
- 若 circuit_broken 非空，交付时是否说明了剩余未执行项数？
- failed > 0 时是否给出了失败原因与 retry-failed 清单？
装上之后怎么用？
安装后，在支持 SkillHub 的 AI 客户端（如 WorkBuddy）里直接使用即可。
触发方式：对话里提到「批量任务、批量执行、批处理」等场景，或把相关文件发给 AI，它就会自动响应。
也可以直接跑脚本，典型用法：python scripts/batch_runner.py <子命令> [参数]（完整参数见包内说明）。
或从客户端的「已安装技能」列表里手动唤起。
怎么验证它真的没有联网？
不发一个网络包——包的 frontmatter 声明 network: none，不声明就没有联网能力。三条验证路径任选：
① 安装后把网断掉再跑一遍，功能照常——它本来就没打算联网；
② 用抓包工具（Wireshark / Fiddler）观察该技能进程，零外部连接；
③ 直接翻源码：batch_runner.py、job_state.py 等源码全部公开可预览，没有一行网络代码。这是能逐行核对的技术事实，不是宣传口号。
要付费吗？要 API Key 吗？
不需要 API Key，全部技能免费安装。
许可为 BUSL-1.1：BUSL-1.1 源码可见，个人及企业内部可自由使用（含内部生产环境）；发布满 4 年自动转为 Apache-2.0。详见随包 LICENSE.md。
什么环境能跑？需要装依赖吗？
Windows / macOS / Linux 都能跑。
纯 Python 标准库实现，不需要 pip install 任何东西，也就没有环境冲突要调。
唯一前置是本机装了 Python 3；客户端（如 WorkBuddy）会替你调用，一般不用手动敲命令。
它会不会乱动我的电脑？高危操作怎么办？
四项诚实承诺写死在每个包里：算不出就说算不出；高危动作强制人工确认（阻断而非提示，不是弹窗问一句就放行）；幂等断点，绝不重复副作用；全程留痕可审计。
这类工具包只读取你指定的输入，结果写到输出目录，不改原文件；每一步动作留痕可查。
遇到问题怎么反馈？
执行 · 门禁 · 账单 · 可靠 —— 四块拼图，覆盖 Agent 落地全链路
去企业页 →