西宁市网站建设_网站建设公司_Java_seo优化

从"提示工程"向"上下文工程"转变标志着AI应用开发的新范式。上下文工程关注如何系统性地准备AI推理所需的所有信息，而非仅优化提示词。它包含四大策略：写入/代理式内存、压缩/精炼、隔离/分治、选择/RAG升级。为解决"上下文腐烂"问题，文章提出三层架构：数据与知识层、语义层、代理与编排层。这一转变使开发者从"与AI聊天的人"进化为"AI系统架构师"，构建更高效可靠的AI系统。

想象一下，你让你的 AI 差旅助手“小智”去“预订下个月去朝阳开会的酒店”。

几秒钟后，它回复：“搞定！我为您预订了汉庭酒店，位于辽宁省朝阳市。”

你很生气，但转念一想，这可能是你的错。你没有说清楚是“北京市朝阳区”。这是**提示工程（Prompt Engineering）**的失败。

于是你吸取教训，发出了更明确的指令：“在北京市朝阳区，帮我订三里屯附近的酒店，预算1000 一晚。“小智迅速完成了预订。然而，当你提交报销时，却被财务拒绝了，因为这远远超过了你公司 500 元/晚的差旅标准。

这一次，你很难再责怪自己。

一个真正智能的助手，难道不应该被“工程化”地接入你的日历（工具）以自动知晓会议地点，并主动查询公司的差旅政策（RAG）来提醒你预算超标吗？

这个case，正是“提示工程”的上限和“上下文工程”（Context Engineering）的起点。

一场已经发生的认知革命：从“提示”到“上下文”

过去两年，我们都痴迷于“提示工程”——试图找到那句能让 AI 产生惊艳结果的“魔法咒语”。但 AI 领域的顶尖实践者们，已经开始转向一个更宏大、更系统的领域。

“Context Engineering”的概念源于几个大神在 X 中的讨论。

Shopify 的 CEO Tobi Lütke 在 2025年6月19号 首先提出了“Context Engineering”：

我真的更喜欢“上下文工程”这个词，而不是“提示工程”。它更好地描述了核心技能：提供任务所需的所有上下文，使其能被 LLM 合理地解决。

这个观点迅速得到了 Andrej Karpathy 的响应，他将其拔高到了“工业级应用”的层面：

为“上下文工程”点赞。……在每一个工业级的 LLM 应用中，上下文工程都是一门精细的艺术和科学，它要做的就是在下一步中用恰到好处的信息填满上下文窗口。

最后，BloomTech 的 CEO Austen Allred 发表了极具冲击力的总结：

上下文工程比提示工程强 10 倍。

为什么他们都在强调要从“提示工程”向“上下文工程”转变？因为我们构建 AI 的方式已经发生了根本变化。

到底什么是上下文工程？

如果说“提示工程”关心的是“你问什么”，那么“上下文工程”关心的就是“你如何准备让模型来回答”。

它不再是关于设计单个指令文本，而是演变为一门系统级的学科：在 AI Agent 执行任务的每一步，动态地、程序化地组装和优化 LLM 在推理时看到的所有信息。

一个简单的公式可以概括：

上下文工程 = 提示工程 + （RAG + 工具 + 内存 + 任务状态 + …）

Andrej Karpathy 有一个最棒的比喻：LLM 是 CPU，上下文窗口就是它的 RAM。

“提示工程”就像是在 RAM 里写一个简单的脚本。而“上下文工程”则是构建一个完整的操作系统，它需要决定在每一纳秒，哪些数据应该被加载进 RAM，哪些应该被清除，哪些应该被压缩后存入硬盘。

IBM 表示一个 AI Agent 最终在运行时看到的“总提示词”，可能只有 20% 是你写的静态指令，而 80% 是由上下文工程动态组装的内容（如 RAG 的检索结果、内存中的事实、工具的 API 响应等）。

一个设计精良的上下文“信息有效载荷”（information payload），通常由以下组件构成：

• 指令提示词（Instruction Prompt）：系统提示词，用于设定 AI 的角色、规则和必须遵循的原则和工作流程。
• 知识（Knowledge）：通过 RAG（Retrieval-Augmented Generation，检索增强生成）、GraphRAG（Graph Retrieval-Augmented Generation，图谱检索增强生成） 或 API 检索到的内/外部数据。
• 内存 （Memory）：短期（对话历史）和长期（跨会话的用户偏好等）。
• 工具（Tools）：工具的 API 规范（告知 AI 它能做什么）和工具的响应（告知 AI 它刚做了什么，得到了什么结果）。
• 状态（State）：一个“暂存器”（Scratchpad），用于跟踪多步骤任务的进展。
• 输出结构（Output Structure）：强制模型按特定 JSON 或 XML Schema 输出的指令，以便下游系统解析。

核心挑战：“天真 RAG” 与 “上下文腐烂”

在深入实践之前，我们必须理解上下文工程要解决的核心问题。

首先，我们必须弄清一个概念：“天真 RAG”（Naive RAG）。

“天真 RAG” 是我们最早接触 RAG 时的做法：1. 将一堆 PDF 文档无脑切成小块（Chunking）；2. 将这些碎块全部“向量化”（Embedding）后塞进向量数据库；3. 当用户提问时，捞出最相似的 5 到 10 个碎块（原理：将问题Embedding，然后在向量数据库中计算”问题向量“和”知识向量“的”余弦相似度“，越相似则向量间的夹角越小），然后把它们和问题一起塞给 LLM。

你可能会想：现在上下文窗口越来越大，从 128K 到 1M Token，我把所有资料都塞进去不就行了？

这是一个致命的误解。这里边存在一个核心悖论：

• “上下文腐烂”（Context Rot）：Anthropic 的“大海捞针”测试和 Chroma 的研究都表明，上下文窗口是一种有限的“注意力预算” （Attention Budget）。当上下文中的信息（Token）过多时，模型准确回忆和利用信息的能力反而会急剧下降。
• 上下文“失败模式”：简单地塞满上下文，会导致：

• 上下文中毒（Context Poisoning）：不相关或错误的信息会“污染”模型的推理。
• 上下文混淆（Context Confusion）：过量（即使相关）的信息也会“淹没”模型，使其分心（tips：模型天然对上下文的头部和尾部的内容注意力更高）。

因此，上下文工程的真正目标，是追求 Anthropic 所提出的的：“最小可行的高信号 Token 集” （smallest possible set of high-signal tokens）。我们不再是“信息填充者”，而是“信息规划者”。

工程应用的四大核心策略

那么，我们具体该如何“工程化”这个 ”RAM“ ？

1. 写入（Write）/ 代理式内存（Agentic Memory）

• 是什么：允许 Agent “记笔记”。将关键事实、中间结论或用户偏好，写入到上下文窗口之外的持久化存储中（例如一个 NOTES.md 文件或专用的内存工具）。
• 举例：Anthropic 曾展示 Claude 玩《宝可梦》。它会在游戏过程中不断地“记笔记”，比如“我正在1号公路训练皮卡丘，目标10级，已完成8级”。当上下文窗口重置后，它会“读回笔记”，从而实现跨越数小时的长周期任务。

2. 压缩（Compress）/ 精炼

• 是什么：当上下文接近极限时，主动进行“有损压缩”。Anthropic 将之称为 “Compaction”。
• 举例：最简单却高效的技巧是“工具结果清理”（Tool result clearing）。假设 AI 调用了一个 API 来查询订单，该 API 返回了一个包含 1000 个 Token 的巨大 JSON。在“压缩”策略下，AI 在确认信息后，会丢弃这个 JSON，只在上下文中保留一句“状态：订单 8975 已确认”，从而释放 990+ 个宝贵的 Token 空间。

3. 隔离（Isolate）/ 分治

• 是什么：通过“子代理架构”（Sub-agent Architectures）将复杂任务分解。
• 举例：来自 Human Layer 团队的实践：一个“主代理”需要在一个复杂代码库中查找功能 。它启动一个“搜索子代理”。这个子代理可以在自己的上下文窗口中“消耗”50,000 个 Token（读取文件、grep、分析依赖），这个过程是“脏”和“高噪音”的。但它最终只向主代理返回一个 50 Token 的摘要：“功能 X 位于 utils/auth.py 第 42 行”。主代理的上下文因此保持了“干净”和“高信号”。

4. 选择（Select）/ RAG升级

• 是什么：这是 RAG 的进化版。代理在需要时，主动“选择”要拉取什么信息放入上下文。
• 举例：这不再是“天真 RAG”。一个成熟的代理会混合使用多种工具来实现“即时上下文” (Just-in-Time Context) ：

• 任务：总结一下‘XX项目’的风险。
• 选择1（GraphRAG）：查询知识图谱获取结构化关系：谁是项目经理？依赖哪些项目？
• 选择2（API工具）：调用 Jira API 获取实时数据：有哪些未解决的 P0 Bug？
• 选择3（文件工具）：grep 代码库查找关键实现：//TODO: HACK
• 选择4（向量检索）：最后才使用向量检索：“找找看还有哪些文档和风险相关。

上下文工程的三层架构

理论很清晰，但在一个复杂系统中，尤其是企业应用，如何将这些策略落地？答案是构建一个分层的架构，实现可治理、可扩展的 AI Agent。

L1：数据与知识层（The Source Layer）

这是所有信息的源头，也是上下文工程的“弹药库”。

• 作用：存储企业的所有知识，包括结构化数据（数据库）、半结构化数据（JSON、API）和非结构化数据（PDF、文档）。
• 如何构建：

• 向量数据库（Vector DBs）：这是“天真 RAG”的基础。通过“Chunking-Embedding”的方式处理非结构化文档。
• 知识图谱（Knowledge Graph – KG）：这是 RAG 的进化，即 GraphRAG。知识图谱不再存储“扁平的文本块”，而是存储实体（Entities）和关系（Relationships）。
• 举例：
• 天真 RAG：你问“‘XX项目’的负责人是谁？”，它从 PDF 中检索出 10 个包含“XX项目”和“负责人”的段落，答案可能就藏在其中。
• GraphRAG：你问同样的问题，它直接从 KG 中返回一个精确的事实：{实体: “张三”} -[关系: LEADS]-> {实体: “XX项目”} 。这极大提升了检索的准确性和可解释性。

一张表看懂 天真 RAG 和 GraphRAG ：

L2：语义层（The Semantic Layer）

这是最关键、也最容易被忽视的一层。它是数据和 AI 之间的“翻译官”和“治理者”。

• 作用：它是一个集中的“元数据中心”，用于标准化数据定义和治理策略。

• 为什么至关重要：它解决了“巴别塔”问题（由圣经《创世纪》中“巴别塔”故事所引发的象征性困境，具体来说就是由于语言不通造成的沟通障碍和合作失败）。

• 举例：

  情景1：没有 L2（AI 瞎猜）：

  用户提问：上季度我们的“活跃用户”有多少？

  **AI 的困境： AI 在数据层（L1）发现两个冲突的定义：****销售库（L1）：active_users = 30天内付费的用户。产品库（L1）：dau = 24小时内登录的用户。**结果：AI 彻底懵了，只能瞎猜一个（比如它猜了“登录”用户），导致给出了一个完全错误的答案。

情景2：有了 L2（AI 查字典）：

L2 是一个由****人类专家预先定义好的“权威业务词典”。AI 不再需要猜测。
在这个“词典”里，人类已经写明了一条“唯一事实”：“活跃用户”（业务术语）= 30天，付费的用户（业务定义） = [执行这条 SQL 查询 sales_db]。
现在 AI 的工作流被彻底改变了：
AI 先向 L2 提问：“活跃用户”的定义是什么？
L2 响应：这是“活跃用户”的唯一定义，以及它的SQL 查询语句。
AI 执行 L1：AI 拿着 L2 给的“标准答案”SQL，去 L1 的 sales_db 中执行，得到 100% 准确的结果。

• 总结：L2 语义层不存数据，只存“定义”和“权威指令”。它确保了 Agent 在面对复杂业务时，其行为 100% 可控、可预测，并始终与人类专家的业务口径保持一致。

L3：代理与编排层（The Agentic Layer）

这是上下文工程的“指挥中心”和“CPU”。

• 作用：这是 Agent 本身所在的地方。它负责接收用户目标，并执行上文提到的“四大策略”（写入、压缩、隔离、选择）。
• 如何构建：使用 LangChain 的 LangGraph、LlamaIndex 的 Workflows 、 Anthropic 提出的“规范驱动工作流”或自行开发来编排 Agent 的行为。
• 举例（三层联动）：

1. 目标：用户要求“总结一下‘XX项目’的风险”。
2. 查询 L2（语义层）：Agent 首先访问 L2，查询“XX项目”和“风险”的定义。L2 告诉它：“相关数据在知识图谱A（查状态）和 Jira API B（查Bugs）”。
3. 选择（L3）：Agent 选择并调用 GraphRAG 工具和 Jira 工具。
4. 检索（L1）：它从 L1 的知识图谱中拉取‘XX项目’的状态，并调用 Jira API 获取最新的 Bug 报告。
5. 写入/压缩（L3）：它得到了两个巨大的 JSON 响应。它使用“Write”策略将它们放入“暂存器”，并使用“Compress”策略将其总结为几个关键风险点。
6. 响应：最后，它基于这些精炼过的“高信号”上下文，生成一份准确的总结报告。

总结

从“提示工程”到“上下文工程”的转变，标志着我们从“与 AI 聊天的人”进化为“AI 系统架构师”。

提示工程给你带来更好的问题，上下文工程给你带来更好的系统。

AI 应用开发不再是比拼谁的提示词写得更巧妙，而是比拼谁能构建出更高效、更可靠的上下文供给系统。这不再是一个“提示”问题，这是一个“架构”问题，例如构建一个三层架构，利用知识图谱提供结构化知识，利用语义层实现治理和统一理解等。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】