流程大咖说 | 流程智能——把隐性规则变成 AI 可推理的上下文

引言： 上一篇我们讨论了沃尔玛的Agent治理架构：当成百上千个部门自建Agent在系统里协同奔跑时，信任必须被携带，而不能被假设——每个Agent都要携带一份机器可读、可被核验的"身份证"（Agent Card），声明自己能做什么、不能碰什么、什么情况下必须转人工。

文章结尾凡得留下了一个思考：上篇反复强调的"流程智能"，本质是把企业里散落在各部门员工经验和判断里的隐性规则，完成显性化、标准化、系统化、AI化四步蜕变。但有一个问题当时没有展开：Agent要声明身份、边界和意图，前提是这个Agent得先知道自己能声明什么。而这恰恰是企业落地Agent时最容易被低估的工作。本篇就来拆解：一条只存在于老员工脑子里的经验，是怎么变成AI在推理那一刻真正能调用的上下文的。

▼

上一篇讨论沃尔玛的 Agent 治理架构时，留了一个没展开的问题：Agent 之间要建立信任、要协作，靠的是"声明身份、能力边界、可审计"。但声明的前提是——这个 Agent 得先知道自己能声明什么。而在一个跨部门的决策链上，多数时候，Agent 卡在某一步不是因为算法不够强，而是因为它在那一步缺一条本来就没写下来的规则。

于是决策链治理的第一个动作，不是选模型、不是搭编排框架，而是逐环节地问一句：这一步，AI 现在缺的是什么信息？这条信息现在在谁手里？它为什么没有被写下来？

这句话看起来简单，但它其实拆出了三个完全不同性质的子问题，分别对应三种不同的解法：

• 缺信息，但信息本来就该实时查（库存数、价格、天气）→ 这是数据接口问题，接 API 就好，不构成本文讨论的难点。

• 缺信息，信息以文档形式存在但没被结构化（SOP、审批手册、邮件里的"惯例"）→ 这是显性化问题。

• 缺信息，因为这条规则从来没被写下来，只存在于某个老员工的判断力里（"客户如果是这种情况，通常我们会……"）→ 这是隐性知识问题，也是最难、最值钱的一类。

流程挖掘（Process Mining）负责解决第二、第三类问题里"这条规则到底是什么"；上下文工程（Context Engineering）负责把挖出来的规则，变成 Agent 在推理那一刻真正能调用的东西。两者不是同一个工作的两个名字，是接力关系。

本文定义流程智能=流程挖掘（Process Mining）+ 上下文工程（Context Engineering）。

大多数企业的规则不是不存在，而是分布式地存在——一部分在系统日志里（谁在什么时间点做了什么审批），一部分在人的脑子里（"这种订单我们从来不走标准流程，因为一走就慢两天"）。流程挖掘做的事情，是拿真实的操作日志（事件时间戳、执行人、系统状态变化），去反推出组织实际在跑的流程，而不是流程图上画的那个理想流程。

这里有个关键区分，决定了流程挖掘为什么对 agent 落地特别重要：写在制度文件里的 Policy，和系统日志里跑出来的 Policy，几乎永远是两个不同的东西。

//案例：采购审批的"隐性快速通道"

假设某企业的正式审批 SOP 写的是：任何超过 5 万元的采购，必须经过三级审批，平均耗时 4 天。但流程挖掘对半年的审批日志做事件重建后，会发现真实分布是双峰的——一部分订单确实走了 4 天的完整链路,另一部分订单，只要满足"供应商是过去合作过 20 次以上的名单内供应商 + 采购人是某几个特定岗位"，审批耗时永远稳定在 4 小时以内，且从未被拒绝过。

这条"4小时通道"在任何制度文件里都不存在。它是某几位审批人长期以来用经验判断出的一条隐性规则：老供应商 + 熟手采购，风险已经被验证过，走不走三级都是走过场。流程挖掘的价值，就是把这条从没被写下来、但已经稳定运行了两年的规则,用数据的方式挖出来、显性化、变成一条可以被检验、可以被标准化的候选规则。

这一步做完，企业面前会出现两条路：要么把这条隐性规则升级为正式标准（写进 SOP，让所有符合条件的订单都走快速通道，减少人工审批负担）；要么发现这条隐性规则其实藏着风险（比如快速通道里有 3% 的订单事后被审计发现有异常，只是过去没人系统统计过），从而收紧规则。无论哪条路，前提都是先把它从"某人的判断力"里挖出来，变成一句人人能看懂、能核验的话。

这正是流程挖掘对应你说的"Policy 显性化、标准化"这两步——显性化是把隐性规则挖出来变成文字，标准化是把这条文字变成一条明确、可重复执行、有边界条件的规则(不是"通常我们会……"，而是"当条件 A 且条件 B 同时满足时，执行 C，例外情况 D 转人工")。

流程挖掘挖出来的，是一条规则的文字描述。但一个 agent 在推理的那一刻，不会去读一份 SOP 文档——它需要的是：在它做决策的那个瞬间，这条规则以它能理解、能调用的形式，恰好出现在它的输入里。

这就是上下文工程要解决的问题，也是"标准化"之后"系统化、AI 化"这两步真正发生的地方。上下文工程的核心工作可以概括为四个动作：写入（Write）、筛选（Select）、压缩（Compress）、隔离（Isolate）——决定什么信息该被记住、什么时候该被取出来、怎么压缩到不占用过多推理空间、以及不同任务之间的上下文要不要互相隔离，避免互相污染。

//继续用采购审批的例子往下走：

• 写入（Write）——流程挖掘挖出的"4小时快速通道"规则，被结构化写成一条可检索的策略条目：条件字段（供应商历史合作次数≥20、采购人岗位属于名单X）、动作（跳过二三级审批）、例外（金额超过某阈值仍需人工）、有效期与复核周期。这条策略不是存在一份 PDF 里，而是存进一个策略库，可以被程序化查询。

• 筛选（Select）——当一个新的采购请求进来，agent 在推理前，不是把整本 SOP 都塞进上下文（那样既浪费也容易让模型抓错重点），而是根据这笔采购的供应商、金额、采购人角色，只检索出与这一单真正相关的那几条策略，作为上下文注入。这一步做得好不好，直接决定 agent 判断的准确率——这也是为什么很多企业觉得"上下文工程"听起来像是"多喂点文档"，但做出来效果很差，因为喂错了文档，或者喂了太多不相关的文档,反而稀释了关键信息。

• 压缩（Compress）——一条完整的策略描述可能有几百字的背景说明、历史沿革、例外情况列表，但 agent 在推理那一刻用不上这么多，上下文工程要把它压缩成推理最需要的那几句结构化判断条件,类似"if-then"的形式,而不是让模型自己去从大段文字里提炼。

• 隔离（Isolate）——采购部门的策略上下文，不应该和物流部门的策略上下文混在同一个推理窗口里,否则容易出现"用错部门的规则去判断另一个部门的事"这种串戏错误。跨部门协作时，每个部门的 agent 应该带着自己那部分被隔离、被清洗过的上下文进入协作，而不是共享一个大杂烩式的全局上下文。

这四步做完，一条原本只存在于某个审批人脑子里的经验，才真正变成了"AI 化"的东西——不是被写下来就叫 AI 化，而是被组织成 agent 在正确的时刻、以正确的形式、只拿到该拿到的那部分，能够直接拿来推理的输入，这才是"被推理"这个词真正的含义。
 

把前面两节串起来，一条隐性 Policy 从"存在于人的脑子里"到"能被 agent 正确推理"，要走完四步，缺一步都会出问题：

• 第一步，隐性知识被流程挖掘从日志里反推出来——这一步解决"这条规则到底是什么"，产出是一条自然语言描述的候选规则，加上支撑它的数据证据（比如"过去两年，符合条件X的订单里，98%走了快速通道，且事后审计异常率仅为普通通道的三分之一"）。

• 第二步，规则被标准化为明确的条件-动作对——这一步解决"这条规则能不能被清楚地写下来、检验、争论",产出是一条结构化的策略条目,有明确的输入字段、判断逻辑、例外情况和负责人签字确认。这一步最容易被跳过,很多企业以为挖出来就完了，直接把还带着模糊表述的规则丢给 AI，结果是 AI 学到的是一条自己也解释不清楚边界的规则，出错了都不知道错在哪个环节。

• 第三步，标准化的规则被上下文工程系统化——这一步解决"这条规则怎么在正确的时刻出现在 AI 面前"，产出是一套检索、压缩、隔离机制,让 agent 在需要的那个瞬间，恰好拿到恰好够用的那部分上下文。

• 第四步，规则进入生产后被持续监控，反馈回流程挖掘——agent 用这条规则做出的决策，本身又会产生新的操作日志,流程挖掘再对这些新日志做分析，检验这条规则是不是真的如预期运作,有没有出现新的例外模式,值不值得再挖出一条"规则的规则"。这一步让整个链条形成闭环，而不是挖一次、用一次就结束。

这条链路最重要的启示是：上下文工程做得再精细，如果流程挖掘那一步挖出来的规则本身是错的、或者边界模糊的，AI 依然会规律性地犯错——只是犯得更快、更自信。这也是为什么把"显性化标准化"和"系统化 AI 化"分成两个独立的能力来建设，而不是指望买一套上下文管理工具就能自动解决，是有道理的：前者是组织认知层面的工作，需要业务专家介入判断"这条隐性规则到底该不该变成标准"，后者才是纯技术层面的工程问题。

难点一，隐性规则的"发现"本身会触碰既得利益。挖出"某几位审批人一直在走快速通道"这件事，等于把原本只属于少数人的判断权公开化、可审计化。这种发现在实际推行中常常遇到的不是技术阻力，而是"这条规则如果写清楚了，我的价值是不是就没了"这种心理阻力——尤其是当那条隐性规则本身就是某个老员工经验价值的核心部分时。

难点二，规则的"边界条件"永远比想象的多。现实中的隐性规则很少是干净的 if-then，更多是"通常这样，除非遇到 A、B、C 这几种特殊情况，而这些特殊情况我们也说不清楚全部列表"。流程挖掘挖出来的规则如果只覆盖了 80% 的常见情况，剩下 20% 的边界情况被强行塞进同一条规则里，agent 上线后大概率会在这些边界情况上出问题——而这些边界情况往往恰恰是风险最高的那一部分。

难点三，"标准化"和"系统化"之间容易出现责任真空。业务部门觉得"我们已经把规则写清楚了，是 AI 团队没做好"，AI 团队觉得"你们给的规则本身模糊、有歧义，我们没法系统化"。这个真空地带如果没有一个角色专门负责"策略条目的最终确认权"，项目会在这个环节反复拉锯。

先挑一个范围小、日志质量高、风险可控的流程做试点，不要一开始就挑跨五个部门、涉及重大决策权的流程。理想的第一个试点，满足三个条件：操作日志本身就是结构化电子记录（不需要额外补录）、决策后果在几天内就能验证对错（不用等半年才知道判断准不准）、出错的代价可控（不是那种一旦错了就损失巨大的决策)。

流程挖掘产出的候选规则，先让业务专家"签字确认"再进入标准化，不要让技术团队单方面拍板。每一条从日志里挖出来的隐性规则，都应该经过懂业务的人过一遍：这条规则是"值得保留和推广的经验"，还是"长期存在但其实一直有问题的漏洞"。这一步跳过，很容易把错误的隐性规则也系统化、AI化，让错误被规模化放大而不是被纠正。

上下文工程阶段，先做"筛选"和"隔离"，再做"压缩"。很多团队一上来就急着把规则压缩成最精简的形式喂给模型,但如果筛选逻辑本身不准（喂错了规则、喂了不相关的规则），压缩得再精简也没用。先保证"拿对了东西"，再考虑"怎么拿得更干净"。

给每条上线的规则设定复核周期，而不是一次性上线就不管。隐性规则被标准化后，业务环境仍然会变（新的供应商类型出现、市场条件变化），如果没有强制的复核节点，规则会像最初那条隐性规则一样，悄悄地和现实脱节，只是这次脱节的是被写进系统的"标准"，而不是某个人的经验判断——脱节得更隐蔽，因为它披着"标准"的外衣。

跨部门协作的场景，放在单部门流程跑通之后才做，不要一开始就上。单部门场景里，规则的所有者是清楚的（一个部门负责人就能签字确认）。跨部门场景里，一条规则往往涉及多个部门谁的判断优先，这个协调成本在没有先跑通单部门方法论之前去处理，会把方法论问题和组织协调问题混在一起，两个都解决不好。
 

第一阶段（1-2 个月）：选定一个高频、后果可快速验证的单部门流程，跑通"日志采集→流程挖掘→候选规则→业务专家确认"这一条链路。这一阶段的目标不是上线 AI，而是验证组织有没有能力把一条隐性规则完整地挖出来、写清楚、达成一致——如果连这一步都做不顺，后面上下文工程和 agent 落地都是空中楼阁。

第二阶段（2-3 个月）：把第一阶段确认过的标准化规则，接入上下文工程流水线，做筛选、压缩、隔离，先在人工决策的"辅助建议"模式下运行，不做自动执行。这一阶段让 AI 的判断和人的判断并行跑一段时间，比较两者的分歧点在哪里，这些分歧点往往就是规则里还没覆盖到的边界条件，借此机会把规则打磨得更完整。

第三阶段（2-3 个月）：在分歧率降到可接受水平后，把低风险、高置信度的那部分决策交给 AI 自动执行，高风险或低置信度的部分继续转人工。这一步不是"全自动"和"全人工"的二选一，而是按风险和置信度分层放权，这也是沃尔玛治理架构里强调的"agent 声明能力边界"在这个语境下的具体体现。

第四阶段（持续）：把这套方法论复制到第二个、第三个部门的流程，同时开始建立"部门间规则冲突检测"机制，为跨部门协作打基础。只有当至少两三个部门都各自跑通了"隐性规则可被挖掘、标准化、系统化"这一条链路，跨部门编排才有意义——否则每个部门自己的规则都还没理清楚，跨部门协调只会把混乱放大到更大范围。

优先从哪个场景开始，如果要给一个具体建议：选那种"结果错了成本不高、但发生频率足够高，值得投入"的判断类任务——比如内部报销异常识别、供应商准入初筛、客户投诉的优先级分级，这类任务日志质量通常较好、隐性规则相对集中在少数几位资深员工身上，是验证整套方法论最划算的起点。跨部门的复杂决策链（比如你在意的那类端到端协调场景），应该是这套能力被验证过后的第二步，而不是第一步。
 

总结：上篇说，Agent协作的前提是"信任必须被携带，而不能被假设"。本篇补上了这句话的下半句：规则也一样——隐性规则必须被挖出来、写下来、标准化，再被组织成AI在正确时刻能调用的上下文，否则Agent之间的信任协议再严密，也不过是让系统更自信地执行那些从没被验证过的猜想。 流程挖掘解决"规则是什么"，上下文工程解决"规则何时以何种形式出现"，两者接力，才是"流程智能"完整的含义。