任务不怕重启丢：Browser Use Desktop 会话持久化（SQLite）设计与原理剖析-北京尧图网络

【免费下载链接】desktopBrowser Use Desktop App项目地址https://gitcode.com/gh_mirrors/desktop65/desktop点击查看免费下载Browser Use Desktop 是一款 AI Agent 浏览器桌面应用你把任务丢给它它会自己打开网页、点击、填写、抓取数据。但这类任务动辄跑几分钟甚至更久——如果应用在任务中途重启或崩溃会话记录会不会全部丢失答案是不会。Browser Use Desktop 用一套基于 SQLite 的会话持久化Session Persistence机制把会话状态、完整事件流和附件文件全部落盘到本地数据库应用重启后会话列表、暂停状态、引擎对话 ID 都能原样找回。本文带你从零看懂这套设计的核心原理。为什么选 SQLite 做会话持久化桌面应用要持久化会话这种复杂数据状态、消息流、二进制附件、成本统计可选方案其实不少JSON 文件、内存数据库、远程 API……而 Browser Use Desktop 选择了SQLite原因很实在考量SQLite 给出的答案部署复杂度单个.db文件无需任何数据库服务器崩溃安全WAL预写日志模式进程被杀也不会丢已提交数据并发读写WAL 模式下读写互不阻塞主进程可高频写入事件数据形态关系表 BLOB天然适合元数据事件流附件三层结构迁移能力user_version 增量 migration老库自动升级数据库文件位于 Electron 的标准用户数据目录下应用启动时由 index.ts 一行代码创建const sessionManager new SessionManager(path.join(app.getPath(userData), sessions.db));也就是说你在 macOS 上可以在~/Library/Application Support/下找到这个sessions.db文件它就是全部会话历史的家。三层表结构会话、事件、附件各司其职打开 SessionDb.ts 的建表逻辑数据库共有三张表职责划分非常清晰1.sessions表每个会话一行这是会话名片。每个会话一行记录列出了你关心的几乎所有元数据身份与来源idUUID 主键、prompt、origin_channel、origin_conversation_id状态机status取值限定为 6 种——draft / running / stuck / paused / idle / stopped见 db-constants.ts非法状态在写入前就会被拦截现场信息primary_site主要访问的站点如example.com、last_url最后一个可恢复的 URL引擎指纹engine、engine_session_id、model、auth_mode——重启后凭这些字段让会话回到原来的引擎里继续聊成本统计cost_usd、input_tokens、output_tokens、cached_input_tokens2.session_events表完整的事件流日志会话执行过程中产生的每一条事件用户输入、Agent 输出、通知、错误……都以 JSON 形式追加进来UNIQUE(session_id, seq)保证每个会话内序号唯一有序。这张表有两个巧妙设计外键级联删除REFERENCES sessions(id) ON DELETE CASCADE删掉会话时事件自动清理绝不留孤儿数据事件即回放素材重启后 UI 要恢复聊天记录直接按seq顺序读回事件流即可hydrateOutputSessionManager.ts3.session_attachments表图片/PDF 等附件的 BLOB 存储用户在对话里上传的附件不做外部文件管理直接以BLOB存进数据库同时记录name、mime、size和turn_index属于第几轮对话。同样配置了级联删除会话删除即附件删除。一个直观的对应关系sessions管是什么session_events管发生了什么session_attachments管带了什么。启动即恢复重启后的两步修复真正让任务不怕重启丢成立的是 SessionManager 在启动时执行的恢复流程。第一步把假死会话标记为已停止上次应用是被强杀还是意外退出的数据库里可能残留着状态还是running/stuck的会话。启动时recoverStaleSessions()会一条 UPDATE 把所有这类会话批量置为stopped并附上错误信息App exited unexpectedly常量定义见 db-constants.ts。于是重启后你在界面里看到的是上次任务因应用退出而停止而不是一个永远不会动的运行中假象。第二步重建内存中的会话随后loadPersistedSessions()从库里读出最近的 100 个会话逐一重建内存对象并重点恢复三类续命信息引擎与对话 IDengine_session_id是服务商侧的会话标识如 Codex 的thread_id恢复它追问就能继续原对话而不是开新对话现场 URLlast_urlprimary_site重启后能定位到 Agent 上次停在哪暂停状态paused的会话重启后仍是paused——你暂停的任务不会因为重启而复活或蒸发。事件流则采用懒加载只有当 UI 真正打开某个会话时才从session_events读回完整记录hydrateOutput避免启动时把所有历史一次灌进内存。WAL 模式性能与崩溃安全的平衡打开数据库的那一刻SessionDb 构造函数就设置了三个 pragmaPRAGMA journal_mode WAL; PRAGMA synchronous NORMAL; PRAGMA foreign_keys ON;WALWrite-Ahead Logging写入先进追加式日志再合并读写不再互相锁表。Agent 高频吐事件时UI 的查询不会被卡住synchronous NORMAL在 WAL 模式下这是性能与安全的甜点——崩溃最多丢最后一个 checkpoint而不会丢已提交事务foreign_keys ONSQLite 默认不启用外键这里手动打开才能让删会话级联删事件/附件真正生效。此外所有 SQL 语句在 prepareStatements() 中启动时一次性预编译30 多条语句全部缓存为 prepared statement之后每次写入都走缓存的语句对象省掉反复解析编译的开销。批量写入事件时用db.transaction()把多条 INSERT 包进一个事务appendEventsBatch一次性提交原子又快。应用正常退出前还会执行wal_checkpoint(TRUNCATE)close()把 WAL 日志合并回主库并清空日志文件——下次启动更干净。Schema 版本与指纹数据库不会越界数据库比应用新怎么办老应用打开新数据库是危险的。runMigrations() 的策略很硬核if (current DB_SCHEMA_VERSION) → 直接抛错拒绝启动即只允许数据库比应用旧触发迁移升级绝不允许数据库比应用新宁可罢工也不读乱。当前 schema 版本号为 12DB_SCHEMA_VERSIONmigration 从 v1 的三张基础表一路演进到 v12 的last_url/engine_session_id每个版本都在事务中执行、幂等可重入。除了版本号项目还做了一层指纹校验schemaIdentity.ts 把所有表、索引、视图按规范顺序读出序列化成 JSON 后做 SHA256生成形如sessions:v12:sha256-xxxx的 schema 身份标识。任何对结构的意外改动哪怕版本号没变都能被哈希差异暴露出来——这是比user_version更细一级的保险。附件怎么存限制是算出来的附件大小限制藏在 db-constants.ts而且注释里写明了推导过程LLM API 对base64 编码后的 payload 有限制如 5MBbase64 比原始体积大 4:3所以原始上限要按floor(api_limit × 3/4) - 1024回推图片约 3.75MB、PDF 约 24MB、纯文本 1MB、其他类型 10MB每个会话最多 200 个附件、每条消息最多 10 个、单条消息附件总量不超过 50MB这些上限在saveAttachment写入前强制检查防止无限制的追问上传把数据库撑爆。测试如何守住重启不丢这条底线这套机制不是靠应该没问题而是有专门的测试用例守着持久化单测SessionManager.persistence.test.ts 模拟创建 → 销毁 → 重新打开同一个库的完整重启流程逐一验证导航信息primarySite/lastUrl恢复、引擎对话 IDthread-123恢复、暂停的会话重启后仍是paused、已停止的会话可以接受新的追问并重置输出……E2E 回归session-restore.spec.ts 用 Playwright 真实启动应用两次验证打开 3 个标签 → 退出 → 重启 → 标签数和 URL 原样还在以及会话文件损坏时优雅降级而不是崩溃。Schema 校验SessionDb.schemaIdentity.test.ts 守护 schema 指纹计算的正确性。另外提一句浏览器标签页的恢复session.json与Agent 会话的恢复sessions.db是两套独立机制前者管你开着哪些网页后者管你和 Agent 聊到哪了各管一摊、互不干扰。小结一套值得借鉴的持久化设计回看 Browser Use Desktop 的会话持久化方案它的完整拼图是SQLite 单文件 WAL零部署、崩溃安全、读写不互锁三张表分层元数据 / 事件流 / 附件外键级联保证一致性启动恢复先批量修复假死会话再重建内存事件懒加载双重结构守卫user_version迁移 SHA256 schema 指纹量化限制附件大小和数量上限有明确推导防止数据库膨胀测试兜底单测模拟重启、E2E 真实重启、损坏场景降级验证对任何需要会话可恢复的桌面 Agent 应用来说这套设计简洁、可验证也足够坚固——任务跑一半重启应用回来继续。延伸阅读核心实现SessionDb.ts、SessionManager.ts、db-constants.ts类型定义shared/session-schemas.ts性能与启动耗时审计PERFORMANCE.mdIPC 事件协议规范shared/schemas/README.md赞分享【免费下载链接】desktopBrowser Use Desktop App项目地址https://gitcode.com/gh_mirrors/desktop65/desktop点击查看免费下载相关推荐Browser-Use存储状态会话数据持久化管理Browser Use存储状态会话数据持久化管理概述在现代Web自动化场景中会话状态的持久化管理是确保自动化任务连续性和可靠性的关键。Browser U人工智能AI Agent浏览器控制MCP 服务终极解决方案Browser-Use WebUI持久会话技术让浏览器状态永不丢失终极解决方案Browser Use WebUI持久会话技术让浏览器状态永不丢失 GitHub推荐项目精选的web ui是一款能够在浏览器中运行AI Agent人工智能AI 应用大模型AI Agent浏览器控制深度研究本地部署对话不丢失chatbot-ui会话持久化与恢复全解析对话不丢失chatbot ui会话持久化与恢复全解析你是否遇到过这样的困扰与AI助手深入交流时意外刷新页面所有对话历史瞬间消失作为开源AI聊天界面的佼人工智能AI 应用前端上一篇如何让你和设计文件用同一套语言说话开源设计工具 Penpot 完全指南下一篇从Blender到实体3D打印工作流的终极完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

任务不怕重启丢：Browser Use Desktop 会话持久化（SQLite）设计与原理剖析

相关推荐

sp_vision_25 部署完整指南：4步搞定自启动注册、udev规则配置与GPU推理加速

NanoMDM 设备注册迁移指南：3 步用 nano2nano 换存储后端、搬 MDM 服务器，不重新注册

DVWA 本地部署教程：一条命令拉起你的 Web 安全靶场

更多资讯

TRAE的solo与IDE模式：AI编程工具的双模实战解析

迷你世界UGC3.0脚本触发器事件管理实战指南

系统清理工具核心技术解析与优化实践

金融风控模型对抗学习增强实战解析

一枚回形针的隐藏宇宙：从机械设计到发散思维与AI安全

DEA介电弹性体驱动器PID控制：Simulink建模调参与扰动抑制避坑

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？