问个问题，AI回得牛头不对马嘴？别急着吐槽它“太蠢”，可能是它根本没听懂你是谁、想干啥。本文用浅显易懂的方式，带你认识一个冷门却超关键的概念——Context Engineering，也许是AI真的“读懂你”的那把钥匙。在文章开始之前，想问大家一个问题，大模型有记忆吗？背景安德烈 ·卡帕西（Andrej Karpathy) 最近成功把Context engineering带火。知名电商平台 Shopify 的 联合创始人兼首席执行官 托比・卢特克（Tobi Lutke）在社交媒体上发了一个帖子：比起“提示工程”（prompt engineering），我确实更喜欢“上下文工程”（context engineering）这个术语。它更好地描述了核心技能：提供完成任务所需全部上下文信息，使大语言模型（LLM）能够合理解决问题的艺术。硅谷AI 大神 安德烈 ·卡帕西（Andrej Karpathy) 赶紧跟帖。他将上下文工程称为“一门精深的科学，也是一门巧妙的艺术。”咱们先来说说为什么科学？因为做好这件事涉及：任何说明与解释、few-shot 示例、RAG检索、相关数据、工具、状态、历史记录、信息压缩等。信息太少或者格式不对，大语言模型就拿不到做出好回答的材料；信息太多或者不相关，则会消耗更多token和算力等，让成本变高、性能降低。那为什么说是艺术呢？怎么用这些方法让模型最‘舒服’、效果最‘出彩’” 。它需要开发者像艺术家一样，用直觉、经验甚至创意去打磨 —— 没有标准答案，却能做出千变万化的精妙设计。同时他还指出：“大多数AI智能体的失败，不是模型的能力不足，而是上下文的失败。”其核心在于在恰当的时机、以恰当格式提供恰当的信息。 涵盖系统提示词、用户输入、状态历史、长期记忆、检索信息、可用工具和结构化输出等全方位、系统的工程。介绍了背景，那Context engineering 到底是什么呢？一、什么是上下文呢大模型要做决策，决策制定正确与否直接决定着回复用户的质量。那如何才能正确的做决策呢？关键是要收集、归纳、整理好做决策需要的信息。这所有必要的信息我们统称为 上下文（context）。二、什么是“上下文工程”？上下文工程，指的是：如何组织、选择、格式化、压缩、排序你给模型的输入内容；如何最大限度利用模型的“上下文窗口”，让它理解任务背景、指令、知识和限制；是提示词工程（promptengineering）的进阶版，更重视结构化、多轮对话、动态补充知识。举个例子：智能投研助手用户问“这只股票为什么跌了？”上下文工程要做的是：整理：K线图（图片）、财务数据（表格）、相关新闻（文本）等格式化：统一编码成大模型能理解的格式指令：告诉模型“你是金融分析专家，请结合数据判断原因。”三、上下文工程有哪些内容组成呢？Google DeepMind 的高级 AI 关系工程师 Philipp Schmid 在他最新的一篇博客里也把上下文工程拆成多个组成模块。包括：系统提示词，这个是系统给模型一开始的指令，比如模型在给谁，在什么场景下，解决问题。相当于给模型做好一个人设，LLM需要扮演什么角色、遵循哪些规则、输出什么格式等等。举个例子，你是一个知书达理的大学教授，具备完善的AI领域知识，不会泄露机密的AI小助手。请避免去谈论政治，这些……敏感词汇请不要说…我们需要给模型限制好一些行为准则；用户提示词：用户发出的具体的问题和任务（Prompt）；短期记忆：当前的聊天对话（用户的提示词和大语言模型的回答）；长期记忆：跨会话的用户偏好、项目信息；工具调用大语言模型可以调用的所有工具和函数等。比如让AI去查日历，发邮件模型会把整个的输入输出、函数调用写在上下文下面，以便记得用户到底做过哪些事情。这个又会占据成千上百个token；检索文档的内容（RAG），通过检索知识库获得参考资料；结构化输出：规定格式，比如Json、表格。为了方便小伙伴们的理解，这里给大家举个我生活中的小例子：比如我发出请求说，帮我约小七老师这周日一起去健身，并发一个邮件提醒她。仔细拆解这个请求，其实包含着两个任务，第一个任务是去找到我和小七老师周日都有空闲的时间段。第二个任务是去创建一个日程提醒并发送邮件给小七老师。这就是复合任务解析。那么AI会先向系统中已经注册的MCPserver去查询它的能力列表。比如是不是可以访问日历？是不是有权限去发邮件？是不是能获取到小七老师的联系人信息？这就是工具能力查询。这些能力的声明和用户的请求一并去交给大语言模型去处理。基于给定的上下文，去判断应该怎么整合现有的工具去完成任务。这就是基于上下文整合工具和数据。不巧的是，小七老师要上课，周日没空。模型会回复我，基于工具调用和查询，发现周日小七老师日程是满的，周六下午6点，你和小七老师都有空闲，需要帮你约周六下午6点吗？我说OK，那模型就会去调用Email server，把这个邮件帮我发出去。那如果模型不了解我的上下文，我让它帮我做这件事，它可能就OK我帮我你约好了，那实际上，周日这天日程是满的，根本就挤不出时间去健身。这就是上下文缺失的后果。所以说只有在模型充分了解用户上下文的情况下，它做出的决策才有可能是正确的 。四、上下文窗口发展历程GPT-2的最大上下文窗口是2048tokens，大概是2K个Token，相当于1～1.5页A4正常排版的文字内容；GPT-3：上下文窗口为4096tokens，大概是4K个Token，相当于可以容纳一整篇新闻特写/报告文章；GPT-4：上下文128,000tokens，大概是128K个Token，可以容纳一部中长篇小说的全部内容。例如，J.K.罗琳的《哈利·波特与魔法石》英文版约77K单词，完全能放入上下文中。按照这个发展，是不是上下文窗口越大越好呢？当然不是，长时间运行任务和调用工具意味着Agent通常会消耗大量的Token。五、上下文设计不当会导致以下几个问题问题一：上下文中毒即幻觉进入上下文中，比如AI在调用工具时，带回了错误的信息或者纯碎的“幻觉”，那么这些幻觉信息会污染整个上下文，导致后续推理满盘皆输问题二：上下文干扰上下文太长，混杂了太多信息，会让模型“注意力分散”，无法专注于重要内容，就像考试时桌上放了一堆没用的参考书；问题三：语境混淆一些没用的信息可能影响模型判断，比如你问模型一个问题，它却被上下文中不相关的东西误导了；问题四：上下文冲突比如上下文中如果出现前后矛盾的内容（比如版本不一致的说法），模型可能不知道该相信哪一个，导致答复混乱或错误。Anthropic也明确指出：Agent通常会参与跨越数百个回合的对话，需要谨慎的上下文管理策略。基于以上挑战，我们该如何应对呢？六、上下文工程四类管理策略我们将Agent上下文工程给予以下四类策略–写入、筛选、压缩、隔离。针对每个策略我们展开讲讲吧～1. 写入（Write Context）让模型记住重要的信息包含三类“记忆”方式：Long-term memories（长期记忆）：跨多个对话保留，比如之前的知识、历史任务等。暂存器帮助智能体在给定的会话（或线程）内解决任务，但有时智能体会跨多个会话（session）。Reflexion（反射机制 ）引入了在智能体每次行动后进行反思，并复用这些自主生成的记忆的理念。生成式智能体（Generative Agents ）会根据过往智能体反馈的集合，定期合成新记忆，模型能在更长的时间段内保持对话一致性和信息引用。Scratchpad（暂存器）：当前会话中临时记录的信息，像是草稿纸。当我们在进行数学演算的时候，我们会打草稿、理清思路和步骤。在开会时，会进行做笔记，方便记录下会议纪要。智能体也是如此，通过暂存器（Scratchpads）记录笔记也是智能体在执行任务时保存信息的一种方法。它的理念是将信息保存在上下文窗口之外，以便智能体可以使用。这样既可以保持上下文窗口的干净整洁，又能让AI拥有持续思考和学习的能力。State（状态）：会话过程中的结构化状态信息，比如执行结果、变量值等。通俗来说：，就像我们平时做项目时，有：历史资料（长期记忆）、临时便条（便签本）、项目文档（状态）——这些都可以写进“记忆区”，供模型后续使用。为了方便小伙伴理解，我把几个名词解释了一下～Scratchpads(暂存器）：是智能体在处理任务过程中，临时存储信息的一种机制，文中介绍了它两种常见实现形式，作用是辅助智能体在单次会话里完成任务，就像人类做任务时，用便签纸随手记关键信息来推进工作 。session（会话 / 线程 ）：指智能体与系统交互的一个连续过程，比如用户使用智能客服咨询问题，从开始咨询到结束对话，就是一个会话，便签本的信息一般在单次会话内有效，辅助本次交互任务。跨会话记忆：有些场景下，智能体需要把不同会话里的信息关联、留存，像 Reflexion 让智能体行动后反思，把经验变成可复用的记忆；Generative Agents 则定期整合过往反馈生成新记忆，这样智能体下次处理任务（可能跨会话 ）时，能调用这些历史记忆，提升处理能力，类似人类积累经验，下次遇到相关事能借鉴之前做法。2. 筛选（Select Context）啥意思呢，就是从工具、“草稿本”、长期记忆、短期记忆、相关知识中检索出最相关的部分，将这些精准的信息投喂给大模型，这可以避免大语言模型的信息过剩，让模型可以聚焦在最关键的问题上。选择来源包括：工具（relevanttools）便签本（scratchpad）长期记忆（long-termmemory）知识库（relevantknowledge）下图是关于三种记忆类型，它把人类的记忆方式类比到 AI Agent 的“记忆系统”中通俗来讲： 像是在“知识仓库”里挑出对当前问题有帮助的资料，避免全部塞进去，节省空间，也减少干扰。3. 压缩（Compress Context）优化内容，让模型读更少的 token，但还保留重点。上文介绍了，OPEN AI 把上下文窗口做到了128K，即使这么大也仍然有上限。当对话历史、调用工具或者检索文档过大时，就必须要删繁区间，通过提取摘要、修剪等策略，智能的为上下文进行瘦身。在不丢失关键信息的情况下，把最核心、最关键的信息留在宝贵的上下文窗口内。比如Claude Code 会在超出上下文窗口的 95% 后运行“自动压缩”，并汇总用户与代理交互的完整轨迹。这种跨代理轨迹的压缩可以使用各种策略，例如递归或分层汇总。两种压缩方式：Summarize（总结）：用总结法保留重点，比如把1000字内容浓缩成200字。Trim（裁剪）：直接剪掉不相关的内容。通俗理解： 就像你写 PPT，只放结论和关键点，不贴整篇论文4. 隔离（Isolate Context）把上下文拆分或隔离开，避免相互干扰。将一个大任务拆分成两个或多个子任务，每个子任务都有一组特定的工具、指令和各自的上下文窗口。这样做，既利用并行计算加速，又通过隔离保证任务处理的独立性和准确性 ，避免多个Agent之间互相干扰和影响。三种隔离方式：Partitioninstate（分区保存）：把不同内容放进不同的状态文件夹中。Holdinsandbox（沙盒保存）：像是临时容器，信息不外泄。Partitionacrossmulti-agent（多智能体分区）：让多个AI分别处理不同部分，互不干扰。通俗来讲： 像多个团队各自处理自己项目的内容，互不打扰，互相传输结果就可以。总结面对超长上下文，系统要像一个聪明的项目经理一样：先记录信息（写）再挑选有用的（选）然后做浓缩压缩（压）最后做好隔离管理（隔）这样，AI 才不会“被信息淹没”，能更高效地思考与行动～小伙伴们，还记得开头的问题吗？看完文章你认为AI是否有记忆呢？我的回答是没有。默认大模型不会主动记住过去的对话，一旦关闭页面、或者开始一个新的对话窗口，它就会忘了你是谁。有些人可能会说，不对呀，我昨天聊的事情，今天还可以接着聊呀？那是因为我们有上下文窗口，它可以临时“记住”一些内容，且完全依赖于你当前这次对话的内容。一旦超过“上下文长度限制，早期的对话就会“遗忘”。小伙伴们，关于Prompt Engineering 和 Context Engineering你们怎么看呢？本文由 @梧桐AI 原创发布于人人都是产品经理。未经作者许可，禁止转载题图来自Unsplash，基于CC0协议该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务