你的AI助手正在被你自己的对话淹没。这不是比喻——这是Google现在迫使开发者正视的根本问题。当你向单个AI会话分配更多任务时，性能就会下降。模型会被自己的历史搞混。响应质量在你最需要它的时候反而变差。上下文腐化现在有了名字，它正在扼杀开发者的生产力。
Gemini CLI的新子代理功能是Google给出的答案，但这不是大多数开发者预期的那一个。Google没有追逐越来越大的上下文窗口，而是押注架构优于原始容量。子代理是专门的AI工作者，在与主会话完全隔离的环境中运行。它们拥有全新的上下文窗口，执行复杂的多步骤任务，然后将一切总结成简洁的简报返回给主协调器。
其机制简洁优雅。你在Markdown文件中定义一个子代理——本质上是一个提示词，告诉代理扮演什么角色、应该做什么。然后你可以在对话中任何地方使用@agent语法调用它。子代理启动，在干净的上下文中处理工作负载，然后回传结果。你可以并行运行多个子代理，将顺序工作流转变为并发工作流。
这种架构之所以重要，是因为它规避了一个物理限制。Token上下文有上限，而这个上限因模型和定价等级而异。但代理编排可以水平扩展。一个代理向另一个代理交接，每个都在全新的上下文中操作，理论上可以处理无限复杂性。主会话永远不会积累中间步骤的残渣——它只看到结论。
对于构建复杂工作流的开发者来说，这改变了整个方程式。一个原本会因五十次失败尝试而膨胀上下文的调试会话，现在保持精简：子代理进行探索，回报告知根本原因和修复方案。一个原本需要粘贴整个文件才能进行的代码审查，现在可以分块处理，子代理综合发现结果。20万token的上下文窗口不再是奢侈品——它是一种共享资源，子代理可以高效消耗而非浪费。
竞争影响远不止这个单一功能。Google正在发出信号：下一个前沿不是模型能容纳多少token，而是工作如何智能地分配到多个代理。Anthropic、OpenAI和开源社区都在向类似架构竞速。开发者战场正从模型基准测试转向代理原语——定义、组合和调试多代理系统有多容易？
Google基于Markdown的方法为子代理提供了低门槛。任何能写提示词的开发者都可以创建代理。但这同时也设置了高天花板：复杂的团队可以构建专门的代理层级结构，每个代理针对不同任务类型进行优化。工具会成熟，模式会稳定。Google今天种下的是一种与AI协作新方式的基础设施。
上下文腐化一直是复杂AI工作流的隐性税收。现在，它的解决方案有了明确的标价。