企业官网建设流程全解析

1. 这是干什么的：别把上下文工程只当成“拼提示词”

先说个我的观察：很多人搭 AI Agent，第一步就急着去调模型、写工具、配流程，结果跑起来之后发现 Agent 经常“犯傻”——明明上一步已经拿到了结果，下一步就忘了；用户提了个稍微绕一点的需求，它就开始东拉西扯；更常见的是，对话一长，模型开始复读、漏信息、答非所问。这不是模型不行，问题多半出在上下文工程没做到位。

上下文工程是 AI Agent 开发里最容易被低估、但实际决定体验上限的环节。它负责的是“模型到底看到了什么、以什么顺序看到、哪些信息被保留、哪些被丢掉”。同样是 GPT-4 或 Claude 级别的模型，上下文组织得好不好，效果差距能拉到非常大——这不是玄学，是可以量化、可以复现、可以优化的工程问题。

这篇文章我把上下文工程拆开讲清楚：它由哪些部分组成、每一部分的设计逻辑是什么、Token 预算怎么分配、长对话怎么记忆、工具调用结果怎么回填、出了典型问题怎么排查。内容偏实操，会给出可直接抄走的代码结构和配置思路，适合正在开发 Agent 的工程师，也适合想搞懂 Agent 到底“为什么有时聪明有时蠢”的产品和技术人员。下面所有方案都基于我的实际项目经验，不保证唯一正确，但保证踩过坑、填过平。

2. 上下文工程全景：核心组成与设计逻辑

2.1 为什么必须单独做上下文工程

先做个类比：Agent 的上下文，就像一个临时工的工位。工位上只有一个白板，临时工每次做一个新任务，能看到的只有白板上写的东西。你写得好，他干得利索；你写得乱，他就开始自由发挥。上下文工程干的事情，就是持续管理这块白板——什么时候写什么、什么时候擦什么、哪些内容用大字写在最显眼的位置、哪些内容收进抽屉随用随取。

模型本身的权重是“长时记忆”，训练时固定下来的；而上下文是模型的“工作记忆”，每次请求时临时放进来的。两者有本质区别：权重没法动态改，但上下文可以。所以对应用开发者来说，上下文是少数几个能完全掌控、并且能显著影响模型行为的变量。这也是“上下文工程”能成为独立方向的根本原因——它不是提示词工程的边角料，而是一套围绕模型输入的系统设计。

之前很多人管这摊事叫“提示词工程”，但提示词工程更多停留在“怎么写好一段指令”，上下文工程要复杂得多：它要管多轮对话历史、管外部工具返回的结构化数据、管记忆的存取策略、管