为什么越来越多 Agent 开始采用 Event-driven 架构

来源：抖音 @龙哥搞算法

性能瓶颈：架构决定上限

在 Agent 系统的性能优化中，90% 的人容易陷入一个误区，即认为瓶颈完全在于模型本身。实际上，架构设计往往才是决定系统效率的关键。如果仅仅将 Agent 简化为“思考、规划、执行、循环”，面试官或资深开发者早已预判这种回答过于浅显，未能触及系统设计的核心。

传统 Agent Loop：持续轮询的状态机

传统的 Agent Loop 本质上是一个持续轮询的状态机。其核心流程包括：

• Observe：观察输入
• Think：模型推理
• Act：调用工具
• Poll：继续等待

在没有事件发生时，系统仍然占用调度资源。这就像一个保安每隔一分钟就去检查一次大门是否有异常，无论是否有任务，这种“空转”都在无谓地消耗资源。当 Agent 需要处理大量异步任务时，这种机制的效率显然不足。

Event-driven：从主动找事，变成有事再干活

Event-driven（事件驱动）架构的核心在于“唤醒”。与传统循环不同，事件驱动不是主动去寻找任务，而是等待特定的事件发生。

核心组件：Event Bus

• 输入源：用户发消息、数据库更新、邮件到达、支付成功等均可成为触发 Agent 的事件。
• Agent 行为：当 Event Bus 接收到事件时，Agent 被唤醒。事件携带上下文信息，触发对应的工作流。如果没有事件发生，系统保持休眠，无需占用资源。

这种机制实现了“从主动找事，变成有事再干活”的转变。以客服系统为例：

• 传统 Loop：像每隔几分钟刷新一次工单系统，延迟较高且资源浪费。
• Event-driven：更像微信通知，消息来了直接弹窗，延迟更低、成本也更集中。

什么时候不应该使用 Event-driven？

虽然 Event-driven 在高并发场景下极具优势，但并非万能。面试官常问：“什么时候不要用 Event-driven？”答案并非“永远不用”，而是要谨慎用于复杂推理链场景。

以下场景更适合使用传统的 Agent Loop：

1. 科研 Agent：需要持续探索假设、比较证据、逐步收敛，这是一个连续的推理状态机。
2. 代码 Agent：需要跨文件理解、计划、执行、测试、修复，逻辑链条紧密。
3. 长链规划 Agent：整个推理过程本身就是连续的。

架构选型判断矩阵

在面试或设计架构时，可以参考以下判断矩阵：

核心结论

简单来说，事件驱动解决的是“什么时候干活”的问题，而 Agent Loop 解决的是“怎么干活”的问题。在高并发、异步场景下，善用 Event-driven 架构；在复杂推理、连续思考场景下，回归 Agent Loop 循环。