06 — 匿名交付
某内地企业 · 生产运维
告警到恢复的运维智能体
把告警 → 证据 → 恢复变成一条有责任人的闭环。
平台运维需要在分散的控制面 API 之间做巡检、处理告警与排查作业。真正有用的 Agent 不是通用聊天，而是一条有边界的流程：收集正确工件、解释发现，并在写操作前停下来。
我们交付定时巡检与告警驱动排障。Agent 沿任务或实例串联日志、SQL 与血缘，提出重跑或下一步建议；如要改变生产状态，值班工程师仍在审批链路中。
工作里
定时巡检
每小时覆盖取代每周脚本仪式，为每次事故建立一致起点。
先取工件，不猜原因
实例状态、日志、SQL 与血缘先被串联，Agent 才解释可能原因。
写操作由人负责
重跑与调参保持范围限制和审批，Agent 加速排查而不让事故失去责任人。
问题与背景
平台工程师定位典型故障常需 30 分钟以上，每周人工巡检脚本耗时 2–4 小时；告警、日志与作业上下文各自存在，没有可重复的闭环。
量化结果
每小时全量巡检取代每周 2–4 小时人工脚本；典型故障定位由 30 分钟以上缩短至 5 分钟内，平台运维 On-call 量下降 60%+；约 60 名工程师日常使用，30%+ 任务失败咨询可自助闭环。
合作范围
- 每小时全量巡检与告警触发排障
- 作业／实例 → 日志工件 → SQL／血缘 → 重跑建议
- 审批门槛、Trace 传递与 On-call 交接
交付内容
- → 定时与事件驱动的运维智能体工作流
- → 作业、实例、日志、告警、元数据、血缘与 SQL 的 MCP Adapter
- → 企业微信与 CLI 入口，共用同一追踪上下文
匿名说明
委托方名称与内部运维标识不公开；耗时与 On-call 指标来自该项目运行记录。