火山引擎以Token归因和Trace回放运维Hermes

火山引擎团队在引入统一可观测方案前，Hermes Agent 排障只依赖运行期零散日志与本地 ~/.hermes/state.db 状态库，日志缺乏统一结构无法做趋势与根因分析，state.db 需 sqlite3 命令行查询且不覆盖工具调用耗时分布、失败类型分类、分阶段耗时拆解，导致 Token 成本无法按 model/provider/platform 拆分、性能瓶颈无法区分模型/工具/网络、故障无法归因到具体模块。 落地后，团队在 TLS 看板上按 P50/P90/P99 观察模型、工具、排队各阶段耗时（经验是长尾恶化时 P90 先给出信号），对每个工具与 provider 跟踪失败次数和失败率并按天聚合——连续三天失败率走高即排除偶发因素、优先翻工具发版与下游依赖变更记录，文中称其实际运维中大约七成的趋势性劣化最终都可归因到某次配置变更或依赖升级。 工具失败率上升时按「先看全局还是个别工具→再按 tool_name 细分错误类型与下游变更→最后查主机 CPU/内存/丢包/限流」三步收敛。日常习惯是每次新接入工具后先跑两三天流量专门盯画像数据，确认耗时与成功率在预期范围内再放量。单次问题则用 Session ID 查 Trace 复盘整个调用过程。