AI流程执行中断率有两种常用算法：按中断次数算，回答流程运行稳不稳定；按受影响任务数算，回答业务被波及多广。两者分母不同、用途不同，单看一个容易误判。本文给出两个公式、取数字段、去重规则和一组可复算的示例，并说明解读时的限制。
要点总览（TL;DR）
- 中断率有两种口径，回答的问题不同：中断次数率衡量流程运行稳定性，任务影响率衡量业务受影响面，建议并列报告。
- 中断次数率 = 中断次数 ÷ 执行总次数 × 100%，分母是同一时间窗内的有效执行次数，适合按天或按周做值班监控。
- 任务影响率 = 受影响任务数 ÷ 任务总数 × 100%，受影响任务按任务ID去重，同一任务在同一窗口内只计一次。
- 一次中断波及多个任务时，中断次数仍计一次，受影响任务数按实际波及任务去重计数；分母为零时报告为不适用并注明原因。
- 两个口径的结果不能直接横向比较不同流程，趋势对比前需确认中断定义、统计范围、时间窗和去重规则保持一致。
评估目标：中断率要回答哪两个问题
中断率首先是一个运行监控指标，其次才是一个影响评估指标。这两个用途对应两类问题：流程本身跑得顺不顺，以及流程出问题时有多少业务任务被卡住。把两个问题混在一个数字里，就会出现“中断率很低但业务抱怨很多”或“中断率偏高但实际影响有限”的矛盾观感。
按中断次数统计，关注的是执行单元的失败频率。一次执行失败就是一次中断，无论这次执行背后是一张单据、一个代码合并请求还是一批数据处理。这个口径适合值班监控、告警阈值设置和流程版本对比，因为它对每一次异常都敏感，能快速反映流程稳定性变化。
按受影响任务数统计，关注的是业务对象的覆盖范围。一次中断可能只影响一个任务，也可能因为批量处理、级联触发而影响几十个任务。这个口径适合向业务方说明影响面、评估补数或返工工作量，以及判断某类流程故障是否值得优先修复。
单一口径的误导通常来自两个方向。只看中断次数，会把“高频但每次只影响一个任务”的小故障放大，也可能漏掉“低频但一次波及大量任务”的严重故障。只看受影响任务数，则会把偶发的批量失败稀释在大量正常任务中，掩盖流程本身的脆弱点。因此建议双口径并列报告：日常监控以中断次数率为主指标，影响评估以任务影响率为辅指标，两个数字同时出现在同一张监控报表中，并注明各自的时间窗和范围。
指标与范围：中断的定义、统计对象和时间窗
统计之前必须先写清楚“什么算一次中断”。AI流程的执行结果通常不止成功和失败两种，还包括超时、人工接管、等待外部依赖、部分成功等中间状态。如果这些状态没有事先归类，不同人取数会得到不同结果。
| 执行状态 | 是否计为中断 | 说明 |
|---|---|---|
| 执行失败并终止 | 计入 | 流程未产出预期结果，需人工介入或重新触发 |
| 执行超时 | 计入 | 超过约定时限未完成，按中断处理；时限需在口径中写明 |
| 人工接管 | 计入 | AI未能继续，由人接手完成，属于执行中断 |
| 等待外部依赖后恢复 | 视约定 | 若在时限内自动恢复，可不计；超过时限按超时计入 |
| 部分成功 | 视约定 | 建议按受影响任务拆分计数，并在口径中注明 |
| 主动取消 | 不计入 | 人为终止不属于流程故障 |
| 测试执行、重复触发 | 不计入 | 需通过环境标识或触发来源字段排除 |
统计对象范围要同时界定流程和任务两侧。流程侧明确纳入哪些AI流程，例如只统计生产环境上线的流程，还是包含预发验证流程；任务侧明确哪些业务对象算“被流程处理的任务”，例如工单、需求、代码合并请求或数据批次。范围一旦确定，应在整个统计周期内保持不变，否则趋势对比失去意义。
时间窗按监控节奏选择。日常值班可用按天汇总，管理复盘可用按周汇总，批次型流程可按批次汇总。关键是两个口径使用同一时间窗，且中断发生时间与任务处理时间按同一规则归属到窗口，避免跨窗口的中断被重复计入相邻两天。
数据口径与证据：分子分母从哪里取
两个口径的分子分母来自不同的记录表，取数时要分别锁定字段，不能互相替代。
| 口径 | 分子 | 分母 | 取数来源 |
|---|---|---|---|
| 中断次数率 | 时间窗内判定为中断的执行次数 | 时间窗内执行总次数 | 流程运行记录：执行ID、开始时间、结束时间、执行状态、触发来源、环境标识 |
| 任务影响率 | 时间窗内被中断波及的任务数（去重） | 时间窗内被流程处理的任务总数 | 任务记录与执行关联：任务ID、任务处理时间、关联执行ID、任务状态 |
中断与任务的关联方式是取数的难点。一次中断可能对应一个任务，也可能对应一批任务。建议在运行记录中保留执行ID与任务ID的关联字段，统计任务影响率时以任务ID去重：同一任务在同一时间窗内被多次中断波及，只计一次；同一任务跨窗口被波及，按任务处理时间归属窗口。中断次数口径则按执行ID计数，一次执行中断计一次，不因波及任务多而放大。
数据缺失和重复记录要在取数阶段识别。常见情况包括：执行记录缺少结束时间导致状态无法判定、同一执行因重试产生多条记录、任务被重复触发产生多条处理记录。处理方式是先按执行ID和任务ID去重，再对状态缺失的记录单独列出并注明未纳入统计的数量，避免把缺失当成正常。
计算步骤：两个公式与去重规则
两个公式都乘以100%，以百分比表示，分子分母取自同一时间窗和同一流程范围。
公式一：中断次数率 = 中断次数 ÷ 执行总次数 × 100%。分子为判定为中断的执行次数，分母为同一窗口内全部有效执行次数。该指标衡量流程运行稳定性，适合按天或按周监控。
公式二：任务影响率 = 受影响任务数 ÷ 任务总数 × 100%。分子为被中断波及的任务数并按任务ID去重，分母为同一窗口内被流程处理的任务总数。该指标衡量业务受影响面，适合按周或按批次评估。
去重规则需要写进口径文档：中断次数口径按执行ID计数，重试产生的多次执行分别计数；任务影响口径按任务ID计数，同一任务在一个窗口内只计一次。若一次中断波及多个任务，中断次数仍计一次，受影响任务数按实际波及的任务去重计数。
分母为零时，报告为“不适用”并注明原因，例如该窗口内流程未运行或任务未产生，不写成0%。重试成功是否计入中断，需事先约定：若约定重试成功不计入中断，应在报告中注明重试规则和重试次数，避免读者误以为流程一次通过。
例子：一周运行数据的两口径计算
以下为演示数据，用于说明计算过程，不代表任何真实系统的运行水平。
某AI流程一周内执行总次数为2,000次，其中判定为中断的执行次数为40次；同一周内该流程处理任务总数为5,000个，被中断波及的任务去重后为120个。
中断次数率 = 40 ÷ 2,000 × 100% = 2.0%。任务影响率 = 120 ÷ 5,000 × 100% = 2.4%。
两个结果接近但含义不同：2.0%说明每100次执行中约有2次中断，反映流程运行的稳定性；2.4%说明每100个被处理任务中约有2.4个受到中断影响，反映业务受影响面。本例中任务影响率略高，原因是部分中断发生在批量处理环节，一次中断波及多个任务，抬高了任务侧的比例。若另一周中断次数率仍为2.0%但任务影响率升到5%，则说明中断更集中地发生在批量任务上，修复优先级应转向批量处理环节。
解读与限制：结果怎么用、哪里会失真
中断次数率适合用于值班告警、流程版本对比和稳定性趋势观察；任务影响率适合用于影响面说明、返工量估算和修复优先级排序。两者并列报告时，应同时给出时间窗、流程范围、中断定义和去重规则，否则数字之间不可比。
高频小任务与低频大任务会显著改变两个口径的关系。高频小任务每次中断只影响一个任务，中断次数率与任务影响率接近；低频大任务一次中断波及大量任务，任务影响率会明显高于中断次数率。解读时应结合流程的任务粒度，不能直接横向比较不同流程的中断率。
中断率是过程监控指标，不能单独作为业务损失或质量的结论依据。中断率下降可能来自流程优化，也可能来自统计范围收窄或中断定义放宽。趋势对比前需确认定义、范围、时间窗和去重规则保持一致，并对口径变更单独标注。
在ONES中落地这套统计时，可以把每次AI流程执行记录为可追踪的工作项，将执行状态、关联任务和触发来源作为字段保留，再由ONES Assistant基于项目与工作项上下文汇总分析。ONES Assistant连接ONES Project、ONES Wiki与ONES TestCase，能够理解项目、工作项、迭代和Wiki页面等真实工作上下文，并直接执行后续操作，结果保存为工作项或Wiki页面，便于把中断记录、任务关联和指标口径沉淀在同一处，减少页面切换和重复录入。基于ONES权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合需要定期复核统计口径的监控场景。
常见问题
重试后成功的执行，算不算一次中断？
这取决于口径约定，两种做法都能用，但必须事先写清楚并保持稳定。若约定“重试成功不计入中断”，中断次数只统计最终未恢复的执行，报告里要同时注明重试规则和重试次数，否则读者会误以为流程一次通过。若约定“每次失败执行都计入中断”，中断次数会偏高，但能更敏感地反映流程脆弱点。无论选哪种，同一统计周期内不要中途切换，切换时需单独标注口径变更。
一次中断波及多个任务，任务影响率会不会被重复放大？
按任务ID去重后不会。规则是：中断次数口径按执行ID计数，一次执行中断只计一次；任务影响口径按任务ID计数，同一任务在同一时间窗内被多次中断波及只计一次。这样一次批量失败即使波及几十个任务，中断次数仍是一次，任务影响数按实际波及的任务去重后计入分子。前提是运行记录中保留了执行ID与任务ID的关联字段，否则无法完成去重。
两个口径算出来的数字差很多，应该先看哪个？
先看差异来自哪里，再决定关注重点。若中断次数率低而任务影响率高，通常说明中断集中在批量处理或级联触发环节，一次故障波及多个任务，修复优先级应放在批量环节。若中断次数率高而任务影响率低，说明故障高频但每次只影响少量任务，适合从流程稳定性和告警治理入手。日常值班以中断次数率为主指标，向业务方说明影响面时以任务影响率为主，两个数字放在同一张报表里并注明各自的时间窗和范围。
统计范围中途调整过，历史数据还能直接对比吗？
不能直接对比。中断定义放宽、流程范围收窄或时间窗改变，都会让中断率发生变化，这种变化可能来自口径调整而非流程本身。建议在口径文档中记录每次变更的日期、变更内容和影响范围，趋势图上对变更点单独标注，必要时按新口径回溯重算一段历史数据再比较。若无法回溯，就把变更前后的数据分段呈现，避免把口径变化误读为稳定性改善或恶化。
在ONES里落地这套统计，需要准备哪些记录？
核心是把每次AI流程执行记录为可追踪的工作项，保留执行状态、关联任务和触发来源等字段，让中断判定和任务关联都有据可查。ONES Assistant连接ONES Project、ONES Wiki与ONES TestCase，能够理解项目、工作项、迭代和Wiki页面等真实工作上下文，并直接执行后续操作，结果保存为工作项或Wiki页面，便于把中断记录、任务关联和指标口径沉淀在同一处。基于ONES权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合需要定期复核统计口径的监控场景。
