第二章 Reach维度详解：触达范围量化与统计口径
RICE评分中的Reach（触达范围）衡量的是Agent任务在单位时间内能够影响到的目标实体数量。不同于“曝光量”或“用户数”，Agent任务的触达统计需要根据任务的交互模式、目标对象类型以及数据采集边界来定义。错误的统计口径会导致评分偏差，进而影响任务编排优先级。
2.1 触达范围的量化方法
在Agent编排场景下，Reach的量化遵循“一次交互周期内，被任务状态机明确处理过的独立实体总数”原则。常见量化方法包括：
- 计数法：统计任务运行期间，所有进入处理队列的唯一实体ID数量（如用户ID、订单ID、设备ID）。
- 加权法：对不同类型实体赋予权重（如VIP用户权重=2，普通用户权重=1），计算加权总和。
- 时段截断法：仅统计任务指定观测窗口（如1天、1小时）内的活跃实体数，去除离线或休眠实体。
- 去重法：对于循环触达任务，每个实体只计1次，避免重复统计夸大Reach。
关键原则：Reach统计的时间窗口必须与RICE评估周期一致。如果RICE按周评估，那么Reach应统计该周内任务实际触达的独立实体数量，而非累计历史总量。
2.2 不同Agent任务的触达统计口径
根据Agent任务的交互模式，触达口径分为以下四种典型类型：
| 任务类型 | 统计实体 | 统计口径示例 | 常见误区 |
|---|---|---|---|
| 信息推送型 | 接收推送消息的用户 | 成功推送且被客户端确认收讫的唯一用户数 | 将发送请求数当作触达数（忽略送达失败） |
| 数据采集型 | 被采集数据的源系统/设备 | 采集任务成功拉取并写入数据仓库的源实体数 | 统计了全部源实体，但忽略任务实际只处理了其中一部分 |
| 任务编排型 | 被调度的工作流实例 | 在任务执行期间被Agent主动启动、监控或中断的子流程数 | 将被动等待的流程实例也计入（实际未触达） |
| 交互响应型 | 发起交互请求的终端用户 | Agent完成响应（含超时和失败）的独立用户会话数 | 只统计成功响应，忽略失败尝试的触达影响 |
2.3 触达统计流程拆解
为确保Reach数据可复现、可审计，建议按照以下三步流程建立统计流水线：
- 定义实体标识：明确每个目标实体的唯一键（如userId、deviceId、flowId），并在任务日志中记录该键。
- 设置采集点：在Agent任务处理管道的“开始处理”、“处理完成”、“处理失败”三个节点分别埋点，记录实体键与时间戳。
- 聚合去重：按评估周期，对采集点数据进行合并，仅保留第一次出现的时间戳，计算独立实体数。
实操建议：如果任务由多个Agent链式执行，Reach应以“第一个实际处理该实体的Agent”为准，避免下游Agent重复计数。例如，意图识别Agent触达了用户，下游生成Agent只做增强，不应重复计入Reach。
2.4 案例分析：对比两种统计口径的差异
场景：某电商Agent每天执行一次“促销消息推送”任务，目标用户池100万人。任务规则：若用户上次登录在7天内，则推送短信；否则不推送。任务实际调用短信接口50万次，其中5万次因用户已退订失败，最终成功送达45万人。
采用不同口径后的Reach结果：
- 口径A（按调用数）：Reach = 50万（含失败） → RICE评分虚高。
- 口径B（按成功送达）：Reach = 45万 → 真实触达范围。
- 口径C（按潜在符合用户）：Reach = 100万（未过滤规则） → 严重失真。
避坑提醒：不要将“任务应影响范围”与“实际触达范围”混淆。Reach应始终基于可观测的执行结果，而非预设的理论值。在RICE优先级排序中，低Reach任务可能需要更激进编排或另寻替代方案。
2.5 Reach量化关系图
下图展示了从任务输入到Reach统计的完整数据流向与去重逻辑：
2.6 表格总结：Reach量化要点速查
| 维度 | 正确做法 | 错误做法 |
|---|---|---|
| 实体定义 | 使用业务唯一键（userId, orderId） | 使用消息ID或任务实例ID（不反映真实对象） |
| 时间窗口 | 与RICE评估周期严格对齐 | 使用系统默认时间范围（如无限制累计） |
| 去重策略 | 按实体键去重，保留最早触达时间 | 不合并重复触达，导致Reach虚高 |
| 失败处理 | 计入失败尝试（触达行为已发生） | 仅统计成功实体，忽略失败触达 |
| 链式任务 | 仅统计第一个实际处理实体的Agent | 每个Agent都重复统计实体 |
2.7 实践清单
- ☐ 为每个Agent任务建立唯一的实体ID生成规则，并在日志中强制记录。
- ☐ 在任务编排图中，标注每个处理节点对应的实体类型与统计口径。
- ☐ 设置每日/每周Reach校验任务，与实际业务活跃数据比对，发现偏差及时调整。
- ☐ 对于链式Agent任务，在全局配置中启用“上游处理标识”传递，避免重复计数。
- ☐ 将Reach统计结果作为RICE评估的原始数据字段，固化到评分流水表中。
- ☐ 定期复盘Reach与Impact的比值（Reach/Impact），排查是否存在“触达广但影响浅”的任务。