方案选型对比

1. 方案概览

针对动态上下文载入问题，业界已经发展出多种解决方案。本节将对比分析四种主流方案：

2. 详细方案分析

2.1 Monolithic Loading（整体加载）

工作原理： 在每次API调用前，将所有可能需要的上下文信息一次性注入System Prompt。

# 伪代码示例
system_prompt = f"""
{agent_identity}  # 1000 tokens
{all_tools_schema}  # 5000 tokens
{all_skills}  # 3000 tokens
{workspace_files}  # 8000 tokens
{conversation_history}  # 4000 tokens
"""

优点：

• 实现简单，无需复杂的上下文管理逻辑
• 模型始终能看到完整信息（理论上）
• 调试容易，System Prompt就是最终形态

缺点：

• Token消耗巨大（20K+ tokens/轮）
• 成本高（$0.06-0.15/轮）
• “Lost in the Middle”问题严重
• 延迟大（TTFT长）

适用场景：

• 简单的一次性任务
• 原型验证阶段
• 上下文需求确实很小的场景

2.2 Progressive Loading（渐进式加载）

工作原理： 将上下文分为多个层次，基础层始终加载，其他层按需动态载入。

# 三层渐进加载示例
class ProgressiveContextManager:
    def __init__(self):
        self.l1_navigation = self.load_core_identity()  # 始终加载
        self.l2_skills_registry = self.load_skill_summaries()  # 技能摘要始终加载
        self.l3_execution = {}  # 延迟加载
    
    def assemble_context(self, user_intent):
        context = self.l1_navigation + self.l2_skills_registry
        
        # 根据意图动态加载
        required_skills = self.identify_skills(user_intent)
        for skill in required_skills:
            context += self.load_skill_detail(skill)
        
        return context

优点：

• Token效率高（可节省90%+）
• 减少噪声，提高关键信息可见性
• 模块化，易于维护和扩展
• 支持大规模工具集和技能库

缺点：

• 架构复杂度高
• 需要准确的意图识别
• 首次实现成本较高
• 需要额外的上下文组装开销

适用场景：

• 复杂的多工具Agent系统
• 大规模代码库助手
• 长会话对话系统
• 成本敏感的生产环境

实际效果： 根据William Zujkowski的实践：

• Token使用量：150K → 2K-8K（节省95%）
• 成本：$4.50/会话 →$0.06/会话
• 准确率：保持不变或略有提升

2.3 RAG-based Assembly（基于检索的组装）

工作原理： 使用向量检索动态获取与当前查询最相关的上下文片段，而非预加载全部内容。

# RAG-based上下文组装
class RAGContextManager:
    def __init__(self):
        self.vector_store = VectorStore()
        self.core_identity = load_core_identity()  # 核心身份始终加载
    
    def assemble_context(self, user_query):
        # 检索相关内容
        relevant_chunks = self.vector_store.similarity_search(
            query=user_query,
            k=5,
            filter={"type": ["tool_doc", "skill_desc", "memory"]}
        )
        
        # 组装上下文
        context = self.core_identity
        for chunk in relevant_chunks:
            context += chunk.content
        
        return context

优点：

• 高度动态，精确匹配当前需求
• 支持大规模知识库
• 可跨会话保持记忆
• 检索结果可解释、可调试

缺点：

• 需要额外的向量数据库基础设施
• 检索质量依赖嵌入模型
• 可能遗漏关键信息（检索失败）
• 延迟增加（检索时间）

适用场景：

• 知识密集型问答系统
• 大规模文档助手
• 需要跨会话记忆的场景
• 已有向量数据库基础设施的环境

2.4 Hybrid Approach（混合方案）

工作原理： 结合Progressive Loading和RAG的优势，根据场景选择最佳策略。

# 混合方案示例
class HybridContextManager:
    def __init__(self):
        self.progressive_loader = ProgressiveContextManager()
        self.rag_retriever = RAGContextManager()
        self.core_identity = load_core_identity()
    
    def assemble_context(self, user_intent, user_query):
        context = self.core_identity
        
        # L2: Progressive Loading for skills
        skills_context = self.progressive_loader.load_relevant_skills(user_intent)
        context += skills_context
        
        # L3: RAG for memories and docs
        if self.needs_memory(user_intent):
            memory_context = self.rag_retriever.retrieve_memories(user_query)
            context += memory_context
        
        # L4: On-demand tool loading
        if self.needs_tools(user_intent):
            tool_context = self.load_required_tools(user_intent)
            context += tool_context
        
        return context

OpenClaw 2026.3.7+的实现： 通过ContextEngine插件架构，支持：

• Legacy Engine：Sliding-window + Summarization
• RAG Engine：基于检索的上下文组装
• Custom Engine：用户自定义策略

优点：

• 灵活性最高
• 可根据场景动态选择策略
• 平衡成本和效果
• 插件化架构便于扩展

缺点：

• 架构最复杂
• 需要精细的策略调优
• 调试难度较高

适用场景：

• 企业级生产环境
• 复杂的Agent生态系统
• 需要多种记忆类型的场景

3. 决策矩阵

3.1 评估维度

3.2 量化评分（1-5分）

计算方式：加权总分 / 总权重

3.3 场景化推荐

flowchart TD
    A[选择动态上下文方案] --> B{项目阶段?}
    B -->|原型/MVP| C[Monolithic Loading]
    B -->|生产环境| D{知识库规模?}
    
    D -->|小规模<br/><10工具| E[Progressive Loading]
    D -->|大规模<br/>>100工具| F{已有向量DB?}
    
    F -->|是| G[RAG-based或Hybrid]
    F -->|否| H[Progressive Loading]
    
    D -->|企业级<br/>多类型记忆| I[Hybrid Approach]
    
    C --> J[快速迭代<br/>验证想法]
    E --> K[平衡方案<br/>推荐首选]
    G --> L[精准检索<br/>知识密集]
    H --> M[渐进扩展<br/>避免过度设计]
    I --> N[终极方案<br/>灵活性最高]

3.4 OpenClaw的选择

OpenClaw在2026.3.7版本中选择了Hybrid Approach的插件化实现：

1. 默认引擎：Legacy（Sliding-window）保持向后兼容
2. 可选引擎：RAG-based Assembly支持知识密集型场景
3. 扩展能力：ContextEngine插件接口允许自定义策略

这种设计的智慧在于：

• 不强制用户接受特定策略
• 渐进式采用：可以从Legacy逐步迁移到更高效的方案
• 生态支持：社区可以贡献不同的ContextEngine实现

4. 关键权衡

4.1 Token节省 vs 信息完整性

建议：从平衡策略开始，根据实际效果调整。

4.2 架构复杂度 vs 长期收益

早期投入: High
        |
        v
    [Progressive/Hybrid架构]
        |
        v
长期收益: Very High (成本节省、可维护性)

vs

早期投入: Low
        |
        v
    [Monolithic]
        |
        v
长期成本: Very High (持续的高token消耗、技术债务)

结论：对于计划长期运行的Agent系统，前期投入Progressive Loading架构是值得的。

参考资料

• Dynamic Context Loading in AI Agents - Dixon - Claude与Cursor动态加载对比
• Reducing Context Bloat with Dynamic Context Loading - Moncef Abboud - MCP场景的动态加载
• Progressive Disclosure in AI Agents - Marta Fernández García - 渐进式披露技术详解