Agent 系列（22）：Context Engineering 深度——三种上下文管理策略的量化对比

上下文的线性成本问题

Agent 不是无状态的 API 调用——它需要记住对话历史。每一轮对话都会累积到上下文窗口里，直到触发两个问题：

Turn 1: 1K tokens ← 便宜 Turn 10: 5K tokens ← 还好 Turn 50: 25K tokens ← 开始贵了 Turn 100: 50K tokens ← 每次调用都是重新喂一遍历史

这不是理论问题。一个 30 轮的项目讨论对话，全量历史 ~2,500 tokens；100 轮之后这个数字是 ~8,000 tokens，且线性增长。

常见的三种应对策略：

本文用真实 benchmark 验证"直觉上的代价"是否准确。

Demo 设计

对话构造

30 轮项目讨论，覆盖数据库选型、缓存配置、迁移责任、部署平台、CI/CD、认证方案等 30 个技术决策。关键设计：重要决策刻意放在第 1-4 轮（最早期），后续才是"近期内容"。这样可以强制暴露上下文丢失问题。

三种策略实现

Strategy 1：Naive（基准）

defrun_naive(history:list,query:str,keywords:list[str])->StrategyResult:msgs=[SystemMessage(content=SYSTEM_PROMPT)]+history+[HumanMessage(content=query)]tokens=count_messages_tokens(msgs)t0=time.time()text=str(llm.invoke(msgs).content)returnStrategyResult(text,tokens,time.time()-t0,recall_score(text,keywords))

Strategy 2：Sliding Window（截断）

defrun_sliding_window(history: