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

OODER Studio · 2026年7月 · 深度技术博文第1章问题定义 — 为什么Agent需要上下文治理1.1 核心矛盾有限窗口 vs 无限流程LLM的上下文窗口是一个刚性约束。GPT-4的128K tokens、Claude的200K tokens看起来很大但当Agent执行一个包含数十个活动的长流程时上下文消耗速度远超想象。一个典型的企业级审批流程可能包含流程定义JSON3K-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 SYSTEMSYSTEMAgent身份与核心约束角色定义、安全边界、不可变规则L2 PROCESSPROCESS流程结构定义BPM流程图、活动拓扑、网关定义L3 KNOWLEDGEKNOWLEDGE领域知识注入RAG检索结果、知识图谱、领域规则L4 HISTORYHISTORY执行历史记录已完成活动的产出、决策日志L5 WORKINGWORKING当前工作空间当前活动输入/输出、中间变量L6 EPHEMERALEPHEMERAL临时计算缓冲工具调用参数、推理中间态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 tokensL4 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临时·不持久化·不继承调用后清除生命周期长 → 短压缩强度弱 → 强图26层上下文金字塔 — 顶层共享不变成略底层临时强压缩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 且无保留键冲突 → 纯规则压缩无需LLMD1-LLM增强压力比 0.6-1.0 或涉及语义判断 → LLM生成摘要D2-LLM分支AND_SPLIT时需要LLM理解分支语义差异D3-冲突自动策略无法解决 → LLM评估HUMAN回路开始活动AD1XORANDD2分裂分支B1分支B2ANDD3合并活动C结束压缩检测0.6不压缩0.8压缩图33大决策点在流程中的位置 — D1压缩在每步前D2分裂在AND_SPLITD3合并在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图45维注意力雷达图 — 红色虚线为0.6阈值蓝色区域为实际检测值第5章HUMAN回路 — 4种触发×5级干预5.1 为什么需要HUMAN回路上下文治理不是纯技术问题——压缩什么、保留什么、冲突如何解决这些都涉及业务语义判断。纯自动化可能做出技术上正确但业务上错误的决策。HUMAN回路提供了人在环中的安全阀。5.2 四种触发类型触发类型标识触发时机典型场景设计时触发DESIGN_TIMEBPM流程设计阶段定义活动阈值、保留键、压缩策略运行时触发RUNTIME流程执行中注意力分数低于阈值、压缩前确认质量触发QUALITY产出质量检测输出置信度低、推理链断裂冲突触发CONFLICTAND_JOIN合并分支间key冲突、策略不一致5.3 五级交互级别级别标识说明用户感知L1AUTO_ALLOW自动执行无需人工确认无感知L2MICRO_SUGGESTION微提示不阻塞执行非阻塞提示L3DIFF_PREVIEW变更预览用户可快速确认阻塞预览L4EXPLICIT_APPROVAL明确审批需用户主动确认阻塞确认L5AUTO_DENY自动拒绝禁止执行操作被阻止5.4 触发×干预矩阵AUTO_ALLOWMICRO_SUGGESTIONDIFF_PREVIEWEXPLICIT_APPROVALAUTO_DENYDESIGN_TIME默认策略生效策略建议配置变更预览关键规则修改非法配置RUNTIME常规压缩轻度过载提示压缩变更预览核心上下文压缩SYSTEM层修改QUALITY质量达标质量波动提示输出修正预览重大输出变更安全违规CONFLICT自动解决冲突提示解决方案预览关键冲突决策不可调和冲突5.5 与human_confirm工具的级联映射触发类型和干预级别最终通过human_confirm工具落地。级联规则L1 AUTO_ALLOW → 不调用human_confirmL2 MICRO_SUGGESTION → 调用human_confirm(modesuggestion)L3 DIFF_PREVIEW → 调用human_confirm(modediff_preview)L4 EXPLICIT_APPROVAL → 调用human_confirm(modeexplicit_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面板运行时人工审批决策解决冲突触发类型 → 干预级别 → 工具级联 → 干预角色干预级别越高人类参与度越深自动化程度越低高自动化 ←→ 高人工介入图5HUMAN回路 — 触发类型×干预级别×工具级联×干预角色完整映射第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.0context_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评估→知识重注入是时间链路1D1自动context_inspectcontext_compress✓ 无LLM参与链路2D1-LLM增强context_inspectcompress(evaluate)LLM判断context_compress链路3D2-LLM分支context_branch(snap)context_inspectLLM评估分裂执行链路4D3冲突context_branch(eval)context_branch(resolve)human_confirm链路5知识反馈context_inspect(KNOW)LLM评估知识重注入工具调用LLM参与调用方向图65条工具链路调用时序图 — 从左到右按时间顺序执行第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 MapContextLayer, LayerStorage layers; private final String processInstanceId; private final ListString 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(ListContextSnapshot snapshots) { MergeResult result new MergeResult(); // HISTORY层按时间线交错合并 result.mergeHistory(interleaveByTimestamp(snapshots)); // WORKING层冲突检测 ListConflict 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, SetString retainKeys, CompressStrategy strategy) { LayerStorage storage getStorage(layer); CompressResult result new CompressResult(); // 1. 保留键完整保留 MapString, Object retained storage.retainAll(retainKeys); // 2. 按策略压缩其余内容 MapString, 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, SetString keys) { MapString, 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. 阈值配置workingThresholdWORKING层字符数阈值2. 保留键配置retainKeys压缩时必须保留的key列表3. 压缩策略compressStrategySUMMARY/ARCHIVE/AGGRESSIVE4. 干预级别interactionLevel该活动的最小干预级别5. 知识需求knowledgeRequirements该活动需要的知识类型和数量6. 分支策略branchStrategy分裂/合并时的继承和冲突策略public class ActivityExtensionConfig { private int workingThreshold 12000; private SetString retainKeys new HashSet(); private CompressStrategy compressStrategy CompressStrategy.SUMMARY; private InteractionLevel minInteractionLevel InteractionLevel.AUTO_ALLOW; private ListKnowledgeRequirement knowledgeRequirements new ArrayList(); private BranchStrategy branchStrategy BranchStrategy.INHERIT_ALL; }8.6 ChatProcessBridge — Chat↔Process双向同步ChatProcessBridge解决LLM-Chat与BPM-Process之间的上下文同步问题Chat→ProcessLLM推理产出写入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维注意力检测的工程实践