一次 session 只是数据点，连续观测才是趋势 —— agentprof list 列最近 sessions 给你「本周用得多吗」的即时感，agentprof aggregate --by model/tool/day 给跨 session 报表回答「哪个模型 cache 命中率高」「哪个 tool 是 token 大户」「这一周 agent 是不是在空转」。
❓ 你想看的是什么维度？
📊 模型对比
→
aggregate --by model — 含 cache 命中列 (ADR-0023)🔧 找浪费 tool
→
aggregate --by tool — 按 total_duration 排📅 时间趋势
→
aggregate --by day + --low-utilization-threshold📋 单 session 列表
→
list --since 7d --limit 20🔌 生活类比
从 top 升级到 Grafana —— analyze 是单点快照（这一刻 CPU 在干嘛），list + aggregate 是仪表盘（这一周 CPU 用在了哪里、哪个进程一直涨）。同样的数据源，换一个时间维度看就是另一个故事。
3 条命令 — 跨 session 怎么挑？
下面三条覆盖最常见的「本周用量 / 模型对比 / tool 排名」三种问法：
| 命令 | 输出 | 典型场景 |
|---|---|---|
agentprof list --since 7d | 最近 sessions 列表（Cache% / Turns / Out-tokens） | 「本周用得多吗？哪几次最贵？」 |
agentprof aggregate --by model | 跨模型对比（CacheCr / CacheRd / Hit% / NetSaved） | 「Sonnet vs Opus 哪个 cache 命中率高？」 |
agentprof aggregate --by tool \ --since 30d | Tool 维度排名（调用次数 + 总 token） | 「过去一个月哪个 tool 是 token 大户？」 |
👇 四张卡片展开 list 与三种 --by 模式：① 输出长什么样 · ② 为什么这么设计 · ③ agentprof 怎么做。
1 list --since 7d --limit 20 — 最近 sessions 点击展开
🧪 输出长什么样
一张紧凑表：每行 session id + start 时间 + turns + out-tokens + Cache%（M2.5 加的列），按时间倒序。
--since 支持 7d / 12h / 30m / all；--limit 20 控制行数。一眼能看出「最近哪几次特别费 token」「哪几次 cache 完全没命中」。🤔 为什么这么设计
单看一次 session 容易误判 —— 也许这次就是任务特别复杂。列最近 N 次才看得出基线：如果你每天平均 30k token，今天突然 300k，那就值得深挖。
--since 用 文件 mtime 过滤而不是解析每个 session 头里的时间戳，便宜很多 —— 列表场景不需要精确到秒。✅ agentprof 怎么做
走
Adapter::discover() trait —— 每家适配器（ClaudeAdapter / CopilotAdapter / CodexAdapter）自己实现「在我的默认路径下扫 session 文件」。--since 解析在 cmd/since.rs 抽出复用，被 list / aggregate / watch 三处共享。Cache% 列只读 session header 不做完整解析，所以 20 行的列表能在百毫秒级返回。2 aggregate --by model — 跨模型 cache 对比 点击展开
🧪 输出长什么样
按模型分组的表：每行一个模型，列出 CacheCr（cache_creation_input_tokens 总和）/ CacheRd（cache_read_input_tokens 总和）/ Hit%（命中率）/ NetSaved（净节省 token 数 = read - creation × write_multiplier）。直接能看出「Sonnet 在这批 session 里 cache 命中 85%」vs「Opus 只有 40%」这种对比。
🤔 为什么这么设计
不同模型的 cache 行为差异巨大 —— 有的 prompt 结构对 prefix cache 友好，有的因为 system message 频繁变动一直 miss。聚合到模型维度才看得出「应不应该把这条 workload 迁去某个模型」。NetSaved 不是单纯算 CacheRd，要扣掉 creation 的额外成本（per ADR-0023），才是真实省下的钱。
✅ agentprof 怎么做
核心算法在
agentprof-core::analyzer::aggregate::aggregate_by_model，CLI 入口在 agentprof-cli::cmd::aggregate::compute_aggregate 调度。Cache 列的口径完全跟随 ADR-0023（"cache attribution"）—— per-session cache 算出 CacheMetrics 后按模型 sum，避免重复计入。3 aggregate --by tool / --by mcp-server — 找 token 大户 点击展开
🧪 输出长什么样
按 tool（或 mcp-server）分组：每行 tool 名 / 调用次数 / 总 out-tokens / 平均每次 token / sessions 覆盖数。一眼能看出「filesystem.read_file 调了 800 次平均 12k token」这种红色信号 —— 是真的需要读这么多，还是 agent 在重复读同一个文件？不出 Cache 列（per ADR-0023 D-3：per-tool cache attribution undefined，硬编码列也会误导）。
🤔 为什么这么设计
"哪个 tool 是 token 大户"是优化第一性问题 —— 砍掉一个高频高 token 的 tool 比调任何 prompt 都管用。聚合到 tool / mcp-server 两个维度对应两种砍法：tool 维度找单一调用过贵，mcp-server 维度找整个 server该不该挂。不出 cache是诚实 —— cache 是 prompt prefix 维度的概念，把它强行摊到 tool 上要么算不准要么误导用户。
✅ agentprof 怎么做
两个独立函数
aggregate_by_tool / aggregate_by_mcp_server 在 agentprof-core::analyzer::aggregate，输出 schema 不含 cache 字段（编译期就拒绝误用）。compute_aggregate 根据 --by 参数派发到对应函数，渲染层（md / tui）也对应两套表头。4 aggregate --by day + --low-utilization-threshold — 时间序列 点击展开
🧪 输出长什么样
按天分桶的时间序列：每行一个日期 + sessions 数 + turns 数 + 总 token + 是否低利用率。配合
--low-utilization-threshold 5000（默认 token / day 阈值）能直接标红那些「开了 agent 但实际没怎么用」的日子 —— 比如 IDE 后台跑着 watch 但你那天去开会了。🤔 为什么这么设计
订阅制 agent（Copilot / Claude）按月付费，低利用率 = 钱白花。时间维度能暴露两种浪费：① 长期空转的 watcher / hook，② 周末 / 节假日的无效保持。把判定内建到 aggregate 而不是让用户自己看曲线，因为大部分人不会主动审。
✅ agentprof 怎么做
aggregate_by_day 返回一组 DayBucket，每个桶上挂 is_low_utilization 方法 —— 输入是用户给的阈值（默认值见 agentprof-core::analyzer::aggregate 常量）。CLI 层只负责渲染时把 true 的行标红 / 加 ⚠ 前缀，不在渲染层做判定逻辑（per L1 分层规约：业务判定归 core）。「何时用哪个 --by」决策表
| 想回答的问题 | 用这个 --by | 为什么 |
|---|---|---|
| 哪个模型 cache 命中率最高 / NetSaved 最多？ | --by model | 唯一含 cache 列的维度（per ADR-0023） |
| 哪个 tool / mcp-server 是 token 大户？ | --by tool 或 --by mcp-server | 调用次数 × 平均 token 直接排序 |
| 这一周 / 一月趋势如何？有没有空转日？ | --by day | 时间桶 + low-utilization 自动告警 |
下一步
会看跨 session 之后，下一课会带你看 watch + serve：把这些聚合做成常驻面板，agent 在跑的时候实时刷新；以及 config 怎么把这些参数固化到本地配置避免每次敲一长串。
📂 相关源码：
agentprof-cli/cmd/list.rs
run
📂 相关源码：
agentprof-cli/cmd/aggregate.rs
compute_aggregate