首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Agent Workflow子流程与场景流程的上下文管理——从爆炸到有序的设计哲学

Agent Workflow子流程与场景流程的上下文管理——从爆炸到有序的设计哲学

原创
作者头像
OneCode
发布2026-07-28 17:33:28
发布2026-07-28 17:33:28
1610
举报
文章被收录于专栏:ooderAgentooderAgent

从爆炸到有序的设计哲学

一、背景:多Agent协作中的上下文挑战

在基于Workflow引擎调度的Agent系统中,子流程场景流程是两种核心的流程抽象模式。它们使得复杂的人机协作、多Agent协同成为可能,但同时也带来了严峻的上下文管理挑战。

1.1 问题的本质:上下文爆炸

当一个Agent系统需要协调多个子任务、处理复杂的业务流程时,上下文数据会呈现指数级增长:

代码语言:javascript
复制
Main Process Context
├── Input: user query, session info, system config
├── Step 1 Result: intent, entities, confidence
├── Step 2 Result: componentType, fields, layout config
├── Sub-Process A Context (inherited)
│   ├── Parent Context (read-only)
│   ├── Step A1 Result: design metadata
│   ├── Step A2 Result: generated code
│   └── Sub-Sub-Process Context...
├── Scene Flow B Context (injected)
│   ├── Knowledge Repository Query
│   ├── Scene-specific config
│   └── Runtime accumulated data
└── ...exponential growth

上下文爆炸的三大根源:

  1. 数据累积:每个步骤产生新数据,未清理的历史数据持续堆积
  2. 传播冗余:相同的上下文信息在多个子流程间重复传播
  3. 语义漂移:字段命名不一致、结构变化导致理解困难

1.2 知识库的衔接困境

上下文不仅是数据容器,更是知识体系与执行实例的桥梁。然而,这条桥梁常因以下原因断裂:

  • 时序错位:知识库中的元数据定义与运行时上下文结构不同步
  • 命名割裂:配置文件中的字段名与代码中的变量名不一致
  • 类型失配:静态配置的类型约束在动态上下文中被绕过

二、理论框架:三层对齐模型

为了系统性地解决上述问题,我们提出流程-场景-实例三层对齐模型

2.1 对齐维度

维度

流程定义层

场景概念层

执行实例层

结构

Activity定义、SubFlow引用

SceneConfig、KnowledgeGroup

ProcessInstance、Context Bean

产出物

producedOutputs配置

stepMetadata注册

accumulatedData字段

输入

requiredInputs声明

capabilityRequirements

context.getAccumulated()

路由

transition条件表达式

failureStrategy策略

guard_escalation事件

2.2 核心约束

  1. C1 活动覆盖约束:流程定义中的每个Activity必须在场景层有对应的Step实现
  2. C2 产出物传播约束:producedOutputs中的每个字段必须出现在下游步骤的requiredInputs或accumulatedData中
  3. C3 路由一致性约束:transition条件的变量引用必须在上下文中存在

三、上下文生命周期管理

3.1 四阶段生命周期

阶段一:初始化(静态注入)

上下文的初始状态由三部分构成:

  1. 系统级配置:workMode、sceneGroupId、projectName等从配置文件加载
  2. 用户输入:query、conversationHistory从请求中获取
  3. 知识库预置:通过SceneConfig.preloadKnowledge注入的领域知识
代码语言:javascript
复制
// 初始化上下文的配置驱动模式
public class NlpResolutionContext {
    private String query;           // 用户输入
    private String workMode;        // 从application.properties注入
    private String sceneGroupId;    // 从流程定义继承
    private List<String> fields;    // 运行期填充

    public static NlpResolutionContext initialize(SceneConfig config) {
        NlpResolutionContext ctx = new NlpResolutionContext();
        ctx.setWorkMode(config.getWorkMode());
        ctx.setSceneGroupId(config.getSceneGroupId());
        return ctx;
    }
}
阶段二:运行期填充(动态数据)

随着流程执行,各步骤产生新的上下文数据:

  • 意图识别步骤:产出intent、componentType、confidence
  • 实体提取步骤:产出entities、fields、fieldTypes
  • 配置生成步骤:产出genJson、designerResult

关键设计:安全合并策略

代码语言:javascript
复制
// 避免null覆盖的安全合并
public void mergeAccumulatedData(Map<String, Object> newData) {
    for (Map.Entry<String, Object> entry : newData.entrySet()) {
        String key = entry.getKey();
        Object value = entry.getValue();
        // 只在当前值不存在或为null时覆盖
        if (!this.accumulatedData.containsKey(key) || this.accumulatedData.get(key) == null) {
            this.accumulatedData.put(key, value);
        }
    }
}
阶段三:结果缓存(持久化)

上下文快照通过VFS(虚拟文件系统)持久化,实现:

  1. 断点续传:流程中断后可从快照恢复
  2. 审计追溯:记录完整的执行轨迹
  3. 版本管理:支持上下文版本回滚
代码语言:javascript
复制
// VFS持久化接口
public interface NlpResolutionContextVfsHelper {
    void save(String processInstId, NlpResolutionContext ctx);
    NlpResolutionContext load(String processInstId);
    boolean exists(String processInstId);
}
阶段四:转移(继承与注入)

这是最关键的阶段,决定了子流程和场景流程如何获取上下文。

四、子流程与场景流程的转移机制对比

4.1 核心区别:继承 vs 注入

特性

子流程(Sub-Process)

场景流程(Scene Flow)

转移方式

继承(Inheritance)

注入(Injection)

上下文来源

父流程上下文的副本

场景配置+知识库查询

数据可见性

只读父流程数据

按需注入领域数据

生命周期

随父流程结束而结束

独立于触发流程

适用场景

任务分解、并行分支

领域切换、能力编排

4.2 继承模式(子流程)

子流程通过继承获得父流程的上下文副本。这意味着:

  • 子流程可以读取父流程的所有accumulatedData
  • 子流程的修改不会影响父流程(隔离性)
  • 子流程结束后,其产出物可选择性地回写到父流程
代码语言:javascript
复制
// 子流程上下文继承
public ProcessContext inheritFromParent(ProcessContext parentCtx) {
    ProcessContext childCtx = new ProcessContext();
    // 浅拷贝accumulatedData(只读)
    childCtx.setAccumulatedData(new HashMap<>(parentCtx.getAccumulatedData()));
    // 继承系统级配置
    childCtx.setWorkMode(parentCtx.getWorkMode());
    childCtx.setSceneGroupId(parentCtx.getSceneGroupId());
    return childCtx;
}

继承模式的优势:

  1. 数据透明性:子流程可以访问父流程的所有上下文,无需显式传递
  2. 隔离性:子流程的修改不会污染父流程,避免意外的副作用
  3. 简化编排:无需在流程定义中显式声明输入输出映射

4.3 注入模式(场景流程)

场景流程通过注入获得上下文。注入的数据来源包括:

  • 场景配置文件(SceneConfig)
  • 知识库查询结果(KnowledgeRepository)
  • 运行时计算的动态数据
代码语言:javascript
复制
// 场景流程上下文注入
public ProcessContext injectForScene(SceneConfig sceneConfig, 
                                       KnowledgeRepository repo,
                                       ProcessContext triggerCtx) {
    ProcessContext sceneCtx = new ProcessContext();

    // 1. 注入场景配置
    sceneCtx.setSceneGroupId(sceneConfig.getSceneGroupId());
    sceneCtx.setCapabilities(sceneConfig.getRequiredCapabilities());

    // 2. 注入知识库数据
    KnowledgeEntry knowledge = repo.query(sceneConfig.getKnowledgeGroupId());
    sceneCtx.setDomainKnowledge(knowledge.getMetadata());

    // 3. 注入触发上下文的关键字段(选择性注入,非全量继承)
    sceneCtx.setQuery(triggerCtx.getQuery());
    sceneCtx.setIntent(triggerCtx.getIntent());

    return sceneCtx;
}

注入模式的优势:

  1. 按需加载:只注入场景所需的数据,避免上下文膨胀
  2. 领域隔离:场景流程可以拥有独立的领域知识,不污染通用上下文
  3. 动态绑定:知识库查询在运行时执行,支持热更新

4.4 图示对比

五、压缩机制:应对上下文爆炸

5.1 上下文压缩策略

策略

实现方式

适用场景

字段过滤

仅保留requiredInputs定义的字段

子流程转移

快照差异

只存储与上一版本的差异

VFS持久化

知识外置

将领域知识移至知识库,按需查询

场景流程注入

Bean同源

使用强类型Bean替代散列Map

全局上下文管理

5.2 Bean同源设计

将散列的Map<String, Object>替换为强类型Bean,实现:

  1. 编译期类型检查:字段类型错误在编译时发现
  2. IDE支持:自动补全、重构安全
  3. 文档化:Bean结构即文档
代码语言:javascript
复制
/**
 * 实体解析结果上下文Bean
 * 替代散列Map传播,提供实体Bean同源处理
 */
public class NlpResolutionContext {
    private String query;
    private String intent;
    private String componentType;
    private String moduleName;
    private List<String> fields;
    private List<String> fieldEnglishNames;
    private Map<String, String> fieldTypes;

    // 从PipelineResult构建
    public static NlpResolutionContext fromPipelineResult(
            PipelineResult result, String query) {
        NlpResolutionContext ctx = new NlpResolutionContext();
        ctx.setQuery(query);
        ctx.setIntent(result.getIntent());
        ctx.setComponentType(result.getComponentType());
        ctx.setModuleName(result.getModuleName());
        ctx.setFields(result.getFields());
        ctx.setFieldEnglishNames(result.getEntityResult().getFieldEnglishNames());
        ctx.setFieldTypes(result.getEntityResult().getFieldTypes());
        return ctx;
    }

    // 判断是否包含Grid所需字段
    public boolean hasGridFields() {
        return fields != null && !fields.isEmpty() 
            && fieldEnglishNames != null && !fieldEnglishNames.isEmpty();
    }
}

六、最佳实践:配置驱动与运行时验证

6.1 配置驱动的字段映射

将硬编码的字段映射逻辑抽取到JSON配置文件,实现:

  • 可维护性:新增字段无需修改代码
  • 可追溯性:配置文件即文档
  • 运行时验证:自动检测未注册字段
代码语言:javascript
复制
// nlp-skill-field-mapping.json
{
  "pipelineContextFields": [
    {"mapKey": "query", "beanProperty": "query", "type": "String"},
    {"mapKey": "workMode", "beanProperty": "workMode", "type": "String"},
    {"mapKey": "sceneGroupId", "beanProperty": "sceneGroupId", "type": "String"}
  ],
  "pipelineResultEntityFields": [
    {"mapKey": "moduleName", "beanProperty": "moduleName", "type": "String"},
    {"mapKey": "fields", "beanProperty": "fields", "type": "List<String>"},
    {"mapKey": "fieldEnglishNames", "beanProperty": "fieldEnglishNames", "type": "List<String>"}
  ]
}

6.2 运行时验证机制

在上下文转换方法中嵌入验证逻辑,及时发现遗漏的字段映射:

代码语言:javascript
复制
public static PipelineContext toPipelineContext(Map<String, Object> context) {
    // CONFIG验证: 检测未注册的Map key
    Set<String> unmapped = detectUnmappedKeys(context);
    if (!unmapped.isEmpty()) {
        log.debug("[NlpSkillContextHelper] 未注册Map key={}", unmapped);
    }
    // ... 字段映射逻辑
}

七、总结:设计优势与适用场景

7.1 继承模式(子流程)适用场景

  • ✅ 任务分解:将复杂任务拆解为多个子任务
  • ✅ 并行执行:多个子流程同时运行,最后合并结果
  • ✅ 错误隔离:子流程失败不影响父流程其他部分

7.2 注入模式(场景流程)适用场景

  • ✅ 领域切换:从一个业务领域切换到另一个
  • ✅ 能力编排:组合多个独立的能力模块
  • ✅ 知识隔离:不同场景使用不同的知识库

7.3 混合模式

在实际系统中,子流程和场景流程往往结合使用:

代码语言:javascript
复制
Main Process (architect-pipeline)
├── Sub-Process: understand-subflow (继承)
│   ├── Activity: intent_classification
│   ├── Activity: entity_extraction
│   └── Activity: entity_resolution
├── Scene Flow: rad-scene (注入)
│   ├── Knowledge: component-type-registry
│   └── Capability: nlp.design
└── Sub-Process: quality-validation (继承)
    ├── Activity: llm_fallback
    └── Activity: cls_audit

这种混合架构既保证了数据透明性(继承),又实现了领域隔离(注入),是多Agent协作系统的最佳实践。

参考文献

  1. Workflow引擎设计模式 - BPMN 2.0规范
  2. 知识图谱与Agent系统融合 - 学术综述
  3. 上下文管理最佳实践 - OODER技术白皮书

© 2026 OODER技术团队 | 子流程与场景流程上下文管理设计

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、背景:多Agent协作中的上下文挑战
    • 1.1 问题的本质:上下文爆炸
    • 1.2 知识库的衔接困境
  • 二、理论框架:三层对齐模型
    • 2.1 对齐维度
    • 2.2 核心约束
  • 三、上下文生命周期管理
    • 3.1 四阶段生命周期
      • 阶段一:初始化(静态注入)
      • 阶段二:运行期填充(动态数据)
      • 阶段三:结果缓存(持久化)
      • 阶段四:转移(继承与注入)
  • 四、子流程与场景流程的转移机制对比
    • 4.1 核心区别:继承 vs 注入
    • 4.2 继承模式(子流程)
    • 4.3 注入模式(场景流程)
    • 4.4 图示对比
  • 五、压缩机制:应对上下文爆炸
    • 5.1 上下文压缩策略
    • 5.2 Bean同源设计
  • 六、最佳实践:配置驱动与运行时验证
    • 6.1 配置驱动的字段映射
    • 6.2 运行时验证机制
  • 七、总结:设计优势与适用场景
    • 7.1 继承模式(子流程)适用场景
    • 7.2 注入模式(场景流程)适用场景
    • 7.3 混合模式
  • 参考文献
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档