"始终在线"的代理真的需要始终在线吗？
摘要
讨论了始终在线AI代理的架构设计，提出它们并非必须真正始终在线；相反，可以通过使用无服务器计算和状态管理使其更具临时性，以节省成本。
如果我们将一个始终在线的代理分解，我们得到的是IO通道、计算、配置、存储。所有的工具调用、记忆都是次要的，因为每个工具调用都是一次网络调用，而记忆主要是磁盘操作。你是否了解任何已进行或正在进行的，使始终在线代理更加临时化的相关工作，例如像lambda那样来去自如，再加上一些状态管理？（目标显然是为了节省成本/提高效率。）
相似文章
AI agents 正在改变人们对计算成本的看法
本文讨论了AI代理工作流如何将优化重心从单纯的推理成本转向更广泛的挑战，如延迟、编排开销和可靠性。文章强调了向混合架构和动态模型路由发展的趋势，以应对这些多步骤工作流的复杂性。
如何让代理运行数小时，以及哪些架构真正对代理友好？#深度探讨 #氛围程序员问题
作者探讨了AI编码代理的两个关键挑战：确保长时间自主执行（数小时）以及为本地应用设计对代理友好的架构。他们提出在规划和执行之前，增加一个显式的知识组织阶段来管理混乱的上下文。
@omarsar0: 始终在线智能体的精彩概述。（收藏它）这是一份全新的130多页的关于始终在线智能体的调查报告。简单来说，始终…
一份全新的130多页的关于始终在线智能体的调查报告。始终在线智能体是其未来行为依赖于先前交互中积累的持久状态的系统。该调查将状态视为不仅仅是记忆，而是沿着生命周期对每个状态项在六个轴上进行评分，并引入了始终在线评估协议（AOEP-v0）来管理状态变化和恢复。
AI代理没有智能问题，它们有状态管理问题
文章认为，AI代理在生产中的大多数故障是由于不稳定的运行状态和内存退化造成的，而非模型能力不足，并强调需要更好的基础设施来支持状态管理、可观测性和自适应可靠性。
本地代理的难点不在于模型，而在于控制平面
本文认为，本地AI代理的真正瓶颈并非模型本身，而是控制平面。控制平面经常泄露元数据，且无法访问防火墙后的内部系统。文章强调了定制MCP连接器和完全VPC/本地部署的必要性，才能使此类代理真正可行。