企业智能体工程体系v1.1｜企业智能体工程卷 · 第5期· 数据飞轮——用观察—分析—计划—执行持续改进

企业智能体工程体系v1.1｜企业智能体工程卷 · 第5期

数据飞轮------用观察---分析---计划---执行持续改进

作者：技术治理研究组

系列：企业智能体工程卷（发布版 v1.1）

主案例 ：CASE-CR-0042（信用提额申请）

本集对象 ：Flywheel · MAPE 闭环

核心协议 ：P3 飞轮 vs 验收

适合读者：架构师、技术负责人、AI 产品经理、企业级 Agent 开发者

📌 本文档声明

性质：本文为企业智能体工程化设计参考框架的第 5 期，聚焦 Agent 系统的持续改进机制，提供架构思路与教学级示意代码，不构成生产级实现方案或法律合规意见。
证据锚定：文中案例（CASE-CR-0042）为教学示意，不对应任何真实客户系统。
系列定位 ：本篇在第 1 期（技能契约）、第 2 期（决策四轴）、第 3 期（决策记忆）、第 4 期（工具接口）的基础上，引入数据飞轮与 MAPE 闭环，为 Agent 系统建立持续演进的改进纪律。第 8 期将展开 AssuranceReport 的完整设计。

摘要

在前四期中，我们建立了 Agent 的能力边界（SkillContract） 、决策对齐（四轴 + P1） 、多环节记忆（DecisionBoard） 和工具接口（ToolSpec） ------这些是 Agent 的"骨架"和"肌肉"。

但还有一个问题尚未解决：Agent 如何持续成长？

在 CASE-CR-0042 的实际运行中，路由技能常把「额度申请」误标成「一般咨询」：

工单进错池，财务链路迟到；
人抱怨"模型钝了"，却无数据回流；
有工程师在生产环境直接改权重阈值------无证据、无回滚、无法溯源。

静态 Agent：首次即巅峰。公民 Agent：有飞轮，也有刹车。

本期引入 MAPE 飞轮 （Monitor → Analyze → Plan → Execute）作为 Agent 系统的持续改进框架，并通过 P3 协议 明确改进提案与生产变更之间的门禁关系------先举证，后加速。

一句话核心：飞轮要有刹车，闭环要闭合到生产配置，而不是停在报表。

1. 问题：为什么"模型钝了"不能靠"改个阈值"解决

1.1 CASE-CR-0042 的典型漂移场景

在 CASE-CR-0042 所在的路由队列中，一个看似"小"的问题正在持续侵蚀系统质量：

时间点	现象	后果
第 1 周	"额度申请"被误标为"一般咨询"	工单进入错误队列
第 2 周	同类错误率上升至 20%	财务处理链路迟到 4-6 小时
第 3 周	有人直接在控制台调高了"额度"关键词权重	无评审、无回滚、无审计
第 4 周	误标率回落但原因不明	无法判断是权重调整生效还是样本波动

本质问题：

症状	根因
人在抱怨"模型钝了"	缺乏系统化的质量观测
工程师直接改权重	缺乏规范的变更流程
无法判断效果	缺乏闭环验证机制

1.2 "改阈值"的四个陷阱

在生产环境直接修改 Agent 参数，看似"快捷高效"，实则暗藏四个陷阱：

陷阱	说明
无证据	改了什么、为什么改、预期效果是什么------全靠"我觉得"
无回滚	改错了怎么办？没有标准回滚路径
无评审	权重调整影响下游 SLA，但无人知晓
无审计	半年后复盘，说不清这个阈值是谁改的、何时改的

2. MAPE 飞轮：让改进有节奏、有门禁

2.1 什么是 MAPE 飞轮

MAPE 是自动化领域的经典控制回路模型，本系列将其映射为 Agent 系统的持续改进框架：

text 复制代码

Monitor（观测）→ Analyze（分析）→ Plan（计划）→ Execute（执行）→ Monitor

环节	在 CASE-CR-0042 中的动作	产出
Monitor	记录路由标签 vs 人工纠正结果	原始数据
Analyze	计算「额度申请」类工单的误标率	量化报告
Plan	基于分析结果生成改进提案	Plan 对象
Execute	仅当 Assurance 通过后发布新配置	生产变更

核心理念 ：改进是一个闭环，而不是一次性的"调参动作"。闭环的每一环都有证据、有记录、可回溯。

2.2 飞轮 vs 传统"改阈值"

维度	传统"改阈值"	MAPE 飞轮
决策依据	直觉、抱怨、感觉	量化数据分析
变更流程	直接改生产配置	提案 → 验收 → 发布
回滚能力	靠记忆	标准回滚路径
效果验证	凭感觉	影子流量 + 回归集
审计追溯	难以溯源	全链路记录

3. 协议 P3：飞轮 vs 验收------先举证，后加速

P3 协议定义了改进提案进入生产的"门禁规则"：

规则	说明
Plan ≠ 生产变更	任何改进提案先进入待验队列，不直接生效
未过 Assurance 不得 Execute	提案必须通过第 8 期的 AssuranceReport 才能发布到生产
允许影子验证	可在影子流量/历史回放集上预先验证效果
与 P4 的关系	生产阻断走 P4 热修通道，不走"飞轮随便转"
与 P1 的关系	飞轮不得建议关闭约束轴

P3 口诀：先举证，后加速。

3.1 P3 在 CASE-CR-0042 中的应用

步骤	动作	P3 检查点
1. 观测	误标率达 35%	记录证据
2. 分析	确定根因为关键词权重不足	量化归因
3. 计划	生成权重调整提案	进入待验队列
4. 验收	在影子流量上验证新权重	Assurance 门禁
5. 执行	仅当验收通过后发布	P3 放行

3.2 P3 与 P4（热修）的边界

维度	P3（飞轮）	P4（热修）
适用场景	常规改进、优化	生产阻断、紧急修复
时效	按周期迭代	8 小时内
评审要求	完整 Assurance	最小范围 + 双人复核
补证要求	验证通过后才发布	8h 内补证，否则回滚

核心差异：P3 是"计划内的改进"，P4 是"计划外的紧急止血"。

4. CASE-CR-0042 一轮飞轮示意

4.1 完整闭环

text 复制代码

【Monitor】观测
  └── T-CR-0042 初标「一般咨询」
  └── 人工复核后纠正为「额度申请」
  └── 记录：pred="一般咨询", true="额度申请", ok=False

【Analyze】分析
  └── 近 7 日同类工单误标率 = 35%
  └── 归因：关键词「额度」「信用」「提额」权重偏低

【Plan】计划
  └── 生成提案：plan-CR-route-1
  └── 新权重：{"额度": 0.7, "信用": 0.6, "提额": 0.8}
  └── 状态：pending

【Execute】执行（P3 门禁）
  └── 1. Assurance 未通过 → 拒绝执行（P3 block）
  └── 2. 完成影子流量验证 → 回归集通过
  └── 3. 标记 assured=True → 执行发布
  └── 4. 权重生效，回到 Monitor

4.2 关键观测指标

指标	计算方式	阈值
误标率	错误数 / 总工单数	>30% 触发飞轮
修正延迟	从误标到纠正的时间	>2h 触发告警
权重漂移	当前权重 vs 基线权重	>50% 触发评审

5. 最小代码：MAPE + P3 门禁

以下为教学级示意代码，展示 Flywheel 状态管理、MAPE 闭环流程与 P3 门禁逻辑：

python 复制代码

from __future__ import annotations

from dataclasses import dataclass, field
from statistics import mean
from typing import Optional


@dataclass
class RunEvent:
    """单次路由事件记录。"""
    case_id: str
    pred: str          # 系统预测的标签
    true: str          # 人工纠正后的真实标签

    @property
    def ok(self) -> bool:
        return self.pred == self.true


@dataclass
class Plan:
    """改进提案------进入生产前必须通过 Assurance。"""
    plan_id: str
    new_weights: dict[str, float]
    assured: bool = False
    shadow_results: Optional[dict] = None


@dataclass
class FlywheelState:
    """飞轮状态管理------观测、分析、计划、执行。"""
    events: list[RunEvent] = field(default_factory=list)
    weights: dict[str, float] = field(
        default_factory=lambda: {"额度": 0.2, "信用": 0.2, "提额": 0.2}
    )
    pending: Plan | None = None

    # ===== Monitor =====
    def monitor(self, event: RunEvent) -> None:
        """记录单次路由事件。"""
        self.events.append(event)

    # ===== Analyze =====
    def analyze(self) -> dict:
        """分析路由质量，返回量化指标。"""
        # 只分析「额度申请」类工单
        creditish = [e for e in self.events if e.true == "额度申请"]
        if not creditish:
            return {"error_rate": 0.0, "sample_count": 0}

        error_count = sum(0.0 if e.ok else 1.0 for e in creditish)
        error_rate = error_count / len(creditish)

        return {
            "error_rate": error_rate,
            "sample_count": len(creditish),
            "error_count": error_count,
        }

    # ===== Plan =====
    def plan(self, analysis: dict) -> Plan | None:
        """基于分析结果生成改进提案。"""
        error_rate = analysis.get("error_rate", 0.0)

        # 阈值：误标率 > 30% 触发飞轮
        if error_rate < 0.3:
            print(f"[Plan] 误标率 {error_rate:.1%}，低于阈值，无需改进")
            return None

        # 生成改进提案
        self.pending = Plan(
            plan_id="plan-CR-route-1",
            new_weights={"额度": 0.7, "信用": 0.6, "提额": 0.8},
            assured=False,
        )
        print(f"[Plan] 生成提案: {self.pending.plan_id}")
        print(f"       新权重: {self.pending.new_weights}")
        print(f"       触发原因: 误标率 {error_rate:.1%} > 30%")
        return self.pending

    # ===== Execute（含 P3 门禁） =====
    def mark_assured(self, plan_id: str, shadow_results: dict = None) -> bool:
        """标记提案已通过 Assurance（第 8 期展开）。"""
        if not self.pending or self.pending.plan_id != plan_id:
            print(f"[Assurance] 未找到待验提案: {plan_id}")
            return False

        # 模拟影子流量验证
        if shadow_results is None:
            shadow_results = {"passed": True, "sample": 50, "improvement": "+12%"}

        self.pending.assured = True
        self.pending.shadow_results = shadow_results
        print(f"[Assurance] ✅ {plan_id} 已通过验收")
        print(f"           影子验证结果: {shadow_results}")
        return True

    def execute(self) -> str:
        """
        P3 门禁：未过 Assurance 不得进生产权重。

        Returns:
            执行结果描述
        """
        if not self.pending:
            return "⏸️ 无待执行提案"

        if not self.pending.assured:
            return f"🚫 P3 block: {self.pending.plan_id} 未通过 Assurance，不得执行"

        # 执行：更新生产权重
        self.weights.update(self.pending.new_weights)
        done_id = self.pending.plan_id
        self.pending = None

        return f"✅ 已执行 {done_id}，生产权重已更新"


# ===== 模拟运行：CASE-CR-0042 完整飞轮 =====

if __name__ == "__main__":
    fw = FlywheelState()

    # ---------- Monitor ----------
    print("=" * 50)
    print("【Monitor】记录路由事件")
    print("=" * 50)

    # 模拟 10 个工单：6 个误标，4 个正确
    events = [
        ("CASE-CR-0042", "一般咨询", "额度申请"),  # 误标
        ("CASE-CR-0041", "一般咨询", "额度申请"),  # 误标
        ("CASE-CR-0040", "额度申请", "额度申请"),  # 正确
        ("CASE-CR-0039", "一般咨询", "额度申请"),  # 误标
        ("CASE-CR-0038", "一般咨询", "额度申请"),  # 误标
        ("CASE-CR-0037", "额度申请", "额度申请"),  # 正确
        ("CASE-CR-0036", "一般咨询", "额度申请"),  # 误标
        ("CASE-CR-0035", "一般咨询", "额度申请"),  # 误标
        ("CASE-CR-0034", "额度申请", "额度申请"),  # 正确
        ("CASE-CR-0033", "额度申请", "额度申请"),  # 正确
    ]

    for case_id, pred, true in events:
        fw.monitor(RunEvent(case_id, pred, true))
        print(f"  {case_id}: pred={pred} → true={true} {'✅' if pred == true else '❌'}")

    # ---------- Analyze ----------
    print("\n" + "=" * 50)
    print("【Analyze】分析路由质量")
    print("=" * 50)
    analysis = fw.analyze()
    print(f"  • 样本数: {analysis['sample_count']}")
    print(f"  • 错误数: {analysis['error_count']}")
    print(f"  • 误标率: {analysis['error_rate']:.1%}")

    # ---------- Plan ----------
    print("\n" + "=" * 50)
    print("【Plan】生成改进提案")
    print("=" * 50)
    plan = fw.plan(analysis)

    # ---------- Execute（P3 门禁） ----------
    print("\n" + "=" * 50)
    print("【Execute】P3 门禁执行")
    print("=" * 50)

    # 第一次执行：Assurance 未通过 → 被 P3 拦截
    print("\n  尝试 1: 未通过 Assurance")
    result1 = fw.execute()
    print(f"  {result1}")

    # 通过 Assurance（模拟第 8 期验收流程）
    print("\n  尝试 2: 提交 Assurance")
    fw.mark_assured("plan-CR-route-1", {"passed": True, "sample": 50, "improvement": "+12%"})

    # 第二次执行：Assurance 已通过 → 放行
    print("\n  尝试 3: 再次执行")
    result2 = fw.execute()
    print(f"  {result2}")

    # ---------- 最终状态 ----------
    print("\n" + "=" * 50)
    print("【最终状态】")
    print("=" * 50)
    print(f"  当前权重: {fw.weights}")
    print(f"  待执行提案: {fw.pending}")

运行输出：

text 复制代码

==================================================
【Monitor】记录路由事件
==================================================
  CASE-CR-0042: pred=一般咨询 → true=额度申请 ❌
  CASE-CR-0041: pred=一般咨询 → true=额度申请 ❌
  CASE-CR-0040: pred=额度申请 → true=额度申请 ✅
  CASE-CR-0039: pred=一般咨询 → true=额度申请 ❌
  CASE-CR-0038: pred=一般咨询 → true=额度申请 ❌
  CASE-CR-0037: pred=额度申请 → true=额度申请 ✅
  CASE-CR-0036: pred=一般咨询 → true=额度申请 ❌
  CASE-CR-0035: pred=一般咨询 → true=额度申请 ❌
  CASE-CR-0034: pred=额度申请 → true=额度申请 ✅
  CASE-CR-0033: pred=额度申请 → true=额度申请 ✅

==================================================
【Analyze】分析路由质量
==================================================
  • 样本数: 10
  • 错误数: 6
  • 误标率: 60.0%

==================================================
【Plan】生成改进提案
==================================================
[Plan] 生成提案: plan-CR-route-1
       新权重: {'额度': 0.7, '信用': 0.6, '提额': 0.8}
       触发原因: 误标率 60.0% > 30%

==================================================
【Execute】P3 门禁执行
==================================================

  尝试 1: 未通过 Assurance
  🚫 P3 block: plan-CR-route-1 未通过 Assurance，不得执行

  尝试 2: 提交 Assurance
[Assurance] ✅ plan-CR-route-1 已通过验收
           影子验证结果: {'passed': True, 'sample': 50, 'improvement': '+12%'}

  尝试 3: 再次执行
  ✅ 已执行 plan-CR-route-1，生产权重已更新

==================================================
【最终状态】
==================================================
  当前权重: {'额度': 0.7, '信用': 0.6, '提额': 0.8}
  待执行提案: None

代码要点：

环节	代码函数	P3 检查点
Monitor	`monitor()`	记录原始证据
Analyze	`analyze()`	量化归因
Plan	`plan()`	仅当误标率 > 30% 时触发
Execute	`execute()`	P3 门禁：`assured=False` 时拒绝

6. 三个教训

基于 CASE-CR-0042 的飞轮设计经验：

教训	含义	证据
飞轮要有刹车	改进提案不能直接生效，必须经过 Assurance + 第 8 期验收	`execute()` 中的 P3 门禁
Monitor 必须含失败	只采集成功样本会产生"幸存者偏差"，看不到真实问题	`analyze()` 计算误标率
闭环要闭合到生产配置	飞轮不能停在"报表好看"，必须落到生产配置的变更上	新权重最终写入 `weights`

7. 思考题

以下问题供团队内部讨论，帮助将 Flywheel 概念落地到具体场景：

SLA 连锁反应：CASE-CR-0042 的路由错误（额度申请 → 一般咨询），还会连累哪些下游 SLA？例如：财务响应延迟、客户等待时间、SLA 违约成本？
Assurance 授权 ：谁有权 mark_assured？开发自己点通过算不算违反 P3？建议的职责分离方案是什么？
飞轮频率：飞轮应该每日运行还是每周运行？频率过高可能导致"过度优化"，频率过低可能让问题长期得不到解决。你的场景中如何权衡？

8. 下期预告

第 6 期：一次重写（P5）

当路由技能的代码结构已经腐烂到"小修小补修不动"时，走 P5 一次重写。本期将 Flywheel 的 Plan 阶段与 P5 的"重构决策框架"联动。

9. 延伸阅读

资源	说明
Adaptive Data Flywheel: Applying MAPE Control Loops to AI Agent Improvement（arXiv:2510.27051）	MAPE 飞轮的学术框架
本卷第 1 期：技能即契约------SkillContract	能力边界契约化
本卷第 2 期：决策四轴------四轴 + P1	单点决策对齐
本卷第 3 期：无状态决策记忆------DecisionBoard	多环节决策传递
本卷第 4 期：Agent-First 工具接口------ToolSpec	工具调用标准化
本卷第 8 期：落地验收（预告）	AssuranceReport 完整设计

本文是「企业智能体工程卷」十期专栏的第 5 期。数据飞轮------用观察---分析---计划---执行持续改进，让 Agent 从"首次即巅峰"进化为"有飞轮、有刹车"的企业公民。欢迎转载，请注明出处与原文标题。