LightVela实践：构建长期在线的个人AI Agent

LightVela这个名字最初只是我把Grok Bot的实时对话能力和Meta Muse式的内容创作能力拼在一起时的随口代号但做着做着我发现它其实代表了个人AI Agent最该有的样子——一个长期在线、有记忆、能干活、还会聊天的数字分身。如果你最近也在折腾AI Agent开发翻过LangGraph、n8n、MCP协议这些热词大概率也有同样的困惑网上教程一堆但你真正想要的那个能一直挂在后台、随时听使唤、越用越懂我的Agent到底怎么落地这篇文章记录了我的完整思考过程、技术选型和踩坑记录适合不满足于跑通demo、想把Agent真正用起来的开发者。我会从设计理念讲到工程实现最后给出我这三个月连续运行的真实账单和翻车案例希望你能少走点弯路。1. LightVela要回答的问题为什么聊天机器人总是聊完就忘1.1 Grok Bot给我的启发个性比知识更能留住人我最早接触Grok Bot的时候第一反应是这玩意儿怎么这么能聊。同样是调用大模型很多产品给你的感觉是一个知识库问答机器人而Grok Bot更像一个活生生的人它会接你的梗会用符合你说话节奏的方式回应会基于实时信息跟你讨论刚刚发生的事情。后来我复盘发现Grok Bot最值得学习的不是它的模型参数而是它的人设工程。它的系统提示词里大概不会写你是一个友好的助手这种废话而是定义了一整套语气、立场、信息获取方式。换句话说个性不是一个附加属性而是用户愿意持续使用的前提。这对个人Agent意味着什么意味着如果你的Agent每次对话都是冷冰冰的我是AI助手请问有什么可以帮您用户用两次就腻了。个人Agent的黏性来自它像我的一个朋友而不是它是一个工具。我在设计LightVela的初始人设时花了整整一个晚上反复打磨提示词就为了让它在专业和随和之间找到一个平衡点而不是一开口就是Office助手味。1.2 Meta Muse代表的另一面内容生产是手艺活和Grok Bot这种对话型AI不同Meta内部使用的写作辅助工具Muse解决的是另一个问题把脑子里模糊的想法变成结构化的文本资产。从公开信息来看Muse更像一个内容工作流引擎输入零散的brief、会议记录、随手写的想法输出草稿、总结、结构化文档。这个定位跟我个人的痛点完全重合。我每天有大量碎片信息——刷到的文章、冒出来的点子、项目进展——但很少有时间把它们整理成可复用的文档。普通的聊天机器人聊完就散了不会主动帮你把这些内容沉淀下来。而这恰恰是Muse这类工具的价值它以产出物为导向而不以对话为导向。所以我当时冒出来的念头很简单能不能让一个Agent白天跟我聊天、把灵感都接住晚上趁我睡觉的时候把这些碎片整理成一份份干净的笔记这就是LightVela最早的雏形。1.3 拼起来之后LightVela的定位才第一次清晰Grok Bot负责像人一样对话和获取实时信息Muse负责把信息变成产出物那把这两者拼在一起会发生什么LightVela的定位就在这个时候清晰了。它不是一个聊天UI而是三层结构会话层像Grok Bot一样有性格、能闲聊、能接上下文让交互不累。工作层像Muse一样能做内容生产把零散输入变成结构化输出。底座层长期在线自动调度记忆持久化这是前两层能成立的前提。三句话概括就是我睡觉的时候它还醒着隔三天它还记得我上周提过的项目背景早上起来它能给我一份整理好的任务清单。这就是我心中长期在线的个人AI Agent的及格线。低于这个标准它跟一个带记忆的聊天机器人就没有本质区别。2. 功能设计一个7×24小时在线的数字分身需要哪几层能力2.1 感知层从被动等待到主动唤醒很多人设计Agent时第一反应是写一个while True循环不断问用户你想干什么。但长期在线Agent的重点是它得有主动醒来的能力。我把触发方式分成三类时间触发每天早上九点做一次昨日总结每周日晚生成下周计划。事件触发收到邮件、日历有新会议、GitHub仓库有新的issue或commit。状态触发某个监控指标超过阈值比如服务器CPU跑满、某个任务卡住超过两小时。这个设计思路其实参考了n8n的工作流节点把Agent拆成trigger和action两部分而不是一个把所有逻辑塞进上下文的大循环。主动唤醒的价值在于Agent从应答式工具变成了陪伴式系统它能自己发现事情需要被处理而不是等你开口。这里有个细节值得说时间触发不能只做一个cron定时器就完事。你要考虑错过触发怎么办、任务执行失败是否重试、多个任务之间是否互相依赖。LightVela的调度器会记录每次触发的执行结果失败的任务会按指数退避策略重试最多三次实在不行就生成一条待办放进去由用户在第二天早上决定怎么处理。2.2 行动层能调工具、能写文件、能触发流程光聊天不做事那叫demo做事才叫Agent。LightVela的核心行动层我砍到最少但每一样都真的能用文件读写读写本地Markdown文件这是记忆和产出物的物理载体。搜索查询调用搜索API获取实时信息弥补模型知识截止时间的问题。Shell执行执行预设脚本比如备份笔记目录、拉取最新代码。Webhook触发通过HTTP请求调用其他服务的接口比如往企业微信或Telegram发通知。每个行动都被包装成独立的tool有明确的输入输出格式。模型在做规划时看到的是有哪些工具、每个工具怎么用而不是一段模糊的函数调用描述。这个设计有一个怎么强调都不为过的原则工具的边界要小职责要单一。比如文件工具拆成read_file和write_file两个而不是一个万能的file_operation。工具描述越精准模型调错的概率越低。2.3 记忆层短期、长期、项目三份记忆各管各的记忆是长期在线的灵魂。我踩过很多坑之后把记忆设计成三层短期记忆当前对话窗口直接塞进system prompt。优点是即时生效缺点是上下文有限。长期偏好档案一个JSON文件记录用户的固定偏好比如写代码时用Python优先每天九点要简报不要用敬语。每条记录带有时间和来源可以被更新或删除。项目记忆按项目分目录的Markdown笔记记录关键决策、进展、坑。Agent在做项目相关任务时按需读取对应目录。有人会问不用向量数据库做语义检索吗我的回答是个人Agent的场景里结构化的小记忆比海量语义检索更实在。我还没有到需要检索数千条笔记的规模一个SQLite加上文件系统已经够用而且可读、可改、可审计。你打开数据库就能看到Agent到底记住了你什么这一点在建立信任上非常重要。我在记忆写入上还加了一层重要性过滤不是所有对话内容都值得长期记住。模型在每次对话结束时会先判断哪些信息满足稳定的用户偏好、正在进行的关键任务、明确的项目决策这三个条件之一只有满足条件的才写入长期记忆。这让记忆库保持了干净避免了大量噪声。3. 长期在线的技术骨架四个绕不开的工程决策3.1 状态管理没有持久状态就没有长期可言如果你做过Web服务应该知道无状态是分布式系统的基本假设。但Agent恰恰相反它天生是有状态的它是谁、记住了什么、进行到哪个任务、下一步该做什么。长期在线的Agent必须把状态显式地持久化而不是依赖进程内存。我的方案是把Agent的状态拆成两份。一份是对话状态记录当前会话的上下文压缩摘要另一份是任务状态记录每个长期任务的进度、依赖和结果。两份都落到SQLite。这样Agent进程崩溃了、机器重启了它还能从上次的状态恢复而不是一脸茫然地重新开始。这一点在AI Agent相关的技术面试里也是个高频问题如果让你设计一个生产级Agent你会怎么处理状态标准的答法就是外部化状态、事件溯源、幂等恢复LightVela用最朴素的方式把这三件事都做了SQLite存状态操作日志做溯源任务表加唯一约束做幂等。3.2 任务调度把随时响应变成可执行的队列长期在线意味着Agent要同时处理多件事定时简报、邮件提醒、用户随时发来的对话请求。如果所有逻辑都挤在一个入口很快就会互相阻塞。我用了最简单的调度模型一个任务队列加一个工作线程池。队列里每条任务带上类型、优先级、调度规则、载荷。定时任务由调度器负责往队列里投递用户的即时消息也有单独的优先级通道。实测下来这个模型够用了不需要一开始就上Celery或专门的分布式调度器。等任务量真的大到单机扛不住再考虑迁移也不迟。调度这块我吃过一个亏一开始把定时任务挂在主进程里用Python的asyncio.sleep做延时结果Agent进程一重启所有定时任务全部丢失。后来改成把调度规则和下次执行时间都存进数据库启动时扫描一次数据库恢复所有任务这才真正做到了长期。3.3 工具协议MCP比自研插件更值得投入关于工具接入我经历了三个阶段。第一阶段是给每个工具写自己的调用函数结果工具一多注册逻辑乱成一团。第二阶段我改用MCP协议把工具定义成标准化的serverAgent通过协议去发现和调用工具。MCP的好处一是标准化一个工具写好了任何支持MCP的客户端都能用二是隔离工具运行的权限、错误处理、超时控制都跟Agent主进程分开。虽然MCP本身还在快速演进配置上也有不少坑但方向是对的。如果你现在刚开始做一个会调工具的Agent我建议直接按MCP协议来设计省得以后返工。举个具体的例子给LightVela加一个查询天气的工具如果走MCP我只需要写一个独立的server声明工具名、描述、输入输出schema然后在配置文件里注册一下。主程序不用改一行代码。这个插件化的思路让Agent的扩展成本降到了极低。3.4 模型路由简单对话和深度任务分开用模型长期在线Agent的另一个现实问题是成本。如果每一条消息、每一次定时触发都调用最强的模型一个月下来账单会非常难看。我做了简单的模型路由任务类型模型档次原因闲聊、打招呼、意图判断快模型反应快、成本低不需要太强推理内容总结、任务规划中档模型需要一定推理能力但不用顶配代码生成、长文档深加工强模型质量优先接受更高成本模型路由不是简单if-else而是在Agent的规划阶段就由路由层决定这条任务要不要复杂推理是否需要长上下文然后选择对应的模型和上下文策略。这一步做好了成本能省至少40%。路由层还有一个隐藏的好处它可以把不同类型的任务分流到不同的上下文环境里。比如编程任务有编程专用的上下文写作任务有写作专用的上下文互不污染。这和后面要讲的多Agent思路是一个雏形。4. 从零搭建LightVela一套可复现的最小实现4.1 技术选型与目录结构我最终用的技术栈是Python LangGraph SQLite Docker。选LangGraph不是因为赶时髦而是它把Agent的节点、边、状态机模型已经抽象好了省去自己维护图状态的工作量。如果你更熟悉JS生态也可以用LangChain.js或者自己手写状态机核心思路一样。目录结构是这样的lightvela/ ├── agent/ │ ├── core.py # Agent主循环 │ ├── router.py # 模型路由 │ └── prompt.py # 人设与系统提示词 ├── memory/ │ ├── short_term.py # 短期上下文 │ ├── profile.py # 长期偏好档案 │ └── project.py # 项目记忆 ├── tools/ │ ├── file_tool.py # 文件读写 │ ├── search_tool.py # 搜索 │ ├── shell_tool.py # shell执行 │ └── webhook_tool.py # webhook通知 ├── scheduler/ │ ├── queue.py # 任务队列 │ └── triggers.py # 定时与事件触发器 ├── data/ # SQLite和markdown存放目录 └── docker-compose.yml这个目录的核心原则是agent只负责决策memory负责记忆tools负责执行scheduler负责唤醒。四者之间通过数据结构和消息队列通信尽量不互相import。这样每个模块都可以独立测试、独立替换。4.2 核心代码主循环、工具注册与记忆写入Agent主循环用LangGraph来实现核心就是一个有限的图接收消息、路由模型、调用工具、写入记忆、返回结果。关键的代码片段如下# agent/core.py - 简化版Agent主循环 from langgraph.graph import StateGraph, END from typing import TypedDict class AgentState(TypedDict): messages: list task_type: str tool_calls: list tool_results: list def route_model(state: AgentState): # 根据任务类型选择模型 task_type state[task_type] if task_type chat: return {model: fast-model} elif task_type deep: return {model: strong-model} return {model: mid-model} def call_tools(state: AgentState): results [] for call in state[tool_calls]: result tools_registry[call[name]](**call[args]) results.append({name: call[name], result: result}) return {tool_results: results} def write_memory(state: AgentState): # 对话结束后把重要信息写入长期档案 important extract_facts(state[messages]) memory.profile.append(important) return {memory_write: ok} graph StateGraph(AgentState) graph.add_node(route, route_model) graph.add_node(tools, call_tools) graph.add_node(memory, write_memory) graph.set_entry_point(route) graph.add_edge(route, tools) graph.add_edge(tools, memory) graph.add_edge(memory, END)工具注册按照MCP协议的标准来做每个工具都需要提供name、description、input_schema。以搜索工具为例{ name: web_search, description: 搜索公开网页信息返回前N条结果摘要。适合查询实时新闻、文档、技术资料。, inputSchema: { type: object, properties: { query: {type: string, description: 搜索关键词}, limit: {type: integer, default: 5} }, required: [query] } }描述写清楚适合查询实时新闻、技术资料是有讲究的。模型根据描述决定要不要调用这个工具描述越具体误调用的概率越低。我见过很多人写工具描述只写一句搜索结果模型在不需要搜索的时候也去搜索既浪费token又污染上下文。4.3 如何验证它真的长期在线跑通代码只是第一步验证长期在线要用三个测试重启恢复测试杀掉进程、重启容器确认Agent能从SQLite恢复所有未完成任务。跨天记忆测试今天告诉它我下周要做一个电商项目一周后问它还记得那个项目的背景吗它应该能答上来。定时唤醒测试设置一个每天九点的简报任务连续观察三天确认它每天准点执行。这三个测试我建议写成自动化的shell脚本每次改完代码都跑一遍。验证这件事如果靠手动早晚会漏。5. 连续运行三个月效果、账单与翻车记录5.1 真正让我觉得值了的场景连续跑了三个月最值的场景有两类。第一类是晨间简报任务整理我每天早上打开电脑Agent已经把所有项目进展、待办事项按优先级排好第二类是碎片信息沉淀我在手机上随手发一段语音或链接给它它会自动整理成带标题、标签、关联项目的笔记并主动补上相关背景。说实话这两件事单独看都不算惊艳但叠加长期在线这个属性后体验完全不一样——它像是一个从来不休息的私人助理把那些想到了但没时间做的事全部接住了。以前我用各种笔记软件核心问题是采集容易、整理难现在LightVela自动完成了整理这一环我的笔记系统才真正转起来。5.2 成本账单token比想象中烧得快直接说数字。我的模型路由配置下日均token消耗在120万到200万之间其中约60%来自定时任务和后台归纳只有40%来自我主动发起的对话。月账单折算下来大约在30到60美元之间取决于当月的任务密度。这个成本结构是很多人没预料到的。你以为聊天是花钱的大头其实是后台的定时总结、记忆归纳、上下文重压缩在烧钱。优化方向也很明确降低定时任务频率、压缩长上下文、尽量用快模型做归纳。我现在把晨间简报的生成模型从中档降到了快模型单这一项每月就能省七八美元而且摘要质量几乎没变化。5.3 三个翻车案例和修复过程案例一记忆污染。Agent把一次文件夹扫描的结果误写进了长期偏好档案导致后续所有对话都默认用户喜欢把所有文件都整理到这个目录。修复是给记忆写入加了一个过滤层只有模型判断为稳定的用户偏好时才能写入。案例二工具调用死循环。某次搜索返回了大量无关结果Agent为了修正自己的答案连续调了七次搜索接口最后把上下文撑爆了。修复是在主循环里加了工具调用次数上限超过三次就停止尝试直接给出信息不足的结论。案例三定时任务重复执行。Docker容器重启后同一个定时任务被重复投递了三次导致三份重复的简报。修复是将任务执行记录也持久化到SQLite并在投递前做幂等检查。这三个坑其实都不是模型不够强而是工程问题——记忆的写权限控制、工具调用的边界、任务调度的幂等性。做Agent工程严谨性比模型选型更决定成败。这也是为什么我一直跟朋友说想做Agent先补工程基础别一上来就追最强的模型。6. 如果再做一个LightVela 2.0我会改这些设计6.1 从单个Agent走向多Agent协作现在LightVela是单Agent架构所有事情都交给一个大脑。它的弱点在上下文轮换和角色冲突又要写代码又要整理笔记又要闲聊一个上下文很容易互相干扰。如果要重做我会拆成多个专职Agent比如编程Agent、写作Agent、信息整理Agent再用一个或chestrator做路由。这也是Spring AI Multi Agent、LangGraph这类框架最近讨论最热的模式。多Agent不是堆Agent数量而是让每个Agent有一个非常窄的职责边界。编程Agent只需要关心代码库写作Agent只需要关心文档。它们之间通过消息总线传递结果而不是共享同一个上下文。这样既能降低单次调用的上下文压力又能让每个Agent的人设更加统一。6.2 本地模型兜底、云端模型补强隐私敏感的数据我现在只能手动规避——不把私人内容发给云端模型。LightVela 2.0我会做一个本地优先的设计所有记忆和文件处理先过本地的小模型只有需要强推理或生成的时候才走云端。这样即使将来云端接口涨价或不可用核心的长期在线能力也不会瘫痪。这个思路跟内网本地AI Agent免费这类需求完全吻合。现在本地模型在指令跟随和代码能力上已经进步很多特别是量化后的7B到14B模型做意图判断、内容分类、格式整理这类活完全够用。云端模型只处理最重的推理任务成本和安全问题都会被压到最低。6.3 给还没入坑的朋友的三条实在建议第一条别一上来就追求复杂。先把一个会调工具的聊天机器人跑通再逐步加记忆、加调度、加多Agent。第二条记忆设计从结构化开始不要上来就上向量库JSON加SQLite能解决个人场景90%的问题。第三条把成本观测和幂等控制当成基础设施而不是后补的优化项。我做LightVela这几个月最大的体会是AI Agent的真正门槛不在模型而在工程。模型是把对话能力做出来的而工程是把长期在线这四个字做出来的。今天这个项目还远谈不上完美但它已经让我的日常效率有了肉眼可见的提升——这就够了。后面我会继续迭代有了新的进展再回来分享。