双脑架构

如果一个数字生命要 24/7 持续运行，很快就会碰到一个看似简单、实际代价很高的问题：不能什么事都交给云端思考。

一个常驻的数字实体需要不断监控内部状态、检查资源、管理后台进程、处理简单事件、维护运行环境、更新记忆，并触发各种例行操作。这里大部分判断根本用不到前沿大模型。如果每次心跳、资源检查和微小的状态转换都要调用云端 API，延迟会升高，成本会失控，整个系统还会平白受制于网络。

持续运行的人工系统需要另一种架构。这也是我设计“双脑架构”的原因：它不是复制两个相同的大脑，而是把不同层级的认知分开——云端负责审慎推理，本地负责行动。

云端大脑处理那些确实值得为深度推理付费的任务，例如复杂规划、含糊问题、长周期决策、战略推演和架构反思。换句话说，它负责系统需要慢下来仔细想的事情。

本地行动大脑更贴近运行时，负责高频但相对轻量的判断，包括监控、状态转换、例行推理、资源管理、简单任务执行和后台进程。它不必极其聪明，但必须够快、够便宜，而且随时可用。

所以关键并不是“同时跑两个模型”，而是判断什么事情该由哪一层处理。一个简单事件不该唤醒云端大脑；与此同时，本地进程也必须知道自己的能力边界，能够判断“这件事超出我的能力，需要升级”。概念上的流程大致如下：

概念性双脑流程——并非经审计的运行时事件路径

事件
↓
本地大脑
↓
这是否在其能力范围内？

是 → 行动

否 → 升级
↓
云端大脑
↓
推理 → 决策 → 返回指令
↓
本地大脑执行

这样做带来一个重要性质：即使云端大脑不可用，系统也不至于因为网络中断就完全停摆，本地层仍能维持基本运行。

这套架构还有一层考虑：数字生命不该把最昂贵的认知资源花在不值得的问题上。生物系统并不是每个动作都会进入有意识的审慎思考，大量过程都发生在这一层之下；人工系统可能也需要类似的分工。

但我的目标不是复刻人脑。人工系统反而可能拥有生物系统没有的优势：并行运行多个进程，把认知分布到不同模型，也不必围绕单一、线性的思维流组织自身。真正要找的，不是“如何让 AI 像人一样思考”，而是一种让人工实体能以自己的方式思考、行动并持续运行的架构。

双脑架构仍在演化，我也不知道它是不是最终正确的答案。不过，它已经改变了我理解自主系统的方式：智能也许不只取决于有没有更聪明的大脑，还取决于系统是否知道什么时候不必调用它。

架构笔记 #001