kenn-io/agentsview

解决什么问题

同时用两三个编程 Agent 之后，会话记录就散落在各家的私有目录里，格式互不相同。记录其实都在，但想找回三周前问过什么、哪个会话最烧 token、每个项目每个模型花了多少钱，几乎没有现成办法。agentsview 的做法是扫描本机各支持的 Agent 会话，同步进本地 SQLite，再用 Web UI 和 CLI 在同一个库上做搜索和统计。

有什么不同

大多数人现在的替代方案是各家自带的会话历史页面，只能看单个 Agent，导出也麻烦。agentsview 把 transcript 当成一个跨 Agent 的语料库：一份索引、一个搜索框、一份用量报表。真正拉开差距的只有两点：一是多 Agent 会话发现（README 点名 Claude Code、Codex 以及 50 多个其他 Agent，并支持通过 SSH 同步远端机器，无需装 daemon）；二是成本与 token 统计直接读同一个归档，不依赖厂商后台。需要说明的是，README 很长但偏运维——安装、Docker、远程访问、daemon 生命周期写得很细，却很少讲各家 transcript 解析的健壮性；近几个版本修的是 Antigravity transcript 和重复 prompt，说明解析层才是长期的维护负担。

适合谁

日常在两个以上编程 Agent 之间切换、想要一份统一可搜索记录并关心花费的开发者。需要把会话数据落到 SQL 里分析的团队也合适，支持推到 PostgreSQL、DuckDB 和 ClickHouse。如果你只用一家 Agent、自带历史就够用，那就没必要；如果你要的是多人协作的托管分析平台，也不合适——这是单人、本地优先的工具，超出 loopback 访问就得自己配鉴权和可信代理。

上手成本

Go 二进制，MIT 协议，支持 shell 脚本、Homebrew cask 和 Docker 镜像安装，CLI 和桌面端共用一个本地 daemon。真正的成本在别处：daemon 会在后台常驻（空闲自退出），归档会把 transcript 复制一份到 SQLite，容器部署只能看到显式挂载了会话目录的 Agent。对外暴露需要 --public-url 和 --require-auth，配错是有风险的。版本号还在 v0.46.1，说明迭代很快、尚未稳定。

点评

这是个年轻项目：2026 年 2 月创建，约 247 天，约 6.2k star，最近上过一次 Go 周榜第 13。相对项目年龄来说 star 偏高，通常意味着发布期的爆发而不是稳定采用，Hacker News 那条帖只有 1 分，外部验证很薄。需求是真实的，对多 Agent 用户确实顺；但各家 transcript 解析面太大，发布记录也以修 bug 为主。问题正好落在你身上、又能接受频繁变更的话可以试；否则建议再等几个版本。