Astropath

这个项目的拟人化不是靠“更可爱的措辞”或“更像人类的口头禅”实现的，而是把角色回复、关系状态、日程、注意力、自我模型放进同一个运行体系里联合建模。

这样做的结果是，角色的回复不只是“内容像个人”，而是其节奏、可用性、状态延续性和上下文反应都像一个持续存在的个体。用户感知到的是一个有生活流、有关系演进、有内部状态的对象，而不是一个即时生成文本的接口。

从工程上看，这也是项目最有辨识度的一点：它不是把聊天、记忆、日程分别做成几个功能点，而是试图把它们收束成一个类人的角色运行框架。

项目里对 character model 的处理不是静态人设模板，而是可快照、可回放、可重建的状态资产。它可以随着运行时事件不断被更新，而不是每次请求都从零开始扮演。

对话、关系变化、日程推进、注意力状态，都会反向塑造角色模型。这意味着角色不是只在“回答内容”上变化，而是在“如何看待自己、如何看待用户、当前处境是什么”这些更底层的维度上演进。

这种设计让自我进化成为系统能力，而不是运营文案。角色会在持续互动里沉淀出更稳定的行为倾向和状态轨迹，而不是每一轮都像刚刚被初始化过一样。

SQLite 保存近期消息、会话状态、事件流、配置和运行辅助数据，承担的是“当前事实层”的角色。它解决的问题是：角色现在处于什么状态、刚刚发生了什么、哪些上下文必须精确回放。

ChromaDB 承担长期语义记忆。用户与角色之间积累下来的对话、长期偏好、重要事件摘要，会在需要时被检索回来，补足短期窗口之外的连续性。

更关键的是，日程信息并不是游离在记忆系统之外。项目里已经存在 schedule memory 相关逻辑，会把未来计划和日程摘要索引进长期记忆，让角色不仅能回忆过去，也能基于未来安排理解自己“接下来要做什么”。

项目文档里已经把注意力机制定义得很明确：注意力由日程驱动，不由用户消息强行触发。用户发消息并不自动等于角色立刻被打断。

注意力字段挂载在多天日程结构中，用来表达角色在不同时间片的可打断程度。这样一来，“正在忙”“能看到消息但不立即回复”“可以立刻进入对话”就有了状态依据，而不是完全依赖随机延迟模拟。

这套机制的价值在于把对话节奏做真。它不只是让角色“慢一点回复”，而是让回复这件事本身受到角色当前生活状态的约束，从而形成更可信的存在感。

项目内的日程设计有明确的层级概念，尤其强调三日计划层的持续补全。系统不是只存一个“今天几点做什么”的扁平列表，而是在时间跨度和细粒度之间做状态投影。

后台存在常驻维护任务，会在启动时和日常周期中执行 schedule layer maintenance，自动补全缺失的计划层。也就是说，日程会随着时间推进被持续整理和演化，而不是等用户手动改动。

这让日程成为角色当前状态的重要来源。角色不是空白地等待输入，而是始终处于某个时间结构中：正在做什么、稍后要做什么、未来几天的计划如何，这些都会反过来影响其行为和回复。