上下文的线性成本问题
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，且线性增长。
常见的三种应对策略：
| 策略 | 做法 | 直觉上的代价 |
|---|---|---|
| Naive | 全量历史传入 | 贵，但准 |
| Sliding Window | 只保留最近 N 条 | 省，但可能丢信息 |
| Rolling Summary | LLM 压缩旧消息 + 保留近期 | 均衡？ |
本文用真实 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:
