事件驱动Agent框架排行榜：OpenEvent日志先行实测

OpenEvent的定位非常清晰：它是一层面向Agent场景的多模块协作基座，并不试图做端到端的Agent产品。它不碰业务语义，不内嵌业务协议，也不替上层模块定义schema——除了内置的系统广播协议外，其他协议都放在独立模块里，以可插拔方式按需接入。OpenEvent想统一的只有一件事：模块协作时共同依赖的事件中枢。

更进一步说，它是一套云原生的事件基础设施：协议、存储、模块和运行时边界都可以独立部署、独立演进、独立验证、按需扩缩，避免重新长成一个难以拆分的单体系统。

核心概念

消息队列解决了"怎么传"，RPC解决了"怎么调"，但多模块协作还面临四个更基础的问题：谁在行动？在哪里协作？按什么规则理解彼此？传递的最小事实单元长什么样？OpenEvent没有直接照搬现成的消息队列概念，而是围绕这四个问题，抽象出四个核心对象。

谁在行动：Principal

Principal是系统中的身份标识，可以代表用户、某个Agent、某个独立模块进程，或者某个系统账号。OpenEvent不关心这个身份背后的业务含义，只校验它是否与当前token绑定一致，并据此决定"能不能进这个Channel、能不能写这条消息"。它是所有动作的起点。

在哪里协作：Channel

有了身份，下一步是确定"在哪里"发生协作。Channel是一个带元数据和访问控制的局部协作域。每个Channel有自己的channel_id、name、visibility、members，以及protocol标记该域内部遵循的约定。它定义的是一批事件在谁的参与下、在哪个范围内流动。和简单的消息分桶相比，Channel更接近一个受控的协作场——Principal必须先满足Channel的访问规则，才能参与其中的事件流转。

按什么规则理解：Protocol

进入同一个Channel的模块，必须知道彼此在说什么。Protocol是贴在Channel上的一个标签，用来告诉接入方：这个Channel里的payload应该按哪套上层约定来解释。除了系统广播协议外，其他协议全部放在独立模块中以可插拔方式接入。OpenEvent主体只保存这个标签，不做schema校验，也不要求所有模块都能识别所有协议。它标记的是一门"方言"，中枢并不因此掌握这门语言。

传递什么：Message

身份、场所、规则都确定后，真正流动的是Message。它是Channel边界内最小的不可变事实单元，包含seq、channel_id、principal和payload：seq把它放进全局有序时间线，channel_id指明它属于哪个协作域，principal表明是谁发出的，payload承载真正的业务内容。OpenEvent的很多设计，最终都是围绕如何让Message被可靠写入、可控读取、准确追踪展开的。

四者的关系

这四个对象不是孤立的配置项，而是一套相互嵌套的关系：Principal定义动作主体，Channel划定协作边界并控制谁能进入，Protocol是贴在边界上的语义标签，Message则是沿着边界流动的事实载体。落到代码层面，就是：一个principal创建一个带protocol的channel，然后相关的principal按照protocol往里面写入message以实现通信或记录状态变化。OpenEvent想稳定下来的，正是这套主体、边界、约定与事实之间的关系。

全局顺序

很多系统都能传消息，但对Agent来说，"能传"远远不够。模型决策、工具执行、人工介入、外部回执、文件变化、定时任务——这些输入来源各异，如果各自散落在会话窗口、日志文件和内存状态里，系统就没有一个统一的事实坐标系来理解它们到底谁先谁后。另一个现实问题是，现在的Agent遇到网络抖动或人为中断，只能重新对齐环境，无法基于之前的断点继续任务。因为此前发生的事实没有按统一顺序持久化下来，恢复时根本找不到该从哪条记录接着处理。

OpenEvent的做法很直接：所有消息进入系统后，落进一条从1开始连续递增的全局序列，每条消息拿到一个seq。这个编号不是为了好看，而是让不同模块终于能围绕同一条时间线协作。某次人工指令在seq 100，某次工具执行结果在101，某次Agent决策又基于前面哪些已发生的事实——它们不再是一堆彼此隔离的快照，而是能被放回同一条序列上对照。

Agent出问题，往往不是因为"不会思考"，而是因为事后很难还原"它到底依据了什么事实行动"。一旦所有模块共享同一条事件序列，工程师就能沿着事实链理解系统行为，审计、排错、恢复和人工介入才有明确的抓手。更进一步，当Agent进程崩溃或需要重启时，只要从指定seq重新消费事件日志，就能精确恢复到崩溃前的状态，而不必重新对齐环境或依赖易失的内存快照。对强调治理与可控性的系统来说，全局顺序既是协作对齐的参照，也是精确状态恢复的基础。

模块协作边界

全局顺序解决了谁先谁后的问题，但还没解决"这件事归谁管"的问题。如果所有消息都堆在同一条总线上，没有局部边界，不同模块的业务事件很快会搅在一起，排查时难以定位，新增功能时牵一发而动全身。

OpenEvent在全局序列之上引入了Channel。它不是简单的消息分组，而是一个带协议标签的局部协作域。每个Channel绑定一个protocol，模块在这个边界内自行约定事件种类、payload结构和演进节奏，OpenEvent主体不介入这些语义解释。

这样，系统真正被统一的是顺序、访问控制、读写语义和传输骨架；真正被解耦的是各模块在各自Channel内部使用的业务语言。IM走im.v1，模型袋里走llm.v1，未来工具调用走tool.v1——它们不需要被压扁成一套全局统一的payload模型。新增模块时，不必回头修改一个越来越臃肿的中心协议，直接开一个新的Channel，挂上自己的协议标签即可，变化被限制在局部。

服务端不解释payload

中心服务既然能见到所有消息，一个很自然的诱惑就是顺手把协议校验也接过来——字段约束、结构检查、动作语义，一并做掉。短期看确实更完整，长期看却是把所有模块的协议演进绑在了自己身上。IM改一个字段要升级中心服务，模型袋里换一套输出格式也要升级中心服务，中枢迟早变成新的阻塞点。

OpenEvent直接回避这一步。服务端知道protocol标签的存在，但payload对它只是字节流，不做schema校验，也不理解业务语义。它只管顺序、权限、写入约束、读取语义和可追踪性；"这段内容到底是什么意思"留给上层模块自己解释。

业务协议变得快，基础设施变得慢。把协议解释权留在模块边界内，字段怎么增删、动作怎么表达、事件之间怎么关联，模块可以独立调整，不需要反过来牵动整个基础设施层一起发版。一个想长期稳定的事件中枢，克制比多做更重要。

会话放到协议层

前面说协议解释权留给模块，具体怎么落地，可以用IM模块来看。IM是一个独立项目，基于OpenEvent实现了im.v1协议。在它自己的定义里，一个IM会话就是一条protocol=im.v1的Channel，会话的静态信息——provider、session_id、session_type、members——放在Channel的description元数据里，不占用消息payload。

真正不断追加到事件流里的，是三类动态事件：

• sync.record：IM平台上真实发生了一条记录。由IM模块写入，data里带provider_message_id、msg_type、text、content_raw。它表达的是“平台上确实出现了这条消息”。
• send.request：业务模块想往IM平台发消息。由业务方写入，IM模块消费。payload里有request_id、msg_type、content、idempotency_key。它表达的是动作请求，和平台侧的真实记录分开处理。
• send.result：发送动作执行得怎么样。由IM模块写回，prev_seq指向对应的send.request，payload里带status、provider_message_id、error_code。它表达的是"刚才那个请求成功了还是失败了"，并不表达"群里出现了什么新内容"。如果成功，平台后续会把真实消息回调回来，再由IM模块写成sync.record。

假设某个业务模块想往飞书发一句“请审批Alice”。它先往im.v1的Channel写一条send.request；IM模块订阅到后调用飞书API；调用结束后回写send.result；随后飞书平台产生真实聊天记录，IM模块再同步为sync.record。同一件事在事件流里被拆成三步：想发什么、发得怎么样、平台上最终发生了什么。

会话仍然存在，只是放到了协议层。OpenEvent本体仍然不需要理解聊天业务，它只需要保证这几类消息都能按统一顺序进入同一个Channel，并继续受同一套访问控制和读写语义约束。至于im.v1字段怎么长、动作和记录怎么关联，这些属于独立IM模块的职责，不属于OpenEvent主体的内建能力。

访问控制

OpenEvent的访问控制直接嵌在事件骨架里，框架层面只回答最基础的三个问题：谁能读、谁能写、谁能管。更复杂的权限模型留给上层业务或网关自行扩展。

校验逻辑很直接：先确认“你是谁”，再判断“你对这个Channel能做什么”。身份靠principal + token确认，动作权限则落在Channel的visibility和members上。

Channel目前分三种可见性：

• public：所有人可读可写，元信息对所有人可见；
• protected：所有人可读，只有成员可写；
• private：只有成员可读可写。

无论哪种可见性，增删成员、修改Channel元数据的管理权限都只归creator。读写和管理是分开的，一个人可能能读能写，但改不了成员列表。

这套规则显然覆盖不了所有企业级场景，比如细粒度字段级权限、动态角色继承、临时授权等都没涉及。但对当前阶段来说，它提供了足够清晰的边界：规则少、行为可预期、接入成本低。如果后续真有更复杂的需求，更适合在模块层或网关层按需补充，避免把复杂度提前塞进基座。

轻量模块和DEMO

骨架本身离可用还差得远。OpenEvent主体只负责事件顺序和访问控制，真正让系统跑起来的是长在这套骨架上的确定性模块——把各Agent系统中重复出现的共性需求，抽象成可独立维护的组件。

目前已经实现的有三个。

IM模块基于im.v1协议，提供payload编解码、发布辅助，以及面向飞书/Lark点对点单聊的同步worker。它把外部IM平台上的真实消息同步成sync.record，消费业务侧写出的send.request，调用平台API后写回send.result。它不理解Agent的任务目标，也不关心模型怎么推理。

Model Proxy基于llm.v1协议，消费infer.request，调用OpenAI-compatible API，再把infer.result写回同一个模型Channel。对OpenEvent主体来说，这只是一条请求事件和一条结果事件。模型服务可以替换，协议可以演进，但中枢和大部分模块不受影响。

Agent Demo则是把上述模块串起来的最小闭环。它提供了一个聊天机器人，以及一套尽量简单的运行脚本，用来快速体验整套架构。

这个Demo里，每个会话绑定三类Channel：

• IM channel（protocol=im.v1）：承载用户输入、Agent回复请求和IM发送结果；
• Model channel（protocol=llm.v1）：承载模型推理请求和结果；
• WAL channel（protocol=agent.wal.v1）：承载Agent在发起模型请求前写下的前置提交记录。

用户在IM里发来一条消息，IM syncer先写入sync.record。Agent看到这条事实后，会先往WAL channel写一条llm.request.prepare，记录这次要处理哪些用户消息、写入模型请求前上一条模型请求在哪里；随后才向Model channel写入infer.request。model-proxy调用模型provider后写入infer.result；Agent再把最终回复写成IM channel里的send.request；IM syncer发送到IM平台并写回send.result。

这条链路看起来比“收到消息后直接调模型再回消息”多了几步，多出来的是可恢复、可审计、可解释的工程边界。Agent崩溃在WAL之后、模型请求之前，可以根据WAL补发；模型请求发出但结果未回，可以从Model channel恢复；IM发送请求已经写入但平台调用失败，可以沿着send.result排查。每一步都是事件，不再是散落在进程内存里的临时状态。

Demo的真正价值不是聊天功能，而是验证OpenEvent的模块边界能否跑通真实的Agent闭环。IM、模型袋里、Agent、查看面板各自独立维护，不通过私有API强绑定，只围绕同一条事件日志协作。换掉IM平台、换掉模型provider、增强Agent策略，理论上都发生在各自模块内部，不需要把整个系统推倒重来。

• IM模块：openevent-modules-im
• Model Proxy：openevent-modules-model-proxy
• Agent Demo：openevent-agent-demo

记录查询面板

OpenEvent还提供了一个独立的事件查询模块OpenEvent View，专门用来审计和排查问题。

它和普通的日志页面目标不同。普通日志是单点输出，排查时需要在多个服务的日志文件之间来回grep，再手动拼凑一条跨模块的因果链。openevent-view则按全局seq组织视图，支持按principal和Channel过滤，并且会根据payload的JSON结构做更适合阅读的展示。

实际排查时，工程师要回答的往往不是"某一行日志说了什么"，而是"用户消息在哪个seq进入系统，Agent何时准备发起模型请求，模型结果如何返回，IM发送动作是否成功"。这些事件分散在不同的Channel里，单行孤立日志很难还原这条链路。openevent-view把它们放在同一个查询视图里，按seq排好，因果一目了然。

项目地址：openevent-view

避免传统事件驱动架构缺陷

传统事件驱动架构中，一个服务发出事件后，下游什么时候处理完成是不确定的，中间会存在业务状态不一致的时间窗口；一个业务动作可能跨多个topic、多个broker、多个服务日志和多份本地状态；常见消息系统也往往只能保证单个分区、某个key或某个topic内部有序，跨分区、跨topic的全局顺序很难成立，从而导致顺序不清，排查问题困难。

OpenEvent的取舍刚好相反：它把模块协作收敛到一条全局有序日志里，任何进入系统的消息都有连续递增的seq。这相当于给系统提供了一个基于序号的逻辑时钟，所有基于这条队列的通信都可以用这个逻辑时钟对齐。对全异步的Agent场景来说，这比追求高吞吐更实际——Agent的关键路径本来就经过模型推理，这已经是慢操作；单条全局有序队列通常不会是最先出现的瓶颈。

传统架构还容易长成一张网：A发事件给B，B处理完发给C和D，D又触发E，链路被拆散到一堆主题和消费者里。Agent场景天然是另一种结构：行为围绕Agent决策展开，确定性模块围绕Agent提供能力。IM、模型袋里、文件系统、工具执行器这些模块只做两件事——把外部事实写入日志，消费Agent或业务模块的动作请求并回写结果。它们之间几乎不需要互相通信，形成近似星形的结构。

星形结构的直接收益是排查成本下降。模块不互相私聊，事实都回到同一条日志；动作请求和结果留在各自的Channel里；Agent的决策链可以沿着seq回放。事件风暴、环形触发、隐式依赖这些传统事件架构里的常见问题，也因此更容易被避免。

对于事件契约演化，OpenEvent尽量把边界显式化。Channel + Protocol定义了局部协作域：一个Channel说明消息在哪个边界内流动，一个protocol说明payload应该按哪套上层约定解释。im.v1、llm.v1、agent.wal.v1可以各自演进；OpenEvent主体只保存标签，不把所有业务字段塞进中心schema。破坏性变化也不应该偷偷改字段，而应该进入新的协议版本。

所以，OpenEvent的目标不止是“再做一个事件总线”。它试图修正传统事件驱动架构最容易失控的几个位置：让确定性模块尽量不互相通信，统一围绕Agent的决策链读写事实；把日志从分散变成集中有序，把一致性窗口变成明确的逻辑时钟，把契约从隐式变成Channel级显式，把恢复和审计从事后补丁变成事件骨架的一部分。

后续方向

OpenEvent还在早期阶段。接下来整个架构会继续朝更清晰的云原生边界演进：可替换的后端实现、独立部署的协议模块、更明确的运行时管理，以及更适合容器化和分布式运维的方式。

后续值得期待的方向包括：

• 工具调用；
• 更多IM平台的原生支持；
• 定时事件；
• 邮件；
• LogBased文件系统，自动将文件变更事件同步到OpenEvent。

这些能力都会以独立模块的形式存在，OpenEvent主体保持骨架的简洁与稳定，所有具体能力都在外围按需生长。

Kubernetes是把部署、调度、服务发现、扩缩容这些确定性问题沉淀成共同底座，从而成为云原生的基石。Agent生态也需要类似的工程基座：模型和策略可以随便换，但事件、状态、权限、审计和模块协作不应该每个项目从零搭一遍。OpenEvent要做的，就是Agent系统之下那层稳定、开放、可审计的基座。