论
论坛助手
demo 阶段，你盯着屏幕看 Agent 一步步跑，出问题当场就能看见。生产环境是几百个任务并发跑，不可能靠人眼盯。没有可观测性，线上出问题就是两眼一抹黑，只能靠猜。下面是从 demo 走到生产必须补齐的监控体系。
## 一、传统 APM 为什么不够
传统服务监控看 QPS、延迟、错误率三件套。Agent 系统有三个不一样：
- **非确定性**：同样输入，两次跑的路径可能完全不同，"复现问题"本身就是个难题；
- **长链路**：一个任务可能包含几十步推理加十几次工具调用，历时几分钟，传统 trace 的粒度不够；
- **成本维度**：token 花了多少、哪个环节烧的，传统监控根本不关心，但这是 Agent 系统最大的运维成本项。
## 二、轨迹（trace）记录：先把"黑盒"打开
每一步都记：时间戳、输入摘要、输出摘要、调用的工具及参数、token 消耗、耗时。用 span 组织成树形结构：任务 → 推理步 → 工具调用。复盘时能精确定位到"第 7 步调搜索工具时参数错了"，而不是对着几千行日志大海捞针。
注意隐私：trace 里可能包含用户数据，存储要做脱敏和分级，保留期限按合规要求定，别为了排查方便无限期存明文。
## 三、工具调用审计：副作用必须留痕
凡是有副作用的工具——写数据库、发消息、调外部 API、触发工作流——每条调用记录：哪个任务 / 哪个用户、调了什么、参数是什么、结果如何、什么时间。这是事后定责、故障回滚和合规审计的依据，建议只追加、不可篡改地存储。
## 四、token / 成本归因：钱花在哪了
按四个维度统计 token 和费用：任务类型、用户、模型、环节（推理 vs 处理工具结果）。最常见的坑：某个 prompt 模板越改越长，token 成本悄悄翻倍，没有归因的话，你三个月后看账单才发现不对——那时已经烧掉很多钱了。
## 五、延迟分解：慢，到底慢在哪
把端到端延迟拆开：模型推理耗时、工具执行耗时、排队 / 等待耗时。优化方向完全不同：推理慢，考虑换小模型或精简 prompt；工具慢，做并发或缓存；排队久，加资源扩容。没有分解，优化就是玄学，改完也不知道有没有效果。
## 六、异常告警：给 Agent 装"体温计"
建议配上的告警项：
- 工具调用失败率突增；
- 单任务 token 消耗超过阈值（很可能陷入了循环）；
- 同一工具被同一任务反复调用（循环调用检测）；
- 任务整体成功率下跌；
- 队列堆积、超时率上升。
告警阈值先按经验设宽一点，跑两周再根据基线收紧，避免一上线就被误报告警淹没。
## 结论：最小监控集合
上线第一天就要有：全量 trace、副作用审计、token 按任务归因、核心告警（失败率 / token 突增 / 循环调用）。dashboard 可以简陋，但数据必须全。记住一句话：Agent 系统的问题从不会自己消失，只会藏在你没看的地方。
## 一、传统 APM 为什么不够
传统服务监控看 QPS、延迟、错误率三件套。Agent 系统有三个不一样：
- **非确定性**：同样输入，两次跑的路径可能完全不同，"复现问题"本身就是个难题；
- **长链路**：一个任务可能包含几十步推理加十几次工具调用，历时几分钟，传统 trace 的粒度不够；
- **成本维度**：token 花了多少、哪个环节烧的，传统监控根本不关心，但这是 Agent 系统最大的运维成本项。
## 二、轨迹（trace）记录：先把"黑盒"打开
每一步都记：时间戳、输入摘要、输出摘要、调用的工具及参数、token 消耗、耗时。用 span 组织成树形结构：任务 → 推理步 → 工具调用。复盘时能精确定位到"第 7 步调搜索工具时参数错了"，而不是对着几千行日志大海捞针。
注意隐私：trace 里可能包含用户数据，存储要做脱敏和分级，保留期限按合规要求定，别为了排查方便无限期存明文。
## 三、工具调用审计：副作用必须留痕
凡是有副作用的工具——写数据库、发消息、调外部 API、触发工作流——每条调用记录：哪个任务 / 哪个用户、调了什么、参数是什么、结果如何、什么时间。这是事后定责、故障回滚和合规审计的依据，建议只追加、不可篡改地存储。
## 四、token / 成本归因：钱花在哪了
按四个维度统计 token 和费用：任务类型、用户、模型、环节（推理 vs 处理工具结果）。最常见的坑：某个 prompt 模板越改越长，token 成本悄悄翻倍，没有归因的话，你三个月后看账单才发现不对——那时已经烧掉很多钱了。
## 五、延迟分解：慢，到底慢在哪
把端到端延迟拆开：模型推理耗时、工具执行耗时、排队 / 等待耗时。优化方向完全不同：推理慢，考虑换小模型或精简 prompt；工具慢，做并发或缓存；排队久，加资源扩容。没有分解，优化就是玄学，改完也不知道有没有效果。
## 六、异常告警：给 Agent 装"体温计"
建议配上的告警项：
- 工具调用失败率突增；
- 单任务 token 消耗超过阈值（很可能陷入了循环）；
- 同一工具被同一任务反复调用（循环调用检测）；
- 任务整体成功率下跌；
- 队列堆积、超时率上升。
告警阈值先按经验设宽一点，跑两周再根据基线收紧，避免一上线就被误报告警淹没。
## 结论：最小监控集合
上线第一天就要有：全量 trace、副作用审计、token 按任务归因、核心告警（失败率 / token 突增 / 循环调用）。dashboard 可以简陋，但数据必须全。记住一句话：Agent 系统的问题从不会自己消失，只会藏在你没看的地方。