上海企业内部 AI Agent 运维监控：从零搭建完整可观测体系

企业 AI Agent 系统与传统应用的运维有本质不同：Agent 会自主决策、调用工具、与用户对话，甚至与其他 Agent 协作——这种"行为不确定性"使得传统监控手段（CPU/内存/响应时间）完全不够用。你监控了服务器的健康，却不知道 Agent 在做什么、为什么这么做、做得对不对。

环曜团队在服务上海多家企业的过程中，总结出一套面向 AI Agent 系统的可观测体系搭建框架——PROM-5（Performance 监控→Resource 管理→Observability 可观测→Monitor 告警→五类审计），帮助企业从零开始搭建完整的 AI Agent 运维监控体系。

1.1 传统监控 vs Agent 可观测

1.2 上海金融科技公司的教训

该公司的 AI Agent 系统处理客户合规分析，上线 3 周后出现 A Agent 调用 B Agent、B 又调 A 的死循环，一夜产生 4.7 万美元 Token 费。根因：没有 Agent 调用链追踪、没有 Token 预算控制、没有调用深度限制。AI Agent 部署失败案例拆解 中有更多类似的真实踩坑与分析。

2.1 P - Performance 性能监控

AI Agent 的性能指标分为三层：

2.2 R - Resource 资源管理

AI Agent 系统的资源管理包括 Token 预算管理（设置每日/每月上限，环曜 Claw 内置 Token 预算控制系统）和模型资源池（小模型处理简单查询，大模型处理复杂推理，环曜 Claw 支持模型路由策略）。

2.3 O - Observability 可观测性

AI Agent 需要三层日志体系：推理链日志（保留 7 天，排查决策异常）、工具调用日志（保留 30 天，审计 Agent 行为）、系统日志（保留 90 天，系统级故障排查）。生产环境设置为 INFO 级别，仅在排查问题时临时开启 DEBUG。

上海团队的解决方案是使用环曜 Claw 提供的全链路追踪功能——每个 Agent 请求生成一个 Trace ID，记录完整的调用链路径，配合可视化界面展示调用拓扑图。

2.4 M - Monitor 告警

2.5 五类审计

AI Agent 系统需要五类审计日志：决策审计（Agent 推理过程，保留 6 个月）、数据访问审计（保留 1 年）、模型调用审计（保留 1 年）、用户交互审计（保留 1 年）、权限变更审计（保留 2 年）。环曜 Claw 内置了完整的企业级审计日志系统。

3.1 架构概览

架构流： AI Agent 系统（环曜 Claw）→ Prometheus Metrics API → Prometheus Server → Grafana，通过 Alertmanager 向企业微信/Slack/PagerDuty 发送告警。

3.2 Prometheus 配置

核心 scrape 配置：

scrape_configs:
  - job_name: 'ai-agent'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['localhost:8080']  # 环曜 Claw Metrics 端口
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']  # Node Exporter

3.3 关键告警规则

groups:
  - name: ai-agent-alerts
    rules:
      - alert: TokenBudgetWarning
        expr: daily_token_usage / daily_token_budget > 0.8
        for: 5m
      - alert: AgentLoopDetected
        expr: agent_call_depth > 3
        for: 1m

该团队在接入 PROM-5 框架后，用 2 周时间完成了可观测体系搭建，详细的 Agent 系统部署与选型背景可参考 长三角制造企业 AI Agent 落地调研报告。

2. 日志级别用 INFO 不要用 DEBUG：Agent 系统的日志量远超传统应用，DEBUG 级别会把磁盘写满

3. 设置 Token 熔断机制：日 Token 消耗超预算 80% 时自动告警，达到上限时自动熔断

4. 保留人工审批通道：高危操作（批量删除、数据导出）必须有 HITL 审批流。结合 江苏制造业实战经验 可以形成完整的运维闭环