Google ADK - 构建生产级、高效的上下文感知多智能体框架
本文翻译自 Google Developer Blog 的 Architecting efficient context-aware multi-agent framework for production。 AI 智能体（Agent）的开发领域正经历着风起云涌的变化。我们早就跨过了还在做单轮聊天机器人原型的阶段。如今，各家机构正在部署的是那种复杂的、自主的智能体，它们能处理长链路任务（long-horizon tasks）：比如自动化工作流、开展深度研究，甚至维护庞大的代码库。 但这一愿景很快就撞上了一堵墙：上下文（Context）。 随着智能体运行时间的拉长，它们需要“记住”的信息量——聊天记录、工具返回的数据、外部文档、中间的推理过程——会呈爆炸式增长。目前的“通解”通常是依赖基础模型（Foundation Models）越来越大的上下文窗口（Context Window）。但是，单纯指望给智能体更大的空间来粘贴文本，绝不可能是长久的扩展之道。 为了构建可靠、高效且易于调试的生产级智能体，业界正在探索一门新的学科： 上下文工程（Context Engineering） —— 不再把上下文仅仅当作一段文本，而是将其视为系统中的“一等公民”，拥有独立的架构、生命周期和约束条件。 基于我们在扩展复杂的单智能体或多智能体系统方面的经验，我们在 Google Agent Development Kit (ADK) 中设计并迭代了上下文栈（Context Stack）来支持这一学科。ADK 是一个开源的、原生支持多智能体的框架，旨在让主动的上下文工程在实际系统中落地。 扩展性的瓶颈 更大的上下文窗口虽能缓解问题，却治标不治本。在实践中，那种幼稚的模式——把所有东西都追加到一个巨大的提示词（Prompt）里——会在以下三重压力下崩塌： 成本与延迟的恶性循环： 模型的推理成本和“首字延迟”（Time-to-first-token）会随着上下文长度迅速飙升。把原始的历史记录和冗长的工具返回结果“一股脑塞进”窗口，会让智能体变得既迟钝又昂贵。 信号衰减（“迷失在中间”）： 一个充斥着无关日志、过时工具输出或废弃状态的上下文窗口，会分散模型的注意力。这会导致模型死盯着过去的模式，而忽略了当前的指令。为了确保决策稳健，我们必须最大化相关信息的密度。 物理极限： 现实世界的工作负载——涉及完整的 RAG 检索结果、中间产物（Artifacts）和漫长的对话痕迹——最终甚至会撑爆最大的固定窗口。 单纯靠“砸 Token”只能争取时间，却改变不了问题的本质。要实现规模化，我们需要改变上下文的表示和管理方式，而不仅仅是纠结于一次调用能塞进多少内容。
