深度解析Context Engineering：从提示词工程到智能体系统架构的演进(必读收藏)
回顾过去一年 AI 领域对 “提示词工程（Prompt Engineering）” 的深度剖析，一个细微却影响深远的概念分歧逐渐浮出水面。这一分歧不仅是术语定义的差异，更折射出 AI 应用从简单交互向复杂系统演进的核心趋势。
一、术语之争背后的领域演进：从 Prompt 到 Context 的认知升级
当 AI 实践从单次对话交互迈向规模化智能体（Agent）系统构建时，“如何定义输入优化工作” 成为前沿实践者与学术界共同关注的焦点，形成了两种代表性观点：
（一）工程实践派的 “Context Engineering” 主张
以 Andrej Karpathy 为代表的一线系统构建者，率先提出用 “上下文工程（Context Engineering）” 替代 “提示词工程”。在他们看来，“提示词工程” 的表述存在显著局限 —— 它将复杂的系统工作简化为 “在聊天框里输入文字”，正如业内调侃的 “给打字行为起了个故作高深的名字”。
这类实践者的核心诉求在于：构建智能体系统的关键挑战，早已超越 “设计一句优质指令” 的范畴。以自动代码生成 Agent 为例，其核心需求是设计一套能动态整合代码库信息、语法规则、用户历史需求的数据流架构，而非仅优化 “请生成 XX 功能代码” 的静态提示。他们认为，“Context Engineering” 更能体现 “为模型提供完整任务环境” 的系统思维。
（二）学术研究界的 “Prompt Engineering” 广义定义
在学术文献与标准化研究中，“提示词工程” 被赋予了更宽泛的 “伞形术语（umbrella term）” 属性。例如，斯坦福大学《Prompt Engineering 指南》将其定义为 “所有不修改模型权重、仅通过调整输入内容优化模型输出的技术集合”，其中明确包含 “支持性内容（Supporting Content）” 与 “上下文信息（Context）”。
这种定义方式的优势在于兼容性 —— 它能涵盖从简单零样本提示到复杂少样本示例设计的全场景，便于不同研究成果的横向对比。但在工程实践者看来，这种 “大而全” 的定义模糊了 “编写指令” 与 “构建系统” 的层级差异。
（三）分歧的本质：AI 系统成熟度的阶段性映射
两种术语的碰撞，本质上是 AI 应用发展的必然结果：
- 早期阶段：AI 交互以单次、简单任务为主（如文本摘要、信息问答），优化静态提示词即可显著提升效果，“Prompt Engineering” 足以描述核心工作；
- 当前阶段：AI 系统需处理多步骤、长周期任务（如企业级知识库问答、自动化数据分析），仅靠优化指令无法解决 “信息动态整合”“状态持续管理” 等问题，“Context Engineering” 应运而生。
简言之，二者并非对立关系，而是层次差异：Prompt Engineering 是 “设计指令的技能（skill）”，Context Engineering 是 “构建自动化上下文系统的科学（science）”。即使学术定义中包含上下文要素，工程实践仍需专门学科聚焦 “动态上下文的构建与管理”。
二、核心概念辨析：Prompt 与 Context 的边界与关联
要理解这一范式跃迁，需先明确二者的定义、技术体系与局限性，建立清晰的概念框架。
（一）Prompt Engineering：指令设计的 “技艺”
作为与大语言模型（LLM）交互的基础方法，Prompt Engineering 的核心是通过结构化输入引导模型输出，其技术体系围绕 “如何让指令更精准” 展开。
1. 提示词的核心构成要素
一个完整的提示词并非单一语句，而是包含多组件的 “沟通包”：
- 核心指令（Instructions）：明确模型需执行的任务，如 “将以下英文文档翻译成中文”“分析用户反馈中的负面情绪”；
- 输入数据（Primary Content）：模型需处理的原始信息，可能是文本、表格、代码片段等；
- 示例演示（Examples/Shots）：通过 “输入 - 输出” 配对提供学习样本，例如在情感分析任务中，先给出 “‘产品很好用’→正面” 的示例，帮助模型理解任务标准；
- 输出指引（Cues/Output Indicators）：规定输出格式或启动信号，如 “请以 JSON 格式返回结果”“分析完毕后，直接输出结论：”；
- 背景补充（Supporting Content）：为任务提供必要上下文，如 “基于 2023 年公司财务报告，回答以下问题”—— 这一组件正是 Context Engineering 的概念雏形。
2. Prompt Engineering 的核心技术
Prompt Engineer 使用一系列技术来优化模型输出，这些技术可按复杂性进行分类：
- 零样本提示（Zero-Shot Prompting）： 在不提供任何示例的情况下直接向模型下达任务，完全依赖其在预训练阶段获得的知识和推理能力。
- 少样本提示（Few-Shot Prompting）： 在提示中提供少量（通常为 1 到 5 个）高质量的示例，以引导模型的行为。对于复杂任务，这种“上下文学习”方法被证明极为有效。
- 思维链提示（Chain-of-Thought Prompting, CoT）： 引导模型将复杂问题分解为一系列中间推理步骤，显著增强了其在逻辑、数学和推理任务上的表现。
- 高级推理技术： 在 CoT 的基础上，研究人员还开发了更为复杂的变体，如思维树（Tree-of-Thought）、苏格拉底式提示（Maieutic Prompting）和由简到繁提示（Least-to-Most Prompting），以探索更多样化的解决方案路径。
3.以提示为中心的方法的局限性
尽管 Prompt Engineering 至关重要，但对于构建稳健、可用于生产环境的系统而言，它存在固有的局限性：
- 脆弱性&不可复现性： 提示中微小的措辞变化可能导致输出结果的巨大差异，使得这一过程更像是一种依赖反复试错的“艺术”，而非可复现的“科学”。
- 扩展性差： 手动、迭代地优化提示的过程，在面对大量用户、多样化用例和不断出现的边缘情况时，难以有效扩展。
- 用户负担： 这种方法将精心构建一套详尽指令的负担完全压在了用户身上，对于需要自主运行、或处理高并发请求的系统而言是不切实际的。
- 无状态性： Prompt Engineering 本质上是为单轮、“一次性”的交互而设计的，难以处理需要记忆和状态管理的长对话或多步骤任务。
（二） Context Engineering 兴起：范式的转移
Context Engineering 并非要取代 Prompt Engineering，而是一个更高阶、更侧重于系统设计的必要学科。
1. 定义 Context Engineering
Context Engineering 是一门设计、构建并优化动态自动化系统的学科，旨在为大型语言模型在正确的时间、以正确的格式，提供正确的信息和工具，从而可靠、可扩展地完成复杂任务。
prompt 告诉模型如何思考，而 Context 则赋予模型完成工作所需的知识和工具。
2. “Context”的范畴
“Context”的定义已远超用户单次的即时提示，它涵盖了 LLM 在做出响应前所能看到的所有信息生态系统：
- 系统级指令和角色设定。
- 对话历史（短期记忆）。
- 持久化的用户偏好和事实（长期记忆）。
- 动态检索的外部数据（例如来自RAG）。
- 可用的工具（API、函数）及其定义。
- 期望的输出格式（例如，JSON Schema）。
3. 对比分析
关系：超集，而非对抗、竞争
Prompt Engineering 是 Context Engineering 的一个子集。
- Context Engineering 决定用什么内容填充 Context Window，
- Prompt Engineering 则负责优化窗口内的具体指令。
Prompt Engineering vs. Context Engineering
三、Context Engineering 的技术基石：检索增强生成（RAG）
在 Context Engineering 的实践中，检索增强生成（Retrieval-Augmented Generation, RAG）是最核心、最成熟的技术架构。它通过 “检索外部知识→增强模型输入→生成精准结果” 的流程，解决了 LLM 的固有缺陷，成为企业级 AI 应用的标配。
（一）RAG 的核心价值：弥补 LLM 的三大短板
标准 LLM 在企业场景中存在明显局限，而 RAG 通过动态引入外部知识，从根本上解决了这些问题：
- 突破知识冻结：LLM 的知识截止于训练数据时间（如 GPT-4 截止到 2023 年 10 月），无法获取实时信息。RAG 可在推理时检索最新数据（如 2024 年行业报告），让模型输出具备时效性；
- 接入私有知识：企业内部文档（如技术手册、客户资料）未纳入 LLM 训练数据，RAG 可将这些私有数据转化为检索资源，使模型能回答 “公司产品的保修政策” 等内部问题；
- 降低幻觉风险：LLM 可能生成虚构信息（“幻觉”），而 RAG 让模型基于可验证的检索结果生成回答，例如在医疗咨询中，模型可引用权威医学文献作为依据，提升可信度。
（二）RAG 的核心工作流程
RAG 的实现分为离线索引与在线推理两个阶段，形成完整的闭环：
1. 离线索引阶段（数据准备）
- 文档加载：导入各类数据源，包括结构化数据（Excel 表格）、非结构化数据（PDF 文档、Word 文件）、半结构化数据（HTML 页面、JSON 日志）；
- 文本分块：将长文档分割为语义连贯的短块（Chunk），例如将一份 50 页的技术手册，按章节分割为 200-300 词的文本块，避免单次输入超出 LLM 上下文窗口；
- 向量转换：通过嵌入模型（如 Sentence-BERT、OpenAI Embeddings）将文本块转化为向量（Embedding），捕捉文本的语义信息；
- 向量存储：将向量存入专门的向量数据库（如 Pinecone、Milvus），建立索引以支持快速相似性检索。
2. 在线推理阶段（用户交互）
- 检索（Retrieve）：将用户查询转化为向量，在向量数据库中进行相似性搜索，筛选出与查询最相关的 Top N 文本块（通常为 5-10 个）；
- 增强（Augment）：将检索到的文本块、用户原始查询、系统指令整合，构建 “增强提示词”，例如 “基于以下文档内容，回答用户问题：[检索到的文本块 1]… [用户查询：XX]”；
- 生成（Generate）：将增强提示词输入 LLM，模型结合外部知识生成回答，并可引用检索来源（如 “根据 2024 年行业报告第 3 章内容，XX 领域增长主要源于…”）。
（三）RAG 的架构演进：从基础到智能体级
随着应用需求的复杂化，RAG 架构已从基础版本发展出多种进阶形态，适应不同场景需求：
| 架构类型 | 核心特点 | 适用场景 |
|---|---|---|
| 基础 RAG（Naive RAG） | 无额外处理步骤，直接执行 “检索 - 增强 - 生成” 流程 | 简单问答场景（如 FAQ 机器人、产品信息查询） |
| 高级 RAG（Advanced RAG） | 增加检索前处理（如查询改写、智能分块）与检索后处理（如重排序、上下文压缩） | 中等复杂度任务（如行业报告分析、学术文献总结） |
| 模块化 RAG（Modular RAG） | 将检索、记忆、路由等功能拆分为独立模块，支持灵活组合 | 复杂业务流程（如企业级客服、多数据源分析） |
| 自优化 RAG（Self-RAG） | 让 LLM 自主判断是否需要检索、检索什么内容，通过特殊 Token 触发检索 | 开放式任务（如创意写作、多主题调研） |
| 智能体 RAG（Agentic RAG） | 融入智能体循环，支持多步骤推理、多工具调用，动态调整检索策略 | 高复杂度任务（如自动数据分析、法律咨询） |
以 Agentic RAG 为例，在 “为企业制定市场拓展方案” 任务中，系统会先通过 RAG 检索目标市场的政策法规，再调用数据分析工具处理市场规模数据，最后结合检索到的竞品信息，生成完整方案 —— 这一过程中，RAG 不再是独立环节，而是智能体决策的重要支撑。
（四）向量数据库的选型：关键技术决策
向量数据库是 RAG 架构的 “存储核心”，其性能直接影响检索效率与准确性。企业在选型时需重点关注以下维度：
核心考量因素
- 部署模式：托管服务（如 Pinecone、Weaviate Cloud）适合快速上线，无需维护基础设施；开源方案（如 Milvus、Chroma）适合需要深度定制或数据本地化的场景；
- 扩展性：能否支持向量规模从百万级扩展到数十亿级，是否支持水平扩容（如 Milvus 的分布式架构）；
- 功能支持：是否支持混合搜索（向量搜索 + 关键词搜索）、元数据过滤（如按文档类型筛选）、多模态数据处理（如图片、音频向量）；
- 易用性：API 是否简洁、是否提供 SDK（如 Python/Java SDK）、文档是否完善，降低开发成本。
为了给技术选型提供一个实用的决策框架，下表对几个主流的向量数据库进行了比较。
主流 RAG 向量数据库对比分析
四、Context 工程化的核心概念和目标
1. 从原始数据到相关分块
本节聚焦于从知识库中识别和检索最有价值信息的初始阶段。
1.1、高级分块策略
文本分块（Chunking）是 RAG 流程中最关键也最容易被忽视的一步。其目标是创建在语义上自成一体的文本块。
- 朴素分块的问题：固定大小的分块方法虽然简单，但常常会粗暴地切断句子或段落，导致上下文支离破碎，语义不完整。
- 内容感知分块：
- 递归字符分割：一种更智能的方法，它会按照一个预设的分割符层次结构（如：先按段落，再按句子，最后按单词）进行分割，以尽可能保持文本的自然结构。
- 文档特定分块：利用文档自身的结构进行分割，例如，根据 Markdown 的标题、代码文件的函数或法律合同的条款来划分。
- 语言学分块：使用 NLTK、spaCy 等自然语言处理库，基于句子、名词短语或动词短语等语法边界进行分割。
- 语义分块： 这是最先进的方法之一。它使用嵌入模型来检测文本中语义的转变点。当文本的主题或意义发生变化时，就在该处进行分割，从而确保每个分块在主题上是高度内聚的。研究表明，这种策略的性能优于其他方法。
- 智能体分块：一个前沿概念，即利用一个 LLM 智能体来决定如何对文本进行分块，例如，通过将文本分解为一系列独立的 propositions 来实现。
1.2、通过重排序提升精度
为了平衡检索的速度和准确性，业界普遍采用两阶段检索流程。
两阶段流程：
-
第一阶段（召回）： 使用一个快速、高效的检索器（如基于 bi-encoder 的向量搜索或 BM25 等词法搜索）进行广泛撒网，召回一个较大的候选文档集（例如，前 100 个）。
-
第二阶段（精排/重排序）： 使用一个更强大但计算成本更高的模型，对这个较小的候选集进行重新评估，以识别出最相关的少数几个文档（例如，前 5 个）。
Cross-Encoder： 交叉编码器之所以在重排序阶段表现优越，是因为它与双编码器的工作方式不同。双编码器独立地为查询和文档生成嵌入向量，然后计算它们的相似度。而交叉编码器则是将查询和文档同时作为输入，让模型在内部通过 Attention Mechanism 对二者进行深度交互。这使得模型能够捕捉到更细微的语义关系，从而给出更准确的相关性评分。
实际影响： 重排序显著提高了最终送入 LLM 的上下文质量，从而产出更准确、幻觉更少的答案。在金融、法律等高风险领域，重排序被认为是必不可少而非可选的步骤。
2.核心问题 - Lost in the Middle
https://arxiv.org/abs/2307.03172 Lost in the Middle: How Language Models Use Long Contexts
当前 LLM 存在一个根本性认知局限，这一局限使得简单的上下文堆砌变得无效，并催生了后续的优化技术。
- 定义：LLM 在处理长上下文时表现出一种独特的 U 型 性能曲线。当关键信息位于上下文窗口的开头（首因效应）或结尾（近因效应）时，模型能够高效地利用这些信息。然而，当关键信息被 “hidden”在长篇上下文的中间位置时，模型的性能会显著下降。
- 实验： 在多文档问答任务时，即使检索器召回了更多相关的文档，模型的性能提升也很快达到饱和。这意味着简单地增加上下文长度（即添加更多文档）不仅无益，甚至因为关键信息被淹没而损害性能 。
- “知道但说不出来”： 并非模型“找不到”信息。通过探测模型的内部表征发现，模型通常能够准确地编码关键信息的位置，但在生成最终答案时却未能有效利用这些信息。这表明在模型内部，信息检索和信息利用（或沟通）之间存在脱节。
上下文丰富性与窗口局限性之间的考量
Context Engineering 的核心存在一个根本性的矛盾。一方面，提供丰富、全面的上下文是获得高质量响应的关键。另一方面，LLM 的上下文窗口是有限的，并且由于 Lost in the Middle、contextual distraction 等问题，过长的上下文反而会导致性能下降。
一个朴素的想法是尽可能多地将相关信息塞进上下文窗口。然而，研究和实践都证明这是适得其反的。LLM 会被无关信息淹没、分心，或者干脆忽略那些不在窗口两端的信息。
这就产生了一个核心的优化问题：如何在固定的 Token 预算内，最大化“信号”（真正相关的信息），同时最小化“噪声”（不相关或分散注意力的信息），并充分考虑到模型存在的认知偏差？
这个考量是 Context Engineering 领域创新的主要驱动力。所有的高级技术——无论是语义分块、重排序，还是后续将讨论的压缩、摘要和智能体隔离——都是为了有效管理这一权衡而设计的。因此，Context Engineering 不仅是关于提供上下文，更是关于如何策划和塑造上下文，使其对一个认知能力有限的处理单元（LLM）最为有效。
3.优化上下文窗口：压缩与摘要
本节详细介绍用于主动管理上下文的技术，确保最有价值的信息被优先呈现。
上下文压缩的目标
缩短检索到的文档列表和/或精简单个文档的内容，只将最相关的信息传递给LLM。这能有效降低API调用成本、减少延迟，并缓解 Lost in the Middle 的问题 。
压缩方法
- 过滤式压缩： 这类方法决定是保留还是丢弃整个检索到的文档。
- LLMChainFilter：利用一个 LLM 对每个文档的相关性做出简单的“是/否”判断。
- EmbeddingsFilter：更经济快速的方法，根据文档嵌入与查询嵌入的余弦相似度来过滤文档。
- 内容提取式压缩：这类方法会直接修改文档内容。
- LLMChainExtractor：遍历每个文档，并使用 LLM 从中提取仅与查询相关的句子或陈述 。
- 用 top N 代替压缩：像 LLMListwiseRerank 这样的技术，使用 LLM 对检索到的文档进行重排序，并只返回排名最高的 N 个，从而起到高质量过滤器的作用。
作为压缩策略的摘要
对于非常长的文档或冗长的对话历史，可以利用 LLM 生成摘要。这些摘要随后被注入上下文，既保留了关键信息，又大幅减少了 Token 数量。这是在长时程运行的智能体中管理上下文的关键技术。
4.智能体系统的上下文管理
从 HITL 到 SITL
Prompt Engineering 本质上是一个手动的、Human-in-the-Loop 的试错过程。而 Context Engineering，尤其是在其智能体形式中，则是关于构建一个自动化的 System-in-the-Loop，这个系统在LLM看到提示之前就为其准备好上下文。
一个人类提示工程师需要手动收集信息、组织语言并进行测试。而一个 Context Engineering 化的系统则将此过程自动化：RAG 流程本身就是一个自动收集信息的系统；路由器是一个自动决定收集哪些信息的系统；记忆模块是一个自动持久化和检索历史信息的系统。
正是这种自动化，使得 AI 系统能够变得“智能体化”（Agentic）——即能够在没有人类为每一步微观管理上下文的情况下，进行自主的、多步骤的推理 。因此，Context Engineering 的目标是构建一个可靠、可重复的上下文组装机器。这台机器取代了提示工程师的临时性、手工劳动，从而使创建真正自主和可扩展的 AI 智能体成为可能。焦点从单个提示的“技艺”转向了生成该提示的“系统工程”。
智能体上下文管理框架
LangChain 博客中提出的四个关键策略 ：
Write - 持久化上下文：
- Scratchpads：供智能体在执行复杂任务时使用的临时、会话内记忆，用于记录中间步骤。
- Memory：长期、持久化的存储，记录关键事实、用户偏好或对话摘要，可在不同会话间调用。
Select - 检索上下文：根据当前的子任务，使用 RAG 技术动态地从记忆、工具库或知识库中选择相关上下文。这甚至包括对工具描述本身应用 RAG，以避免向智能体提供过多无关的工具选项。
Compress - 优化上下文：利用摘要或修剪技术来管理智能体在长时程任务中不断增长的上下文，防止上下文窗口溢出和“ Lost in the Middle ”问题。
Isolate - 分割上下文：
- 多智能体系统： 将一个复杂问题分解，并将子任务分配给专门的子智能体，每个子智能体都拥有自己独立的、更聚焦的上下文窗口。
- 沙盒环境： 在一个隔离的环境中执行工具调用，只将必要的执行结果返回给 LLM，从而将包含大量 Token 的复杂对象隔离在主上下文窗口之外。
五、多智能体架构中的 Context 数据流与工作流编排
LLM 正在从被动地响应用户查询的“响应者”，演变为能够自主规划、决策并执行多步骤复杂任务的“执行者”——即我们所说的“智能体”（AI Agent）。
当一个智能体不再是简单地“输入-输出”，而是需要调用工具、访问数据库、与用户进行多轮交互时，其内部的数据是如何流动和管理的？如何进行技术选型？
1.工作流（Workflow） vs. 智能体（Agent）
在深入技术细节之前，建立一个清晰的概念框架至关重要。业界（如 Anthropic）倾向于对“智能体系统”进行两种架构上的区分。
工作流（Workflows）
指的是 LLM 和工具通过预定义的代码路径进行编排的系统。在这种模式下，数据流动的路径是固定的、由开发者明确设计的，类似于上世纪流行的“专家系统”。例如，“第一步：分析用户邮件；第二步：根据分析结果在日历中查找空闲时段；第三步：起草会议邀请邮件”。这种模式确定性高，易于调试和控制，非常适合有明确业务流程的场景（如风控需求高、数据敏感、安全等级要求）。
智能体（Agents）
指的是 LLM 动态地指导自己的流程和工具使用，自主控制如何完成任务的系统。在这种模式下，数据流动的路径不是预先固定的，而是由LLM在每一步根据当前情况和目标动态决定的。这种模式灵活性高，能处理开放式问题，但可控性和可预测性较低。
复杂的智能体通常是这两种模式的混合体，在宏观层面遵循一个预定义的工作流，但在某些节点内部，又赋予 LLM 一定的自主决策权。管理这一切的核心，我们称之为编排层（Orchestration Layer）。
2.多 Agent 编排的核心架构：预定义数据流的实现
为了实现可靠、可控的数据流动，开发者们已经探索出几种成熟的架构模式。这些模式可以单独使用，也可以组合成更复杂的系统。
链式工作流（Prompt Chaining）（GPT-3.5 时期的工作原理）
- 数据流： 输入 -> 模块 A -> 输出 A -> 模块 B -> 输出 B ->… -> 最终输出
- 工作原理： 每个模块（LLM 调用）只负责一个定义明确的子任务。
路由工作流（Routing）（o3 的早期工作原理）
- 数据流： 输入 -> 路由器选择 => -> 输出
- 工作原理： 一个充当“路由器”的 LLM 调用，其唯一任务就是决策。它会分析输入数据，然后输出一个指令，告诉编排系统接下来应该调用哪个具体的业务模块。
- 实现方式： LangGraph 使用 Conditional Edges 来实现这种逻辑，即一个节点的输出决定了图的下一跳走向何方。
编排器-工作者模式（Orchestrator-Workers）
- 对于极其复杂的任务，可以采用多智能体（Multi-agent）架构，也称为 Orchestrator-Workers 模式。一个中心 Orchestrator 智能体负责分解任务，并将子任务分配给多个专职的 Workers 智能体。
- 数据流：这是一个分层、协作的流动模式。 总任务 -> Orchestrator => -> 结果汇总 -> 最终输出
- 工作原理：每个工作者智能体都有自己独立的上下文和专用工具，专注于解决特定领域的问题。
3.决策与数据选择机制
在上述架构中，智能体（或其模块）如何决定“需要什么数据”以及“下一步做什么”？这依赖于其内部的规划和推理能力。
ReAct 框架
ReAct（Reasoning and Acting）是一个基础且强大的框架，它通过模拟人类的“Reasoning-Acting”模式，使LLM能够动态地决定数据需求。
其核心是一个循环：
-
思考（Thought）：LLM 首先进行内部推理。它分析当前任务和已有信息，判断是否缺少完成任务所需的知识，并制定下一步的行动计划。
例如：“用户问我今天旧金山的天气，但我不知道。我需要调用天气查询工具。”
-
行动（Action）： LLM 决定调用一个具体的工具，并生成调用该工具所需的参数。
例如：Action: search_weather(location=“San Francisco”)。
-
观察（Observation）：系统执行该行动（调用外部 API），并将返回的结果作为“观察”数据提供给LLM。
例如：Observation: “旧金山今天晴，22摄氏度。”
-
再次思考： LLM 接收到新的观察数据，再次进入思考环节，判断任务是否完成，或是否需要进一步的行动。
例如：“我已经获得了天气信息，现在可以回答用户的问题了。”
在这个循环中，数据流是根据 LLM 的“思考”结果动态生成的。当LLM判断需要外部数据时，它会主动触发一个“行动”来获取数据，然后将获取到的“观察”数据整合进自己的上下文中，用于下一步的决策。
Planning 和任务分解
对于更复杂的任务，智能体通常会先进行规划（Planning）。一个高阶的规划模块会将用户的宏大目标分解成一系列更小、更具体、可执行的子任务。
数据流向： 规划模块的输出是一份“计划清单”（Planning List），这份清单定义了后续一系列模块的调用顺序和数据依赖关系。
（前一阵子流行的 Claude Code，刚更新的 Cursor v1.2，以及上个版本流行的 Gemini/GPT DeepResearch 就属于这个架构）
例如，对于“帮我策划一次巴黎三人五日游”的请求，规划模块可能会生成如下计划，并定义了每个步骤所需的数据输入和输出：
- [获取用户预算和偏好] -> [搜索往返机票]
- [机票信息] -> [根据旅行日期和预算搜索酒店]
- [酒店信息] -> [规划每日行程]
- [机票、酒店、行程信息] -> [生成最终行程单和预算报告]
Reflection 机制
先进的智能体架构还包含反思（Reflection）机制 。智能体在执行完一个动作或完成一个子任务后，会评估其结果的质量和正确性。如果发现问题，它可以自我修正，重新规划路径。
（这是截止撰文时，各大主流 deep research 平台使用的核心技术方案） 数据流向： 这是一个反馈循环。模块的输出不仅流向下一个任务模块，还会流向一个“评估器”模块。评估器的输出（如“成功”、“失败”、“信息不足”）会反过来影响规划模块，从而调整后续的数据流向。
4.框架与工具
上述的架构和机制并非凭空存在，而是通过具体的开发框架实现的。其中，LangGraph 作为 LangChain 的扩展，为构建具有显式数据流的智能体系统提供了强大的工具集。
LangGraph：用图（Graph）定义工作流（Workflow）
LangGraph 的核心思想是将智能体应用构建成一个状态图（State Graph）。这个图由节点和边组成，清晰地定义了数据如何在不同模块间流动
- 状态（State）：这是整个图的核心，一个所有节点共享的中央数据对象。你可以把它想象成一个“数据总线”或共享内存。开发者需要预先定义 State 的结构，每个节点在执行时都可以读取和更新这个 State 对象 。
- 节点（Nodes）：代表工作流中的一个计算单元或一个步骤。每个节点通常是一个 Python 函数，它接收当前的 State 作为输入，执行特定任务（如调用 LLM、执行工具、处理数据），然后返回对 State 的更新。
- 边（Edges）：连接节点，定义了工作流的路径，即数据在 State 更新后应该流向哪个节点。
- 简单边（Simple Edges）：定义了固定的、无条件的流向，用于实现链式工作流。
- 条件边（Conditional Edges）： 用于实现路由逻辑。它会根据一个函数的输出来决定接下来应该走向哪个节点，从而实现流程的分支 。
- 检查点（Checkpointer）： LangGraph 提供了持久化机制，可以在每一步执行后自动保存 State 的状态。这对于构建需要长期记忆、可中断和恢复、或需要 Human-in-the-Loop 的复杂业务流程至关重要。
复杂业务流程的 AI 智能体，其核心挑战已从单纯优化信息检索（如 RAG）或提示词，转向了对内部工作流和数据流的精心设计与编排。
六、Context Engineering 的未来
- Graph RAG 的兴起：标准的基于向量的 RAG 在处理高度互联的数据时存在局限。而利用知识图谱的图 RAG 不仅能检索离散的信息块，还能检索它们之间的显式关系。这使得模型能够进行更复杂的多跳推理，并提供上下文更准确的回答 。
- 智能体自主性的增强：像 Self-RAG 和 Agentic RAG 这样更自主的系统将成为趋势，LLM 将承担更多管理自身上下文的责任。这将模糊 Context Engineering 系统与 LLM 本身之间的界限。
- 超越固定上下文窗口：针对 Lost in the Middle 问题的研究正在进行中，包括探索新的模型架构（如改进的位置编码）和训练技术。这些研究的突破可能会从根本上改变当今 Context Engineering 师所面临的约束。
- 终极目标：Context Engineering 本质上是一座桥梁，它是一套复杂的补偿机制，用以弥补 LLM “don’t read minds—they read tokens”的现实。人工智能研究的长期目标是创造出具有更强大内部世界模型的 AI，从而减少对此类庞大外部上下文支架的依赖。 Context Engineering 的演进，将是衡量我们朝此目标迈进的关键指标。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
为什么要学习大模型？
我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。
大模型入门到实战全套学习大礼包
1、大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
2、大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
3、AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
4、大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
5、大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
适用人群
第一阶段（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%免费】
北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台
更多推荐
13
0- 0
已为社区贡献31条内容
所有评论(0)