本卷完整描述系统侧:交互 / 流程 / 引擎 / 调用 / 基座五层,工作流引擎 = 流程引擎 + 活动基座,人类工具四卡,统一事件标准,记忆系统,web + server 运行拓扑,活动与系统的边界,基座与治理。活动是像小程序一样在系统外开发、经活动库安装的 Agent 机制(Case = loop,SOP = flow),其活动侧规范见《活动模型》;本卷只写系统。
ERP / CRM 记录生意的结果性事实:订单成了、款收了、货发了。但对「这件事是怎么被做成的」,它们一无所知。
本系统记录工作的过程性事实:哪个触发器起的单、每一步谁在场、AI 干了哪段、人修订了什么、在哪里监听了三天、驳回过几次、最终谁放的行——即任务记忆与事件流(08)。这份含人机分工与认账链的轨迹,是任何 ERP 都不持有、事后也补不出来的数据;它的首要用途是增强工作质量的确定性(0.2),其次才是合规与复盘。ERP 记生意的事实,本系统记工作的事实——互补不重叠,这也是本系统不与 ERP 争地盘的原因;护城河不在业务数据,而在工作轨迹。
判断类工作的质量,传统上是一个随机变量:取决于谁在做、状态如何、经验是否在场。把 AI 以「加个聊天框」的方式引入,只会再放大它——产出不可复现、无法追因、责任模糊。
本系统对「AI Native」的定义与此相反:AI 参与的目标不是替人干活,而是增强工作质量的确定性;人机协作的可审计轨迹正是达成这一目标的机制。非确定性(人与 AI 的判断)被三重结构围住:事前有契约(契约七件,4.1)、事中有门(放行只属于人;流程层另有审批点)、事后有痕(任务记忆与事件流,可回放可归因)。围住之后,质量不取决于个体发挥,而取决于契约与业务模型——可版本化、可审计、可持续进化的组织资产。
本系统服务企业:协调员工与 AI 高效开展经营活动。按单次部署 ≤ 50 人、单组织设计:不做多租户,治理角色由组织内兼任,一切机制的复杂度预算以此为上限。系统只对两类主数据拥有事实源——员工与工作(任务、工作流、记忆);客户、物料、订单等业务对象,或在活动声明的台账里(数据可自生长,07),或在外部系统里(以外部系统调用接入,事实源在外)。
交互定呈现与责任,流程定结构与流转,引擎定执行,调用定能力,基座定事实。实现拓扑上,系统是 web + server 两侧(09)。
| 术语 | 定义 |
|---|---|
| 流程包 / 工作流 | 流程包 = 调用接口 + 两种活动 + 审批点 + 两种网关的编排定义:治理台在系统内编排,版本化存放于基座;工作流 = 流程包的运行时实例(03)。 |
| 活动 | 一个完成一项任务的 Agent 机制的开发态:基于活动基座在系统外开发,经活动库安装,以声明入流;两种:案例活动(loop)与标准活动(flow)。 |
| 任务 | 活动的运行态:活动被调起的一次运行;恰有一个负责人;工作台「任务」要素的单位。 |
| Agent 机制 | 活动完成任务的机制本体,范式两种:loop(临场演绎)与 flow(照谱执行);业务模型、交互内容、技能清单、Harness 与过程工作区皆随活动(《活动模型》)。 |
| 活动基座 | 落在系统内的通用运行模式,六件:契约 · 交互 · 记忆 · 数据 · 工具(调用契约)· LLM 调用;内容归活动,笼子归系统(04)。 |
| 活动包 / 活动库 | 活动的交付单元 / 已安装活动之库(独立的安装与卸载入口,11)。 |
| 工具包 / 工具箱 | 功能工具的交付单元(独立开发的代码包)/ 其注册入口与库(07 / 11)。 |
| 人类工具 | 调用层四种内置工具:决策 · 执行 · 补全 · 放行——与 LLM 工具同列;经对话流卡片到达人,回传异步(05)。 |
| 审批点 | 流程层的通用人裁节点:卡到审批人工位,通过 / 驳回,附依据;与活动级的放行不同层(03 / 05)。 |
| 事件信封 | 系统向活动抛事件的统一标准:ID · 类型 · 关联 · 载荷 · 时间与来源 · 留痕指针;四类:数据 / 时间 / 人 / 控制(06)。 |
| 任务记忆 | 一单任务的会话历史 = 消息历史 + 引擎事件流,同轴按时间全序;只追加;续跑、审计、回放的依据与蒸馏源(08)。 |
| 活动记忆 | 关于一个活动的跨实例持久事实,四层结构,为优化业务模型而设计;记忆不载权力(08)。 |
| 放行 | 人对任务成果的落地裁决:放行通过 / 驳回重做 / 驳回迭代;完成只出自放行通过——落地预检过关才发卡,放行即落地,落地收敛终态方成(05 / 7.3 / 09)。 |
| 对话流 / 视图区 | 工作台-任务的交互结构:对话流是唯一回环输入口;视图区是只读呈现容器,内容由后端流控推送(09)。 |
交互层只有两个面:工作台面向员工,治理台面向组织的管理者。面上零业务逻辑——呈现的一切都来自下层的事实与投影。
工作台是员工的责任面:它回答「现在哪些事等我、我裁过什么、与我相关的发生了什么、我们沉淀了什么、我干了什么」。员工不需要在系统里"找工作干"——责任被系统推到工作台上,员工被动响应;主动动作只有一类:维护纪要。
| 要素 | 性质 | 内容 |
|---|---|---|
| 任务 | 责任 · 被动响应 | 一个活动(标准活动或案例活动)的一次运行,落到恰一名负责人的工作台 |
| 审批 | 责任 · 被动响应 | 工作流中的审批点,卡到审批人工位:通过 / 驳回,附依据 |
| 消息 | 信息 · 被动响应 | 系统通知与跨任务征答:通知(承载触发器的邮件和消息、一般公告、提醒与告警)+ 他人任务发来的人类工具卡(以系统消息送达,就地作答,2.1) |
| 纪要 | 团队主动维护上传 | 会议纪要等团队沉淀;决议可经登记触发转为工作流的启动(3.1)——登记人即来源 |
| 汇报 | 自动 | 按日、周、月、年自动总结此员工的工作汇报——由本人各任务的任务日志聚合生成(8.1),确认即提交,零手工汇报 |
治理台功能清单九项——每一项对应架构中的一件,治理台由此覆盖全部五层:
| 功能 | 管什么 | 对应 |
|---|---|---|
| 任务管理 | 运行态:任务与工作流(两级运行时实例)的在途监控、干预与控制(叫停 / 暂停 / 终止,即控制事件,06);查看任意任务的任务日志(8.1);改派——在途任务与待答卡片的负责人 / 审批人变更,改派留痕并通知双方 | 引擎 · 流程层 |
| 员工管理 | 员工、岗位、权限——权限按岗位授予:客体三类(数据:域.对象[.字段] / 治理功能 / 任务),动作三种(读 / 写 / 治理);任务负责人与被征答人对所涉内容天然可见;停用前置检查——员工停用前,其在途任务与待答卡须先改派完毕 | 基座 · 数据 |
| 工作流管理 | 设计态:流程包的五要素编排(03)与版本;编排即定契约——画完工作流图可导出活动开发的依赖文件(11) | 流程层 · 基座 · 流程包 |
| 触发器配置 | 触发器的创建、配置与启停——定义调用工作流的时机(周期规则与事件规则);触发器与工作流平级、不属于工作流,不随流程包版本;触发器 = 流程层的系统级事件监听(06),经调用接口调起流程包 | 流程层 · 基座(系统自持) |
| 活动库管理 | 活动包的安装、卸载、版本并存与引用查询——独立入口(11);库内按业务分类(一级,组织自定)× 活动类型(标准 / 案例)两维管理,两维平级、相互独立 | 基座 · 活动库 |
| 工具管理 | 工具包注册、白名单与授权、账号 / 密钥 / endpoint 配置 | 调用层 · 基座 · 工具箱 |
| 数据管理 | 主数据、共享对象目录、台账治理(脱敏、保留期、权限) | 基座 · 数据与台账 |
| 记忆管理 | 任务记忆归档与活动记忆库的治理 | 基座 · 记忆 |
| 系统管理 | 系统配置,含 LLM 实例(创建自定义名称模型:Provider(开发支持的厂商枚举)/ URL / API-Key / Model name;活动以名称声明引用)、通道实例(邮箱、IM 接入;归属键提取规则与默认认领岗位,6.2)与系统用途模型绑定(系统自身的 LLM 消耗点——叙述性小结、汇报生成、蒸馏钩子——绑定专用模型实例与预算,计量入系统账、不占活动预算)管理 | 引擎 · 调用层 |
治理动作本身留痕入事件流——治理也被治理。
流程包 = 调用接口 + 两种活动 + 审批点 + 两种网关的流程编排;工作流 = 流程包的运行时实例。包与实例两级对称:流程包 → 工作流,活动 → 任务——包在库,实例在跑。
编排层的基础要素有五:活动(声明)、审批、网关、触发器、流程包——活动、审批、网关是流程包内的节点要素,触发器与流程包是平级的顶层要素;治理台的编排就在这五种要素上进行。其中活动以声明入流:编排引用的是活动库中已安装的活动,安装与卸载走活动库的独立入口(11),不在编排中发生。
| 构件 | 职责 | 要点 |
|---|---|---|
| 调用接口 | 流程包的唯一出入口 | 声明输入契约与输出声明;触发器与上游系统一律经此调起;流程包声明显式终点,工作流完成时末端输出载荷按输出声明交付、按来源回执——登记人收消息回执,上游系统收回调 |
| 活动(两种) | 责任单元 | 标准活动(flow)与案例活动(loop);节点以声明引用活动库中已安装的活动,恰有一名负责人;任务 = 活动的运行时实例——活动被调起的一次运行即一单任务 |
| 审批点(通用) | 工作流级的人裁节点 | 功能属性四件:审批岗位(复用负责人四策略解析)· 输入装配映射(审批人所见载荷,复用边机制)· 驳回走向(声明式:回指定节点重开新实例(带载荷映射)/ 终止,不由临场决定)· 催办阶梯(时限机制复用:提醒 → 升级) |
| 网关(两种) | 路由 | 并行(AND:分叉与汇合)与异或(XOR:条件路由,判定依据入事件记录);条件声明式、静态可检,不得内嵌自由逻辑 |
边与载荷映射:连线即映射,画图即校验,不闭合不得发布。流程包的每条边携带输入装配映射——上游输出口载荷字段 / 流程变量 / 起单载荷 / 常量 → 下游活动契约的 data 字段,允许 S-FEEL 表达式做转换;与触发器的字段映射同一形式(3.1)。编排画布强制契约前后约束:连一条边即须完成该边映射(编排器就地给出上游载荷与下游必填字段的对照,必填未映射 = 边未完成),类型兼容依两端契约 schema 当场校验;存在未完成边、未满足必填或类型冲突的流程包可存草稿、不得发布。两种连线情形同受此约束:引用已安装活动,对活动库中的契约校验;新活动(未开发),契约的输入输出在编排中就地定义、随边成形——依赖文件的输入输出声明由此生成(11.1)。AND 汇合后的同名字段必须显式指定来源分支,不做隐式合并;message 由编排声明模板(可插值载荷字段),缺省为空。
负责人与审批人解析:编排声明岗位,起单时确定性解析。活动节点与审批点声明岗位与解析策略,策略封闭四选:指定人(直接绑定员工,慎用)/ 岗位唯一人 / 轮值(岗内以在途任务数最少者优先)/ 来源跟随(复用同一工作流内该岗位已解析出的人,保持一单一人的连续)。默认:岗位唯一人;岗上多人时按轮值。解析发生在节点起单时,结果与依据留痕;岗位空缺按该节点的失败走向处置,或转治理台待指派;运行中变更走治理台改派(02)。
失败走向:每个活动节点可声明,封闭四选,默认终止流。节点以非完成终态结束(受阻、熔断、耗尽等)时,按其声明的失败走向处置:终止流(默认)——工作流转「异常」,通知治理台 · 任务管理,人工处置;改道——声明一条备选边(失败载荷 = 终态、原因码与说明,备选边同带载荷映射);升审批——失败落到指定审批点,由审批人裁决:重开新任务实例 / 改道 / 终止流;容忍(仅限 AND 分支)——显式声明该分支失败不阻汇合,静态校验其下游映射不得依赖该分支的必填字段。流程层不自动重试活动(过程内重试归 Harness);流级重做一律是人裁决后重开新任务实例——同一节点、新任务 ID、留痕关联,不复活旧任务。
触发器 = 基于周期、事件或登记触发的工作流启动调用。在统一事件标准下,触发器就是流程层的系统级事件监听(06):消费同一条事件流,动作是起单。三类:周期触发——再分两型:日历型(纯日历规则:对账日、周报周期)与数据日历型(按台账日期字段 + 偏移 + 过滤条件逐行起单,如「合同到期前 N 天」;同一行同一日期只触发一次,字段值变更后可再触发);事件触发(通道入站命中规则、台账数据事件);登记触发——人工起单的统一形态:登记人选择流程包、按调用接口 schema 填写输入(表单由 schema 自动渲染)、提交即起单;纪要决议转起单即经登记触发。
触发器输入装配——事件触发的触发器配置含声明式字段映射:事件信封与载荷字段 → 调用接口的 data 字段;缺必填字段则起单失败、入死信。周期触发以规则求值结果装配;登记触发以登记表单为输入。
触发器与工作流是平级概念。触发器的配置定义的是调用工作流的时机——它不属于工作流:不入流程包结构,不随流程包版本,配置与启停在治理台独立进行(02),配置存于基座的系统自持存储(11)。触发器只负责「起单」,经调用接口调起流程包、生成一条工作流;流程包与活动内部不含任何触发逻辑。同一个流程包可以被多个触发器调起,同一个触发器也只知道调用接口、不知流程内部;触发器的增删启停不改流程包的任何版本。凡单必有来源:每条工作流的来源可追溯——触发器即来源;纪要登记起单的,登记人即来源。
声明条件的表达语言——系统侧一切声明式条件(XOR 网关条件、触发器事件规则、监听过滤条件)统一采用 FEEL 表达式子集(S-FEEL):比较、逻辑、算术、字符串与日期函数,无外部调用,静态可检。求值输入:网关处 = 流转载荷与流程变量;触发器处 = 事件信封与载荷字段;监听处 = 事件信封与载荷字段。周期规则 = 日历表达式 + 日历偏移(支持「日期字段 − N 天」式)。节点间的载荷映射与触发器字段映射同一形式(03 边与载荷映射)。
工作流引擎 = 流程引擎 + 活动基座。
活动基座对所有活动同一份。活动在系统外开发时,面对的就是这六件的接口;安装进来,跑在同一副基座上:
| 构件 | 内容 | 职责 |
|---|---|---|
| 契约 | 契约七件:输入(data + message)· 输出口(必发 / 选择)· 必交付物 · 验收判据(分级标注:L1 形式校验 / L2 机检 / L3 抽验 / L4 独立评审 / L5 人放行,不得谎报等级)· 禁区 · 授权边界 · 资源声明 | 活动对外的全部承诺;两种范式同一契约格式——"统一套执行契约"的锚点;《活动模型》自开发视角展开同一份七件清单 |
| 交互 | 工作台-任务的对话流 + 视图区容器 | 交互的结构骨架:对话流是任务的人机时间线、一切回环输入的唯一入口;视图区是活动渲染的只读呈现容器——结构归基座,内容归活动。控制权共同持有、按态转交:活动激活时归活动(视图流控与对话输出由活动驱动),流程流转时归系统(流转、审批与终态呈现由系统驱动);输入侧不转交,永远走系统单入口 |
| 记忆 | 任务记忆 + 活动记忆 | 任务记忆 = 会话历史(消息历史 + 引擎事件流,同轴按时间全序),框架自动记录、只追加;活动侧唯一接口 = 窗口配置(每次 LLM 调用加载多少轮)。活动记忆 = 结构化记忆,基座只提供存与取,结构归活动侧,为优化业务模型而设计(08) |
| 数据(台账) | 「数据域.数据对象.字段」三级寻址 + 通用事务性接口 | 活动对数据与台账的一切操作按数据域.数据对象.字段声明寻址;数据库提供通用事务性接口(增删改查与事务,对所有活动同一套);安装时系统检查数据表,依活动声明自生长。声明语义:声明的是活动要用什么字段,不是对象该定义什么字段——对象的实际 schema = 全部使用声明的最大化合并(并集);定义只增不破坏:声明永不缩表、不删改已有字段,清理归档是数据管理的治理动作、不经声明发生(11)。同名字段类型不一致时,以能兼容双方的最宽类型落地(放宽即增,不破坏),静态审提示、不阻塞;语义互斥不可兼容的极端情形才拦下,交数据管理裁决。运行中的写入落任务级草稿层,放行时合并入正式版(09) |
| 工具(调用契约) | 白名单工具的调用契约 | 活动只经调用契约使用工具;系统调用、LLM 工具、人类工具与通道皆以工具形态自调用层供给(07),功能工具经工具箱注册;授权在白名单与契约,不在活动代码 |
| LLM 调用(模型) | 声明自定义模型名称 | 活动侧只声明自定义的模型名称(逻辑名);名称在系统侧创建与绑定——Provider(系统通过开发支持的厂商枚举)/ URL / API-Key / Model name 四元配置(治理台 · 系统管理,02);活动不触厂商与密钥;模型与版本记入留痕,行为可归因 |
预算与熔断由活动基座在环外强制执行——活动仅在 Harness 配置中申报参数,不自查自守。计量口径:步 = loop 的一次决策循环 / flow 的一个声明步;token = LLM 调用出入 token 累计;时长 = 活跃时长(Agent 机制运行与工具执行的时间;挂起、监听等待、待卡回传不计入——熔断不误杀等待中的任务;时限阶梯另用日历时长,06);调人次数按卡计。任一项越限,基座抛控制事件并挂起任务,处置归治理台 · 任务管理(02)。
完成由框架裁定,终态由系统命名——任务终态是封闭枚举,五名:
| 终态 | 语义 | 触发者 |
|---|---|---|
| 放行完成 | 唯一成功终态:放行通过且落地收敛,输出口已发射 | 放行卡 + 落地执行(7.3) |
| 受阻待人 | 无法推进,封卷待治理处置——处置 = 改派 / 重开新实例 / 终止 | Agent 机制申报,或治理台判定 |
| 停滞熔断 | 停滞检测触发:该动未动、超限仍无推进 | 预算执行器(04) |
| 预算耗尽 | 步数 / token / 活跃时长 / 调人次数任一越限 | 预算执行器(04) |
| 被终止 | 控制事件 · 终止,含工作流终止的级联(06) | 治理台 / 负责人 |
不是终态:驳回(重做 / 迭代)是环内回转,任务继续;叫停是控制事件,挂起待恢复;落地受阻是运行态(7.3)。非完成终态触发节点的失败走向(03);终态分布入度量(8.3)。
两种活动的 Agent 机制范式不同——Case 是 loop(装载 CMMN + DMN 临场演绎),SOP 是 flow(按声明步序照谱执行)——但统一套执行契约:活动基座的六件对两种范式完全一致。差异被压缩到唯一一处:Agent 机制的范式与业务模型的形态。对流程层与交互层而言,两种活动不可区分地是"一个节点、一单任务"。
| 对象 | 调度权 | 形态 |
|---|---|---|
| 工作流(流程层) | 系统 | 流程引擎照结构流转:路由、汇合、审批点推进,零 LLM |
| flow 范式活动 | 系统 | 引擎照声明步序推进,零临场调度 |
| loop 范式活动 | AI | Agent 机制在业务模型的结构上临场决断下一步 |
| 放行(处处) | 人 | 任务完成只出自放行通过(05);流程节点间裁决归审批人 |
活动过程中对人的调用,收敛为四种人类工具。定位上它们与 LLM 工具同列——都是调用层的内置工具(07):AI 在环内调用人,与调用任何工具同构,经调用契约、受白名单与授权约束;差别只在通道与时延——人类工具经对话流到达人(卡片),回传异步。这正是本系统的出发点:人在环是一种被调用的工具——何时调、调哪种,loop 里由 AI 临场判定,flow 里由步序声明给定;人不驱动过程,人被过程调用。卡片结构与回传协议归系统,内容由活动填充。
| 工具 | AI 输出(卡面) | 人回传 |
|---|---|---|
| 决策 | 分支条件选择表:可选分支、各自条件与后果、依据快照、AI 建议 | 选定分支,可附理由 |
| 执行 | 作业指导书 + 结果回填表格:做什么、怎么做、完成标准 | 按表回填结果,凭证随附 |
| 补全 | 补全需求 + 回填表格:缺什么、为何需要、格式要求 | 按表回填 |
| 放行 | 成果清单 + 放行选择表:交付物、验收判据与依据 | 三选一:放行通过 / 驳回重做 / 驳回迭代,驳回必附意见 |
活动以事件监听声明它对外界的一切依赖,系统按统一事件标准投递。监听是接口的契约:活动只声明"听什么、听到了怎么办";挂起、恢复、路由、去重全部归系统。
| 信封字段 | 内容 |
|---|---|
| 事件 ID | 全局唯一,幂等键——重复投递可去重 |
| 类型 | 四类之一(下表) |
| 关联 | 消费目标:目标类型 + 目标 ID(任务 / 触发器 / 工作流 / 消息收件岗位);起因:数据对象 / 卡 ID / 定时器 ID |
| 载荷 | schema 化内容,附原件指针(如邮件原文的存档地址) |
| 时间与来源 | 发生时刻 · 来源(通道 / 引擎 / 工位 / 治理台) |
| 留痕指针 | 事件存储位置(先持久后投递);投递入任务后另记任务记忆指针——事件流与记忆同轴;无任务目标的事件仅有存储位 |
| 类型 | 内容 | 例 |
|---|---|---|
| 数据事件 | 任务相关数据对象的写入与变更;环外回音(邮件、人工代收)经归属解析归一为数据写入后,以数据事件抛出——活动认数据,不认通道;数据事件只由正式版写入产生(系统写与放行写,09),草稿写不抛事件 | 客户回信已写入台账,附原件指针 |
| 时间事件 | 定时器到点:监听时限、约定时点、周期检查 | 等待第 3 天未回,时限事件 |
| 人事件 | 人类工具卡的回传到达(05),与负责人的主动输入——对话流自由输入:写入任务记忆,loop 作为观察,不驱动 flow 步 | 放行卡回传:驳回迭代 + 意见;负责人留言「客户来电改期」 |
| 控制事件 | 治理台与负责人的指令,三种语义:暂停 = 可恢复冻结(监听与时限停摆)· 叫停 = 负责人紧急中断(挂起并记最重档纠正,恢复归负责人)· 终止 = 不可恢复关闭——工作流终止级联:在途任务终止、待答卡与征答消息作废、审批点撤卡 | 负责人叫停 |
通道入站(邮件、IM)到统一事件流之间,由归属解析完成路由。解析依据是通道实例配置中的归属键提取规则(声明式):会话 / 线程 ID、往来地址、正文模式(如单号正则)。匹配次序确定、逐级短路:
提取失败或歧义一律降级为无主——宁交人,不错投;无主入站的"相关人" = 通道实例配置的默认认领岗位(治理台 · 系统管理)。有主入站归一为数据写入——写入目标由通道实例配置的载荷映射给定(提取字段 → 域.对象.字段,与边映射同一形式),原件存档为附件对象,以数据事件抛出。有主 ≠ 必须唤醒:归属解析命中的任务,事件一律写入其任务数据与任务记忆(记录);是否推进由监听命中决定——零命中时仅记录,不降级为无主、不入消息兜底(它有主,只是当下无人等它;loop 在后续观察窗口内自然可见)。消息兜底只针对无主事件。
监听声明——活动声明监听,两种立法:静态(随业务模型:loop 的前提条件、flow 的步完成条件)与动态(运行中由 Agent 机制临场登记,如发出报价邮件后登记"等回信"监听)。每条监听 = 过滤条件(事件类型 + 关联键,条件用 S-FEEL,03)+ 处理语义(loop:事件即观察;flow:事件即步的完成条件)+ 时限(必配:到期抛时间事件——无死等,无来源又无时限的监听安装时拒绝)。
投递语义——系统侧五条承诺:
一条事件流,三级消费:任务监听(推进旧单)与触发器(起单规则,开新单)相互独立判定——同一事件可既推进旧单又起新单;消息是兜底:仅当既无监听命中亦无触发命中时,入站事件落相关人的消息要素(02,人工认领 / 代收)。触发器由此获得统一定义:流程层的系统级事件监听——监听同一条事件流,消费动作是"经调用接口调起流程包、生成新工作流"。
系统调用、LLM 工具、人类工具以及通道在调用层。调用层是一切能力的注册与授权之地;能力以工具形态、经活动基座的「工具(调用契约)」供给活动(04):
调用层四类是供给形态——皆以工具形态经调用契约供给活动;按开发与固化形态,工具分三来处:
| 来处 | 机制 | 治理 |
|---|---|---|
| 功能工具 | 系统调用类能力的交付形态:按需开发的业务能力,是独立开发的代码包——经基座的工具箱注册进系统(11),入白名单;账号、密钥与 endpoint 配置随工具归组织;工具包规范见 7.3 | 先系统、后活动;活动只声明引用其调用契约 |
| LLM 工具 · 人类工具 | 固化在系统里,随系统迭代而更新;声明即用 | 白名单授权;模型实例与工位由治理台配置 |
| 纯工具 | 无外效应(计算、转换、操作自持台账),可随活动包自带 | 安装时注册进工具表、经运行时调用而留痕,不得内联绕过 |
ERP / CRM 等存量系统:事实源永远在外,以外部系统调用接入——注册在工具箱与白名单上的调用接口,读 = 快照留痕,写 = 过放行;不做库对库同步,不搬事实源。无存量系统承载的对象,以台账声明物化承载,数据资产随运行沉淀——混合是常态:按对象逐个选择「调用接入」或「声明物化」,活动只依赖调用契约与共享对象目录,不依赖任何具体事实源。
权力边界在此收拢:能力在调用层(注册、白名单、授权),方法在活动内(技能)。技能基于工具、在活动内定义,载方法不载权力——不能扩大任何授权,只沉淀"怎么用好"(《活动模型》)。
一个功能工具以一个工具包交付:独立开发的代码包,经工具箱注册进系统。工具承载权力,约束严于活动包,三面分离:契约对活动,实现对系统,凭证对治理台。
| 构成 | 内容 |
|---|---|
| 调用契约 (对活动的唯一暴露面) | 工具名(全局唯一逻辑名)· 描述(面向 AI 的适用说明:何时用、语义、边界)· 入参 / 出参 schema · 效应等级(读 / 写) · 错误约定(结构化错误码 + 可重试标志)· 幂等性声明 · 超时与重试默认值 |
| 实现 | server 侧执行代码;运行时受限——只可访问注册申报的连接目标,无其他环境能力 |
| 连接配置声明 | endpoint / 账号 / 密钥的键(值不入包):注册时在治理台绑定值,可按环境绑定不同实例——与 LLM 实例的名称间接层同构 |
| 契约测试集 | 样例入参 → 期望出参形状;注册试运行审与回归的依据 |
四件构成合成工具包的包清单(manifest),与活动包清单同构(11.1);注册两审:静态审读清单,试运行审验代码。
效应等级决定运行时待遇:
一单任务的智能有两个来源:这一单里发生过什么(任务记忆),与这类事历来是什么样(活动记忆)。框架站在环内一切调用的必经之路上——记录不靠自觉,靠位置。
任务记忆 = 会话历史:消息历史 + 引擎事件流,同轴合流、按时间全序——Agent 机制的观察、思考、动作、结果逐条原生,引擎的流转、投递、门与卡裁决逐条结构化。四条性质(必须):
职能四:续跑(挂起恢复时由此重建上下文——记忆在,环可断可续)、审计(发生了什么)、回放(换个办法,这单会不会成)、蒸馏源(活动记忆的唯一原料)。生命周期:随单生、只追加长、终态封卷归档(基座 · 记忆,11)。
基座接口最小:任务记忆由框架自动记录,活动侧唯一可配置项是窗口大小——每次 LLM 调用加载多少轮会话历史;窗口之外的历史不进上下文,但完整在库——续跑、审计与回放永远对全量记录进行。
任务日志:任务记忆的两级投影。日志不是另一份记录——做事与留痕是同一个动作,不存在补写日志;任务日志由任务记忆按需生成:
消费方:工作台「汇报」按日 / 周 / 月 / 年聚合各任务日志(02);放行卡与审批点的过程摘要取自任务日志;治理台 · 任务管理可查看任意任务的任务日志(02);对话流时间线与日志同源、不同筛选。治理约束:投影不得比源暴露更多——日志继承任务记忆的治理标记,按读者权限裁剪生成。
活动记忆是关于这个活动(事类)的持久事实,跨全部任务实例累积——结构化记忆:基座只提供存与取(条目的写入与检索),不解释语义;结构归活动侧,标准由《活动模型》规定。结构为迭代而设计——每类条目对准一个模型作用面:
| 层 | 存什么 | 优化谁 |
|---|---|---|
| 事实层 | 环境与对手方的稳定事实:端点脾性、对手方节奏(客户均值 3 天回信)、术语与实体档案 | 校准监听时限、判断阈值、DMN 输入项 |
| 模式层 | 路径统计:动作启用频次与共现序列、阶段耗时分布、技能组合效果 | 候选业务模型结构增量(阶段重组、新前提、新里程碑) |
| 裁决层 | 纠正沉淀:每次驳回(重做 / 迭代)、叫停与裁决理由,归纳为一般化陈述 | 候选新前提条件、收紧验收判据、DMN 新规则行 |
| 例外层 | 反例与禁忌:已知失败形态、边界案例、「此处留人」标记 | 规则适用边界、负向条件、技能适用描述修正 |
| 指标 | 定义 | 读法 |
|---|---|---|
| 自主率 | 机器产出 ÷(机器产出 + 人产出);裁决与等待不进分母 | 第一指标:AI 自主完成工作的比例 |
| 纠正率 | 按提交批次计:每次放行提交 = 一个产出批次;驳回重做 / 驳回迭代 / 叫停 / 裁决推翻记该批纠正;纠正率 = 被纠正批次 ÷ 提交批次 | 第二指标:自主的质;与自主率成对读——单看任一都会被优化坏 |
| 有效自主率 | 自主率 ×(1 − 纠正率) | 「AI 越多越确定」的可测判据 |
| 打扰率 | 每单任务调用人类工具的次数(四卡合计) | 应随资产成熟而下降;人环的带宽成本 |
| 断点率 | loop 中因"当下可为与目标所需交集为空"而调人或立监听的频次占比 | 断点聚类是业务模型迭代的首要线索 |
| DMN 覆盖率 | 确定性求值(DMN 与机检)占判断次数的比例 | 「临场搬进确定」的进度表 |
| 单位成本 | 总消耗(token / 时长 / 调人)÷ 放行通过的任务数 | 环是否真在产出 |
| 终态分布 | 五个终态的占比(名录见 4.3) | 非完成终态偏高 = 契约或资产有缺陷 |
计量单位:归侧条目。产出以任务记忆的归侧条目计(机器产出 / 人产出各按其条目数);条目粒度随活动而异但活动内恒定——指标的主用途是同一活动的纵向趋势(口径自洽);跨活动横比仅在同业务分类内作参考,不作考核。口径全部挂在归侧标签与事件流上——零埋点,统计即查询;指标异动是进化的扳机:纠正聚类指向活动记忆的裁决层,断点聚类指向业务模型的结构层,蒸馏候选增量走治理管线(11)。
系统是 web + server。分界原则一句话:过程在后端,呈现在 web;放行是草稿态与事实态之间的门。
| 侧 | 承载 |
|---|---|
| web 侧 | 呈现与输入面:工作台五要素的呈现、对话流(卡片输入,唯一回环入口)、视图区(渲染后端推送的 HTML)、治理台界面。零活动代码、零过程逻辑 |
| server 侧 | 活动过程集中在后端——Agent 机制的推进、LLM 调用与 LLM 工具、过程草拟(活动自设的工作区)、视图流控(AI 以 HTML 模版组织视图、推送 web)· 流程引擎(工作流流转、审批点、网关)· 触发器与通道 · 系统调用的执行 · 基座存放 |
活动过程集中在后端,带来两条直接性质:环不依赖浏览器在线——负责人关掉页面,活动照常推进,任务挂起、事件补投与断点续跑天然成立(06);web 是纯呈现与输入面——视图由后端流控推送,输入经对话流卡片回传,浏览器端不落过程状态。
落后端系统的动作集中在活动放行时:过程产物无论在活动的工作区里怎么草拟都是草稿态,不碰台账与外部系统;放行前有落地预检(检查可落地才允许放行,7.3),放行一刻动作落到事实——写台账、调外部系统、提交交付物;落地收敛,输出口才发射。「箱内自由,出箱有门」的边界因此是逻辑的而非物理的:门立在草稿态与事实态之间(草稿 → 台账 / 外部系统),与草稿箱的具体形态无关。任务记忆与留痕随过程持续归档,不受门限。
写分三类。①系统写——入站归一、流转记录、留痕:登记的是世界已发生的事实,不过放行门,写入正式版并即时产生数据事件;②草稿写——任务运行中,活动对自持域台账的写入落在台账的任务级草稿层(读己之写:本任务可见、正式版不可见、不产生数据事件)——过程工作区的数据形态即此草稿层;③放行写——放行通过,草稿层合并入正式版、外部动作意向执行(7.3),此刻才产生数据事件;共享域写一律走放行,契约预授权的即时写是显式列举的例外。环内推进读任务视图 = 正式版 + 本任务草稿层,不依赖事件;跨任务监听只认正式版事件——别的任务只见你放行后的事实,这是「箱内自由,出箱有门」的数据语义。
草稿持久,断点可续。草稿层与动作意向持久于 server 的系统自持存储——关闭页面、断线、隔天再开都不丢;没有「保存」动作,写即持久。任务做一半的续跑由三份持久状态共同保证:任务记忆(会话历史,按窗口重建上下文,08)、草稿层(截至断点的全部过程产物与动作意向)、运行时实例状态(loop 的模型定位与就绪集 / flow 的步序位置,11)。过程在后端:「打开任务」只是打开呈现,不是启动过程——过程要么在跑,要么挂起在等(人 / 事件 / 恢复指令);事件到达或人回传即按投递续跑(06),人打开工作台看到的永远是当前状态的投影。
两条轴把系统切成四象限:物理轴(web / server,09)与归属轴(系统 / 活动)。边界清楚,双方才能各自迭代:系统不为业务改一行,活动不越笼子半步。
| 系统供给(笼子,本卷) | 活动定义(内容,《活动模型》) |
|---|---|
| 活动基座六件:契约格式 · 交互结构(对话流 + 视图区容器)· 记忆系统 · 数据(「数据域.数据对象.字段」三级寻址 + 通用事务性接口,安装时依声明自生长)· 工具调用契约 · LLM 调用(04) | 契约内容(七件):输入(data + message)/ 输出口(必发 / 选择)/ 必交付物 / 验收判据(分级标注)/ 禁区 / 授权边界 / 资源声明(4.1) |
| 人类工具四卡的模式与回传协议(05) | 范式选择:loop 或 flow(04) |
| 统一事件标准:信封 · 四类事件 · 归属解析 · 投递五诺(06) | 业务模型:CMMN + DMN 或步序声明(04) |
| 调用层四类:系统调用 · LLM 工具 · 人类工具 · 通道;白名单与授权;工具箱(07) | 交互内容:视图模版 · 卡内容 schema · 汇报组织(04 / 09) |
| 放行门:草稿态 → 事实态的落地时机与协议(09) | 技能清单(基于工具,载方法不载权力)与监听声明(静态 + 动态,时限必配)(06 / 07) |
| 流程层(流程包 / 工作流 · 审批点 · 网关 · 触发器)· 预算执行器(环外强制,04) | Harness 参数申报:停止条件 · 预算 · 时限 · 恢复——执行归系统(04) |
| 基座六项存放 · 治理台九功能 · web 呈现容器(11 / 02 / 09) | 过程工作区(自设)· 纯工具 · 台账 schema(声明物化)· 蒸馏钩子(04 / 08) |
本表与《活动模型》0.2 镜像同表(行数、行序、措辞一一对应,括号内章号各随本卷)——左列是系统的承诺,右列是活动的申报;边界线即活动基座六件的接口。
基座 = 数据、台账、记忆、工具箱、活动库、流程包。基座是存放层,只存事实、记录、能力与工件,零业务逻辑——与活动基座(04)不同物:活动基座是运行时的通用模式(宿主),本章基座是存放(库房)。
| 构件 | 内容 |
|---|---|
| 数据 | 主数据:员工、岗位、权限、共享对象目录 |
| 台账 | 活动声明的业务数据表与台账:schema 声明、宿主物化、统一治理(脱敏、保留期、权限) |
| 记忆 | 记忆系统的存放:任务记忆的归档库(单单封卷)与活动记忆库(跨单持久)(08) |
| 工具箱 | 功能工具之库,独立的开发与注册入口:工具是独立开发的代码包,由此注册进调用层、入白名单;账号、密钥与 endpoint 配置随工具管理,版本并存;活动以调用契约引用 |
| 活动库 | 已安装活动之库,独立的安装与卸载入口:活动包(系统外开发,含业务模型与技能初始版)由此进出,版本并存;库内按业务分类(一级,组织自定)× 活动类型(标准 / 案例)两维管理,两维平级、相互独立;每活动两条版本序列:包版本 × 资产版本(11.3);编排层以声明引用库中活动 |
| 流程包 | 治理台在系统内编排的结构定义,版本化存放;工作流 = 流程包的运行时实例 |
一切运行都能在基座找到出处:其事实在数据与台账,其记录在记忆,其能力在工具箱,其定义在活动库与流程包。
持久层两分:系统自持 × 活动自生长。基座的一切持久存储按归属分两类:
| 归属 | 存什么 | schema 谁定 · 怎么变 |
|---|---|---|
| 系统自持 | 主数据 · 共享对象目录 · 记忆存放(任务记忆归档库、活动记忆库)· 事件存储(统一事件流,"先持久后投递"的底座,06)· 运行时实例(工作流与任务的状态与投影)· 触发器配置(调用工作流的时机规则,独立于流程包)· 工具箱注册表(工具、白名单、密钥与 endpoint)· 活动库与流程包(定义与版本) | 系统 schema,随系统版本迭代、系统自带迁移;活动不可写结构,只经接口读写被允许的内容 |
| 活动自生长 | 业务台账与数据表:活动以「数据域.数据对象.字段」声明 | 使用声明的最大化合并,只增不破坏(版本升级声明多了就长、少了不缩,无迁移);数据随事类不随包版本,在途照旧 |
两条补充口径:共享对象 = 共享域的台账,不是第三类外装件——各活动声明各自要用的字段,对象 schema 按最大化合并自生长(首个声明创建、后续声明并入);目录只是数据管理的视图,写授权按域.对象在契约申报、白名单核准——箱只有两个(工具箱、活动库),数据不设箱、数据靠域;过程草稿(工作区,即台账的任务级草稿层与动作意向,09)是任务范围的暂存——持久于系统自持存储(断线不丢稿,写即持久)但非事实:放行前不落台账正式版与外部系统,放行时合并落地,随任务终态封卷处理。
工作流编排先于活动开发——编排工作流的过程,就是定义活动契约的过程。闭环五步:
契约不是活动开发者单方申报,而是编排给定、开发实现、安装校核——工作流图是契约的母体,三方共读同一份声明。
包清单(manifest):包的自述文件。活动包 = 包清单 + 代码产物(.JS)+ 资产文件;清单机器可读,系统不执行代码即知包为何物——导入登记、安装静态审、编排装配读的都是清单。清单六区:
| 区 | 内容 |
|---|---|
| 身份 | 活动名(全局唯一)· 包版本 · 业务分类 · 活动类型(loop / flow)· SDK 版本 · 签名与校验和 |
| 契约 | 契约七件,声明形式(4.1) |
| 声明 | 模型声明(自定义模型名)· 工具声明(调用契约引用 + 版本约束)· 台账与共享域使用声明(域.对象.字段)· 静态监听声明 · Harness 配置 |
| 资产初始版 | 业务模型(CMMN + 说明书 / 步序声明)· DMN · 技能 · 视图模版 · 卡 schema |
| 样例集 | 样例输入 → 期望输出口与载荷形状;首装审与回归依据(11.2) |
| 代码入口 | .JS 产物的入口与校验和 |
依赖文件即清单骨架——编排导出定其契约区与声明区,开发补代码与资产,编译合成完整清单;静态审审清单,试运行验代码。工具包同构:身份 + 调用契约 + 连接配置声明 + 契约测试集 + 代码入口(7.3)。
外装件两类、两个独立入口:活动包经活动库安装卸载,工具包经工具箱注册——都不在编排中发生。安装检查两道:静态审(签名、无动态执行、SDK 兼容、所需调用契约与角色齐备、schema 校验)与回放审。安装恒为新增、版本并存;在途任务按其启动时版本跑完,切换零丢单;生效 / 停用 / 卸载由治理台管理。
回放审 = 确定性断言重跑。新版本对历史任务记忆重演其中可确定判定的部分:契约 schema 校验、业务模型静态检查、DMN 决策表对历史输入重算、监听过滤与时限求值、纯工具重跑——比对新旧版结论。LLM 步不重推理:以历史出入参作录制回放,仅校验历史出参对新版 schema 的兼容;人的回传与外部世界的响应一律取历史录制值;写类动作只校验动作意向的构造,不执行。判定口径:「旧成不坏」是生效硬门——历史成功单在新版下断言全过,方可生效;「旧败能成」(历史失败单中新版断言可拦住者)为报告参考项,列入重演报告、不作门槛;无历史失败单天然通过。首次安装无历史:免回放审,以静态审 + 样例集替代(样例集为包清单一区,11.1)。
形态类比小程序:业务装在系统里,以活动包交付——装一个新业务 = 装一个小程序,底座不为它改一行;界面容器、身份权限、记忆与卡片全由系统供给,包内无越权代码;上架有审,上线下线随时可控,包与包互不干扰,在途的单照常办完。
资产与包分离版本化。活动库对每个活动维护两条版本序列,各有各的门、各自单写者:包版本管代码、契约、交互模版、Harness 声明——变更必须系统外重编,走安装两审(11.2);资产版本管业务模型、DMN 与技能——活动包只携初始版(安装时播种入库),此后的资产新版由本节的进化管线在系统内产生(回放 + 人放行),不重编包、不重签名。任务装载 = 包版本 + 各资产当前生效版,全部入信封,行为可归因;包新版携带的资产初始版不覆盖已有更高的资产版——覆盖只能是显式的资产回退治理动作。