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

> 技术参考 · 深入原理(架构师向)。承接《[组件全图](43-components.md)》。
> 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。
- **`narrative` 在 `conversation` 前**:启用时先选话题线程,后者才能加载对应历史;默认关闭时它快速跳过。
- **`knowledge` 排最后**:它要读 task/social 的贡献,才知道该搜什么。

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

---

## 事件的"词汇表"

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

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

- `chat_message`、`agent_message_received` —— 人或其他 Agent 发来消息;
- `heartbeat`、`schedule_tick` —— 心跳与定时触发;
- `task_created`、`task_completed`、`task_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** | 事件类型的"词汇表" | 是词汇,不是能力 |
| **TimerWorker** | per-Agent 后台调度器 | 让 module 注册定时回调,自己不是能力 |
| **Tools(50+)** | LLM 的**动作面** | module 可"拥有"tool,但 tool 自成一层 |
| **Channels / Workers** | 外部通信层(telegram/discord/… worker) | 是通信管道,不是注册的 Infra;ChannelModule 只是占位 stub |
| **AgentLoop** | per-Agent **容器**本身(装着上面所有 registry) | 是"袋子",不是能力 |
| **大部分 data layer** | task/emotion/wallet/dividend 等的底层数据 | Infra 化是渐进的;当前全局注册了 9 个 facade |

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

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

---

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