EverRoom

EverRoom 是一个本地优先的桌面工作区，立在这样一句话上：上下文应当由证据拼装、被限定在某个工作场所之内，并且足够可见，让人能管得住它。文件、仓库、会议录音、一个浏览器扩展，以及飞书、Slack、Notion、Gmail 这类被连接的服务，都从同一条入口进来；每份来源都保留稳定的身份、内容哈希、版本与来源记录，而一条策略快照决定它究竟变成 Room 的 Wiki 页、实体候选、记忆文档，还是仅仅一条链接。工作单位是 Context Room——一个项目、话题、人或一项长期职责——agent 会话拿到的是这个 Room 的工具与文档，而不是一整片语料。文档是有版本、按块操作的，agent 的改稿要先经过操作内核提交，随后才轮到知识或记忆的扇出，于是一个外部服务出错也弄不坏文档。底下是 SQLite 加 Drizzle、FTS5 与按内容寻址的对象库，一个由 Electron 监管的 Fastify 5 网关，一个从 TencentDB-Agent-Memory 分叉来的 MemoryCore 服务负责分层记忆管线，以及一个由文件驱动的、装着十三个子代理的目录。

谁做的一个公司账号而不是个人：仓库全名是 NxcoreAI/EverRoom，元数据里没有所有者资料，735 次提交记在七个贡献者账号名下——21335464876（173 次）、SkylistqAq（159 次）、lzp-plus（128 次）与 Ewan-yuan（112 次）写了其中大部分，Rlacat 有 72 次，ultralan 有 9 次，xgx1124982311-sys 有 2 次，另有八十次提交没有关联到任何账号。提交邮箱指向一个团队而不是陌生人：五个地址挂在 vyitec.com 上，其中一个 xieguoxin@vyitec.com 有 25 次提交，还有二十四次来自 nexcore@nexcoredeMacBook-Pro.local。88 次提交带共同作者尾注，而每一条尾注点的都是 Claude 模型。某条 pull request 里出现的连接器回调域名是 connect.everroom.vyitec.com，主页是 r.nxcore.ai。

1. 01

   七周、735 次提交，以及从群聊里进来的 bug 报告

   仓库建于 2026-08-14，比它最早的一次提交——「feat: scaffold NexCore CE desktop app」，时间戳 2026-08-12T03:49:30Z——晚两天；735 次提交之后，它站在 3,069 个星、322 个 fork、219 个 watcher 的位置上。曲线的形状更像公司冲刺而不是个人长跑：八月剩下的日子里 561 次，九月 174 次，其中最新的一次是 2026-09-20 合并 pull request 239，而仓库记录的最后一次 push 是 2026-09-30，中间隔了十天。735 次提交里有 655 次关联到账号，而最忙的四个账号就写了 572 次。88 次提交带共同作者尾注，88 条全部指向 Claude 模型：31 条只写「Claude」，20 条 Fable 5，12 条 Opus 5，11 条 Opus 4.8，7 条带百万上下文的 Opus 4.8，5 条「Claude Code」，2 条 Opus 4.6。社区是从聊天客户端进来的而不是 issue 列表：三十条 issue 与 pull request 里有三条由 github-actions[bot] 代开，带着 <!-- feishu-request:... --> 标记；仓库里留着四个通知工作流和一个可复用的 feishu-card action，还有一条 issue 的全部内容就是指向本仓库的一个网址。

2. 02

   nightly 当流水线，stable 靠手打，以及一个被回退的版本号

   材料里列了二十个 release，最早的一个 nightly 发布于 2026-09-08，最晚的是 2026-09-30 发布的 desktop-v0.1.9-nightly.20261001.81；其中十八个是 nightly，命名为 desktop-v<版本>-nightly.<日期>.<序号>，例外只有 desktop-v0.1.7 与 desktop-v0.1.8。pull request 261 是定下这套规则并给出理由的那份文件：自动升正式版被删掉了——那大约四十行会扫 feat 提交并把某个构建提上 stable 渠道，0.1.9 就是这样被误升的；渠道改为在构建时按 tag 通过 NXCORE_UPDATE_CHANNEL 烙进包内；nightly 渠道打开 allowDowngrade，因为在 semver 里 X.Y.Z 到 X.Y.Z-nightly.N 属于降级；stable 则继续禁止降级，因为真的降级必须挡住。同一份 pull request 还提醒：SaaS 侧有一条配套改动必须同批合并，否则窗口期里 nightly 设备会查到一个空渠道。版本线上留着这次错误的代价：0.1.8 曾为了热更新链路被升成 0.2.0 当基线，又升到 0.2.1 当更新目标，而 pull request 253 把两者一起回退到 0.1.9，称它们是「误定的跳跃版本号」，并请求在当晚零点前合并，免得定时任务从错误的版本序列切出 nightly。

3. 03

   来源是一条台账记录，不是一段摘要

   摄入设计用一句话把机制说清：同一份内容靠 sourceId + contentHash 被认出，命中摄入台账后直接返回，不会再解析、再扇出一次。一条被记录下来的策略快照决定这份材料能到达哪些下游系统——示例里的策略是 meeting-minutes，默认同时打开 Room、Wiki 与 Memory 三条链路——而转换出的 Markdown 落进 parsed_contents，ingest_events 则留着源版本、内容指纹、策略快照与路由任务。围绕它的规则都是在把半成品挡在外面：转写还处在 pending_confirmation 时根本不写 Wiki；已确认的录音异步投递，不把确认接口按住不放；不改动 Wiki 正文的元数据更新不触发任何东西；自动投递失败只记日志，不回滚用户已经确认录音这件事。人工补投有自己的端点 POST /v1/reality/events/:id/knowledge-ingest，且只接受完成态事件。同一份文档还画了边界：感知模块只决定何时投递、并持有源 ID，它从不引用知识服务，而 bootstrap 注入的适配器让这三个模块不至于形成环依赖。

4. 04

   与本档案已有的三个记忆项目相比，它不同在哪

   本档案已经收了三个给 agent 用的记忆层，差别在于记忆从哪来。OKF Agent Memory 把一包 Markdown 形式的 OKF bundle 留在仓库里，用进程内 BM25 检索，于是记忆能出现在 git diff 里；agent-memory 让一个文件就是一条记忆，用有效期区间替代状态字段，并让一个独立的睡眠期层按自己的时钟新增与更新；Memmy 则跑一个本地服务，供十个不同的宿主读写。EverRoom 不是这几种形状里的任何一种。它是一个自带入口的应用，记忆是派生物而不是主要产物：来源先被规范化一次，然后才由一条被记录的策略决定有没有东西变成知识或记忆——这和「让 agent 往一个库里写」正好相反。它的存储是迁移线里六十三个 SQL 文件建起来的 SQLite，不是仓库里的 Markdown；做判断的是项目自带的 Pi 运行时，不是用户本来开着的那个宿主工具。这个项目给自己找的对照物是聊天客户端和一层薄薄的检索界面，而不是某个记忆库；而它的 README 同时列出了还没做完的东西：冲突展示、来源导航、手工挂接与回退、来源级诊断，以及更完整的带引用 agent 流程，都还是路线图条目而非已交付行为。记忆管线本身是借来的——MemoryCore 打包自 TencentDB-Agent-Memory 的一个分叉，而仓库里四个补丁中的一个补的就是这个依赖。

5. 05

   pull request 本身就是说明书

   这个仓库的写作发生在 pull request 正文里，其中几条比它们承载的改动更值钱。273 号是一次两个平台同时挂掉的 nightly：某个依赖在构建期去取 https://oomol.com/en/apps/catalog.json，而那个网址在站点改版后开始返回 404；作者拿锁文件 SHA 和上一次成功构建对比，证明变数不在依赖本身，指出上游项目自 2026-08-03 起没有任何提交，最后顺着仓库既有的补丁链加了一层 try-catch。271 号是一行改动，把 lib/commands/test.js 从随包内置的 npm 运行时里排除掉——此前发版审计因为一个违禁文件把包拦了下来。268 号是两处测试断言，因为新增一个 agent 工具改变了预期的工具清单，作者还写明这条分支在改动之前就是红的。262 号最锋利：总结区域被逐字稿本身占满，修法是先剥掉时间戳与说话人标记，再到原文里找八个互不重叠的 64 字探针，命中过半就判为回显。还有两条 pull request 从两端追同一个偶发 500——263 号让网关把笼统的内部错误换成带重试提示的具名 503，267 号则在桌面端的桥里加静默重试，先等一秒再等三秒，只针对打开 Room 的那两个只读请求。

6. 06

   作者写明不做的东西

   README 在介绍功能之前先划边界：第一个版本不做持续录屏、不做自主的多 agent 集群、不做企业管理、也不要求云端同步，理由是这一版要做的是可信的本地上下文。同样的克制出现在发版工程里。macOS 是写明的开发目标，Windows 安装包没有签名，于是 README 直说 SmartScreen 会警告。九月的更新链路调试发现：打包出来的应用里根本没有 app-update.yml——那是 electron-updater 在能下载任何东西之前必须先读的文件，缺它是因为构建配置里没有 publish；而手动检查更新只要 versionInfo 存在就报「发现新版本」，可这个字段永远存在，于是判据改成 isUpdateAvailable。一个 490 MB 的更新包下了二十多分钟、界面上连百分比都没有，这才有了进度广播与多段并发下载，理由是差量下载才是让这个体积活下去的东西。站在别人代码上的代价写在树里：patches/ 下四个补丁——electron osx-sign、记忆核心、MCP 适配器与 sqlite-vec；也写在某个早晨：工作流锁定的下载工具版本被 CDN 下架，于是一次 nightly 只建出了 GitHub release，既没有分发也没有登记。