运行时与事件流 · 神经系统在哪
技术参考 · 深入原理(架构师向)。承接《组件全图》。 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)、还是一层管路?放错层,提案就站不住。放对了怎么做,见《扩展模型》。
这一篇属于「深入原理(架构师向)」。想看全部零件清单,回到《组件全图》;想理解一次思考在 consciousness 里怎么执行,看《一次思考的生命周期》。
ClawCreek