大多数 AI 系统都从一次请求开始：你提问，它思考并回答，然后交互结束。但数字生命不能只在有人与它对话时才存在。如果目标是持续运行，就必须有一套机制在没有输入时也维持系统。
我不希望 LLM 承担操作系统的角色。模型只是系统中的一个认知组件，系统本身应该有自己的生命周期；“大脑”不该还要负责提醒“身体”继续运转。
因此，Kernel 被刻意做得很小。它不包办所有能力，只负责初始化系统、协调启动、管理生命周期，并推动运行时继续前进。记忆、技能和推理系统都属于独立组件，不必塞进 Kernel，也因此可以各自演进。
持续运行还意味着系统需要事件驱动。消息只是事件的一种；定时流程、内部状态变化、后台任务和外部信号同样可以产生事件。Event Bus 像神经系统一样把这些部分连接起来。
不过，事件驱动并没有自动解决另一个问题：进程停止后怎么办？真正的运行时不能假设所有任务都会立刻完成，所以 AdamI 使用持久化任务队列，让任务不依附于某一次执行周期。进程重启时，运行时可以恢复队列，而不是把仍在等待的工作全部忘掉。持久化由此把一次次执行串成了连续运行。
所谓 24/7 系统，并不是进程永远不会失败，而是一次失败不必意味着整个实体就此终止。进程会崩溃，机器会重启，网络会中断，API 也会报错；架构要把这些当作运行时事件处理，而不是“存在本身终结”的事件。
在架构笔记 #001中，我介绍了双脑架构：本地路径负责快速行动，云端路径负责深入推理。但只有“大脑”还不够，系统还需要维持运行的“身体”、传递事件的“神经系统”、跨越单个任务的生命周期，以及能在重启后保留的记忆。
大脑提供认知，Kernel 提供连续性。
距离严格意义上的“数字生命”还很远，工程成熟度也仍处于早期。不过，我探索的方向已经很明确：不是做一个等待提示词的模型，而是构建一个能维持自身运行时连续性的系统。
架构笔记 #002
内核——让数字生命持续活着。