03 / Multi-agent
有多智能体。没有多智能体框架。
pstack 里到处是并行代理。但它没有消息总线，没有共享黑板，没有角色扮演剧团。主线程是 lead。Task 工具是派遣。Worktree 是隔离。综合发生在主线程。
- 要解决的失败
- 对抗「第一个形状被锁死」
- 是否同一任务
- 是。同一 brief，N 次独立尝试。
- 有没有 judge
- 跨模型家族的只读 judge 按私有 rubric 打分。然后选 base，再嫁接失败者身上值得留的部分。
- 如何隔离
- 每个候选自己的 worktree 或目录。禁止共享可写路径。
- 什么时候用
- 设计、命名、算法、错误模型。一次尝试代价高的决策。
- 什么时候不用
- 要覆盖很多独立切片时。那是 swarm。
还有两种扇出，经常被算进 multi-agent
how 在子系统很大时拆成 2 到 4 个探索块：数据模型、请求路径、配置与指标。一个解释者再合成心智模型。批判模式会先解释，再让几个模型审这套架构。顺序很重要。批评者拿到的是被追踪过的系统，不是一个文件名加一句猜测。
why 按证据源扇出：源码历史、工单、长文、聊天、监控、错误追踪、产品分析。每个可用类别一个调查者。最后的模型把直接事实和推断分开。空搜索也要汇报。编一个听起来合理的原因，比诚实说「没有文档」更糟。
并行的真正约束是共享可变状态
多个代理写同一个工作区，会互相踩。原则里专门有一条：先分开，再序列化共享状态。默认是给每个写者自己的 worktree 或输出目录。加锁去保护一个共享目录，是在错误的层解决问题。
功能 playbook 里还有吞吐量检查点：先做阻塞步骤，再标出独立工作流，再处理共享可变状态，最后决定最小安全分解。一个工人更好时，要写出为什么。父级扇出只用于产出独立产物的切片。代码耦合的工作给一个 owner，由它在内部再扇出。
规模再往上，是协调而不是更多同级工人
Orchestrate 是站着的项目协调者：多日、许多堆叠 PR、几十到上百子代理、极少的人类回合。Autopilot-full 是每个 PR 一个 owner，从构建到合并；根在合并前做 swarm 验证。Autopilot-stack 做出一条线性已审堆栈，落地留给人。
思维上这已经接近小型工程组织。成本也按组织算。先让单循环可信：理解、复现、修、验证、展示。再乘。