在生产环境中的智能体中，人们如何处理上下文压缩与提示缓存之间的权衡？

Reddit r/AI_Agents 新闻
context-compaction prompt-caching ai-agents production-ai context-management subagents

摘要

本文探讨了生产环境AI智能体中上下文压缩与提示缓存之间的权衡，提出使用子代理作为策略，以保持缓存效率并减少上下文污染。

我一直在思考长期运行的智能体的上下文管理。压缩显然有助于控制上下文增长，但似乎需要付出代价：一旦你重写或总结对话状态，就可能失去提示缓存的许多好处，因为前缀不断变化。因此我想知道在生产环境中人们是如何处理这个问题的。你们是否经常压缩主智能体的上下文？或者是否有更好的模式，保持主上下文相对稳定，将孤立的工作推送到具有干净上下文的子代理，然后只将相关的结果或产出物返回给父代理？类似于：主智能体 → 生成专注的子代理 → 子代理进行探索/工具调用 → 返回简洁结果 → 主上下文保持干净。这似乎能带来：更好的提示缓存利用率、更少的上下文污染、更清晰的任务边界、更少因重复总结导致的信息损失。那么，压缩更多地成为对真正长期状态的后备方案，而不是每N轮对话就需要的东西。好奇人们在生产中实际是怎么做的。你们多久压缩一次上下文，以及何时更倾向于压缩而非上下文隔离/子代理？
查看原文

相似文章

代理中的提示缓存

Lobsters Hottest

本文解释了提示缓存在大语言模型代理中的工作原理，涵盖 KV 缓存机制、预填充和解码阶段，以及其对延迟、成本和代理设计的影响。

小型子代理用于上下文工程

Reddit r/AI_Agents

作者建议使用小型、快速的AI子代理进行上下文工程，以提高AI系统的效率并降低成本，质疑为何这种方法未被广泛采用，并寻求社区反馈。