Event-driven 才是 Agent 性能瓶颈的解药吗？什么时候反而该用传统 Loop？
Agent 跑得慢，90% 的情况锅不在模型，在架构。架构选错，模型再强也是给一个漏水的桶灌水。
- 性能瓶颈在哪：不是 token 慢，是 agent 闲着没事干还在转圈
- 两种范式：Pull 模式（Loop 主动要任务）vs Push 模式（Event 主动叫 agent）
- 传统 Loop 不是死循环：真正的 ReAct / Plan-Execute 是有终止的思考-行动-观察链
- Event-driven 核心不是 push：是控制反转——agent 不用关心"什么时候该醒"
- 适用边界：Loop 适合推理密集，Event-driven 适合 I/O 密集 + 异步多源
- 反直觉：用错 Event-driven 反而更慢，因为它把"思考"也异步化了
- 实战选择：高并发客服用 Event-driven，长链科研推理用 Loop
什么时候干什么活，比怎么干活更决定成本——这是架构选择的第一性原理。
别再怪模型了，瓶颈在架构
如果 Agent 很慢，90% 的第一反应是"换更强的模型"。
这是典型的因果错配。Agent 慢，绝大多数时候不是模型推理慢，是架构在空转。
空转有两种典型形态：
- Loop 里的空转：Agent 没事干还在轮询，模型每 30 秒被拉起来问"有活吗？"，每次都消耗一整套 input token
- Event 链里的空转：Agent 收到一个事件，但事件是噪声或低优先级，模型被迫中断当前推理去处理，结果是"该干的事没干，不该干的事干了一堆"
性能优化的第一步，是先识别你现在的空转是哪一种，再决定该换 Loop 还是换 Event。
两种范式：Pull vs Push
把 Agent 想象成一个员工，Loop 和 Event-driven 是两种完全不同的管理方式：
| 维度 | Agent Loop（Pull 模式） | Event-driven（Push 模式） |
|---|---|---|
| 触发方式 | Agent 主动拉任务 / 自己思考 | 外部事件推过来 |
| Agent 状态 | 持续在线、连续推理 | 多数时间休眠，事件唤醒 |
| 成本结构 | 每步都要 LLM 调用 | 没事件几乎零成本 |
| 推理连续性 | 强，状态在 prompt 里 | 弱，每次唤醒要重载上下文 |
| 适用负载 | 计算密集、连续推理 | I/O 密集、多源异步 |
| 状态复杂度 | 低（线性的思考链） | 高（事件顺序、幂等、补偿） |
这两个范式不是非此即彼，而是对应不同 的工作节奏：
- Loop 是"深度工作模式"——坐下来，关上门，一口气把一个复杂问题想清楚
- Event-driven 是"协作消息模式"——消息来了看一眼，没事就放着
判断该用哪个，不是看技术酷不酷，是看你的 Agent 一天里到底在干哪种活。
"传统 Agent Loop" 到底在说什么
很多人对 Agent Loop 的第一印象是"不停思考-规划-执行-循环"。这个描述不准确，会让你选错架构。
真正的传统 Agent Loop（ReAct、Plan-and-Execute、Reflexion 这类）有以下特征：
- 有终止条件：要么模型判断"任务完成"主动
end_turn，要么达到最大步数 - 状态在 prompt 里累积：每一步的观察都追加进上下文，下一步基于完整历史决策
- 每步都调用 LLM：思考本身是 LLM 调用，行动可以是工具调用
- 单线推理：模型在每一步的决策空间是收敛的——上一步想明白了，下一步才有方向
它 不是 死循环轮询。死循环轮询是另一种东西（传统的 message queue consumer 模式），把它和 Agent Loop 混为一谈会让你在架构选型时直接踩坑。
Loop 适合的场景是 强状态依赖的连续推理——上一步的输出是下一步的输入，状态必 须保留。
Event-driven 真正的本质
Event-driven Agent 经常被误解为"响应速度更快"或"延迟更低"。这两个都是表象，不是本质。
Event-driven 的本质是控制反转：
- Loop 模式：Agent 自己决定"下一步该干什么"，节奏在自己手里
- Event 模式：外部世界决定"什么时候该干什么"，Agent 是被叫起来的
这个差别决定了 Event-driven 的几个关键属性：
- 可以并发处理多源事件：用户消息、数据库更新、webhook、定时任务、邮件——多个事件源可以同时驱动同一个 Agent
- 天然适合长生命周期：Agent 不需要一直在线，只在有事时被唤醒
- 状态管理变难：事件可能乱序到达、可能重复、可能丢失，要靠幂等性 + 事件溯源 + 补偿机制保证正确性
- 不擅长长链推理：每收到一个事件都得重新加载上下文，连续性被切碎
第 4 点是 Event-driven 的阿喀琉斯之踵，也是技术评审时最容易引发讨论的地方。
什么时候用哪个：场景判断
按工作负载类型做一个快速判断：
| 场景 | 典型代表 | 推荐范式 | 理由 |
|---|---|---|---|
| 高并发异步消息处理 | 客服 Agent、IM 助手 | Event-driven | 多源事件、突发流量、需要响应外部世界 |
| 长生命周期 + 多源触发 | 部署 Agent、定时巡检 | Event-driven | 平时无事，有事唤醒；不在线就是浪费 |
| 复杂多步推理 | 科研 Agent、代码生成 | Loop | 状态强依赖，拆开会丢上下文 |
| 工具编排 + 状态机 | 审批流、工作流引擎 | Loop | 状态转移有明确前驱后继 |
| 多 Agent 协作 | 协调者 + 工作者 | 混合：协调者 Loop，子任务 Event | 协调需要持续状态，子任务可异步 |
| 实时流式响应 | 聊天、代码补全 | Loop（短） | 单次会话内的推理链很短，但仍是推理 |
简单来说，Event-driven 解决的是"什么时候干活"，Agent Loop 解决的是"怎么干活"。
反直觉：Event-driven 用错地方反而更慢
很多人以为 Event-driven 一定比 Loop 高效，因为"没事件就不花钱"。这是错的。
Event-driven 在以下场景反而拖慢系统：
- 每个事件都要重新加载上下文：长会话的 Agent 被事件频繁唤醒，每次都要把历史重新塞进 prompt，token 成本可能比 Loop 高几倍
- 思考被 事件打碎：Agent 正在做长链推理，中间突然来了个低优先级事件，被迫中断去处理，事后还要从中断点恢复
- 幂等性补偿成本：事件可能重复到达，处理逻辑要写补偿代码，复杂度上去后调试成本陡增
- 调试困难：事件流不像 Loop 那样线性可读，出问题要追整个事件链，定位成本高
把"复杂推理"放进 Event-driven 是最常见的架构错误。Event 适合触发"轻量级判断"（"这个工单分给谁"、"这条消息要不要回"），不适合触发"长链思考"（"读完这 50 篇论文后给出综述"）。
实战选择：混合架构 + 判断流程
生产环境几乎没有纯 Loop 或纯 Event-driven 的 Agent，主流是混合：
判断流程可以简化成一个问题：
这一步是"做判断"还是"做思考"？
- 做判断（路由、分类、响应）→ Event-driven
- 做思考（规划、推理、生成）→ Loop
- 混合场景 → 编排层用 Event，单元内用 Loop
一句话总结
Event-driven 和 Agent Loop 不是技术选型，是工作节奏选型。看你的 Agent 一天里大部分时间在"等待外部世界"还是在"连续思考"，答案就出来了。
References
- 阿里一面 为什么越来越多 Agent 开始采用 Event-driven 架构？什么时候不应该使用传统 Agent Loop？ —— 龙哥搞算法, Bilibili