Google ADK 深度探索（二）：不同语境下的专用上下文对象
在上一篇 《ADK 一等公民 Context 解析》 中，我们了解到上下文是智能体运行的核心。承载这些能力的核心容器是功能强大的 InvocationContext，但为提升安全性与易用性，ADK 对其进行了精细化的分类，为不同语境提供了粒度各异的专用上下文对象。 要理解上下文分类的粒度，让我们重温一下 ADK 的核心理念：发送给 LLM 的“工作上下文（Working Context）”是一个更丰富、有状态系统的编译视图（Compiled View）。 “上下文编译器” 在传统软件工程中，编译器将高级源代码转换为机器刻度的二级制文件，在编译过程中执行优化、类型检查和安全检查。类似地，ADK 运行时（Runtime）充当上下文编译器的角色。它摄取交互的“源代码“ – 包括持久的会话状态（Session State）、临时的用户输入（User Instruction）、检索到的工件（Artifacts）、记忆库（Long-Term Knowledge）和系统指令（System Instruction）– 并将他们”编译“成针对当前执行阶段量身定制的特定上下文对象。 这个编译过程需要针对智能体系统的不同组件提供不同的接口（参考 前文）。负责渲染系统提示词的指令提供者（Instruction Provider）所需的访问权限，与设计用于修改数据库的工具或用于验证用户授权的回调（Callback）截然不同。ADK 的四种主要上下文类型 – InvocationContext、ReadonlyContext、CallbackContext 和 ToolContext – 代表了这些不同的接口。每种类型都强制执行最小权限原则（Principle of Least Priviledge），确保组件在最小化潜在的错误或安全漏洞“爆炸半径”的范围内执行。 智能体状态的演变 从智能体的发展轨迹，我们也能窥探这种分离架构的必要性。早期的框架本质上将应用程序的整个状态转储到一个单一的对象中，并将这个“上帝对象（God Object）”传递给每个函数。这必然导致：
