Agent 对话全统计

编年史 · 第四篇 · Hermes Agent 使用数据全景（AI生成）

核心数字

指标	数值
数据库大小	1.4 GB（state.db）
会话总数	600
消息总数	~115,000（135 MB 文本）
Tool Calls	62,338
API 请求数	80,968（DeepSeek 口径）
总 Tokens	14,081,786,297（14.08B）（DeepSeek 累积计费）
累计费用	¥554.80
使用模型	deepseek-v4-flash（599/600 会话）
项目覆盖	v1 + v2 = 28 天全覆盖

会话来源分布

来源	数量	占比	说明
TUI 主会话	292	49%	你在 Hermes TUI 中直接发起的对话
subagent（子代理）	262	44%	Agent 自动派生的并行工作单元
CLI	41	7%	命令行模式会话
飞书（feishu）	5	1%	v1 早期飞书集成（6/19 前后）

子代理比例是重要指标： 44% 的会话是 Agent 自己生的。在 v2 的审计密集期，每个审计任务会并行派生 5-10 个子代理，各自独立工作。

时间分布

按日活跃度（全局 28 天）

日期      会话数  消息数    Input Tokens     Output Tokens
06/19      197    11,457     8,154,449       3,775,104   ← v1 启动（含大量初始配置）
06/20       18     2,273     1,270,347         565,693
06/24       28     7,409     3,279,302       1,399,856
06/26       23     5,938     2,212,424       1,511,025
07/04       10     1,473       933,398         551,238   ← v2 设计期
07/09       15     4,179     3,046,626       1,230,073   ← 设计定稿
07/10       20     7,911     4,251,161       1,780,915   ← Phase 0-1
07/11       60    16,027     9,543,178       3,186,831   ← 🔥 峰值
07/12       39     7,064     6,290,344       1,788,470   ← 走查工具
07/13       41    10,739     9,868,773       2,084,335   ← UAT 走查
07/14       40    14,943    10,210,331       3,510,154   ← 修复密集
07/15       26     7,926     6,064,551       1,679,898   ← 性能优化
07/16       48    10,371     5,946,751       2,050,292   ← 发布准备

v1 vs v2 对比

指标	v1 期（6/19~7/2）	v2 期（7/3~7/17）	v2/v1 倍数
会话数	283	318	1.1x
消息数	30,189	84,584	2.8x
日均消息	~2,156	~5,639	2.6x
Input tokens	16.9M	59.1M	3.5x
Output tokens	8.0M	19.5M	2.4x

v2 的 Agent 使用密度远高于 v1，原因：

代码量更大：Flutter（276 Dart 文件） vs Django 模板网页
审计体系：每轮审计消耗大量 tokens
子代理并行：v2 大量使用 delegate_task 派生子代理

成本分析

费用构成

成分	估计占比	金额
系统提示词重发（每轮 30K tokens）	~60%	~¥333
累积对话历史重发（会话越长越贵）	~30%	~¥166
工具返回结果（终端输出/文件内容）	~9%	~¥50
你的手动输入（5,129 条消息）	~0.017%	~¥0.09

核心结论： ¥554.80 中 99.98% 花在 “让 Agent 记住上下文” 上，而不是 “理解你说了什么”。系统提示词 + 工具定义 + 累积历史的重发成本是绝对大头。

按 v1/v2 分摊

时期	估计费用	占比
v1（6/19~7/2）	~¥170	~30%
v2（7/3~7/17）	~¥385	~70%

你的手动输入量

总量

指标	数值	类比
总消息数	5,129 条	—
总字符数（含系统标记）	3,684,635	约 3.5 部《三体》
其中系统自动附加（`[Hermes UI Workspace]`）	721,145（19.6%）	—
你实际打的字	2,963,490	约 3 部《三体》
每天平均	~106K 字符	—
每条平均	~576 字符	约 3-4 行中文对话

按日分布（v2 期）

7/3     6K   ▏
7/4    31K   ██▌
7/5     2K   ▏
7/6    13K   █
7/7    10K   ▊
7/8    24K   ██
7/9    39K   ███
7/10  146K   ███████████▋
7/11 1182K   ████████████████████████████████████████████████████████████  ← 🔥
7/12  611K   ████████████████████████████████████▍
7/13  436K   ████████████████████████████▉
7/14  141K   ██████████
7/15   92K   ██████▉
7/16  206K   ███████████████
7/17    3K   ▏

7/11 的 118 万字符峰值不是打字速度突然提升，而是当天你在 Phase 2-3 密集编码中大量粘贴代码块、错误栈、文件路径到对话中。

最长的手动输入

前 10 条最长消息全是系统自动附加的 [Hermes UI Workspace] 标记块（~~40K~~92K 字符/条）。去掉这些后，真正由你输入的最长内容通常是粘贴的代码段或错误日志，约 1,000-5,000 字符。

子代理（Subagent）体系

262 个 subagent 会话是 v2 质量保障的核心机制。

子代理工作模式

你的一条指令
    │
    ▼
主会话 ──→ delegate_task ──→ subagent A（审计服务端）
    │                       └── subagent B（审计 Flutter 数据层）
    │                       └── subagent C（审计 Flutter UI）
    │                       └── subagent D（审计教师端）
    │                       └── subagent E（审计部署）
    │
    ▼
汇总 5 份审计报告
    │
    ▼
fix-batch-workflow → 批量修复 → 子代理验证 → 合入

典型子代理树（7/11 审计轮次）

主会话 "审计-2"（~300 msgs）
├── subagent "Type A — 服务端审计-2"（141 msgs）
├── subagent "Type B — 数据层审计-2"（116 msgs）
├── subagent "Type C — UI 审计-2"（180 msgs）
├── subagent "Type D — 教师端审计-2"（153 msgs）
└── subagent "Type E — 部署审计-2"（150 msgs）
     ↓
主会话 "修复-B组"（893 msgs）
├── subagent 1（修复一部分）
├── subagent 2（修复另一部分）
└── subagent 3（验证改动）

子代理的优势：

隔离：每个子代理有独立的上下文，不会被其他任务的细节污染
并行：5 个审计同时进行，总耗时 ≈ 最慢的那个
专注：子代理只读指定文件/路径，不会被工具返回的大段输出撑爆上下文

最长会话 Top 10

排名	消息数	会话主题	日期
1	1,097	落地Phase1后半部分	7/10
2	1,045	落地Phase2前半	7/10
3	955	内测准备工作	7/16
4	954	配图渲染排查	7/15
5	937	落地Phase3c+	7/11
6	901	manual-audit-recorder（完整UAT）	7/13
7	893	新审计发现问题修复-A组	7/11
8	892	界面友好性	7/15
9	866	落地教师端	7/11
10	844	落地Phase2后半	7/10

超过 500 条消息的会话有 40+ 个。最长会话（1,097 条）是 Phase 1 后半段的服务端全量编码。

工具使用概况

62,338 次 tool call 涵盖以下类别：

工具类别	用途	使用频率
write_file / patch	写代码、修改文件	⭐⭐⭐⭐⭐
read_file	读取代码/文档	⭐⭐⭐⭐⭐
terminal	运行命令、启动服务	⭐⭐⭐⭐
search_files	搜索代码、查找文件	⭐⭐⭐⭐
delegate_task	派生子代理	⭐⭐⭐（v2 后期大量使用）
mcp__winnav__*	桌面自动化走查	⭐⭐（7/12 之后）
web_search	查文档/API/问题	⭐⭐
memory / skill_manage	记录偏好、管理 Skill	⭐⭐
todo / context_usage	任务管理	⭐

对话主题分类

173 个有标题的 TUI 会话按主题分类：

类别	数量	说明
排查/诊断	~45	“解题页面排查”、“同步系统排查”
修复/bug fix	~30	“积分系统修复”、“硬编码问题修复”
落地实施	~20	“落地Phase3a~3b”、“落地教师端”
审计/走查	~25	“Type A—服务端审计-1/2/3”、“三次走查”
工具构建	~15	“winnav工具封装”、“走查流程设计”
功能开发	~15	“解题地图页面”、“pdf生成修复”
设计/文档	~10	“教师端设计”、“编写细化文档”
其他	~13	“iOS内测发布”、“编译发布alpha1”

与 Git 仓库的对应关系

Git 仓库	会话数	总消息数	时间段
`zhangyuzhixue_app_v2`	44	15,398	7/4~7/16
`math_platform`	1	220	6/28
无 git_repo_root 但有匹配 cwd	218	64,488	7/3~7/17

大部分 v2 会话没有设置 git_repo_root，但 cwd 指向了项目目录。加上 cwd 匹配后，v2 的实际项目会话约为 262 个（44 + 218）。

数据可靠性说明

state.db 的 token 计数是增量口径（每次 API 的新增 tokens），不是 DeepSeek 的累积计费口径。差距原因是每次 API 请求都会重发完整的系统提示词 + 工具定义 + 累积对话历史。14.08B / 80,968 ≈ 174K tokens/请求，即每次 API 调用平均携带约 174K 的上下文。

因此两个口径各有用途：

state.db 口径（增量）： 反映你产出的内容量（135 MB 文本 / ~104M tokens）
DeepSeek 口径（累积）： 反映真实成本（14.08B / ¥554.80）

附录：一分钟读懂你的 ¥554 花在哪

你每次说一句话，Hermes 做的是：
1. 把整个对话历史（越来越长）打包
2. 加上系统提示词 + 工具定义（~30K tokens）
3. 发给 DeepSeek
4. DeepSeek 的回复写完新代码，工具去执行
5. 工具返回的结果（文件内容、终端输出、编译日志）又加进来
6. 下一轮再从头开始...

所以：
  你的话  →  触发对话   →  每次带历史重发  →  累积成 14B tokens
  ¥0.09      驱动流程        ¥554 花在这里        ¥554.80

核心数字#

会话来源分布#

时间分布#

按日活跃度（全局 28 天）#

v1 vs v2 对比#

成本分析#

费用构成#

按 v1/v2 分摊#

你的手动输入量#

总量#

按日分布（v2 期）#

最长的手动输入#

子代理（Subagent）体系#

子代理工作模式#

典型子代理树（7/11 审计轮次）#

最长会话 Top 10#

工具使用概况#

对话主题分类#

与 Git 仓库的对应关系#

数据可靠性说明#

附录：一分钟读懂你的 ¥554 花在哪#