背景
最近在重构核心客服系统时，我们又遇到了那个熟悉又无力的场景：用户怒气冲冲地追问“我的货到哪了”，而系统只能反复推送三天前生成的“已发货”通知事件。事件本身没错，但它完全错过了用户此刻的真实意图——不是要确认“已发货”这个事实，而是想缓解“为什么还没送到”的焦虑。
这件事让我们重新审视一个信奉多年的架构原则：事件驱动架构（EDA）。在过去的确定性问题域里，它是解耦和伸缩的利器。但当用户开始用自然语言、带着复杂上下文和情绪与系统交互时，我们突然发现，仅仅对“发生了什么”（事件）做出反应，已经远远不够了。也许我们是时候讨论一种更贴近本质的范式：意图驱动。
一、 核心分野：是响应“事件”，还是理解“为什么现在问这个”？
两者的区别，可以用一个简单的类比：
事件驱动：像一套精密的多米诺骨牌。订单创建（事件A）推倒发货（事件B），再推倒通知（事件C）。流程清晰，但用户如果在中途伸手拦住问“现在到哪了？”，整个链条就懵了——因为“查询状态”不是预设的下一个骨牌。
意图驱动：像一个有经验的私人助理。听到“我的货呢”？他不会机械地复读发货单，而是立刻理解你的意图是“了解进度并缓解焦虑”。于是他主动查询物流、预估时间、甚至解释可能的延迟原因，将多个后台动作组合成一个连贯的响应。
问题的根源在于，用户的“目标”和系统的“事件”经常错位。 事件是离散的、事实性的。而意图是连续的、目标导向的，且深深嵌入在对话上下文和用户情绪中。我们当前的EDA系统，擅长处理前者，对后者近乎失明。
二、 意图驱动：不是替换EDA，而是在其上构建“语义层”
转向意图驱动，绝不是要拆掉运行良好的事件总线。相反，它是在坚实的事件基础设施之上，增加一个“意图理解与编排层”。
这个新层负责三件事：
1. 意图感知：
