Token管理

引言 Prompt工程关注"如何写好一条提示"，而上下文工程关注"如何设计Agent的整个认知环境"。在2026年，随着Agent需要处理越来越复杂的任务，单条Prompt的优化已经触及天花板。上下文工程——系统性地设计Agent在每一步推理时看到什么信息、以什么顺序、什么格式——成为了新的性能提升杠杆。 一、什么是上下文工程 1.1 从Prompt到Context Prompt工程是上下文工程的子集。一条Prompt包含在上下文中，但上下文远不止Prompt： Agent上下文 = System Prompt + 用户消息 + 对话历史 + 工具描述 + 检索到的记忆 + 工具调用结果 + 环境状态 + 元指令 每个组成部分都需要精心设计，任何一个部分的质量问题都会影响Agent的整体表现。 1.2 上下文预算 上下文窗口是有限的资源。2026年主流模型的上下文窗口为128K-2M tokens，但"能用"和"用好"是两回事： 过长上下文导致注意力分散：模型对中间部分的信息关注不足（“lost in the middle"问题） 成本与长度正相关：每多1000 tokens的输入，就多一份成本 延迟与长度正相关：更长的上下文意味着更长的处理时间 因此，上下文工程的核心是：在有限的预算内，让每一条信息都发挥最大价值。 二、上下文组装策略 2.1 上下文分区 将上下文分为不同的功能区，每个区有明确的职责： ┌─────────────────────────────────────┐ │ System Prompt (固定区) │ ← 身份、能力、规则 ├─────────────────────────────────────┤ │ Tool Descriptions (工具区) │ ← 可用工具的描述 ├─────────────────────────────────────┤ │ Retrieved Memory (记忆区) │ ← 检索到的相关记忆 ├─────────────────────────────────────┤ │ Conversation History (对话区) │ ← 对话历史 ├─────────────────────────────────────┤ │ Current Input (输入区) │ ← 用户当前输入 ├─────────────────────────────────────┤ │ Instructions (指令区) │ ← 当前步骤的具体指令 └─────────────────────────────────────┘ 2.2 动态上下文组装 不同任务、不同阶段需要不同的上下文结构： ...

一个真实案例 我们运营一个客服 Agent，日均处理 5000 次对话。优化前月成本约 $3,200，优化后降至 $680——降本 78%。以下是完整的优化路径。 成本构成分析 优化前月成本分布： ├── LLM API 调用 72% ($2,304) │ ├── 主模型 (GPT-4o) 58% │ ├── 嵌入模型 8% │ └── 审核模型 6% ├── 向量数据库 12% ($384) ├── 服务器/带宽 8% ($256) └── 监控/日志 8% ($256) 第一层：模型分级路由 不是所有请求都需要最强模型： class ModelRouter: def __init__(self): self.routes = { "simple_qa": { "model": "gpt-4o-mini", "criteria": lambda q: len(q) < 50 and not q.requires_tools }, "standard": { "model": "claude-3.5-sonnet", "criteria": lambda q: q.complexity < 5 }, "complex": { "model": "gpt-4o", "criteria": lambda q: True # fallback } } def route(self, query): for level, config in self.routes.items(): if config["criteria"](query): return config["model"] return "gpt-4o" # 效果：62% 的请求被路由到 mini 模型 # 月节省：$1,180 第二层：语义缓存 相似问题命中缓存，避免重复调用 LLM： ...