集成依赖多个可能变化的系统。自动化上线也是运营开始，维护帮助发现问题、保存数据并恢复工作流程。
上线前约定监控与恢复方式。运行中的流程需要负责人和可以检查的历史。
故障从哪里来
API 改变、订阅到期、令牌失效或 CRM 字段改名，都可能影响流程。有时技术仍正常，但新订单类型走了旧规则。
AI 流程也可能在模型、指令或知识库变化后改变质量。一次成功测试不能证明更新后仍正确。
发现停滞或错误工作
技术报错还不够。流程可能无异常结束，却分配错误状态。应检查记录是否创建、负责人是否分配、接收与处理事件能否核对。
通知需要上下文：编号、失败阶段和下一步比重复报错更有用。每个重要提醒都应有人实际查看。
保留有用历史
记录事件时间、编号、已完成步骤及结果。AI 操作的指令和模型版本有助于重现问题，日志中应避免秘密和多余个人数据。
保存期限依流程而定，访问应受限。调查故障不需要在多个系统无限复制每一段对话。
带检查与后备方案的更新
保留正常输入、缺失数据、重复事件和服务不可用的测试案例。每次改动前比较结果，还要检查智能体何时应停下或求助。
先更新有限部分，保留原配置并计划回滚。数据迁移要单独测试，回退代码未必恢复改变的记录格式。
约定维护责任
明确谁监控、服务时间、故障分类和持续服务范围。新增流程与恢复现有流程属于不同工作。
获取访问、依赖、备份和人工处理文档。流程应能够检查，也能交给其他专业人员维护。
示例：CRM 拒收线索
CRM 新增必填字段后，网站仍接受表单但无法建交易。监测收到与确认记录之间的差距，而不只看网站在线。
记录接收、发送、确认和等待状态。提醒应说明故障步骤及恢复位置，避免泄露个人资料。修复后安全重放并核对，防止重复消息；提前准备恢复说明。
写清支持范围
区分约定功能的缺陷、外部服务变化和新功能。另一套 CRM 不自动属于日常维护。
明确时间、渠道、优先级和响应时间，开始排查不等于同期限内修复。指定续费、密钥及限额负责人；夜间关键流程需约定服务和费用。
安全更新
保留工作版本，在安全环境测试普通和异常场景，不能误发消息或修改真实客户数据。
上线后比较错误、耗时和队列，并准备回退或人工路线。模型、指令和知识变更也要检查，服务器有响应不代表答案正确。
每月检查
对比数量、错误、人工介入和费用。账单上涨可能是业务增长或重试循环，需要事件历史来区分。
用简短报告说明修改、故障、处理及剩余问题。企业保留权限、说明及备用流程；支持的目标是可管理，而不是承诺永不故障。
检查清单
- 指定提醒与恢复负责人。
- 同时监控业务结果和 API 故障。
- 使用代表案例测试改动。
- 约定维护、文档和人工后备方案。
