核心框架：AI 工程循环
监控是 AI 工程循环的一环：生产追踪 → 结构化迭代 → 数据集/实验/评估 → 新数据 → 循环。
追踪（Tracing）记录每一次请求、模型调用、工具使用。监控（Monitoring）让你理解这些数据——持续观察系统表现，并 surface 值得调查的个案。
两类监控活动
| 类型 | 回答的问题 | 示例 |
|---|---|---|
| 聚合指标追踪 | 事情在变好还是变坏？ | 成本、延迟、评估分数的趋势 |
| 信号检测 | 现在该看哪里？ | 错误、重试集群、用户中途放弃 |
信号的价值在于它附着到触发它的具体 trace——那个 trace 是你理解问题的起点。
指标和信号从哪来
基础数据来自正确插桩后的观测：延迟、token 衍生成本、模型和路由元数据、工具结果、错误——这些通常从客户端和 provider API 自动流出，无需额外接线。
之上叠加评估：
- 显式反馈：点赞/点踩、星级评分、用户评论——信号明确，但响应率低且偏向不满意用户
- 隐式反馈：从行为推导——重试查询、与系统分歧、复制响应、接受建议、中途放弃对话——无需用户努力、数据量大，但信号间接需解读
实例：客服聊天机器人
- 显式：对话结束时的 thumbs up/down
- 隐式：对话中途请求人工接管
两者都注册为分数，进入同一仪表盘、趋势图、信号规则。
两种自动评估器
- LLM-as-a-judge——质量信号或行为模式（如用户分歧）
- Code-based evaluators——精确检查（响应是否包含某词、是否超长度限制）
从哪开始
- 手动看数据——读 trace，注意反复出现的东西。不知道在找什么之前，无法设置有用的监控
- 用错误分析 surface 值得追踪的——结构化地找到跨 trace 的重复问题，转化为持续运行的自动评估器
- 思考你的应用如何表现失败——应用特定的隐式信号（客服中用户分歧、流程自动化中的纠正）通常比通用分数更 actionable
- 视为迭代过程——使用模式变化、模型更新、新故障模式出现，持续精炼监控设置以 cut through noise
发现值得调查的东西后
- 直接修复——如果原因明显
- 捕获到数据集——如果看起来像模式
- 运行结构化评估——如果怀疑系统性问题
关键 takeaway
有用的信号不是平均成功率。是奇怪的恢复、跳过的工具调用、以及模型知道下一步却 quietly walked into a rake 的地方。
生产 trace 是代理从神话落地为工程的地方。监控不是仪表盘，是持续的理解过程。