上下文工程学习笔记 Day 1：什么是上下文工程？

一句话总结

上下文工程（Context Engineering）就是给AI做"内存管理"——在有限的工作空间里，智能地决定放什么、换什么、压什么、隔什么。

一、上下文的三大类别

LLM 的上下文不是一坨混在一起的文字，它可以清晰地拆分成三类：

1. 指导性上下文（Guiding Context）—— "怎么做"

告诉模型该做什么、怎么做、以什么标准输出。包括：

• System Prompt（角色设定）
• Task Description（任务描述）
• Few-shot Examples（示例）
• Output Schema（输出格式约束，比如要求JSON）

我们平时说的 Prompt
Engineering，本质上就是在优化这一层。你每天跟AI说"你是一个XX专家，帮我做XX"，就是在写指导性上下文。

2. 信息性上下文（Informational Context）—— "知道什么"

为模型提供解决问题所需的知识和数据。包括：

• RAG（从外部知识库检索的信息）
• Short-term Memory（当前对话历史，维持对话连贯）
• Long-term Memory（跨会话的用户偏好和历史认知）
• State / Scratchpad（临时草稿纸，比如Claude Code的TODO）

这里最大的挑战不是"给得够不够多"，而是信噪比。把所有资料一股脑塞进去反而会让模型"迷路"。高效的信息性上下文应该是一 份精炼的备忘录，不是一座杂乱的图书馆。

3. 行动性上下文（Actionable Context）—— "能做什么"

告诉模型它能调用哪些工具，以及工具返回了什么结果。包括：

• Tool Definition（工具定义和使用说明）
• Tool Calls & Results（工具调用历史和返回结果）

这是 Chatbot 和 Agent
的分水岭。没有行动性上下文，模型就是"缸中之脑"——什么都懂但什么都做不了。有了它，模型才真正拥有了"手脚"。

二、Karpathy 的操作系统类比

Andrej Karpathy 有一个精妙的比喻，把整个上下文工程体系一下讲透了：

三大类上下文（指导性 / 信息性 / 行动性）都是需要被加载到 RAM
里的不同类型数据，而上下文工程就是负责协调它们分配的"内存管理器"。

三、重新理解那些技术热词

用上下文工程的视角重新看那些耳熟能详的概念：

• Prompt Engineering → 上下文工程的子集，专注优化指导性上下文，面向单轮交互
• RAG → 实现动态信息性上下文的关键手段，但上下文工程的范畴远大于RAG
• Memory → 同样服务信息性上下文，和RAG互补。Short-term保持对话连贯，Long-term让AI"记住你"
• MCP → 为行动性上下文提供标准化交互规范，是Function Calling的进阶形态，摆脱了平台绑定

我的理解

上下文工程的本质就是给AI做"内存调度"。模型本身的能力出厂就定了（就像CPU），但同一个模型面对同一个问题，给它不同的上下
文组合，输出质量天差地别。

决定AI表现上限的，往往不是模型本身有多强，而是你给它的上下文有多精准。这就是为什么上下文工程正在成为AI应用层最核心的工 程能力。