AutoGen 是这一簇里的编程抽象层祖师爷：它把复杂 LLM 应用统一为「多个可对话 agent 相互聊天」，用 auto-reply 循环 + reply 函数注册把控制流从显式编排器中移除
[2308.08155]。簇内其余 8 篇几乎全部站在它（及 LangGraph/AgentScope 等同代框架）之下或之侧，分属三个截然不同的层次，正好构成 agent 栈的纵向切片：
[2308.08155]，但从不回答「一个 LLM 调用该派给强模型还是弱模型」；RouteLLM 用偏好数据训练一个二元路由器 $P(\text{win}_s\mid q)$，>2× 成本节省、保 >90% 强模型质量 [2406.18665]。它可作为 AutoGen 里每个 AssistantAgent 的 backbone 选择器插件。
UserProxyAgent 执行代码/工具正是这类 CPU 负载 [2511.00739]。关系本质：AutoGen 定义了「what runs」（agent 拓扑与对话流），而簇内 6 篇 serving 论文 + 2 篇上层论文各自回答「how it runs efficiently / how it connects」。AutoGen 是被优化的对象，不是优化者。
AutoGen 是唯一的「编程模型」论文，其余全是「系统/协议」论文——这是最大的 delta，也决定了它们几乎无法在同一指标上直接比较。
| 维度 | AutoGen (2308.08155) | serving 簇 (Autellix/Continuum/TokenCake/Halo/KVCOMM) | 上层簇 (RouteLLM / 协议综述) |
|---|---|---|---|
| 贡献类型 | 编程抽象（对话即 control plane） | 调度/内存/放置机制 | 路由决策 / 通信标准 |
| 主指标 | task success rate + 代码行数 | throughput / latency / KV util | cost saving / 定性对比 |
| 有无形式化证明 | 无，纯实证 [2308.08155] | 多为无（Continuum 有 utility model 但无 competitive ratio [2511.02230]） | 无 |
| 层次 | 编排层 | serving 层 | backbone 选择 / 互操作层 |
AutoGen 独有、后续论文没有的：
后续论文相对 AutoGen 的增量（AutoGen 留下的洞被逐个填补）：
矛盾/张力：AutoGen 声称「无需独立 control plane，控制流由 auto-reply 自然涌现」是通用性的来源 [2308.08155]。但 Halo 的立场恰相反——它认为把编排与性能解耦（框架只编排、serving 层不知情）正是低效之源，必须引入一个显式的、看得见全 batch DAG 结构的优化器 [2509.02121]。
矛盾根源：两者的目标函数与 workload 假设不同。AutoGen 优化的是开发者表达力与任务成功率（六个异构应用共享一套抽象 [2308.08155]），把控制流藏起来降低心智负担；Halo 优化的是批量同模板 workflow 的 makespan/吞吐，此时「藏起来的控制流」= 对调度器不可见的结构 = 无法复用的冗余。二者在各自 workload 上都对——AutoGen 面向少量异构交互式应用，Halo 面向数千条同构离线 workflow。
攻击点 1 — 「对话即 control plane」在生产 serving 下是负债而非资产。
AutoGen 宣称去掉显式编排器、让控制流由 auto-reply 循环隐式涌现是通用性的根因 [2308.08155]。但下游整簇 serving 论文的存在恰恰证伪了「隐式即够用」：Autellix 必须重建 program 结构（stateful session + global process table）才能调度 [2502.13965]，Halo 必须把 workflow 显式还原成 DAG 才能优化放置 [2509.02121]。换言之，AutoGen 藏起来的 control plane，serving 层不得不逆向工程再造一遍。这是抽象泄漏（leaky abstraction）的经典症状——AutoGen 的通用性是以下游不可观测性为代价买来的。
攻击点 2 — 成功率增益部分来自 backbone 弱，会随模型变强而蒸发。
AutoGen 最亮眼的数字是 OptiGuide 多 agent 相对单 agent 在 GPT-3.5 上 +35%、GPT-4 上仅 +8%，并自陈「后端越弱增益越大」 [2308.08155]。这与 2511.00739 的观测方向一致：GPU/backbone 越强，瓶颈越快移出 LLM 本身 [2511.00739]。外推：在 2026 年的强 backbone 下，多 agent 分工的「补能力」价值可能显著缩水，AutoGen 的核心卖点之一（弱模型靠协作追平强模型）时效性存疑。
攻击点 3 — 延迟主张站不住脚。
AutoGen 只报 OptiGuide 端到端 ~1.5 min vs Code Interpreter 4′35″，且明说这是「等 GPT-4 响应」的用户耗时，非交互延迟保证 [2308.08155]。而 Continuum 实测 multi-turn agent 的排队气泡占总延迟 58.2% 且随 turn 数线性累积（1× turns 1.6× → 5× turns 3.7× 改善空间）[2511.02230]。AutoGen 的动态群聊、多轮往返正是高 turn 数场景，其未测量的排队延迟很可能是主导项——AutoGen 对自身延迟画像是空白的。
攻击点 4 — 进程内 send/receive 无法跨组织扩展。
AutoGen 的统一接口是单运行时内的方法调用 [2308.08155]。2505.02279 指出真实 agent 生态需要跨框架、跨信任边界的协议（MCP/ACP/A2A/ANP），且没有单一协议能同时覆盖工具耦合、结构化消息、企业委派与开放发现 [2505.02279]。AutoGen 的抽象在「一个团队、一个进程」内优雅，跨越组织边界时缺失 identity/auth/discovery 三件套。
范式定位：AutoGen 是 2023 年「多 agent 对话框架」范式的奠基作与事实标准之一，与 LangGraph、AgentScope、MetaGPT 同代。它把 agent 编排从「专用脚本」提升为「通用编程模型」，其历史地位类似于把 GPU 编程从手写 kernel 抬到 CUDA 抽象层。
采纳证据（来自下游论文的引用行为，这是最硬的生态位信号）：
生态位判断：AutoGen 已从「一篇论文」固化为「一层基础设施假设」。整簇 serving 论文的分工格局——上有 RouteLLM/协议、下有 5 篇调度内存优化——本身就是 AutoGen 这类编排层成为生态锚点后自然分化出的上下游。它不再需要证明自己有效，而是被后来者当作坐标原点。
从这个簇的空白格子看，几条 hybrid / adaptive 方向技术上可做但目前无人在同一系统里做全：
register_reply/initiate_chat 时顺带导出一个可选的 workflow DAG hint给下游调度器 [2308.08155]，使 Autellix 的 program 追踪 [2502.13965] 和 Halo 的 placement [2509.02121] 无需 non-clairvoyant 猜测。目前没有框架-调度器的结构直通接口。UserProxyAgent 是这些 CPU 工具的执行者 [2308.08155]，但 AutoGen 的拓扑设计（几个 agent、谁调工具）完全不考虑 CPU/GPU 负载平衡。一个 CPU-aware 的 AutoGen 调度器可在编排时就把 CPU-heavy 工具 agent 与 GPU-heavy 推理 agent 做 COMB 式重叠——编排层与 §2511.00739 的 COMB/MAS 调度融合是未探索的跨层组合。