ServiceNow 的 AI Workflow Factory：把流程改进变成一个有治理的闭环

ServiceNow 在 2026 年 10 月 6 日于孟买 World Forum 发布了 AI Workflow Factory 与 Autonomous Engineer。官方公告的第一句话点明了它要解决的问题：企业数字化改造的痛点，在于「碎片化、遗留的基础设施造成的执行缺口」。所以这次的方案不是再卖一个「转型项目」，而是把流程改进本身做成一个持续运转的闭环——用官方说法，就是「数天而不是数月」完成业务运营的规模化。

「数天而非数月」完成业务运营扩展

换一种做法：把改进变成循环，而不是项目

传统企业改造的做法是「发现一个问题，立一个项目，交付，然后等下一个大动作」。ServiceNow 想换掉这个节奏：每个产出应该直接暴露下一个改进机会，形成持续的循环。公告里那个例子很好懂——如果目标是把若干业务单元的个案转移率提高 20%，旧办法是先组建一个成熟的个案转移团队、在一个业务单元试点、然后再推下一个；新办法是让「结果」引导过程：Process Mining 先显示今天在哪里可以转移，工厂把工作流建出来，Agent 在各业务单元并行铺开，并持续按既定结果优化。更微妙的转变在于归属。在项目制里，业务单元是发起方，平台团队是交付方；在闭环里，平台团队运营工厂，而每个业务单元继续拥有自己的 KPI。正是这次重新分工让「并行推进」变得可能：业务单元不再排在一个中央交付团队后面等，但同时也无法把自己被考核的那个数字的责任外包出去。

# The unit of work is a loop, not a project. Each outcome is the
# input to finding the next opportunity - that is the whole idea.
LOOP = [
    ("mine",    "Process Mining: which processes should change, tied to KPIs"),
    ("build",   "Autonomous Engineer + Build Agent: construct and QA"),
    ("run",     "App Engine: run the improved workflow at scale"),
    ("measure", "compare against the KPI the business unit already tracks"),
    ("repeat",  "feed the result back in as the next candidate"),
]

def improve(target_kpi):
    for phase, _ in LOOP:
        audit_log.record(phase, target_kpi)     # governance from step one
    return "next_opportunity"

# Compare that to a one-off transformation project: it ships,
# then everyone goes back to waiting for the next big initiative.

三段式闭环：挖掘、构建、运行

循环由三个部件咬合。Process Mining 负责找出哪个业务流程该改，并且明确「绑定到业务单元真正在考核的 KPI」——这一步是做对方向的关键，否则优化的是好看的指标而不是重要的指标。Autonomous Engineer 与 Build Agent 负责把改进构建出来并控制质量。App Engine 负责把改进后的工作流安全地规模化运行。三者串成一条流水线，中间由 AI Control Tower 做治理，而不是事后补审计。同样有必要讲清闭环「不做什么」。它不替代 KPI 的负责人。20% 这个目标本身是否定对了，仍然需要人来判断，而这个判断不会从流程挖掘或 Agent 的构建日志里长出来。工厂自动化的是「从机会到可测量结果」的路径，而不是接管「哪个结果值得要」的争论。

# Start from the outcome, not from the tooling. ServiceNow's own
# worked example: increase case deflection by 20% across several
# business units. Process Mining shows where deflection is possible today.
def find_opportunities(kpi, business_units):
    hits = []
    for bu in business_units:
        current = bu.measure(kpi)                  # baseline first
        reachable, evidence = mine_processes(bu, kpi)
        if reachable > current:
            hits.append({
                "unit": bu.name,
                "baseline": current,
                "target": round(current * 1.20, 4),  # +20%
                "evidence": evidence,
                "owning_team": bu.owner,
            })
    return hits

# The old way: assemble a mature deflection team, pilot in one
# unit, then move to the next. The loop lets units run in tandem.

Process Mining → 构建 → 运行 → 度量 → 下一个机会

无人值守编码，但关键决定仍然归人

Autonomous Engineer 提供的是「无人值守编码」：自主规划、构建、测试实施工作。这个词容易让人紧张，但公告立刻加了边界——开发者获得一站式工具，同时「保留对关键决策的控制」。拆开看就更清楚：机械环节（写实现、跑测试、生成配置）不需要开会，因此可以自主跑；而带后果的决定——上线什么、影响哪些客户、在受监管场景里能否放行——仍然需要具名的人签字。这套分工和 On 的云迁移案例是同一个模式。

# Autonomous Engineer takes the mechanical build work: planning,
# building and testing. Humans keep the calls with consequences.
task_spec:
  objective: "Implement case-deflection workflow for B2C support"
  definition_of_done:
    - deflection_rate >= baseline * 1.20
    - no regression in CSAT (>= -0.5%)
    - audit_trail_complete: true
  guardrails:
    max_auto_changes_per_day: 25
    require_human_approval_for:
      - "changes touching customer_identity"
      - "changes affecting billing"
      - "any change over 500 records"
  build_agent:
    plan: true
    implement: true
    test: true
    escalate_on_ambiguity: human

# Unattended does not mean unsupervised. It means the routine
# steps run without a meeting, and the risky ones still wait.

为什么治理必须写进循环而不是加在最后

公告反复强调 AI Control Tower 的作用：治理通过工厂运行的「工作流、决策与 Agent 动作」。这句话的份量在于位置——治理被放在循环内部，而不是交付后的合规检查。对受监管行业来说这不是装饰：BFSI 与电信的采购评审问的第一批问题就是谁能改、改了什么、日志留多久、出事怎么回滚。ServiceNow 也提到其在印度的数据中心为这些行业提供韧性、可审计性与监督，这基本是在回答采购清单而非技术清单。

# Governance is the part that gets skipped and then haunts you.
# AI Control Tower governs the workflows, decisions and agent
# actions running through the factory - one audit trail.
control_tower:
  scope: [workflows, agent_actions, decisions, spend]
  policies:
    - id: pii-boundary
      rule: "agents may read PII only inside approved systems"
    - id: spend-guard
      rule: "pause campaign if projected spend > budget * 1.1"
    - id: human-signoff
      rule: "regulated workflows require named approver per release"
  audit:
    retention: 7y
    immutable: true
  reporting:
    per_department_cost: true
    per_workflow_success_rate: true

# For BFSI and telecom buyers this is not decoration - it is the
# difference between 'put AI to work' and 'put AI to work here'.

无人值守编码负责规划、构建与测试，关键决定仍归人

数据说明缺口在执行，而不是野心

公告给了一个值得单独看的数字：据 ServiceNow 2026 企业 AI 成熟度指数，印度的企业 AI 投资在一年内增长了 119%，而在受访市场中表现靠前。更关键的是官方对差距的判断——不是野心不够、不是速度不快，而是「把速度转化为有治理、连通的执行」，具体堵点是遗留系统集成缺口与「方案蔓延」（solutions sprawl）。这解释了他们为什么把产品做成闭环加治理，而不是再做一个更聪明的助手。

# Action Fabric extends the same governed loop to third-party
# agents and tools, so choice does not mean losing control.
def run_third_party(agent, action, context):
    # every external call passes the same policy gate
    decision = control_tower.evaluate(
        actor=agent.id,
        action=action,
        data_scope=context.data_scope,
        jurisdiction=context.jurisdiction,
    )
    if decision == "deny":
        raise PolicyDenied(agent.id, action)
    result = agent.invoke(action, context)
    control_tower.record(agent.id, action, result, decision)
    return result   # one governed view across the enterprise

# Rollout note: AI Workflow Factory is globally available today;
# Autonomous Engineer is in Early Access on request.

照搬这个闭环的五个步骤

想借用这套思路，按这五步走比较稳。第一，先选一个业务单元真正在考核的 KPI，并把基线量出来，没有基线就没有闭环。第二，用流程挖掘找出「今天就能改善」的机会，而不是靠 brainstorming 列愿望清单。第三，把改进的构建拆成机械部分与后果部分，机械部分交给自动化，后果部分设具名审批人。第四，设定硬护栏——例如每日自动变更上限、触碰客户身份或计费必须人工批准、影响记录数超阈值必须升级——让自主执行有明确的活动边界。第五，把每个产出的结果反馈回机会池，同时保留完整的不可篡改审计轨迹。注意落地节奏：工作流工厂已全球可用，而 Autonomous Engineer 需申请 Early Access。最后补一条关于排序的提醒：先用单一 KPI 起步，不要一上来铺一个组合。一个同时把三个指标都做得很差的闭环，既无法教会你机制是否有效，也让归因变得不可能。先在一个数字上证明闭环成立，再考虑扩大范围；同时把第一个指标的流程挖掘证据留好——因为当第二个 KPI 上线时，你要拿它做基准对照。