客服不用一直盯着，预约改期怎样继续办下去？

有了一个好用的按钮，为什么还需要流程？

上一章的应用解决了阿宁眼前的一次操作：她选中预约，查看可选场次，确认后提交改期。离开这个页面以后，业务仍然会继续。联系人可能补来一份材料，主管可能晚些时候批准，接待系统可能暂时没有确认。每一步都发生在不同时间，不能指望工作人员一直盯着同一张页面。

流程把这些时刻连接起来。团队把“改期申请”定义成一条独立业务记录，让它关联原预约，并用状态表示办理进度。比如待整理、待补信息、待审核、待申请人确认、已完成。状态说明现在到了哪里，进入和离开状态的条件说明下一步怎样发生。这样换班后的同事也能从同一条申请继续处理。

数据管道在前面负责取得并整理资料，例如把预约系统和场次表更新到一致的信息。业务流程则围绕某一件事继续推进：收到申请后做什么，谁要确认，什么时候重试，何时结束。数据准备、页面操作和流程流转共享对象，但各自在解决不同的问题。

团队先在方案图中讨论这些连接。Solution Designer 可以表达平台组件与外部集成的关系，AIP Architect 帮助形成方案和实施建议，AIP Critic 帮助审视方案。图画出来以后，一个特别基础的问题就清楚了：系统必须先知道什么时候开始办理。

本节事实核查：官方资料 [1]官方资料 [3]

系统怎样知道，现在该轮到它做事了？

一种开始时机，是业务对象发生变化。例如出现一条新的改期申请，或者待补信息的申请终于收到人数。另一种开始时机，是时间到达。例如每天下午检查哪些申请已经等待联系人回复超过一天。

Automate 可以按持续检查或计划时间评估这些条件。条件成立后，它执行配置好的后续工作，例如调用操作、运行函数或 AIP Logic，或者发送平台和邮件通知。你可以把它理解为一套“到这个时刻，符合这些条件，就开始做这件事”的安排。

在这个虚构方案里，新申请首先进入资料整理；等待超过约定时间的申请会提醒负责人。哪些情况需要自动处理，哪些只提醒人，来自团队对业务的定义。例如“可选场次还有名额”只是可以进一步办理的条件，“申请人已经同意新时间”才允许继续正式提交。

触发规则还需要使用清楚的对象状态。同一笔申请已经进入审核，就不应因为原始数据又刷新一次而被当成全新的事情反复办理。系统是否重复、何时重新检查，由具体条件和处理逻辑决定。现在申请能够按时进入流程，接下来要让它的内容变得可以处理。

本节事实核查：官方资料 [1]官方资料 [17]

一封邮件和几页附件，怎样变成可处理的申请？

表单里的日期和人数容易直接读取，邮件则可能写成：“我们大巴晚一小时，想换到后面一场，人数以附件为准。”附件还可能是扫描件。要继续排期，系统必须从这些不同形式的材料里找出日期、人数和需求。

AIP Document Intelligence 用来比较和部署文档提取方案。有文字层的电子 PDF 可以读取原生文字；OCR 将扫描图里的字识别成文本；保留版面的 OCR 还保留文字位置；视觉语言模型可以结合文字、图像与页面布局处理内容。工具还可以把提取结果对应回原 PDF 的具体区域，便于人确认。

例如附件上同时写了“预计 24 人”和“最终确认 20 人”。如果提取结果只留下数字而没有上下文，后面的排期判断就容易用错。阿宁能够回到原页查看数字所在的位置，确认应该采用哪一个。这说明文档提取的价值，在于把材料变成可读、可查的内容；业务上采用哪个字段，还需要相应规则。

当团队找到合适的提取方法，就可以将它部署到批处理流程中，让后续类似材料按同样方式处理。AIP Logic 再把读取说明、归纳需求、查询相关对象和输出结果组织为可重复调用的函数。它可以使用条件、变量、循环、模型、函数及业务操作等处理块。

明确的日期和人数条件适合交给规则判断；表达多样的说明适合让模型帮助整理。如果邮件只说“晚一点”，输出可以保留“目标时间未明确”，让申请进入待补信息，而不是自行猜一个时间。申请内容逐渐清楚后，流程才有足够依据决定下一步走哪条路。

本节事实核查：官方资料 [4]官方资料 [5]官方资料 [7]

把办理顺序画出来，每种分支就有了去向

团队希望把这段过程看成一条可运行的图：收到申请，整理材料，核对名额；信息不全时请人补充，需要特殊安排时交主管，条件满足时准备待确认方案。Workflow Builder 的官方核心概念文档介绍了这样的画布。节点表示一个处理步骤，连线表示执行次序和对象如何继续传递。

原文提到的七类节点，可以放回这件事中理解。trigger 启动流程；compute 调用计算或配置转换，例如核对日期与名额；use LLM 让语言模型理解说明，并可使用已经提供的业务工具。到了需要分流的地方，fork 按条件让不同情况走不同路径；effect 则执行操作，例如改变申请状态或发送通知。

申请可能有三份附件，loop 可以把同样的处理逐份执行。多个地方都需要“检查申请是否完整”时，subgraph 可以把这组步骤组织成可复用单元。它当前可以在同一张 Workflow Builder 图里复用，跨图则需要复制。复用的意义在于，团队修改一次检查逻辑，就有明确的一组步骤可以维护。

流程还要表达等待。官方的 after fork 会在所有分支完成后继续，after loop 会在所有循环轮次完成后继续。理解这些汇合点，就容易看懂为什么某个后续步骤尚未开始：它可能正在等待前面的几项处理，而不是程序无缘无故停住。

画布把复杂度显露出来，也让团队能够看见某种申请会走向哪里。但画得通并不等于实际会办对。下一步需要拿一些真实形态的申请，观察路径和结果。

本节事实核查：官方资料 [21]

看起来能走通，怎样知道每一步都理解对了？

团队先拿一份材料齐全的申请，再拿一份缺人数的申请。预期很明确：前者应该进入方案确认，后者应该进入待补信息。Workflow Builder 提供预览，可以选输入观察对象经过的节点和分支，也能查看输出、运行记录和版本记录。这样就能把抽象流程图与一笔具体业务联系起来。

不过，走了正确分支与正确理解材料，仍是两种检查。模型可能从复杂附件里读错人数，却恰好仍走进“可预约”分支。AIP Evals 可以用一组案例和评分规则反复比较函数、模型或版本的表现，帮助发现同类表达是否被稳定处理。

这组案例可以沿同一业务自然展开：信息完整、缺页、两个日期相互矛盾、资料无权读取、目标场次已经满员。正确结果不总是“自动通过”。对于没有明确时间的申请，保留待补状态，恰恰说明系统没有把未知内容当作事实。

在 AIP Logic 编辑器里看到拟议修改，也不代表正式业务记录已经发生变化。具体来说，先在编辑器里检查拟议修改；配置并发布函数后，再由 Action（业务操作）或 Automation（自动化）调用，才能实际写入本体。团队分别理解预览中的结果、待确认的方案和真正执行后的状态，就能知道正在观察哪一种证据。

这些准备完成后，流程开始处理日常申请。接下来，阿宁需要一眼看见所有申请的进展，团队则需要了解整体哪里耗时最多。

本节事实核查：官方资料 [6]官方资料 [8]官方资料 [21]

同样是“卡住了”，怎么分清到底卡在哪里？

Autopilot 可以把流程表示为看板：一列是待补信息，一列是待审核，另一列是待联系人确认，每张卡片对应一条申请。阿宁点开 A102，就能看见当前属性、修改历史和关联自动化事件。它帮助解决一笔具体事情：“这条申请现在需要谁继续处理？”

Machinery 则利用状态变化日志分析整个过程。假如多半申请在待审核停留两天，问题可能出在审核排班；如果申请常常从审核退回补信息，可能是最初的材料要求没有表达清楚。日志记录对象在何时进入了哪个状态，才能计算路径和等待时间。外部流程也可以接入，但需要提供相应的变化记录。

这些记录的时间性有边界。Machinery 标准日志链路的官方典型延迟为两到五分钟，适合过程分析，不能当作要求立即响应的控制信号。分析异常路径时还要知道默认的一致性筛选可能排除偏离设计的实例；否则恰好需要研究的异常可能不在结果里。

还有一种卡住发生在系统本身：持续执行失败，或者输入停了，长时间没有新的评估和触发。Monitoring views 可以按规则发出告警。申请积压、一次执行失败、数据不再到达，应该被区分开，因为它们对应不同原因。

暂时性故障可以重试。Automate 的事件重试可配置一至五次，无法重试或次数耗尽后可以进入后备处理。静音继续评估条件但不触发后续工作；暂停停止定时与实时触发并中断活动执行，同时仍允许手动运行或重试。无论重试还是暂停，都不会自动撤回已经成功发出的外部请求，所以同一笔申请如何避免重复处理仍需业务方案解决。

本节事实核查：官方资料 [9]官方资料 [10]官方资料 [11]官方资料 [12]官方资料 [13]官方资料 [14]官方资料 [15]

业务规则变了，怎样让整条流程一起跟上？

过一段时间，博物馆决定把“待审核”拆成“待初审”和“待复核”。这并非只改一个显示名称：提醒条件、操作规则和客服页面也可能依赖原来的状态。Workflow Lineage 用依赖关系图帮助团队找出这些连接，并提供部分批量维护能力。它关注理解和管理已有流程，和编排执行的画布各有侧重。

一些变更可以放进 Global Branching 中进行。团队在统一分支里修改受支持资源，检查相关流程，再按资源要求审阅并合并。这让一组相互影响的变化有机会一起验证。分支合并与跨环境发布仍是不同环节，合并完成后还要由发布安排决定哪一版进入目标环境。部分批量修改可能直接作用于资源，是否审批取决于具体操作和配置；批量换模型也只支持特定 Logic 路径。

交接时还要看自动化用谁的身份运行。Automate 通常以 owner，即所有者的权限，评估条件并执行操作；通知则按收件人权限处理。所有者可以是个人，也可以是配置支持的应用身份。人员变动后，流程是否还能访问所需资料，和这份身份有关。自动化历史目前保留六个月，需要更久的业务证据时，应另行保存为受管理的数据。

再看 A102 的整个过程。资料读清、场次确认、预约修改和外部接待系统确认，共同构成团队约定的完成结果。外部请求是否成功送达、重试是否重复、失败后谁补办，都在这件事的办理范围中。共用对象让这些工具少做重复映射，但使用费用、迁移和维护工作仍需要结合现有系统考虑。

阿宁终于不必记住每笔申请下一步该提醒谁了。应用给她一个清楚的办理界面，流程负责把重复步骤按条件推进。最后还有一个让人期待的问题：如果联系人直接用一句话描述需求，助手能不能理解它，并借助这些已经准备好的能力帮助办理？这就是下一篇的企业 AI。

本节事实核查：官方资料 [2]官方资料 [16]官方资料 [17]官方资料 [18]官方资料 [19]官方资料 [20]

适用边界与容易误解的地方

术语速查

状态机

列出业务可处于哪些状态，以及允许怎样转换。

流程挖掘

用历史事件还原实际办理路径和等待时间。

后备处理

正常执行失败后，通知、记录或转人工的路径。

执行身份

系统执行任务时使用哪一个账户的权限。

来源与核查

对应原文

Rahul Garg · 2026-08-20 · Vanyar

1. Automate条件、效果与分支能力。
2. Workflow Lineage命名历史和依赖管理定位。
3. Solution Designer架构设计、Architect 和 Critic。
4. AIP Logic函数化流程构建。
5. Logic 核心概念处理块及组合。
6. Logic 入门预览与正式编辑路径。
7. Document Intelligence提取策略、原文定位及部署。
8. AIP Evals案例、指标和版本比较。
9. Machinery 概念状态过程与事件日志。
10. Machinery 数据接入日志要求和典型延迟。
11. Machinery 分析一致性过滤范围。
12. Autopilot 看板按状态查看对象与重试。
13. Monitoring 规则无新触发和失败等监控规则。
14. 自动化重试重试次数、资格和后备处理。
15. 静音与暂停停止评估与停止效果的区别。
16. 流程依赖与批量维护批量变更模式和模型限制。
17. 自动化权限个人或应用 owner 与通知权限。
18. 自动化历史六个月保留及长期保存路径。
19. 外部 Webhook外部请求与事务边界。
20. Global Branching 官方概览分支隔离、端到端测试、按资源策略审批与合并，以及和发布管理的区别。
21. Workflow Builder 核心概念当前官方画布、七类节点、预览、运行历史、汇合与子图复用规则。

资料核对日期：2026-09-15。本文用中文概括原文观点，结合一手资料独立讲解；分析、图解和教学示例由本指南编写。主题清单用于检查议题覆盖，不表示逐项复写原文全部细节。产品能力以所在部署的当前官方文档与实际配置为准。