一个人调度四个角色：多会话协作 Skill 的实测与边界

skill multi-session-collab（4 个文件、269 行）与配套手册《评审、修改、测试、裁决：Claude Code 多会话协作实践手册》；实测环境 Claude Code v2.1.302（macOS arm64）。

一个人干一个团队的活，难在换立场。写代码的人很难同时当评审、当测试、当裁决：评审需要距离，修改需要克制，测试需要怀疑，这三种状态在同一个上下文里会互相打架。

这次把四种角色交给一套多会话协作 Skill：评审者、修改者、测试者 各占一个会话，裁判 负责汇总与裁决，一个人只做调度与拍板。一轮完整流程跑下来：评审者 找出代码的两个缺陷，测试者 复现出三个失败用例，修改者 按裁决单修复，复测全绿，终审通过；四个会话没有互相读过对方的上下文，只交换了十来条消息和两份结果表。

跑通之后回头整理，这次修复本身没什么可写的；需要记录的是为了让 agent 自己跑完这套流程而补的那一层东西。手册回答人怎么做，skill 回答 agent 何时做、按什么格式做、被卡住怎么办。

这篇写给已经在用 Claude Code（尤其多窗口、多 agent）的开发者；不熟悉 skill 的，可以先把它当成「按需加载的流程包」。一个人怎么调度一支团队，从一次真实的分工开始。

配套手册：Claude Code 项目级多会话协作实践手册

好书推荐：

一、一次完整流程是怎么跑起来的

测试仓库是一个故意留了 bug 的 average 函数：空列表返回 0（规格要求抛 ValueError），非空时除数是 len(values) - 1。四个会话的角色与分工按手册设定：

tester 还多报了一条：串行执行的 __main__ 在首个失败处中止，后两个用例根本没执行，逐例结果得单独调用才拿得到。这条不在任何任务卡里，是它自己看出来的。

流程本身不难，麻烦都在跑之前：谁先说话、消息长什么样、被拒绝了怎么办。这些原则在手册里已经写成操作流程。剩下的问题是，要让 agent 照着执行，还得把流程封装成可加载的 skill。

二、为什么是 skill

skill 不是 MCP。跨会话消息、Agent Teams、Dynamic Workflow 都是 Claude Code 的原生能力；MCP 是模型与工具之间的协议，没有 agent 间通信能力。用 MCP 再包一层协作总线，等于重写原生的会话发现、审批与投递语义，投入产出不划算。

它也不是更长的文档。文档不会被自动加载，读者是人；agent 需要的是触发条件（什么时候用、什么时候不用）、强制顺序（先选路再配置）、失败处理（消息被扣、名字冲突）。这些放在 SKILL.md 里，agent 才会在合适的时机读到。

skill 不提供新机制，只负责编排：把口头约定换成可执行的流程包。三个载体的分工：

三、三层结构：决策、协议、动作

multi-session-collab 一共 269 行，拆成三层、四个文件：

这个拆法的依据是加载时机：SKILL.md 每次触发都会进上下文，必须短；references 只在需要时读；scripts 是可执行动作，只做「打印」这类无副作用的事，不改配置、不启动会话。脚本的边界是有意画死的：让 skill 能安全地重复运行。

SKILL.md 的「何时用 / 不用」是触发入口（SKILL.md:10-22）：

   
   
   
   ## 何时用 / 不用

用：

- 用户要开多个 CLI 窗口分工（评审、修改、测试），并要一个裁决者
- 需要跨会话消息协议、judge rubric、质量门禁
- 要把「评审 → 修改 → 测试 → 裁决」固化成可重复流程

不用：

- 单会话内的并行子任务 → 用后台 subagent（Agent 工具）
- 一次性短任务 → 多开会话只会把协调成本翻倍
- 只是远程盯屏 → Remote Control / Desktop

四、先用起来：安装与触发

安装就是把仓库副本复制到用户级 skill 目录：

   
   
   
   cp -R 08_agentic_system/agent_skills/multi-session-collab ~/.claude/skills/

之后在会话里用自然语言触发，例如：

• • 「组一个多会话评审队：reviewer 只读评审、modifier 按裁决单修改、tester 复测，你来裁决」
• • 「按 multi-session-collab 的协议给我一份任务卡与回报模板」
• • 或显式 /multi-session-collab

它适合需要多个角色分工、最后由一个人裁决的任务；单窗口能做完的小任务不用它，一个会话反而更快。

五、实测校准：四个缺口

手册写得再细，没跑过就不算数。这次端到端测试暴露了四个缺口，每一个都补进了 skill 与手册，总览见图 2。

先看实际下发的一张任务卡（节选）：

   
   
   
   @reviewer 任务：对照 /tmp/collab-e2e/docs/spec.md 评审 calc.py。
输出格式（只输出 JSON，不修改任何文件）：
{"verdict":"pass|fail","findings":[{"id":"F-001","file":"calc.py","line":12,"issue":"...","evidence":"calc.py:12","confidence":"observed","verdict":"confirmed"}],"unknowns":["..."]}
时限：5 分钟；拿不准的写进 unknowns，不要猜。

reviewer 的实际回报长这样（一条 finding，节选）：

   
   
   
   {
  "id": "F-001",
  "file": "calc.py",
  "line": 11,
  "severity": "high",
  "issue": "非空列表使用 len(values)-1 作除数，违反规格「返回 sum(values)/len(values)」；普通列表结果偏大，单元素列表触发 ZeroDivisionError",
  "evidence": "calc.py:11；实测 average([2,4])=6.0（期望 3.0），average([5]) 抛 ZeroDivisionError",
  "confidence": "observed",
  "verdict": "confirmed"
}

judge 的裁决单据此打回：F-001 除数改为 len(values)，F-002 空列表抛 ValueError；验收标准是三个用例全过。

5.1 worker 怎么起

手册默认开终端窗口，但无人值守时更顺手的是后台会话。claude --bg --name reviewer --add-dir <目标目录> --settings <配置> 能起一个可寻址的 worker，它会出现在 /list-agents 里（kind 为 bg），用 claude agents / claude logs <id> / claude stop <id> 管理。第一次在 /tmp/collab-e2e 直接启动时被拒，报错是「Workspace not trusted」；改成在已受信任的仓库启动、用 --add-dir 授权目标目录才通过。这条补进了 skill 的 references/setup.md:10-23 与手册 §3.1。

5.2 回信会被扣留

双方权限模式不同类时，接收方会扣下跨会话消息。实测里 reviewer 的第一条就绪消息一直没送到；后续的回报多次出现「扣留→放行」，日志原文是 released after approval。把接收方的 crossSessionInbound 设为 accept 可以稳定收信；消息被扣住时，claude logs <id> 能从后台会话的日志里读回内容，这次 tester 的完整 JSON 就是靠它捞回来的。手册 §3.2 与 skill 的入站矩阵都补了这一条。

5.3 只读约束是硬约束

我们原本让 worker 把结果另外写一份到 outbox 文件，reviewer 直接拒绝了：它的角色 prompt 写着只读、禁止修改任何文件。这说明角色约束会真实生效；反过来也提醒，若要用文件回执，必须在角色 prompt 里显式授权路径，不能想当然。

5.4 测试能报出任务卡之外的信息

串行 runner 首败即止、__pycache__ 由谁产生，这些不在任务卡里，但 tester 都写进了 unknowns。回报模板里给 unknowns 留位置，这次派上了用场。

四个缺口补完之后，整条链路是这样：

六、边界：什么该固化，什么不该

skill 写多了会僵化，写少了不顶用。这次实践里，边界大致是这样：

该固化：协议形状（任务卡、回报模板、findings schema、rubric）、决策规则（三个问题选路线）、安全边界（消息不能代批权限、judge 不改代码）、排错表（名字冲突、消息被扣、审批过期）。

不该固化：版本敏感的命令细节（指向官方文档，不抄参数表）、实验特性的开关（Agent Teams 明确标注「实验」）、权限配置（crossSessionInbound 只给建议，由使用者选择）、组织习惯（会话命名、人数上限）。

三个反模式：

1. 1. 文档搬运：把手册整段复制进 SKILL.md，触发时上下文被撑大，agent 反而抓不住重点。
2. 2. 替机制：用 skill 假装成 MCP 或工作流引擎，该由协议层做的事硬塞进提示词，最后不可维护。
3. 3. 过度脚本化：脚本改配置、起会话、删文件，skill 变成半成品工具，失去「可安全重复运行」的性质。

判断一个流程该不该做成 skill，四个问题够用：它会重复发生吗？中间有需要判断的决策点吗？有必须遵守的顺序或门禁吗？会跨项目复用吗？四个都答「是」，才值得做成 skill；只有一两个「是」，写进 CLAUDE.md 或一篇文档就够。

七、收尾

现在这个 skill 是 269 行、4 个文件：70 行的决策层、146 行的协议与环境参考、53 行的只读脚本。一次实测跑了 6 个回合、4 个角色、十来条跨会话消息，暴露出 4 个缺口，全部补回去了。仓库里对应的是那篇手册；这篇记录两者之间的转换与实测，三者的分工见 §二 的表格。

源文件索引

参考资料

• • 评审、修改、测试、裁决：Claude Code 多会话协作实践手册