能不能像接评论框一样接 Agent：AgentHub 的设想
静态博客贴一小段代码就有了评论区，平台想让评论里的一个 @ 落到用户自己电脑上的 agent，却要从头写一整套系统。把评论框和本地 agent 当 bot 这两件事放在一起看：平台为一个 @ 到底写了什么，评论框的先例能借走什么，现有的方案各补了哪一块，一个像 Redis 一样起实例就能用的中间件该长什么样，身份和写回怎么做，公开评论区带来的新风险，以及它怎样才不会重蹈多说的覆辙。
把经历过的，连成记忆。
这是我的记忆构建平台，你也能搭一个。
最新文章
心跳越不规律越健康，那注意力呢
健康的心跳并不规律：心率一直在变，是为了让血压稳住，HRV 量的正是这份调控能动多宽。顺着这个启示去看注意力：它背后有没有一个调控者，反应时该当成心率还是血压，调控怎样被压窄、怎样恢复，能不能像 HRV 一样戴着就测，最后附一个 3 分钟的反应时测试。
GitLab 的 Git 服务架构：Gitaly、Praefect 与仓库的拆分
GitLab.com 早年打开一个仓库的 P99 超过 30 秒，CPU 却只用了 15 毫秒。顺着这个现象往下追：仓库为什么离开 NFS，一次 clone 由谁鉴权、pack 字节走哪条路，Gitaly 怎么把 RPC 变成受控的 git 进程、怎么扛住 CI 的并发 clone，push 怎么在 Gitaly 和 Rails 之间往返，Praefect 怎么投票、怎么修复落后的副本，最后看 WAL 和 MVCC 后端在当前源码里真正走到了哪一步。
Gerrit 的架构：把代码评审写进 Git 引用
Gerrit 的评审记录可以用 git fetch 拉下来，一次投票就是一个提交。顺着这个现象往下追：Gerrit 为什么用 JGit 自己做 Git 服务端，push 到 refs/for/main 时发生了什么，评审数据为什么从 SQL 搬进 Git，引用多到几十万个之后怎么存、怎么按权限过滤，合并时怎么保证原子性，索引和缓存怎么配合，以及多台机器之间怎么同步。
walgit 架构原理：把 Git 仓库交给对象存储
walgit 的一次 push 只对桶发 5 个请求，一次读只发 1 个，却保证 push 被确认后任何一台机器都能读到。顺着这两个数字往下追：为什么不能让 git 直接读对象存储，manifest 的 CAS 为什么就是提交点，并发 push 和“每个对象每秒一次写”怎么处理，读路径为什么要分级，日志怎么折叠和压缩，进程崩溃之后怎么办，以及 GitLab 的对象存储后端为什么选了另一条路。