模型超时、API 限流、工具权限变化、工作流节点报错，任务停在半路没人接手。
AI RUN / OPERATE / IMPROVE
AI 上线之后，
也要有人持续看着它。
模型会更新，资料会变化，调用会失败，成本会波动，员工也会遇到新问题。我们按约定检查运行状态、任务质量和使用成本，处理范围内的问题，并把需要改进的地方变成下一步计划。
不是只看服务器在线·不默认 7×24 小时托管·范围与账单透明
AI SERVICE / AFTER GO-LIVE CARE PLAN
CONTINUOUS运行保障观察 → 判断 → 处理 → 复盘
01服务状态失败 · 延迟 · 资源
02任务质量抽检 · 返工 · 转人工
03使用成本API · 云资源 · 单任务
每个告警都要有负责人、处理规则和回退办法。
为什么“已经上线”还不够 / THE WORK AFTER LAUNCH
AI 正在用，但你可能并不知道它
是不是还在好好工作。
很多问题不会表现为系统彻底宕机：它可能还在回复，却开始引用旧资料；接口还通着，但重试变多、账单突然上升；员工没有报错，却悄悄绕开了工具。
模型版本、提示词、知识资料或业务规则变化后，答案引用不准、格式变差、人工修改增多。
多个应用共用 API、不同任务消耗差异大，客户只看到总账单，不知道是哪项流程在花钱。
员工重复遇到错误答案或操作中断，但不知道如何提交问题，也没人负责分类和回访。
本地 GPU 显存、存储和温度使用不清；模型文件重复；备份、升级和恢复步骤没人维护。
换模型、改工作流、更新依赖后，没有固定样例回归验证，也没有明确回滚方案。
具体会关注什么 / WHAT WE LOOK AFTER
不只盯机器，
还要看 AI 有没有完成工作。
服务从客户已有系统出发。可能只需要巡检和用量复盘，也可能需要把应用、知识库、GPU 环境和团队反馈一起纳入约定范围。
服务能否稳定被访问
关注服务可用情况、失败任务、超时、重试、错误类型、依赖服务和告警处理记录。重点不是堆一块仪表盘，而是明确出现问题之后谁来判断、如何恢复。
检查项：运行状态 · 延迟 · 失败率 · 依赖连接 · 恢复记录
流程在哪一步卡住
查看模型调用、工具执行、检索、审批和人工接管是否按预期发生。对异常情况做分类，区分模型问题、数据问题、权限问题和业务规则问题。
检查项：节点失败 · 工具调用 · 重试 · 任务完成 · 人工接手
结果是否可信、能否复核
按客户约定的样例和抽检方式评估答案来源、事实匹配、格式完整度、未命中率和人工修改原因。知识资料更新时，确认检索与回答是否受影响。
检查项：来源引用 · 抽检结果 · 返工原因 · 未命中 · 版本变化
用量变化能不能解释清楚
整理可获取的模型调用量、任务类别、模型路由和第三方账单；识别异常增长，讨论限额、缓存、模型选择或流程缩短等优化办法。
检查项：调用量 · 费用归属 · 预算提醒 · 单任务成本 · 异常波动
设备、存储和备份是否可维护
对约定的工作站、服务器或局域网服务检查资源余量、存储、备份状态和版本记录。硬件故障处理、备件、现场维护和保修根据具体合同另行约定。
检查项：GPU/显存 · 磁盘 · 温度与告警 · 备份 · 更新记录
工具是否真正进入日常工作
结合活跃使用、任务放弃、常见疑问和用户反馈，发现培训缺口、流程摩擦或不适合自动化的环节，并提出下一轮优化建议。
检查项：采用情况 · 使用反馈 · 培训问题 · 任务绕行 · 新需求
日志和追踪要先定好数据边界。AI 运行记录可能包含用户输入、模型输出或工具参数。接入监控前先确认记录内容、脱敏规则、访问权限和保留时间；不是所有项目都需要保存完整对话。
服务周期 / A REPEATABLE OPERATING LOOP
每个周期都能回答四件事：
发生了什么，处理了什么，接下来做什么。
根据服务深度按周、月或季度复盘。频率、指标和响应时间应在合同里约定，不能因为有月费就默认包含无限修改或随时响应。
确认运行对象与基线
列明服务、模型、数据源、责任人、服务时段和已知风险；定义任务成功、质量抽检与用量口径。
收集必要的运行信号
按授权采集状态、错误、延迟、成本和质量样例；减少不必要的敏感内容记录。
分类问题并按约处理
区分服务故障、第三方故障、资料或规则变化、用户误用和新增需求；记录负责人和处理结论。
复盘并决定改进优先级
对比基线与本期变化，给出已处理事项、待客户决定事项、风险、成本情况和下期建议。
每期服务交付样例
让客户拿到一份能用于经营和技术决策的运行简报。
运行状态与异常清单任务失败 / 延迟 / 重试趋势抽检质量与人工修改原因API 和云资源用量明细已处理事项与变更记录风险、责任人和下期计划
怎么衡量有用 / MEASURE WHAT MATTERS
系统指标和业务指标，
要放在一起看。
不能只用“模型调用成功”代表业务成功。每项指标要有定义、数据来源、复核责任和可解释的例外。
按你的运行需要选择合作方式 / SERVICE MODES
从上线护航到持续支持，
按系统重要程度和团队能力来选。
不是所有客户都需要长期托管。可以只买阶段性检查，也可以把指定应用纳入持续服务；已有内部 IT 或软件供应商的客户同样可以采用协同模式。
部署刚完成
上线护航
在约定的初期运行阶段观察真实使用问题，处理约定范围内的配置与使用障碍，收集员工反馈，补齐操作文档和已知限制。
- 确认系统与责任人清单
- 处理部署后问题与使用疑问
- 阶段复盘并给出移交建议
需要定期看状态
月度 / 季度运行巡检
按固定周期检查约定系统、运行日志、异常、用量和反馈，形成问题清单与建议。客户内部人员负责日常处置，我们提供诊断和周期性专业支持。
- 约定频率的远程检查
- 用量与异常变化说明
- 周期运行简报和下期事项
流程已影响日常工作
持续运行支持
把指定 AI 应用或流程纳入持续关注范围，按约定支持时段接收问题、分级、定位和跟进；定期评估质量、成本和变化风险。
- 服务目录、问题等级与升级路径
- 约定时段内响应和进展同步
- 固定范围内的小型配置优化
需要改变或扩展
专项优化与顾问支持
模型替换、流程重构、增加新部门、接入新系统、硬件扩容或新增 Agent 等变化，按专项工作重新评估、设计、实施和验收。
- 变更影响与风险评估
- 测试样例与回归验证
- 变更记录、回滚与知识交接
这不是一条和咨询、培训、部署互相排斥的业务轨道。运行保障可以独立接手客户已有系统，也可以接在顾问诊断、团队培训、硬件部署或 FDE 项目之后。具体组合按客户当前问题、内部人员和责任边界决定。
费用怎么拆，客户才看得明白 / CLEAR COSTS
服务费、专项改造费、
API 用量费分别列清楚。
建议让客户保留第三方服务账号和账单可见权。实际费用以供应商账单和合同约定为准，避免把用量费藏在“运维套餐”里。
费用类型常见计费方式应提前约定什么
运行服务费按月、按年或按约定周期系统范围、巡检频率、支持时段、响应目标、报告内容、包含工时
专项改造费按项目、阶段或工作量新增流程、模型调整、系统集成、现场服务和验收标准
API / 云模型用量客户直接支付，或按第三方账单透明结算模型与账号归属、用量明细、预算提醒、上限与超额处理
云资源 / 软件订阅由客户订阅或分项代采代付续费责任、账号控制权、数据迁移和停止服务后的处理
硬件与保修按设备采购与实际维护项目结算供货品牌、厂商质保、备件、上门范围和故障责任
响应和责任必须说清 / SERVICE BOUNDARIES
承诺范围内的响应，
比含糊的“包运维”更可靠。
只有建立了值守、升级、告警和应急机制，才能承诺全天候响应。服务页面和合同都要避免超出实际团队能力的承诺。
合同里要写明
- 纳入服务的应用、账号、设备和环境
- 服务时段、问题等级、响应与升级路径
- 远程支持、现场服务与第三方故障边界
- 巡检、报告、包含工时和变更审批方式
- 数据记录、访问权限、保留和删除要求
默认不应含糊承诺
- 不默认包含 7×24 小时值守
- 不默认包含无限新增功能或修改
- 不保证第三方模型、API 或云服务永不故障
- 不承诺模型零错误或固定节省比例
- 不把“本地部署”表述成自动安全或免维护
客户侧也需要有人负责
- 指定业务负责人和技术联系人
- 及时确认业务规则、样例和权限变更
- 审批敏感操作与关键变更
- 维护第三方账号和费用授权
- 对员工使用反馈和业务结果作判断
关于 AI 追踪与日志：追踪可能记录模型输入输出、工具参数和任务上下文。我们会先确定最小必要记录、敏感字段脱敏、访问权限和保留期限；数据采集本身也要纳入项目授权和客户安全要求。
常见问题 / BEFORE YOU START
关于 AI 运维，
客户常会先问这些。
你们会接管我们的全部 IT 系统吗？
不会默认接管。服务只覆盖清单中明确约定的 AI 应用、模型服务、设备或流程。网络、数据库、业务系统和终端管理是否纳入，要逐项确认责任与权限。
有月费是不是所有问题都包含？
不是。月费对应约定系统、支持时段、巡检频率、包含工时和报告内容。新功能、重大改造、现场硬件维修和超范围工作会先评估并单独报价。
API 费用是包含在服务费里吗？
建议分开。API、云模型和软件订阅等第三方费用由客户直接支付，或按第三方账单透明结算；服务费另列。能否设置预算告警和硬上限取决于具体服务商能力。
你们能保证智能体一直准确吗？
不能保证模型永不出错。可以按约定样例抽检、追踪错误类型、改进提示与资料、补充人工确认并验证变更效果。对高风险动作要保留人工审批和停止路径。
我们的系统是别人做的，也能提供支持吗？
可以先做系统和权限盘点，确认接口、日志、文档、供应商配合和可访问范围，再决定能承接哪些部分。无法观察或无权修改的部分会明确列为依赖或外部责任。
本地服务器也需要持续运维吗？
需要。模型、驱动、容器、磁盘、备份、账号和硬件状态都可能变化。离线或内网环境还要提前规划补丁、模型更新、故障恢复和备份介质管理。
从已有系统开始，不必先换平台
让我们先看你现在运行的 AI，
再决定需要多深的支持。
告诉我们已有的应用或设备、谁在使用、近期遇到的问题、是否能查看运行日志，以及希望的响应方式。我们会先判断适合做一次巡检、上线护航还是持续运行支持。