简介：面向通信行业运维人员、网络保障工程师及智能化运维开发者，一套以智能体为核心的重保项目全流程管理方案，覆盖保障前、中、后三阶段各项操作。方案具体讲解如何通过自然语言指令驱动智能体完成保障项目创建、重保模板导入、保障小区关联，以及基于感知和普通策略的容量预测；同时涵盖预案执行反馈、质差处理反馈的批量导入，以及保障监控报告和总结报告的生成与查询。在此基础上，智能问数能力可针对保障项目数量、小区分布、容量预测结果、指标趋势等提供多维统计与查询，便于快速定位问题、支撑决策。资源包为一个docx格式文档，大小为5.72MB，内容结构完整，按业务流程组织，既有话术示例也有逻辑说明，适合跟随保障前、中、后节奏逐步实践。已有672人学习下载，对通信智能化运维与重大活动保障效率提升有直接参考价值。

1. 通信保障重保项目里，智能体如何让容量预测和预案执行不再靠人肉接力

大型演出散场、体育赛事开赛、电商大促这类场景，通信保障团队最怕的不是设备故障，而是容量预测失灵和预案执行跟不上：明明提前做了场馆周边扩容，开场前两小时话务峰值一来，还是得靠人盯着指标打一轮电话，才把应急策略放下去。这个标题做的事，是把重保项目的全流程拆成两条自动化主线——容量预测环节负责提前告诉你会不会被撑爆，预案执行自动化环节负责在预测触发时把应急策略自动下发、验证和回滚，智能体在中间做感知和编排，让预测和执行不再断档。这套系统设计适合负责重大活动通信保障的运维工程师、网络规划人员，也适合想把保障流程从人肉值班升级成可审计自动化流程的研发团队。

2. 先搞懂智能体在这个系统里的真正身位：预测与执行闭环的四段式编排

2.1 传统重保流程在容量侧和预案侧各断一截：预测靠表格、执行靠电话

传统重保流程有两个长期痛点。容量预测环节多数靠两样东西：往年同档活动的历史数据表，加上老师傅的经验判断。数据表记录的是上周同期、去年同比的话务量、PRB利用率和RRC连接数，经验判断则是对“这次演唱会票卖得比上次好、开场时间提前”这类变量的感性修正。这套做法的问题在于颗粒度太粗，只能估算到“场馆周边整体会忙”，没办法落到具体小区、具体时段，更没办法给出概率意义上的峰值区间，扩容和载波调配自然只能按最大预估去做，资源浪费和保障缺口同时存在。

预案执行环节更原始。即使预测做出来了，预案通常是一份Word文档，写着“当某小区利用率超过80%时，执行扩容操作并通知保障组”。真到触发那一刻，值班人员要先找到文档、翻到对应章节、再登录网管系统手工下发配置，快则十几分钟，慢则半小时。这个时延放在开场前峰值曲线陡升的场景里，基本等于没救。复盘时写报告，靠聊天记录和值班日志拼时间线，经常说不清某个操作到底是几点几分执行的、当时决策依据是什么。预测侧断在“算不准”，执行侧断在“来不及”，两块彼此独立，中间没有编排层。

这个标题想解决的，正是把这两段接起来：预测结果直接成为执行动作的触发条件，执行过程和结果再回填给预测模块做效果评估。智能体的价值不在单点算法，而在把感知、判断、动作、恢复这四个环节做成一个闭环，替代原来靠人肉接力才能完成的流程。

2.2 智能体的四段式循环：感知、决策、执行、回滚如何把流程串起来

做智能体开发时，我习惯把重保场景里的智能体定义成一个四段式循环，而不是一个“能对话的机器人”。第一段是感知，持续采集小区级KPI、保障事件时间表、天气、票务人数这类外部因子，把离散数据整理成当前保障态势的快照。第二段是决策，把感知结果送进容量预测模型，输出未来几个小时的容量分位数预测，再和预案库里的触发条件做匹配，决定“要不要动、动哪个预案”。第三段是执行，调用网管系统、配置下发网关、工单系统的接口，把预案里的动作按顺序执行下去。第四段是回滚，执行完成后持续验证指标，如果容量没有回落、或出现异常，就按预案定义的回滚逻辑恢复原状或者转人工介入。

这个循环和传统自动化脚本的本质区别在于：脚本只认固定触发条件，比如“利用率>80就执行某条命令”，它没有上下文，也不知道这次预测是来自哪个时段的哪个分位数、置信度有多高。智能体的决策段把这些上下文全部带上了，同一个动作在不同置信度下可以走不同路径——预测置信度低时先通知人工复核，置信度高时才走自动下发。

2.3 系统设计的两个边界：单智能体编排优先，别急着上多智能体协商

这个标题下最容易翻车的设计决策，是过度设计。一听到“基于智能体”，就想着要上多智能体协同、用多个agent分别管预测、管执行、管回滚，再做任务协商。真实场景里，重保流程是强时序依赖：先有预测，再有预案匹配，然后才有执行和验证，中间不存在多个目标需要谈判协商的余地。硬拆成多智能体，只是把一条流水线变成了需要互相通信的多个服务，引入的时序不确定性和消息延迟，反而是保障场景最不能接受的。

我一般会建议从单智能体编排起步，把预测、匹配、执行、回滚做成一个工作流里的四个阶段，每个阶段有明确的输入输出和超时上限。这个方案比多智能体简单得多，也更容易做审计——任何一个动作都能追溯到“哪条预测、哪个阈值、哪条预案”触发的。至于“智能体框架”和“智能体架构”的选型，用现成的智能体平台，还是自研Workflow引擎，在这个场景里不是关键，关键是循环本身要闭合，并且每个环节都要有日志。后面章节给出的代码骨架，不改也能直接套进主流框架里跑。

3. 容量预测子系统设计：从KPI时序特征到分位数回归模型的可复现代码

3.1 特征工程：先回答“预测什么、用什么预测”，特征工厂的代码实现

容量预测的第一步不是建模，而是把特征定义清楚。这个场景下预测的目标是小区级PRB利用率，粒度到小时即可——保障场景的动作下发通常也是小时级决策，再细到分钟级在实际执行中意义不大。特征上分四类：第一类是目标值的历史形态，包括前3天、前7天同一小时的利用率、用户数和下行流量；第二类是保障事件的相对时间位置，用“距离事件开始还有几个小时”来刻画，这样模型能学到开场前两小时曲线陡升的规律；第三类是事件属性，包括票务人数、场馆规模、天气；第四类是基础时间特征，小时、星期几、是否节假日。

# 特征工厂：从原始KPI时间序列构造训练样本 import pandas as pd import numpy as np def build_features(kpi_df, event_df, window_h=24): """ kpi_df: 小区粒度小时级容量KPI 列: cell_id, ts, prb_util, rrc_users, dl_traffic_gb event_df: 保障事件表 列: cell_id, event_id, t_start, t_end, attendee_num """ df = kpi_df.merge(event_df, on=['cell_id'], how='left') df['ts'] = pd.to_datetime(df['ts']) df['hour'] = df['ts'].dt.hour df['dow'] = df['ts'].dt.dayofweek # 相对保障时刻的位置：负数为保障前，正数为保障开始后 df['rel_hour'] = (df['ts'] - df['t_start']).dt.total_seconds() / 3600 # 历史滞后窗口：保留同时段形态，比滑动平均更有效 for lag in [3, 7]: tmp = kpi_df.copy() tmp['ts'] = tmp['ts'] + pd.Timedelta(days=lag) tmp = tmp.rename(columns={ 'prb_util': f'prb_util_lag{lag}d', 'rrc_users': f'rrc_users_lag{lag}d', 'dl_traffic_gb': f'dl_traffic_lag{lag}d'}) df = df.merge(tmp, on=['cell_id', 'ts'], how='left') # 票务人数取对数，消除量级差异 df['attendee_weight'] = np.log1p(df['attendee_num'].fillna(0)) return df

这里最值得说明的是滞后窗口的选择。直接用过去7天的滑动平均，会把忙时和闲时混在一起，形态被抹平；取“前3天同一小时”和“前7天同一小时”，保留的是与预测时刻相同时间段的流量形态，电话会议型写字楼和演出场馆的曲线差异才能被模型捕捉到。rel_hour这个特征在保障场景里几乎是决定性特征：它会告诉模型现在处于入场前2小时还是散场后1小时，这两个时段的流量行为完全不同。attendee_weight取log1p，是因为票务人数从几千到几万跨度太大，线性特征容易主导模型，对数变换后成为温和的缩放因子。

3.2 训练LightGBM分位数回归：参数表与三个必调参数

预测目标上，我强烈建议用分位数回归而不是普通回归。普通均方误差回归输出的是期望值，对容量保障来说等于“平均会到这个水平”，但我们要的是“最坏情况下会到多少”。分位数回归可以输出0.5、0.9、0.99三档，分别对应中位预期、保守预期和极端预期，决策侧按不同档位触发不同预案。LightGBM原生支持分位数回归目标，改一个objective参数就能切换，训练代价几乎没有增加。

import lightgbm as lgb from sklearn.model_selection import TimeSeriesSplit import numpy as np params = { 'objective': 'quantile', 'alpha': 0.95, # 预测95%分位，给容量余量留buffer 'num_leaves': 63, # 容量曲线非线性强，叶子数不能太小 'learning_rate': 0.05, 'min_data_in_leaf': 30, # 防止小样本叶子，保障数据量有限 'feature_fraction': 0.8, # 列采样，抑制过拟合 'verbosity': -1, } # 时序分裂，防止未来信息泄漏 tscv = TimeSeriesSplit(n_splits=5) oof_pred = np.zeros(len(train_df)) for tr_idx, va_idx in tscv.split(train_df): tr, va = train_df.iloc[tr_idx], train_df.iloc[va_idx] dtr = lgb.Dataset(tr[feat_cols], tr['prb_util']) dva = lgb.Dataset(va[feat_cols], va['prb_util'], reference=dtr) model = lgb.train(params, dtr, num_boost_round=500, valid_sets=[dva], callbacks=[lgb.early_stopping(50)]) oof_pred[va_idx] = model.predict(va[feat_cols], num_iteration=model.best_iteration)

三个必调参数值得单独说。alpha是分位数目标的核心参数，0.95意味着预测值有95%概率覆盖实际容量，实际中不建议直接拉到0.99——极端分位数在数据有限时方差很大，预测曲线会抖动到没法用，从0.9起步、验证后再上调更稳妥。min_data_in_leaf在重保场景里要设大一点，因为保障事件本身是稀疏的，一个月可能只有几场，叶子太小学到的是单场事件的噪声。feature_fraction设到0.8，是为了在参数有限的特征集上减少过拟合，同时保留每棵树的稳定性和可解释性。

3.3 从分位数到保障等级：容量利用率阈值与三级预案的映射

模型输出的是分位数预测值，落到执行侧需要映射成保障等级和具体动作。这个映射我一般做成表格驱动，而不是在代码里写死条件——运营人员改阈值不需要动代码，改配置文件即可。核心指标是预测PRB利用率，分位数档位决定置信等级，两者交叉得到最终动作。

阈值80%本身不能一刀切。忙时利用率和闲时利用率差两三倍的小区，同一个绝对阈值要么频发误报、要么永远不报，第5章会单独讲动态基线的处理方式。映射表的价值在于把预测分位数的概率语义和执行动作的保守程度对齐：中位数预测到80%，说明“大概率会满”，先通知人盯着；极端分位数到80%，说明“最坏情况会满”，需要直接上硬动作。这样既不会把所有压力都堆给值班人员，也不会让自动化系统在小概率事件上反应过度。

4. 预案执行自动化设计：YAML模板驱动的动作编排与安全回滚

4.1 把Word预案重写成机器可读的YAML：条件、动作、回滚字段

预案执行自动化的前提，是预案本身能被机器解析。传统重保预案写在Word里，自然语言描述让自动化系统无从下手。改造的第一步是定义预案Schema，把每个预案拆成五个部分：触发条件、执行动作、验证条件、回滚逻辑、审批策略。YAML恰好适合做这件事，层级清晰、支持注释、写错了有语法校验。

id: PRE-2024-0701-001 name: 大型演出开场容量应急预案 ownership: owner_group: 无线优化组 approval_required: true # 关键动作需要人工审批 trigger: metric: prb_util predicted_quantile: 0.90 threshold: 80 duration_mins: 15 # 预测持续15分钟超阈值才触发 actions: - name: soft_expand_carrier type: config # 配置下发类动作 target: basestation_controller params: cell_ids: ["${cell_id_list}"] # 执行时从上下文注入 config_set: "soft_cap_expand_v2" timeout_sec: 120 - name: notify_group type: notify target: im_group params: message: "预测容量超过80%，已下发软扩容，请观测" verify: after_action_sec: 300 # 执行后等5分钟再验证 metric: prb_util condition: "< 75" rollback: on_verify_fail: revert_last_action on_timeout: revert_last_action auto: false # 回滚默认转人工确认，经过演练后再放开

trigger里的duration_mins很多人会漏掉，它解决的是预测抖动问题。单次预测过阈值可能是模型噪声，持续15分钟预测都过阈值才是真趋势，这个参数能显著降低误触发率。actions里的timeout_sec必须显式设置，否则一次网管接口卡顿会让整个执行循环挂死。rollback部分最初可以全部设为auto: false，等同一预案在演练环境跑过三轮以上，再逐步放开成自动回滚，这是最稳妥的灰度策略。

4.2 编排引擎的核心循环：状态机里跑感知-行动，不透支并发

预案解析完之后，需要有一个执行循环把预测结果和预案绑定起来。这个循环本质是一个轻量状态机：每次收到新的预测结果，就做预案匹配，匹配上就执行动作序列，然后进入验证状态，根据验证结果决定转入回滚还是完结。不能把执行循环设计成简单的顺序脚本，因为真实环境中动作可能半路失败、可能超时，每一步都需要有状态记录和对应的恢复路径。

import time from dataclasses import dataclass @dataclass class ActionRecord: action_id: str status: str # pending / done / failed / rolled_back verify_result: dict class ExecutionLoop: def __init__(self, executor, verifier, plan_repo): self.executor = executor self.verifier = verifier self.plan_repo = plan_repo def run_once(self, prediction, cell_ctx): # 1. 根据预测分位数和当前小区上下文匹配预案 plan = self.plan_repo.match( prediction, cell_ctx, quantile=prediction.quantile, threshold=prediction.prb_util) if plan is None: return None # 2. 逐个执行动作，带超时控制 for action in plan.actions: rec = self.executor.run(action, timeout=action.timeout_sec) if rec.status != 'done': # 动作失败直接进入回滚判断 return self._rollback(plan, rec) # 3. 执行完成后等待指定时间，验证容量是否回落 verify_ok = self.verifier.check( plan.verify.metric, plan.verify.condition, wait=plan.verify.after_action_sec) if not verify_ok and plan.rollback.auto: return self._rollback(plan, rec) return plan

这段代码最核心的设计是ActionRecord这个结构。它让每一次下发、每一次验证都有据可查，对应审计需求里的“什么时间、谁触发、结果如何”。执行循环本身不持有任何业务逻辑，业务规则全部在预案YAML里，这样有一个额外的好处：新增预案不需要改代码，运营人员写完YAML提交进预案库即可生效。匹配函数里带上quantile参数，是为了让同一个阈值下不同置信度走不同的预案分支，类似3.3节里的三级映射。

4.3 与网管系统和工单接口的对接：执行超时、人工复核、变更窗避让

执行循环跑起来之后，真正的复杂度在接口对接。重保场景涉及三类外部系统：网管配置下发网关、工单系统、即时通讯通知网关。配置下发是核心动作，但也是最容易翻车的环节——网管系统往往连接着数百个基站控制器，接口响应时间不稳定，批量下发时经常出现部分成功部分失败的情况。常见做法是为每个动作设置明确超时，超时后先查部分成功状态，再决定回滚还是重试，不能简单暴力重发。

两个容易被忽略的设计点。第一是人工复核位，预案里approval_required为true时，执行到关键动作前必须挂起等待审批，审批超时默认不执行，这个机制能避免自动化系统在合规流程面前踩红线。第二是变更窗口避让，编排引擎在解析预案时要同步检查变更日历，如果当前时间落在例行变更窗口内，自动把执行时间顺延到窗口结束后，或者降级为只通知不动作——重保再急，也不能和既定变更流程抢时间窗口，这是运维合规的基本底线。

5. 重保自动化系统落地的五个避坑记录：从数据断裂到回滚失效

5.1 小区分裂合并导致时序断点，模型把割接当天学成了正常态

现象：模型上线后第一次重保预测就出现异常，某些小区预测曲线在割接日前后出现断崖式下跌，RMSE比平时高三倍以上，且误差集中在最近一周的数据上。原因：保障活动前运营商常做网络优化，把高负载小区分裂成两个、或把低负载小区合并，物理小区ID发生了变化。特征工程按cell_id关联前3天、前7天历史窗口时，取到的是旧小区的数据，和当前小区的容量行为完全没有关系，模型等于在用一段不存在的历史做预测。解决：建立小区簇映射表，把分裂合并的小区映射到同一个逻辑簇ID，特征工程按簇ID取历史；同时给新建小区打冷启动标签，冷启动期间不用滞后特征，用周边同类型小区同时段均值兜底。

5.2 固定容量阈值在忙闲时差异下反复误报，逼得值班组关闭告警

现象：阈值设80%后，白天商业区小区频繁触发二级预警，深夜几乎从不触发。值班组被无效告警轰炸两周后，直接把预警等级降级，结果一场真正的周末赛事保障反而漏了告警。原因：固定绝对阈值没有考虑小区自身的忙闲基线，同一个小区凌晨3点的40%利用率和下午3点的40%利用率含义完全不同。解决：引入动态基线，取每个小区过去28天同时段利用率的中位数作为基线值，触发条件改为“预测利用率超过基线值的1.5倍，且绝对值超过60%”，两者取高者生效。这个改动让误报率在生产环境下降了约六成。

5.3 自动执行撞上变更窗口，被合规流程硬生生叫停

现象：预案在晚间高峰期自动下发软扩容配置，执行到一半被运维合规平台拦截，原因是该时段处于例行版本发布的变更窗口内，自动变更操作被判定违规。原因：编排引擎只考虑了预测和预案匹配，完全没有查变更日历。网络运维的变更管控体系会锁住窗口时段内的配置变更操作，自动化系统绕过这道锁就是合规事故。解决：在ExecutionLoop的预案匹配之后加一道变更窗口检查，冲突时把动作降级为“仅通知+等待窗口结束”，或者在预案YAML里增加allowed_changewindows字段，让预案作者提前声明哪些时段允许自动执行。

5.4 预案没写回滚条件，执行后给现网留了半截配置

现象：一次软扩容下发后验证条件（利用率降到75%以下）没达成，系统没有报错，也没有清理动作，设备上一直留着扩容参数。三天后另一个保障场景复用该设备，出现参数冲突。原因：预案模板的rollback字段在早期版本里是可选填，执行循环在验证失败时发现rollback为空，默认当作“不需要处理”。解决：预案Schema把rollback设为必填；验证失败且rollback缺失时，执行循环直接置为异常状态并通知负责人介入，而不是静默通过。后续版本又加了自动回滚开关，但默认仍是转人工确认，只有经过多轮演练的预案才允许auto: true。

5.5 模型上线后不看分布漂移，预测越来越乐观直到某天失灵

现象：容量预测模型上线后前三个月表现很好，之后预测值持续偏低，误差逐月增大，直到一场大型赛事当天预测利用率70%，实际冲到了93%，预案触发晚了近一小时。原因：用户行为在变化，直播类大流量业务占比上升，小区流量均值整体抬高，但模型训练集还是几个月前的分布，特征和目标的联合分布已经漂移。解决：加预测偏差监控，每日对比预测分位数与实际值的中位数偏差，偏差连续三天超过±10%就触发自动重训流程。这个监控指标本身要画在保障大屏上，运维人员每天扫一眼就能发现模型是否在偷偷失效。

6. 让这套系统真正可信的最后一公里：回测、演练与行为审计三板斧

6.1 用历史保障事件做滑窗回测：先证明预测不会带偏执行

新系统上线前，我会先拿最近三场完整重保事件的历史KPI做滑窗回测。回测目标不是看RMSE，而是看预测提前量和动作有效性：预测曲线是否在峰值前至少两个小时抬升、预案触发时刻是否足够早、验证条件在真实数据上是否成立。回测脚本复用第3章的模型和第4章的执行编排循环，只是把预测和执行的接口替换成历史数据回放。如果回测里预案触发后验证条件在演练数据上从未通过，那一定不是模型问题，而是阈值映射不合理——先查动态基线，再查分位数档位，别急着调模型参数。

6.2 演练剧本与故障注入：把预案执行当压测一样跑

回测证明模型可行之后，还要在仿真环境做故障注入演练。常见做法是准备三种剧本：容量陡增剧本，在开场前30分钟把目标小区利用率从50%拉到95%，验证软扩容预案能否触发、执行、验证闭环；接口超时剧本，让网管配置下发接口随机返回超时，验证状态机能否正确记录失败并回滚；双预案冲突剧本，同时命中两个预案，验证编排引擎按优先级只执行高等级预案而不互相覆盖。演练产出的执行延时数据，直接作为预案YAML里timeout_sec和after_action_sec的调参依据。

6.3 智能体行为审计：记录每一次决策上下文，复盘才有据可查

重保结束后的复盘，最怕说不清楚“当时为什么这样做”。这套系统里的每次动作，从预测结果到预案匹配、到审批人、到下发结果、到验证数据，都要落审计日志。我给每条日志定义一个结构化上下文：trigger_context包含预测分位数、阈值、动态基线的实测值；action_context包含动作ID、目标小区列表、执行耗时；verify_context包含验证指标前后对比。这样复盘时导出的不是一堆命令行的零散记录，而是一条完整的时间线。以我自己的习惯，这套审计日志也会用来做月度质量分析，看哪类预案触发次数最多、哪类回滚最频繁，下个季度的保障策略调整完全靠数据说话，而不是靠感觉。这套系统从设计到落地，最大的教训就是永远别信“预测很准”这个感觉，回测数据说行，才敢让它上生产。希望帮到你。

本文还有配套的精品资源，点击获取