企业智能体工程体系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 系统的持续改进框架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 完整闭环【Monitor】观测 └── T-CR-0042 初标「一般咨询」 └── 人工复核后纠正为「额度申请」 └── 记录pred一般咨询, true额度申请, okFalse 【Analyze】分析 └── 近 7 日同类工单误标率 35% └── 归因关键词「额度」「信用」「提额」权重偏低 【Plan】计划 └── 生成提案plan-CR-route-1 └── 新权重{额度: 0.7, 信用: 0.6, 提额: 0.8} └── 状态pending 【Execute】执行P3 门禁 └── 1. Assurance 未通过 → 拒绝执行P3 block └── 2. 完成影子流量验证 → 回归集通过 └── 3. 标记 assuredTrue → 执行发布 └── 4. 权重生效回到 Monitor4.2 关键观测指标指标计算方式阈值误标率错误数 / 总工单数30% 触发飞轮修正延迟从误标到纠正的时间2h 触发告警权重漂移当前权重 vs 基线权重50% 触发评审5. 最小代码MAPE P3 门禁以下为教学级示意代码展示 Flywheel 状态管理、MAPE 闭环流程与 P3 门禁逻辑from__future__importannotationsfromdataclassesimportdataclass,fieldfromstatisticsimportmeanfromtypingimportOptionaldataclassclassRunEvent:单次路由事件记录。case_id:strpred:str# 系统预测的标签true:str# 人工纠正后的真实标签propertydefok(self)-bool:returnself.predself.truedataclassclassPlan:改进提案——进入生产前必须通过 Assurance。plan_id:strnew_weights:dict[str,float]assured:boolFalseshadow_results:Optional[dict]NonedataclassclassFlywheelState:飞轮状态管理——观测、分析、计划、执行。events:list[RunEvent]field(default_factorylist)weights:dict[str,float]field(default_factorylambda:{额度:0.2,信用:0.2,提额:0.2})pending:Plan|NoneNone# Monitor defmonitor(self,event:RunEvent)-None:记录单次路由事件。self.events.append(event)# Analyze defanalyze(self)-dict:分析路由质量返回量化指标。# 只分析「额度申请」类工单creditish[eforeinself.eventsife.true额度申请]ifnotcreditish:return{error_rate:0.0,sample_count:0}error_countsum(0.0ife.okelse1.0foreincreditish)error_rateerror_count/len(creditish)return{error_rate:error_rate,sample_count:len(creditish),error_count:error_count,}# Plan defplan(self,analysis:dict)-Plan|None:基于分析结果生成改进提案。error_rateanalysis.get(error_rate,0.0)# 阈值误标率 30% 触发飞轮iferror_rate0.3:print(f[Plan] 误标率{error_rate:.1%}低于阈值无需改进)returnNone# 生成改进提案self.pendingPlan(plan_idplan-CR-route-1,new_weights{额度:0.7,信用:0.6,提额:0.8},assuredFalse,)print(f[Plan] 生成提案:{self.pending.plan_id})print(f 新权重:{self.pending.new_weights})print(f 触发原因: 误标率{error_rate:.1%} 30%)returnself.pending# Execute含 P3 门禁 defmark_assured(self,plan_id:str,shadow_results:dictNone)-bool:标记提案已通过 Assurance第 8 期展开。ifnotself.pendingorself.pending.plan_id!plan_id:print(f[Assurance] 未找到待验提案:{plan_id})returnFalse# 模拟影子流量验证ifshadow_resultsisNone:shadow_results{passed:True,sample:50,improvement:12%}self.pending.assuredTrueself.pending.shadow_resultsshadow_resultsprint(f[Assurance] ✅{plan_id}已通过验收)print(f 影子验证结果:{shadow_results})returnTruedefexecute(self)-str: P3 门禁未过 Assurance 不得进生产权重。 Returns: 执行结果描述 ifnotself.pending:return⏸️ 无待执行提案ifnotself.pending.assured:returnf P3 block:{self.pending.plan_id}未通过 Assurance不得执行# 执行更新生产权重self.weights.update(self.pending.new_weights)done_idself.pending.plan_id self.pendingNonereturnf✅ 已执行{done_id}生产权重已更新# 模拟运行CASE-CR-0042 完整飞轮 if__name____main__:fwFlywheelState()# ---------- 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,额度申请,额度申请),# 正确]forcase_id,pred,trueinevents:fw.monitor(RunEvent(case_id,pred,true))print(f{case_id}: pred{pred}→ true{true}{✅ifpredtrueelse❌})# ---------- Analyze ----------print(\n*50)print(【Analyze】分析路由质量)print(*50)analysisfw.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)planfw.plan(analysis)# ---------- ExecuteP3 门禁 ----------print(\n*50)print(【Execute】P3 门禁执行)print(*50)# 第一次执行Assurance 未通过 → 被 P3 拦截print(\n 尝试 1: 未通过 Assurance)result1fw.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: 再次执行)result2fw.execute()print(f{result2})# ---------- 最终状态 ----------print(\n*50)print(【最终状态】)print(*50)print(f 当前权重:{fw.weights})print(f 待执行提案:{fw.pending})运行输出 【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 检查点Monitormonitor()记录原始证据Analyzeanalyze()量化归因Planplan()仅当误标率 30% 时触发Executeexecute()P3 门禁assuredFalse时拒绝6. 三个教训基于 CASE-CR-0042 的飞轮设计经验教训含义证据飞轮要有刹车改进提案不能直接生效必须经过 Assurance 第 8 期验收execute()中的 P3 门禁Monitor 必须含失败只采集成功样本会产生“幸存者偏差”看不到真实问题analyze()计算误标率闭环要闭合到生产配置飞轮不能停在“报表好看”必须落到生产配置的变更上新权重最终写入weights7. 思考题以下问题供团队内部讨论帮助将 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 ImprovementarXiv:2510.27051MAPE 飞轮的学术框架本卷第 1 期技能即契约——SkillContract能力边界契约化本卷第 2 期决策四轴——四轴 P1单点决策对齐本卷第 3 期无状态决策记忆——DecisionBoard多环节决策传递本卷第 4 期Agent-First 工具接口——ToolSpec工具调用标准化本卷第 8 期落地验收预告AssuranceReport 完整设计本文是「企业智能体工程卷」十期专栏的第 5 期。数据飞轮——用观察—分析—计划—执行持续改进让 Agent 从“首次即巅峰”进化为“有飞轮、有刹车”的企业公民。欢迎转载请注明出处与原文标题。