从记事本开始
最开始的需求很简单：让 Hermes Agent 每天凌晨把我前一天的工作整理成日记。
第一版确实也做到了——凌晨 2:00 跑个 cron，读聊天记录、写 Obsidian 日记、保存几个知识点、微信通知。功能完整，但用了一周发现一个根本问题：它只记录，不行动。
用户教它的事情（比如”以后遇到这种情况应该这样做”），记在日记里就结束了，下次还会踩同样的坑。日记成了流水账，没有变成改进的动力。
于是开始了三轮架构迭代。
阶段 1：并行分析为什么失败了
第一个改造思路很直觉—把分析拆成 5 个维度，用子 agent 并行跑：
- 维度 A：流程脚本化
- 维度 B：反馈闭环审计
- 维度 C：错误纠正与自动修复
- 维度 D：技能更新
- 维度 E：空白发现
然后每个子 agent 独立分析同一批会话，最后汇总。
上线当天就发现问题了：
- 同源数据重复读：5 个子 agent 各读一遍会话内容，token 消耗直接翻 5 倍
- 洞察割裂：用户一条”这个命令用错了，应该用新脚本”的纠正，同时命中「脚本化」和「技能更新」两个维度，但被拆分到两个子 agent 里，各看到一半
- 优先级无法传导：维度 A 发现了一个严重 bug，维度 B 也在发现小问题，但汇总时没有机制说”先修 bug 再管别的”
子 agent 本身也有静默丢失的问题——接近 max_iterations 时来不及保存骨架 JSON，整个分析就丢了。主 agent 不知道它失败了，以为在等结果。
第二天我就废弃了这个方案。
阶段 2：串行 + 六维 + 三级分流
重新设计的核心决策很简单：以 session 为原子单元，串行分析，不拆分。 一个 session 完整看完，一次性打 6 个维度的标签，再执行改进。
六维分析框架
| 维度 | 看什么 |
|---|---|
| 流程脚本化 | 命令能不能写成可复用脚本？ |
| 反馈闭环 | 用户纠正后我改了没有？还会再犯吗？ |
| 错误修复 | 报错修了没？修复方式对不对？ |
| 技能更新 | 有没有值得做成技能的知识点？ |
| 空白发现 | 有没有应该做但还没做的事？ |
| 流程优化 | 有没有绕弯路、选错工具的情况？ |
三级分流
所有发现不急着改。先分级：
- 🟢 立即行动：错误纠正、脚本化机会、工具优化 — 当天执行
- 🟡 观察：潜在优化点、功能建议 — 需”3天出现2次”才升级
- ⚪ 跳过：一次性异常、噪声 — 直接丢弃
这个分级机制解决了之前”什么都想改但什么都改不完”的问题。
决策门
日常要分析的 session 通常是 8-12 个。≤12 个时主 agent 直接分析（保持上下文完整）；13+ 个时用子 agent 委派，但加了一个保障——子 agent 必须先写出骨架 JSON 再填充，保证即使超时也有部分结果返回。
核心组件
work-overview.yaml
这是系统的”持久记忆”。一个 YAML 文件记录了 16 个工作域的当前状态：
自我进化引擎:
status: active
triggered_by: ["cron-daily-diary"]
scripts: ["~/tools/..."]
known_issues: []
last_update: 2026-07-08
9Router AI 网关:
status: active
triggered_by: ["user-chat", "weixin"]
known_issues:
- "gl model sometimes 429 on burst requests"
last_update: 2026-07-08
每天分析完 session 后自动更新 known_issues 和 last_update。下次分析时拿着这份”体检报告”去检查问题是否已解决。
查询层
query_state_db.py 直接从 state.db（SQLite）查会话元数据，不需要读全量对话内容，速度快：
python3 query_state_db.py 20260707 --limit 300
返回昨天所有 session 的 ID、来源、消息数、时间范围。然后根据来源过滤——排除 cron 自身的 session（source != 'cron'），只分析用户交互 session。
输出层
分析完成后：
- 写 Obsidian 日记
Daily/YYYY-MM-DD.md - 知识入库到 GBrain（临时文件法写入）
- 🟢 项批量执行改进
- 自检问题登记到 Vikunja 项目 7
- 微信通知推送摘要
踩坑记录
1. 子 agent 静默丢失
现象：delegate_task 返回成功但实际分析文件为空。
根因：sub agent 在接近 max_iterations 时没来得及写骨架 JSON 就退出了，且主 agent 无法感知。
解决：≤12 session 用主 agent 直接分析，不再委派。
2. cron 会话过滤漏洞
WHERE id NOT LIKE 'cron%' 漏过滤了一批 cron 产生的 session——因为有些 cron session 的 ID 生成的格式不以 cron 开头。
解决：加 source != 'cron' 条件双保险。
3. 噪声过滤不足
最初看到异常就想修，结果很多是一次性的环境波动（网络超时、API 限流等）。修了白修。
解决：引入”连续 2 天出现才修复”规则，减少无效改进。
当前运行状态
- 触发时间：每天凌晨 02:00
- 分析量：日常 8-12 个 session，最多 21 个
- 工作域：16 个（从 AI 网关到智能家居全覆盖）
- 知识点入库：每次 2-6 个
- 自检登记：发现系统性问题自动写 Vikunja
几条经验
- 先记录，再行动。 日记系统不想写流水账，就需要一个”从听到做”的执行链路。
- 串行比并行好。 直觉上并行更快，但分析类任务上下文割裂的代价远超速度收益。
- 持久状态很重要。 不带”上次检查结果”的审计每次都从零开始。work-overview.yaml 让分析有了历史参照。
- 分级比全收好。 不是所有发现都值得当天处理。三级分流机制解决了”什么都要改”的冲动。
从凌晨 2 点写记事本的简单 cron，到一个会自动发现 6 类改进机会并执行它们的闭环系统——整个迭代过程最有价值的不是代码量，而是对”什么是值得自动化的”这个问题的理解。