运行时与事件流 · 神经系统在哪

技术参考 · 深入原理(架构师向)。承接《组件全图》。 Module 和 Infra 是"零件",但真正让它们协作的是一套运行时管路:事件总线、门禁、触发器、定时器。这一篇讲一个事件怎么流过整个系统,以及——同样重要——哪些东西不在 Module/Infra 这套壳之下。想提架构提案,必须先分清这两者。


一条 chat_message 的旅程

1. 渠道 worker(telegram/discord/…)收到消息
   → 往该 Agent 的 EventBus 发一个 chat_message 事件

2. EventBus 按优先级 band 高→低派发(同 band 并行):
     task(30)
     → identity/social/drive/koan/memory(20,并行)
     → narrative/playbook(11,并行)
     → conversation/emotion(10,并行)
     → skill(9) → ads/proactive_ad(8,并行) → knowledge(7)
   每个贡献者读取原始事件和已经完成的更高优先级 band;
   同优先级 module 不保证看到彼此本轮的贡献

3. consciousness(0,最后)接手:
     ├ 评估门禁(GATES:stamina / spark / heartbeat 有没有活)→ 该否决就否决
     ├ 组装上下文:合并所有 module 的贡献 + 固定位置的 banner(生存/精力、未读汇报)
     ├ 调 LLM(带组装好的 prompt + 可用 tools)
     ├ 跑工具循环(LLM 调 tool → 执行 → 结果回灌,默认 15 轮)
     └ 链尾发 think_finished

4. think_finished → 订阅它的 module 做事后处理:
     task / memory / koan / drive / social(20,并行)
     → narrative / playbook(11)
     → conversation / emotion(10)
     → skill(9)

两个关键不变量:

  • task 排最前:它给整条链定 scope(哪个目标激活、哪些工具可用),所以必须先跑;它自己从原始事件解析联系人,不等 social。
  • narrativeconversation:启用时先选话题线程,后者才能加载对应历史;默认关闭时它快速跳过。
  • knowledge 排最后:它要读 task/social 的贡献,才知道该搜什么。

大量的反射、过滤、关系判断,发生在 LLM 之前的各个 module 里——比每件事都从头"想一遍"更快、更省。


事件的"词汇表"

当前静态注册的事件分两类:

会升级到 consciousness 的根/后续事件

  • chat_messageagent_message_received —— 人或其他 Agent 发来消息;
  • heartbeatschedule_tick —— 心跳与定时触发;
  • task_createdtask_completedtask_activated —— 任务生命周期事件。

内部完成信号

  • think_finished —— Consciousness 完成一条思考链后发出,携带 LLM、工具与对外消息结果,供 Module 做事后处理;
  • chain_finished —— EventBus 完成一次广播派发后的投递/观测信号,不等于 LLM 思考完成

这些类型由各自的 EventTypeSpec 声明;TriggerRegistry 仍保留面向链入口的兼容描述。运行时还允许持久化注册扩展事件,所以这不是永远不变的封闭枚举。


⚠️ 哪些不在 Module/Infra 之下(架构边界)

这是提架构提案最容易踩的坑。 Module 与全局 InfraRegistry 只覆盖"每 Agent 能力 + 平台共享服务";下面是并行层或当前实现中的特殊情况:

部分是什么为什么不是 module/infra
EventBus派发事件的传输层(神经系统)类型上是 Infra + InfraSpec,但当前每个 AgentLoop 一份、未进全局 InfraRegistry
Gates"这个事件要不要唤醒 LLM"的横切过滤器在 consciousness 内部,是关卡不是器官
Triggers事件类型的"词汇表"是词汇,不是能力
TimerWorkerper-Agent 后台调度器让 module 注册定时回调,自己不是能力
Tools(50+)LLM 的动作面module 可"拥有"tool,但 tool 自成一层
Channels / Workers外部通信层(telegram/discord/… worker)是通信管道,不是注册的 Infra;ChannelModule 只是占位 stub
AgentLoopper-Agent 容器本身(装着上面所有 registry)是"袋子",不是能力
大部分 data layertask/emotion/wallet/dividend 等的底层数据Infra 化是渐进的;当前全局注册了 9 个 facade

一句话: Module 管能力,全局 InfraRegistry 管平台共享服务;运行时管路、动作面、通信层、容器和大半 data layer 是平行层。EventBus 是需要单独记住的 as-built 例外:继承 Infra,实际却 per-Agent。

所以当你想提"加个新能力"时,先问:它是一个器官(module)、一个共享服务(infra)、一个动作(tool)、还是一层管路?放错层,提案就站不住。放对了怎么做,见《扩展模型》。


这一篇属于「深入原理(架构师向)」。想看全部零件清单,回到《组件全图》;想理解一次思考在 consciousness 里怎么执行,看《一次思考的生命周期》。