A Policy-Driven Runtime Layer for Agentic LLM Serving
本文提出了一种新的架构“智能体运行时层”，旨在弥合多智能体框架与大语言模型服务引擎之间的鸿沟以实现策略驱动的优化，并通过 CacheSage 系统证明该方法在多样化的多智能体工作负载中显著提升了缓存命中率、首词元生成时间及吞吐量。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象你正在经营一家繁忙的高端餐厅。
当前设置：沟通中断
目前，你的餐厅有两个截然不同的层级，它们彼此之间沟通不畅：
- 主厨（代理框架）： 这个人知道菜单、服务员的角色以及每张桌子的具体指令。他们知道谁在点餐以及需要什么。然而，他们从未见过厨房内部；他们不知道哪些锅正在炉灶上，也不知道哪些食材即将耗尽。
- 厨房员工（服务引擎）： 这个团队看到每一道进来的订单。他们确切地知道有多少锅在煮沸，以及烹饪速度有多快。但他们完全不知道顾客是谁，也不知道这顿饭的“故事”是什么。对他们而言，每个订单只是一个通用的请求。
问题：事物出错的“接缝”处
由于这两组人没有共享信息，餐厅做出了低效的决策。
- 示例： 主厨知道 4 号桌总是在主菜前点同样的开胃菜。但厨房员工不知道这一点。因此，每当 4 号桌点餐时，厨房都必须从头开始切洋葱，尽管他们五分钟前刚为同一张桌子做过这件事。
- 论文将这种情况称为“接缝”。目前，如果你想解决这个问题，你不得不通过特定的、一次性的规则来修补主厨的笔记或厨房的工作流程。这很混乱，而且无法扩展。
解决方案：“代理运行时层”（新的楼层经理）
作者提议在主厨和厨房之间构建一个第三层：一位楼层经理。
这位楼层经理有一份特殊的工作。他们倾听主厨（以了解角色和身份），并观察厨房（以查看烹饪事件）。他们利用这种综合知识，使用四种简单的工具做出明智的决策：
- 观察： “我看到来自‘规划者’服务员的新订单进来了。”
- 评分： “根据历史数据，这个‘规划者’的订单非常重要，且很可能随后会有‘代码者’的订单。给予高优先级。”
- 预测： “我打赌下一个订单将来自‘代码者’服务员。让我们现在就准备好他们的食材。”
- 行动： “继续为‘代码者’预热炉灶，以免延误。”
这位楼层经理充当通用翻译器。任何新规则（例如“公平对待所有桌子”或“节约能源”）都可以插入到这位经理中，而不会破坏主厨或厨房的功能。
案例研究："CacheSage"（智能储藏室）
为了证明这行之有效，作者构建了一个名为CacheSage的特定楼层经理来处理“储藏室”（计算机的内存，或 KV 缓存）。
- 旧方法： 厨房根据食材被使用的时间长短来丢弃食材（内存）。如果“规划者”服务员休息后回来，厨房必须重新切一切，因为食材已经被扔掉了。
- CacheSage 方法： 楼层经理学习模式。他们注意到“规划者”几乎总是紧接着“代码者”。
- 当“规划者”完成时，楼层经理说：“我预测下一个是‘代码者’。”
- 他们安全地保留“规划者”的食材（使其不被扔掉），甚至在新订单到达之前就开始准备“代码者”的食材。
结果
当他们在五个不同的现实世界“餐厅”场景（复杂的 AI 任务）中测试这一点时：
- 减少浪费： 他们比以前多 13% 到 37% 的时间将正确的食材保留在储藏室中。
- 更快的服务： 顾客拿到食物的速度快了 12% 到 29%，因为厨房不必从头开始。
- 更多顾客： 餐厅每小时可以接待多 6% 到 14% 的桌子。
总结
论文认为，为了让 AI 代理高效运行，我们不能仅仅调整顶层（逻辑）或底层（硬件）。我们需要一个专门的“中层管理者”，它既能理解代理的身份，又能理解引擎的事件，利用一套简单的四条规则，使整个系统变得更聪明、更快速。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。