什么是上下文工程 Context Engineering｜上下文 Context｜Agent 的缺点
* 标题：【人工智能】什么是上下文工程 Context Engineering｜上下文 Context｜Agent 的缺点｜提示词工程｜RAG｜MCP｜写入｜选取｜压缩｜隔离 * 时长：15 分 20 秒 开篇引入 当你第一次把 ChatGPT、Claude 或 Llama 接入自己的应用，往往会惊叹于它们在 demo 阶段仿佛无所不能；可一旦需要持续稳定地执行多步任务，它们就像一位忘性极大的同事，时而“断片”、时而输出幻觉。大飞在这支 15 分钟的视频里给出了一个犀利的诊断——问题往往不在模型，而在我们没有给它准备好“记忆”和“工具”——即上下文工程 (Context Engineering) 的失败。 这场短小却密度极高的讲解，不只厘清了 Prompt Engineering、RAG、MCP 与 Context Engineering 的关系，更给出了“四字诀”——写入、选取、压缩、隔离，让我们得以像操作系统里的内存管理器一样，精确调度每一 Token 的价值。以下文字，将带你比看视频更深入地理解这门新兴“工程学”的全貌与实战要义。 一、什么是“上下文”？——从聊天记录到三大维度 [00:00-02:20] 核心观点 上下文不是简单的聊天历史，而是所有支撑模型下一步推理的多维信息，可分为指导性、信息性、行动性三大类。 深度阐述 开场不到一分钟，大飞就抛出挑衅性问题：“上下文就是聊天记录吗？”随后他给出更具系统性的定义：“提供给大语言模型用于完成下一步推理或生成任务的全部信息集合”。 他将其拆解为三类： * 指导性上下文 (Guiding Context)：系统提示、任务描述、Few-shot 示例、输出格式。简言之，它告诉模型“做什么、怎么做”。 * 信息性上下文 (Informational Context)：外部检索结果、短期/长期记忆、State、Scratchpad。它回答“需要哪些知识”。 * 行动性上下文 (Actionable Context)：工具定义、调用与结果。它限定“能做什么，以及做完之后的反馈”。 “上下文其实是一个多维、动态、服务于特定任务的系统性的概念，远不止我们以为的聊天记录那么简单。” [01:52] 视频画面里，大飞用一张三栏表格配合颜色高亮，把三类上下文与典型元素一一对应，直观展示层级关系与信息流动方向。若读者脑海里仍将“上下文”简化为聊天历史，这一视觉示意会强迫你建立更立体的认知。 个人感受 你能明显感受到作者的急迫感：如果不先端正“上下文”观念，后续关于工程方法的讨论根本无从谈起。 他多次用“远不止”“其实”来纠正大众误区，语气里带着技术布道者的坚决。 延伸思考 在多模态模型时代，图像、音频乃至传感器数据也将流入上下文窗口——三大类别或许还要继续细分：指导性 prompt 可能包含视觉例子，行动性上下文会涉及 API 之外的物理执行器。 精华收获 * 摆脱“聊天记录”窄定义，理解三类上下文的职能差异。 * 为后续工程手段奠定清晰坐标系。 二、上下文工程的诞生与角色定位 [02:20-04:20] 核心观点 上下文工程是一门系统学科，负责像内存管理器一样，在每个时刻为模型组装“恰到好处”的上下文组合。 深度阐述 大飞借用 Shopify 创始人 Tobi Lütke 和 Andrej Karpathy 的引语，将 Context Engineering 定义为“提供全部必要上下文的艺术与科学”。他打了一个绝妙比喻： “如果把 Agent 视为新型操作系统，模型是 CPU，上下文窗口是内存；上下文工程就是内存管理器，负责决定何时加载、何时换出、何时优先处理。” [03:22] 视频中出现一张 OS 结构示意图：CPU、RAM、Cache 被替换成 Model、Context Window、Scratchpad，红色箭头表示数据在时钟周期中的流动，让技术背景薄弱的观众也能秒懂其职责。 作者进一步指出：Prompt Engineering 与 RAG 只是“单点优化”，而上下文工程是“系统级调度”。它既要考虑检索什么，也要动态重组三类上下文，并在 RAG 失败时选择其他工具。 个人感受 可以听出大飞在“系统”一词上刻意加重语调——这是一次范式升级，他希望观众把目光从单条 prompt 的技巧，抬到“信息供应链”的全局视角。 延伸思考 此比喻也暗示了未来岗位变迁：Prompt 工程师终将演化成“Context Ops”或“LLM Memory Architect”，职责更像数据库与缓存工程师的混合体。 精华收获 * 上下文工程的终极指标不是句子优美，而是系统吞吐量、成本与正确率。 * Prompt Engineering 与 RAG 将被纳入更宏观的上下文流水线。 三、为什么需要上下文工程：两个失败与成功的对照 [04:20-06:50] 核心观点 当模型能力跨过智能阈值后，性能瓶颈几乎都由上下文缺失或冗余引起。 深度阐述 大飞给出两个生动案例。首先是邮件助手场景：Agent 只看到一句“明天有空聚一下吗？”就机械回复；而上下文充足的版本先检索日历、识别联系人重要性、选择合适语气，并提供 send_calendar_invite 工具定义，最终生成能推进事务的回复。 “这里的‘魔力’，并非更智能的模型，而是一个能够为特定任务动态组装合适上下文的系统。” [06:35] 第二个例子聚焦编程 Agent 的长期任务。朴素策略将所有历史交互塞进上下文，导致性能下降、成本激增、最终溢出窗口。屏幕上同时播放 token 计数实时跳涨的动画，直观展示“线性累加”策略的灾难。 个人感受 随着两个对照场景交替播放，你会真切体会到“缺上下文”和“乱上下文”都是致命伤。大飞在提到“上下文干扰”时皱眉、略带无奈，像极了 Debug 时面对幻觉回答的开发者。 延伸思考 这部分为企业应用敲响警钟：模型升级并非灵丹妙药，投入前先自问能否持续提供高质量上下文，否则预算可能都烧在无效 token 上。 精华收获 * 动态组装远优于历史全量累加。 * 成本、延迟、正确率三角中，“上下文策略”是最可控的杠杆。 四、上下文工程四字诀：写入、选取、压缩、隔离 [06:50-13:40] 1. 写入 (Write) 06:50-10:00] 核心观点 通过会话内 Scratchpad 和持久化 Memory，将中间产物与长期价值信息写出上下文窗口之外，为后续检索做准备。 深度阐述 大飞首先区分 Session-level Write（草稿纸）与 Persistent Write（向量数据库／知识图谱）。他示例 ChatGPT 的记忆功能、Anthropic 建议的“子 Agent 写入文件系统”，强调写入是打破窗口上限的前提。画面演示一段代码：Agent 把阶段性计划 JSON 写入 S3，再记录到 PGVector 索引，供未来检索。 个人感受 作者在介绍写入时语速放缓、声音上扬，仿佛在说：“先别急着把东西全塞模型，这里才是长效记忆的入口。” 延伸思考 在隐私敏感场景，写入策略需与加密、数据分级结合，形成“零信任上下文存储”。 精华收获 * Scratchpad 降低短期思考负载，Memory 实现跨会话知识积累。 * 写入质量直接决定后续选取效果。 2. 选取 (Select) 10:00-11:06] 核心观点 在每次调用前，动态拉取与当前子任务最相关的信息，确保上下文信噪比。 深度阐述 大飞将选取分成三类：Deterministic、Model-driven、Retrieval-based，并用 Claude Code 固定加载 CLAUDE.md、模型自筛与向量检索逐一示例。他提示RAG 只是选取里的“检索式”子集，不要把两者等同。 个人感受 此段他用“信噪比”一词反复强调，技术人立刻能联想到信息论的 Shannon 比喻，增加专业沉浸感。 精华收获 * 选取策略决定了后续压缩与推理能否聚焦真正要点。 3. 压缩 (Compress) 11:06-12:00] 核心观点 在有限窗口内，以有损或无损方式用更少 token 保留核心信号。 深度阐述 大飞举 Claude Code 的 “auto-compact” 自动摘要为例，指出其尚不完善，“与其自动压缩，不如最小上下文重启”。他补充硬截断策略虽简单，却可能丢失必要语境。 个人感受 当他说到“硬截断”时轻叹一声，透出实际开发中被截断坑过的无奈，这种情绪贴近一线工程师的痛点。 精华收获 * 压缩算法选择需权衡信息完整性与 token 预算。 4. 隔离 (Isolate) 12:00-13:40] 核心观点 在系统架构层面为多信息流设边界，通过子 Agent 或沙盒先行消化，仅上交摘要，既降噪又降成本。 深度阐述 隔离被视为“跨流压缩”。大飞引用 Anthropic “搜索即压缩”理念，延伸到多 Agent 架构：子 Agent 像专家团队，主 Agent 只处理提炼后的摘要报告。屏幕上动画展示主-子 Agent 栈调用，主流 Green/Red 通道分别代表高价值摘要与原始长文，强化“减负”直观感。 精华收获 * 隔离通过模块化降低上下文冲突，是大规模系统的必备设计。 五、MCP：上下文工程的接口基建 [13:40-15:00] 核心观点 模型上下文协议 (MCP) 是为行动性及部分信息性上下文提供标准化交换的基础设施，是实现稳健上下文工程的管道。 深度阐述 在收束全文前，大飞再次点题：MCP 可被视为“上下文交换协议”，让 Agent 与工具／数据源通信更安全、流畅。 “多数 AI Agent 的失败，并不是模型能力上的失败，而是上下文工程的失败。” [15:00] 这句近乎宣言的话，配合作者举起的 T 恤广告牌，既自嘲也强化记忆点。 延伸思考 随着 Open-AI function calling、LangChain Schemas 等方案涌现，MCP 不止一种实现，但**“接口即治理”**——标准化是团队协作与合规落地的前提。 精华收获 * 工程不是孤岛，标准协议决定生态生死。 * 做好上下文工程，要像 DevOps 一样重视接口规范。 全文精华收获 * 观念升级：上下文是多维动态系统，Prompt 与 RAG 只是其中组件。 * 系统思维：把自己当作内存管理器，以写入-选取-压缩-隔离四步对信息流做全链路治理。 * 性能杠杆：当模型能力趋同，胜负手在于上下文供应链；成本、延迟、正确率可通过精细调度显著优化。 * 方法论落地： * 会话 Scratchpad + 持久 Memory 构建长期记忆。 * 三类选取策略确保信噪比。 * 压缩算法与截断策略要结合任务敏感度。 * 多 Agent 隔离架构减轻主模型负担。 * 未来启示：Prompt 工程师的下一站是“Context Architect”；MCP 等协议将成为 LLM 基建的新战场。 透过 15 分钟的高密度讲解与本文的深度拆解，你不仅能够复现视频里的每个关键知识点，更能获得一套可立即用于产品设计与团队协作的上下文工程思维框架——让你的 LLM 系统少掉链子，多出成果。 聊天讨论群，微信群二维码（如果进不了，看频道首页，可加个人微信gxjdian入群）
* 标题：【人工智能】什么是上下文工程 Context Engineering｜上下文 Context｜Agent 的缺点｜提示词工程｜RAG｜MCP｜写入｜选取｜压缩｜隔离 * 时长：15 分 20 秒 开篇引入 当你第一次把 ChatGPT、Claude 或 Llama 接入自己的应用，往往会惊叹于它们在 demo 阶段仿佛无所不能；可一旦需要持续稳定地执行多步任务，它们就像一位忘性极大的同事，时而“断片”、时而输出幻觉。大飞在这支 15 分钟的视频里给出了一个犀利的诊断——问题往往不在模型，而在我们没有给它准备好“记忆”和“工具”——即上下文工程 (Context Engineering) 的失败。 这场短小却密度极高的讲解，不只厘清了 Prompt Engineering、RAG、MCP 与 Context Engineering 的关系，更给出了“四字诀”——写入、选取、压缩、隔离，让我们得以像操作系统里的内存管理器一样，精确调度每一 Token 的价值。以下文字，将带你比看视频更深入地理解这门新兴“工程学”的全貌与实战要义。 一、什么是“上下文”？——从聊天记录到三大维度 [00:00-02:20] 核心观点 上下文不是简单的聊天历史，而是所有支撑模型下一步推理的多维信息，可分为指导性、信息性、行动性三大类。 深度阐述 开场不到一分钟，大飞就抛出挑衅性问题：“上下文就是聊天记录吗？”随后他给出更具系统性的定义：“提供给大语言模型用于完成下一步推理或生成任务的全部信息集合”。 他将其拆解为三类： * 指导性上下文 (Guiding Context)：系统提示、任务描述、Few-shot 示例、输出格式。简言之，它告诉模型“做什么、怎么做”。 * 信息性上下文 (Informational Context)：外部检索结果、短期/长期记忆、State、Scratchpad。它回答“需要哪些知识”。 * 行动性上下文 (Actionable Context)：工具定义、调用与结果。它限定“能做什么，以及做完之后的反馈”。 “上下文其实是一个多维、动态、服务于特定任务的系统性的概念，远不止我们以为的聊天记录那么简单。” [01:52] 视频画面里，大飞用一张三栏表格配合颜色高亮，把三类上下文与典型元素一一对应，直观展示层级关系与信息流动方向。若读者脑海里仍将“上下文”简化为聊天历史，这一视觉示意会强迫你建立更立体的认知。 个人感受 你能明显感受到作者的急迫感：如果不先端正“上下文”观念，后续关于工程方法的讨论根本无从谈起。 他多次用“远不止”“其实”来纠正大众误区，语气里带着技术布道者的坚决。 延伸思考 在多模态模型时代，图像、音频乃至传感器数据也将流入上下文窗口——三大类别或许还要继续细分：指导性 prompt 可能包含视觉例子，行动性上下文会涉及 API 之外的物理执行器。 精华收获 * 摆脱“聊天记录”窄定义，理解三类上下文的职能差异。 * 为后续工程手段奠定清晰坐标系。 二、上下文工程的诞生与角色定位 [02:20-04:20] 核心观点 上下文工程是一门系统学科，负责像内存管理器一样，在每个时刻为模型组装“恰到好处”的上下文组合。 深度阐述 大飞借用 Shopify 创始人 Tobi Lütke 和 Andrej Karpathy 的引语，将 Context Engineering 定义为“提供全部必要上下文的艺术与科学”。他打了一个绝妙比喻： “如果把 Agent 视为新型操作系统，模型是 CPU，上下文窗口是内存；上下文工程就是内存管理器，负责决定何时加载、何时换出、何时优先处理。” [03:22] 视频中出现一张 OS 结构示意图：CPU、RAM、Cache 被替换成 Model、Context Window、Scratchpad，红色箭头表示数据在时钟周期中的流动，让技术背景薄弱的观众也能秒懂其职责。 作者进一步指出：Prompt Engineering 与 RAG 只是“单点优化”，而上下文工程是“系统级调度”。它既要考虑检索什么，也要动态重组三类上下文，并在 RAG 失败时选择其他工具。 个人感受 可以听出大飞在“系统”一词上刻意加重语调——这是一次范式升级，他希望观众把目光从单条 prompt 的技巧，抬到“信息供应链”的全局视角。 延伸思考 此比喻也暗示了未来岗位变迁：Prompt 工程师终将演化成“Context Ops”或“LLM Memory Architect”，职责更像数据库与缓存工程师的混合体。 精华收获 * 上下文工程的终极指标不是句子优美，而是系统吞吐量、成本与正确率。 * Prompt Engineering 与 RAG 将被纳入更宏观的上下文流水线。 三、为什么需要上下文工程：两个失败与成功的对照 [04:20-06:50] 核心观点 当模型能力跨过智能阈值后，性能瓶颈几乎都由上下文缺失或冗余引起。 深度阐述 大飞给出两个生动案例。首先是邮件助手场景：Agent 只看到一句“明天有空聚一下吗？”就机械回复；而上下文充足的版本先检索日历、识别联系人重要性、选择合适语气，并提供 send_calendar_invite 工具定义，最终生成能推进事务的回复。 “这里的‘魔力’，并非更智能的模型，而是一个能够为特定任务动态组装合适上下文的系统。” [06:35] 第二个例子聚焦编程 Agent 的长期任务。朴素策略将所有历史交互塞进上下文，导致性能下降、成本激增、最终溢出窗口。屏幕上同时播放 token 计数实时跳涨的动画，直观展示“线性累加”策略的灾难。 个人感受 随着两个对照场景交替播放，你会真切体会到“缺上下文”和“乱上下文”都是致命伤。大飞在提到“上下文干扰”时皱眉、略带无奈，像极了 Debug 时面对幻觉回答的开发者。 延伸思考 这部分为企业应用敲响警钟：模型升级并非灵丹妙药，投入前先自问能否持续提供高质量上下文，否则预算可能都烧在无效 token 上。 精华收获 * 动态组装远优于历史全量累加。 * 成本、延迟、正确率三角中，“上下文策略”是最可控的杠杆。 四、上下文工程四字诀：写入、选取、压缩、隔离 [06:50-13:40] 1. 写入 (Write) 06:50-10:00] 核心观点 通过会话内 Scratchpad 和持久化 Memory，将中间产物与长期价值信息写出上下文窗口之外，为后续检索做准备。 深度阐述 大飞首先区分 Session-level Write（草稿纸）与 Persistent Write（向量数据库／知识图谱）。他示例 ChatGPT 的记忆功能、Anthropic 建议的“子 Agent 写入文件系统”，强调写入是打破窗口上限的前提。画面演示一段代码：Agent 把阶段性计划 JSON 写入 S3，再记录到 PGVector 索引，供未来检索。 个人感受 作者在介绍写入时语速放缓、声音上扬，仿佛在说：“先别急着把东西全塞模型，这里才是长效记忆的入口。” 延伸思考 在隐私敏感场景，写入策略需与加密、数据分级结合，形成“零信任上下文存储”。 精华收获 * Scratchpad 降低短期思考负载，Memory 实现跨会话知识积累。 * 写入质量直接决定后续选取效果。 2. 选取 (Select) 10:00-11:06] 核心观点 在每次调用前，动态拉取与当前子任务最相关的信息，确保上下文信噪比。 深度阐述 大飞将选取分成三类：Deterministic、Model-driven、Retrieval-based，并用 Claude Code 固定加载 CLAUDE.md、模型自筛与向量检索逐一示例。他提示RAG 只是选取里的“检索式”子集，不要把两者等同。 个人感受 此段他用“信噪比”一词反复强调，技术人立刻能联想到信息论的 Shannon 比喻，增加专业沉浸感。 精华收获 * 选取策略决定了后续压缩与推理能否聚焦真正要点。 3. 压缩 (Compress) 11:06-12:00] 核心观点 在有限窗口内，以有损或无损方式用更少 token 保留核心信号。 深度阐述 大飞举 Claude Code 的 “auto-compact” 自动摘要为例，指出其尚不完善，“与其自动压缩，不如最小上下文重启”。他补充硬截断策略虽简单，却可能丢失必要语境。 个人感受 当他说到“硬截断”时轻叹一声，透出实际开发中被截断坑过的无奈，这种情绪贴近一线工程师的痛点。 精华收获 * 压缩算法选择需权衡信息完整性与 token 预算。 4. 隔离 (Isolate) 12:00-13:40] 核心观点 在系统架构层面为多信息流设边界，通过子 Agent 或沙盒先行消化，仅上交摘要，既降噪又降成本。 深度阐述 隔离被视为“跨流压缩”。大飞引用 Anthropic “搜索即压缩”理念，延伸到多 Agent 架构：子 Agent 像专家团队，主 Agent 只处理提炼后的摘要报告。屏幕上动画展示主-子 Agent 栈调用，主流 Green/Red 通道分别代表高价值摘要与原始长文，强化“减负”直观感。 精华收获 * 隔离通过模块化降低上下文冲突，是大规模系统的必备设计。 五、MCP：上下文工程的接口基建 [13:40-15:00] 核心观点 模型上下文协议 (MCP) 是为行动性及部分信息性上下文提供标准化交换的基础设施，是实现稳健上下文工程的管道。 深度阐述 在收束全文前，大飞再次点题：MCP 可被视为“上下文交换协议”，让 Agent 与工具／数据源通信更安全、流畅。 “多数 AI Agent 的失败，并不是模型能力上的失败，而是上下文工程的失败。” [15:00] 这句近乎宣言的话，配合作者举起的 T 恤广告牌，既自嘲也强化记忆点。 延伸思考 随着 Open-AI function calling、LangChain Schemas 等方案涌现，MCP 不止一种实现，但**“接口即治理”**——标准化是团队协作与合规落地的前提。 精华收获 * 工程不是孤岛，标准协议决定生态生死。 * 做好上下文工程，要像 DevOps 一样重视接口规范。 全文精华收获 * 观念升级：上下文是多维动态系统，Prompt 与 RAG 只是其中组件。 * 系统思维：把自己当作内存管理器，以写入-选取-压缩-隔离四步对信息流做全链路治理。 * 性能杠杆：当模型能力趋同，胜负手在于上下文供应链；成本、延迟、正确率可通过精细调度显著优化。 * 方法论落地： * 会话 Scratchpad + 持久 Memory 构建长期记忆。 * 三类选取策略确保信噪比。 * 压缩算法与截断策略要结合任务敏感度。 * 多 Agent 隔离架构减轻主模型负担。 * 未来启示：Prompt 工程师的下一站是“Context Architect”；MCP 等协议将成为 LLM 基建的新战场。 透过 15 分钟的高密度讲解与本文的深度拆解，你不仅能够复现视频里的每个关键知识点，更能获得一套可立即用于产品设计与团队协作的上下文工程思维框架——让你的 LLM 系统少掉链子，多出成果。 聊天讨论群，微信群二维码（如果进不了，看频道首页，可加个人微信gxjdian入群）