内蒙古自治区网站建设_网站建设公司_导航易用性_seo优化

AI 智能体的开发格局正在快速演变。我们早已跨越单轮对话机器人的原型阶段，如今各类组织都在部署复杂的自主智能体，以处理长周期任务：自动化工作流、开展深度调研、维护复杂代码库。

而这一目标的推进，很快就遇到了一个瓶颈：上下文。

随着智能体运行时长增加，其需要跟踪的信息量：聊天记录、工具输出、外部文档、中间推理过程等会呈爆炸式增长。目前主流的 “解决方案” 是依赖基础模型不断扩容的上下文窗口，但仅仅为智能体提供更大的文本容纳空间，绝非唯一的扩展策略。

要构建可靠、高效且可调试的生产级智能体，行业正探索一门全新的学科：上下文工程（Context Engineering） ，将上下文视为独立的一等系统，为其设计专属的架构、生命周期与约束条件。

基于谷歌在构建复杂单智能体及多智能体系统过程中积累的实践经验，我们在谷歌智能体开发工具包（ADK）中设计并优化了上下文栈，以此支撑这门学科的落地实践。ADK 是一款开源的、原生支持多智能体的框架，旨在让主动式上下文工程在实际业务系统中得以实现。

一、扩展瓶颈

更大的上下文窗口虽能缓解部分上下文相关问题，却无法彻底解决所有痛点。在实际应用中，“将所有内容一股脑塞进一个超大提示词” 这种简单粗暴的模式，会在三重压力下崩溃：

• 成本与延迟飙升：模型调用成本与首 token 输出时间，会随上下文长度快速增长。把原始历史记录和冗长的工具返回数据 “一股脑” 填入窗口，会让智能体的运行速度变得极慢，成本高到难以承受。

• 信号衰减（“中间信息丢失”）：如果上下文窗口充斥无关日志、过时工具输出或废弃状态数据，会干扰模型判断，使其执着于历史交互模式，而非当前指令。要保障决策的稳健性，就必须最大化上下文的相关信息密度。

• 物理上限约束：实际业务负载，包括检索增强生成（RAG）的完整结果、中间生成产物、长对话轨迹，最终会撑爆即便是最大的固定上下文窗口。

单纯增加 token 数量只是权宜之计，无法改变问题的本质。要实现系统的规模化扩展，我们需要改变上下文的表示与管理方式，而非仅仅追求单次调用能塞入更多内容。

二、设计核心理念：上下文即编译视图

上一代智能体框架将上下文视为可变字符串缓冲区，而 ADK 的设计基于截然不同的核心理念：上下文是对更丰富的有状态系统的编译视图（Compiled View）。

在这一理念下：

• 会话、记忆与工件（文件）是数据来源，包含交互过程及相关数据的完整结构化状态。
• 流程与处理器是编译流水线，通过一系列有序处理步骤完成对原始状态的转换。
• 工作上下文是本次模型调用的编译视图，即最终传入大语言模型（LLM）的内容。

一旦采用这一思维模型，上下文工程就不再是 “提示词技巧”，而是真正意义上的系统工程。开发者需要思考系统设计的标准问题：中间表示形式是什么？在哪些环节进行压缩？如何让转换过程可观测？

ADK 的架构通过三大设计原则回答了这些问题：

• 存储与表示分离：明确区分持久化状态（会话）与单次调用视图（工作上下文），支持存储模式与提示词格式的独立迭代优化。
• 显式转换机制：上下文通过命名且有序的处理器构建，而非临时的字符串拼接，让 “编译” 过程可观测、可测试。
• 默认上下文范围限制：每个模型调用与子智能体仅能获取完成任务所需的最小上下文，智能体必须通过工具显式请求更多信息，而非默认接收全部数据。

ADK 的分层结构、相关性筛选机制与多智能体上下文传递语义，本质上都是这一 “编译” 理念与三大原则的落地实践：

• 结构化设计：采用分层模型，分离信息的存储方式与模型的可见内容。
• 相关性管理：结合智能体自主决策与人工干预，判断当前任务所需的关键信息。
• 多智能体上下文：定义明确的语义规则，实现智能体间上下文切片的精准传递。

下文将逐一拆解这三大核心支柱。

三、结构化设计：分层模型

早期智能体系统大多默认采用单一上下文窗口，ADK 则反其道而行之。它通过存储与表示分离的设计，将上下文划分为多个功能明确的层级，每一层都承担专属职责：

• 工作上下文：本次模型调用的即时提示词，包含系统指令、智能体身份信息、精选历史记录、工具输出、可选记忆数据及工件引用。
• 会话：交互过程的持久化日志，所有用户消息、智能体回复、工具调用、工具返回结果、控制信号及错误信息，均以结构化事件对象的形式存储。
• 记忆：独立于单次会话的长期可检索知识库，包含用户偏好、历史对话等信息。
• 工件：与会话或用户关联的大型二进制 / 文本数据（文件、日志、图像），通过名称和版本进行索引，而非直接粘贴到提示词中。

3.1 工作上下文：按需重计算的视图

在每次模型调用时，ADK 都会基于底层状态重新构建工作上下文：从系统指令与智能体身份信息开始，提取会话中的关键事件，再按需附加记忆数据。这一视图具有三大特性：临时性（调用结束后即销毁）、可配置性（无需迁移存储即可调整格式）、模型无关性（适配不同大语言模型）。

这种灵活性正是 “编译视图” 理念带来的首个优势：开发者无需再硬编码 “固定提示词”，而是将其视为可迭代优化的派生表示。

3.2 流程与处理器：上下文处理流水线

实现存储与表示分离后，需要一套机制将前者 “编译” 为后者。在 ADK 中，每个基于大语言模型的智能体都由大语言模型流程（LLM Flow）提供支撑，该流程维护着有序的处理器列表。

一个简化的单流程（SingleFlow）示例如下：

这些流程是 ADK 编译上下文的核心机制，处理器的执行顺序至关重要：每个处理器都基于前序步骤的输出进行加工。这一设计为开发者提供了天然的扩展入口，可灵活插入自定义过滤规则、压缩策略、缓存机制与多智能体路由逻辑。开发者无需再反复修改臃肿的 “提示词模板”，只需新增或调整处理器的顺序即可。

3.3 会话与事件：结构化、跨语言的交互历史

ADK 中的会话（Session）代表一次对话或工作流实例的权威状态。具体而言，它承担三大角色：会话元数据容器（存储 ID、应用名称等）、结构化变量的临时存储区、以及最重要的：按时间排序的事件（Event）列表。

不同于存储原始提示词字符串的传统方式，ADK 将所有交互行为：用户消息、智能体回复、工具调用、调用结果、控制信号、错误信息等，都封装为强类型事件记录。这一结构化设计带来三大显著优势：

• 模型无关性：存储格式与提示词格式解耦，更换底层模型时无需重构历史数据。
• 丰富的可操作性：下游的压缩、回溯调试、记忆注入等组件，可直接基于结构化事件流处理，无需解析晦涩的文本内容。
• 可观测性：为数据分析提供天然载体，支持开发者精准洞察系统的状态转换与行为轨迹。

会话与工作上下文之间的桥梁是内容处理器（contents processor），它通过三个关键步骤，将会话数据转换为工作上下文中的历史记录部分：

• 筛选：过滤事件流中的无关事件、不完整事件及框架内部噪声，避免干扰模型决策。
• 转换：将筛选后的事件转换为内容对象（Content），为其分配正确的角色标签（用户 / 助手 / 工具），并根据目标模型接口要求添加注解。
• 注入：将格式化后的历史记录写入 llm_request.contents，确保下游处理器及模型能获取清晰、连贯的对话轨迹。

在这一架构中，会话是数据的 “真相来源”，而工作上下文只是一个可被持续优化的计算投影。

3.4 会话层的上下文压缩与过滤

如果无限制地追加原始事件，系统的延迟与 token 消耗终将失控。ADK 的上下文压缩（Context Compaction）功能在会话层直接解决这一问题。

当达到可配置的阈值（如模型调用次数）时，ADK 会触发异步压缩流程：利用大语言模型，对滑动窗口内的历史事件进行摘要（窗口参数包括压缩周期与重叠长度），并将生成的摘要作为一条新的 “压缩” 类型事件写入会话。关键在于，系统可基于摘要对原始事件进行裁剪或降级处理。

由于压缩操作直接作用于事件流，其优势会传导至下游所有环节：

• 可扩展性：即便是超长会话，也能保持物理存储的可控性。
• 简洁的视图：内容处理器直接基于已压缩的历史数据构建上下文，无需在查询阶段执行复杂逻辑。
• 解耦性：调整压缩提示词与策略时，无需修改任何智能体代码或模板逻辑。

这为长上下文管理构建了可扩展的生命周期。对于纯规则驱动的精简需求，ADK 还提供了过滤（Filtering）功能：通过预置插件，在数据进入模型前，基于确定性规则全局裁剪上下文内容。

3.5 上下文缓存

现代大模型普遍支持上下文缓存（前缀缓存）技术，允许推理引擎在多次调用间复用注意力计算结果。ADK 的 “会话 - 工作上下文” 分离架构，为这一优化提供了天然的技术基座。

该架构将上下文窗口划分为两个区域：

• 稳定前缀区：包含系统指令、智能体身份信息、长期摘要等不常变化的内容。
• 可变后缀区：包含最新用户输入、新工具输出、小增量更新等动态内容。

由于 ADK 的流程与处理器具备显式性，开发者可将缓存友好性作为硬性设计约束：通过调整流水线顺序，将高频复用的内容稳定置于上下文窗口前端，同时将高动态内容后置。为强化这一约束，我们引入了静态指令（static instruction）原语，确保系统提示词的不可变性，从而保障缓存前缀在多次调用中始终有效。

这正是上下文工程贯穿全栈系统设计的典型案例：开发者不仅决定模型 “看到什么”，还能优化硬件层的张量运算复用效率。

四、相关性管理：智能驱动的关键信息筛选

完成结构化设计后，核心挑战转向相关性管理：基于分层上下文架构，如何确定当前模型调用窗口中应包含哪些关键信息？

ADK 的解决方案是结合人类领域知识与智能体自主决策。单纯依赖硬编码规则，成本虽低但灵活性不足；完全交由智能体自主检索所有数据，虽灵活但成本高昂且稳定性差。

理想的工作上下文，是二者权衡的结果：人类工程师定义架构（数据存储位置、摘要方式、过滤规则），智能体则提供决策智能，动态判断何时需要调取特定记忆片段或工件，以响应当前用户请求。

4.1 工件管理：外置存储大体积状态数据

早期智能体实现常陷入 “上下文堆砌” 的误区：将 5MB 大小的 CSV 文件、庞大的 JSON 接口响应、完整的 PDF 文本直接粘贴到聊天记录中。这会给会话带来永久性负担，后续每轮调用都需携带这些冗余数据，既掩盖关键指令，又推高成本。

ADK 通过工件（Artifacts）机制解决该问题：将大体积数据定义为命名、带版本的二进制或文本对象，由工件服务（ArtifactService）统一管理。

从设计理念上，ADK 对大体积数据采用句柄模式：数据存储于工件仓库，而非提示词中。默认情况下，智能体通过请求处理器仅能获取轻量化的引用信息（名称 + 摘要）。只有当智能体需要原始数据才能回答用户问题时，才会调用加载工件工具（LoadArtifactsTool），将数据临时加载到工作上下文中。

关键特性是临时扩展：模型调用或任务完成后，工件会默认从工作上下文中卸载。这一设计将 “每轮提示词中 5MB 的冗余数据”，转变为可按需精准调用的资源。即便数据体积庞大，上下文窗口仍能保持精简。

4.2 记忆管理：按需检索的长期知识库

如果说工件机制用于处理离散的大体积对象，ADK 的记忆（Memory）层则用于管理跨越单次会话的长期语义知识，如用户偏好、历史决策、领域事实等。

我们围绕两大原则设计记忆服务（MemoryService）：记忆数据必须支持检索（而非永久固定在上下文中），且检索行为由智能体自主驱动。

记忆服务会将数据（通常来自已结束的会话）注入向量数据库或关键词语料库。智能体通过两种模式访问该知识库：

• 被动召回：智能体识别到知识缺口（如 “用户的饮食禁忌是什么？”），主动调用加载记忆工具（load_memory_tool）检索语料库。
• 主动召回：系统通过前置处理器，基于最新用户输入执行相似度检索，在模型调用前，通过预加载记忆工具（preload_memory_tool）将高相关片段注入上下文。

这一方案用 “记忆驱动” 的工作流，取代了 “上下文堆砌” 的反模式。智能体只需调取当前任务所需的精准片段，无需承载所有历史对话的冗余信息。

五、多智能体上下文：精准管控信息可见范围

单智能体系统已面临上下文膨胀问题，多智能体系统会进一步放大这一挑战。如果主智能体将完整历史传递给子智能体，而子智能体又重复此操作，会引发上下文爆炸：token 数量急剧攀升，子智能体也会被无关对话历史干扰。

在 ADK 中，当一个智能体调用另一个智能体时，开发者可显式定义被调用方的上下文范围，例如仅传递最新用户查询和一个工件，同时屏蔽大部分上游历史。

5.1 两种多智能体交互模式

从架构层面，ADK 将多智能体交互归纳为两种核心模式：

• 工具化智能体（Agents as Tools）：主智能体将专业子智能体视为函数调用，传入聚焦的提示词，获取结果后继续执行流程。被调用的子智能体仅能看到特定指令和必要工件，无任何历史对话信息。
• 智能体移交（Agent Transfer，分层模式）：控制权完全移交子智能体，由其继续推进对话。子智能体可继承会话视图，自主调用工具或进一步移交控制权。

5.2 智能体移交的范围化上下文传递

移交行为的控制，依赖 include_contents 等配置项，这些参数决定主智能体向下传递的上下文范围。默认模式下，ADK 会传递主智能体工作上下文的完整内容，适用于子智能体需要全量历史的场景。在 none 模式下，子智能体无法查看任何历史数据，仅接收开发者为其构建的新提示词（如最新用户输入 + 少量工具调用记录）。专业子智能体由此获得完成任务所需的最小上下文，而非默认继承冗长的对话全文。

由于子智能体的上下文同样由处理器构建，这些传递规则可无缝接入单智能体调用的同一流程流水线。开发者无需为多智能体交互单独构建一套机制，只需调整现有上下文编译器对上游状态的访问权限即可。

5.3 智能体移交的对话转译

大语言模型基于固定角色模式运行：系统、用户、助手。它们无法原生区分 “助手 A” 与 “助手 B” 的身份。

当 ADK 执行控制权移交时，必须对现有对话历史进行主动转译，确保新智能体能获取连贯的工作上下文。如果新智能体直接看到上游智能体的 “助手” 消息，会错误地认为这些是自身的历史行为。

为避免此类问题，ADK 在移交过程中执行以下转译操作：

• 叙事重构：将上游 “助手” 消息重构为叙事性上下文（例如修改角色标签，或添加[背景信息]：智能体B曾表示……等注解），而非作为新智能体的历史输出。
• 行为归因：对其他智能体发起的工具调用进行标记或摘要，确保新智能体能基于调用结果执行操作，同时不会混淆自身与其他智能体的能力边界。

实际上，ADK 会从子智能体的视角重新构建工作上下文，同时在会话中完整保留事实性历史记录。这一设计保障了系统行为的正确性，让每个智能体都能安心承担 “助手” 角色，而不会将整个系统的历史行为归因于自身。

六、 结语

随着我们推动智能体承担更长周期的任务，“上下文管理” 的内涵已不再是简单的 “字符串拼接”，而必须与存储、计算并列，视为核心的架构设计问题。

ADK 的上下文架构，分层存储、编译视图、流水线处理与严格的范围管控，正是我们应对这一挑战的解决方案。它凝聚了将智能体从概念原型推向可扩展、高可靠生产系统所需的严谨系统工程思想。

七、如何学习AI大模型？

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

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

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

第一阶段：从大模型系统设计入手，讲解大模型的主要方法；

第二阶段：在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段：大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段：大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段：大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段：以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段：以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

👉学会后的收获：👈

• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓