1. 项目概述当软件工程遇上流程挖掘与AI智能体最近在跟几个技术团队聊自动化提效发现一个挺有意思的痛点很多团队都沉淀了大量的过程数据——Jira上的任务流转、Git仓库的提交记录、CI/CD流水线的构建日志、甚至Slack/Teams里的沟通片段。这些数据就像散落一地的“数字面包屑”记录了软件从需求到上线的完整旅程。但问题来了这些记录往往沉睡在各自的系统里我们很难从中抽取出一个可执行、可优化、甚至能“自主运行”的智能工作流。这正是“Using Process Mining to Generate AI Agents from Software Engineering Process Records”这个命题试图破解的难题。简单说它想做的就是利用流程挖掘技术从我们日常的软件工程事件日志中自动发现、分析并最终生成能模拟甚至增强这些流程的AI智能体AI Agents。这不仅仅是做个报表或者画个流程图那么简单。传统的流程管理要么靠人工梳理耗时且主观要么靠预设模板僵化且不贴合实际。而流程挖掘Process Mining提供了一种数据驱动的、客观的“逆向工程”视角。它把每一次代码提交、每一个工单状态变更、每一轮代码评审都看作一个“事件”通过分析这些事件序列之间的关联、频率和耗时能像法医一样精准还原出团队实际运行的“真实流程模型”而不是“理论上应该有的流程”。而AI智能体的引入则将这个静态模型动态化、智能化。生成的AI Agent可以扮演多种角色比如一个“智能流程助手”能根据当前任务上下文自动推荐下一步最佳操作或负责人一个“合规性检查员”能实时监控流程执行是否偏离安全或质量红线甚至一个“虚拟工程师”能自动执行一些高度模式化的子流程如代码合并后的基础测试触发、依赖库版本检查等。其核心价值在于将过去被动的、事后分析的流程数据转化为主动的、实时的、可交互的智能生产力。这篇文章我将结合自己过去在DevOps和流程自动化领域的实践拆解如何一步步实现这个构想。无论你是负责工程效能的平台工程师、对AI应用感兴趣的开发者还是希望优化团队协作流程的技术负责人相信都能从中找到可直接落地的思路和避坑指南。2. 核心思路与架构设计从事件日志到可执行智能体要实现“流程挖掘生成AI智能体”不能一蹴而就需要一个清晰的、分层递进的架构。整个流程可以看作一个数据转化和价值提升的管道原始事件日志 - 清洗与标准化 - 流程模型挖掘 - 模型分析与增强 - 智能体生成与封装。下面我们来逐一拆解每个环节的设计考量与核心思路。2.1 数据源整合与事件日志标准化万事开头难而数据往往是第一道坎。软件工程过程数据天生就是多源、异构、脏乱的。1. 识别核心数据源通常我们需要从以下几个关键系统抽取事件日志项目管理工具如Jira, Azure DevOps Boards提供需求、任务、缺陷的创建、分配、状态流转如“待办”-“进行中”-“代码审查”-“完成”、评论等活动。这是流程的主干。版本控制系统如Git提供代码提交Commit、分支创建/合并、拉取请求Pull Request的开启、评审、合并等事件。这是开发活动的核心记录。CI/CD平台如Jenkins, GitLab CI, GitHub Actions提供构建、测试、部署任务的触发、开始、成功/失败等事件。这是交付自动化环节的体现。沟通协作工具如Slack, Microsoft Teams可提供代码评审讨论、部署通知、故障告警等事件。这部分数据非结构化程度高但蕴含了重要的决策和协作上下文。2. 定义统一的事件日志模型流程挖掘算法需要一个标准格式的输入通常是遵循“事件日志”Event Log规范如XESeXtensible Event System格式或简化的CSV。每条记录至少应包含Case ID案例ID唯一标识一个完整的流程实例。在软件工程中这通常是一个用户故事ID、缺陷ID或一个特性分支名。它将所有属于同一个工作项的事件串联起来。Activity活动描述发生了什么如“提交代码”、“开启PR”、“构建开始”、“部署至预发环境”。Timestamp时间戳事件发生的精确时间。Resource资源/执行者谁执行了这个活动通常是开发者用户名、系统账号或机器人。注意定义“Case ID”是关键决策点。如果以“缺陷ID”为案例你挖掘的是缺陷修复流程如果以“特性分支名”为案例你挖掘的是特性开发到上线的全流程。目标不同选择也不同。3. 数据抽取与实时流考虑对于探索阶段可以定期如每天从各系统API批量拉取数据进行离线分析。但对于目标生成实时响应的AI Agent则需要建立近实时的事件流管道例如使用Apache Kafka作为事件总线各系统通过webhook或轻量级Agent将事件推送到Kafka再由下游的流程挖掘引擎消费。这为智能体的实时决策提供了数据基础。2.2 流程挖掘算法选型与应用有了干净的事件日志就可以动用流程挖掘的“显微镜”了。流程挖掘主要有三类技术过程发现Process Discovery、一致性检查Conformance Checking、过程增强Process Enhancement。在我们的场景中过程发现是起点也最为关键。1. 过程发现算法选择目标是从事件日志中自动生成一个流程模型通常用BPMN流程图或Petri网表示。常用算法有Alpha Miner经典算法但处理复杂日志并行、循环多时效果有限。Heuristic Miner更实用能通过频率和依赖关系处理噪声和复杂逻辑生成的模型更贴近现实。对于软件工程日志常有不按套路出牌的提交、回滚等Heuristic Miner通常是更好的起点。Inductive Miner能保证生成“声学正确”Sound的模型即不会死锁结果更结构化。实操建议不要迷信单一算法。可以先用Heuristic Miner快速得到一个可理解的模型观察主要路径和瓶颈再用Inditive Miner生成一个更规范、可用于自动化执行的模型。市面上成熟的工具如ProM开源、功能强大但需桌面端、Celonis商业、强大、或开源Python库pm4py都实现了这些算法。2. 挖掘什么—— 软件工程特定视角在通用流程挖掘之上我们需要注入软件工程领域的洞察挖掘“价值流”不仅看活动顺序更要关联活动的“等待时间”和“有效工作时间”。例如从“代码提交”到“代码评审开始”的等待时间可能揭示了评审环节的资源瓶颈。挖掘“质量关口”分析导致构建失败或缺陷重开的常见活动序列。例如挖掘出“在未运行本地测试的情况下直接推送导致CI失败概率增加70%”这样的模式。挖掘协作模式通过“Resource”字段分析不同开发者或团队之间的协作网络和交接模式发现知识孤岛或协作瓶颈。3. 输出可解释的流程模型与指标流程挖掘的结果不应只是一张复杂的流程图。它必须输出关键的性能指标Performance Indicators例如每个活动的平均耗时、等待时间。路径频率哪些开发路径如“特性分支 - 直接合并主干”是最常见的哪些是导致延迟的“迂回路径”合规性有多少比例的案例遵循了预设的“理想流程”如必须经过代码评审这些指标和模型是后续训练和评估AI Agent的“事实基准”和“优化目标”。2.3 AI智能体的生成策略与架构这是从“分析”走向“行动”的关键一跃。生成的AI Agent不是通用大模型而是高度场景化、具备特定目标和行动能力的专用智能体。其生成策略可以分层实现1. 智能体类型定义根据流程模型中的角色和痛点我们可以生成不同类型的Agent导航与推荐型Agent基于当前案例Case的状态和历史路径预测下一步最可能或最优的活动并推荐给开发者。例如“根据类似缺陷的修复历史下一步进行‘单元测试补充’的成功合并率最高。”监控与预警型Agent实时监控事件流检测偏离标准流程、出现性能瓶颈如等待时间超阈值或高风险模式如跳过评审直接合并的案例并即时告警。执行型Agent对于模型中识别出的、高度自动化且规则明确的环节可以生成能直接调用API执行的Agent。例如当流程模型显示“PR合并后95%的案例会触发部署到集成环境”那么就可以生成一个自动执行该部署命令的Agent。2. 技术实现架构一个可生成的AI Agent系统可能包含以下组件知识库存储挖掘出的流程模型、历史路径、最佳实践规则、系统API文档等。推理引擎这是Agent的“大脑”。可以采用基于规则的引擎对于明确逻辑、机器学习模型用于预测和推荐或两者结合。例如用决策树模型预测下一步活动用规则引擎确保合规性检查。行动模块封装了与外部系统Git、Jira、Jenkins交互的能力通过API执行具体操作。上下文感知器持续从事件流中获取当前案例的最新状态作为推理的输入。学习与反馈循环Agent的行动结果成功/失败应作为新的事件日志反馈回系统用于优化流程模型和Agent自身的策略形成闭环。3. “生成”的具体含义这里的“生成”不是无中生有而是基于挖掘结果进行“装配”和“配置”。根据流程模型中一个“评审代码”的节点及其属性执行者角色、平均耗时可以自动生成一个“代码评审提醒Agent”的配置模板包括触发条件PR创建后1小时未分配评审人、行动提醒相关角色、升级策略2小时后未动团队负责人。根据挖掘出的高频成功路径可以生成一个“新手任务引导Agent”为新人开发者提供步骤化的任务清单和上下文帮助。3. 实操构建从零搭建一个原型系统理论说得再多不如动手搭一个。下面我将以一个简化场景为例展示如何构建一个最小可行原型MVP为一个开源项目的GitHub开发流程构建一个“智能PR流程导航Agent”。3.1 环境准备与数据获取我们选择Python生态因为它有丰富的流程挖掘和AI库。1. 核心工具栈流程挖掘pm4py- 主流的Python流程挖掘库。数据处理pandas,numpy。AI/MLscikit-learn用于基础预测模型未来可考虑集成langchain框架来构建更复杂的Agent。数据源GitHub REST API。可视化graphviz用于绘制流程模型matplotlib。2. 获取并预处理GitHub事件日志我们的目标是分析一个仓库的Pull Request流程。Case ID就是PR编号。我们需要获取每个PR的一系列事件活动。import requests import pandas as pd from datetime import datetime # 假设访问的是公开仓库需准备GitHub Token有更高频率限制 GITHUB_TOKEN your_token REPO_OWNER owner REPO_NAME repo headers {Authorization: ftoken {GITHUB_TOKEN}} def fetch_pr_events(pr_number): 获取单个PR的所有事件 url fhttps://api.github.com/repos/{REPO_OWNER}/{REPO_NAME}/issues/{pr_number}/events events [] page 1 while True: response requests.get(url, headersheaders, params{page: page, per_page: 100}) page_events response.json() if not page_events: break for event in page_events: # 提取我们需要的信息 events.append({ case_id: pr_number, activity: event[event], # 如 review_requested, closed, referenced timestamp: event[created_at], resource: event[actor][login] if event[actor] else system, pr_data: event # 保留原始数据以备后用 }) page 1 return events # 获取最近100个PR的列表然后获取每个PR的事件 pr_list_url fhttps://api.github.com/repos/{REPO_OWNER}/{REPO_NAME}/pulls?stateallper_page100 prs requests.get(pr_list_url, headersheaders).json() all_events [] for pr in prs: all_events.extend(fetch_pr_events(pr[number])) # 转换为DataFrame df_log pd.DataFrame(all_events) df_log[timestamp] pd.to_datetime(df_log[timestamp]) df_log df_log.sort_values([case_id, timestamp]).reset_index(dropTrue)关键点GitHub的issues/events端点包含了丰富的状态变更事件如review_requested,reviewed,merged,closed等。我们需要将其映射为流程挖掘中的“活动”。可能需要合并或重命名一些活动使其更具业务意义例如将reviewed且state为approved的映射为活动“代码评审通过”。3.2 使用pm4py进行流程发现与分析现在我们有了一个初步的事件日志DataFrame (df_log)。接下来使用pm4py进行流程挖掘。import pm4py # 1. 创建事件日志对象pm4py期望的格式 from pm4py.objects.log.util import dataframe_utils from pm4py.objects.conversion.log import converter as log_converter # 确保列名符合pm4py要求 df_log df_log.rename(columns{ case_id: case:concept:name, activity: concept:name, timestamp: time:timestamp, resource: org:resource }) # 转换为pm4py事件日志 event_log log_converter.apply(df_log) # 2. 使用启发式挖掘器Heuristic Miner发现流程模型 from pm4py.algo.discovery.heuristics import algorithm as heuristics_miner heu_net heuristics_miner.apply_heu(event_log, parameters{ heuristics_miner.Variants.CLASSIC.value.Parameters.DEPENDENCY_THRESH: 0.5, heuristics_miner.Variants.CLASSIC.value.Parameters.MIN_ACT_COUNT: 2 }) # 3. 将启发式网络转换为Petri网便于可视化和分析 from pm4py.objects.heuristics_net.obj import HeuristicsNet from pm4py.algo.discovery.heuristics import algorithm as heuristics_miner net, im, fm heuristics_miner.apply(event_log, parameters{ heuristics_miner.Variants.CLASSIC.value.Parameters.DEPENDENCY_THRESH: 0.5 }) # 4. 可视化流程模型 from pm4py.visualization.petri_net import visualizer as pn_visualizer gviz pn_visualizer.apply(net, im, fm) pn_visualizer.view(gviz) # 会弹出窗口显示流程图 # 5. 计算性能指标例如每个活动的平均耗时 from pm4py.statistics.traces.generic.log import case_statistics case_durations case_statistics.get_all_case_durations(event_log, parameters{ case_statistics.Parameters.TIMESTAMP_KEY: time:timestamp }) print(f平均PR处理周期{pd.Series(case_durations).mean() / (3600*24):.2f} 天) # 更细粒度的活动级耗时分析 from pm4py.statistics.sojourn_time.log import get as sojourn_time sojourn_dict sojourn_time.apply(event_log, parameters{ sojourn_time.Parameters.TIMESTAMP_KEY: time:timestamp }) for act, stats in sojourn_dict.items(): print(f活动 {act} 平均耗时{stats[mean] if stats[mean] else 0:.2f} 秒)运行这段代码你将得到一张展示该仓库PR实际流转情况的Petri网图。图中会清晰显示主要路径如opened-review_requested-reviewed-merged以及可能存在的“捷径”如直接从opened到merged意味着有未经验审的合并或“循环”如reviewed后状态变回changes_requested意味着需要修改后重新评审。3.3 构建一个简单的导航推荐Agent基于挖掘出的模型和统计数据我们可以构建一个最简单的推荐Agent给定一个处于特定状态的PR推荐下一个最可能发生的活动。1. 特征工程我们将每个PR的当前状态转化为机器学习模型可以理解的特征。# 假设我们只考虑当前最后一个活动作为状态 def extract_features_for_pr(pr_events_df): 从单个PR的事件序列中提取特征 features {} # 1. 当前活动One-Hot编码 current_activity pr_events_df.iloc[-1][concept:name] # 这里简化处理实际需要所有活动类型的列表 all_activities df_log[concept:name].unique() for act in all_activities: features[fact_{act}] 1 if current_activity act else 0 # 2. 当前活动已持续时间 last_time pr_events_df.iloc[-1][time:timestamp] if len(pr_events_df) 1: prev_time pr_events_df.iloc[-2][time:timestamp] features[duration_in_current_state] (last_time - prev_time).total_seconds() else: features[duration_in_current_state] 0 # 3. PR的基本特征可从初始事件或PR元数据获取 # features[pr_has_labels], features[pr_comment_count]等... return features # 为历史数据准备训练集对于每个PR的每个时刻除了最后时刻预测其下一个活动 training_data [] for case_id, group in df_log.groupby(case:concept:name): group group.sort_values(time:timestamp) for i in range(len(group) - 1): current_state group.iloc[:i1] # 到当前时刻为止的历史 next_activity group.iloc[i1][concept:name] # 下一个真实发生的活动 features extract_features_for_pr(current_state) features[next_activity] next_activity training_data.append(features) train_df pd.DataFrame(training_data)2. 训练预测模型我们使用一个简单的多分类模型如随机森林。from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestClassifier from sklearn.preprocessing import LabelEncoder # 准备特征X和标签y X train_df.drop(next_activity, axis1).fillna(0) y train_df[next_activity] # 标签编码 le LabelEncoder() y_encoded le.fit_transform(y) X_train, X_test, y_train, y_test train_test_split(X, y_encoded, test_size0.2, random_state42) clf RandomForestClassifier(n_estimators100, random_state42) clf.fit(X_train, y_train) print(f模型准确率{clf.score(X_test, y_test):.3f})3. 封装成导航Agent服务现在我们可以创建一个简单的函数作为Agent的核心逻辑。class PRNavigationAgent: def __init__(self, model, label_encoder, activity_list): self.model model self.le label_encoder self.activity_list activity_list def recommend_next(self, pr_events_dataframe): 为给定的PR事件序列推荐下一个最可能的活动 # 1. 提取特征 features extract_features_for_pr(pr_events_dataframe) features_vector pd.DataFrame([features], columnsX.columns).fillna(0) # 2. 预测 proba self.model.predict_proba(features_vector)[0] # 获取概率最高的前3个活动 top3_idx proba.argsort()[-3:][::-1] recommendations [] for idx in top3_idx: activity self.le.inverse_transform([idx])[0] confidence proba[idx] recommendations.append((activity, confidence)) # 3. 可选结合流程模型规则进行过滤或排序 # 例如如果当前活动是review_requested但模型推荐了merged # 而流程模型显示这两者很少直接相连则可以降低其置信度或过滤掉。 return recommendations # 初始化Agent agent PRNavigationAgent(clf, le, all_activities) # 模拟使用假设有一个新PR当前状态是刚刚 review_requested simulated_pr_events pd.DataFrame([ {case:concept:name: PR999, concept:name: opened, time:timestamp: pd.Timestamp(2023-10-01 10:00), org:resource: alice}, {case:concept:name: PR999, concept:name: review_requested, time:timestamp: pd.Timestamp(2023-10-01 10:05), org:resource: alice}, ]) recs agent.recommend_next(simulated_pr_events) print(推荐的下一个活动) for act, conf in recs: print(f - {act} (置信度{conf:.2%}))这个简单的Agent已经可以根据历史模式给出下一个可能活动的预测。在实际应用中这个推荐可以集成到GitHub的Slack通知中或者作为一个Chatbot的应答。4. 深入挑战与进阶优化方案构建出原型只是第一步。要将这个想法真正用于生产环境并生成强大可靠的AI Agent我们还需要面对并解决一系列深层次的挑战。4.1 处理软件工程日志的独特复杂性软件工程事件日志比标准的业务流程日志如订单处理要混乱得多。1. 高并发与交叉案例干扰一个开发者可能同时处理多个PRCase事件交错发生。这会导致单个案例的事件流不连续干扰流程发现。解决方案是尽可能精确地定义Case ID并利用“资源”执行者维度进行辅助分析。同时在挖掘时可以采用更注重直接跟随关系Directly-Follows Graph的算法开始而不是急于生成复杂的并行结构模型。2. 大量“噪音”与特例比如一次临时的push、一次错误的commit后又revert或者大量的自动化系统事件如CI的周期性构建。这些事件会污染模型。解决方案包括预处理过滤在事件日志层面过滤掉明显无关或高频低信息量的活动如某些系统心跳事件。使用频率阈值在流程挖掘算法中设置最小出现次数如min_activity_count2过滤掉偶发路径。聚类分析先对案例进行聚类挖掘主流模式再分别分析特例集群。3. 活动粒度的选择“提交代码”是一个活动但“运行单元测试”也是一个活动。粒度太粗模型没价值粒度太细模型复杂到无法理解。实操心得从业务目标倒推。如果你想优化代码评审效率那么“提交代码”、“请求评审”、“评审中”、“评审通过”就是合适的粒度。初期建议从较粗的、有明确业务含义的粒度开始后续再根据需要下钻。4.2 从推荐到执行构建可信的自动化Agent导航推荐Agent相对安全因为它只提供建议。但执行型Agent如自动合并PR、自动触发部署则责任重大需要极高的可信度。1. 安全边界与审批链任何自动化执行都必须有明确的、基于策略的安全边界。例如生成的“自动合并Agent”绝不能应用于主干分支main branch或者必须满足一系列硬性条件至少2个批准Approval、所有CI状态通过、无冲突、且不是由新人贡献者发起。这些策略应作为Agent行动模块的“防护栏”Guardrails以代码或配置的形式明确声明和固化。2. 可解释性与可干预性Agent在决定执行一个动作如合并前必须能清晰解释“为什么”是因为它匹配了流程模型中成功率99%的高频路径还是因为满足了所有预设的质量门禁同时必须提供便捷的人工干预入口例如在自动化操作执行前有一个短暂的“缓冲期”允许人工取消或者提供一个审批覆盖Override机制。3. 渐进式自动化策略不要试图一步到位生成全自动Agent。采用“观察 - 推荐 - 半自动 - 全自动”的渐进路径。阶段一观察Agent只记录和报告展示“如果自动化这里可以执行XX操作”。阶段二推荐Agent在界面提供“一键执行”按钮由人工确认后触发。阶段三半自动对于低风险、高重复性任务如为符合条件的小修改打标签Agent在人工设定的规则下自动执行并发送执行报告。阶段四全自动经过长期验证和团队信任后对高度成熟的子流程实现全自动。4.3 模型持续学习与流程闭环优化流程不是静态的团队的工作方式也在演变。因此基于流程挖掘的AI Agent系统必须是一个活系统。1. 建立反馈循环Agent的每一次行动无论是推荐还是执行及其结果都应该作为新的事件反馈到原始的事件日志库中。例如一个“推荐运行特定测试”的Agent如果用户采纳了该推荐并成功那么这个“采纳推荐”的事件就强化了该路径的权重。如果推荐被忽略或导致问题则成为优化模型的负样本。2. 定期重挖掘与模型迭代不能指望一个初始挖掘的模型用一辈子。需要建立定期如每月重跑流程挖掘作业的机制使用包含最新反馈数据的日志生成更新的流程模型。然后将新模型与旧模型进行对比分析Delta Analysis识别出流程的变化点是出现了新的高效实践还是产生了需要纠正的“流程债务”3. 漂移检测Drift Detection除了定期重跑还可以实施实时或近实时的流程漂移检测。通过统计方法监控关键流程指标如活动间耗时、路径频率的分布变化。当检测到显著漂移时例如“代码评审”平均耗时突然从2天增加到5天系统可以自动告警提示团队负责人关注并触发一次临时的流程分析。这能让Agent系统始终保持对当前实际流程的敏感性。5. 典型应用场景与价值展望这个技术组合的价值在于它能将软件工程中那些模糊的、依赖个人经验的“最佳实践”转化为清晰的、可度量、可优化的数据模型并最终具象化为辅助甚至替代部分重复劳动的智能体。场景一新人入职引导与加速新成员加入团队面对复杂的开发流程常常不知所措。一个基于历史成功案例挖掘的“新手导航Agent”可以像一个贴身的导师根据新人当前的任务如“修复一个简单的UI Bug”动态生成一个个性化的任务清单“第1步从Jira领取任务ABC-123第2步基于main创建特性分支命名建议为fix/ABC-123-ui-bug第3步修改文件X和Y历史上类似修改常伴随单元测试Z的更新...”。这不仅能大幅缩短新人的上手时间也能保证流程的规范性。场景二质量门禁与风险预警通过挖掘历史中导致线上故障、回滚或重大缺陷的流程模式可以训练一个“风险预测Agent”。例如Agent发现当前某个即将上线的特性其流程路径与历史上70%的线上事故案例高度相似如跳过了一个关键的集成测试环境、主要修改者近期提交的代码故障率较高它可以自动标记高风险并阻止自动部署要求人工介入审查。这是一种数据驱动的、前瞻性的质量保障。场景三团队效能瓶颈诊断与优化流程挖掘最直接的价值就是可视化瓶颈。生成的“效能看板Agent”可以持续监控流程并主动报告“过去两周‘等待测试环境就绪’这个活动的平均等待时间增加了50%是导致本次迭代延迟的主要因素”或者“团队A向团队B的代码库提交PR时评审周期平均比团队内PR长3天建议审视跨团队协作协议”。这为工程效能团队提供了精准的优化靶点。场景四自动化流水线的智能编排现有的CI/CD流水线大多是静态配置的。通过分析历史构建和部署记录可以挖掘出在不同上下文如代码变更类型、涉及模块、提交者习惯下最可靠、最快速的流水线组合。进而生成一个“智能流水线编排Agent”。当新的代码提交时Agent能动态推荐或直接选择一组最适合的测试套件和部署策略在保证质量的前提下最大化交付速度。从我个人的实践来看将流程挖掘与AI智能体结合其最大的魅力在于它提供了一种从数据中来到业务中去的闭环能力。我们不再仅仅是在“监控”或“报告”流程而是在“理解”和“塑造”流程。这个过程本身就是推动软件开发从一门手艺Craft向一门可度量、可优化的工程学科Engineering迈进的有力一步。当然这条路充满挑战尤其是数据质量、模型可信度和组织文化接受度方面。但正如我们搭建这个原型所展示的起点可以很低价值却可以随着数据和经验的积累而不断放大。 流程挖掘与AI智能体：从软件工程日志生成自动化工作流
1. 项目概述当软件工程遇上流程挖掘与AI智能体最近在跟几个技术团队聊自动化提效发现一个挺有意思的痛点很多团队都沉淀了大量的过程数据——Jira上的任务流转、Git仓库的提交记录、CI/CD流水线的构建日志、甚至Slack/Teams里的沟通片段。这些数据就像散落一地的“数字面包屑”记录了软件从需求到上线的完整旅程。但问题来了这些记录往往沉睡在各自的系统里我们很难从中抽取出一个可执行、可优化、甚至能“自主运行”的智能工作流。这正是“Using Process Mining to Generate AI Agents from Software Engineering Process Records”这个命题试图破解的难题。简单说它想做的就是利用流程挖掘技术从我们日常的软件工程事件日志中自动发现、分析并最终生成能模拟甚至增强这些流程的AI智能体AI Agents。这不仅仅是做个报表或者画个流程图那么简单。传统的流程管理要么靠人工梳理耗时且主观要么靠预设模板僵化且不贴合实际。而流程挖掘Process Mining提供了一种数据驱动的、客观的“逆向工程”视角。它把每一次代码提交、每一个工单状态变更、每一轮代码评审都看作一个“事件”通过分析这些事件序列之间的关联、频率和耗时能像法医一样精准还原出团队实际运行的“真实流程模型”而不是“理论上应该有的流程”。而AI智能体的引入则将这个静态模型动态化、智能化。生成的AI Agent可以扮演多种角色比如一个“智能流程助手”能根据当前任务上下文自动推荐下一步最佳操作或负责人一个“合规性检查员”能实时监控流程执行是否偏离安全或质量红线甚至一个“虚拟工程师”能自动执行一些高度模式化的子流程如代码合并后的基础测试触发、依赖库版本检查等。其核心价值在于将过去被动的、事后分析的流程数据转化为主动的、实时的、可交互的智能生产力。这篇文章我将结合自己过去在DevOps和流程自动化领域的实践拆解如何一步步实现这个构想。无论你是负责工程效能的平台工程师、对AI应用感兴趣的开发者还是希望优化团队协作流程的技术负责人相信都能从中找到可直接落地的思路和避坑指南。2. 核心思路与架构设计从事件日志到可执行智能体要实现“流程挖掘生成AI智能体”不能一蹴而就需要一个清晰的、分层递进的架构。整个流程可以看作一个数据转化和价值提升的管道原始事件日志 - 清洗与标准化 - 流程模型挖掘 - 模型分析与增强 - 智能体生成与封装。下面我们来逐一拆解每个环节的设计考量与核心思路。2.1 数据源整合与事件日志标准化万事开头难而数据往往是第一道坎。软件工程过程数据天生就是多源、异构、脏乱的。1. 识别核心数据源通常我们需要从以下几个关键系统抽取事件日志项目管理工具如Jira, Azure DevOps Boards提供需求、任务、缺陷的创建、分配、状态流转如“待办”-“进行中”-“代码审查”-“完成”、评论等活动。这是流程的主干。版本控制系统如Git提供代码提交Commit、分支创建/合并、拉取请求Pull Request的开启、评审、合并等事件。这是开发活动的核心记录。CI/CD平台如Jenkins, GitLab CI, GitHub Actions提供构建、测试、部署任务的触发、开始、成功/失败等事件。这是交付自动化环节的体现。沟通协作工具如Slack, Microsoft Teams可提供代码评审讨论、部署通知、故障告警等事件。这部分数据非结构化程度高但蕴含了重要的决策和协作上下文。2. 定义统一的事件日志模型流程挖掘算法需要一个标准格式的输入通常是遵循“事件日志”Event Log规范如XESeXtensible Event System格式或简化的CSV。每条记录至少应包含Case ID案例ID唯一标识一个完整的流程实例。在软件工程中这通常是一个用户故事ID、缺陷ID或一个特性分支名。它将所有属于同一个工作项的事件串联起来。Activity活动描述发生了什么如“提交代码”、“开启PR”、“构建开始”、“部署至预发环境”。Timestamp时间戳事件发生的精确时间。Resource资源/执行者谁执行了这个活动通常是开发者用户名、系统账号或机器人。注意定义“Case ID”是关键决策点。如果以“缺陷ID”为案例你挖掘的是缺陷修复流程如果以“特性分支名”为案例你挖掘的是特性开发到上线的全流程。目标不同选择也不同。3. 数据抽取与实时流考虑对于探索阶段可以定期如每天从各系统API批量拉取数据进行离线分析。但对于目标生成实时响应的AI Agent则需要建立近实时的事件流管道例如使用Apache Kafka作为事件总线各系统通过webhook或轻量级Agent将事件推送到Kafka再由下游的流程挖掘引擎消费。这为智能体的实时决策提供了数据基础。2.2 流程挖掘算法选型与应用有了干净的事件日志就可以动用流程挖掘的“显微镜”了。流程挖掘主要有三类技术过程发现Process Discovery、一致性检查Conformance Checking、过程增强Process Enhancement。在我们的场景中过程发现是起点也最为关键。1. 过程发现算法选择目标是从事件日志中自动生成一个流程模型通常用BPMN流程图或Petri网表示。常用算法有Alpha Miner经典算法但处理复杂日志并行、循环多时效果有限。Heuristic Miner更实用能通过频率和依赖关系处理噪声和复杂逻辑生成的模型更贴近现实。对于软件工程日志常有不按套路出牌的提交、回滚等Heuristic Miner通常是更好的起点。Inductive Miner能保证生成“声学正确”Sound的模型即不会死锁结果更结构化。实操建议不要迷信单一算法。可以先用Heuristic Miner快速得到一个可理解的模型观察主要路径和瓶颈再用Inditive Miner生成一个更规范、可用于自动化执行的模型。市面上成熟的工具如ProM开源、功能强大但需桌面端、Celonis商业、强大、或开源Python库pm4py都实现了这些算法。2. 挖掘什么—— 软件工程特定视角在通用流程挖掘之上我们需要注入软件工程领域的洞察挖掘“价值流”不仅看活动顺序更要关联活动的“等待时间”和“有效工作时间”。例如从“代码提交”到“代码评审开始”的等待时间可能揭示了评审环节的资源瓶颈。挖掘“质量关口”分析导致构建失败或缺陷重开的常见活动序列。例如挖掘出“在未运行本地测试的情况下直接推送导致CI失败概率增加70%”这样的模式。挖掘协作模式通过“Resource”字段分析不同开发者或团队之间的协作网络和交接模式发现知识孤岛或协作瓶颈。3. 输出可解释的流程模型与指标流程挖掘的结果不应只是一张复杂的流程图。它必须输出关键的性能指标Performance Indicators例如每个活动的平均耗时、等待时间。路径频率哪些开发路径如“特性分支 - 直接合并主干”是最常见的哪些是导致延迟的“迂回路径”合规性有多少比例的案例遵循了预设的“理想流程”如必须经过代码评审这些指标和模型是后续训练和评估AI Agent的“事实基准”和“优化目标”。2.3 AI智能体的生成策略与架构这是从“分析”走向“行动”的关键一跃。生成的AI Agent不是通用大模型而是高度场景化、具备特定目标和行动能力的专用智能体。其生成策略可以分层实现1. 智能体类型定义根据流程模型中的角色和痛点我们可以生成不同类型的Agent导航与推荐型Agent基于当前案例Case的状态和历史路径预测下一步最可能或最优的活动并推荐给开发者。例如“根据类似缺陷的修复历史下一步进行‘单元测试补充’的成功合并率最高。”监控与预警型Agent实时监控事件流检测偏离标准流程、出现性能瓶颈如等待时间超阈值或高风险模式如跳过评审直接合并的案例并即时告警。执行型Agent对于模型中识别出的、高度自动化且规则明确的环节可以生成能直接调用API执行的Agent。例如当流程模型显示“PR合并后95%的案例会触发部署到集成环境”那么就可以生成一个自动执行该部署命令的Agent。2. 技术实现架构一个可生成的AI Agent系统可能包含以下组件知识库存储挖掘出的流程模型、历史路径、最佳实践规则、系统API文档等。推理引擎这是Agent的“大脑”。可以采用基于规则的引擎对于明确逻辑、机器学习模型用于预测和推荐或两者结合。例如用决策树模型预测下一步活动用规则引擎确保合规性检查。行动模块封装了与外部系统Git、Jira、Jenkins交互的能力通过API执行具体操作。上下文感知器持续从事件流中获取当前案例的最新状态作为推理的输入。学习与反馈循环Agent的行动结果成功/失败应作为新的事件日志反馈回系统用于优化流程模型和Agent自身的策略形成闭环。3. “生成”的具体含义这里的“生成”不是无中生有而是基于挖掘结果进行“装配”和“配置”。根据流程模型中一个“评审代码”的节点及其属性执行者角色、平均耗时可以自动生成一个“代码评审提醒Agent”的配置模板包括触发条件PR创建后1小时未分配评审人、行动提醒相关角色、升级策略2小时后未动团队负责人。根据挖掘出的高频成功路径可以生成一个“新手任务引导Agent”为新人开发者提供步骤化的任务清单和上下文帮助。3. 实操构建从零搭建一个原型系统理论说得再多不如动手搭一个。下面我将以一个简化场景为例展示如何构建一个最小可行原型MVP为一个开源项目的GitHub开发流程构建一个“智能PR流程导航Agent”。3.1 环境准备与数据获取我们选择Python生态因为它有丰富的流程挖掘和AI库。1. 核心工具栈流程挖掘pm4py- 主流的Python流程挖掘库。数据处理pandas,numpy。AI/MLscikit-learn用于基础预测模型未来可考虑集成langchain框架来构建更复杂的Agent。数据源GitHub REST API。可视化graphviz用于绘制流程模型matplotlib。2. 获取并预处理GitHub事件日志我们的目标是分析一个仓库的Pull Request流程。Case ID就是PR编号。我们需要获取每个PR的一系列事件活动。import requests import pandas as pd from datetime import datetime # 假设访问的是公开仓库需准备GitHub Token有更高频率限制 GITHUB_TOKEN your_token REPO_OWNER owner REPO_NAME repo headers {Authorization: ftoken {GITHUB_TOKEN}} def fetch_pr_events(pr_number): 获取单个PR的所有事件 url fhttps://api.github.com/repos/{REPO_OWNER}/{REPO_NAME}/issues/{pr_number}/events events [] page 1 while True: response requests.get(url, headersheaders, params{page: page, per_page: 100}) page_events response.json() if not page_events: break for event in page_events: # 提取我们需要的信息 events.append({ case_id: pr_number, activity: event[event], # 如 review_requested, closed, referenced timestamp: event[created_at], resource: event[actor][login] if event[actor] else system, pr_data: event # 保留原始数据以备后用 }) page 1 return events # 获取最近100个PR的列表然后获取每个PR的事件 pr_list_url fhttps://api.github.com/repos/{REPO_OWNER}/{REPO_NAME}/pulls?stateallper_page100 prs requests.get(pr_list_url, headersheaders).json() all_events [] for pr in prs: all_events.extend(fetch_pr_events(pr[number])) # 转换为DataFrame df_log pd.DataFrame(all_events) df_log[timestamp] pd.to_datetime(df_log[timestamp]) df_log df_log.sort_values([case_id, timestamp]).reset_index(dropTrue)关键点GitHub的issues/events端点包含了丰富的状态变更事件如review_requested,reviewed,merged,closed等。我们需要将其映射为流程挖掘中的“活动”。可能需要合并或重命名一些活动使其更具业务意义例如将reviewed且state为approved的映射为活动“代码评审通过”。3.2 使用pm4py进行流程发现与分析现在我们有了一个初步的事件日志DataFrame (df_log)。接下来使用pm4py进行流程挖掘。import pm4py # 1. 创建事件日志对象pm4py期望的格式 from pm4py.objects.log.util import dataframe_utils from pm4py.objects.conversion.log import converter as log_converter # 确保列名符合pm4py要求 df_log df_log.rename(columns{ case_id: case:concept:name, activity: concept:name, timestamp: time:timestamp, resource: org:resource }) # 转换为pm4py事件日志 event_log log_converter.apply(df_log) # 2. 使用启发式挖掘器Heuristic Miner发现流程模型 from pm4py.algo.discovery.heuristics import algorithm as heuristics_miner heu_net heuristics_miner.apply_heu(event_log, parameters{ heuristics_miner.Variants.CLASSIC.value.Parameters.DEPENDENCY_THRESH: 0.5, heuristics_miner.Variants.CLASSIC.value.Parameters.MIN_ACT_COUNT: 2 }) # 3. 将启发式网络转换为Petri网便于可视化和分析 from pm4py.objects.heuristics_net.obj import HeuristicsNet from pm4py.algo.discovery.heuristics import algorithm as heuristics_miner net, im, fm heuristics_miner.apply(event_log, parameters{ heuristics_miner.Variants.CLASSIC.value.Parameters.DEPENDENCY_THRESH: 0.5 }) # 4. 可视化流程模型 from pm4py.visualization.petri_net import visualizer as pn_visualizer gviz pn_visualizer.apply(net, im, fm) pn_visualizer.view(gviz) # 会弹出窗口显示流程图 # 5. 计算性能指标例如每个活动的平均耗时 from pm4py.statistics.traces.generic.log import case_statistics case_durations case_statistics.get_all_case_durations(event_log, parameters{ case_statistics.Parameters.TIMESTAMP_KEY: time:timestamp }) print(f平均PR处理周期{pd.Series(case_durations).mean() / (3600*24):.2f} 天) # 更细粒度的活动级耗时分析 from pm4py.statistics.sojourn_time.log import get as sojourn_time sojourn_dict sojourn_time.apply(event_log, parameters{ sojourn_time.Parameters.TIMESTAMP_KEY: time:timestamp }) for act, stats in sojourn_dict.items(): print(f活动 {act} 平均耗时{stats[mean] if stats[mean] else 0:.2f} 秒)运行这段代码你将得到一张展示该仓库PR实际流转情况的Petri网图。图中会清晰显示主要路径如opened-review_requested-reviewed-merged以及可能存在的“捷径”如直接从opened到merged意味着有未经验审的合并或“循环”如reviewed后状态变回changes_requested意味着需要修改后重新评审。3.3 构建一个简单的导航推荐Agent基于挖掘出的模型和统计数据我们可以构建一个最简单的推荐Agent给定一个处于特定状态的PR推荐下一个最可能发生的活动。1. 特征工程我们将每个PR的当前状态转化为机器学习模型可以理解的特征。# 假设我们只考虑当前最后一个活动作为状态 def extract_features_for_pr(pr_events_df): 从单个PR的事件序列中提取特征 features {} # 1. 当前活动One-Hot编码 current_activity pr_events_df.iloc[-1][concept:name] # 这里简化处理实际需要所有活动类型的列表 all_activities df_log[concept:name].unique() for act in all_activities: features[fact_{act}] 1 if current_activity act else 0 # 2. 当前活动已持续时间 last_time pr_events_df.iloc[-1][time:timestamp] if len(pr_events_df) 1: prev_time pr_events_df.iloc[-2][time:timestamp] features[duration_in_current_state] (last_time - prev_time).total_seconds() else: features[duration_in_current_state] 0 # 3. PR的基本特征可从初始事件或PR元数据获取 # features[pr_has_labels], features[pr_comment_count]等... return features # 为历史数据准备训练集对于每个PR的每个时刻除了最后时刻预测其下一个活动 training_data [] for case_id, group in df_log.groupby(case:concept:name): group group.sort_values(time:timestamp) for i in range(len(group) - 1): current_state group.iloc[:i1] # 到当前时刻为止的历史 next_activity group.iloc[i1][concept:name] # 下一个真实发生的活动 features extract_features_for_pr(current_state) features[next_activity] next_activity training_data.append(features) train_df pd.DataFrame(training_data)2. 训练预测模型我们使用一个简单的多分类模型如随机森林。from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestClassifier from sklearn.preprocessing import LabelEncoder # 准备特征X和标签y X train_df.drop(next_activity, axis1).fillna(0) y train_df[next_activity] # 标签编码 le LabelEncoder() y_encoded le.fit_transform(y) X_train, X_test, y_train, y_test train_test_split(X, y_encoded, test_size0.2, random_state42) clf RandomForestClassifier(n_estimators100, random_state42) clf.fit(X_train, y_train) print(f模型准确率{clf.score(X_test, y_test):.3f})3. 封装成导航Agent服务现在我们可以创建一个简单的函数作为Agent的核心逻辑。class PRNavigationAgent: def __init__(self, model, label_encoder, activity_list): self.model model self.le label_encoder self.activity_list activity_list def recommend_next(self, pr_events_dataframe): 为给定的PR事件序列推荐下一个最可能的活动 # 1. 提取特征 features extract_features_for_pr(pr_events_dataframe) features_vector pd.DataFrame([features], columnsX.columns).fillna(0) # 2. 预测 proba self.model.predict_proba(features_vector)[0] # 获取概率最高的前3个活动 top3_idx proba.argsort()[-3:][::-1] recommendations [] for idx in top3_idx: activity self.le.inverse_transform([idx])[0] confidence proba[idx] recommendations.append((activity, confidence)) # 3. 可选结合流程模型规则进行过滤或排序 # 例如如果当前活动是review_requested但模型推荐了merged # 而流程模型显示这两者很少直接相连则可以降低其置信度或过滤掉。 return recommendations # 初始化Agent agent PRNavigationAgent(clf, le, all_activities) # 模拟使用假设有一个新PR当前状态是刚刚 review_requested simulated_pr_events pd.DataFrame([ {case:concept:name: PR999, concept:name: opened, time:timestamp: pd.Timestamp(2023-10-01 10:00), org:resource: alice}, {case:concept:name: PR999, concept:name: review_requested, time:timestamp: pd.Timestamp(2023-10-01 10:05), org:resource: alice}, ]) recs agent.recommend_next(simulated_pr_events) print(推荐的下一个活动) for act, conf in recs: print(f - {act} (置信度{conf:.2%}))这个简单的Agent已经可以根据历史模式给出下一个可能活动的预测。在实际应用中这个推荐可以集成到GitHub的Slack通知中或者作为一个Chatbot的应答。4. 深入挑战与进阶优化方案构建出原型只是第一步。要将这个想法真正用于生产环境并生成强大可靠的AI Agent我们还需要面对并解决一系列深层次的挑战。4.1 处理软件工程日志的独特复杂性软件工程事件日志比标准的业务流程日志如订单处理要混乱得多。1. 高并发与交叉案例干扰一个开发者可能同时处理多个PRCase事件交错发生。这会导致单个案例的事件流不连续干扰流程发现。解决方案是尽可能精确地定义Case ID并利用“资源”执行者维度进行辅助分析。同时在挖掘时可以采用更注重直接跟随关系Directly-Follows Graph的算法开始而不是急于生成复杂的并行结构模型。2. 大量“噪音”与特例比如一次临时的push、一次错误的commit后又revert或者大量的自动化系统事件如CI的周期性构建。这些事件会污染模型。解决方案包括预处理过滤在事件日志层面过滤掉明显无关或高频低信息量的活动如某些系统心跳事件。使用频率阈值在流程挖掘算法中设置最小出现次数如min_activity_count2过滤掉偶发路径。聚类分析先对案例进行聚类挖掘主流模式再分别分析特例集群。3. 活动粒度的选择“提交代码”是一个活动但“运行单元测试”也是一个活动。粒度太粗模型没价值粒度太细模型复杂到无法理解。实操心得从业务目标倒推。如果你想优化代码评审效率那么“提交代码”、“请求评审”、“评审中”、“评审通过”就是合适的粒度。初期建议从较粗的、有明确业务含义的粒度开始后续再根据需要下钻。4.2 从推荐到执行构建可信的自动化Agent导航推荐Agent相对安全因为它只提供建议。但执行型Agent如自动合并PR、自动触发部署则责任重大需要极高的可信度。1. 安全边界与审批链任何自动化执行都必须有明确的、基于策略的安全边界。例如生成的“自动合并Agent”绝不能应用于主干分支main branch或者必须满足一系列硬性条件至少2个批准Approval、所有CI状态通过、无冲突、且不是由新人贡献者发起。这些策略应作为Agent行动模块的“防护栏”Guardrails以代码或配置的形式明确声明和固化。2. 可解释性与可干预性Agent在决定执行一个动作如合并前必须能清晰解释“为什么”是因为它匹配了流程模型中成功率99%的高频路径还是因为满足了所有预设的质量门禁同时必须提供便捷的人工干预入口例如在自动化操作执行前有一个短暂的“缓冲期”允许人工取消或者提供一个审批覆盖Override机制。3. 渐进式自动化策略不要试图一步到位生成全自动Agent。采用“观察 - 推荐 - 半自动 - 全自动”的渐进路径。阶段一观察Agent只记录和报告展示“如果自动化这里可以执行XX操作”。阶段二推荐Agent在界面提供“一键执行”按钮由人工确认后触发。阶段三半自动对于低风险、高重复性任务如为符合条件的小修改打标签Agent在人工设定的规则下自动执行并发送执行报告。阶段四全自动经过长期验证和团队信任后对高度成熟的子流程实现全自动。4.3 模型持续学习与流程闭环优化流程不是静态的团队的工作方式也在演变。因此基于流程挖掘的AI Agent系统必须是一个活系统。1. 建立反馈循环Agent的每一次行动无论是推荐还是执行及其结果都应该作为新的事件反馈到原始的事件日志库中。例如一个“推荐运行特定测试”的Agent如果用户采纳了该推荐并成功那么这个“采纳推荐”的事件就强化了该路径的权重。如果推荐被忽略或导致问题则成为优化模型的负样本。2. 定期重挖掘与模型迭代不能指望一个初始挖掘的模型用一辈子。需要建立定期如每月重跑流程挖掘作业的机制使用包含最新反馈数据的日志生成更新的流程模型。然后将新模型与旧模型进行对比分析Delta Analysis识别出流程的变化点是出现了新的高效实践还是产生了需要纠正的“流程债务”3. 漂移检测Drift Detection除了定期重跑还可以实施实时或近实时的流程漂移检测。通过统计方法监控关键流程指标如活动间耗时、路径频率的分布变化。当检测到显著漂移时例如“代码评审”平均耗时突然从2天增加到5天系统可以自动告警提示团队负责人关注并触发一次临时的流程分析。这能让Agent系统始终保持对当前实际流程的敏感性。5. 典型应用场景与价值展望这个技术组合的价值在于它能将软件工程中那些模糊的、依赖个人经验的“最佳实践”转化为清晰的、可度量、可优化的数据模型并最终具象化为辅助甚至替代部分重复劳动的智能体。场景一新人入职引导与加速新成员加入团队面对复杂的开发流程常常不知所措。一个基于历史成功案例挖掘的“新手导航Agent”可以像一个贴身的导师根据新人当前的任务如“修复一个简单的UI Bug”动态生成一个个性化的任务清单“第1步从Jira领取任务ABC-123第2步基于main创建特性分支命名建议为fix/ABC-123-ui-bug第3步修改文件X和Y历史上类似修改常伴随单元测试Z的更新...”。这不仅能大幅缩短新人的上手时间也能保证流程的规范性。场景二质量门禁与风险预警通过挖掘历史中导致线上故障、回滚或重大缺陷的流程模式可以训练一个“风险预测Agent”。例如Agent发现当前某个即将上线的特性其流程路径与历史上70%的线上事故案例高度相似如跳过了一个关键的集成测试环境、主要修改者近期提交的代码故障率较高它可以自动标记高风险并阻止自动部署要求人工介入审查。这是一种数据驱动的、前瞻性的质量保障。场景三团队效能瓶颈诊断与优化流程挖掘最直接的价值就是可视化瓶颈。生成的“效能看板Agent”可以持续监控流程并主动报告“过去两周‘等待测试环境就绪’这个活动的平均等待时间增加了50%是导致本次迭代延迟的主要因素”或者“团队A向团队B的代码库提交PR时评审周期平均比团队内PR长3天建议审视跨团队协作协议”。这为工程效能团队提供了精准的优化靶点。场景四自动化流水线的智能编排现有的CI/CD流水线大多是静态配置的。通过分析历史构建和部署记录可以挖掘出在不同上下文如代码变更类型、涉及模块、提交者习惯下最可靠、最快速的流水线组合。进而生成一个“智能流水线编排Agent”。当新的代码提交时Agent能动态推荐或直接选择一组最适合的测试套件和部署策略在保证质量的前提下最大化交付速度。从我个人的实践来看将流程挖掘与AI智能体结合其最大的魅力在于它提供了一种从数据中来到业务中去的闭环能力。我们不再仅仅是在“监控”或“报告”流程而是在“理解”和“塑造”流程。这个过程本身就是推动软件开发从一门手艺Craft向一门可度量、可优化的工程学科Engineering迈进的有力一步。当然这条路充满挑战尤其是数据质量、模型可信度和组织文化接受度方面。但正如我们搭建这个原型所展示的起点可以很低价值却可以随着数据和经验的积累而不断放大。