Agent上下文治理从6层模型到5维注意力检测的工程实践

wenzhangli7

233人浏览 · 2026-07-10 17:38:13

wenzhangli7 · 2026-07-10 17:38:13 发布

OODER Studio · 2026年7月 · 深度技术博文

第1章：问题定义 — 为什么Agent需要上下文治理

1.1 核心矛盾：有限窗口 vs 无限流程

LLM的上下文窗口是一个刚性约束。GPT-4的128K tokens、Claude的200K tokens看起来很大，但当Agent执行一个包含数十个活动的长流程时，上下文消耗速度远超想象。一个典型的企业级审批流程可能包含：

流程定义JSON（3K-8K tokens）
每个活动节点产生的输出（1K-3K tokens/活动）
对话历史（每轮2K-5K tokens）
知识库注入（5K-20K tokens）

一个15步流程的Agent运行，上下文消耗轻松突破150K tokens。更关键的是——这不是偶发问题，而是Agent范式的结构性缺陷。传统LLM聊天是"一问一答"的短交互，Agent是"长流程、多步骤、有状态"的连续执行，两者对上下文的使用模式完全不同。

1.2 上下文膨胀的3个来源

来源1：活动产出物累积

每个BPM活动执行后都会产生结果——代码片段、决策记录、数据转换输出。这些产出物如果不加管控地堆叠在上下文中，会形成产出物雪崩。第1个活动的产出在第10个活动时可能已经毫无价值，但仍然占据上下文空间。

来源2：对话历史膨胀

Agent的每一步都需要LLM推理，每次推理都产生对话轮次。在AND_SPLIT并行分支中，多条分支各自产生对话历史，合并时如果不加裁剪，历史记录呈指数级膨胀。

来源3：知识注入过量

知识库检索是Agent的"超能力"，但也是上下文的"黑洞"。RAG检索的Top-K结果、知识图谱的关联节点、领域规则的注入——如果缺乏针对性筛选，知识注入会迅速淹没核心任务上下文。

150K100K50K0tokens步骤1步骤5步骤10步骤15步骤20窗口上限溢出区总上下文活动产出物对话历史知识注入

图1：上下文膨胀 vs 窗口容量 — 无治理时总上下文在步骤12左右溢出

1.3 无治理的典型问题

问题1：注意力稀释

当上下文中充斥着早期步骤的过时信息时，LLM的注意力被分散。研究表明，LLM在长上下文中存在"中间丢失"效应——对上下文中间部分的信息关注度显著低于开头和结尾。不加治理的上下文恰好把最重要的当前任务上下文推到了"中间"位置。

问题2：知识过时

第3步注入的知识，到第15步时环境可能已变。比如配置项已更新、API签名已变更，但旧知识仍在上下文中"作祟"，导致Agent基于过期信息做出错误决策。

问题3：冲突堆积

AND_SPLIT的并行分支各自产生输出，这些输出在AND_JOIN合并时可能存在冲突——同一配置项的两个不同值、对同一逻辑的两种不同理解。如果缺乏冲突检测和解决机制，冲突会像技术债一样累积，最终导致流程崩溃。

核心洞察

上下文治理不是"锦上添花"，而是Agent能否可靠执行长流程的生存性问题。没有上下文治理的Agent，就像没有内存管理的操作系统——短任务可以运行，长任务必然崩溃。

第2章：6层上下文模型 — 分层即治理

2.1 分层架构设计

将上下文空间划分为6个语义层次，每层有独立的职责、生命周期和管理策略。分层的核心价值在于：不同类型的信息有不同的时效性和重要性，应该有不同的治理策略。

层次	标识	核心职责	典型内容
L1 SYSTEM	SYSTEM	Agent身份与核心约束	角色定义、安全边界、不可变规则
L2 PROCESS	PROCESS	流程结构定义	BPM流程图、活动拓扑、网关定义
L3 KNOWLEDGE	KNOWLEDGE	领域知识注入	RAG检索结果、知识图谱、领域规则
L4 HISTORY	HISTORY	执行历史记录	已完成活动的产出、决策日志
L5 WORKING	WORKING	当前工作空间	当前活动输入/输出、中间变量
L6 EPHEMERAL	EPHEMERAL	临时计算缓冲	工具调用参数、推理中间态

2.2 各层详细定义

L1 SYSTEM层

SYSTEM层是上下文的"宪法"——定义Agent是谁、能做什么、不能做什么。这一层在Agent初始化时写入，整个执行周期内不可变。任何试图修改SYSTEM层的操作都必须经过HUMAN回路的EXPLICIT_APPROVAL级别审批。

生命周期：Agent创建时初始化，流程结束时销毁
持久化策略：每次调用LLM时作为system prompt首段注入
大小控制：严格限制在2K tokens以内

L2 PROCESS层

PROCESS层存储BPM流程的结构定义。在XOR_SPLIT/AND_SPLIT等分支点，PROCESS层需要"分裂"——每个分支继承完整流程定义但只关注自己的路径。

生命周期：流程启动时加载，流程结束时归档
持久化策略：压缩存储，仅当前路径展开
分裂策略：AND_SPLIT时完整继承，XOR_SPLIT时路径裁剪

L3 KNOWLEDGE层

KNOWLEDGE层是最"动态"的层之一。不同活动需要的知识不同，同一个活动在不同阶段需要的知识粒度也不同。KNOWLEDGE层的核心治理策略是按需注入、及时清除、置信度过滤。

生命周期：按活动粒度注入/清除
持久化策略：高置信度知识可跨活动保留
大小控制：单次注入不超过8K tokens

L4 HISTORY层

HISTORY层记录已完成活动的产出。这是压缩的主要对象——完成时间越久远的活动产出，其保留优先级越低。HISTORY层采用分级压缩策略：最近3步完整保留、3-8步摘要保留、8步以上仅保留关键决策点。

L5 WORKING层

WORKING层是Agent的"工作台"，存放当前活动需要的所有输入和已产生的输出。这是注意力检测的核心监控对象——WORKING层的大小直接决定LLM的推理质量。

大小阈值：默认12K tokens，可按活动类型配置
压缩触发：达到阈值80%时进入预警，100%时强制压缩

L6 EPHEMERAL层

EPHEMERAL层是"草稿纸"——工具调用的临时参数、推理的中间状态、一次性的计算结果。这一层的生命周期最短，每次LLM调用后即可清除。EPHEMERAL层从不持久化，分裂时不继承，合并时不参与冲突检测。

SYSTEM不可变·共享全局共享PROCESS继承·分支感知分裂继承KNOWLEDGE按需注入·置信度过滤HISTORY分级压缩·时间衰减WORKING阈值监控·强制压缩分支私有EPHEMERAL临时·不持久化·不继承调用后清除生命周期：长 → 短压缩强度：弱 → 强

图2：6层上下文金字塔 — 顶层共享不变成略，底层临时强压缩

2.3 层间关系矩阵

关系	源层	目标层	说明
共享	SYSTEM	所有分支	SYSTEM层在所有分支中完全一致
继承	PROCESS	分裂分支	分支继承完整流程定义，按路径裁剪
继承	KNOWLEDGE	分裂分支	分支继承知识但可按需重新检索
私有	WORKING	当前分支	每个分支有独立的WORKING空间
合并	HISTORY	合并后主分支	多个分支的HISTORY合并时需冲突检测
临时	EPHEMERAL	无	不继承、不合并、不持久化

第3章：3大决策点 — 压缩/分裂/合并

3.1 D1 压缩决策

压缩决策是上下文治理的"日常功课"——在每次LLM调用前评估上下文健康度，决定是否压缩。决策流程：

阈值检测：WORKING层字符数 / 阈值 → 压力比
策略选择：压力比 < 0.6 → 不压缩；0.6-0.8 → 轻度摘要；0.8-1.0 → 中度压缩；> 1.0 → 强制压缩
执行压缩：保留关键key，摘要化低优先级内容，EPHEMERAL层清空

压缩策略细节

压缩不是简单的"删除"。关键保留键（retainKeys）指定的内容完整保留，其余内容按优先级降级：完整→摘要→仅保留key名→归档到二级存储。二级压缩在首次压缩后仍超阈值时触发，进一步降低粒度。

3.2 D2 分裂决策

当流程执行到AND_SPLIT网关时，上下文需要"分裂"为多个独立分支。分裂决策的核心问题是：每层如何继承？

层次	分裂策略	理由
SYSTEM	完整复制	Agent身份和约束在所有分支中一致
PROCESS	完整复制+路径标注	每个分支需知道完整流程但关注自己的路径
KNOWLEDGE	完整复制+按需重检索	分支可继承知识但可按新上下文重新检索
HISTORY	完整复制	历史对齐，避免分支间理解偏差
WORKING	分裂独立	每个分支有独立的工作空间
EPHEMERAL	不继承(清空)	临时数据无需保留

3.3 D3 合并决策

AND_JOIN网关触发合并决策。合并的关键挑战是冲突检测与解决。合并流程：

快照对齐：确保所有分支到达合并点
HISTORY层合并：按时间线交错合并各分支的执行记录
WORKING层冲突检测：扫描各分支WORKING层中的同名key，检测值冲突
冲突解决：自动策略（最后写入优先/最高置信度优先）或HUMAN回路介入
KNOWLEDGE层去重：合并各分支的知识注入，去重+置信度加权

3.4 LLM参与条件

三个决策点中，并非所有情况都需要LLM参与：

D1-自动路径：压力比 > 1.0 且无保留键冲突 → 纯规则压缩，无需LLM
D1-LLM增强：压力比 0.6-1.0 或涉及语义判断 → LLM生成摘要
D2-LLM分支：AND_SPLIT时需要LLM理解分支语义差异
D3-冲突：自动策略无法解决 → LLM评估+HUMAN回路

开始活动AD1XORANDD2分裂分支B1分支B2ANDD3合并活动C结束压缩检测<0.6不压缩>0.8压缩

图3：3大决策点在流程中的位置 — D1压缩在每步前，D2分裂在AND_SPLIT，D3合并在AND_JOIN

第4章：5维注意力检测 — 量化上下文健康度

4.1 为什么需要注意力检测

上下文治理需要"仪表盘"——不能等到溢出才发现问题，需要在恶化过程中提前预警。5维注意力检测提供了量化上下文健康度的框架，每个维度对应一个具体的风险因素，加权计算综合注意力分数。

4.2 五个维度详解

维度1：容量维度（权重0.30）

衡量WORKING层的空间占用情况。计算公式：

capacityScore = 1.0 - (workingLayerChars / thresholdChars)

当WORKING层占用超过阈值时，capacityScore变为负数，表示已进入危险区域。这是权重最高的维度，因为容量问题是最直接、最致命的——一旦溢出，流程直接失败。

维度2：层间重复维度（权重0.20）

检测不同层之间的key重叠情况。如果KNOWLEDGE层和WORKING层有大量同名key，说明存在信息冗余，可以安全地去重。计算公式：

duplicationScore = 1.0 - crossLayerKeyOverlapRate

维度3：知识有效性维度（权重0.20）

评估KNOWLEDGE层中知识的实际价值。结合两个指标：

置信度：知识来源的可靠性评分（0-1）
引用率：知识在推理中被实际引用的比例

knowledgeScore = avg(confidence) * citationRate

低置信度且零引用的知识是"上下文垃圾"，应该优先清除。

维度4：分支活跃度维度（权重0.15）

检测并行分支的活跃情况。活跃分支数 / 总分支数反映并行度。活跃度过低可能意味着某些分支已停滞，其上下文可以被冻结或压缩。计算公式：

branchScore = activeBranches / totalBranches

维度5：冲突密度维度（权重0.15）

检测AND_JOIN待合并的分支之间的冲突情况。冲突越多，合并越困难，需要更多LLM推理和HUMAN干预。计算公式：

conflictScore = 1.0 - (conflictCount / totalKeyCount)

4.3 综合注意力分数

attentionScore = 0.30 * capacityScore
               + 0.20 * duplicationScore
               + 0.20 * knowledgeScore
               + 0.15 * branchScore
               + 0.15 * conflictScore

综合分数范围[-0.5, 1.0]，不同区间对应不同的建议动作：

分数区间	健康等级	建议动作
[0.8, 1.0]	健康	继续执行，无需干预
[0.6, 0.8)	关注	轻度压缩，清除EPHEMERAL层
[0.4, 0.6)	警告	中度压缩，HISTORY层摘要化
[0.2, 0.4)	危险	强制压缩+知识重注入+HUMAN预警
< 0.2	紧急	暂停执行+全面压缩+HUMAN必须介入

容量权重0.30层间重复权重0.20知识有效性权重0.20分支活跃度权重0.15冲突密度权重0.15阈值=0.60.500.700.800.900.60综合注意力分数 = 0.30×0.50 + 0.20×0.70 + 0.20×0.80 + 0.15×0.90 + 0.15×0.60 = 0.675

图4：5维注意力雷达图 — 红色虚线为0.6阈值，蓝色区域为实际检测值

第5章：HUMAN回路 — 4种触发×5级干预

5.1 为什么需要HUMAN回路

上下文治理不是纯技术问题——压缩什么、保留什么、冲突如何解决，这些都涉及业务语义判断。纯自动化可能做出"技术上正确但业务上错误"的决策。HUMAN回路提供了"人在环中"的安全阀。

5.2 四种触发类型

触发类型	标识	触发时机	典型场景
设计时触发	DESIGN_TIME	BPM流程设计阶段	定义活动阈值、保留键、压缩策略
运行时触发	RUNTIME	流程执行中	注意力分数低于阈值、压缩前确认
质量触发	QUALITY	产出质量检测	输出置信度低、推理链断裂
冲突触发	CONFLICT	AND_JOIN合并	分支间key冲突、策略不一致

5.3 五级交互级别

级别	标识	说明	用户感知
L1	AUTO_ALLOW	自动执行，无需人工确认	无感知
L2	MICRO_SUGGESTION	微提示，不阻塞执行	非阻塞提示
L3	DIFF_PREVIEW	变更预览，用户可快速确认	阻塞+预览
L4	EXPLICIT_APPROVAL	明确审批，需用户主动确认	阻塞+确认
L5	AUTO_DENY	自动拒绝，禁止执行	操作被阻止

5.4 触发×干预矩阵

	AUTO_ALLOW	MICRO_SUGGESTION	DIFF_PREVIEW	EXPLICIT_APPROVAL	AUTO_DENY
DESIGN_TIME	默认策略生效	策略建议	配置变更预览	关键规则修改	非法配置
RUNTIME	常规压缩	轻度过载提示	压缩变更预览	核心上下文压缩	SYSTEM层修改
QUALITY	质量达标	质量波动提示	输出修正预览	重大输出变更	安全违规
CONFLICT	自动解决	冲突提示	解决方案预览	关键冲突决策	不可调和冲突

5.5 与human_confirm工具的级联映射

触发类型和干预级别最终通过human_confirm工具落地。级联规则：

L1 AUTO_ALLOW → 不调用human_confirm
L2 MICRO_SUGGESTION → 调用human_confirm(mode="suggestion")
L3 DIFF_PREVIEW → 调用human_confirm(mode="diff_preview")
L4 EXPLICIT_APPROVAL → 调用human_confirm(mode="explicit_approval")
L5 AUTO_DENY → 不调用human_confirm，直接拒绝并记录日志

5.6 干预选项拆分

HUMAN回路的干预在不同场景下由不同角色执行：

Designer（定义时）：在BPMDesigner中配置活动的上下文策略——阈值、保留键、压缩策略、干预级别。这是"预防性干预"。
LLM-Chat（运行时-自动）：在LLM推理过程中，自动触发上下文操作——压缩、分裂、合并。LLM是上下文治理的"执行者"。
Human面板（运行时-人工）：当干预级别 ≥ L3时，人类通过面板介入——审批压缩方案、解决冲突、修正知识。这是"纠正性干预"。

DESIGN_TIME设计时触发RUNTIME运行时触发QUALITY质量触发CONFLICT冲突触发AUTO_ALLOWMICRO_SUGGESTDIFF_PREVIEWEXPLICIT_APPROVEAUTO_DENY不调用confirmconfirm(suggest)confirm(diff)confirm(approve)直接拒绝+日志Designer定义时干预配置策略设定阈值LLM-Chat运行时自动执行压缩检测+决策Human面板运行时人工审批决策解决冲突触发类型 → 干预级别 → 工具级联 → 干预角色干预级别越高，人类参与度越深，自动化程度越低高自动化 ←→ 高人工介入

图5：HUMAN回路 — 触发类型×干预级别×工具级联×干预角色完整映射

第6章：LLM工具链 — Function Calling驱动的上下文操作

6.1 工具设计原则

上下文治理的所有操作都通过Function Calling工具暴露给LLM。这样设计有三个好处：

可控性：每个操作都有明确的入参和出参，便于审计和回溯
可组合性：LLM可以按需组合多个工具调用，形成工具链
可观测性：所有工具调用都有日志，便于调试和优化

6.2 四大核心工具

context_inspect — 6层检视

查看指定层的当前状态，包括大小、key列表、内容摘要。这是LLM"看"上下文的能力。

// 工具定义
{
  "name": "context_inspect",
  "parameters": {
    "layer": "SYSTEM|PROCESS|KNOWLEDGE|HISTORY|WORKING|EPHEMERAL|ALL",
    "keys": "可选，指定检视的key列表",
    "summary_only": "true时仅返回摘要，不返回完整内容"
  }
}

context_compress — 压缩/解压/评估

对指定层执行压缩操作，或评估压缩建议。支持三种模式：

compress：执行压缩，传入保留键列表
decompress：从二级存储恢复已压缩的内容
evaluate：仅评估压缩效果，不实际执行

// 工具定义
{
  "name": "context_compress",
  "parameters": {
    "mode": "compress|decompress|evaluate",
    "layer": "HISTORY|WORKING",
    "retain_keys": "保留键列表",
    "strategy": "SUMMARY|ARCHIVE|AGGRESSIVE"
  }
}

context_branch — 分支评估/冲突解决/快照

管理分支相关的上下文操作：

evaluate：评估当前分支的上下文健康度
resolve_conflict：解决合并冲突
snapshot：创建当前上下文快照

// 工具定义
{
  "name": "context_branch",
  "parameters": {
    "mode": "evaluate|resolve_conflict|snapshot",
    "branch_id": "分支标识",
    "conflict_keys": "冲突key列表(resolve_conflict模式)",
    "resolution_strategy": "LAST_WRITE|HIGHEST_CONFIDENCE|HUMAN"
  }
}

human_confirm — HUMAN确认

触发HUMAN回路的人工干预。仅在干预级别 ≥ L2时调用。

// 工具定义
{
  "name": "human_confirm",
  "parameters": {
    "trigger_type": "DESIGN_TIME|RUNTIME|QUALITY|CONFLICT",
    "interaction_level": "MICRO_SUGGESTION|DIFF_PREVIEW|EXPLICIT_APPROVAL",
    "message": "提示消息",
    "diff_content": "变更内容(DIFF_PREVIEW模式)",
    "options": "可选操作列表"
  }
}

6.3 五条工具链路

链路	触发条件	工具调用序列	LLM参与
D1自动	压力比>1.0，无保留键冲突	context_inspect→context_compress(compress)	否
D1-LLM增强	压力比0.6-1.0	context_inspect→context_compress(evaluate)→LLM判断→context_compress(compress)	是
D2-LLM分支	AND_SPLIT网关	context_branch(snapshot)→context_inspect→LLM分支评估→分裂执行	是
D3冲突	AND_JOIN检测到冲突	context_branch(evaluate)→context_branch(resolve_conflict)→human_confirm	是
知识反馈	知识有效性低	context_inspect(KNOWLEDGE)→LLM评估→知识重注入	是

时间链路1：D1自动context_inspectcontext_compress✓ 无LLM参与链路2：D1-LLM增强context_inspectcompress(evaluate)LLM判断context_compress链路3：D2-LLM分支context_branch(snap)context_inspectLLM评估分裂执行链路4：D3冲突context_branch(eval)context_branch(resolve)human_confirm链路5：知识反馈context_inspect(KNOW)LLM评估知识重注入工具调用LLM参与调用方向

图6：5条工具链路调用时序图 — 从左到右按时间顺序执行

第7章：知识飞轮 — 上下文治理的知识闭环

7.1 知识不是静态的

上下文治理中的KNOWLEDGE层不是"注入即忘"的静态数据。知识有生命周期——从生产到消费，从消费到反馈，从反馈到更新，形成飞轮效应。飞轮转得越快，上下文中的知识质量越高，Agent的推理质量也越高。

7.2 四阶段闭环

阶段1：知识生产

知识的来源有三个：

设计时注入：Designer在BPM流程中标注的知识需求，如"此活动需要OAuth2.0认证知识"
运行时检索：Agent执行时通过RAG检索的知识，如"从知识库检索Java Spring配置规范"
推理产出：LLM推理过程中产生的新知识，如"发现了API v3与v2的签名差异"

每条知识都附带置信度评分（0-1），置信度来源包括：知识库权威性、引用次数、人工确认。

阶段2：知识入库

新产生的知识需要经过筛选才能入库：

置信度 < 0.3 → 不入库，作为EPHEMERAL数据使用
置信度 0.3-0.7 → 入库但标记为"待验证"
置信度 > 0.7 → 入库并标记为"可用"

入库的知识需要去重——与现有知识的相似度 > 0.9时，选择置信度更高的版本保留。

阶段3：知识消费

知识注入KNOWLEDGE层时，注意力检测会影响注入策略：

注意力分数 > 0.6 → 正常注入，保留完整知识
注意力分数 0.4-0.6 → 精简注入，仅保留高置信度核心内容
注意力分数 < 0.4 → 最小注入，仅保留关键key和摘要

阶段4：知识反馈

知识消费后，通过两个指标评估知识的实际价值：

引用率：知识在后续推理中被引用的比例
有效性：基于引用后的推理结果是否正确

低引用率+低有效性的知识会被降权或清除；高引用率+高有效性的知识会被升权并推荐到更多场景。

7.3 知识置信度与注意力检测的联动

知识有效性维度（5维中的第3维）直接驱动知识飞轮的反馈阶段：

// 知识有效性评分驱动自动重注入
if (knowledgeScore < 0.4) {
    // 标记当前KNOWLEDGE层知识为"低效"
    lowEffectivenessKeys = detectLowEffectiveness(knowledgeLayer);
    // 触发知识重注入
    reInjectKnowledge(lowEffectivenessKeys, "PRECISE");
    // 更新知识置信度
    updateConfidence(lowEffectivenessKeys, -0.1);
}
if (knowledgeScore > 0.8) {
    // 高效知识，提升置信度
    highEffectivenessKeys = detectHighEffectiveness(knowledgeLayer);
    updateConfidence(highEffectivenessKeys, +0.05);
}

知识飞轮持续加速① 知识生产设计时注入 + RAG检索 + 推理产出输出：知识条目 + 置信度② 知识入库筛选 + 去重 + 标记输出：知识库条目③ 知识消费注入KNOWLEDGE层 + 注意力适配输出：上下文知识④ 知识反馈引用率 + 有效性评估输出：置信度更新注意力检测有效性评分驱动重注入

图7：知识飞轮4阶段闭环 — 注意力检测在消费阶段适配注入策略

第8章：工程实现 — 关键代码架构

8.1 ContextLayerManager — 6层读写引擎

ContextLayerManager是上下文治理的核心引擎，负责6层上下文的读写、分裂、合并和恢复操作。

public class ContextLayerManager {
    
    private final Map<ContextLayer, LayerStorage> layers;
    private final String processInstanceId;
    private final List<String> activeBranches;
    
    @Override
    public void write(ContextLayer layer, String key, Object value) {
        // SYSTEM层写入需EXPLICIT_APPROVAL
        if (layer == ContextLayer.SYSTEM) {
            requireHumanApproval(TriggerType.RUNTIME,
                InteractionLevel.EXPLICIT_APPROVAL,
                "Attempting to modify SYSTEM layer: " + key);
        }
        layers.get(layer).put(key, value);
    }
    
    @Override
    public ContextSnapshot split(String branchId, SplitStrategy strategy) {
        ContextSnapshot snapshot = new ContextSnapshot();
        // SYSTEM/PROCESS/KNOWLEDGE/HISTORY 完整继承
        for (ContextLayer layer : Arrays.asList(
                SYSTEM, PROCESS, KNOWLEDGE, HISTORY)) {
            snapshot.inherit(layer, layers.get(layer).deepCopy());
        }
        // WORKING 分裂独立
        snapshot.create(WORKING, new LayerStorage());
        // EPHEMERAL 不继承
        snapshot.create(EPHEMERAL, new LayerStorage());
        activeBranches.add(branchId);
        return snapshot;
    }
    
    @Override
    public MergeResult merge(List<ContextSnapshot> snapshots) {
        MergeResult result = new MergeResult();
        // HISTORY层按时间线交错合并
        result.mergeHistory(interleaveByTimestamp(snapshots));
        // WORKING层冲突检测
        List<Conflict> conflicts = detectConflicts(snapshots, WORKING);
        if (!conflicts.isEmpty()) {
            result.setConflicts(conflicts);
            result.setNeedsHumanIntervention(true);
        }
        // KNOWLEDGE层去重
        result.mergeKnowledge(dedupByConfidence(snapshots));
        return result;
    }
    
    @Override
    public void restore(ContextSnapshot snapshot) {
        layers.clear();
        snapshot.getLayers().forEach((k, v) -> layers.put(k, v));
    }
}

8.2 ContextCompressor — 动态压缩引擎

public class ContextCompressor {
    
    private final CompressConfig config;
    private final SecondaryStorage secondaryStorage;
    
    public CompressResult compress(ContextLayer layer,
            Set<String> retainKeys, CompressStrategy strategy) {
        
        LayerStorage storage = getStorage(layer);
        CompressResult result = new CompressResult();
        
        // 1. 保留键完整保留
        Map<String, Object> retained = storage.retainAll(retainKeys);
        
        // 2. 按策略压缩其余内容
        Map<String, Object> compressed = switch (strategy) {
            case SUMMARY -> summarize(storage.except(retainKeys));
            case ARCHIVE -> archive(storage.except(retainKeys));
            case AGGRESSIVE -> aggressiveCompress(storage.except(retainKeys));
        };
        
        // 3. 写回
        storage.clear();
        storage.putAll(retained);
        storage.putAll(compressed);
        
        // 4. 归档到二级存储
        secondaryStorage.archive(layer, result.getArchived());
        
        // 5. 二级压缩检查
        if (storage.charCount() > config.getThreshold() * 0.8) {
            secondaryCompress(layer, retainKeys);
        }
        
        return result;
    }
    
    public DecompressResult decompress(ContextLayer layer, Set<String> keys) {
        Map<String, Object> restored = secondaryStorage.restore(layer, keys);
        getStorage(layer).putAll(restored);
        return new DecompressResult(restored.size());
    }
}

8.3 ContextAttentionDetector — 5维检测引擎

public class ContextAttentionDetector {
    
    private static final double[] WEIGHTS = {0.30, 0.20, 0.20, 0.15, 0.15};
    
    public AttentionReport detect(ContextLayerManager manager) {
        // 维度1：容量
        double capacityScore = 1.0 - (double) manager.charCount(WORKING)
            / config.getWorkingThreshold();
        
        // 维度2：层间重复
        double duplicationScore = 1.0 - crossLayerOverlapRate(manager);
        
        // 维度3：知识有效性
        double knowledgeScore = avgConfidence(manager, KNOWLEDGE)
            * citationRate(manager, KNOWLEDGE);
        
        // 维度4：分支活跃度
        double branchScore = (double) manager.activeBranchCount()
            / manager.totalBranchCount();
        
        // 维度5：冲突密度
        double conflictScore = 1.0 - (double) manager.conflictCount()
            / manager.totalKeyCount();
        
        // 综合分数
        double[] scores = {capacityScore, duplicationScore,
            knowledgeScore, branchScore, conflictScore};
        double attentionScore = 0;
        for (int i = 0; i < WEIGHTS.length; i++) {
            attentionScore += WEIGHTS[i] * scores[i];
        }
        
        // 建议动作
        SuggestedAction action = suggestAction(attentionScore);
        
        return new AttentionReport(scores, attentionScore, action);
    }
    
    private SuggestedAction suggestAction(double score) {
        if (score >= 0.8) return SuggestedAction.CONTINUE;
        if (score >= 0.6) return SuggestedAction.LIGHT_COMPRESS;
        if (score >= 0.4) return SuggestedAction.MODERATE_COMPRESS;
        if (score >= 0.2) return SuggestedAction.FORCED_COMPRESS_AND_HUMAN;
        return SuggestedAction.PAUSE_AND_HUMAN;
    }
}

8.4 HumanLoopTriggerDetector — 4触发×5级干预

public class HumanLoopTriggerDetector {
    
    public InterventionDecision evaluate(TriggerType trigger,
            ContextLayerManager manager, AttentionReport report) {
        
        InteractionLevel level = determineLevel(trigger, report);
        
        return InterventionDecision.builder()
            .trigger(trigger)
            .level(level)
            .needsHumanConfirm(level.ordinal() >= InteractionLevel.MICRO_SUGGESTION.ordinal())
            .confirmMode(toConfirmMode(level))
            .message(buildMessage(trigger, report))
            .build();
    }
    
    private InteractionLevel determineLevel(TriggerType trigger,
            AttentionReport report) {
        return switch (trigger) {
            case DESIGN_TIME -> report.getScore() < 0.3
                ? InteractionLevel.EXPLICIT_APPROVAL
                : InteractionLevel.AUTO_ALLOW;
            case RUNTIME -> runtimeLevel(report);
            case QUALITY -> report.getScore() < 0.4
                ? InteractionLevel.DIFF_PREVIEW
                : InteractionLevel.MICRO_SUGGESTION;
            case CONFLICT -> conflictLevel(report);
        };
    }
}

8.5 ActivityExtensionConfig — 6维配置模型

ActivityExtensionConfig将BPMDesigner中定义的上下文治理策略与运行时引擎对齐。6个配置维度：

维度	属性	说明
1. 阈值配置	workingThreshold	WORKING层字符数阈值
2. 保留键配置	retainKeys	压缩时必须保留的key列表
3. 压缩策略	compressStrategy	SUMMARY/ARCHIVE/AGGRESSIVE
4. 干预级别	interactionLevel	该活动的最小干预级别
5. 知识需求	knowledgeRequirements	该活动需要的知识类型和数量
6. 分支策略	branchStrategy	分裂/合并时的继承和冲突策略

public class ActivityExtensionConfig {
    private int workingThreshold = 12000;
    private Set<String> retainKeys = new HashSet<>();
    private CompressStrategy compressStrategy = CompressStrategy.SUMMARY;
    private InteractionLevel minInteractionLevel = InteractionLevel.AUTO_ALLOW;
    private List<KnowledgeRequirement> knowledgeRequirements = new ArrayList<>();
    private BranchStrategy branchStrategy = BranchStrategy.INHERIT_ALL;
}

8.6 ChatProcessBridge — Chat↔Process双向同步

ChatProcessBridge解决LLM-Chat与BPM-Process之间的上下文同步问题：

Chat→Process：LLM推理产出写入WORKING层，触发注意力检测
Process→Chat：流程事件（活动完成、网关到达）更新PROCESS和HISTORY层

public class ChatProcessBridge {
    
    private final ContextLayerManager layerManager;
    private final ContextAttentionDetector attentionDetector;
    
    @EventListener
    public void onActivityComplete(ActivityCompleteEvent event) {
        // 1. 将活动产出从WORKING迁移到HISTORY
        layerManager.moveToHistory(event.getActivityId());
        
        // 2. 清空EPHEMERAL层
        layerManager.clear(EPHEMERAL);
        
        // 3. 检测注意力
        AttentionReport report = attentionDetector.detect(layerManager);
        
        // 4. 根据报告决定下一步操作
        if (report.getAction() == SuggestedAction.LIGHT_COMPRESS) {
            layerManager.compress(HISTORY, getRetainKeys(event), SUMMARY);
        }
    }
    
    @EventListener
    public void onGatewayReached(GatewayEvent event) {
        switch (event.getGatewayType()) {
            case AND_SPLIT -> {
                layerManager.split(event.getBranchId(), INHERIT_ALL);
            }
            case AND_JOIN -> {
                MergeResult result = layerManager.merge(event.getSnapshots());
                if (result.needsHumanIntervention()) {
                    triggerHumanLoop(CONFLICT, result.getConflicts());
                }
            }
        }
    }
}

ContextLayerManager6层读写 + 分裂 + 合并 + 恢复write / read / split / mergerestore / moveToHistory / clearContextCompressor动态配置 + 保留键 + 压缩块compress / decompress / evaluateKnowledgeFlywheel生产→入库→消费→反馈produce / store / consume / feedbackAttentionDetector5维检测 + 建议动作detect / suggestActionHumanLoopDetector4触发 × 5级干预evaluate / determineLevelChatProcessBridgeChat↔Process双向同步onActivityComplete / onGatewayActivityExtensionConfig6维配置模型threshold / retain / strategy / level使用驱动联动触发回调同步上下文配置阈值配置直接依赖配置/间接

图8：核心引擎类图 — 从ContextLayerManager到HumanLoopTriggerDetector的完整依赖关系

8.7 架构总结

以上6个核心组件构成了Agent上下文治理的完整技术栈：

ContextLayerManager是基础——6层模型的读写引擎，所有其他组件都依赖它
ContextCompressor是执行者——根据策略执行压缩/解压/评估
KnowledgeFlywheel是闭环——知识从生产到反馈的持续优化
ContextAttentionDetector是仪表盘——5维量化上下文健康度
HumanLoopTriggerDetector是安全阀——决定何时需要人工干预
ChatProcessBridge是桥梁——Chat与Process的双向同步

设计原则

整个架构遵循"检测先行、决策分层、执行可逆、人工兜底"的16字方针。每一个压缩操作都有对应的解压恢复，每一个自动决策都有HUMAN回路兜底，每一次上下文变更都有快照可回溯。这不是"最佳实践"——这是Agent可靠执行长流程的最低要求。

— 全文完 —
OODER Studio · Agent上下文治理技术博文
从6层模型到5维注意力检测的工程实践

DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

Kimi K3实测：2.8万亿参数MoE架构，Arena前端编程全球第一

DeepSeek技术社区

东莞GEO服务商选型避坑：系统架构五维横向对比

DeepSeek技术社区

GPT-5.6 代码生成与项目重构实测：一份偏理性的横向对比

DeepSeek技术社区

所有评论(0)

查看更多评论

wenzhangli7

@wenzhangli

已为社区贡献4条内容

Agent上下文治理从6层模型到5维注意力检测的工程实践

wenzhangli7

第1章：问题定义 — 为什么Agent需要上下文治理

1.1 核心矛盾：有限窗口 vs 无限流程

1.2 上下文膨胀的3个来源

来源1：活动产出物累积

来源2：对话历史膨胀

来源3：知识注入过量

1.3 无治理的典型问题

第2章：6层上下文模型 — 分层即治理

2.1 分层架构设计

2.2 各层详细定义

L1 SYSTEM层

L2 PROCESS层

L3 KNOWLEDGE层

L4 HISTORY层

L5 WORKING层

L6 EPHEMERAL层

2.3 层间关系矩阵

第3章：3大决策点 — 压缩/分裂/合并

3.1 D1 压缩决策

3.2 D2 分裂决策

3.3 D3 合并决策

3.4 LLM参与条件

第4章：5维注意力检测 — 量化上下文健康度

4.1 为什么需要注意力检测

4.2 五个维度详解

维度1：容量维度（权重0.30）

维度2：层间重复维度（权重0.20）

维度3：知识有效性维度（权重0.20）

维度4：分支活跃度维度（权重0.15）

维度5：冲突密度维度（权重0.15）

4.3 综合注意力分数

第5章：HUMAN回路 — 4种触发×5级干预

5.1 为什么需要HUMAN回路

5.2 四种触发类型

5.3 五级交互级别

5.4 触发×干预矩阵

5.5 与human_confirm工具的级联映射

5.6 干预选项拆分

第6章：LLM工具链 — Function Calling驱动的上下文操作

6.1 工具设计原则

6.2 四大核心工具

context_inspect — 6层检视

context_compress — 压缩/解压/评估

context_branch — 分支评估/冲突解决/快照

human_confirm — HUMAN确认

6.3 五条工具链路

第7章：知识飞轮 — 上下文治理的知识闭环

7.1 知识不是静态的

7.2 四阶段闭环

阶段1：知识生产

阶段2：知识入库

阶段3：知识消费

阶段4：知识反馈

7.3 知识置信度与注意力检测的联动

第8章：工程实现 — 关键代码架构

8.1 ContextLayerManager — 6层读写引擎

8.2 ContextCompressor — 动态压缩引擎

8.3 ContextAttentionDetector — 5维检测引擎

8.4 HumanLoopTriggerDetector — 4触发×5级干预

8.5 ActivityExtensionConfig — 6维配置模型

8.6 ChatProcessBridge — Chat↔Process双向同步

8.7 架构总结

所有评论(0)

温馨提示：您尚未绑定手机号

wenzhangli7