问个问题，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）。
上下文工程，指的是：
举个例子：智能投研助手
用户问“这只股票为什么跌了？”
上下文工程要做的是：
Google DeepMind 的高级 AI 关系工程师 Philipp Schmid 在他最新的一篇博客里也把上下文工程拆成多个组成模块。
包括：
为了方便小伙伴们的理解，这里给大家举个我生活中的小例子：
比如我发出请求说，帮我约小七老师这周日一起去健身，并发一个邮件提醒她。
仔细拆解这个请求，其实包含着两个任务，
第一个任务是去找到我和小七老师周日都有空闲的时间段。
第二个任务是去创建一个日程提醒并发送邮件给小七老师。
这就是复合任务解析。
那么AI会先向系统中已经注册的MCPserver去查询它的能力列表。
比如是不是可以访问日历？是不是有权限去发邮件？是不是能获取到小七老师的联系人信息？这就是工具能力查询。
这些能力的声明和用户的请求一并去交给大语言模型去处理。
基于给定的上下文，去判断应该怎么整合现有的工具去完成任务。
这就是基于上下文整合工具和数据。
不巧的是，小七老师要上课，周日没空。模型会回复我，基于工具调用和查询，发现周日小七老师日程是满的，周六下午6点，你和小七老师都有空闲，需要帮你约周六下午6点吗？
我说OK，那模型就会去调用Email server，把这个邮件帮我发出去。
那如果模型不了解我的上下文，我让它帮我做这件事，它可能就OK我帮我你约好了，
那实际上，周日这天日程是满的，根本就挤不出时间去健身。
这就是上下文缺失的后果。
所以说只有在模型充分了解用户上下文的情况下，它做出的决策才有可能是正确的 。
按照这个发展，是不是上下文窗口越大越好呢？当然不是，长时间运行任务和调用工具意味着Agent通常会消耗大量的Token。
问题一：上下文中毒
即幻觉进入上下文中，比如AI在调用工具时，带回了错误的信息或者纯碎的“幻觉”，那么这些幻觉信息会污染整个上下文，导致后续推理满盘皆输
问题二：上下文干扰
上下文太长，混杂了太多信息，会让模型“注意力分散”，无法专注于重要内容，就像考试时桌上放了一堆没用的参考书；
问题三：语境混淆
一些没用的信息可能影响模型判断，比如你问模型一个问题，它却被上下文中不相关的东西误导了；
问题四：上下文冲突
比如上下文中如果出现前后矛盾的内容（比如版本不一致的说法），模型可能不知道该相信哪一个，导致答复混乱或错误。
Anthropic也明确指出：Agent通常会参与跨越数百个回合的对话，需要谨慎的上下文管理策略。
基于以上挑战，我们该如何应对呢？
我们将Agent上下文工程给予以下四类策略–写入、筛选、压缩、隔离。
针对每个策略我们展开讲讲吧～
让模型记住重要的信息
包含三类“记忆”方式：
Long-term memories（长期记忆）：跨多个对话保留，比如之前的知识、历史任务等。
暂存器帮助智能体在给定的会话（或线程）内解决任务，但有时智能体会跨多个会话（session）。Reflexion（反射机制 ）引入了在智能体每次行动后进行反思，并复用这些自主生成的记忆的理念。生成式智能体（Generative Agents ）会根据过往智能体反馈的集合，定期合成新记忆，模型能在更长的时间段内保持对话一致性和信息引用。
Scratchpad（暂存器）：当前会话中临时记录的信息，像是草稿纸。
当我们在进行数学演算的时候，我们会打草稿、理清思路和步骤。在开会时，会进行做笔记，方便记录下会议纪要。智能体也是如此，通过暂存器（Scratchpads）记录笔记也是智能体在执行任务时保存信息的一种方法。它的理念是将信息保存在上下文窗口之外，以便智能体可以使用。这样既可以保持上下文窗口的干净整洁，又能让AI拥有持续思考和学习的能力。
State（状态）：会话过程中的结构化状态信息，比如执行结果、变量值等。
通俗来说：，就像我们平时做项目时，有：
为了方便小伙伴理解，我把几个名词解释了一下～Scratchpads
(暂存器）：是智能体在处理任务过程中，临时存储信息的一种机制，文中介绍了它两种常见实现形式，作用是辅助智能体在单次会话里完成任务，就像人类做任务时，用便签纸随手记关键信息来推进工作 。
session（会话 / 线程 ）：指智能体与系统交互的一个连续过程，比如用户使用智能客服咨询问题，从开始咨询到结束对话，就是一个会话，便签本的信息一般在单次会话内有效，辅助本次交互任务。
跨会话记忆：有些场景下，智能体需要把不同会话里的信息关联、留存，像 Reflexion 让智能体行动后反思，把经验变成可复用的记忆；Generative Agents 则定期整合过往反馈生成新记忆，这样智能体下次处理任务（可能跨会话 ）时，能调用这些历史记忆，提升处理能力，类似人类积累经验，下次遇到相关事能借鉴之前做法。
啥意思呢，就是从工具、“草稿本”、长期记忆、短期记忆、相关知识中检索出最相关的部分，将这些精准的信息投喂给大模型，这可以避免大语言模型的信息过剩，让模型可以聚焦在最关键的问题上。
选择来源包括：
下图是关于三种记忆类型，它把人类的记忆方式类比到 AI Agent 的“记忆系统”中
通俗来讲： 像是在“知识仓库”里挑出对当前问题有帮助的资料，避免全部塞进去，节省空间，也减少干扰。
优化内容，让模型读更少的 token，但还保留重点。
上文介绍了，OPEN AI 把上下文窗口做到了128K，即使这么大也仍然有上限。当对话历史、调用工具或者检索文档过大时，就必须要删繁区间，通过提取摘要、修剪等策略，智能的为上下文进行瘦身。在不丢失关键信息的情况下，把最核心、最关键的信息留在宝贵的上下文窗口内。
比如Claude Code 会在超出上下文窗口的 95% 后运行“自动压缩”，并汇总用户与代理交互的完整轨迹。这种跨代理轨迹的压缩可以使用各种策略，例如递归或分层汇总。
两种压缩方式：
通俗理解： 就像你写 PPT，只放结论和关键点，不贴整篇论文
把上下文拆分或隔离开，避免相互干扰。
将一个大任务拆分成两个或多个子任务，每个子任务都有一组特定的工具、指令和各自的上下文窗口。这样做，既利用并行计算加速，又通过隔离保证任务处理的独立性和准确性 ，避免多个Agent之间互相干扰和影响。
三种隔离方式：
通俗来讲： 像多个团队各自处理自己项目的内容，互不打扰，互相传输结果就可以。
面对超长上下文，系统要像一个聪明的项目经理一样：
这样，AI 才不会“被信息淹没”，能更高效地思考与行动～
小伙伴们，还记得开头的问题吗？
看完文章你认为AI是否有记忆呢？我的回答是没有。
默认大模型不会主动记住过去的对话，一旦关闭页面、或者开始一个新的对话窗口，它就会忘了你是谁。
有些人可能会说，不对呀，我昨天聊的事情，今天还可以接着聊呀？
那是因为我们有上下文窗口，它可以临时“记住”一些内容，且完全依赖于你当前这次对话的内容。一旦超过“上下文长度限制，早期的对话就会“遗忘”。
小伙伴们，关于Prompt Engineering 和 Context Engineering你们怎么看呢？
本文由 @梧桐AI 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。