FDE 交付实战营

Appearance

第八章 建议到执行 ​

8.3 放权路径：只读 → 建议 → 执行 ​

承前：动作安全层建好了，但并不代表第一天就把执行权限全打开。给 Agent 放权像教徒弟开车——先坐副驾看，再摸方向盘你踩刹车，最后才交钥匙。这一节讲放权的三个阶段、放权节奏怎么用数据决定，以及最容易被忽略的一件事：放出去的权，还要能收回来。

8.3.1 为什么要分阶段，而不是一步到位 ​

上一节我们花大力气建了动作安全层，为什么不全量直接上？因为安全层防的是单次动作出错，放权节奏防的是系统性出错。

即使有确认、幂等、白名单，一个刚上线的执行系统仍然有大量未知：模型在什么场景下会提出错误动作？运营对确认界面的疲劳曲线是什么样？拒绝理由里藏着多少条没文档化的规则？这些问题的答案只有运行数据能给。一步到位等于把所有未知同时暴露到生产流量上。

放权三阶段的基本框架：

阶段一：只读期              阶段二：建议期            阶段三：执行期
┌─────────────┐        ┌─────────────┐        ┌─────────────┐
│ Agent 只查  │  采纳率 │ Agent 建议  │  兑现率 │ Agent 执行  │
│ 数据、做分析│ ──────→ │ 人工决定是 │ ──────→ │ 确认后落地  │
│ 不提动作    │  达标   │ 否采纳     │  达标   │ 白名单内   │
└─────────────┘        └─────────────┘        └─────────────┘
   验证：判断是否        验证：判断是否           验证：执行是否
   靠谱（认知）          可信（决策）             安全（落地）

三个阶段验证的是三种不同的可信度：只读期验证 Agent 的认知能力（它对业务事实的理解对不对），建议期验证决策能力（它给出的动作建议该不该被采纳），执行期验证落地能力（确认、幂等、回滚这套机制扛不扛得住）。每一关都有独立的晋级标准，跳级的风险就是——认知都没验证完就给了执行权，等于让一个还没学会看地图的人开车。

8.3.2 采纳率：建议期的核心指标 ​

采纳率（adoption rate）的定义很朴素：Agent 提出的建议中，被人工采纳执行的比例。

但这个指标的口径设计有很多讲究，建议在评估集注册（第 3 章讲过的指标口径方法）时一并固化：

  • 分子分母：分母是"Agent 给出的明确建议数"（不含"信息不足无法建议"的情况）；分子是"人工点击采纳的建议数"。
  • 剔除规则：同一建议人工拖了 7 天没处理，算"过期"不计入分母（否则采纳率会被无限稀释）。
  • 分层看：按场景分（唤回发券 vs 补偿发券）、按门店分、按建议置信度分。一个整体 88% 的采纳率，拆开看可能是"唤回场景 95%、补偿场景 61%"——低的那块才是下一轮迭代的目标。

采纳率多少算"可以进入执行期"？没有万能数字，经验上是连续两周稳定在某个双方认可的水位（例如 85%+），且剩余拒绝里有明确模式可修。更重要的不是绝对值，而是趋势和可解释性：拒绝理由能归类、能对应到改进动作，说明采纳率是"可经营的"；拒绝理由五花八门说不清，说明模型还没理解业务，再高的采纳率也可能是运营无脑点同意刷出来的。

8.3.3 兑现率：执行期的晋级关卡 ​

进入执行期后，核心指标换成了兑现率：Agent 执行的动作中，事后被认定正确且没有被人工撤销的比例。

为什么执行期不看采纳率了？因为在执行模式下，"人点确认"这个动作本身会退化（上一节讲的橡皮图章化）。真正衡量质量的是事后追溯：券发出去之后 7 天内，有没有被作废？有没有触发客诉？会员有没有真实核销、产生复购？这些事后信号才反映动作的真实质量。

兑现率低但采纳率高——典型的橡皮图章信号，要立刻收紧确认流程（增加抽查、强制二级确认）。兑现率高但采纳率低——说明模型判断其实靠谱，是人不信任它，要加强透明度（展示理由、置信度、同类历史案例）而不是改模型。

两个指标的组合读法：

采纳率兑现率诊断动作
高高健康放权可扩大白名单、提高自动化比例
高低橡皮图章化收紧 HITL、引入事后抽查
低高信任缺口加强解释性，展示理由与依据
低低模型能力不足回到评估集修 bad case，暂缓放权

这张表就是"放权节奏由数据决定"的具体化：**每一次扩大权限，都要用采纳率/兑现率的组合做关卡；每一次收回权限，也都有明确的数据触发条件。**放权不是单向门，数据恶化就要收回来——收回本身也要写进放权计划（"若兑现率连续两周 < 80%，自动回退到建议模式"），让客户提前知道规则，回退时就不是"事故"，是"机制在起作用"。

8.3.4 沙盘：青禾的放权十二周 ​

把三阶段放进青禾优选的时间线（接 W7 数字化总监提的验收要求）：

  • 第 1-3 周（只读期）：助手接入会员、订单、券数据，只做分析和归因，"复购率下滑的主要人群画像是什么"。这一阶段同时跑第 4 章的诊断，验证 Agent 对双轨 ID、脏标签的免疫力。
  • 第 4-8 周（建议期）：开发两个 Tool（8.2），但连接器以"草稿模式"运行——建议只生成工单，由运营在原有系统里人工执行。每周统计采纳率、收集拒绝理由。
  • 第 9-12 周（执行期）：采纳率连续两周 ≥ 85%，上线真正的执行通道，白名单先只开放 10 家门店、单券 ≤ 20 元。兑现率每日报送，两周复盘一次，逐步扩门店、提额度。

注意这个节奏里的一个关键设计：建议期用"草稿模式"跑通了完整的工程链路（工具定义、参数校验、工单生成），执行期上线时只是把"生成工单"换成"直接执行"。切换成本低、风险面窄。反过来，如果建议期只做提示词层面的"文字建议"，执行期才第一次碰连接器，风险全部堆在切换日。

8.3.5 To B 常识：项目制、订阅制与 SLA ​

放权路径通常是"项目期"向"订阅期"过渡的窗口，这里补几个 To B 商务常识，纯技术的 FDE 也要懂，因为交付节奏和商务形态是绑定的。

项目制：签 SOW、按里程碑交付验收、结项。适合从 0 到 1 的定制建设——比如你给青禾做的数据诊断、连接器开发就是项目制内容。特点是收入一次性、边界靠 SOW 圈定。

订阅制：按月/年付费持续使用，乙方持续运维升级。Agent 产品天然适合订阅——因为模型在变、规则在变、bad case 永远在出现，"结项"这个概念在 AI 应用里基本不成立。放权路径走得越深（执行期），客户对持续服务的依赖越重，订阅价值越高。

SLA（服务等级协议）：订阅制下的服务质量合同。常见条款包括可用性（如月度 99.9%，注意 99.9% 意味着每月允许约 44 分钟停机）、支持响应分级（P1 级事故 15-60 分钟响应、P4 级请求次个工作日响应）、赔偿条款（未达标按月费比例返服务券，通常上限为当月费用）。FDE 要懂 SLA 的原因很实际：你承诺的技术指标（可用性、响应时间、修复时限）会被商务谈判直接量化进合同，一个"评估准确率"的技术指标一旦写进 SLA，就从工程问题变成了赔付问题。上线前（第 9 章专题）务必和商务同事过一遍：哪些指标能进 SLA、哪些只能进"努力目标"。

8.3.6 收权机制：放出去的权要能收回来 ​

放权讲了很多，收权讲得太少——但实践中收权设计的质量决定放权敢走多远。敢放权不是胆子大，是知道随时能收回。

收权要设计三个层次，从软到硬：

层次触发条件收权动作恢复条件
软收紧（熔断）单日拒绝率突增、客诉 > N 条新动作强制二级确认，存量不动触发原因修复、观察 48h
硬回退兑现率连续两周 < 80%执行模式整体回退到建议模式重新走 G2 门
局部降级某门店/某场景兑现率异常只收回该门店/场景的执行权单独复盘通过后恢复

关键设计原则：回退要自动化、恢复要人工审。 反过来做（回退靠人拍板、恢复自动）是事故放大器——出问题时每分钟都在多发错券，等开会决定回退已经晚了；而恢复没人审，等于回退形同虚设。触发条件写进放权计划并通知客户侧值班人，回退发生时对方收到的是"机制生效通知"，不是"事故通报"。

沙盘里跑一次收权：第 10 周，华东 3 家门店兑现率从 91% 掉到 74%——排查发现是那批门店刚做完会员迁移，双轨 ID 比例突然升高，Agent 把老 ID 上的消费误判为流失信号。系统自动触发局部降级（只收回这 3 家店的执行权），你在周报里写"已回退、原因、预计恢复时间"，数字化总监看到的是一个有免疫系统的产品，而不是一个需要救火的产品。客户对可控性的信任，往往来自看你处理一次小事故的样子，而不是看一切顺利的样子。

8.3.7 要点总结 ​

  • 放权三阶段各有验证目标：只读验证认知、建议验证决策、执行验证落地；跳级等于把未知一次性砸进生产。
  • 采纳率看"人是否买账"（口径要固定：分子分母、剔除、分层），兑现率看"事后是否正确"（防橡皮图章化）。
  • 两指标组合成四象限诊断表，放权和收权都以数据为触发条件；回退规则提前写进放权计划。
  • 建议期用"草稿模式"先跑通工程链路，执行期只做最后一跳切换。
  • 商务形态与交付节奏绑定：项目制建、订阅制养，技术指标一旦进 SLA 就是赔付条款。

参考资料 ​