multi-agent-shogun：用 tmux 和 YAML 拼出的多智能体指挥链

它解决的不是「让 AI 更强」，而是「让 AI 同时干活」

单个编码智能体的瓶颈很少是智力，而是串行。你让它改一个模块，它改完再改下一个，中间你只能等。multi-agent-shogun 针对的就是这段等待时间：它把多个 CLI 实例同时跑起来，由一个上层实例接单、拆解、分发，下层实例并行执行。README 里给出的画面是「一个 karo 协调 7 个 ashigaru 加 1 个 gunshi」，共 8 个独立智能体。

目标用户写得很直白：已经订阅了 Claude Code、Codex、Copilot、Kimi、OpenCode、Cursor 或 Antigravity 中任意一种，并且想把这笔固定月费榨干的人。README 自己算了一笔账，8 个 Opus 级别智能体走 API 每小时约 100 美元以上，而 CLI 包月大约每月 200 美元。这个对比是项目全部设计动机的来源：既然边际成本为零，那就多开几个。

需要说清楚的是，这个数字来自 README 的自述，不是第三方测算。它是否成立，取决于你的订阅层级、并发限制和实际用量，这些都必须你自己核对。

指挥链落在磁盘上：YAML 文件加 tmux 窗格

机制本身不复杂，甚至有点朴素。每个智能体跑在自己的 tmux 窗格（pane）里，彼此之间不通过内存队列、不通过消息中间件，而是通过磁盘上的 YAML 文件传递指令和报告。README 用「zero coordination overhead」概括这一点，意思是编排本身不产生任何 API 调用，token 只花在真正的工作上。

数据流是单向的：你在 shogun 窗格输入一句自然语言，shogun 把它转成任务交给 karo，karo 拆成子任务分给各个 ashigaru，ashigaru 执行后把结果写回文件。README 强调通信是事件驱动而非轮询，每个智能体有专属文件、归属清晰，因此不会互相抢写。

这个设计换来的好处是可观测和可版本控制：所有指令、报告、决策都是纯文本 YAML，你能读、能 diff、能提交进 git。代价同样明显，磁盘文件不是事务性的，YAML 也没有 schema 强制；如果两个智能体的写入范围出现重叠，冲突只能靠人去看、去合。README 用「clear ownership, dedicated files per agent」来描述防线，这本质上是一条约定，不是运行时保证。

从 first_setup.sh 到 shutsujin_departure.sh

安装路径在 README 里给得很完整。前置条件是 tmux、bash 4+，以及至少一种受支持的 CLI。命令序列是：

git clone https://github.com/yohey-w/multi-agent-shogun cd multi-agent-shogun bash first_setup.sh source ~/.bashrc claude --dangerously-skip-permissions bash shutsujin_departure.sh

first_setup.sh 负责一次性配置、依赖安装和 MCP 接入；source ~/.bashrc 是为了重载 PATH；claude --dangerously-skip-permissions 只在首次运行时需要，用来完成 OAuth 并接受 Bypass Permissions，之后退出；最后 shutsujin_departure.sh（出击）一次性拉起全部智能体。

这里有一个必须停一下看的点：--dangerously-skip-permissions 这个参数名不是修辞。它意味着 Claude Code 在该会话中不再逐次向你确认文件写入和命令执行。项目把它放在首次运行的必经路径上，说明设计者默认用户接受这个前提。你在多窗格里同时跑 8 个具备写权限的智能体，等于同时放弃 8 份人工确认。README 没有展开讨论这个风险，这是文档里最薄的一块。

配置方面，README 提到 first_setup.sh 会生成配置、支持多 CLI 设置，但没有在可见部分列出具体的配置键名。要改默认模型或切换 CLI，得去翻仓库里的配置文件本身。

作者把自己的部队解散了，这件事写在 README 最上面

README 开头有一段加粗提示，日期标注为 2026 年 8 月：作者已经把自己那支 10 智能体的部队裁减到单个智能体，让那一个智能体承载他自己的判断力。后继项目叫 kagemusha，交付的是「判断回路」的形式（修正 → 原则 → 常备规则），而不是智能体本身。原文链接是一篇日文文章，标题大意是「kagemusha 与 shogun 解散记」。README 同时声明，multi-agent-shogun 本身继续可用。

这不是普通的版本更新说明，而是一条关于适用边界的一手信息。项目的作者在长期使用后，判断并行智能体的收益不足以抵消维护它的成本，于是把系统降级为单智能体加一套规则沉淀机制。README 没有给出解散的具体理由，也没有量化对比，所以不能替他补充动机。但事实本身足够清楚：这个项目最资深的用户认为，问题不在编排层，而在判断层。

对读者的实际含义是：如果你想要的是「让 AI 同时干更多活」，这个项目仍然成立；如果你想要的是「让 AI 越来越懂我的判断」，作者已经用行动告诉你，他把答案放在了另一个仓库里。

零协调成本是真实的，但它把成本挪到了别处

README 的对比表把 multi-agent-shogun 和 Claude Code 内置的 Task 工具、Agent Teams、LangGraph、CrewAI 放在一起，主张自己协调成本为零、支持 7 种 CLI、可观测性靠实时 tmux 窗格。这几条在架构层面站得住：YAML 文件确实不调用 API，tmux 窗格确实肉眼可见。

但「零协调成本」只描述了 token 账本，没描述人的账本。8 个窗格同时在滚，谁来读？每个 ashigaru 写出的 YAML 报告需要有人判断是否合格、是否要返工、是否与其他分片冲突。README 里那句「You watch the dashboard. That's it.」把这一步压缩成了一个逗号，实际上它才是日常开销的主体。

另一个被表格掩盖的约束是任务可切分性。7 个 worker 并行有意义的前提，是任务能被切成边界清晰、互不依赖的分片。像重构一个共享数据结构、调整全局命名约定这类工作，切成 7 份只会制造 7 份冲突。项目本身没有提供自动合并或冲突消解机制，这一点在 README 中没有任何承诺。

还有一层是 CLI 侧的并发限制。README 没有说明各 CLI 订阅对同时会话数、速率的具体约束。8 个并发实例是否触及上限，需要按你实际订阅的服务条款核对，项目文档帮不上忙。

和 LangGraph、CrewAI 的差别不在功能多少，在状态放在哪

拿 LangGraph 做对照最能说明问题。LangGraph 把多智能体建模成图上的状态机，状态在进程内流转，需要 Postgres 或 Redis 这类基础设施来持久化和恢复，好处是可重放、可中断、可在生产环境做检查点。multi-agent-shogun 把状态放在磁盘的 YAML 文件里，好处是零依赖、零基础设施、随时可以 cat 出来看，代价是没有事务、没有恢复语义、没有并发写保护。

CrewAI 走的是角色抽象路线，用 Python 定义 agent 和 task，模型通过 API 调用，跨模型切换靠换 API key。multi-agent-shogun 则绑定在 CLI 上，用的是你已有的包月订阅而不是按 token 计费。这个差异直接决定了成本曲线形状：CrewAI 是线性的、随用量增长的，shogun 是阶梯式的、封顶的。

所以选择标准不是「谁更强」，而是你的任务需要哪种状态语义。需要重放和审计留痕，LangGraph 那套基础设施是必要成本；需要的是把一笔固定订阅变成 8 份并行产能，并且能接受人去读 YAML，shogun 的取舍更划算。两边都不适合的场景是：任务高度耦合、必须共享同一份上下文。

维护成本与 MIT 许可下的实际自由度

项目是纯 Shell，README 的徽章标注 Shell/Bash 100%。这意味着没有构建步骤、没有依赖树、没有版本解析，升级方式基本就是 git pull 之后重跑 first_setup.sh。最近几个版本的节奏可以看出来：v4.6.0 在 2026 年 4 月，v5.0.0 在 5 月加入 OpenCode 一等支持，v5.1.0 在 5 月把 karo 改成流量控制器，8 月还有提交。迭代不算慢，但每次大版本都可能改动 YAML 的约定格式，而 YAML 正是你的任务数据所在的地方。

因此真正的升级成本不在脚本本身，而在你积累的那些 YAML 文件和围绕它们形成的操作习惯。这部分没有任何迁移工具，README 也没有提及兼容性策略。

许可方面，MIT 允许商用、修改、再分发，只需要保留版权声明和许可文本。需要注意的两点与许可无关而与使用有关：一是被编排的各个 CLI 各有自己的服务条款，把包月订阅用于并发自动化是否符合条款，得逐家确认；二是 --dangerously-skip-permissions 带来的写入权限，属于你自己的风险决策，MIT 不会替你承担。以上只是对许可文本的复述，不构成法律意见。

编辑结论

如果你已经为 Claude Code 或 Codex 付了包月订阅，手上有一批能拆成独立文件边界的任务，并且愿意接受 tmux 窗格这种略显原始的交互方式，multi-agent-shogun 值得跑一次 first_setup.sh 看看。反过来，如果你的任务需要频繁共享上下文、需要精细的成本核算，或者团队里没人愿意读 YAML，那它只会给你制造一堆需要人工合并的产物。动手之前先确认三件事：你的 CLI 订阅条款是否允许这种并发调用、你的任务能否被切成互不依赖的分片、以及 kagemusha 那条替代路线是否更贴近你真正想解决的问题。

官方来源

1. Issues
2. License: MIT
3. README
4. Releases
5. yohey-w/multi-agent-shogun on GitHub