谷歌刚刚发布了一份重磅指南，聚焦于多智能体系统中的高效上下文工程。这对AI开发者来说绝对值得关注！（强烈建议收藏）
https://developers.googleblog.com/en/architecting-efficient-context-aware-multi-agent-framework-for-production/
下面是我从指南中提炼的关键要点：
上下文窗口并不是瓶颈，上下文工程才是。对于更复杂和长远的问题，上下文管理不能简单视为“字符串操作”问题。目前，智能体系统中处理上下文的默认方法仍然是将所有内容塞进提示中。历史记录越多、令牌越多、混乱越多。大多数团队将上下文视为字符串拼接问题。但这种原始上下文转储会造成三个关键失败：
重复信息导致成本爆炸 “中间丢失”效应导致性能下降 当智能体在系统中错误归因动作时，幻觉率增加
上下文管理已成为与存储和计算并重的架构问题。这意味着要用明确的转换取代临时字符串拼接。智能体默认接收最小所需上下文，并通过工具明确请求额外信息。看来谷歌的Agent Development Kit（简称ADK）在上下文管理上思考得很深入。它引入了一个分层架构，将上下文视为“状态系统上的编译视图”，而非简单的提示填充活动。
这看起来是怎样的呢？
1）结构：分层模型
该框架将存储与呈现分离为四个 distinct 层：
- 工作上下文：处理短暂的每次调用视图。
- 会话：维护持久的事件日志，捕获每条消息、工具调用和控制信号。
- 内存：提供可搜索的长期知识，超出单个会话的寿命。
- 工件：通过版本化引用管理大型二进制数据，而不是内嵌嵌入。
上下文编译是如何实际运作的？它通过有序的LLM流程和明确的处理器实现。内容处理器执行三个操作：选择过滤无关事件、转换将事件扁平化为适当角色的内容对象，以及注入将格式化的历史写入LLM请求中。内容处理器本质上是会话和工作上下文之间的桥梁。
该架构通过将上下文分为稳定前缀（指令、身份、摘要）和可变后缀（最新回合、工具输出）来实现前缀缓存。此外，static_instruction 原语保证系统提示的不可变性，从而在多次调用中保持缓存有效性。
2）Agentic管理当前重要事项
一旦确定了结构，核心挑战就变成了相关性。你需要弄清楚当前活跃窗口中应该包含什么。ADK通过人类定义的架构与Agentic决策的协作来解决这个问题。工程师定义数据的位置以及如何总结。智能体动态决定何时“伸手”获取特定内存块或工件。
对于大型负载，ADK应用句柄模式。5MB的CSV或海量JSON响应存储在工件存储中，而不是提示中。智能体默认只看到轻量级引用。当需要原始数据时，它们调用LoadArtifactsTool进行临时扩展。任务完成后，工件卸载。这将永久上下文税转为精确的按需访问。
对于长期知识，MemoryService提供两种检索模式：
- 反应式回忆：智能体识别知识空白并明确搜索语料库。
- 主动式回忆：预处理器在用户输入上运行相似性搜索，在模型调用前注入相关片段。
智能体只回忆当前步骤所需的确切片段，而不是携带所有以往对话。这让我想起了Claude Skills的分层方法，它确实提升了Claude Code中上下文的高效使用。
3）多智能体上下文
单智能体系统会遭受上下文膨胀。当构建多智能体时，这个问题会进一步放大，容易导致“上下文爆炸”，因为你融入了更多子智能体。为了使多智能体协调有效运作，ADK提供了两种模式。
智能体作为工具：将专用智能体视为可调用对象，它们接收专注的提示，而不带祖先历史。智能体转移：启用完整的控制移交，其中子智能体继承会话视图。include_contents 参数控制上下文流动，默认提供完整工作上下文或仅新提示。
在智能体移交期间，什么能防止幻觉？解决方案是对话翻译。先前的Assistant消息转换为带有归因标签的叙述上下文。来自其他智能体的工具调用被明确标记。每个智能体假设Assistant角色，而不会将更广泛的系统历史错误归因于自身。
最后，你不必使用谷歌ADK来应用这些洞见。我认为这些在构建多智能体系统时可以普遍适用。
（图片来源：nano banana pro）
