Google 上下文工程手册以及上下文感知多智能体框架
Agent 从聊天机器人变成能自主干活的系统之后，最大瓶颈变成了「它记不清上下文」。Google 的解法是把上下文当可编译系统来管。
- 先讲上下文扩展的三重困境：记不住、分不清、装不下。
- 核心理念是把上下文视为可编译系统，而不是一段越堆越长的文本。
- ADK 的四层架构像一个上下文操作系统，各层职责分明。
- 上下文处理流水线像编译过程一样生成最终提示词。
- 这套思路是 Agent 工程的基础设施层，换框架也搬得走。
随着 AI 代理（Agent）从简单的聊天机器人演进为多轮、自主执行任务的系统（如代码维护、研究、工作流自动化），最大瓶颈变成了 上下文管理（Context Management）。
任务变得更长、更复杂，一个巨大的问题出现了：
Agent记不清楚上下文了
也就是：
- 它需要记住之前做过什么；
- 它要知道当前环境、任务目标、用过哪些工具；
- 它要能从过去的对话、文件、数据中“找回”正确的信息。
过去的解决方案很粗暴：
“那就给模型一个更大的上下文窗口吧！”
比如GPT-4有128K的上下文，Gemini 有1M的上下文。
但是Google指出： 💥 光靠加大窗口，根本不是根本的解决办法。
上下文扩展的三重困境
单纯依赖“更大的上下文窗口”会导致三类系统性问题：
- 成本与延迟增长（Cost & Latency Spiral）
上下文长度与模型调用的时间、计算成本呈线性甚至超线性增长。随着对话、工具结果、日志文件等被不断拼接，模型响应速度和运行成本迅速上升。
- 信号退化（Signal Degradation / Lost in the Middle）
当上下文被过量的无关或过时信息占据时，模型的关注焦点分散，重要指令可能被掩盖，决策质量下降。
- 物理极限（Physical Limits）
现实任务往往涉及检索增强生成（RAG）结果、长期日志与多模态数据，这些内容在任何有限窗口内都无法完全容纳。
因此，Google提出：AI系统的可扩展性不应依赖“扩窗”，而应依赖“上下文架构设计”。 这催生了一个新的工程学科——Context Engineering（上下文工程）。
Google的解决方案：Context Engineering（上下文工程）
他们提出了一个新的概念：
上下文不是一堆文字，而是一个系统。
核心理念：将上下文视为可编译系统
Google的核心论点是：
“上下文应被视为一种有架构的、可编译的系统状态（compiled view over a structured system）。”
即：
- 上下文不再是被动堆叠的字符串；
- 它是从底层结构化状态（包括会话、记忆、文件等）经过管线化转换生成的“工作视图”（working context）；
- 这一过程可配置、可调试、可扩展。
该理念由Google的Agent Development Kit (ADK) 实现。 ADK 是一个多智能体原生（multi-agent-native）框架，用于在生产环境中实现主动上下文工程。
所以，Google为此专门设计了一个框架：
🧩 ADK：Agent Development Kit
这是一个开源的多智能体框架，用来帮助工程师：
- 高效管理上下文；
- 让智能体可以长时间运行；
- 控制、压缩、重建上下文；
- 实现多个Agent之间的上下文协作。
ADK的核心思想：上下文像“编译器”一样工作
Google用一个非常形象的比喻：
“上下文就像代码，Prompt只是它编译后的结果。”
也就是说：
- 你不再手动拼字符串当提示词；
- 你用“编译流程（Flows + Processors）”自动生成上下文；
- 每次调用模型时，系统都会“重建”最合适的上下文视图（Working Context）。
架构核心：ADK 的三大支柱
ADK 的上下文架构遵循三项设计原则：
- 存储与呈现分离（Separation of Storage and Presentation）
- 将“持久状态”（Session）与“即时上下文”（Working Context）区分；
- 允许独立演进数据结构与Prompt格式。
- 显式转换（Explicit Transformations）
- 上下文的生成通过定义好的“处理器（processors）”序列实现；
- 不再依赖手工拼接Prompt，从而可观察、可测试。
- 作用域最小化（Scope by Default）
- 模型调用与子Agent仅能访问所需最小上下文；
- 额外信息需通过显式工具调用加载。
这三项原则体现为ADK的三层技术结构：结构（Structure）、相关性（Relevance）、多智能体上下文（Multi-Agent Context）。
ADK的四层架构（像一个“上下文操作系统”）
Google 把整个上下文分成四个层次，每一层有不同的职责：
🌱 1. Working Context（工作上下文）
每次调用模型时，ADK会从Session、Memory、Artifacts里重新组装出一个小上下文窗口，只放“这次必要的信息”。
好处：
- 不用每次都塞全部历史；
- 更快、更便宜；
- 容易调试和修改。
⚙️ 2. Session（会话日志）
ADK不是简单地保存Prompt，而是保存结构化事件：
- 用户消息；
- Agent输出；
- 工具调用；
- 错误信息；
- 以及状态变化。
👉 这样做的好处是：
- 可分析（可以回放、调试）；
- 可压缩（用LLM总结旧历史）；
- 可替换模型（换模型也不会影响数据）。
🧩 3. Memory（长期记忆）
存放长期的、有用的知识，例如：
- 用户的偏好；
- 历史任务；
- 常用背景知识。
💡 有两种“召回”方式：
- Reactive Recall：Agent意识到需要某个信息时主动去查；
- Proactive Recall：系统自动提前加载相关记忆。
所以Agent的“记忆”像人类一样，有主动与被动之分。
🧱 4. Artifacts（外部数据）
存放大文件，如PDF、日志、图片、API返回结果等。
以前人们会直接把文件贴进Prompt里（成本高又乱）。 ADK改为：
- 只放引用（文件名、版本、摘要）；
- 真正需要时才加载；
- 用完自动卸载。
这让Agent的上下文保持“轻量级”运行。
ADK的上下文处理流水线：像“编译”一样生成Prompt
在ADK中，每个Agent都有一个“Flow”，包含多个“Processors”。
self.request_processors += [
basic.request_processor,
auth_preprocessor.request_processor,
instructions.request_processor,
identity.request_processor,
contents.request_processor,
planning.request_processor,
code_execution.request_processor,
output_schema_processor.request_processor,
]每个processor处理一部分上下文（类似编译器的一道“工序”）：
- 加载基本信息；
- 插入系统提示；
- 整理历史内容；
- 插入最新工具结果；
- 输出最终Prompt。
这样，Prompt的生成过程透明、可调试、可插拔。
上下文压缩与缓存机制（让Agent更快更省）
🧭 1. Context Compaction（上下文压缩）
ADK会定期用LLM自动总结旧历史，并把摘要替换原始日志。
好处：
- 长期会话也能保持轻量；
- 节省Token；
- 无需手动剪历史。
⚡ 2. Context Caching（上下文缓存）
ADK自动识别哪些部分是长期不变的（如系统提示、身份），并缓存这些内容。
下次调用时：
- 模型不需要重新计算前缀；
- 响应更快；
- 成本更低。
多智能体（Multi-Agent）上下文协作
当多个Agent合作执行任务（如一个规划Agent调用执行Agent）时，会出现上下文混乱问题。
ADK的解决方案：
- 主Agent只传递必要上下文给子Agent；
- 子Agent有自己独立的工作上下文；
- 历史信息可“翻译”（Narrative Casting），避免角色混淆。
两种模式：
- Agents as Tools：子Agent像工具函数一样使用；
- Agent Transfer：子Agent接管整个任务流程。
总体评价
- 创新性：将“上下文”从字符串转化为系统概念，提出“编译式上下文”范式。
- 工程可行性：以模块化处理管线为基础，具备可测试、可插拔的特性。
- 扩展潜力：为多Agent系统提供作用域与身份隔离机制，支持长期复杂任务。
- 系统定位：ADK代表从Prompt Engineering → Context Engineering → System Engineering的演化方向。
它不是让你写更好的提示词， 而是让你搭建一个上下文架构：
- 什么存；
- 存在哪；
- 什么时候取；
- 谁能看；
- 怎样总结。
架构高效的上下文感知多智能体生产框架
作者：林航飞（Hangfei Lin） 发布日期：2025年12月4日 来源：Google Developers Blog
人工智能代理（AI Agent）的开发格局正在迅速变化。 我们已经超越了只会进行单回合对话的原型阶段。 如今，各类组织正在部署更为复杂且具备自主能力的智能体，以处理长周期任务，例如自动化工作流程、执行深度研究，以及维护复杂的代码库。
然而，这种更高层次的雄心立即遇到了一个关键瓶颈：上下文（Context）。
当智能体运行时间拉长，它所需追踪的信息量（对话历史、工具输出、外部文档、中间推理过程）会呈指数级增长。 目前业内的普遍“解决方案”是依赖越来越大的基础模型上下文窗口（context window）。 但仅仅给予智能体更大的“文本拼贴空间”，并不能成为长期可扩展的解决策略。
为了构建真正面向生产环境的、可靠且高效的智能体系统，业界开始探索一个新的系统工程方向—— 这就是 上下文工程（Context Engineering）： 把上下文视为一个具有自身架构、生命周期与约束条件的一等系统实体（first-class system）。
基于我们在构建和扩展复杂单智能体与多智能体系统的经验，我们设计并演进了 Google Agent Development Kit（简称 ADK） 中的上下文栈（context stack），以支持这一理念。 ADK 是一个开源的、原生面向多智能体的框架，旨在让“主动的上下文工程”成为现实可行的生产系统能力。
扩展瓶颈（The Scaling Bottleneck）
增大上下文窗口虽然能暂时缓解与上下文相关的问题，但并不能从根本上解决它。 在实践中，那种“把所有内容都附加到一个巨大提示中”的简单模式，在三方面压力下迅速崩溃：
- 成本与延迟的螺旋上升（Cost and Latency Spirals）：
模型的调用成本与首 token 延迟会随上下文体积迅速增加。 若将全部历史与冗长的工具输出直接“铲入”窗口，会使智能体的运行成本与响应时间变得不可接受。
- 信号退化（Signal Degradation / “Lost in the Middle”）：
被无关日志、过时工具输出或废弃状态充斥的上下文窗口，会干扰模型的注意力分配，使其沉迷于旧模式而忽略当前指令。 为了确保稳健的决策能力，我们必须最大化上下文中“相关信息的密度”。
- 物理限制（Physical Limits）：
在真实生产负载中，系统往往涉及完整的RAG检索结果、中间工件（artifacts）以及长会话记录，最终会超出任何固定大小的上下文窗口。
仅靠增加Token数量只能延缓问题，而不能改变增长曲线的形态。 要真正实现可扩展性，必须改变“上下文的表示与管理方式”，而非仅仅改变能塞入的内容量。
设计论点：上下文即编译视图（Context as a Compiled View）
在早期一代的智能体框架中，上下文通常被视为可变字符串缓存（mutable string buffer）。 而ADK基于不同的假设—— 上下文是一种“编译视图”（compiled view），它是对更丰富的、有状态系统（stateful system）的投影。
在这一视角下：
- Sessions、Memory、Artifacts（文件或资源） 是“源代码”——即交互和数据的完整结构化状态；
- Flows 与 Processors 是“编译管线”——将这些状态进行有序转换的过程；
- Working Context（工作上下文） 则是编译后的“结果视图”，用于当前一次模型调用。
一旦采用这种思维方式，上下文工程不再是提示词技巧，而是系统工程问题。 开发者需要开始思考标准的系统问题：
- 中间表示（Intermediate Representation）是什么？
- 压缩与抽取应在何处进行？
- 转换过程如何可观测与可测试？
ADK 的三项设计原则
ADK 的架构通过三项核心原则回答了上述问题：
- 分离存储与呈现（Separate Storage from Presentation）
将持久状态（Session）与单次调用的视图（Working Context）区分，从而允许存储结构与提示格式独立演进。
- 显式转换（Explicit Transformations）
上下文的构建通过有序且命名的处理器（processors）完成，而非临时拼接文本； 这样，“编译步骤”即可被观测与测试。
- 默认作用域约束（Scope by Default）
每一次模型调用与子智能体仅能看到最小必要上下文。 若需访问更多信息，必须通过工具显式请求，而非被动加载。
ADK 的分层结构、相关性机制以及多智能体间的上下文传递语义，均是上述“编译式”设计论点及三原则的直接体现。
1. 结构（Structure）：分层模型
早期的大多数智能体系统通常隐式地假设上下文是一个单一窗口。 ADK 采取了完全相反的方向：它明确区分存储与呈现，并将上下文组织为多个层次，每一层都有特定职能。
这些层次包括：
- 工作上下文（Working Context） ——
当前模型调用所使用的即时上下文，包括系统指令、智能体身份、选定的历史、工具输出、可选的记忆结果以及对外部工件（artifacts）的引用。
- 会话（Session） ——
整个交互的持久日志：记录每一条用户消息、智能体回复、工具调用、工具结果、控制信号以及错误。 所有这些内容都以结构化的事件对象（Event objects）形式存储。
- 记忆（Memory） ——
持久、可搜索的知识集合，超越单次会话而存在。 其中包括用户偏好、历史对话、语义性事实等。
- 工件（Artifacts） ——
与会话或用户相关的大型二进制或文本数据（如文件、日志、图像），通过名称与版本引用，而非直接嵌入到提示中。
1.1 工作上下文作为可重构视图（Working Context as a Recomputation View）
对于每一次模型调用，ADK 都会从底层状态重新构建工作上下文。 该过程通常包括以下步骤：
- 从系统指令和智能体身份开始；
- 拉取选定的会话事件；
- 可选地附加记忆检索结果；
- 将它们组合成一个结构化的即时上下文视图。
该工作上下文具有以下特性：
- 临时性：每次调用后即丢弃；
- 可配置性：可以在不迁移底层数据的前提下修改格式；
- 模型无关性：与具体的语言模型接口解耦。
这种灵活性是“编译式上下文”理念的第一个直接收益。 开发者不再需要硬编码提示，而是将其视为从系统状态派生的可变表示。
1.2 流与处理器：上下文处理的流水线（Flows and Processors: Context as a Pipeline）
在存储与呈现分离后，系统需要一套机制来将前者“编译”为后者。 在 ADK 中，每个基于大型语言模型（LLM）的智能体由一个 LLM 流（Flow） 支撑，该流维护一个有序的处理器列表。
一个简化的单智能体流程（SingleFlow）示例如下：
self.request_processors += [
basic.request_processor,
auth_preprocessor.request_processor,
request_confirmation.request_processor,
instructions.request_processor,
identity.request_processor,
contents.request_processor,
context_cache_processor.request_processor,
planning.request_processor,
code_execution.request_processor,
output_schema_processor.request_processor,
]
self.response_processors += [
planning.response_processor,
code_execution.response_processor,
]
这些流（Flows）是 ADK 编译上下文的核心机制。 每个处理器依次运行，后续步骤基于前一步的输出。 这使得开发者可以在自然的插入点实现自定义过滤、压缩策略、缓存机制或多智能体路由。
开发者不再需要重写庞大的“提示模板”，而只需调整或添加处理器即可。
1.3 会话与事件：结构化、与语言无关的历史记录
ADK 的 会话（Session） 表示一次对话或工作流实例的完整状态。 具体而言，它既是：
- 存放元数据（如会话ID、应用名称）的容器；
- 用于存储结构化变量的状态暂存区；
- 也是最重要的部分：按时间顺序组织的事件列表（Events）。
每一个交互——无论是用户输入、智能体输出、工具调用、结果返回、控制信号还是错误——都被捕获为强类型的事件记录（Event Record），而非简单文本。
这一结构性设计带来三项优势：
- 模型无关性（Model Agnosticism）：
由于历史数据与具体的提示格式解耦，可以在不重写历史的情况下更换底层模型。
- 可操作性（Rich Operations）：
下游组件（如压缩、调试、记忆注入）可以直接在事件流上操作，而无需解析文本。
- 可观测性（Observability）：
可以直接审查精确的状态转移与行为路径，用于分析与调试。
会话与工作上下文之间由 contents processor 连接。 它将事件流转化为上下文中的“历史部分”，过程包括：
- 选择（Selection）：过滤掉不相关、部分完成或框架噪声事件；
- 转换（Transformation）：将剩余事件扁平化为内容对象（Content objects），并按模型API要求标注角色（如 user / assistant / tool）；
- 注入（Injection）：将格式化后的历史写入 llm_request.contents，确保后续处理器和模型收到干净、一致的会话轨迹。
在此架构下，Session 是真实的源状态（ground truth），而工作上下文只是可以持续优化的“计算投影”。
1.4 会话层的上下文压缩与过滤（Context Compaction and Filtering）
如果持续附加原始事件，延迟与Token开销将不可避免地膨胀。 ADK 在会话层提供 上下文压缩（Context Compaction） 功能，以应对这一问题。
当可配置阈值（如调用次数）达到上限时，ADK 触发异步进程，使用 LLM 对旧事件执行摘要。 该过程在滑动窗口中运行（由压缩间隔与重叠大小定义），并将生成的摘要写回 Session，标记为动作类型“compaction”。 被摘要的原始事件可被修剪或降权。
由于压缩直接作用于事件流，其益处体现在多个层面：
- 可扩展性：会话规模保持可控；
- 干净视图：内容处理器在读取时自动使用压缩后的历史；
- 解耦性：可以独立调整压缩策略与提示，而无需修改智能体代码。
ADK 同时支持一个相邻机制——过滤（Filtering），用于基于确定性规则（如事件类型或时间）全局删除或裁剪上下文，在其进入模型前进行。
这两种机制构成了可扩展的上下文生命周期管理体系。
1.5 上下文缓存（Context Caching）
现代语言模型支持上下文缓存（又称前缀缓存，prefix caching），即在多次调用间复用注意力计算。 ADK 将 Session（存储）与 Working Context（视图）分离，为这一机制提供了自然的实现基础。
架构上，ADK 将上下文窗口划分为两个区域：
- 稳定前缀（Stable Prefixes）：系统指令、智能体身份、长期摘要等；
- 可变后缀（Variable Suffixes）：最新用户输入、新工具输出、增量更新。
由于 ADK 的流与处理器是显式定义的，开发者可将“缓存友好性”作为设计约束。 可以通过调整处理器顺序，确保可复用段保持在窗口前端，而将高动态内容推向尾部。
为了强化这一特性，ADK 引入 static instruction（静态指令） 原语，确保系统提示不可变，从而维持前缀缓存的有效性。
该机制体现了上下文工程的系统化思维： 它不仅优化模型输入内容，还在硬件层面降低重复张量计算的频率。
2. 相关性（Relevance）：由智能体管理当前“重要信息”
在完成结构层设计后，核心挑战转向“相关性”： 即在分层的上下文架构中，当前模型调用时，哪些信息应当出现在智能体的有效上下文窗口内？
ADK 的解决方案，是在人类领域知识与智能体的动态决策之间建立协作机制。
单纯依赖硬编码规则虽然成本低，但灵活性有限； 单纯依赖智能体自主检索所有信息虽然灵活，但代价高昂且容易失稳。
因此，一个最优的 工作上下文（Working Context） 应当是人类设计与智能体主动行为之间的协商结果。
人类工程师定义整体结构——数据存放位置、摘要策略与过滤逻辑； 智能体则在运行中动态判断——何时检索记忆、何时加载外部数据。
2.1 工件（Artifacts）：外部化大型状态
早期的智能体实现中普遍存在一个问题： “上下文倾倒”（context dumping）。 即系统将大型负载（如 5MB 的 CSV 文件、庞大的 JSON API 响应、或完整的 PDF 转录文本）直接放入对话历史中。
这种做法的结果是：
- 每次调用都被迫携带庞大负载；
- 每次推理成本剧增；
- 有效指令被大量冗余数据掩盖。
ADK 的解决方式是将这些大型数据对象视为 工件（Artifacts）。 工件是带名称与版本控制的二进制或文本对象，由 ArtifactService 负责管理。
概念上，ADK 对大数据采用了 句柄模式（handle pattern）：
- 数据本体存储在工件库中；
- 工作上下文中仅保存轻量引用（如名称、摘要、版本号）；
- 当且仅当智能体确实需要完整数据时，调用 LoadArtifactsTool 加载内容；
- 模型调用完成后，默认自动将该工件从工作上下文卸载。
这种机制的核心在于临时扩展（ephemeral expansion）： 数据可在推理期间短暂加载使用，但不会长期驻留。
其效果是：
- 将“每次携带5MB噪声”的固定负担，转化为“精确、按需调用的资源”；
- 即使面对超大数据，系统上下文仍保持精简、高效。
2.2 记忆（Memory）：按需检索的长期知识
如果说“工件”处理的是离散的大型外部对象，那么 记忆（Memory） 则负责管理长期的语义知识。 这包括用户偏好、历史决策、上下文事实等。
Google 在 ADK 中重新设计了 Memory 服务（MemoryService），遵循两项原则：
- 记忆必须可搜索（searchable），而非永久附着在上下文中；
- 记忆检索应由智能体驱动（agent-directed），而非自动加载全部内容。
MemoryService 将数据（通常来自已完成的会话）存入一个向量索引或关键字索引语料库中。 智能体可通过两种模式访问记忆：
（1）被动召回（Reactive Recall）
当智能体检测到知识缺口（例如：“用户的饮食限制是什么？”）时，它会显式调用 load_memory_tool 进行检索。 检索结果在该调用的上下文中注入。
（2）主动召回（Proactive Recall）
系统可配置预处理器（pre-processor），在用户输入到达模型之前自动执行相似性检索。 检索到的高相关片段通过 preload_memory_tool 注入至工作上下文。
这种设计从根本上取代了“上下文堆积”（context stuffing）的反模式。 智能体仅在当前步骤中检索所需片段，而非持续携带全部历史记忆。
3. 多智能体上下文（Multi-Agent Context）：定义谁能看什么、何时能看
单智能体系统已经存在上下文膨胀问题，而多智能体系统会使该问题呈指数放大。
如果一个主智能体（root agent）将完整历史传递给其子智能体（sub-agent），而子智能体又将自己的历史继续传递下去， 上下文大小将迅速失控，Token 消耗急剧上升，同时子智能体也会因接收无关历史而混乱。
ADK 通过精确的作用域控制机制来解决这一问题： 在智能体之间调用时，开发者可以明确指定被调用智能体（callee）可见的上下文范围。 例如，主智能体可以仅向子智能体传递最新的用户查询及一个工件引用，而不共享全部会话记录。
3.1 两种多智能体交互模式
在总体架构层面，ADK 将多智能体交互抽象为两种基本模式：
（1）代理即工具（Agents as Tools）
在此模式中，根智能体将某个专用智能体视为一个函数或外部服务调用： 调用它 → 获得结果 → 返回上层流程。
被调用的子智能体仅能看到特定指令与必要的工件引用，不继承任何历史。 这种模式适用于封闭型、任务明确的子Agent。
（2）代理转移（Agent Transfer / Hierarchy）
在该模式中，控制权被完全交给子智能体。 子智能体继承会话的部分视图，并可自主继续交互、调用工具或进一步转移控制。 这形成了一个层级化的Agent体系（hierarchical agent architecture）。
3.2 作用域化的上下文传递（Scoped Handoffs for Agent Transfer）
在智能体转移时，ADK 提供可配置的参数控制，例如 include_contents，以决定从调用者传递多少上下文给被调用者。
- 在 默认模式（default mode） 下，系统会传递调用者完整的工作上下文内容；
这在子智能体确实需要了解完整上下文时非常有用。
- 在 none 模式 下，被调用智能体不会接收任何历史，只获得新Prompt（例如最新用户输入和若干工具调用及响应）。
借助这种精确控制，系统能够确保专用子智能体仅接收其任务所需的最小上下文，而不会继承庞大冗余的对话记录。
由于每个智能体的上下文同样通过处理器流水线生成，这些上下文传递规则也能自然嵌入既有流程中。 无需独立的多智能体引擎，只需在上下文编译阶段定义传递范围即可。
3.3 智能体间对话的上下文翻译（Translating Conversations for Agent Transfer）
基础模型通常使用固定角色架构（system、user、assistant）， 并不原生区分不同的“Assistant”身份（例如 Agent A 与 Agent B）。
因此，当 ADK 在智能体之间进行控制权转移时， 必须重构对话，使新智能体看到的上下文连贯且语义正确。
若不做处理，新智能体会将之前的“Assistant”回复误认为是自身的行为，从而导致语义错乱。
为避免这种混淆，ADK 在上下文转移时执行主动翻译过程，包括：
（1）叙事重构（Narrative Casting）
将先前智能体的“Assistant”消息重新表述为叙事性上下文，而非当前智能体的输出。 例如在上下文中注入说明：“（背景信息）Agent B 曾说：……”。
（2）行为归属（Action Attribution）
为来自其他智能体的工具调用结果标注来源，使当前智能体可以利用这些结果而不会误认为是自身执行的。
通过这种转换，ADK 能够从被调用智能体的视角重建全新的工作上下文。 同时，会话（Session）仍保持完整的历史记录，保证系统的可追踪性与一致性。
这一机制确保每个智能体都能在独立的“Assistant”语义角色下运行，而不会错误地继承上游行为。
结论（Conclusion）
随着我们推动智能体处理更长周期、更复杂的任务， “上下文管理”不再意味着“字符串拼接”，而必须被视为与存储、计算同等重要的架构性问题。
ADK 的上下文架构——通过分层存储、编译视图、流水线处理与严格的作用域控制—— 是我们对此挑战的系统性解决方案。
它体现了将严格的系统工程思维应用于AI智能体开发的必要性， 并为智能体从“有趣的原型”迈向“可扩展、可调试、可靠的生产系统”提供了可行路径。