上下文工程：比"怎么问"更重要的，是"喂什么"

你有没有过这样的经历——

花了两个小时反复调一个 prompt，终于让 GPT 输出了你想要的格式。你心满意足地保存下来，第二天换了个稍微不同的输入，它又开始胡说八道了。

你开始怀疑自己：是不是措辞不够精确？是不是少了几个"请注意"？于是你继续加限制条件，prompt 从 3 行膨胀到 30 行，模型的表现却像开盲盒——时灵时不灵。

如果你有过这种体验，恭喜你，你发现了一个大多数人还没意识到的真相：问题从来不在你"怎么问"，而在模型"看到了什么"。

这就是今天我想跟你聊的话题——上下文工程（Context Engineering）。

这个概念正在 AI 工程圈悄悄取代 Prompt Engineering，成为决定 AI 应用质量的核心变量。Shopify CEO Tobi Lütke 说得直白：上下文工程是"提供恰好足够的信息，让任务对 LLM 来说变得可解"的艺术。

Anthropic 团队更进一步：大多数 Agent 的失败，不是模型的失败，而是上下文的失败。

听到这句话，你是不是突然觉得之前调 prompt 的方向可能整个就错了？别急，往下看。

一、从 Prompt 到 Context：一次被低估的认知升级

先说清楚一件事：Prompt Engineering 没有死，但它的能力边界已经到了。

打个比方。

Prompt Engineering 像是你在考试前反复琢磨"这道题该怎么措辞才能让阅卷老师给高分"。你研究出题人的心理，你优化答题话术，你甚至背了几个万能句式。

Context Engineering 则完全不同。它不是在琢磨怎么"说"，而是在设计考生走进考场之前，桌上摆着哪些参考资料、草稿纸上预先写了什么笔记、手边有哪些工具可以用。

一个是措辞术，一个是信息架构。

用更技术的语言说：

Prompt Engineering：优化你发给模型的那段文字——措辞、语序、Few-shot 示例
Context Engineering：设计模型在推理时能看到的一切信息——系统指令、工具定义、检索到的外部数据、对话历史、用户画像、输出格式约束

区别清楚了吗？Prompt 只是 Context 的一个子集。你一直在优化子集，却忽略了全集。

一句话记住

Prompt 是你说的话，Context 是你铺的局。局铺得好，一句大白话就能让模型输出惊人的结果；局铺得差，prompt 写成论文也救不回来。

我自己有个特别真实的体会。

前段时间我在用 Claude Code 开发一个多 Agent 协作框架。刚开始，我花了大量时间优化每个 Agent 的 system prompt——措辞要精确、指令要清晰、边界要明确。效果还行，但总是在一些边界情况下翻车。

后来我换了个思路：不再死磕 prompt 的措辞，而是花时间设计每个 Agent 在执行任务时能"看到"什么——项目的 CLAUDE.md 文件、最近的 git log、相关的代码片段、之前的对话摘要。

结果呢？prompt 反而变简单了，但 Agent 的表现质的飞跃。

这就是 Anthropic 在其工程博客中强调的核心原则：找到最小的高信号 token 集合，最大化模型产出预期结果的概率。

注意两个关键词："最小"和"高信号"。不是把所有信息都塞进去，而是精准地塞入最有用的信息。

Prompt Engineering 回答的是"我该怎么说"，Context Engineering 回答的是"模型该看到什么"。这不是措辞升级，是思维范式的切换。

二、为什么调 Prompt 不够用了

你可能会问：既然 Prompt Engineering 也能用，为什么要上升到"工程"层面？

三个原因。

原因一：Agent 时代来了，单轮对话的日子结束了

2024 年之前，大部分 AI 应用的模式是"你问一句，它答一句"。在这种场景下，prompt 确实很重要——你只有一次机会把话说清楚。

但 2025-2026 年，AI 应用的主角变成了 Agent。Agent 不是聊天机器人，它是一个能调用工具、读写文件、联网搜索、分步执行任务的自主系统。一个复杂任务可能涉及 20-50 轮模型调用。

在这种场景下，单次 prompt 的优化变得微不足道。真正决定成败的，是每一轮调用时，模型的上下文里有没有做这一步所需要的全部信息。

我举个例子。假设你让一个 AI Agent 帮你做代码审查：

# Prompt Engineering 思路：优化指令措辞
system_prompt = """你是一位资深代码审查专家。
请仔细审查以下代码，从安全性、性能、可读性三个维度给出建议。
请用中文回复，格式为..."""

# Context Engineering 思路：设计信息供给
context = {
    "system": "你是代码审查助手",
    "project_rules": load("CLAUDE.md"),        # 项目编码规范
    "recent_changes": git_diff("HEAD~5"),       # 最近 5 次提交
    "related_files": find_dependencies(file),   # 依赖文件
    "past_reviews": search_history(author),     # 该作者的历史审查记录
    "code_to_review": current_diff              # 待审查代码
}

看到区别了吗？第一种方法在"说什么"上下功夫，第二种方法在"看什么"上下功夫。哪个审查结果更靠谱，不用我说你也能猜到。

原因二：Context Rot——上下文越长，模型越"健忘"

这是一个反直觉的事实：模型的上下文窗口越大，它的表现不一定越好。

Anthropic 称之为"Context Rot"（上下文腐烂）。Transformer 架构需要在所有 token 之间建立 n² 的注意力关系。上下文越长，每个 token 分到的注意力越稀薄——就像一个人同时听十个人说话，每个人的话他都在听，但每个人的话他都记不全。

常见误区

很多人以为"上下文窗口 200K，那我把所有文档都塞进去不就行了？"这是 Context Engineering 最大的陷阱。你塞进去的信息越多，模型提取关键信息的准确率越低。Context Engineering 的核心不是"塞更多"，而是"选更准"。

打个比方：给你一本 500 页的书让你找一个关键数据，和直接给你那一页让你找，哪个更快更准？答案不言自明。

原因三：Prompt 是手工活，Context 是系统工程

Prompt Engineering 有个天然缺陷：它是不可复用的。

你给 A 场景写了一个精妙的 prompt，换到 B 场景大概率不好使。于是你又写一个。日积月累，你手上有 100 个 prompt，每个都针对特定场景，维护成本爆炸。

Context Engineering 是系统化的解法。你设计的不是一段文字，而是一套"信息供给管道"——根据任务类型、用户画像、当前状态，动态组装最合适的上下文。一套管道，服务所有场景。

维度	Prompt Engineering	Context Engineering
关注点	措辞和格式	信息架构和数据流
作用范围	单次调用	整个 Agent 生命周期
可复用性	低，场景绑定	高，管道化设计
调试方式	改措辞，试错	检查信息流，定位缺失
上限	措辞再好也补不了信息缺失	信息充分时 prompt 可以极简

大模型不是不聪明，是你没给它聪明的机会。

三、上下文工程的七块积木

好，道理讲完了，具体怎么做？

AI 工程师 Philipp Schmid 提出了一个很有用的框架：模型看到的上下文，可以拆解为七个组件，就像七块乐高积木。你的工作，是根据任务需要，选择合适的积木，拼出最佳组合。

上下文工程的七大组件——模型在推理时"看到"的一切

我们逐个拆解：

1. 系统指令（System Instructions）

这是模型的"人设说明书"。不只是"你是一个 XXX 助手"这么简单，还包括行为边界、回答风格、安全策略。

Anthropic 的建议是找到"金发姑娘区间"（Goldilocks Zone）——既不要写得太死板太具体（容易脆弱），也不要写得太模糊太笼统（模型不知道该怎么做）。用 XML 标签或 Markdown 标题把不同类型的指令分区，让模型清楚什么是规则、什么是偏好、什么是示例。

2. 用户提示（User Prompt）

用户当下的输入。这是唯一你不能提前设计的部分，但你可以设计如何"增强"它——比如自动补全用户没说但需要的信息。

3. 短期记忆（Short-term Memory）

当前对话的历史。对话越长，上下文越拥挤。Context Engineering 的关键操作之一就是"压缩"（Compaction）——把长对话总结成要点，只保留关键信息。

4. 长期记忆（Long-term Memory）

跨会话的持久知识。比如 Claude Code 的 CLAUDE.md 文件——项目的编码规范、架构决策、技术栈偏好——这些信息在每次对话开始时自动注入，不用你每次重复说。

5. RAG 检索信息（Retrieved Context）

从外部知识库实时检索的内容。不是把整个知识库扔给模型，而是像搜索引擎一样，只取最相关的几个片段。

6. 工具定义（Available Tools）

模型能调用哪些工具、每个工具的功能描述和参数说明。工具定义本身就是上下文的一部分——工具太多，模型会选择困难；工具描述不清，模型会乱调。

7. 输出格式（Output Schema）

约束模型的输出结构——JSON、Markdown、HTML。这不只是格式问题，还影响模型的推理路径。

关键原则

这七块积木不是"越多越好"。Anthropic 在实践中发现，最有效的上下文设计遵循一个反直觉的原则：先确保全面（高召回），再剔除冗余（高精度）。 像雕塑一样，先加材料，再削掉多余的。

把这七块积木摆在面前，你就会明白为什么"调 prompt"是不够的。你调的只是第 2 块积木，剩下 6 块被你完全忽略了。

好的上下文不是越多越好，而是刚好够用。多一分是噪音，少一分是盲区。

四、实战：三个让 Agent 脱胎换骨的技巧

理论讲完了，我猜你心里在想："具体该怎么落地？"

我从 Anthropic 的工程实践和自己的开发经验里，提炼了三个最见效的技巧。

技巧一：Just-in-Time 检索——别预加载，现用现取

很多人设计 Agent 的第一反应是：把所有可能用到的信息都塞进 system prompt。

这就像出门旅行把整个衣柜都搬上车——你确实什么衣服都有了，但车装不下了，你也找不到你想穿的那件。

正确的做法是 Just-in-Time（JIT）检索：只预加载核心信息，其余的让 Agent 在需要时自己去取。

Claude Code 就是这么干的。它采用混合策略：

预加载：CLAUDE.md 文件（项目的核心上下文，启动时就读入）
按需检索：代码文件、git 历史、目录结构——通过 glob、grep、read 等工具实时获取

这和人的认知模式完全一致。你不会把所有学过的知识同时加载到大脑里，你只记住核心框架，具体细节需要时去查。

# 反模式：一次性塞入所有信息
context = load_entire_codebase()  # 10万行代码全塞进去？

# 正确姿势：JIT 检索
context = {
    "core": load("CLAUDE.md"),              # 预加载核心上下文
    "task": user_request,                    # 当前任务
    # Agent 在执行过程中按需获取：
    # → grep("function_name") 找到相关代码
    # → read("specific_file.py") 读取目标文件
    # → git_log("-5") 查看最近改动
}

关键在第 7 行：不是你提前帮 Agent 准备好一切，而是给它工具，让它自己决定什么时候取什么信息。

技巧二：结构化笔记——给 Agent 装一个"外部大脑"

Agent 执行长任务时会遇到一个致命问题：上下文窗口有限，早期的信息会被挤出去。

Anthropic 分享了一个迷人的案例：他们让 Claude 玩 Pokémon 游戏，需要跨越数千步持续执行任务。Agent 自发发展出了一套记忆系统——定期把关键信息（目标、地图、道具状态）写入一个 NOTES.md 文件，后续需要时再读回来。

这就是结构化笔记（Structured Note-Taking）技巧：让 Agent 在执行过程中主动写笔记，把关键信息持久化到上下文窗口之外。

一句话理解

短期记忆是大脑里的便签纸，写满了就丢了。结构化笔记是你桌上的笔记本——可以随时翻回去查。

在实践中，这个技巧的效果立竿见影。比如一个做代码重构的 Agent，在分析阶段发现的架构问题、在执行阶段做的设计决策、已经完成的步骤——全部写入笔记文件。这样即使对话被压缩了，关键决策也不会丢失。

技巧三：子 Agent 架构——专业的事交给专业的"人"

当一个任务复杂到需要处理多种不同类型的信息时，单个 Agent 的上下文窗口就不够用了。

解法是：拆分成多个子 Agent，每个子 Agent 拥有独立的、干净的上下文窗口，只关注自己的子任务，最后把结果汇总给主 Agent。

子 Agent 架构：每个子 Agent 独立工作，返回精炼摘要（1000-2000 tokens）

关键在于：每个子 Agent 返回的不是原始数据，而是精炼后的摘要（通常 1000-2000 tokens）。这样主 Agent 的上下文始终保持干净，不会被海量细节淹没。

这就像公司管理：CEO 不需要知道每个工程师写了哪一行代码，他只需要从各个负责人那里拿到关键结论。

"代码的核心职责不再是生成回答，而是收集情报。真正的工作发生在 LLM 被调用之前——准备上下文的那些代码，才是整个系统的灵魂。"
—— Philipp Schmid，The New Skill in AI is Not Prompting, It's Context Engineering

Agent 的代码 80% 在做信息管道，只有 20% 在跟模型说话。这才是 Context Engineering 的本质。

五、总结：从"调词师"到"信息建筑师"

让我们回顾一下今天聊的核心洞察：

Prompt 是子集，Context 是全集：你优化的措辞只占模型输入的一小部分，真正决定输出质量的是模型"看到"的全部信息
Context Rot 是真实存在的：上下文不是越多越好，而是越精准越好。信息过载对模型的伤害不亚于信息不足
七块积木，缺一不可：系统指令、用户提示、短期记忆、长期记忆、RAG 检索、工具定义、输出格式——设计上下文就是拼积木
三个实战技巧：JIT 检索（现用现取）、结构化笔记（外部大脑）、子 Agent（分而治之）

我的判断：Context Engineering 将在未来 1-2 年内成为 AI 工程师的核心能力。不是因为 Prompt Engineering 没用了，而是因为 Agent 时代的复杂度，已经超出了"调措辞"能覆盖的范围。你能不能设计好信息架构，决定了你的 AI 应用是"玩具"还是"产品"。

我甚至认为，"AI 工程师"这个岗位的核心技能正在从"会写 prompt"转向"会设计 context"。就像软件工程从"会写代码"进化到"会设计架构"一样——真正的门槛不在执行层，在设计层。

下一步建议：

审视你现有的 AI 应用：打开你的 system prompt，问自己：模型在回答时还缺什么信息？是不是有些信息你一直在用自然语言"描述"，而不是直接"提供"？把"描述"换成"数据"，效果会有质的提升
给你的 Agent 建一个 CLAUDE.md：哪怕你不用 Claude，这个思路也通用——把项目的核心上下文（规范、架构、常见模式）整理成一个文件，在每次调用时自动注入。这是 Context Engineering 最简单也最有效的起手式

最后，送你一句话。

下一个被淘汰的，不是不会写 prompt 的人，而是不会设计 context 的人。因为 prompt 只能让模型"听懂你的话"，context 才能让模型"理解你的世界"。