如果把 2025 年的 AI 圈浓缩成一个词，那是 “Prompt Engineering”。把 2026 年上半年的 AI 圈浓缩成一个词，那一定是 “Context Engineering”（上下文工程）。

这个概念从 2025 年中由 Karpathy 和 Shopify CEO Tobi Lutke 推文带入主流，到 Anthropic 给出正式定义，再到 2026 年 2 月 OpenAI/Harness Engineering 的延伸——只用了不到 1 年。

为什么所有大厂都在讨论它？因为写好一句话的提示词已经不够了，真正决定 AI Agent 表现的是”它能看什么、看到什么”。

这篇文章要解决 3 件事：

  1. 认知升级：Context Engineering 到底解决什么问题、跟 Prompt Engineering 区别在哪
  2. 7 大核心策略：RAG、Memory、Tool Selection、压缩、隔离、动态注入、结构化输出，每个都配代码
  3. 3 个真实案例：用 LangChain 搭一个能”读 100 页 PDF 然后回答问题”的 Agent

读完全文你应该能用 Context Engineering 思路设计一个能在生产环境稳定运行的 AI Agent。

一、为什么 2026 年必须懂 Context Engineering

💡 Prompt Engineering 决定”一句话怎么写好”，Context Engineering 决定”整个任务过程模型能看到什么”。

读完本章你能得到什么：

  • 清楚区分 Prompt / Context / Harness 3 个概念
  • 明白为什么 Anthropic、OpenAI、Google 都在押注 Context Engineering
  • 判断自己 / 团队是否需要马上学这个技能

1.1 从 Prompt 到 Context：AI 工程语言的 3 次跃迁

按 163.com 那篇《从 Prompt 到 Loop》总结：

  • Prompt Engineering（2023 起）：人写指令、AI 执行，核心是”把话说清楚”
  • Context Engineering（2025 中起）：人退到设计信息供给，模型自主决定”看什么”
  • Harness Engineering（2026.2 起）：Harness 是缰绳/马鞍/路，约束 Agent 行为，让错误在结构上不可能发生

每次跃迁都是”人退一步、AI 进一步”的过程。2026 年不懂 Context Engineering，写提示词再精也跑不赢会设计上下文的团队。

1.2 Context Engineering 解决 3 个核心问题

  • 信息过载：128K 上下文窗口看着大，但 Agent 跑 20 轮就装满了
  • 无关噪声：把不相关的工具结果塞进上下文，模型反而被干扰
  • 幻觉/失忆：长对话后模型忘记早期关键信息，开始编造

GITCODE 那篇《Harness、SDD、Context Engineering 本质》说得很直接：模型在执行任务时”看到”了什么信息，决定它的输出质量。

1.3 真实场景：3 类必须上 Context Engineering 的情况

  • 多轮对话客服：30 轮后模型忘了用户订单号、地址、需求
  • 长文档分析：100 页 PDF 一次性塞进去，模型读不完、读不准
  • 多 Agent 协作：5 个 Agent 互相传话，上下文越来越大、噪音越来越多

1.4 跟 Prompt Engineering 区别

维度 Prompt Engineering Context Engineering
关注点 怎么把任务说清楚 模型能”看”到什么
时机 任务开始时一句话 整个任务生命周期
内容 用户输入 + 指令 检索结果 + 历史 + 工具输出 + 系统提示
技能 角色设定 + 思维链 RAG + 记忆 + 上下文管理
角色 人是主动方 人退到设计信息供给

一句话：Prompt 写”做什么”，Context 写”看什么”。

3 个反例看懂区别：

  • 错：Prompt 思维（以为写好一句话就完事）→ “你是专家，分析下这份报告”
  • 对：Context 思维（控制模型能看到什么）→ 选 Top-3 报告章节 + 补充会议纪要 + 加分析师背景资料
  • 错：Agent 不会用工具 → “请用 search 工具查一下”
  • 对：Agent 不知道有 search 工具 → 在 system prompt 加上”你有一个内部搜索工具，触发条件是…”
  • 错：模型长对话后失忆 → 加更多 history
  • 对：上下文不是越多越好 → 定期压缩 + 选择性保留关键决策

1.5 3 类人必须学

  • AI 应用开发者：Agent 跑 1 个月用户就流失，不学 Context Engineering 解决不了
  • 企业 IT 负责人：内部知识库+客服 Agent 必走这条路
  • 产品经理：理解 Context 才能设计出”能记住用户”的 AI 产品

1.6 业界声音：3 个大牛的话

  • Andrej Karpathy（OpenAI 创始人之一）：“The hottest new programming language is English.” 提示词是”自然语言编程”，但提示词只是一部分，上下文才是完整工程
  • Tobi Lutke（Shopify CEO）：2025 年 5 月推文引爆 Context Engineering 这个词，他说“Context Engineering 就是把对的上下文，送到对的模型手里”
  • Anthropic 官方博客：“Long context ≠ good context.” 上下文窗口变大后，质量比数量更重要

1.7 学完这篇能拿下的 5 个技能

  1. 能区分 Prompt / Context / Harness 三个工程层次的差异
  2. 在 LangChain 中用 7 大策略组合设计 Agent
  3. 解决 80% 长上下文相关问题（成本、衰减、检索不准）
  4. 跟同行讨论 AI Agent 架构时有共同语言
  5. 1 周内设计一个生产级 RAG Agent

二、Anthropic 官方定义：什么是 Context Engineering

💡 Anthropic 在 2025 年 11 月发布的《Effective context engineering for AI agents》是这个领域最系统的官方指南。

2.1 Anthropic 的官方定义

“Context Engineering 是在 Agent 任务生命周期中，动态地精选、格式化、注入、压缩、隔离上下文信息的工程学科。”

拆解一下：

  • 精选（Select）：从海量信息里挑出相关的
  • 格式化（Format）：怎么呈现给模型（XML/JSON/结构化）
  • 注入（Inject）：什么时候把什么信息塞进去
  • 压缩（Compress）：上下文满了怎么办
  • 隔离（Isolate）：不同任务用不同的上下文空间

2.2 5 大技术分层

Anthropic 把 Context Engineering 拆成 5 个层次（从底层到上层）：

  1. Tokens 层：怎么用 Token 表示信息（拼写/缩写/压缩）
  2. Prompts 层：系统提示、用户输入、少样本示例
  3. Messages 层：对话历史、多轮交互
  4. Tools 层：工具描述、工具输出、错误信息
  5. Knowledge 层：RAG 检索结果、外部知识源

实战中 5 层都要考虑，不是只关注 Prompts 层。

2.3 跟 RAG / Prompt Engineering 的关系

  • Prompt Engineering 是 Context Engineering 的子集——专注于第 2 层
  • RAG 是 Context Engineering 的实现方式——解决第 5 层
  • Memory 也是——解决第 3 层（历史压缩）

Context Engineering 是这三者的上位概念。

2.4 2026 年 3 大典型应用场景

  • Claude Code（Anthropic 自己的代码 Agent）：用 Context Engineering 决定”该看哪些文件、该改哪些代码”
  • Devin（AI 软件工程师）：Sub-Agent 隔离策略管理多个任务上下文
  • Manus（通用 Agent）：多用户多任务下的上下文隔离 + 动态注入

三、Context Engineering 7 大核心策略

文内图3

💡 这 7 个策略是 2026 年主流 AI 工程的”通用原语”，掌握后能组合出几乎所有 Agent 架构。

3.1 策略 1：Write Context（写入上下文）

把关键信息主动写进上下文，别让模型自己找：

# 反例：让模型自己"回忆"用户偏好
prompt = "用户想买什么？"

# 正例：把检索到的用户信息写进上下文
context = await get_user_history(user_id)
prompt = f"""
用户历史偏好：{context}

新问题：用户想买什么？
"""

3.2 策略 2：Select Context（选择上下文）

只把相关的内容塞进上下文，别把 100 页全塞：

from langchain_community.vectorstores import Chroma
from langchain_community.embeddings import OpenAIEmbeddings

# 用向量检索选 Top-5 相关文档
retriever = Chroma.from_documents(docs, OpenAIEmbeddings()).as_retriever(k=5)
relevant = retriever.get_relevant_documents(question)

3.3 策略 3：Compress Context（压缩上下文）

超过 80% 窗口容量就要压缩，别等溢出：

# 用 LLM 总结早期对话
def compress_history(messages):
summary = llm.invoke(f"用 200 字总结以下对话：\n{messages}")
return [{"role": "system", "content": f"历史总结：{summary}"}]

3.4 策略 4：Isolate Context（隔离上下文）

子任务用子 Agent，别让主 Agent 上下文污染：

# 主 Agent 只传"任务描述"给子 Agent
subagent_result = subagent.run(
task="查询北京天气",
context_budget=2000 # 限制子 Agent 上下文
)

3.5 策略 5：Tool Selection（工具选择）

工具描述要清晰，别让模型乱选：

# 反例：模糊工具描述
tools = [{"name": "search", "description": "搜索"}]

# 正例：精确工具描述
tools = [{
"name": "search_internal_docs",
"description": "在公司内部知识库中搜索文档。当用户问公司制度、产品手册时使用。返回格式：文件路径+摘要",
"parameters": {"query": "string"}
}]

3.6 策略 6：Dynamic Injection（动态注入）

不同任务阶段塞不同上下文，别一成不变：

if task_stage == "planning":
context += load_planning_templates()
elif task_stage == "execution":
context += load_tool_schemas()

3.7 策略 7：Structured Output（结构化输出）

让模型输出 JSON 而不是散文，方便后续 Agent 解析：

response = client.chat.completions.create(
model="gpt-4o",
response_format={"type": "json_object"}, # 强制 JSON
messages=[{"role": "user", "content": "提取订单信息"}]
)

实操建议：

  • 7 个策略不是孤立的，实战中通常组合用 3-5 个
  • 简单对话用 3.1+3.2 就够；复杂 Agent 用 3.1-3.6 全套
  • 第一次写 Agent 先用 3.1 写入，跑通了再加 RAG/压缩/隔离

四、硬件视角：Context Engineering 跟 Token 成本的关系

💡 Context Engineering 不仅是技术决策，更是成本决策。上下文越长、越全面，账单越惨。

4.1 上下文长度 vs 成本的指数曲线

LLM API 按 Token 计费，上下文越长单价越贵。32K 上下文比 8K 上下文贵 2-4 倍，不只是 4 倍：

模型 8K 输入 32K 输入 128K 输入
GPT-4o $2.5/M $5/M（2x） $10/M（4x）
Claude Opus 4.8 $15/M $30/M（2x） $75/M（5x）
DeepSeek V3 ¥1/M ¥2/M（2x） ¥4/M（4x）

结论：用 32K 上下文跑 1000 次 = 8000 元；用 8K + RAG 跑 1000 次 = 400 元。Context Engineering 不是技术问题，是钱的问题。

4.2 长上下文的”注意力衰减”

研究显示，模型对上下文首尾关注度高，中间内容注意力下降（Lost in the Middle 现象）：

[高注意力] 头部(系统提示+用户问题)
[衰减] 中间(历史对话+检索结果)
[高注意力] 尾部(最近3-5轮对话)

所以关键信息放头部或尾部，中间放次要信息。

4.3 缓存：Context Engineering 的隐藏省钱技巧

大多数 API 提供”Prompt Caching”，重复的上下文前缀只算一次费用：

# 系统提示 + 长文档作为 prefix（缓存命中）
response = client.chat.completions.create(
model="claude-opus-4-8",
system=[
{"type": "text", "text": long_doc, "cache_control": {"type": "ephemeral"}}
],
messages=[{"role": "user", "content": "总结这份文档"}]
)
# 第一次调用 1000 token，第二次只算 50 token（问题部分）

实测：用 Claude 的 prompt caching，月度账单能砍 70%。

4.4 3 个真实账单对比案例

案例 1：100 客户 × 每天 50 轮对话

架构 月成本
32K 全上下文 + Claude Opus 4.8 75000 元
8K 上下文 + RAG + Claude Opus 4.8 12000 元
8K 上下文 + RAG + DeepSeek V3 1500 元
8K 上下文 + RAG + 本地 Qwen 2.5 7B 30 元（电费）

案例 2：客服 Agent 单次任务成本

架构 成本 备注
无缓存 + 长上下文 1.50 元/次 每次全量重发上下文
启用缓存 + 8K 上下文 0.15 元/次 缓存命中率 80%
启用缓存 + RAG 0.05 元/次 检索代替全量

案例 3：100 人企业 RAG 知识库月成本

  • 用户：100 人，每人每天问 20 次
  • 文档库：10 GB，常见文档 100 份
  • 方案 A（长上下文 128K）：$2/天 × 30 = $60/月
  • 方案 B（RAG + 8K 上下文）：$0.2/天 × 30 = $6/月
  • 方案 C（本地 Qwen 7B + RAG）：$0 + $5 电费/月

省钱 90% 以上，Context Engineering 是 ROI 最高的优化方向。

4.5 缓存命中率优化 3 个技巧

1. 把不变内容放前缀

# 正确：长文档作为 system 前缀
system=[{"text": long_doc, "cache_control": {"type": "ephemeral"}}]
# 错误：长文档作为 user message
messages=[{"role": "user", "content": f"文档：{long_doc}\n问题：{q}"}]

2. 控制前缀长度

  • 1024 token 以内：100% 缓存
  • 1024-2048：约 50% 缓存
  • 超过 2048：缓存失效，费用重新算

3. 用语义缓存代替上下文缓存

  • 相同问题的答案直接复用，不调 LLM
  • 命中率 30-50% 时能省 40% 费用

五、LangChain 实战：搭一个能”读 100 页 PDF 然后回答问题”的 Agent

文内图2

💡 项目只装一个 PDF 就能跑起来，不依赖任何企业级接口，个人开发者10 分钟能跑通。

5.1 项目目标

让 Agent 读 100 页 PDF 文档（10 万字），用户问问题时能基于文档内容回答。

5.2 适用场景

企业产品手册问答、学术论文分析、法律合同审查、技术文档检索。

5.3 前置准备

# 1. 安装依赖
pip install langchain langchain-community langchain-openai \
chromadb pypdf tiktoken

# 2. 准备 PDF
mkdir -p ./pdfs
# 把 100 页 PDF 放进去

# 3. 设置 API Key
export OPENAI_API_KEY='***'

5.4 完整代码（保存为 pdf_rag_agent.py）

from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains import RetrievalQA
from langchain.memory import ConversationBufferWindowMemory
from langchain.prompts import PromptTemplate
import os

# ========== 第 1 步：加载并切分 PDF ==========
loader = PyPDFLoader('./pdfs/100pages.pdf')
pages = loader.load()
print(f'加载了 {len(pages)} 页')

text_splitter = RecursiveCharacterTextSplitter(
chunk_size=1000, # 每块 1000 字符
chunk_overlap=200, # 块之间重叠 200 字符
)
chunks = text_splitter.split_documents(pages)
print(f'切分为 {len(chunks)} 个块')

# ========== 第 2 步：向量化入库 ==========
embeddings = OpenAIEmbeddings(model='text-embedding-3-small')
vectorstore = Chroma.from_documents(chunks, embeddings)
print('已存入向量库')

# ========== 第 3 步：搭建带记忆的 RAG 链 ==========
llm = ChatOpenAI(model='gpt-4o-mini', temperature=0)

# 关键：Context Engineering 体现在 4 个地方
# 1. 检索只取 Top-3（避免上下文过大）
retriever = vectorstore.as_retriever(search_kwargs={'k': 3})

# 2. 提示词明确告诉模型"只用上下文信息回答"
prompt_template = """基于以下参考资料回答问题。
如果参考资料里没有答案，请说"未找到相关信息"，不要编造。

参考资料：
{context}

对话历史：
{chat_history}

当前问题：{question}
"""
PROMPT = PromptTemplate(
template=prompt_template,
input_variables=['context', 'chat_history', 'question']
)

# 3. 加窗口记忆（只保留最近 5 轮，避免上下文爆炸）
memory = ConversationBufferWindowMemory(
k=5,
memory_key='chat_history',
return_messages=True
)

# 4. 组装
qa = RetrievalQA.from_chain_type(
llm=llm,
chain_type='stuff', # 把检索结果一次性塞进 prompt
retriever=retriever,
memory=memory,
chain_type_kwargs={'prompt': PROMPT}
)

# ========== 第 4 步：交互式问答 ==========
print('\n=== PDF 问答 Agent 已就绪 ===')
while True:
q = input('\n问 PDF 的问题（q 退出）：')
if q.lower() == 'q':
break
result = qa.invoke({'query': q})
print(f'\nAI 回答：{result["result"]}')

5.5 怎么跑

# 1. 把 100 页 PDF 放到 ./pdfs/100pages.pdf
# 2. 设置 API Key
export OPENAI_API_KEY='sk-…'
# 3. 运行
python3 pdf_rag_agent.py

# 4. 试试问：
问 PDF 的问题：第3章的核心结论是什么？
AI 回答：（基于 PDF 内容的回答）

调试技巧：运行时在终端观察”加载 PDF 用了多久、切了多少块、检索出几篇文档” 这些中间状态，能帮你快速定位问题。

5.6 预期结果

  • 加载 100 页 PDF：5-10 秒
  • 单次问答响应：3-5 秒
  • 准确率（基于文档）：90%+
  • 5 轮对话后仍能记住上下文

5.7 故障排查

  • FileNotFoundError → 确认 PDF 路径是 ./pdfs/100pages.pdf
  • 回答”未找到相关信息”→ 调整 chunk_size（试试 500 或 2000）
  • 回答编造内容 → 把 temperature 降到 0
  • 速度太慢 → 换 gpt-4o-mini 或本地 qwen2.5:7b（参考上一篇）
  • Token 超限 → 减少 k 值（从 3 改成 2）

5.8 进阶玩法

跑通基础版后，加这 3 个 Context Engineering 技巧：

1. 加 Re-ranking：检索 Top-20，再用 Cross-Encoder 重排取 Top-3

from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CohereRerank
# 提高召回质量

2. 加 HyDE（Hypothetical Document Embeddings）：先用模型生成”假设答案”，再检索相似文档

hyde_chain = HypotheticalDocumentEmbedder(llm=llm, base_embeddings=embeddings)

3. 加 Multi-Query Retriever：让 LLM 自动改写 3-5 个问题，扩展检索范围

from langchain.retrievers.multi_query import MultiQueryRetriever

4. 加上评估器：用 LLM 评估回答质量，差的重检索

from langchain.evaluation import load_evaluator
evaluator = load_evaluator("answer_relevance")

5.9 实战中 3 个关键参数调优

chunk_size 怎么选：

  • 技术文档（代码多）：500-800 字符
  • 产品手册（段落长）：1000-1500 字符
  • 论文（公式图表）：800-1200 字符

k 值（检索数量）怎么选：

  • 简单问题：k=3
  • 复杂问题：k=5-8 + Re-ranking
  • 需要多角度：k=10 + Multi-Query

temperature 怎么选：

  • 知识检索：0
  • 文档总结：0.3
  • 创意生成：0.7-1.0

六、Anthropic 官方 Context Engineering 4 大最佳实践

💡 Anthropic 官方 4 大原则。这 4 点不是选诜项，是 2026 年生产级 Agent 的底线。

Anthropic 在 2025 年 11 月发布的《Effective context engineering for AI agents》是被引用最多的实操指南。核心 4 点：

6.1 实践 1：长上下文 ≠ 好上下文

Anthropic 原话：“Just because the model can read 200K tokens doesn’t mean it should.” 上下文窗口变大后，用最相关的信息填满它比”全塞进去”更重要。

6.2 实践 2：让 Agent 自己管理上下文

不要在代码里硬塞上下文，让 Agent 用工具（TodoList、Memory）自己管理：

# 反例：硬塞上下文
prompt = f"用户问：{q}\n历史：{history}\n文档：{docs}\n…"

# 正例：给 Agent 一个"记事本"工具
agent_tools = [search_tool, todo_tool, memory_tool]
agent = create_agent(llm, tools=agent_tools)

6.3 实践 3：长任务用”压缩 + 检索”代替”全上下文”

不要等上下文满了再压缩，主动定期摘要：

# 每 10 轮对话自动压缩一次
if turn % 10 == 0:
summary = summarize(messages)
messages = [{"role": "system", "content": f"历史：{summary}"}]

6.4 实践 4：用 Sub-Agent 隔离上下文

复杂任务拆成多个 Sub-Agent，主 Agent 只传”任务结果”：

# 5 个 Sub-Agent 各自管自己的上下文
researcher = SubAgent(tools=[search, browse])
coder = SubAgent(tools=[python_repl])
writer = SubAgent(tools=[style_guide])

# 主 Agent 只拿到最终结果，不接触 Sub-Agent 的过程
result = orchestrator.run([researcher, coder, writer])

七、5 个真实踩坑案例

文内图1

7.1 坑 1：上下文满了直接 500 错误

现象：长对话跑到 50 轮，突然报 “context_length_exceeded”。

原因：128K 看着大，但工具结果（搜索返回 10 个文档）+ 多模态（图片 base64）很容易撑爆。

解决：

  • 强制每 10 轮压缩一次
  • 工具结果截断（只取前 2000 字符）
  • 多模态用 URL 引用而不是内联

7.2 坑 2：RAG 检索不准

现象：明明文档里有答案，模型说”未找到”。

原因：chunk_size 太大（2000+）或太小（<200）、没有用 HyDE/重排序。 解决：

  • 调 chunk_size 到 500-1000
  • 加 Cross-Encoder rerank
  • 用多查询扩展

7.3 坑 3：模型忽略系统提示

现象：明确说了”用 JSON 输出”，模型还是返回散文。

原因：系统提示被放在用户消息前面，被模型当成”礼貌性建议”忽略。

解决：

  • 用 response_format={"type": "json_object"} 强制
  • 关键指令放在用户消息末尾（Lost in the Middle 的逆运用）

7.4 坑 4：工具描述模糊导致乱选

现象：Agent 调错工具、把 search_internal 调成 search_web。

原因：工具描述写”搜索”过于宽泛。

解决：

  • 工具描述 30+ 字符、明确触发条件
  • 列举”应该用”和”不应该用”的例子

7.5 坑 5：成本失控

现象：单次 Agent 任务花 5 元，比人工还贵。

原因：每次都把所有上下文塞进去，没用 Prompt Caching。

解决：

  • 长文档用 Prompt Caching（前缀缓存）
  • 小任务用小模型（gpt-4o-mini / Claude Haiku）
  • 限制 max_tokens 输出

实操建议：

  • 第一次跑 Agent 先看 Token 消耗，再决定要不要优化
  • 用 OpenAI 的 Token 监控 API 设置月度预算告警
  • 80% 成本来自 20% 的长上下文任务，找出来优先优化

八、Context Engineering 工具栈推荐

💡 选工具看场景，不是看热度。生产环境选成熟的（LangChain / LlamaIndex），创新场景选小众的（CrewAI / DSPy）。

8.1 LangChain / LangGraph

  • 优势：Python 生态最成熟、文档最全
  • 适合：通用 RAG、多 Agent 编排
  • 坑：抽象层太深，简单场景反而麻烦

8.2 LlamaIndex

  • 优势：专注 RAG、数据接入最强（300+ 数据源）
  • 适合：文档问答、结构化数据检索
  • 坑：多 Agent 支持弱

8.3 CrewAI

  • 优势：多 Agent 协作开箱即用
  • 适合：研究/写报告/代码审查等协作场景
  • 坑：单 Agent 场景用不上

8.4 AutoGen（微软）

  • 优势：学术派、人在回路（Human-in-the-loop）支持好
  • 适合：研究、复杂决策链
  • 坑：学习曲线陡、生产部署案例少

8.5 DSPy

  • 优势：用编译代替手写 Prompt，自动优化
  • 适合：大规模 Prompt 优化、A/B 测试
  • 坑：概念新颖、案例少

实操建议：

  • 个人开发者：从 LangChain 上手，2 小时能跑通 RAG
  • 企业生产：LangGraph（LangChain 团队出品，状态管理更稳）
  • 多 Agent 协作：CrewAI / AutoGen
  • Prompt 优化研究：DSPy

九、6 个常见问题 FAQ

9.1 Context Engineering 和 Prompt Engineering 哪个重要？

都重要，但阶段不同。简单对话（1-3 轮）Prompt 决定质量；复杂 Agent（10+ 轮）Context 决定生死。

9.2 上下文窗口越大越好吗？

不是。128K 上下文单价是 8K 的 4 倍，噪音也增加。Anthropic 官方建议”用最相关的填满它”。

9.3 怎么判断我的 Agent 缺 Context Engineering？

3 个症状：① 跑 5 轮后模型开始编造 ② 用户反馈”它听不懂我说话” ③ 单次任务成本超过 1 元。

9.4 RAG 和长上下文哪个划算？

10 万字以下用 RAG（便宜 80%），10 万字以上直接用长上下文（Claude 200K / Gemini 1M）。

9.5 多 Agent 一定要吗？

不一定。单 Agent + 工具 能解决 80% 场景。多 Agent 适合”任务能拆、Sub-Agent 上下文独立”的复杂场景。

9.6 怎么学 Context Engineering 最快？

3 步：① 看 Anthropic 官方博客 ② 用 LangChain 跑通 1 个 RAG ③ 把 LangChain 代码改成 5 大策略（Write/Select/Compress/Isolate/Inject）都用上。

十、3 个月 Context Engineering 进阶路径

10.1 第 1 个月：跑通 RAG

  • Week 1-2：LangChain + Chroma + OpenAI Embedding 文档问答
  • Week 3-4：加 Prompt Caching + 工具调用

10.2 第 2 个月：上多 Agent

  • Week 5-6：LangGraph 状态管理
  • Week 7-8：CrewAI 多 Agent 协作

10.3 第 3 个月：性能优化

  • Week 9-10：Re-ranking + HyDE
  • Week 11-12：Token 成本优化（Prompt Caching + 模型分级）

3 个月后你就是”Context Engineer”——2026 年最缺的人才之一。

十一、参考资料

本文涉及的工具和概念均来自以下官方来源：

  • Anthropic 官方博客：Effective context engineering for AI agents（2025-11）
  • LangChain 官方文档：https://python.langchain.com/docs/
  • OpenAI Cookbook：Prompt Caching 最佳实践
  • LlamaIndex 官方文档：https://docs.llamaindex.ai/
  • 36 氪 2026 AI 智能体指南：https://36kr.com/p/3808851537174018
  • CSDN GitCode：Harness、SDD、Context Engineering 本质 https://gitcode.csdn.net/6a2656cd662f9a54cb7b39c8.html
  • 网易《从 Prompt 到 Loop》：https://www.163.com/dy/article/KV9093R8055616YL.html

互动话题

你做 AI Agent 时，Context Engineering 哪个策略最让你头疼？是 RAG 检索不准、上下文爆炸、还是成本失控？

评论区聊聊，呼声最高的 3 个问题我下一篇文章里集中解答。如果想看”Context Engineering 在企业客服场景的完整实战”教程，点赞告诉我，我单独开一篇深度拆解。

3 类人适合学 Context Engineering

如果你不确定该不该学，看这 3 个问题：

  • 你的 Agent 需要处理多轮对话吗？ 是 → 必学
  • 你的 Agent 要访问外部数据（RAG）吗？ 是 → 必学
  • 你的 Agent 单次任务 Token 成本超 0.1 元吗？ 是 → 必学

推荐资源加载顺序：

  1. 先看 Anthropic 博客（1 小时）了解概念
  2. 跑本文 LangChain 例子（2 小时）体验 RAG
  3. 在自己项目里改用 7 大策略（1 周）
  4. 加入 Anthropic / LangChain Discord（随时问问题）

装个术语表（社区习惯说法）：

  • RAG：检索增强生成
  • Chunk：文档分块
  • Embedding：文本向量化
  • Re-ranking：检索结果重排
  • HyDE：假设文档嵌入
  • Memory：记忆机制
  • Tool Use：工具调用（= Function Calling）
  • Agent Loop：代理循环
  • Sub-Agent：子代理
  • Harness：鞘具/约束框架

本术语表在 Anthropic / OpenAI 官方文档中都能查到。

附一：Context Engineering 必读书单

深入学习 Context Engineering 推荐这 5 份资料：

  1. Anthropic 官方博客：《Effective context engineering for AI agents》（2025-11）
  • URL：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  • 推荐指数：⭐⭐⭐⭐⭐
  • 必读，Context Engineering 领域最权威的官方指南
  1. Andrej Karpathy 推文合集（2025-05）
  • 推荐指数：⭐⭐⭐⭐⭐
  • 概念起源，看完理解为什么这个领域会火
  1. LangChain 官方文档（更新及时）
  • URL：https://python.langchain.com/docs/
  • 推荐指数：⭐⭐⭐⭐
  • 实战 API 参考，7 大策略每个都有代码示例
  1. LangGraph 状态管理指南
  • URL：https://langchain-ai.github.io/langgraph/
  • 推荐指数：⭐⭐⭐⭐
  • 复杂 Agent 必备，理解状态机如何管理 Context
  1. 论文《Lost in the Middle》
  • 推荐指数：⭐⭐⭐
  • 为什么中间上下文注意力衰减，10 分钟读完改认识

附二：Context Engineering 5 个反模式（踩雷警告）

2026 年社区总结的 5 个常见错误：

1. 上下文堆叠（Context Stacking）

  • 反例：把”系统提示 + 用户问题 + 历史对话 + 检索结果 + 工具输出”全塞
  • 后果：Token 爆、噪音大、模型抓不住重点
  • 解决：用 7 大策略选择性注入

2. 工具描述简写（Tool Description Vague）

  • 反例："search": "搜索"
  • 后果：Agent 不会调、调错、重复调
  • 解决：30+ 字符描述 + 触发条件 + 输出格式

3. 无记忆 Agent（Memoryless Agent）

  • 反例：每轮对话独立处理
  • 后果：用户说”我上条提的 X”模型听不懂
  • 解决：加 ConversationBufferWindowMemory(k=5) 或长期记忆库

4. 长 Prompt 不拆（Long Prompt Monolith）

  • 反例：单个 5000 字 Prompt
  • 后果：调试难、修改难、团队合作难
  • 解决：拆成 system / user / context / tools 四个独立部分

5. 不用缓存（No Caching）

  • 反例：每次都把长文档重新发给 API
  • 后果：月度账单 3-5 倍
  • 解决：长文档用 Prompt Caching（前缀缓存）

附三：Context Engineering 5 大未来趋势（2026 下半年）

跟着 OpenAI/Anthropic/Google DeepMind 的路线图，未来 12 个月这 5 个方向会重塑 Context Engineering：

1. 1M+ 上下文窗口成熟

  • Google Gemini 1.5 Pro 已是 1M（200 万 Token）
  • Claude 4 Opus 是 200K，年底到 500K
  • 价格会贵 3-5 倍，但能装下《5 1 选集》全文

2. 动态上下文调度

  • 模型自己决定”什么时候看什么”
  • Anthropic 的 “Thinking” 功能已预演了这个能力
  • 不用开发者手动选择上下文，模型自动筛选

3. 跨会话记忆

  • 今天的对话明天还记得
  • 需要统一记忆架构，OpenAI Memory、Anthropic Project、Mastra
  • 企业 Agent 标配

4. 多模态上下文

  • 文本 + 图片 + 音频 + 视频同时塞入上下文
  • 8K token 中可能含 4K 文本 + 4K 图像描述
  • Anthropic Claude 4、Google Gemini 多模态已领跑

5. RAG 进入”Agentic RAG” 时代

  • Agent 自己决定什么时候检索、检索什么
  • 传统 RAG 是”先检索再生成”，Agentic RAG 是”边思考边检索”
  • LlamaIndex、LangGraph、Letta 是代表框架