一个被很多人忽略的转变
去年这个时候，大家见面聊的还是"你的提示词怎么写的"。各种"咒语大全""万能模板"满天飞，仿佛只要把那句话调对了，模型就能给你想要的一切。
但真正把 Agent 推到生产环境的人，慢慢都发现一件事：当任务复杂到一定程度，提示词写得再花哨，也救不了一个上下文混乱的 Agent。
模型不是不够聪明，而是你没把"它该知道的东西"在正确的时机、用正确的方式喂给它。这件事，比那句开场白重要得多。
于是一个新词开始流行——Context Engineering，上下文工程。
这篇我想把这个概念讲清楚：它到底是什么、由哪些部分组成、和提示工程差在哪，以及落地时该怎么配比。
一、从「写好一句话」到「管好一个信息系统」
先给个我自己的定义：
提示工程，是优化你对模型说的那"一句话"；上下文工程，是优化模型在生成那一刻，整个上下文窗口里装的"所有东西"。
差别在哪？打个比方。
提示工程像是你给一个新来的实习生交代任务时，把话说得尽量清楚。这当然有用，但如果这个实习生对公司业务一无所知、手上没有任何资料、也不记得你昨天说过什么——你这句话说得再漂亮，他也干不好。
上下文工程关心的是另一件事：在他动手前，桌上该摆好哪些资料、哪些历史记录、哪些工具说明书。 这才是决定产出质量的关键。
提示工程是上下文工程的一个子集。这个领域的重心，正在从"调那句话"转向"调整个信息环境"。
二、上下文窗口里到底装了哪七样东西
一个成熟 Agent 在调用模型的那一刻，它的上下文通常由这几块拼装而成。我把它拆成七个组件：
| 组件 | 作用 | 一句话理解 |
|---|---|---|
| 系统指令 | 定义角色、规则、输出格式 | 它是谁、该守什么规矩 |
| 用户输入 | 当前这一轮的真实诉求 | 用户现在要什么 |
| 短期记忆 | 当前会话的对话历史 | 我们刚才聊了什么 |
| 长期记忆 | 跨会话沉淀的偏好与事实 | 我以前就知道的事 |
| 检索内容 | RAG 从知识库拉来的相关资料 | 临时查到的参考资料 |
| 工具定义 | 可调用的函数及其说明 | 我能用哪些工具 |
| 工具结果 | 工具执行后返回的观测 | 工具刚告诉我什么 |
这七样东西，不是越多越好，而是越准越好。 上下文窗口是有限的，塞进去的每一个 token 都在和别的内容抢注意力。上下文工程的核心难题，恰恰是"取舍"——在有限的窗口里，放进当下最该出现的东西。
三、四个核心手法：把信息管起来
知道了组件，接下来是手法。生产里真正高频用到的，是下面四招。
1. 写入（Write）——让信息沉淀下来
模型本身是无状态的，每次调用都"失忆"。要让 Agent 有连续性，就得主动把关键信息写到外部——会话历史、用户画像、任务进度。
最朴素的做法是把对话历史拼回去；更工程化的做法是维护一份结构化的 scratchpad（草稿区），让 Agent 把中间结论记在那里，下一步再读出来。
2. 检索（Select）——只取当下相关的
这就是 RAG 的核心。知识库可能有几百万字，但这一轮你只需要其中最相关的几段。
# 一个最小的检索增强流程
def build_context(query, knowledge_base, top_k=5):
# 1. 把问题向量化
q_vec = embed(query)
# 2. 从向量库里捞最相关的 k 段
chunks = knowledge_base.search(q_vec, top_k=top_k)
# 3. 拼进上下文，而不是把整个库塞进去
return "\n\n".join(c.text for c in chunks)
关键不在于"能检索"，而在于检索得准——召回的内容相关度越高，留给模型胡思乱想的空间就越小，幻觉自然就少了。
3. 压缩（Compress）——把长的变短
对话一长，上下文就爆了。压缩的常见手段有两种：
- 摘要：把前面几十轮对话浓缩成一段要点，替换掉原始记录；
- 裁剪：只保留最近 N 轮 + 最相关的几条，其余丢弃。
我的经验是：别等窗口满了才压缩，而要设一个阈值（比如占用到 70%）就触发，留出安全余量。
4. 隔离（Isolate）——别让信息互相污染
当一个任务要跑多个子 Agent 时，最忌讳的是把所有信息都倒进同一个上下文。正确做法是按职责隔离：每个子 Agent 只看到它该看的那部分，互不干扰。
这也是为什么多 Agent 架构里，"上下文隔离"几乎是头等大事——它直接决定系统会不会越跑越乱。
四、一个实战配比建议
很多人问：这七个组件、四个手法，具体该怎么搭？我给一个我自己常用的起步配比，供参考（不是金科玉律，按场景调）：
- 系统指令：精炼，控制在几百 token 内，别写成长篇大论；
- 检索内容：占大头，但 top_k 别贪多，5 段往往比 20 段效果好；
- 短期记忆：保留最近 5-10 轮，更早的做摘要；
- 长期记忆：只注入和当前任务强相关的几条，别把用户档案全倒进去；
- 工具定义：用到哪些给哪些，工具列表太长反而会干扰模型选择。
一个判断你上下文工程做得好不好的简单信号：当 Agent 表现变差时，你第一反应是去改提示词，还是去查上下文里到底装了什么？ 如果是后者，说明你已经入门了。
五、下一站：从上下文工程到环境工程
值得一提的是，这个领域还在往前走。
上下文工程管的是"喂给模型什么信息"，而更前沿的讨论已经延伸到 环境工程（Environment Engineering）——不只是给信息，而是给 Agent 搭一个完整的、可交互的工作环境：文件系统、可执行的沙箱、持久化的状态存储……让 Agent 像人一样，在一个"工作台"上边干活边获取反馈。
但别急着追新概念。对大多数人来说，先把上下文这七个组件和四个手法吃透，你的 Agent 就已经能甩开一大截了。
写在最后
如果让我用一句话总结这篇：
决定 Agent 上限的，从来不是你那句提示词写得多巧，而是你有没有能力管好它的整个上下文。
提示工程教你"怎么说话"，上下文工程教你"怎么给它配齐一个能干活的信息环境"。前者是入门，后者才是真正拉开差距的地方。
这是 Agent 实战系列的第 1 篇。如果你也在搭 Agent，欢迎交流你在上下文管理上踩过的坑。