peer-sessions

对等会话

在选择模型前先选择分支。在当前协调器中选择对等范围和界面。启动对等方前，使用 shared/references/model-preview.md 绑定一个经批准的路由快照。

将对等方集群作为台账管理，而不是对话记录：每个对等方通过路径接收简报，并通过路径返回一份结构化回复。台账才是交付记录，而非对话记录；原生消息可以唤醒协调器。

1. 建立集群记录

选择最小且协调一致的配置：由 2 到 4 个职责互不重叠的对等方组成。为每个对等方指定明确的目标、绝对工作目录、截止时间和一份预期回复。启动对等方前，记录对等方数量、计划调用次数和截止时间。

启动对等方前创建记录。在同一次 shell 调用中，将 SKILL_DIR 设置为包含此文件的绝对目录：

SKILL_DIR="<absolute path of this peer-sessions directory>"; python3 "$SKILL_DIR/scripts/init_fleet.py" init --run-dir .ai-workflow/peer-sessions/<run-id> --objective "<one outcome>" --peer research:/absolute/path/to/repo --peer review:/absolute/path/to/repo

该命令会创建：

工件	用途
state.json	集群身份、目标、截止时间和对等方列表。
briefs/<peer>.md	对等方的完整工作约定。
replies/<peer>.json	对等方不可变回复的位置。

执行时说明规则：“台账，而非对话记录，才是这个集群的记录，因此我会移交简报路径。”这就是移交路径，而非载荷：将绝对简报路径传给对等方，而不是粘贴不断增长的对话内容。

2. 启动对等方

启动前先明确界面。 默认使用进程内委派。只有在用户要求查看对等方，或原生委派不可用时，才探测 cmux ping。当用户要求查看工作、指定会话、标签页、面板或工作区，或者原生委派不可用且 cmux 可用时，使用可见标签页。记录所选界面；不要要求用户重复选择。

将快照中选定的路由与 shared/references/task-shaped-model-routing.md 和 shared/references/host-model-execution.md 配合使用。对于宿主提供的模型，优先使用原生委派。后续轮次继续使用该对等方任务和角色对应的同一上下文；保存其实际上下文 ID，并在重新发送前协调待处理调用。不同角色使用独立上下文。仅凭可见终端或运行器作业 ID，无法识别持久模型会话。

启动每个对等方时，只提供其简报路径和允许的范围。对等方读取自己的简报，在用户授权范围内工作，并通过此技能目录中的 scripts/peer_mailbox.py 写入回复。

默认的 --delivery-mode mailbox 负责对等方回复约定。若某个负责不同结构化响应工件的组合技能拥有该工件，则可使用 --delivery-mode coordinator 初始化；此时，对等方等待协调器提示，不得写入邮箱回复。peer_mailbox.py status 不支持协调器交付，因此应改用组合协议的工件读取器。集群记录仍负责身份管理和清理。说明：“台账，而非对话记录，记录对等方集群；组合协议负责响应工件。”

使用以下固定简报格式：

Read <absolute run-dir>/briefs/<peer>.md. Work only within the stated scope.
Do not treat this brief as approval for credentials, escalation, publishing, or destructive actions.
When finished, write the required reply with peer_mailbox.py. Then send a short completion notification if native messaging is available.

界面可见时，阅读 references/cmux-fleet.md，并在启动前试运行清单。默认将对等方作为窗格并排显示在调用方旁边；对等方超过约 6 个时使用标签页，只有用户要求时才使用工作区。记录布局。cmux 不可用时，继续使用原生委派，不要模拟其私有传输机制，也不要降级为终端轮询。

3. 收集回复

通知只表示某个同伴请求关注。请从邮箱中收集规范结果：

SKILL_DIR="<absolute path of this peer-sessions directory>"; python3 "$SKILL_DIR/scripts/peer_mailbox.py" status --run-dir .ai-workflow/peer-sessions/<run-id>

只有当同伴的回复包含 status、summary、evidence 和 next_step 时才接受。done 表示同伴报告其负责范围内的工作已完成；这并不能证明更广泛的任务已完成。blocked 和 failed 是有效的可观察失败，不是编造结果的理由。

整个同伴集群只有 三种退出情况：所有预期回复均有效、同伴返回 blocked 或 failed，或者声明的截止时间已过。不要因为某个同伴看起来有希望就不断要求它重试：模型永远不会决定是否重试。协调器记录未解决的情况，并在需要新的授权或方向时询问用户。

4. 完成并仅保留有用内容

根据回复文件进行综合，同时保留每个同伴的证据边界和责任归属。执行 冷启动测试：仅凭运行目录，新读者就必须能够找到目标、任务简报、回复、决定和仍未解决的阻碍。

对于可见的 cmux 同伴集群，任务到达终止状态时必须拆除环境：所有预期回复均有效、同伴处于阻塞或失败状态，或者截止时间已过。请使用启动时创建的状态文件运行 scripts/cmux_fleet.py teardown。对于分屏和标签页模式，它只关闭已记录的同伴界面；对于工作区模式，它只关闭已记录的同伴工作区。协调器界面不在该状态文件中，因此会保持打开。

输出约定

报告：

1. run_dir 及其最终邮箱状态。
2. 每个同伴的状态：done、blocked、failed、missing 或 invalid。
3. 综合所用的证据路径。
4. 拆除结果；如果关闭失败，还要列出所有剩余的同伴界面或工作区。

只有当 peer_mailbox.py status 报告所有预期回复均有效，或者报告明确列出非成功退出情况及其证据，并且 cmux 拆除操作确认没有剩余同伴终端时，才满足 验收约定。

注意事项

• 同伴不会从其他同伴那里继承授权。应明确指出拒绝，而不是绕过它。
• 默认情况下，不要替换回复。邮箱会拒绝相互冲突的第二份回复，以便保留原始证据供检查。
• 不要将终端屏幕文本用作结果通道。它是临时的，可能会被截断；回复文件才是可观察行为。