当前环境离线基线 + 合成数据 Mock 测试，尚未接入生产流量。
业务问题与当前状态
默认显示决策摘要，明细按需展开当前业务判断
在已观测的 treatment 游戏用户中，standard Level 2 是当前优先体验断点。
Agent V1 已完成离线决策、异常兜底和日志回流闭环。下一步通过 Holdout、固定规则与 Agent 三组随机实验，验证 Agent 是否提升 Level 2 通过率并带动游戏完成与后续转化。
问题定位Level 2 体验断点已识别
Agent 闭环决策、工具、兜底和日志已跑通
三组 A/B等待生产流量和成熟队列
业务结论依据 ITT 与显著性判断
Agent 运行指标
判断系统是否可靠运行实验判断指标
判断当前能否作出结论历史诊断用于定位问题，不替代线上随机实验结论
来源：五张原始 CSV关卡用户漏斗
失败与退出不是互斥事件；用户可能失败后再次尝试，故不按简单加总解释。
模式完成率与退出率
范围：已观测的 treatment 游戏用户；不能直接解释 control 与 treatment 的总效果。
Agent 如何干预
从行为信号到可执行动作01 识别读取用户与会话特征
关卡、失败次数、规则状态、设备与历史行为
02 判断识别当前阻断原因
规则未建立、难度受阻、性能风险或交易阻断
03 执行选择个性化干预
教程、Guided Mode、降难度、性能提示或权益提醒
04 回流记录结果并进入实验
动作状态、失败原因、业务结果与评估窗口
| 触发信号 | 业务判断 | Agent 动作 | 失败兜底 | 验证指标 |
|---|
决策树、命中分布和逐用户回放保留在技术工作区。查看决策树与回放审计 →
| 优先级 | 触发信号 | 业务判断 | Agent 动作 | 失败兜底 | 验证指标 |
|---|
数据与技术明细决策树、全量回放、在线测试、Pipeline 和测试报告
Agent 决策与测试明细
来源：8,100 名合成用户的全量五表回放该区域验证 Agent V1 的场景识别、Guardrail、Mock 工具执行与日志闭环。为核验分组字段，三组均运行同一 Agent Mock；不展示或推断真实业务 uplift。
Agent Mock 测试输入
尚未连接
所有动作均为模拟执行，不调用真实淘金币、教程、优惠券或游戏配置接口。
决策结果
连接 Render API 后，选择场景并运行测试。
规则判断轨迹
暂无运行记录。
完整 Mock 响应
{}端到端 Pipeline Mock
验证前端埋点、Backend 监听、实验分桶、特征构建、策略决策、动作执行和数据回流。
尚未运行完整链路。
{}
测试记录与报告
记录保存在当前浏览器，不含真实用户数据；关闭页面后仍可保留，清除浏览器数据或点击清空后删除。
| 测试时间 | 类型 | 场景 / 分组 | 结果 | 请求标识 |
|---|
Agent 决策树
场景与决策状态
| 场景 | 命中用户 | 占全量比例 |
|---|
实验分组覆盖
| 分组 | 评估用户 |
|---|
全量回放分布
| 实验分组 | 最终场景 | 用户数 | 组内占比 |
|---|
回放测试审计
| 校验项 | 结果 |
|---|
全量数据保留于脱敏 CSV；看板仅展示按场景聚合和固定抽样明细。
| 脱敏用户 | 分组 | 最终场景 | 动作计划 | 工具执行 | 五表覆盖 |
|---|
上线后如何判断有效
三组随机实验、成熟队列与运行护栏实验结构
三组随机对照
Holdout固定规则Agent
同时回答“干预是否有效”与“Agent 是否优于固定规则”。
最小样本量
1,898 / 组
三组共 5,694 名完整用户，用于识别 Level 2 通过率至少 +5pp 的效果。
当前决策状态
暂不可下结论
生产入组与成熟样本均为 0。历史基线和 Mock 结果只证明方案可运行，不证明业务增量。
决策规则
主分析采用 ITT，以首次满足 standard + Level 2 + level_fail 的随机入组用户为分母。只有达到最小样本量、观察窗成熟、SRM 与数据质量通过、护栏指标未恶化时，才读取 Agent 相对 Holdout 和固定规则组的效应、置信区间与显著性。
三组实验决策台上线后按小时更新入组与质量，按成熟队列更新业务结果
当前状态：等待生产回流| 指标 / 观察窗 | Holdout | 固定规则 | Agent | Agent vs Holdout | Agent vs 固定规则 | 当前判断 |
|---|
以首次满足 `standard + Level 2 + level_fail` 的入组用户为分母，不以实际接受干预者为分母。未成熟的 24 小时及 7 日队列不得提前作出效果判断。
Agent 运行健康度本地展示浏览器 Mock 测试；上线后切换为 5 分钟实时决策日志
等待测试运行状态
暂无样本
Agent 决策请求 0 次
Agent 崩溃率
—
引擎异常请求 / Agent 决策请求
fallback 率
—
fallback 或客户端超时 / Agent 请求
决策成功率
—
success 或 no_action / Agent 请求
崩溃率低于 0.1% 为正常；0.1%–0.5% 预警；高于 0.5% 暂停扩量；高于 1% 自动降级到固定规则或静态兜底。本地故障注入计入测试值，不代表线上稳定性。
基于历史数据的离线挽回预测来源：`game_behavior_log.csv` + `intervention_test.csv` PSM-DID
仅用于实验规划游戏完成挽回情景
| 策略情景 | 可触达用户 | 效应 | 预计新增完成 |
|---|
5pp MDE 所需样本量
双主比较使用 Bonferroni 校正：双侧 alpha=0.025、power=80%。预测值不可替代新实验结论。
订单与 ROI 基准情景
| 策略 | 订单效应 | 预计增量订单 | 毛贡献 | 变动成本 | 运营 ROI | 一次性成本上限 |
|---|
基准假设：单笔增量订单贡献毛利 ¥8.00，单可触达用户 Agent/工具变动成本 ¥0.50。ROI 不含一次性建设成本；货币参数须在正式立项前由财务与技术团队替换。查看保守/基准/积极三档明细
监控异常排查 Runbook从数据采集到业务工具执行的标准排障顺序
P0 / P1 必须保留 trace_id| 告警 | 优先核验 | 责任团队 | 临时处置 | 恢复标准 |
|---|
排查顺序统一为：前端事件 → Backend → Dify/策略 → 业务工具 → 数据回流。P0/P1 事故必须保留 trace_id、版本号与原始错误码。
离线数据通过 offline_simulation/build_level2_forecast.py 刷新；上线后由事件流、实验宽表和 BI 任务更新生产指标。