编舞不是一种拓扑
编舞是跨拓扑的协调模式，不是六列里的第七列。精神上更接近 Teams 模式，而不是 Orchestrate 的反面。
定义
在分布式系统里，编舞（choreography）指的是没有中央指挥的协调方式—— 事件传播，对端反应。把它放到 AI Agent 上来看，编舞可以与链式 / 路由 / 并行 / 循环 / 层级 / 编排并存。它是一种协调模式，不是一种执行形态。 把它当成第七种拓扑列，会把两种不同性质的轴搅到一起。
它命名了什么问题
[TODO · 咖哥本人填这段：这一节最适合你写。 你在做双轴矩阵时，茹炳晟和姜宁都讨论过"编舞算不算独立拓扑"。 结论是"不算"—— 这件事值得在这里留个 record。 可以一句话讲清：编舞回答 "谁触发谁"，拓扑回答 "工作长什么形状"，问题层不同。]
它如何改变设计决策
一旦把编舞理解为协调模式而不是形态，设计对话就会更干净：
- 可以有"扇出聚合（并行）× 编舞"—— worker 订阅事件后反应，没有 orchestrator 派工
- 可以有"交接链（链式）× 编舞"—— 每个 agent 抛出事件，下一个订阅
- 矩阵保持 7×6；编舞的选择是每个模式里横切的设计决策，不是新加一列
这呼应了老的 Teams 模式（PLOPD）：Teams 讲对等者怎么协调；管道 / 层级讲工作怎么流动。 两条不同的轴。
谱系
- Saga 模式（Garcia-Molina & Salem, 1987）——通过编舞式事件流做分布式事务
- 编舞 vs 编排在微服务里的辩论（2010s 早期）—— 同一个架构问题，Agent 时代继承
- Event Sourcing / CQRS—— 编舞作为事件驱动系统里的主协调模式
- Teams 模式（PLOPD vol. 3, 1995）—— 对等协调作为独立的架构关切
它不是什么
- 不是"编排的反面"。把两者当二元对立会把矩阵压扁。
- 不是第六或第七种拓扑列。矩阵已经命名了六种形态；编舞横跨这六种。
- 不是"无 leader 多 Agent"。编舞是一种协调协议，"无 leader"只是它的若干后果之一。
- 不是在框架里被忽略。它在每个相关模式的正文里讨论（比如协作模块），只是不单独占一列。
在哪里展开
- ADPS 协作模块（C1-C5）：每个模式的白皮书都说明何时编舞合适、何时编排合适
- 说明语在 adpsagent.com/zh/patterns/ 和 kage-ai 双轴页矩阵下方都出现
- 立场论文：arXiv:2605.13850——显式说明为什么编舞坐在拓扑轴之外
引用格式：黄佳 (2026). 编舞不是一种拓扑. kage-ai.com/zh/concepts/choreography-is-not-a-topology/