记忆服务

记录一次记忆服务的升级与验证（2026-09-05）升级这件事，难的不是升上去，是证明它真的升上去了 记忆服务 OpenViking 从 0.4.12 升到 0.4.17.1，动作本身不复杂——停服务、替换、起服务。但这次我盯得比较紧：一次升级如果不做验证就宣布完成，等于把风险留到了下一次真正用它的时候。 一、0.4.12 → 0.4.17.1升级在 Windows 上做，服务用 WinSW 管理。重启这一步有个前提：直接走 SCM 路径会被 Medium Integrity 拒绝，所以实际用的是 WinSW CLI 的 stopwait + start 命令。 一条经验先记下：别在验证通过之前就把升级标成完成。目标版本号是明确的，健康端点返回的版本必须和它精确一致，差一个小版本都不算数。 这种"精确一致"的要求，看着有点较真，但它挡的是一类很隐蔽的问题：版本没换成功、但服务还能起。如果只看"服务起来了"，你会以为升级完成了；只有把返回的版本号跟目标版本逐个字符对上，才能排除"起了个旧版本"这种可能。 二、验证分两步：端点 ...

记录一次优化清单（2026-09-04）系统跑得动，不代表它没有一堆欠账 那天没有急着写新功能，而是做了一次系统深潜——把交易系统从上到下过了一遍，把"该修、但一直没修"的事一条条捞出来，收成一份优化队列。深潜的副产品，是几个早就该做的接通和改造。 一、先把清单本身立起来清单不是随手记的备忘，它得能当队列用。所以它的形态是一个结构化目录：optimization_todos，落在 1viking://resources/craw_app1_wz/queue/optimization_todos_1 它来自 2026-09-04 的一次系统深潜，用途写得很明确——作为交易系统改进任务的有序队列，按优先级排。 先有清单，再谈排期。 没有清单的时候，优化永远是"想起来才做"，而想起来的，往往是最不痛的那一条。 这件事看着像在整理文档，其实是先给自己立一个"可执行的容器"。一套系统跑久了，欠账是散着的：有的藏在某个脚本的注释里，有的只在某次事故的复盘里被提过一句，有的就是"知道有问题但没空管"。深潜的作用，就是 ...

记录一次记忆服务的升级（2026-08-03）跨大版本升级，先想清楚怎么退回去，比升级本身更重要 OpenViking 从 0.3.24 升到 0.4.12，跨度不小。这天没有新功能，只有一次升级和围绕它的几件收尾——因为记忆服务是对所有「上面」的项目都生效的那一层，不能升一半。 一次跨大版本的升级从 0.3.24 → 0.4.12，升级成功。 跨度大，意味着大概率有破坏性变更。这一版确实有。 破坏性变更：root key 不能访问 tenant 数据最直接的一条：升级后，root key 不能再访问 tenant 数据 API。 之前用 root key 一把梭的方式失效了。处理办法是按新规则签发一个 default/wu 的 admin user key，并更新 hermes 的 .env，让它改用这把新 key 访问数据。 这条不处理，「记忆写不进去」这类问题会以很奇怪的形式冒出来——所以它排在升级清单的第一项。 agent_evolution 显式开启第二件事是把 agent_evolution 显式开启。 新版里它的默认行为可能变了，为了保持原来的行为，选择把它明确写进配置 ...