流程承载框架:将传统工作流升级为智能体业务流程管理——CUGA FLO 设计与实现

流程承载框架:将传统工作流升级为智能体业务流程管理------CUGA FLO 设计与实现

原文链接https://arxiv.org/html/2606.27188v1

摘要

本文提出流程承载框架(Process Harness),一种无需替换底层工作流引擎、即可将传统遗留工作流升级为智能体业务流程管理(Agentic BPM)的全新机制。流程承载框架在确定性工作流引擎外层搭建一套受策略约束的智能体层,拦截流程指定控制点并提供推理、自适应与流程监管能力,同时保留引擎对流程结构的管控权限。

为严格定义流程承载框架,本文构建任务-决策-流(TDF)模型,完整定义其数据范式与执行语义。TDF将大模型推理能力拆分为三类受策略管控的智能体:

  1. 任务智能体(TaskAgent):处理知识密集型任务执行;
  2. 决策智能体(DecisionAgent):基于业务实例完成网关路由;
  3. 流程智能体(FlowAgent):通过标准化钩子机制实现运行时流程自适应。

所有智能体均依托流程总策略集FRAME 开展推理,该集合约束系统内全部大模型调用行为。本文基于TDF模型落地实现CUGA FLO系统,并以贷款审批工作流为案例完整验证三类智能体与钩子驱动的监管覆盖逻辑。

流程承载框架同时满足两类流程约束:

  • 命令式约束:由确定性工作流执行保障流程结构合规;
  • 规范式约束:在指定控制点调用受策略限制的智能体自主推理。

1 引言

1.1 传统BPM两大核心缺陷

大模型与智能体框架推动企业业务流程自动化体系重构。传统BPM系统经过数十年迭代,可提供严格的流程结构保障,但缺少开放式推理与突发场景自适应能力,企业只能依靠人工介入处理异常,催生大量流程变通行为。传统流程存在两大固有短板:

  1. 封闭世界假设:所有流程分支、异常必须在设计阶段提前建模;遇到监管变更、新型业务申请、外部系统故障等未预设场景时,引擎只能报错并转交人工处理,未编码的场景无法自动化处理。
  2. 任务执行僵化:自动化任务由固定脚本执行,无法适配非结构化、模糊输入;人工任务具备灵活判断能力,但大规模部署时吞吐量低、执行波动大。

1.2 现有AI流程方案的矛盾

  1. AI增强BPM:仅在单一任务嵌入大模型,流程拓扑完全固定,无法在运行时调整流转逻辑;
  2. 大模型作为规划器:大模型读取BPMN流程生成执行计划,但脱离流程引擎管控,无法保证流程合规、审计追溯、策略约束。

1.3 智能体BPM:规范式+命令式双重需求

智能体BPM白皮书提出:流程系统需同时承载命令式需求 (固定流程拓扑、强制结构合规)与规范式需求(策略约束下的智能自主推理)。

  • 规范层(FRAME):整套策略文档,约束所有大模型推理行为;
  • 命令层:BPMN可执行流程图,由工作流引擎编译并强制运行。

系统包含三层独立管控智能体,配套第二层权限管控机制access_permissions,限制流程智能体可执行的流程修改操作。

1.4 CUGA基础框架介绍

CUGA(可配置通用智能体)是开源企业级智能体承载框架,支持网页/API复杂任务、OpenAPI/MCP协议集成、可组合架构、策略感知能力。核心组件:

  1. CugaAgent:核心执行单元,按需触发规划、工具筛选、上下文摘要,全程绑定策略与记忆;
  2. CugaSupervisor:复杂任务编排层,向下委派子智能体、打通多智能体数据交互。
    CUGA FLO基于CUGA原生能力构建,三类流程智能体均封装CugaAgent实例,并统一向上对接CugaSupervisor。

1.5 智能体BPM的业务价值

企业真实业务流程存在长尾场景:高频标准流程可由传统BPM自动化,低频特殊场景全部依赖人工。CUGA FLO通过策略钩子统一处理长尾场景,无需修改流程模型;同时支持渐进式改造传统工作流,三层自主能力可单独启停,改造可逆。

1.6 本文五大核心贡献

C1. 提出流程承载框架 范式,三大核心特性:结构合规、策略可追溯、运行时自适应,区别于传统BPM与纯大模型规划方案;

C2. 提出TDF任务-决策-流模型 ,将大模型推理拆分为任务、决策、流程三类智能体;

C3. 实例化FRAME总策略集,按三类智能体拆分策略,实现大模型推理层面关注点分离;

C4. 实现CUGA FLO系统,基于钩子机制完成运行时流程自适应,通过MCP桥接层解耦推理层与可替换工作流引擎;

C5. 以贷款审批流程完成全流程案例验证,覆盖三类智能体与监管拦截钩子。

2 流程承载框架范式

2.1 定义

定义1:流程承载框架是一套基于TDF模型的智能体层,包裹在确定性工作流引擎外部。在不改动底层流程语义的前提下,通过受限自主推理、流程干预、运行时自适应,将传统遗留工作流升级为智能体BPM。

2.2 两大底层原则(源自智能体BPM白皮书)

  1. 流程感知:智能体触发时可完整获取流程模型、当前执行状态、历史步骤,推理基于真实流程上下文;
  2. 策略约束(Framing):所有智能体基于人类可读的显式策略推理,行为可控、无黑盒。

2.3 三层可组合智能自主能力(每层可独立开关)

流程引擎到达预设控制点时暂停执行,调用承载框架对应智能体,接收推理结果后恢复流程。三层能力逐级提升自主程度:

层级 智能体类型 能力说明
1级 TaskAgent 任务委托:用受策略管控的大模型脚本替代硬编码脚本,处理知识密集型任务
2级 DecisionAgent 路由委托:网关分支不再使用静态规则,由大模型结合实例上下文完成路由决策
3级 FlowAgent 流程自适应:拦截流程连线,基于钩子策略生成流程结构性干预(跳转、增删节点、终止流程等)

2.4 核心运行机制

  1. 流程拓扑所有权归底层WorkflowEngine,承载框架仅在控制点调用智能体,不修改流程基础图;
  2. 所有大模型推理调用均绑定可读策略;
  3. 流程知识(模型、状态、执行轨迹)在引擎与承载框架间双向同步,保证智能体具备完整流程感知;
  4. 区别于传统异常处理:传统异常需提前建模,框架钩子属于开放世界适配层,仅需更新策略文档即可处理新场景,无需修改BPMN流程文件。

2.5 方案定位对比

二维评估维度:结构合规性、运行时自适应能力

  1. 传统BPM:高合规、低自适应;
  2. 纯LLM规划器:低合规、高自适应;
  3. CUGA FLO流程承载框架:高合规+高自适应。

3 任务-决策-流(TDF)模型

TDF模型将大模型推理职责分配至三类独立智能体,分别绑定流程节点/连线,配套专属FRAME策略,统一封装底层流程承载框架。

3.1 TDF数据范式

3.1.1 基础流程图定义

流程模型为有向图 Pm=(V,E)P_m=(V,E)Pm=(V,E)

  • VVV:流程节点集合;EEE:节点间有向流程连线集合;支持循环拓扑;
    节点细分:
    V=Vstart∪Vend∪T∪Gsplit∪GjoinV=V_{start}\cup V_{end}\cup T\cup G_{split}\cup G_{join}V=Vstart∪Vend∪T∪Gsplit∪Gjoin
  • VstartV_{start}Vstart:起始节点;VendV_{end}Vend:结束节点;
  • TTT:任务节点;
  • GsplitG_{split}Gsplit:分支网关(条件分支/并行分支);
  • GjoinG_{join}Gjoin:合并网关。
  1. 任务节点 t∈Tt\in Tt∈T:绑定目标语句集合、属性集合,执行输出会更新节点属性值;
  2. 条件分支网关 g∈Gsplitcondg\in G_{split}^{cond}g∈Gsplitcond:绑定一组逻辑条件命题,命题结果决定分支走向。
3.1.2 流程全局知识 P=(Pm,Ps,Ph)P=(P_m,P_s,P_h)P=(Pm,Ps,Ph)
  1. PmP_mPm:流程拓扑图;
  2. PsP_sPs:流程状态映射,记录每个任务执行状态:pending/active/hold/completed/halted
  3. PhP_hPh:有序执行轨迹,记录所有已执行节点。
3.1.3 TDF整体元组

针对单流程知识PPP,TDF承载框架定义为:

TDFP=(TAs,DAs,FAs)\mathbf{TDF}_{P}=(TAs,DAs,FAs)TDFP=(TAs,DAs,FAs)

  • TAsTAsTAs:任务智能体集合;DAsDAsDAs:决策智能体集合;FAsFAsFAs:流程智能体集合。
(1)任务智能体定义

a=(t,CT,P,Ts,λ)a=(t,C_T,P,Ts,\lambda)a=(t,CT,P,Ts,λ)

  • ttt:绑定的任务节点;CTC_TCT:任务策略集;PPP:流程全局知识;TsTsTs:可用工具集;λ\lambdaλ:底层LLM推理循环(感知-推理-执行);
    评价标准:策略合规、领域输出准确。
(2)决策智能体定义

d=(g,CD,P,Ts∪{cond_eval},λ)d=(g,C_D,P,Ts\cup\{cond\_eval\},\lambda)d=(g,CD,P,Ts∪{cond_eval},λ)

  • ggg:绑定条件分支网关;CDC_DCD:决策策略集;内置强制工具cond_eval(预计算网关静态条件);
    执行规范:必须先确定性计算网关条件,再执行大模型路由推理;
    评价标准:路由结果确定、分支选择准确。
(3)流程智能体定义

f=(H,Is,ϕ,CF(hk),P,Ts,μ,λ)f=(H,Is,\phi,C_F(h_k),P,Ts,\mu,\lambda)f=(H,Is,ϕ,CF(hk),P,Ts,μ,λ)

  • HHH:钩子连线集合;IsIsIs:流程干预原语集合;
  • ϕ\phiϕ:权限管控函数,区分允许/禁止的干预操作;
  • CF(hk)C_F(h_k)CF(hk):单钩子专属策略;μ\muμ:节点映射函数(任务/网关绑定对应智能体);
    干预原语:继续执行、跳过节点、跳转至指定节点、交换节点、终止流程、删除节点、新增节点;
    评价标准:FRAME策略合规、所有干预行为可审计。
(4)底层LLM推理循环λ\lambdaλ

λ=(M,Ts,sense,reason,act)\lambda=(M,Ts,sense,reason,act)λ=(M,Ts,sense,reason,act)

MMM:智能体记忆;sensesensesense:感知上下文;reasonreasonreason:推理;actactact:执行工具/输出结果;内置ask_user工具支持智能体主动向用户索取输入。

3.2 TDF执行语义

所有智能体统一执行感知-推理-执行循环,输入两类核心上下文:流程感知信息(命令层)、策略约束(规范层)。

3.2.1 任务智能体执行逻辑
  1. 感知:加载流程知识+任务策略至智能体记忆;
  2. 推理:基于任务目标、可用工具生成执行方案;
  3. 执行 :运行方案,输出任务属性结果 αt\alpha_tαt;
    核心职责:将任务目标、上下文转化为可执行方案并输出业务结果。
3.2.2 决策智能体执行逻辑
  1. 感知:加载流程知识与网关决策策略;
  2. 强制前置步骤 :调用cond_eval确定性计算网关原始条件,存入记忆;
  3. 推理:结合条件结果、流程上下文、策略筛选合法分支;
  4. 执行 :输出选中的分支集合RgR_gRg;
    核心职责:在网关节点提供受管控、基于前置条件的分支路由。
3.2.3 流程智能体执行逻辑

两类触发场景:

  1. 钩子拦截触发:流程走到带钩子连线时,基于钩子策略生成干预动作;
  2. 任务/网关回调触发 :通过映射函数μ\muμ委派对应TaskAgent/DecisionAgent执行。

干预校验流程:

  1. LLM推理生成候选干预ifi_fif;
  2. 权限函数ϕ\phiϕ二次校验:仅permitted动作下发引擎,prohibited替换为默认安全动作(继续执行);
  3. 下发合法干预指令ifi_fif至引擎落地。
3.2.4 双层治理架构
  1. FRAME策略层 :约束LLM可推理、可输出的内容;
    F=⋃{CT(ti)}∪{CD(dj)}∪{CF(hk)}\mathcal{F}=\bigcup\{C_T(t_i)\}\cup\{C_D(d_j)\}\cup\{C_F(h_k)\}F=⋃{CT(ti)}∪{CD(dj)}∪{CF(hk)}
  2. 访问权限ϕ\phiϕ层 :独立于策略,管控引擎实际可执行的流程修改操作;
    两层策略均可动态更新,即时作用于后续流程实例。

4 CUGA FLO系统架构

CUGA FLO基于Python库实现TDF模型,核心设计:推理层与流程执行层完全解耦,通过MCPFlowBridge桥接通信,底层工作流引擎可任意替换。

4.1 整体架构总览

  1. 推理侧:FlowAgent(顶层元智能体),内置TaskAgent、DecisionAgent子智能体,全部受FRAME策略管控;
  2. 通信层:MCPFlowBridge(FastMCP服务),唯一交互通道;
  3. 执行侧:可插拔WorkflowEngine,持有BPMN流程模型、驱动实例执行;
  4. 共享数据结构:ControlPointFlowKnowledge,存储全量流程状态;
  5. 上层调度:CugaSupervisor,统一封装invoke()对外调用接口。

桥接层四大MCP工具(推理侧注册):

  • execute_task:触发任务智能体;
  • route_gateway:触发决策智能体;
  • evaluate_hook:触发钩子流程干预;
  • get_static_config:引擎启动时拉取流程静态配置。

引擎侧工具:run_process,用于启动新流程实例。

4.2 FlowAgent:流程感知元智能体

核心定位

全局唯一具备流程结构修改权限的智能体,拥有完整全局流程视图,可读取全部未执行节点信息,用于预判干预行为的后续影响。不持有流程拓扑,拓扑完全由WorkflowEngine管理

钩子机制(运行时自适应核心)

钩子绑定在流程连线上,引擎走到该连线时暂停并调用FlowAgent推理。钩子策略约束7类干预原语:

干预动作 拓扑变更效果 语义说明
continue 无变更 遵循原始流程流转
skip_node 跳过紧邻下一个节点 下节点标记为跳过,直接流向后继
skip_to 跳转至任意未执行任务 绕过中间全部节点,支持跨多步跳转
swap_nodes 交换两个节点执行顺序 调换两个待执行节点先后顺序
terminate 强制终止流程实例 流程直接关闭,不再执行剩余节点
remove_node 从拓扑移除节点 引擎重连该节点前后连线,永久跳过
add_node 插入新任务节点 在当前目标前新增任务,引擎重布线
关注点分离:指令层 vs 执行层
  • CUGA FLO仅输出干预指令;
  • WorkflowEngine负责落地拓扑修改、流程跳转;
  • action_permissions配置文件显式声明每个流程允许/禁止的干预类型,作为第二层强管控。

4.3 DecisionAgent:策略管控路由智能体

绑定条件分支网关,两段式路由逻辑:

  1. 确定性条件预计算:解析网关原始条件表达式,绑定流程变量求值,得到基础分支结果;
  2. LLM策略推理:结合预计算结果、流程全局知识、网关决策策略,筛选最终合法分支ID并输出。

4.4 TaskAgent:策略约束任务执行智能体

绑定单一业务任务,启动时接收三类输入:

  1. 任务目标描述;
  2. 专属任务策略CTC_TCT(约束输出边界、禁止行为、领域规范);
  3. ControlPointFlowKnowledge完整流程上下文。

智能体可调用CUGA工具库、MCP远端工具,自主规划工具调用链路,输出结构化业务结果同步至流程变量。

4.5 ControlPointFlowKnowledge:共享流程观测数据

引擎每次回调推理层时传递该序列化结构体,包含:

  1. 控制点标识:元素ID、名称;
  2. 控制点专属上下文:任务指令/可用分支/钩子连线ID;
  3. FlowState全量快照:流程变量、执行轨迹、各任务输出、网关决策审计记录、流程终止标记;
    所有智能体数据交互依托该结构,智能体之间无直接通信。

4.6 MCP桥接层与工作流引擎

MCPFlowBridge

基于Model Context Protocol标准实现FastMCP服务,作为推理层与执行层唯一契约,实现引擎无感知替换。所有调用携带完整流程快照,推理层无状态。

WorkflowEngine抽象接口

定义标准化集成API,官方提供基础实现LangGraphWorkflowEngine(将BPMN转为LangGraph状态图),生产环境可替换Camunda、Flowable等商用引擎。

运行时序
  1. 构建阶段 :引擎调用get_static_config拉取流程配置,编译流程拓扑;
  2. 执行循环:每到达任务/网关/钩子控制点,引擎通过桥接调用对应推理工具,接收干预结果更新流程状态,继续执行。

4.7 应用部署规范

CUGA FLO应用为独立目录,分为config/policies/两大文件夹。

config/ 配置目录
  1. BPMN流程文件:定义业务流程拓扑;
  2. 应用主配置<app>_config.yaml(核心字段):
    • flow:流程名称、版本、BPMN路径、FlowAgent类型;
    • variables:全局流程变量初始值;
    • tasks:每个任务配置执行模式(native/task_agent)、工具、策略文件路径;
    • gateways:网关配置、原始条件、决策策略路径;
    • action_permissions:本流程允许/禁止的钩子干预动作;
    • hooks:钩子ID、绑定连线、钩子策略文件路径;
    • llm:全局大模型参数覆盖。
  3. 调度器配置supervisor_<app>.yaml:配置CugaSupervisor,绑定多个FlowAgent实例,提供对话交互入口。
policies/ 策略目录

存放全部FRAME策略文档(Markdown格式,可版本管理、热更新),命名规范:

  • task-xxx.md:任务策略;
  • decision-xxx.md:网关决策策略;
  • hook-xxx.md:钩子干预策略;
    策略更新后,后续所有流程推理自动生效,无需重启服务。

5 案例研究:贷款审批工作流

完整覆盖三类TDF智能体+监管拦截钩子,验证系统全能力。

5.1 流程总览(BPMN结构)

流程节点:

  1. 任务节点:信用评估(TaskAgent)、放款处理、拒绝通知;
  2. XOR条件分支网关:基于信用分路由;
  3. 钩子:绑定审批分支连线audit_credit(FlowAgent监管拦截);
    流转逻辑:
  • 信用评估输出信用分→网关判断:分数>0.6走审批分支,否则拒绝;
  • 审批分支触发监管钩子,特殊客户ID 4321强制跳转拒绝流程。

5.2 FRAME策略实例

5.2.1 任务策略:信用评估
  1. 基于5类维度计算标准化信用分0,1:还款历史35%、债务收入比30%、信用历史长度15%、信贷类型10%、近期查询10%;
  2. 必须输出credit_score变量;
  3. 硬性约束:不得输出审批/拒绝结论,决策权归属网关。
5.2.2 决策策略:信用网关
  1. 基础阈值:credit_score>0.6走审批分支;
  2. 大额贷款重写规则:贷款金额>50000,阈值提升至0.75;
  3. 输出唯一合法分支ID,不可多分支。
5.2.3 钩子策略:监管拦截
  1. 强制规则:申请人ID=4321触发监管限制,执行skip_to跳转拒绝节点;
  2. 同步更新变量:rejection_reason="regulatory_policy_restriction"policy_override_active=true
  3. 其余客户默认continue正常流转。
5.2.4 结果处理任务策略
  1. 放款任务:仅在审批标记为true时执行,禁止发起拒绝流程;
  2. 拒绝通知任务:区分普通低分拒绝、监管拦截拒绝,监管场景不得展示信用分数。

5.3 部署文件结构

config/
  1. BPMNdiagram.bpmn:完整流程拓扑;
  2. loan_approval_config.yaml:声明3个任务智能体、1个决策网关智能体、1条监管钩子;权限配置:允许continue/skip_to/terminate,禁止swap_nodes/skip_node;
  3. supervisor_loan_approval.yaml:调度器配置,注册贷款流程FlowAgent。
policies/ 5份策略文档

task-credit_check.md、decision-credit_decision.md、hook-audit_credit_decision.md、task-loan_processor.md、task-rejection_handler.md。

5.4 FlowAgent实例化代码逻辑

python 复制代码
loan_flow_agent = FlowAgent(process_key="loan_approval_v1")

实例化执行流程:

  1. 调用桥接接口拉取流程配置;
  2. 批量初始化3个TaskAgent、1个DecisionAgent、监管钩子;
  3. 加载权限配置、全局变量;
  4. 合并网关不绑定智能体,由引擎原生执行。

5.5 两条完整执行轨迹

场景1:标准客户(ID=23,信用分0.6625)
  1. TaskAgent信用评估:输出credit_score=0.6625
  2. DecisionAgent预计算0.6625>0.6,选中审批分支;
  3. 钩子推理:无监管规则,执行continue;
  4. 放款TaskAgent完成审批,标记loan_granted=true
场景2:监管拦截客户(ID=4321,信用分0.82)
  1. TaskAgent信用评估:输出credit_score=0.82
  2. DecisionAgent判定满足审批分支条件;
  3. 钩子触发监管规则,执行skip_to跳转拒绝节点,写入监管拒绝原因;
  4. 拒绝任务智能体生成监管合规拒绝通知,不展示信用分数。

6 相关工作对比

6.1 技术演进脉络

  1. AI增强BPM:仅在局部任务嵌入AI,流程拓扑固定;
  2. 智能体BPM白皮书:提出智能体作为一等流程实体,但无落地实现;
  3. CUGA FLO:首个完整落地流程承载框架,分层拆解智能体职责,配套形式化TDF模型。

6.2 主流方案横向对比

评估特性 传统BPM LLM规划器 ReAct/AutoGen多智能体 通用智能工作流 CUGA FLO(TDF)
强制流程图合规 仅输入参考 × 开发者自定义 ✓(引擎强制)
结构一致性保障 × × 自定义
运行时自适应 ×
人类可读策略管控 × × × ×
策略可追溯审计 × × 隐式 隐式
逐节点审计日志 × × ×
设计时异常分支 × × × 可选
开放世界动态异常 ×
可复现执行轨迹 × × ×
非程序员可配置 × × × 部分支持

6.3 核心差异化分析

  1. 对比传统BPM异常处理
    传统方案所有异常分支必须在BPMN建模,修改流程需要版本发布;CUGA FLO钩子基于策略文档动态处理无限场景,更新策略即时生效,无需改动流程拓扑。
  2. 对比LLM-as-Planner
    大模型规划器以流程为输入,动态生成执行路径,无强制合规约束;CUGA FLO引擎固定流程拓扑,所有自适应仅在策略允许范围内修改,每条干预完整审计留痕,执行轨迹可稳定复现。
  3. 对比通用智能工作流
    通用动态工作流基于大模型实时编排步骤,无固定流程模型、无合规审计;CUGA FLO以企业标准化BPMN为底层底座,智能体仅作为上层增强层,满足金融、政务等强监管场景需求。

7 讨论与结论

7.1 流程承载框架创新点

  1. 全新流程插桩机制:不替换现有工作流引擎,通过控制点拦截注入策略化智能推理,平衡流程刚性与业务柔性;
  2. TDF模型分层解耦三类智能体,任务、路由、流程全局干预职责隔离;
  3. FRAME全局策略集提供完整审计溯源能力,所有大模型调用绑定可读策略,解决黑盒问题;
  4. 基于MCP协议解耦推理与执行,引擎可无缝替换,适配企业现有BPM资产。

7.2 局限性与未来工作

  1. 流程拓扑覆盖
    当前钩子仅支持流程连线绑定,后续计划支持中间事件、子流程分层FlowAgent;已执行节点不支持删除/修改,未来将探索跨实例流程模型动态同步。
  2. 钩子性能与策略编写成本
    每条钩子遍历均触发LLM推理,存在时延开销;优化方向:状态缓存、轻量前置分类器过滤无意义推理;
    策略冲突检测缺失,后续开发FRAME静态校验工具,自动识别多策略矛盾。
  3. 智能体行为合规性
    框架提供完整策略上下文,但无法从底层保证LLM推理严格遵循策略;未来引入神经符号推理,提供形式化策略合规证明。

7.3 全文总结

本文提出流程承载框架 ,配套形式化TDF任务-决策-流模型,并落地CUGA FLO系统,解决传统遗留工作流升级为智能体BPM的核心痛点。

核心设计思想:结构化流程执行与开放式智能推理不存在固有冲突,通过FlowAgent全局管控、钩子机制实现安全的运行时流程调整;MCP桥接层彻底解耦推理与执行引擎,兼顾现有系统资产复用。

TDF三层智能体分工清晰:

  1. TaskAgent:在策略约束下调用工具完成业务任务;
  2. DecisionAgent:先确定性计算网关条件,再通过LLM完成路由决策;
  3. FlowAgent:顶层元智能体,依托钩子策略执行流程结构性干预,配套双层权限管控。

FRAME总策略集实现全链路可审计,每条大模型调用均绑定可人工阅读的策略文档,快速定位行为偏差。流程承载框架为企业AI流程自动化提供全新插桩式方案,同时保留传统BPM的合规、审计、稳定优势。

资源附录

  1. 论文原文地址:https://arxiv.org/html/2606.27188v1
  2. CUGA FLO开源代码仓库:https://github.com/cuga-project/cuga-agent/tree/cugaflo/src/cuga/backend/cuga_graph/nodes/cuga_flow
  3. MCP协议标准:https://modelcontextprotocol.io
  4. 主流商用BPM引擎参考
  5. 开源基础CUGA智能体框架:https://github.com/cuga-project/cuga-agent
  6. 开源协议:CC BY 4.0