上下文工程：让每个 token 都发挥作用

2026 年，模型上下文窗口从 8K 涨到 2M token，但「上下文够长」不等于「上下文够好」。随便往 prompt 里堆信息，模型会失焦、延迟变长、账单爆炸、甚至把关键信息淹没在噪音里导致回答变差。「上下文工程」（Context Engineering）是Prompt 工程之后的一门新学科：它讨论的是如何在有限的 token 预算里编排最适合当前任务的信息，让每个 token 都产生价值。

这篇文章拆解上下文工程五个核心动作——预算分配、注入策略、压缩与摘要、裁剪与缓存、对话管理——给你一套可以直接落地的方法论。

一、Token 预算：先做分配再做内容

上下文工程第一步不是写 prompt，是规划预算。一个请求的 token 总额度，按下面五块分配：

预算块	典型占比	作用
系统提示词（人设、规则）	5-10%	定基调、约束行为
任务说明与上下文	20-30%	当前任务的具体描述，可能含 RAG 检索结果
对话历史	30-50%	多轮上下文（关键是控制长度）
工具调用结果	10-20%	外部数据（搜索结果、API 响应）
预留输出空间	20-30%	留给 LLM 输出的空间

关键约束：输入 + 输出 ≤ 窗口大小。但实际使用时输入不应该逼近窗口极限——Llama 3、Claude 4、GPT-5 都有「中段失忆」问题（lost-in-the-middle），把关键信息塞到 100K token 后段效果比放中段差很多，关键信息放前段、放后段，不是一味往里堆。

实际策略：把系统提示与任务说明放前面，最新用户问题与最相关 RAG 片段放后面，对话历史居中。这个顺序在大多数模型上效果最好，不是「按时间顺序」堆历史那么简单。

二、注入策略：不是把所有检索结果都丢进去

RAG 场景常见的错误是「检索回来 10 块内容全部拼进 prompt」——结果 LLM 失焦、关键信息被淹没。上下文工程里检索注入有几个原则：

1. Top-N 限制：3-5 块几乎总是比 10 块好。RAG 系统评估指标里检索命中率（recall@k）和忠实度（faithfulness）跟 N 不线性正相关，更多块更多噪音。《RAG 实战指南：用 pgvector 搭建企业知识库》有完整 RAG 评估方法。
2. 每块加来源标注：「【资料 1】来源：XX 手册\第三章 ……」，让 LLM 输出时可引用、便于溯源。这条不动模型、不动检索算法，只动模板就提升引用准确率。
3. 相关性分数配套：如果向量检索返回分数，按分排序后只注入 top-3；分数低于阈值的不注入、让模型回答「资料中没有相关信息」而不是胡编。
4. 区分「事实性资料」和「讨论性内容」：把前者用「请只根据以下资料回答」约束，后者用「参考以下背景信息回答，但可使用外部知识」放宽。别让一个 prompt 既严格又宽松。

三、压缩与摘要：让 20 轮对话变成「上下文」

多轮对话里历史越长，输入 token 越涨，账单线性涨、效果反向跌。两个对策：

1. 滚动摘要（rolling summary）：对话超过 N 轮后，把最早的 M 轮用一个小模型生成摘要，替换原始历史。摘要压缩比目标 5:1——原始 3000 token 压成 600 token 的「已讨论内容 + 用户的核心诉求 + 当前进展」。下次请求时只发摘要 + 最新 5-8 轮原文。
2. 关键信息提取：对结构化任务（如工单系统、表单填写），每轮提取出结构化字段（如「用户已提供：姓名、地址、订单号」）单独保存，摘要部分只保留「软信息」——情绪、诉求变化、未解决问题。

def compress_history(history, keep_recent=5):
    if len(history) <= keep_recent * 2:
        return history
    to_compress = history[:-keep_recent * 2]  # 除最近几轮外全部
    summary = llm.summarize(to_compress, max_tokens=500)
    return [{"role": "system", "content": f"之前对话摘要：{summary}"}] + history[-keep_recent * 2:]

这套做法的隐性收益另一个角度：你对长对话的成本可预测——任何对话压缩后大致都是 1500-2500 token，输入增长有界。可预测的成本配上可观测的延迟，才知道你的业务单位经济成立不。《AI API 成本优化 12 招》关于历史压缩的部分讲了更多细节。

四、工具结果裁剪：最容易被忽略的预算黑洞

Function Calling 的工具返回内容是隐性的 token 黑洞：

• 调一次搜索 API 返回 10 条结果，每条带标题、URL、正文摘要，轻松 3000 token 进上下文。
• 查数据库返回 50 行数据，每行 10 字段，又是 2000 token。
• 调一次地图 API 返回周边 20 个 POI 的详细信息。

但这些原始返回内容里，真正给 LLM 决策的必要信息往往只有 10-20%。上下文工程要求在工具返回与 prompt 拼装之间加一层裁剪器：

def trim_search_results(raw, max_items=3, max_chars=200):
    items = raw.get("results", [])[:max_items]
    return [{"title": i["title"], "snippet": i["snippet"][:max_chars]} for i in items]

# 不要把 raw 拼进 prompt
# 调用工具后立即裁剪，再把裁剪后的结果拼入 prompt
trimmed = trim_search_results(tool_result)
prompt += json.dumps(trimmed, ensure_ascii=False)

这条规则简单但威力巨大：很多团队一上 Function Calling 账单陡涨，根因不在调用次数，在每次工具结果都全量进 prompt。裁剪一下输入 token 直降 60%，效果往往不变。

五、对话历史管理：在哪里存怎么传

LLM 是无状态的，上下文工程离不开你自己的存储。两种选择：

1. 全量重传：每次请求把完整对话历史数组重新发给 LLM。简单、不需要在模型侧操心，除了 token 成本线性增长以外没坏处。适合 50 轮以内的短对话。
2. RAG 化历史：对话历史向量库化，每次请求只取与当前问题最相关的 k 轮历史。适合长对话——客服全程跟一单、陪伴对话。RAG 和原对话历史的拼接方式详见《RAG 还是微调？》。

另外两个不可忽略的实践：

• 会话状态托管在服务端：client 只持有 session_id，避免刷新丢历史。Redis / Postgres / 任何 KV 都可以。这是基础架构问题，详见《10 分钟给你的应用接入 AI 聊天功能》。
• 给用户可见的「历史窗口大小」设定：不做用户看到「请继续」按钮无意义负担；做也不要让历史自行无限长——限制最近 N 轮可见、提供「查看更多」入口。

六、Prompt 缓存：再省一笔

2026 年的旗舰模型大多支持 prompt caching——重复的固定前缀缓存命中后输入价格打 5 折甚至更低。上下文工程对 prompt 缓存的两个设计要点：

1. 固定前缀放最前面：系统提示词、固定的任务模板、不变的工具描述。这些前缀可以被缓存，命中后大幅降本。
2. 可变内容放后面：动态检索的 RAG 片段、对话历史、当前用户输入。这部分每次都变，让缓存从可变点之后失效。

messages = [
    {"role": "system", "content": LONG_SYSTEM_PROMPT},  # 可被缓存
    {"role": "system", "content": TOOL_DESCRIPTIONS},  # 可被缓存
    {"role": "system", "content": f"参考资料：{rag_context}"},  # 不可被缓存
    {"role": "user", "content": user_input},
]

按上面的顺序写，缓存命中率从 0 提升到 80% 的项目很常见。《LLM 缓存技术：前缀缓存与语义缓存实战》有完整的缓存设计与命中率监控方法。

七、上下文工程的隐性收益：稳定性

整理上下文结构的最大收益不是 token 成本下降，而是响应稳定性上升：

• 同一任务、不同实例调用，输出更稳定——因为关键信息有秩序。
• 升级到新模型时迁移容易——因为你的 prompt 结构不依赖某模型的稀有能力。
• A/B 测试与评估更可靠——因为变量更少，更容易归因哪个改动影响效果。

把上下文工程视为架构问题而非「调一下 prompt」的小事，是 AI 应用成熟度的一个分水岭。做好的团队会发现模型能力「足够」反而是常态，不够的是它们如何把模型能力用好。

八、团队规范模板：上下文工程不只是代码

团队级别的上下文工程，需要一份规范模板对齐每个工程师的写法：

1. prompt 注释结构：每个 LLM 调用处附注释写明：任务、预期输出 schema、预期 token 占用、降级路径。
2. 统一上下文构造函数：业务代码不直接拼 prompt，统一走 build_context(task, history, tools)。所有裁剪、压缩、缓存命中都在函数内集中处理。
3. Token 预算声明：每个 build_context 入口写明最大输入预算、最大输出预算。超出预算就触发降级。
4. 归因日志：每次 LLM 调用记录 token 分解——系统多少、工具结果多少、对话历史多少、检索注入多少。成本归因是上下文工程上线后省不起的一环。

这套规范建立后你会发现团队都在「同一套语言」上思考 prompt——而不是每个人各玩各的玄学调法。

九、上下文工程的不变量

• 每个 token 都要产生价值——值得的不是「便宜」是「值得占这个位置」。
• 结构 > 长度——同一信息放对位置比多塞内容更重要。
• 裁剪比扩展更值钱——能去掉的内容一定去掉，省一次输入。
• 缓存优先级高于优化——能命中的 prompt 不用调结构就半价。

上下文工程的本质是有限预算下的最优信息编排，这听起来工程化但没有玄学。做熟一次你会发现自己对模型能力的「上限和下限」有了完全不同的判断——很多「模型不够强」的吐槽，其实是上下文没编排好。先拿 DrAI 的免费额度跑通一个 build_context 函数，逐步把上面五层引入你的生产 prompt：用真实 token 账单判断收益，不要拍脑袋。现在注册 DrAI开始你的上下文工程实践。