Automation Loop（业务闭环）

Automation Loop 是 AIDC 推进业务自动化的基本单元：一个业务场景从开始到结束、能够完整跑通并把结果送回发起方的流程闭环。流程一旦能用文字清楚描述，就能沉淀为 Skill 交给 Agent 执行——业务自动化不是给员工配一个 AI 工具，而是把一个个跑通的闭环交给系统持续运营。

// 一句话理解

把一项业务——比如向客户报价——从「客户发来邀请」到「结果回到发起人」的完整过程画成一个环：环上每一步写清楚由谁提供什么数据、按什么规范、在多长时间内交付。这个环先由人跑通，再交给 Agent 接管。这就是业务自动化。

// 核心命题

企业的数字孪生按 Object → Link → Action 三阶段推进：先让 AI 认识企业里的实体，再打通部门之间的连接，最后把每一个业务闭环固化为可执行的行动。Automation Loop 属于 Action 建模——每一个跑通的闭环，就是一个 Action。

什么是 Loop：业务闭环与业务自动化

Loop（业务闭环）是指一个业务场景从起点到终点、能够完整跑通并产出明确结果的流程循环。一个合格的闭环必须同时满足三个条件：

起点与终点明确 — 从哪里开始（如客户数据进来）、到哪里结束（如结果回传），必须能用文字语言描述清楚；
中间环节可连通 — 每个环节之间的衔接点，包括需要人介入的断点，都被识别和管理；
结果回流 — 最终输出必须回到流程的发起方和相关管理者。结果没有回去，环就没有闭上。

业务自动化，就是选定一个业务场景，把它的闭环用文字完整写下来——第一步做什么、第二步做什么、循环长什么样、中间可能遇到什么问题。流程一旦能用文字清楚描述，就可以转化为 Skill，交给 Agent 执行。一个完整的闭环框架要同时回答四件事：

流程Process

每一步的输入与输出：第一步做什么、第二步做什么、由谁负责、到哪一步结束。流程是闭环的骨架，必须先于一切被写下来。

工具Tools

这套流程中需要使用哪些工具与系统——OA、ERP、知识库、报表系统。工具决定闭环各环节由什么承载。

数据Data

使用哪些数据、数据从哪个部门进来、按什么规范交付、最终沉淀在哪里。数据是闭环上流动的内容物。

协调Coordination

与其他部门的协调方式。协调的本质也是数据——你的数据源从哪个部门进来，就是协调本身。

三条设计原则

原则一：先流程，后 AI

在设计阶段要先把 Agent 剥离开，不要在流程尚未理清时引入 AI。否则会反复出现「这个问题 AI 做不到、那个问题 AI 做得不够好」，在流程不清楚的状态下反而拖慢推进。正确顺序是：

先用人的判断把整套流程建立起来，看每个环节、每个断点能否先连上；
组织框架理清楚之后，再交给 Agent——此时 Agent 的职责是非常清晰的；
设计框架时带着「理解 AI」的视角推进——这正是 FDE 产生价值的地方：驻场到业务现场，和业务一起把流程写清楚。

原则二：断点管理

断点是流程中必须由人介入的环节——例如客户中途提出修改设计、更换材料。一旦闭环中存在未被管理的人工断点，Agent 跑到这里整个流程就会断。因此引入流程框架的同时，必须对断点进行管理：识别断点在哪里、由谁负责、以什么方式衔接回自动化流程。断点不是自动化的敌人，未被管理的断点才是。

原则三：大流程套小流程

企业一定是「流程套流程」的整套框架：从客户开始到项目交付是一个大流程，大流程中的每一个环节——报价、客户交流、开发——又各自是一个小流程。流程设计必须自上而下、从大到细：必须先有大框架再细化，从细节往上拼凑是做不出来的。判断标准很简单：凡是跨部门的就是大流程，一两个人就能解决的是小流程；优先做大流程。同时不必拘泥于细节——当前 AI 做不到非常精细，但能做大概、能做衔接，先把大的环连通，再逐步细化。

一个真实闭环：制造企业的营业报价

以一家制造企业的营业报价为例。过去营业靠线下逐个部门收集设备成本、材料成本，结合个人经验调整后报给客户，反复多轮。把它写成闭环之后，流程是这样的：

客户发出报价邀请 — 通过邮件发来图纸与技术参数；
信息释放 — 营业将技术资料释放给工程中心，由工程中心按各部门要展开的内容分发给各职能部门；
评估会 — 围绕原材料、加工工艺、包装运输、生产节拍、模具工装投入等维度，各部门输出评审结果；
汇总成本依据 — 工程中心将各部门评审结果统一汇总为一份报价参考表单，形成报价的成本依据；
多轮报价 — 商务按客户的报价节点逐轮报价与调整；
结果回流 — 客户输出是否录用、是否定点的结果，回传给项目组与工厂运营管理者——闭环完成。

// 这个闭环里的真实断点

工程中心繁忙时部分资料未分发到位，变成营业自己在追；报价与定点结果没有第一时间回传给项目组；报价所需的基础输入——来自工程、采购、生产技术、装备四个部门——长期靠人工反复催要。这些断点正是自动化要管理的对象，也是闭环价值最大的地方。

规范：闭环的合同

制定规范，就是把一段业务拆成两个部分分别写清楚：逻辑（流程）——数据经过几个人手、几个部门、什么时间节点；材料（数据）——数据本身长什么样、来自谁、有没有入库、决策依据存放在哪里。规范最终要落成有明确格式的文件（Word、Excel 即可），能直接对接到部门，能填入业务系统的台账。

// 治理规则

谁使用数据，谁制定规范。数据的使用者最清楚自己要什么；数据的提供者按规范交付。数据卡在谁那里，系统中可见、可追责。

规范落地为一套异步协同机制——过去靠人催数据，规范建立后由 Agent 按规范定时催办与校验：

数据使用方写清要求与验收标准——要什么数据、什么格式、什么口径；
规范下发给数据提供部门对应的 Agent，由 Agent 转交对应负责人；
约定限时交付（例如三小时内），完成后系统自动触发回传确认；
到期未交付的，由定时任务检查数据是否到位；
数据卡在哪个部门，系统中可见——责任归属清晰，再针对性整改。

规范本身分层级——「大规范套小规范」，与「大流程套小流程」一一对应：

层级	内容	制定者
大规范（抽象层）	通用模板：流程怎么走、数据流怎么走、怎么分析问题；平台如何提供服务、如何与各部门配合	AI / IT 部门
小规范（业务层）	结合具体业务场景：要哪些数据、什么格式与验收标准、各环节交付物	该场景的数据使用方（业务部门）
细分场景规范	细化到具体客户、具体产品的特定规格文件	场景负责人与对应 Agent

围绕任务流构建组织

跨部门协调的本质是数据的流动——「我的数据源从哪个部门进来」就是协调本身。因此组织不应围绕部门墙安排工作，而应围绕任务链和信息流来构建：组织是为最优的协作任务流服务的。任务链清晰之后，每个部门自然清楚自己该做什么、怎么维护数据；任务流中数据卡在哪个部门，系统中可见、可追责。跨部门的大流程是自动化优先级最高的对象，因为部门墙正是断点最多的地方。

信息流要按「能否产生经验」分类处理：

简单推送型 — 一次发送即结束的信息，不必专门存储；
经验沉淀型 — 能形成稳定经验的信息流，需要单独设计存储，沉淀为 SOP 与 Skill；
对话日志 — Agent 的全部对话后台自动留存，作为兜底的审计记录。

每个部门都要把自己的审批流、信息流、工作流总结成文件。整套业务模式像一个树状结构：遇到什么情况 → 调用什么文件 → 找什么人。这是一套复杂的生态系统，靠人机结合让 AI 逐步理解——AI 理解之后就可以复制，并演化得更好。要注意：整理是必须的，上传只是动作——流程一旦嵌入 Agent，Agent 自己就知道，但企业内部必须保留一份备份。

// 会议 SOP

所有会议执行同一条 SOP：录音 → 转写 → 纪要 → 喂给 Agent → 沉淀为知识库条目。但要记住：重要的不是 AI 知道，而是人必须知道——AI 知道而人不知道，是没有用的。

在三阶段中的位置：Object → Link → Action

知识库与 Agent 本质上在做同一件事：企业的数字孪生。数字孪生按三个阶段推进：

阶段	名称	内涵
第一阶段	Object 建模（实体）	让 AI 认识企业中的实体概念——什么是客户、什么是产品、什么是部门。对应 Ontology 的 Object Types
第二阶段	Link 建模（连接）	打通部门与部门之间的数据贯通：数据源对接、跨部门协作、信息流管道。对应 Link Types
第三阶段	Action 建模（行动）	每一个跑通的业务闭环固化为一个 Action，集成到平台中受控执行。对应 Action Types

三个阶段层层递进：先认识实体，再连通部门，最后把每个业务闭环固化为可执行、可审计的行动。业务闭环属于 Action 建模——Automation Loop 写清楚、跑通、规范化之后，就能注册为受控的 Action Type，每次执行写入 Action Log，从此可复制、可审计、可持续演化。