万字长文解析企业级Super Agent工程方案

Codebee2026-07-08 17:11

流程定义与实例的二元结构、六层上下文模型、语义感知的分裂合并、可信回退与历史恢复、LLM增强压缩引擎、知识飞轮闭环 ------ 构建面向企业级复杂场景的Agent工程体系

​

架构设计 · 2026

核心挑战架构哲学理论根基与模式融合六层上下文分裂与合并可信回退压缩引擎知识飞轮统一VFS多引擎协作总结展望

1. Super Agent的核心挑战

构建一个能够处理企业级复杂业务流程的Super Agent，面临的核心挑战并非模型能力本身，而在于如何让Agent在长周期、多节点、多分支的流程中保持上下文一致性 、决策可追溯性 和知识连续性。这些挑战直接决定了系统设计的架构走向。

1.1 上下文膨胀与污染

在多轮对话与多节点流转中，LLM的上下文窗口会快速被历史消息填满。更为严重的是上下文污染 ：不同业务活动的中间状态、临时变量、错误重试信息混杂在一起，导致LLM无法区分当前决策所需的有效上下文 与已完成节点的残留信息。

核心矛盾上下文窗口是有限的共享资源，不加治理的上下文注入等同于全局变量污染 ------ 随着流程复杂度增长，Agent行为将变得不可预测。

具体表现为：

  • Token浪费：已完成活动的详细工作区数据持续占用窗口，压缩可用推理空间
  • 注意力稀释：LLM在无关历史信息上分配注意力权重，降低关键决策的准确性
  • 幻觉加剧：跨活动的信息交叉引用导致LLM产生不存在于当前活动中的"记忆"

1.2 多轮对话连贯性断裂

流程中的活动流转本质上是一种结构化的上下文切换。当Agent从活动A流转到活动B时，需要：

  1. 保留A的关键产出作为B的输入
  2. 切换B的工作区上下文
  3. 维护流程级别的共享状态

但传统的对话式Agent缺乏流程语义，无法自动完成这种结构化切换，导致：

  • 流转时丢失关键中间结果
  • 新活动无法获取前驱活动的决策依据
  • 回退到历史活动时无法恢复当时的上下文状态

1.3 知识生产与消费脱节

Agent在流程执行中会产生大量有价值的知识（如业务规则、决策逻辑、异常处理经验），但这些知识往往随着活动的结束而丢弃，未能形成知识沉淀→复用→增强的闭环。具体表现为：

  • 生产侧：活动产出的结构化数据未提取为可复用知识
  • 入库侧：流程归档时未将活动级知识聚合到流程级
  • 消费侧：新活动执行前未按scope优先级注入相关知识
  • 反馈侧：未比较知识预测与实际结果以更新置信度

设计洞察 三大挑战的本质是同一个问题：缺乏流程感知的上下文治理机制。解决之道不是简单地扩大上下文窗口或增加记忆模块，而是引入流程驱动的架构范式，让上下文的生命周期与流程节点的生命周期对齐。

2. 流程驱动的架构哲学

流程驱动架构的核心思想是：流程定义 描述"应该怎样做"（静态蓝图），流程实例记录"实际怎样做了"（动态轨迹）。二者的分离使得Agent的行为可以被预测、被追溯、被恢复。

2.1 流程定义与实例的二元结构

维度 流程定义 (ProcessDefinition) 流程实例 (ProcessInstance)
本质 静态蓝图，描述节点与转移条件 动态轨迹，记录状态与数据
生命周期 设计时确定，部署后不变 运行时创建，完成后归档
数据特征 节点定义、转移规则、角色映射 当前节点、历史路径、上下文快照
可复制性 一个定义可创建多个实例 每个实例独立
持久化策略 版本管理，不可变 增量保存，可回溯

这种二元结构直接映射到代码层面：ProcessDefinition是编译时常量，ProcessInstance是运行时变量。所有上下文治理机制都围绕"实例"展开 ------ 因为只有实例才拥有状态变迁的历史。

2.2 本地运算优先 + 远程持久化的职责划分

在分布式Agent系统中，每次决策都依赖远程调用会引入不可接受的延迟。因此采用本地运算优先 原则：所有需要实时决策的逻辑（条件计算、路由决策、上下文编排）在客户端执行，只有必须持久化的状态变更才通过RemoteWorkflowBridge同步到服务端。

2.3 RemoteWorkflowBridge的设计原则

RemoteWorkflowBridge作为客户端与服务端之间的唯一通道，承担三个核心职责：

  1. syncState()：将客户端计算的流程状态变更同步到服务端，确保状态一致性
  2. persistData()：将需要持久化的业务数据通过VFS写入服务端存储
  3. restoreSnap()：从服务端恢复历史快照到客户端，支持回退场景

Bridge的设计遵循最少传输原则 ：只传输增量变更而非全量数据。例如，syncState()只传输{from: activityA, to: activityB, timestamp: ...}，而非整个流程实例的JSON。

架构收益 本地运算优先 + Bridge增量同步 =毫秒级决策延迟 +秒级持久化保障。Agent的实时决策完全不受网络波动影响，同时关键状态的持久化由服务端保证ACID特性。

3. 流程驱动的理论根基与设计模式融合

流程驱动并非凭空而来------它植根于工作流理论、Petri网形式化验证和Actor模型，同时与软件工程中大量成熟的设计模式存在深层共鸣。本节阐述流程驱动范式的理论根基，以及React、Harness、Loop、Hooks、上下文工程、数据飞轮等常见模式如何在流程新范式下被重新诠释与融合。

3.1 流程驱动的理论根基

流程驱动架构建立在三个理论支柱之上：

理论支柱 核心思想 在本方案中的映射
Petri网理论 库所（Place）与变迁（Transition）的二元结构，通过令牌（Token）流动描述系统行为；形式化验证可达性、有界性、活性 Activity = Place，Transition = Route，Context Token = 上下文数据；XOR_SPLIT/AND_JOIN对应Petri网的选择/并行结构
工作流模式 Workflow Patterns（van der Aalst, 2003）定义了43种控制流模式，涵盖顺序、并行、选择、迭代、取消等 AND_SPLIT/AND_JOIN映射同步并行，XOR_SPLIT映射排他选择，BACKWARD映射迭代/补偿，noMatchPolicy映射取消
Actor模型 Hewitt的Actor模型：每个Actor拥有私有状态，通过异步消息通信，无共享可变状态 每个ActivityInstance是独立Actor，WORKING层是私有状态，Transition是异步消息，分裂时深拷贝避免共享可变

关键洞察 流程驱动的独特价值在于它同时提供了结构化控制流 （来自工作流模式）和隔离的状态管理（来自Actor模型），并通过Petri网的形式化语义保证行为的可预测性。这三者的结合使得Agent的行为不再是黑盒------每一步决策的输入、条件、输出都可以被精确追溯。

3.2 React模式：声明式上下文渲染

React的核心思想是UI = f(state)------给定状态，渲染结果是确定的。在流程驱动范式中，这一思想被重新诠释为：

流程驱动的React映射Agent行为 = f(流程状态 × 上下文快照) 给定流程当前节点和上下文快照，Agent的下一步行为是确定的、可重现的。

React概念 流程驱动映射 实现方式
State ContextLayer分层状态 6层上下文模型，SYSTEM/PROCESS为全局状态，WORKING为组件局部状态
Props Transition传递的上下文切片 routeTo时通过分支注入_branch标记，子活动只接收属于自己分支的上下文
Reconciliation 上下文分裂与合并 XOR_SPLIT时"diff"出分支差异（_branch注入），AND_JOIN时"reconcile"合并分支输出
Virtual DOM VFS虚拟文件系统 上下文在VFS中维护虚拟层级，通过writeLayer/readLayer按需加载
Re-render 活动重新执行 routeBack + restoreContext = 重新渲染，从历史快照恢复上下文后重新执行活动
useEffect 活动生命周期钩子 活动执行前的injectKnowledge（pre-effect），执行后的compress + extractKnowledge（post-effect）

最关键的映射是Reconciliation → 上下文合并。React通过diff算法确定最小变更集，流程驱动通过合并策略确定冲突解决方式------不追求全局一致性，而是保留各分支的独立输出到_mergedOutputs，标记冲突到_mergedConflicts，让下游LLM节点基于完整信息做最终裁决。

3.3 Harness模式：结构化测试闭环

Harness（测试线束）模式的核心是为被测系统构建受控的执行环境 ，使得输入可预测、输出可验证。在流程驱动范式中，Harness被提升为生产级机制：

Harness概念 流程驱动映射 设计差异
测试夹具(Fixture) 流程定义(ProcessDefinition) 不是临时测试数据，而是正式部署的流程蓝图
测试用例(TestCase) 流程实例(ProcessInstance) 每个实例是一次完整执行轨迹，可重复、可审计
断言(Assertion) 知识飞轮反馈(Feedback) 从"通过/失败"升级为"置信度评分"，量化知识质量
覆盖(Coverage) 流程分支覆盖率 追踪每个Transition是否被实际路由到，而非代码行覆盖
Mock/Stub 本地运算优先 不需要Mock远程服务------本地运算直接替代远程调用，真实环境下零Mock

流程驱动的Harness闭环体现在三个层次：

  1. 样本级：每个流程实例的执行结果都是"测试用例"，通过知识飞轮反馈自动验证
  2. 场景级：SceneGroup（场景组）定义了一组关联流程的执行模板，等价于测试套件
  3. 集群级：多节点并行执行+VFS远程数据落地验证，等价于集成测试

3.4 Loop模式：迭代收敛与流程退回

Loop（循环）在传统编程中是代码级控制结构，在流程驱动中被提升为流程级语义，拥有完整的生命周期管理：

Loop概念 流程驱动映射 增强能力
for循环 AND_SPLIT + AND_JOIN 并行迭代，每个分支独立执行，汇聚时合并；有完整的上下文隔离
while循环 BACKWARD Transition 条件驱动的退回，带maxRetry上限防止死循环；每次退回从历史快照恢复
break noMatchPolicy = TERMINATE 无路由匹配时终止流程，等价于break退出
continue noMatchPolicy = SKIP 跳过当前活动，等价于continue到下一个迭代
循环变量 _retryCount + _branch 退回次数和分支标识作为上下文变量，参与条件计算
循环不变式 PROCESS层上下文 跨迭代不变的量存储在PROCESS层，WORKING层每次迭代重置

关键差异 传统循环只管理控制流 ，流程驱动的Loop同时管理数据流 和上下文快照 。每次BACKWARD退回都不是简单的指令跳转，而是：恢复历史上下文 → 保留PROCESS层不变量 → 重置WORKING层 → 递增_retryCount → 重新执行。这使得"循环"拥有了完整的审计轨迹和状态恢复能力。

3.5 Hooks模式：生命周期织入

Hooks模式的核心是在不修改核心逻辑的前提下，织入横切关注点 。流程驱动将Hooks提升为流程级生命周期事件，与活动状态机严格对齐：

3.6 上下文工程：从窗口管理到流程治理

上下文工程(Context Engineering)是LLM应用中最核心的工程挑战。传统方案将上下文视为一个扁平的窗口------塞入尽可能多的信息，依赖LLM自行筛选。流程驱动范式将上下文治理提升为流程感知的分层治理：

传统上下文工程 流程驱动上下文工程 本质差异
窗口管理：塞入尽可能多token 分层治理：按生命周期和作用域隔离 从"量"的优化到"质"的治理
RAG检索：按相关性注入文档 知识飞轮：按scope优先级注入知识 从"被动检索"到"主动注入+反馈"
滑动窗口：保留最近N轮对话 压缩引擎：PRESERVE_KEYS + COMPRESS_BLOCKS 从"机械截断"到"语义压缩"
全量上下文：所有活动共享同一Map 六层模型：SYSTEM→PROCESS→KNOWLEDGE→HISTORY→WORKING→EPHEMERAL 从"扁平污染"到"结构化隔离"
对话级上下文：session-scoped 流程级上下文：process-scoped + activity-scoped 从"对话粒度"到"活动粒度"

流程驱动上下文工程的核心公式：

javascript 复制代码 
LLM输入 = buildFullContext(processInstId, activityId)
         = SYSTEM层(系统指令)
         + PROCESS层(流程参数, 不随活动变化)
         + KNOWLEDGE层(按scope注入, 分裂时继承)
         + HISTORY层(历史摘要, LLM增强压缩)
         + WORKING层(当前活动私有数据)
         + EPHEMERAL层(临时变量, 不持久化)

每一层都有独立的写入时机 、读取优先级 和分裂行为，使得上下文不再是不可控的黑盒，而是可预测、可调试、可审计的结构化数据。

3.7 数据飞轮：从单向管道到自增强闭环

数据飞轮(Data Flywheel)模式描述的是数据驱动的自增强系统 ------更多数据 → 更好模型 → 更多用户 → 更多数据。在流程驱动范式中，数据飞轮被具象化为知识飞轮(Knowledge Flywheel)，与流程的生命周期严格绑定：

知识飞轮相比传统数据飞轮的关键增强：

  • 流程绑定：生产阶段绑定活动完成事件，入库阶段绑定流程归档事件，消费阶段绑定活动执行前事件------不再是异步批处理，而是同步实时闭环
  • 反馈验证：传统飞轮只有正向增强（更多数据→更好模型），知识飞轮增加了反向验证（evaluateQuality：预测vs实际，更新置信度）------质量不合格的知识会被降权，避免"脏数据飞轮"
  • Scope治理：知识按global/process/activity三级作用域管理，活动级知识只在同流程内可见，全局知识需达到高置信度阈值才晋升------避免低质量知识污染全局

3.8 模式融合全景

所有模式在流程驱动范式下不再是孤立的"银弹"，而是围绕流程实例的生命周期形成协同：

流程生命周期阶段 激活的模式 协同机制
活动执行前 Hooks(useBeforeExecute) + 上下文工程(KNOWLEDGE注入) Hooks触发injectKnowledge，按scope优先级将知识写入KNOWLEDGE层
活动执行中 React(状态驱动) + Loop(条件退回) WORKING层状态变化驱动LLM响应，BACKWARD路由实现重试循环
活动执行后 Hooks(useAfterExecute) + 数据飞轮(生产) + 上下文工程(压缩) compress压缩WORKING→HISTORY，extractKnowledge提取知识
路由转移 React(Reconciliation) + Harness(断言) 分裂=diff分支，合并=reconcile输出，知识飞轮反馈=断言验证
流程归档 数据飞轮(入库) + Harness(覆盖率) archiveKnowledge聚合活动级知识，Transition覆盖率审计

融合核心 流程驱动不是要替代这些模式，而是为它们提供统一的时间轴 和结构化的挂载点 。React的声明式渲染、Harness的验证闭环、Loop的迭代收敛、Hooks的生命周期织入、上下文工程的分层治理、数据飞轮的自增强------所有模式都以流程实例 为坐标原点，以活动状态为时间刻度，形成协同而非冲突的设计整体。

4. 六层上下文模型

上下文治理的核心问题是如何划分信息的作用域 与生命周期。六层上下文模型将Agent运行时上下文严格分层，每层有明确的持久化策略和分裂行为，从而在流程流转中实现精准的上下文隔离与继承。

4.1 层级定义

层级 名称 作用域 持久化 分裂行为 典型内容
L0 SYSTEM 全局 不持久化（硬编码） 共享，永不分裂 系统指令、安全约束、角色定义
L1 PROCESS 流程级 持久化到流程实例 共享，永不分裂 流程参数、全局变量、审批链
L2 KNOWLEDGE 按scope分级 持久化到知识库 继承（深拷贝引用） 业务规则、领域知识、历史经验
L3 HISTORY 流程级 持久化（压缩后） 合并（多分支摘要聚合） 历史活动摘要、决策记录
L4 WORKING 活动级 按需持久化到VFS 深拷贝 + _branch标记 当前活动工作区、中间变量
L5 EPHEMERAL 会话级 不持久化 不参与分裂 临时计数器、UI状态、缓存标记

4.2 层级间的交互规则

六层模型并非简单的堆栈，层与层之间存在严格的读写权限规则：

操作 SYSTEM PROCESS KNOWLEDGE HISTORY WORKING EPHEMERAL
当前活动读 ✅ ✅ ✅ ✅ ✅ ✅
当前活动写 ❌ ✅ (受限) ❌ (只读) 追加 ✅ ✅
流转时继承 ✅ ✅ ✅ ✅ ❌ (压缩后清除) ❌
回退时恢复 ✅ ✅ ✅ ✅ ✅ (从快照) ❌

设计要点 KNOWLEDGE层对当前活动是只读的 ------ 活动不能直接修改知识，只能通过知识飞轮的Production阶段提取产出，再通过Archive阶段归档入库。这种单向数据流保证了知识的一致性。

5. 语义感知的上下文分裂与合并

流程中的网关节点（XOR_SPLIT / AND_JOIN）触发了上下文的分裂与合并。这并非简单的数据复制，而是语义感知的操作：不同层级的上下文根据其语义特性采取不同的分裂/合并策略。

5.1 XOR_SPLIT分裂策略

当流程到达排他网关（XOR_SPLIT）时，需要为每个分支创建独立的上下文：

javascript 复制代码 
// XOR_SPLIT 分裂伪代码
function splitContext(parentContext, branches) {
  const branchContexts = [];
  for (const branch of branches) {
    const branchCtx = {
      // L0 SYSTEM: 直接共享引用（不可变，无需拷贝）
      SYSTEM: parentContext.SYSTEM,

      // L1 PROCESS: 直接共享引用（流程级，所有分支共享）
      PROCESS: parentContext.PROCESS,

      // L2 KNOWLEDGE: 继承（深拷贝引用，分支可独立消费）
      KNOWLEDGE: deepClone(parentContext.KNOWLEDGE),

      // L3 HISTORY: 共享（历史摘要对所有分支可见）
      HISTORY: parentContext.HISTORY,

      // L4 WORKING: 深拷贝 + _branch注入
      WORKING: {
        ...deepClone(parentContext.WORKING),
        _branch: branch.id,        // 注入分支标识
        _branchOrigin: parentContext.currentActivity,
        _splitTimestamp: Date.now()
      },

      // L5 EPHEMERAL: 不参与分裂（重新初始化）
      EPHEMERAL: {}
    };
    branchContexts.push(branchCtx);
  }
  return branchContexts;
}

关键设计点：

  • _branch标记：每个分支的WORKING层注入唯一的分支ID，确保活动执行时可识别自己所属的分支
  • _branchOrigin：记录分裂来源活动，用于后续合并时追溯
  • KNOWLEDGE层的"继承"是深拷贝引用：分支可以独立消费知识，但不修改原始知识库

5.2 AND_JOIN合并策略

当所有并行分支完成后，汇聚网关（AND_JOIN）将多分支上下文合并：

javascript 复制代码 
// AND_JOIN 合并伪代码
function mergeContexts(branchContexts) {
  const merged = {
    SYSTEM: branchContexts[0].SYSTEM,
    PROCESS: branchContexts[0].PROCESS,
    KNOWLEDGE: branchContexts[0].KNOWLEDGE,

    // HISTORY: 各分支摘要聚合
    HISTORY: aggregateSummaries(
      branchContexts.map(ctx => ctx.HISTORY)
    ),

    // WORKING: 合并策略
    WORKING: {
      _mergedOutputs: {},      // 各分支的输出合集
      _mergedConflicts: [],    // 冲突标记
    },

    EPHEMERAL: {}
  };

  for (const branchCtx of branchContexts) {
    // 收集各分支输出
    merged.WORKING._mergedOutputs[branchCtx.WORKING._branch] =
      extractOutput(branchCtx.WORKING);

    // 冲突检测
    const conflicts = detectConflicts(
      branchCtx.WORKING,
      merged.PROCESS
    );
    if (conflicts.length > 0) {
      merged.WORKING._mergedConflicts.push(...conflicts);
    }
  }

  return merged;
}

5.3 冲突解决的语义层次

冲突并非简单的"后者覆盖前者"，而是根据冲突的语义层次采取不同策略：

冲突类型 检测条件 解决策略 标记
输出互补 各分支写入不同字段 直接合并 无需标记
弱冲突 同字段不同值，但无业务约束 取最新值 + 冲突标记 _mergedConflicts
强冲突 PROCESS层字段被多分支修改 保留两个版本，等待人工裁决 _requiresResolution

6. 可信回退与历史恢复

在流程执行中，回退（routeBack）是常见且关键的操作。与简单的"撤销"不同，流程回退需要完整恢复回退目标节点的上下文状态，包括当时的WORKING层数据、KNOWLEDGE层快照以及PROCESS层的参数状态。

6.1 routeTo时的快照保存

每次routeTo操作（从当前活动流转到下一活动）时，系统自动保存完整的状态快照：

javascript 复制代码 
// routeTo 快照保存
function routeTo(fromActivity, toActivity, processInstance) {
  // 1. 保存当前状态快照
  const snapshot = {
    snapshotId: generateId(),
    processInstanceId: processInstance.id,
    fromActivity: fromActivity.id,
    toActivity: toActivity.id,
    timestamp: Date.now(),

    // 完整上下文快照
    context: {
      PROCESS: deepClone(processInstance.context.PROCESS),
      KNOWLEDGE: deepClone(processInstance.context.KNOWLEDGE),
      HISTORY: deepClone(processInstance.context.HISTORY),
      WORKING: deepClone(processInstance.context.WORKING),
    },

    // VFS数据快照路径
    vfsSnapshotPath: `/process-inst/${processInstance.id}/snapshots/${snapshotId}/`
  };

  // 2. 持久化快照
  vfsSave(snapshot.vfsSnapshotPath, snapshot.context);
  workflowEngine.saveSnapshot(snapshot);

  // 3. 执行流转
  workflowEngine.routeTo(processInstance.id, toActivity.id);
}

6.2 routeBack的三级恢复

回退恢复并非简单的"读取快照并还原"，而是一个三级降级的恢复策略：

6.3 检查点重建的细节

当三级降级到检查点重建时，系统采用最小可用上下文策略：

  1. 从流程级检查点恢复PROCESS层参数（这些参数在流程启动时确定，始终可靠）
  2. 从KNOWLEDGE层的scope快照恢复领域知识
  3. WORKING层无法完整恢复，改为注入_reconstructed: true标记和HISTORY层的摘要，让LLM根据摘要重建工作区
  4. 标记_degradationLevel: 3，提醒下游组件当前上下文为降级重建

降级恢复的权衡 检查点重建的WORKING层是不完整的，LLM需要根据HISTORY摘要重建工作状态。这意味着回退后的首次决策可能不如快照恢复精确，但保证了系统在极端情况下的可用性。

7. LLM增强的上下文压缩引擎

上下文窗口是Agent最珍贵的资源。随着流程推进，历史活动的上下文不断累积，必须通过压缩引擎将已完成的WORKING层数据压缩为HISTORY层摘要，为当前活动释放窗口空间。

7.1 压缩策略：PRESERVE_KEYS vs COMPRESS_BLOCKS

并非所有上下文都值得等量压缩。压缩引擎将WORKING层的键值对分为两类：

策略 含义 处理方式 典型字段
PRESERVE_KEYS 必须保留的关键字段 原样保留到HISTORY层 决策结果、审批意见、关键数值
COMPRESS_BLOCKS 可压缩的数据块 只保留引用标记，内容存入VFS 对话历史、中间计算过程、探索记录
javascript 复制代码 
// 压缩引擎核心逻辑
function compressWorkingToHistory(working, preserveKeys, compressBlocks) {
  const historyEntry = {
    activityId: working._currentActivity,
    timestamp: Date.now(),
    preserved: {},
    compressed: {},
    vfsReferences: {}
  };

  // 1. PRESERVE_KEYS: 原样保留
  for (const key of preserveKeys) {
    if (working[key] !== undefined) {
      historyEntry.preserved[key] = working[key];
    }
  }

  // 2. COMPRESS_BLOCKS: 保留引用，内容存VFS
  for (const key of compressBlocks) {
    if (working[key] !== undefined) {
      const vfsPath = `/process-inst/{id}/compressed/${key}`;
      vfsSave(vfsPath, working[key]);
      historyEntry.compressed[key] = `[compressed→${vfsPath}]`;
      historyEntry.vfsReferences[key] = vfsPath;
    }
  }

  return historyEntry;
}

7.2 多活动HISTORY二次压缩

当流程中存在多个已完成活动时，HISTORY层本身也会膨胀。系统采用二次压缩机制：将多个活动的HISTORY条目聚合为一个流程级摘要，由LLM生成连贯的叙述。

javascript 复制代码 
// 二次压缩
function mergeActivitySummaries(historyEntries, processContext) {
  // 当HISTORY层累计超过阈值时触发
  const totalChars = historyEntries.reduce(
    (sum, e) => sum + JSON.stringify(e).length, 0
  );

  if (totalChars > HISTORY_THRESHOLD) {
    // LLM生成流程级摘要
    const processSummary = await llm.summarize({
      prompt: `基于以下活动摘要，生成流程级概述:
        ${historyEntries.map(e => e.summary).join('\n')}`,
      preservedKeys: ['approvalResult', 'totalAmount'],
    });

    return {
      type: 'PROCESS_SUMMARY',
      summary: processSummary,
      entryCount: historyEntries.length,
      originalSize: totalChars,
      compressedSize: processSummary.length,
    };
  }

  return historyEntries; // 未超阈值，保持原样
}

LLM增强的核心价值 压缩引擎中LLM的角色不仅是"生成摘要"，更是在摘要中保留决策因果链。例如，不是简单地说"审批通过"，而是保留"因金额低于50万阈值且符合采购政策第三条，审批通过" ------ 这种因果保留使得后续活动能够理解前驱决策的依据。

8. 知识飞轮闭环

知识飞轮是整个架构的自增强核心。它确保Agent在流程执行中产生的知识能够被提取、归档、消费和验证，形成正向循环，使得同类流程的执行效率随时间递增。

8.1 四阶段闭环

阶段 触发时机 核心动作 数据流向
Production 活动完成时 从活动产出提取结构化知识 WORKING → 知识候选
Archive 流程归档时 活动级聚合到流程级知识 知识候选 → 知识库
Consumption 活动执行前 按scope优先级注入KNOWLEDGE层 知识库 → KNOWLEDGE层
Feedback 活动完成时 比较预测与实际，更新置信度 KNOWLEDGE层 → 知识库(更新)

8.2 知识的Scope分级与优先级注入

知识按scope分为三级，消费时按优先级注入：

javascript 复制代码 
// 知识注入的scope优先级
function injectKnowledge(activity, knowledgeBase) {
  const scopePriority = [
    'global',     // 全局知识：跨流程通用的业务规则
    'process',    // 流程级知识：当前流程类型的特定知识
    'activity',   // 活动级知识：特定活动类型的知识
  ];

  const injected = {};
  for (const scope of scopePriority) {
    const entries = knowledgeBase.query({
      scope,
      processType: activity.processType,
      activityType: activity.type,
      minConfidence: 0.7,  // 最低置信度阈值
    });

    for (const entry of entries) {
      // 高优先级scope的同名知识覆盖低优先级
      injected[entry.key] = entry.value;
    }
  }

  return injected;
}

8.3 反馈机制与置信度更新

Feedback阶段的核心是比较知识的预测与实际执行结果：

  • 命中：知识预测与实际一致 → 置信度 +0.05，使用计数 +1
  • 偏移：知识预测与实际部分一致 → 置信度 -0.1，标记需更新
  • 失效：知识预测与实际完全不一致 → 置信度 -0.3，标记为待审核

当置信度低于0.5时，知识自动从主动注入列表中移除，避免误导后续活动。

9. 统一VFS虚拟文件系统

VFS（Virtual File System）是Super Agent架构中的统一数据存储抽象。它将分散在三个服务中的文件操作统一为一个一致的路径空间和操作接口。

9.1 三套路径统一

统一前，三套VFS服务各自为政：

原始服务 职责 路径风格 问题
ContextPersistenceService 上下文快照持久化 /ctx/{processId}/{actId} 与流程实例ID不对应
WorkflowExecutionVFSBridge 流程执行数据桥接 /wf/{processId}/data 缺少活动级粒度
ProcessKnowledgeVfsService 知识数据存储 /knowledge/{scope}/{key} 无法按流程实例隔离

统一后，所有操作通过UnifiedVFSManager进行，路径遵循统一的规范：

javascript 复制代码 
// 统一VFS路径规范
const VFS_PATH_SPEC = {
  // 流程实例级
  processRoot:    '/process-inst/{processInstId}/',

  // 活动级
  activityRoot:   '/process-inst/{processInstId}/activities/{activityInstId}/',
  activityWorking:'/process-inst/{processInstId}/activities/{activityInstId}/working',
  activitySnapshot:'/process-inst/{processInstId}/activities/{activityInstId}/snapshot',

  // 知识级
  knowledgeRoot:  '/process-inst/{processInstId}/knowledge/{scope}/',
  knowledgeGlobal:'/process-inst/{processInstId}/knowledge/global/',
  knowledgeProcess:'/process-inst/{processInstId}/knowledge/process/',
  knowledgeActivity:'/process-inst/{processInstId}/knowledge/activity/',

  // 压缩数据
  compressedRoot: '/process-inst/{processInstId}/compressed/',

  // 快照
  snapshotRoot:   '/process-inst/{processInstId}/snapshots/{snapshotId}/',
};

9.2 Folder克隆机制

VFS的Folder克隆机制对齐bpm-web中VFSFileEngine的split/combine/restore操作，直接服务于上下文的分裂与合并：

操作 VFS方法 对应上下文行为 实现细节
分裂 cloneFolder(src, dest, options) XOR_SPLIT时为每个分支克隆WORKING目录 深拷贝文件，注入_branch标记到metadata
合并 combineFolders(sources, dest, strategy) AND_JOIN时合并各分支的output目录 按strategy处理冲突：overwrite/skip/merge
恢复 restoreFolder(snapshot, dest) routeBack时从快照目录恢复 原子替换，失败时回滚

克隆的原子性保证 Folder克隆操作通过两阶段提交保证原子性：先将文件写入临时目录，全部写入成功后原子重命名为目标目录。如果中间任何步骤失败，临时目录被清理，目标目录保持不变。

9.3 VFS路径与六层上下文的映射

统一VFS路径与六层上下文模型之间存在直接映射关系：

  • /activities/{actId}/working/ → L4 WORKING层
  • /activities/{actId}/snapshot/ → routeTo时的WORKING层快照
  • /knowledge/{scope}/ → L2 KNOWLEDGE层
  • /compressed/ → 压缩引擎的COMPRESS_BLOCKS原始数据
  • /snapshots/{snapId}/ → routeTo时的完整上下文快照

10. 多引擎协作架构

Super Agent的流程执行涉及四个独立的引擎，每个引擎负责一个正交的关注点。它们的协作遵循客户端门面模式（Facade Pattern），由WorkflowClientServiceImpl统一对外提供接口。

10.1 四引擎职责划分

引擎 职责 核心API 数据存储
WorkflowEngine 流程状态管理 routeTo / routeBack / completeProcessInst 关系数据库
VFSFileEngine 业务数据管理 save / load / clone / combine / restore 虚拟文件系统
DBDataEngine 表单数据管理 saveFormData / loadFormData / queryData 关系数据库
RightEngine 权限控制 checkPermission / getAuthorizedActivities 权限系统

10.2 routeTo时的多引擎调用时序

当执行routeTo操作时，四个引擎按照严格的顺序协作：

javascript 复制代码 
// WorkflowClientServiceImpl.routeTo()
async function routeTo(processInstId, targetActivityId, context) {
  // 0. 权限检查
  const hasPermission = await rightEngine.checkPermission(
    context.currentUser, targetActivityId, 'ROUTE_TO'
  );
  if (!hasPermission) throw new PermissionDeniedError();

  // 1. 保存当前WORKING层到VFS
  await vfsFileEngine.save(
    `/process-inst/${processInstId}/activities/${context.currentActivity}/working`,
    context.WORKING
  );

  // 2. 保存上下文快照
  const snapshotId = generateId();
  await vfsFileEngine.cloneFolder(
    `/process-inst/${processInstId}/activities/${context.currentActivity}/`,
    `/process-inst/${processInstId}/snapshots/${snapshotId}/`,
    { deep: true, includeMetadata: true }
  );

  // 3. 更新流程状态
  await workflowEngine.routeTo(processInstId, targetActivityId);

  // 4. 压缩当前WORKING到HISTORY
  const historyEntry = await compressEngine.compressWorkingToHistory(
    context.WORKING,
    context.PRESERVE_KEYS,
    context.COMPRESS_BLOCKS
  );
  context.HISTORY.push(historyEntry);

  // 5. 注入目标活动的KNOWLEDGE层
  context.KNOWLEDGE = await knowledgeService.injectKnowledge(
    targetActivityId, knowledgeBase
  );

  // 6. 构建目标活动的WORKING层
  context.WORKING = await contextOrchestrator.buildWorkingContext(
    targetActivityId, context.PROCESS, context.HISTORY
  );

  // 7. 保存表单数据
  await dbDataEngine.saveFormData(processInstId, context.WORKING.formData);

  return context;
}

10.3 客户端门面模式的设计意图

WorkflowClientServiceImpl作为门面，封装了四引擎的协作细节，对外只暴露routeTo、routeBack、completeProcessInst三个高层接口。这种设计的核心价值在于：

  • 一致性保证：门面负责协调多引擎的事务边界，确保流程状态、VFS数据、表单数据的一致性
  • 降级策略：当某个引擎不可用时，门面可以降级到本地替代方案（如VFS不可用时写入本地缓存）
  • 审计追踪：门面在每次操作中记录完整的调用链，支持事后审计

架构收益 四引擎分离 + 门面协调 =关注点分离 +事务一致性。每个引擎可以独立演进、独立测试、独立部署，而门面保证了跨引擎操作的原子性。

11. 总结与展望

11.1 核心设计原则回顾

基于流程闭环的Super Agent工程方案，围绕以下核心设计原则构建：

原则 体现 收益
流程感知 六层上下文模型与流程节点生命周期对齐 上下文治理有章可循
语义感知 分裂/合并/压缩策略按上下文层级语义决定 避免"一刀切"的信息丢失
本地优先 实时决策在客户端执行，只增量同步到服务端 毫秒级决策延迟
可信回退 三级降级恢复 + 完整快照 极端情况下仍可恢复
知识闭环 Production→Archive→Consumption→Feedback 自增强，决策质量递增
统一抽象 UnifiedVFSManager + 客户端门面 降低复杂度，提升可维护性

11.2 架构全景

将所有组件组合在一起，Super Agent的架构全景如下：

架构核心公式流程驱动 × 六层上下文 × 知识飞轮 = 可预测、可追溯、可增强的Agent系统

在这个架构中，每个组件都有明确的职责边界：

  • ContextOrchestrator：六层上下文的组装、分裂、合并
  • CompressEngine：上下文压缩与HISTORY层管理
  • KnowledgeFlywheel：知识的生产、归档、消费、反馈
  • RemoteWorkflowBridge：客户端与服务端的增量同步
  • UnifiedVFSManager：统一的数据存储抽象
  • WorkflowClientServiceImpl：四引擎协作的门面

11.3 展望

本方案奠定了流程驱动Agent的工程基础，未来可在以下方向持续深化：

  • 多模态上下文：将图像、表格等非文本数据纳入六层模型，扩展WORKING层的数据类型
  • 分布式协作：多个Agent实例并行执行同一流程的不同分支，通过Bridge协调上下文
  • 自适应压缩：根据LLM的注意力分布动态调整PRESERVE_KEYS和COMPRESS_BLOCKS的分类规则
  • 知识图谱增强：将知识飞轮的结构化知识构建为图谱，支持更精准的scope匹配和推理链追溯
  • 安全沙箱：为KNOWLEDGE层的知识注入增加安全校验，防止恶意知识注入导致Agent行为偏移

基于流程闭环的Super Agent工程方案 · 架构设计文档

流程驱动 × 六层上下文 × 知识飞轮 = 可预测、可追溯、可增强的Agent系统

​

相关推荐
wenzhangli71 小时前
oodAgent 4.0 Skills分布式调度 — 从Code Agent实战看自主维护的Agent网络
运维·网络·人工智能·自动化
接着奏乐接着舞。1 小时前
【2026年7月最新】69道RAG面试题
前端·人工智能·后端·aigc·embedding·rag
以和为贵1 小时前
前端也能搞懂 Agent：从 Function Calling 到自主编排
前端·人工智能·架构
断眉的派大星1 小时前
YOLO实例分割详细解析
人工智能·yolo·计算机视觉
DogDaoDao1 小时前
LLM：用一条命令统一所有大语言模型的 CLI 工具
人工智能·语言模型·自然语言处理·llm·github
ZRS的AI笔记1 小时前
AI Agent 工具链演进：从框架混战到协议标准化
人工智能
K姐研究社2 小时前
OiiOii 2.0 实测 – 智能画布实现 AI 视频创作自动化
运维·人工智能·自动化
掘金一周2 小时前
裁员了，公司很爽快，赔偿一分没少 | 沸点周刊 7.8
前端·人工智能·后端
yaoyouzhong2 小时前
GPT-Image-2 文生图：产品场景提示词撰写指南
人工智能
热门推荐
012026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf02GitHub 镜像站点032026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？04AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路05AI科技热点日报 | 2026年07月01日062026 年 AI 大模型 & AI 编程工具实战全总结072026 AI 编程工具选型横评：Cursor / Claude Code / Trae / Copilot 到底选谁（建议收藏·避坑版）08【AI】2026 年具身智能模型和世界模型总结092026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？102026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片