📐 Context Window Management

什么是Context Window？

Context Window是LLM一次能处理的最大Token数——它就像Agent的短期记忆容量。超过这个限制，旧的内容会被截断，Agent就会"忘记"之前的信息。

主流模型上下文窗口对比

模型	上下文窗口	约等于
GPT-4o	128K	~300页书
Claude 3.5 Sonnet	200K	~500页书
Gemini 1.5 Pro	1M	~2500页书
GPT-4o-mini	128K	~300页书
Llama 3 70B	8K	~20页书

上下文窗口的组成

# 上下文窗口分配策略（128K模型）
context_budget:
  system_prompt: 4000      # 系统提示 4K tokens
  tool_definitions: 8000   # 工具定义 8K tokens
  conversation: 80000      # 对话历史 80K tokens
  input_max: 30000         # 用户最大输入 30K tokens
  output_max: 6000         # 预留输出 6K tokens
  # 总计：128K

上下文管理五大策略

策略1：滑动窗口（Sliding Window）

# 只保留最近N轮对话
context_management:
  sliding_window:
    max_turns: 20          # 保留最近20轮
    summary_threshold: 15  # 超过15轮开始摘要
    preserve_system: true  # 系统提示始终保留
    
# 实现效果：
# 轮次1-15 → 压缩为摘要
# 轮次16-20 → 完整保留

策略2：智能摘要（Smart Summarization）

# OpenClaw自动摘要
context_management:
  summarization:
    enabled: true
    trigger: "token_ratio > 0.7"  # 使用超过70%时触发
    
    summary_prompt: |
      请将以下对话历史摘要为关键要点：
      - 用户的核心需求
      - 已完成的操作
      - 重要的决策和结论
      - 待办事项
      
    preserve_keys:
      - "用户偏好"
      - "重要结论"
      - "待办事项"

策略3：按需检索（Retrieval on Demand）

# 不把所有内容塞进上下文，而是需要时再检索
context_management:
  retrieval:
    enabled: true
    strategy: "hybrid"     # 混合检索
    
    # 最近的对话：直接保留
    recent_context:
      turns: 5
      
    # 较早的对话：通过向量检索
    historical_context:
      embedding: true
      top_k: 3
      threshold: 0.7

策略4：工具定义优化

# 减少工具定义占用的Token
# 优化前：每个工具完整定义 ~500 tokens
# 优化后：只加载可能用到的工具

tool_management:
  loading_strategy: "lazy"     # 按需加载
  max_tools_in_context: 10     # 最多10个工具定义
  
  # 工具分组
  groups:
    coding: [exec, read, write, edit, browser]
    communication: [message, tts]
    search: [web_search, web_fetch]
    
  # 根据用户意图加载对应分组
  auto_load: true

策略5：提示词压缩

# 系统提示词优化
# 优化前：冗长描述 ~3000 tokens
# 优化后：精炼表达 ~1000 tokens

# ❌ 冗长版
"""
你是一个专业的AI助手，你的主要职责是帮助用户完成各种任务。
当你收到用户的请求时，你应该仔细分析需求，然后使用可用的工具来完成任务。
如果遇到不确定的情况，你应该主动询问用户以获取更多信息。
每次使用工具后，你应该向用户报告结果...
"""

# ✅ 精炼版
"""
你是AI助手。分析需求→选工具→执行→报告。
不确定就问。简明有效。
"""

Token计算技巧

# 快速估算Token数
# 英文：1 token ≈ 4 characters ≈ 0.75 words
# 中文：1 token ≈ 1.5 characters ≈ 0.5 words

# 常用内容Token估算
token_estimates:
  system_prompt: "约250-500 tokens"
  tool_definition: "约200-500 tokens/工具"
  conversation_turn: "约100-500 tokens/轮"
  code_block_50_lines: "约1000-2000 tokens"
  a4_page_text: "约750 tokens"
  a4_page_chinese: "约500 tokens"

常见问题

Q: 上下文用完了会怎样？

A: 最早的消息会被截断。如果系统提示被截断，Agent会"忘记"自己的角色和规则。这就是为什么需要主动管理上下文。

Q: 越大的上下文窗口越好吗？

A: 不一定。更大的窗口意味着更多的Token消耗（成本）和更长的推理时间（延迟）。而且研究表明，LLM在处理超长上下文时，对中间部分的信息关注较弱（"Lost in the Middle"现象）。

Q: 如何检测上下文溢出？

A: OpenClaw会在日志中记录Token使用量。设置告警：当单次请求Token超过窗口的80%时触发。

最佳实践

1. 预留缓冲 - 永远不要用满100%的上下文，留15-20%
2. 系统提示精炼 - 越短越好，关键是清晰
3. 工具按需加载 - 不需要的工具别塞进上下文
4. 对话定期摘要 - 不要让对话历史无限增长
5. 监控Token使用 - 建立使用量的仪表盘
6. 选择合适模型 - 简单任务用小模型，省Token省钱

相关资源