告警汇总与降噪
优先试点这一场景的目标是把监控告警、拓扑、历史事件和阈值整理成聚合事件、影响面和优先级。
- 输入
- 监控告警、拓扑、历史事件和阈值
- 输出
- 聚合事件、影响面和优先级
- 验收
- 检查工单处置时长、知识命中率、生产变更回退次数
- 边界
- 高风险告警不能被模型自动压制

IT运维适合用AI智能体汇总日志、知识和工单,生产命令、权限与变更必须受控。
左起第一列是这个岗位可交给 WorkBuddy 的场景; 中间两列是它需要什么、能交付什么;最后一列是必须由人或系统决定的部分 —— 这一列才是评审时真正要看的,因为它决定哪些环节不能自动化。
| 场景 | 需要输入 | WorkBuddy可辅助交付 | 人工或系统边界 |
|---|---|---|---|
| 告警汇总与降噪 | 监控告警、拓扑、历史事件和阈值 | 聚合事件、影响面和优先级 | 高风险告警不能被模型自动压制 |
| 日志分析 | 日志、时间、版本、变更和症状 | 异常模式、根因假设和查询语句 | 日志可能含凭据和个人信息,先脱敏 |
| 故障排查 | 症状、日志、指标、部署和最近变更 | 排查树、验证命令和回滚建议 | 生产命令需人工批准 |
| 运维知识库 | SOP、故障单、架构和厂商手册 | 带出处的处理步骤和相似案例 | 版本和环境必须匹配 |
| 工单分类与处置 | 工单、资产、用户和SLA | 分类、优先级、建议和责任组 | 权限、重置和变更动作走审批 |
| 脚本生成 | 任务、环境、限制和回滚要求 | 脚本草案、检查项和试运行方案 | 先在隔离环境测试,禁止未审查生产执行 |
| 系统接口与集成 | 系统、字段、认证、频率和流程 | 接口映射、数据流和异常处理 | 接口幂等、权限、重试和审计必须设计 |
| 部署与巡检 | 环境、版本、配置和检查表 | 部署计划、巡检报告和差异 | 生产发布可回滚,密钥不进入提示词 |
| 资产与权限治理 | 资产、账号、角色和使用日志 | 资产台账、僵尸账号和权限异常 | 权限回收由授权管理员执行 |
三个优先场景在各岗位下按同一套方法拆解:明确任务口径 → 收集并检查输入 → 让 WorkBuddy 执行整理、检索或生成 → 输出可编辑结果 → 由岗位负责人复核后进入下一流程。
这一场景的目标是把监控告警、拓扑、历史事件和阈值整理成聚合事件、影响面和优先级。

这一场景的目标是把日志、时间、版本、变更和症状整理成异常模式、根因假设和查询语句。

这一场景的目标是把症状、日志、指标、部署和最近变更整理成排查树、验证命令和回滚建议。
同一个岗位的场景会分散在四层里:文件层只用本地文档就能跑, 知识层要先建好有版本、有出处、有权限的资料,系统层要接业务系统, 决策层则必须保留人工批准。先看自己能从哪一层起步。
使用本地文档、表格和模板,结果可人工检查
建立有版本、有出处、有权限的知识资料
通过受控的Connector、MCP或API读写业务系统
展示依据、假设和影响,高风险决定由人批准
推荐先做“运维知识库”。它所需输入是SOP、故障单、架构和厂商手册,目标交付是带出处的处理步骤和相似案例。
试点可按四个动作推进:第一,抽取一批真实历史任务作为基线;第二,用同一批输入让人工流程和WorkBuddy流程并行;第三,记录失败、遗漏和人工修改原因;第四,只在结果稳定、权限清楚、可以回滚时扩大范围。
建议验收指标包括:工单处置时长、知识命中率、生产变更回退次数。如果结果需要大量重做、来源无法追溯、系统写入不可回滚,试点应暂停并先修复数据或流程。
把你们这个岗位最耗人的一件事说清楚,我们按上面四层能力给出可切入点、需要对接的系统清单和人工边界 —— 不是通用方案,是照着你们现有流程改的版本。