开源AI引擎StateFrame：让GPU装下更多Agent，告别上下文膨胀

大多数AI Agent依赖聊天式对话来维持上下文，随着交互轮次增加，上下文窗口不断膨胀，导致显存占用上升、推理速度下降，最终被迫进行上下文压缩（compaction），而压缩往往意味着信息丢失。一位开发者在Reddit上分享了自己耗时五周打造的开源项目StateFrame，试图从根本上改变这一局面：将Agent的一切存储为状态，每一步只向模型提供真正需要的信息，从而保持上下文窗口平坦。

核心思路：用状态取代对话历史

StateFrame的设计哲学很直接——Agent不需要记住整段对话，只需要在每一步拿到当前决策所需的状态。在传统的聊天式Agent中，历史消息会全部塞进上下文窗口，步数越多窗口越大，管理成本随之攀升。StateFrame则把所有信息保存在外部状态中，每次推理仅注入与当前步骤相关的内容。

据作者描述，这种做法的直接结果是上下文窗口变成“平坦”且可预测的：第300步的负载与第3步相当，不会随时间推移而增长。对于一个需要长时间运行的Agent任务而言，这意味着资源消耗曲线从持续爬升变为一条水平线。

上下文窗口（Context Window） 指大语言模型单次推理所能接收的最大token数量，包括系统提示、历史对话、工具返回结果等所有输入。它由模型架构（如注意力机制的复杂度）决定，是硬性上限。当Agent持续将完整对话历史塞入窗口时，token数随轮次线性增长，不仅推高显存占用（KV Cache随之膨胀），还会因序列变长而拖慢推理速度。更关键的是，一旦接近上限，Agent必须压缩或丢弃历史，造成信息损失。StateFrame的“平坦上下文”正是针对这一瓶颈：通过外部状态管理，使每次推理的输入长度保持恒定，从而绕开上下文窗口的容量约束。

平坦上下文带来的三个实际收益

GPU上能跑更多Agent

由于每个Agent的上下文窗口大小稳定且可预测，显存分配不再需要为“历史可能膨胀”预留冗余空间。据作者说明，这直接提升了单块GPU可容纳的Agent数量。对于自托管多Agent系统的团队来说，这是实打实的成本优化。

自托管大模型变得真正可用

作者提到，不少人在自托管大模型时受限于上下文空间耗尽的问题，尤其是长任务场景。平坦窗口意味着模型不会因为历史累积而“撑爆”上下文，同时推理速度也能保持稳定——因为不需要处理不断变长的输入序列。

无需压缩，Agent不丢线索

传统历史型Agent在上下文接近上限时往往采取压缩策略，把旧对话摘要或截断，这容易让Agent丢失关键信息。StateFrame将一切保存在状态中，从机制上移除了压缩环节，作者认为这能让Agent避免“断片”。

KV Cache（键值缓存） 是Transformer推理中的关键优化：自回归生成时，模型会缓存已处理token的Key和Value矩阵，避免重复计算。但缓存大小与上下文长度成正比，长上下文会占用大量显存。对于多Agent并发场景，每个Agent都维护自己的KV Cache，显存压力成倍增加。StateFrame让每个Agent的上下文长度稳定在较小值，KV Cache不再随步数膨胀，因此单卡可同时驻留更多Agent实例。这也是作者强调“GPU上能跑更多Agent”的技术根源——省下的不是模型权重显存，而是动态的缓存与激活开销。

上下文压缩（Compaction） 是长对话Agent常用的兜底策略，典型做法包括：滑动窗口截断旧消息、用LLM对历史做摘要、或按重要性丢弃片段。这些方法虽能暂时腾出空间，却会引入不可逆的信息损失——被摘要的细节可能恰是后续决策的关键依据，截断则直接抹除早期约束。StateFrame从架构上移除了压缩环节：所有原始信息持久化在外部状态存储中，模型每步按需检索，而非被动接收压缩后的历史。这类似于数据库与缓存的区别——状态是完整的事实源，上下文只是当前查询的工作集。因此Agent不会因压缩而“断片”，但代价是需要设计可靠的状态检索与更新机制。

开源与后续计划

项目已在GitHub上以StateFrame之名开源，作者提供了源码供开发者试用。他在帖子中坦言，五周的开发过程中“把Foundry的服务器往死里用”，并预告还有更多功能在路上，其中一些能力“在其他Agent上没见过”。

说个细节，作者在Reddit上发帖的主要诉求之一是获取反馈——他直言“真的很难让任何人看到这个项目”。开源项目冷启动的困境在此可见一斑。对于关注Agent运行时架构的开发者而言，StateFrame提供了一条与主流聊天式方案不同的技术路径，其实际表现和可扩展性值得在真实负载下进一步验证。

Foundry 在此语境下指作者开发期间使用的云GPU/算力平台（如Modal、RunPod或类似服务），用于远程训练与推理测试。作者称“把Foundry的服务器往死里用”，暗示五周内进行了大量高频的实验迭代，这也侧面说明StateFrame的验证依赖真实负载下的反复调优。对于想复现或评估该项目的开发者，需注意其性能表现可能与具体硬件、模型规模及状态存储后端密切相关，开箱即用的体验未必等同于作者测试环境。