多 agent 编排最怕停不下来：skein 用 epoch fence 保证停止真的是停止

多 agent 并行执行最怕什么？不是某个 agent 挂了，是你按下紧急停止后，已经派出去的任务还在后台继续跑。你删了任务定义、关了调度器，但某个 agent 在三十秒前拿到的指令还在执行，写完文件、提交了代码，最后回来告诉你「任务完成」，但这一切已经被你取消了。

skein 是 Balanov（shim 和 verdict 的作者）11 月 2 日发布的第三个工具，263 星、MIT 协议、Go 写的。它解决的是一个大多数编排框架都不认真处理的问题：怎么保证「停止」真的是停止。

一、epoch fence：停止的机制

skein 的核心概念是 epoch fence（世代围栏）。每个任务分配执行时打上当前的 epoch 编号，紧急停止会使 epoch 递增，旧 epoch 的任务结果即使完成也会被拒绝接收，不是标记为「已取消」，而是直接拒绝。进程重启后 epoch 不会被重用。

这意味着：你按下紧急停止，旧 epoch 的所有排队任务和正在执行的任务全部失效，即使某个 agent 在停止前已经完成工作并返回结果，那个结果也会因为 epoch 不匹配而被丢弃。这叫 fail-closed，不确定时按失败处理。

二、架构：执行控制面

skein 定位为执行控制面（execution control plane），不是 agent 框架也不是模型运行时。它执行显式的任务图（task graph），有并发上限，没有守护进程、没有数据库、没有运行时依赖。安装一条命令，单个静态 Go 二进制跨 Linux、macOS 和 Windows 的 amd64 和 arm64。

skein run --state .skein --workers 2 --include-tasks examples/fanout.json
skein stop --state .skein --reason "manual emergency stop"
skein status --state .skein   # {"stopped":true,"epoch":2}

版本 0.2.0 是早期发布。README 里的建议很实在：在你自己的工作负载上先测试停止证明，再考虑生产使用。

三、与 shim 和 verdict 的关系

Balanov 两天连发了三个工具，但它们不是同一个产品的三个模块，而是解决 agent 运行时三个不同层面的问题：shim 是模型到命令的适配层（451 星），verdict 是工具调用的语义验证层（233 星），skein 是多 agent 编排的执行控制层（263 星）。三者可以独立使用，也可以组合：shim 接模型、verdict 验结果、skein 管编排。

四、冷水：四条都得泼

一，0.2.0 早期发布，README 自己说先在你的工作负载上测试停止证明。二，263 星、0 fork 的单人项目，bus factor 等于 1。三，Go 静态二进制虽好，但没有 MCP 集成、没有 Web 界面、没有 agent 框架的丰富生态。四，fail-closed 意味着保守：epoch 递增后，旧 epoch 的合法结果也会被丢弃，如果你的 agent 有长时间运行的任务，被紧急停止后需要从头再来。

五、判断

多 agent 编排工具很多，但大部分关注「怎么把任务分出去」，skein 关注的是「怎么确保停得下来」。epoch fence 这个设计简单但有效，fail-closed 原则对生产环境是正确的选择。三人工具组合起来已经是一个轻量级的 agent 基础设施栈，但生态和文档还需要时间积累。

来源：github.com/Balanov/skein（第一手，README 全文已读，2026-11-04 直读）。