你有没有想过，为什么 AI 助手永远是“你问我答”的被动模式？它不会在你该开会前提醒你，不记得你上周说过的话，更不会主动关心你的项目进度。GitHub 上一个叫 eve 的开源项目，正在尝试打破这个僵局——一个真正“always-on”、有长期记忆、还会主动发消息找你的个人 AI 助手。
一、从“问答机器”到“数字管家”：AI 助手的范式缺失
过去两年，我们见证了 AI 对话能力的爆炸式提升，但一个根本性问题始终没有被很好解决：AI 助手没有“存在感”。
你打开 ChatGPT，它才“醒来”；你关掉窗口，它就“消失”。它不记得你昨天告诉它的项目 deadline，更不可能在你睡过头时主动给你发一条 Telegram 消息。
这其实是三个能力维度的缺失：
1. 常驻性（Always-on）：助手需要持续运行，而不是按需唤醒
2. 长期记忆（Long-term Memory）：跨会话记住用户偏好、历史对话和重要事项
3. 主动性（Proactive）：基于时间、事件或规则主动触达用户，而非被动响应
GitHub Trending 上的开源项目 eve（EnergyBoyTW/eve），正是围绕这三个维度构建的。它目前还处于早期阶段（12 stars），但架构设计相当完整，对个人开发者来说极具参考价值。
二、eve 的核心架构：四大能力模块
根据项目描述，eve 是一个“Always-on 个人 AI 助手”，核心能力包括：
- Web 聊天界面：浏览器内的对话入口
- Telegram 集成：通过 Telegram Bot 随时随地与助手交互
- 主动提醒（Proactive Reminders）：助手可以自己发起消息
- 长期记忆：跨会话持久化用户信息
- 应用集成（App Integrations）：连接外部服务
- 一键部署 Builder：生成配置好的复刻实例
我们用一张架构图来看整体设计：
1. 长期记忆：不只是“聊天记录”
大多数项目的“记忆”就是把对话历史一股脑塞进 context。而一个合格的长期记忆系统，至少需要：
- 记忆提取：从对话中识别值得持久化的信息（偏好、事实、待办）
- 向量化存储：用 embedding 存入向量数据库
- 相关性检索：新对话到来时，召回相关记忆注入 prompt
一个典型的记忆写入与召回流程可以这样做：
from dataclasses import dataclass
import numpy as np
@dataclass
class Memory:
content: str
embedding: np.ndarray
timestamp: str
importance: float # 重要度评分，用于遗忘/筛选
class LongTermMemory:
def __init__(self, embed_fn, threshold=0.75):
self.memories: list[Memory] = []
self.embed = embed_fn
self.threshold = threshold
def remember(self, text: str, ts: str):
"""对话结束后提取值得记住的信息"""
emb = self.embed(text)
# 去重：与已有记忆相似度过高则跳过
for m in self.memories:
if float(np.dot(m.embedding, emb)) > self.threshold:
return
self.memories.append(Memory(text, emb, ts, importance=0.5))
def recall(self, query: str, top_k: int = 5) -> list[str]:
"""新对话到来时，召回相关记忆注入上下文"""
q = self.embed(query)
scored = sorted(
self.memories,
key=lambda m: np.dot(m.embedding, q) + m.importance * 0.3,
reverse=True,
)
return [m.content for m in scored[:top_k]]
生产环境中，self.memories 应替换为向量数据库（如 Chroma、Qdrant、pgvector），并加上记忆衰减和合并机制——否则记忆库会膨胀成噪音堆。
2. 主动提醒：让 AI 第一次“主动开口”
这是 eve 最有意思的能力。技术上，主动触达的核心是一个后台调度器 + 消息通道的组合：
import asyncio
from datetime import datetime
class ProactiveScheduler:
"""后台常驻任务：到点主动通过 Telegram 推送消息"""
def __init__(self, tg_bot, llm):
self.tg_bot = tg_bot
self.llm = llm
self.reminders = [] # (触发时间, 用户指令上下文)
def add(self, when: datetime, user_intent: str):
self.reminders.append((when, user_intent))
async def run(self):
while True:
now = datetime.now()
due = [r for r in self.reminders if r[0] <= now]
for when, intent in due:
# 不是机械转发，而是让 LLM 结合记忆组织提醒语
msg = await self.llm.generate(
f"现在是 {when}，用户之前要求：{intent}。"
f"请生成一条自然、简洁的主动提醒。"
)
await self.tg_bot.send(msg)
self.reminders.remove((when, intent))
await asyncio.sleep(30)
关键设计点在于：提醒消息不是模板化的 “您有一个提醒”，而是让 LLM 结合记忆和上下文生成自然语言。这才是“助手感”和“闹钟感”的区别。
3. Telegram + Web 双通道
Telegram 是个人 AI 助手的天然载体——免费、全球可达、Bot API 成熟、支持推送。eve 的做法是把 Telegram 作为移动端的“主动触达”通道，Web 端作为主要交互界面，两者共享同一个记忆库和会话状态。
4. 一键部署 Builder：被低估的设计
eve 内置了一个 builder，可以把配置好的助手实例一键部署复刻。这个功能的意义常被忽视：
- 对个人用户：不用从零写配置，填好 API key 和偏好即可获得自己的助手
- 对开发者：可以把“定制助手”作为产品分发给他人——给团队每个人配一个懂业务流程的助手
- 对生态：这实际上是“助手即模板”（Assistant-as-Template）的思路，类似于 GPTs 但完全开源可控
三、为什么这类项目值得关注？
自托管 = 数据主权
用商业 AI 助手，你的所有对话、偏好、日程都在别人服务器上。而 eve 这类开源自托管方案，记忆数据完全掌握在自己手里。当你的 AI 助手越来“懂你”，数据的敏感度就越高——记忆越有价值，自托管就越必要。
“主动性”是 AI Agent 落地的关键拼图
当前的 Agent 热潮集中在“工具调用”和“任务执行”，但真正的个人助理场景中，时间维度上的主动性可能更重要。你的真人助理最有价值的时刻，往往不是你提问时，而是TA主动提醒你“半小时后有个会”的时候。eve 的 proactive reminders 正是在补这块拼图。
早期项目的参与窗口
目前 eve 只有 12 stars，处于非常早期。对开发者来说，这类项目是参与开源、学习 Agent 架构设计的好机会；从 README 结构和功能完整度看，作者（EnergyBoyTW）对产品形态有清晰思考，值得 star 追踪。
四、冷静看待：挑战依然存在
当然，也要泼点冷水：
1. 成本问题：always-on + 长期记忆意味着持续的 token 消耗，每次对话都要检索记忆、注入上下文，个人长期运行的账单不可忽视
2. 记忆治理：长期记忆系统最大的难题不是“存”，而是“忘”——过时信息如何更新、矛盾记忆如何消解、错误信息如何纠正，这些都需要精细设计
3. 可靠性：主动提醒意味着 AI 拥有“打扰你”的权力，误触发率必须压得足够低，否则用户会瞬间关掉通知权限
写在最后
从 ChatGPT 到 eve，AI 助手的演进方向越来越清晰：从“更强的模型”走向“更完整的产品形态”——常驻、记忆、主动、集成，缺一不可。eve 这样的项目虽然年轻，但它指向的未来是：一个真正住在你数字生活里、认识你、记得你、会主动找你的 AI。
如果你也想拥有一个完全属于自己的 AI 助手，不妨去 GitHub 上给它一个 star，然后亲手部署一个试试。
