AI Agent 的上下文窗口管理——如何让 Agent 在有限 token 内做更多事

AI Agent 的上下文窗口管理------如何让 Agent 在有限 token 内做更多事

问题：Agent 跑着跑着就"失忆"了

GPT-4o 有 128K 上下文窗口，Claude 有 200K。看起来很大，但跑一个复杂的 Agent 任务，token 消耗速度远超预期。

我做过一个测试：让一个 ReAct Agent 完成"调研某个开源项目并写一份技术评估报告"的任务。Agent 调用了 12 次工具，每次工具返回的内容平均 2000 token。加上系统提示词 1500 token、每轮的 reasoning 输出约 800 token，跑到第 8 轮时，上下文已经超过 40K token。到第 15 轮，逼近 80K。

问题不是"装不下"------128K 理论上够。问题是：

1. 成本线性增长 。每轮都把完整历史发给 API，第 15 轮的请求包含了前 14 轮的所有内容。按 GPT-4o 的 $2.5\; /\; 1\; M\; i\; n\; p\; u\; t\; t\; o\; k\; e\; n\; 计算，一个任务跑下来可能花掉\; 2.5/1M\; input\; token\; 计算，一个任务跑下来可能花掉$2.5/1Minputtoken计算，一个任务跑下来可能花掉0.3-0.5。批量跑 100 个任务，成本就不可忽视了。
2. 注意力被稀释。大模型在长上下文中的表现并不均匀。Needle-in-a-Haystack 测试已经证明，信息放在中间位置时，模型的召回率会下降 10%-30%。Agent 的早期工具调用结果恰好就在"中间"位置。
3. 延迟增加。上下文越长，首 token 延迟（TTFT）越高。128K 上下文的 TTFT 通常是 8K 上下文的 3-5 倍。

所以问题很明确：怎么在不丢失关键信息的前提下，控制上下文的增长速度？

三种实用方案

我在生产环境中试过多种方法，最后沉淀下来三种：滑动窗口 + 摘要、工具输出截断、按需注入。

方案一：滑动窗口 + 摘要

思路很简单：只保留最近 N 轮对话，更早的内容压缩成一段摘要。

from openai import OpenAI

client = OpenAI()

def summarize_messages(messages: list[dict], max_tokens: int = 300) -> str:
    """把一组消息压缩成摘要"""
    content = "\n".join(
        f"[{m['role']}]: {m['content'][:500]}" for m in messages
    )
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "用中文总结以下对话的关键信息，保留所有数据和结论，去掉过程细节。"},
            {"role": "user", "content": content}
        ],
        max_tokens=max_tokens
    )
    return resp.choices[0].message.content

def sliding_window(messages: list[dict], window_size: int = 6) -> list[dict]:
    """保留最近 window_size 轮，其余压缩为摘要"""
    system_msg = messages[0]  # 系统提示词始终保留
    conversation = messages[1:]
    
    if len(conversation) <= window_size * 2:
        return messages  # 还没超，原样返回
    
    old_messages = conversation[:-window_size * 2]
    recent_messages = conversation[-window_size * 2:]
    
    summary = summarize_messages(old_messages)
    
    return [
        system_msg,
        {"role": "user", "content": f"[之前的对话摘要]\n{summary}"},
        *recent_messages
    ]

window_size=6 是我反复调整后的值。太小（比如 3）会丢失刚发生的上下文，Agent 容易重复做已经做过的事。太大（比如 15）起不到压缩效果。6 轮在大多数任务中够用。

摘要用 gpt-4o-mini 生成，成本低，速度快。一次摘要大约 0.001 美元，但能节省后续每轮 5000-10000 token 的输入。

方案二：工具输出截断

Agent 调用搜索 API、读取文件、抓取网页，返回的内容经常有大段无用信息。一个网页抓取结果可能有 8000 token，但 Agent 真正需要的信息只有 500 token。

import tiktoken

encoder = tiktoken.encoding_for_model("gpt-4o")

def truncate_tool_output(content: str, max_tokens: int = 1500) -> str:
    """截断工具输出，保留前后各一部分"""
    tokens = encoder.encode(content)
    if len(tokens) <= max_tokens:
        return content
    
    # 保留前 60% 和后 20%，中间截断
    head_count = int(max_tokens * 0.6)
    tail_count = int(max_tokens * 0.2)
    
    head = encoder.decode(tokens[:head_count])
    tail = encoder.decode(tokens[-tail_count:])
    removed = len(tokens) - head_count - tail_count
    
    return f"{head}\n\n[...已省略 {removed} tokens...]\n\n{tail}"

def smart_truncate(content: str, query: str, max_tokens: int = 1500) -> str:
    """基于相关性的截断：保留与查询相关的段落"""
    paragraphs = content.split("\n\n")
    query_words = set(query.lower().split())
    
    scored = []
    for p in paragraphs:
        p_words = set(p.lower().split())
        overlap = len(query_words & p_words)
        scored.append((overlap, p))
    
    scored.sort(key=lambda x: x[0], reverse=True)
    
    result = []
    current_tokens = 0
    for score, paragraph in scored:
        p_tokens = len(encoder.encode(paragraph))
        if current_tokens + p_tokens > max_tokens:
            break
        result.append(paragraph)
        current_tokens += p_tokens
    
    return "\n\n".join(result)

smart_truncate 比简单截断更好。它根据段落和当前查询的词汇重叠度排序，优先保留相关段落。在实际使用中，这个方法把工具输出的平均 token 数从 3200 降到了 1100，Agent 的任务完成率没有明显下降。

更精确的做法是用 embedding 计算相似度，但对于大多数场景，词汇重叠已经够用，还省掉了 embedding API 的调用。

方案三：按需注入

不要一开始就把所有背景信息塞进系统提示词。把信息拆成模块，Agent 需要时再注入。

CONTEXT_MODULES = {
    "code_style": "代码规范：使用 black 格式化，类型注解必须完整，docstring 用 Google 风格...",
    "project_arch": "项目结构：src/ 下按领域划分模块，每个模块有 models/、services/、api/ 三层...",
    "api_docs": "API 文档：POST /users 创建用户，需要 name 和 email 字段...",
    "db_schema": "数据库：users 表有 id, name, email, created_at 四个字段...",
}

def build_system_prompt(base_prompt: str, active_modules: list[str]) -> str:
    """根据当前任务阶段，拼装系统提示词"""
    parts = [base_prompt]
    for mod in active_modules:
        if mod in CONTEXT_MODULES:
            parts.append(f"\n---\n{CONTEXT_MODULES[mod]}")
    return "\n".join(parts)

# Agent 在写代码阶段，只注入 code_style 和 project_arch
prompt = build_system_prompt(
    "你是一个 Python 开发助手。",
    ["code_style", "project_arch"]
)

# Agent 在调试 API 阶段，换成 api_docs 和 db_schema
prompt = build_system_prompt(
    "你是一个 Python 开发助手。",
    ["api_docs", "db_schema"]
)

这个方法在编码类 Agent 中效果最好。一个典型的项目可能有 5000 token 的背景信息，但 Agent 在某个具体步骤中只需要其中 1000-1500 token。动态注入可以把系统提示词的平均大小降低 60%。

把三种方案组合起来

单独用一种方案效果有限。组合使用才能发挥最大价值：

class ContextManager:
    def __init__(self, window_size=6, max_tool_tokens=1500):
        self.window_size = window_size
        self.max_tool_tokens = max_tool_tokens
        self.messages = []
        self.active_modules = []
    
    def add_message(self, role: str, content: str):
        if role == "tool":
            content = truncate_tool_output(content, self.max_tool_tokens)
        self.messages.append({"role": role, "content": content})
    
    def set_modules(self, modules: list[str]):
        self.active_modules = modules
    
    def get_messages(self, base_prompt: str) -> list[dict]:
        system = build_system_prompt(base_prompt, self.active_modules)
        all_msgs = [{"role": "system", "content": system}] + self.messages
        return sliding_window(all_msgs, self.window_size)
    
    def token_count(self) -> int:
        text = "".join(m["content"] for m in self.messages)
        return len(encoder.encode(text))

踩坑经验

1. 摘要丢信息是不可避免的，关键是选择丢什么。

最初我直接让 LLM "总结对话"，结果它总是丢掉具体的数字和 URL。后来改成在摘要提示词里加一句"保留所有数据、数字、URL、文件路径"，情况好了很多。但仍然会偶尔丢东西。我的解决办法是维护一个独立的 key_facts 列表，把每轮提取的关键数据单独存储，不参与摘要压缩。

2. 截断位置比截断长度更重要。

最开始我用简单的前 N 个 token 截断。问题是很多网页的前 1000 token 是导航栏和版权声明。改成"前 60% + 后 20%"之后好了一些，但最佳方案还是基于相关性的 smart_truncate。

3. token 计算别用 len(text) / 4 估算。

中文文本的 token 比例和英文差异很大。一个中文字符通常是 1-2 个 token，不是 0.25 个。用 tiktoken 精确计算，别估算。我因为用估算值设了截断阈值，导致实际发送的 token 比预期多了 40%，白白多花了钱。

4. 滑动窗口的 window_size 要根据任务类型调。

代码生成任务，window_size 可以小一点（4-5 轮），因为每轮相对独立。调研类任务需要更大的窗口（8-10 轮），因为前后轮之间的依赖关系更强。我现在的做法是根据任务类型动态设置，而不是用一个固定值。

5. 别在每轮都做摘要。

摘要本身也有成本------gpt-4o-mini 的一次调用大约 50-100ms 延迟加上 token 费用。我设了一个阈值：只有当历史消息超过 window_size * 3 时才触发摘要。频繁摘要反而拖慢了 Agent 的响应速度。

---

上下文管理没有银弹。不同任务需要不同策略，代码里的参数也需要根据实际效果反复调整。但把这三种方法组合起来用，在我的场景中把平均 token 消耗降低了 55%，任务完成率只下降了 3%。对于大多数 Agent 应用来说，这个 trade-off 是值得的。