团队不是多 agent 编排

多个 agent 一起干活，常见说法是 multi-agent 编排：把每个 agent 当节点，画出连线，定义谁调用谁、按什么顺序触发。

这又是流程图思维。框架统一的是流程图，不是 agent；编排是它在团队层的翻版——画的是调用拓扑，不是团队。

连线图画不出岗位关系

一个真实的团队，重点不在“谁调用谁”，而在岗位关系：谁负责哪一摊、谁向谁交付、谁对谁的产出负责、出了事谁担。

这些关系，调用拓扑图画不出来。两个 agent 之间有一条连线，只说明 A 会触发 B，不说明 A 交给 B 的是什么、B 的产出由谁验、出了问题算谁的。一张连线漂亮、跑得通的编排图，背后的岗位关系可能一团糟——职责重叠、交付无人负责、责任无处落。流程跑通，不等于团队成立。

所以设计一个 agent 团队，顺序和设计一个 agent 一样：先定义关系，再谈实现。

先把岗位关系理清——每个岗位的职责、它向谁交付什么、它的产出由谁负责。这些定清楚了，调用怎么连只是技术选择。编排实现岗位关系，不等于岗位关系本身。把次序倒过来——先搭一张编排图，再回头想每个节点是干嘛的——就又回到了第一章那个错误的起点：在还没想清“是什么”的时候，先忙着搭结构。

但先设计关系，不等于先把岗位切碎。岗位清楚和岗位细碎是两件事。清楚的是职责、权限、交付物和升级条件；细碎的是把一个本可连续完成的判断拆成几段，再让交接成本吞掉协作收益。

团队的第一个问题，不是“用什么编排框架”，也不是“拆成几个 agent”，而是“哪些边界真实存在”。真实边界来自任务结构、风险边界和事实独立性。没有这些理由，多一个 agent 只是多一个接口。