[Paper] Nalar：智能体服务框架

Source: arXiv - 2601.05109v1

概述

本文介绍了 Nalar，一个专为大型语言模型（LLM）驱动的代理构建的专用服务框架。通过将代理工作流应做的 what 与执行方式 how 明确分离，Nalar 让开发者可以编写普通的 Python 代码，而系统负责编排、状态管理以及延迟感知调度。其结果是显著降低尾部延迟，并提升复杂多步骤 AI 应用的吞吐量。

关键贡献

• 统一工作流抽象 – 代理和工具被表示为普通的 Python 函数；Nalar 自动生成轻量级的 future 存根，以捕获依赖关系和执行上下文。
• 受管状态层 – 逻辑状态与其物理位置解耦，实现安全的复用、迁移以及无需程序员层面记账的确定性重试。
• 双层控制架构 – 全局策略引擎计算高层路由和资源策略，而本地事件驱动的控制器实时执行这些策略。
• 策略驱动的自适应调度 – 基于观测到的延迟、工作负载特性和 SLA 约束，支持动态路由、负载均衡和资源限流。
• 可扩展运行时 – 已展示能够处理超过 130 K 并发 future，控制开销低于 500 ms，并在现有基线崩溃的情况下维持 80 RPS。

方法论

1. 基于 Future 的 API – 当开发者调用代理或工具时，Nalar 用一个 future 对象替代调用，该对象记录调用的输入、所需资源以及任何下游依赖。future 是一个轻量级占位符，可以独立调度。
2. 状态抽象 – 所有可变数据都存放在受管理的状态存储中。存储提供简单的键‑值接口，但内部跟踪版本和位置，允许运行时在机器之间移动状态或在不损坏用户数据的情况下重试操作。
3. 控制层次结构
   • 全局策略引擎：定期评估系统范围的指标（例如队列长度、延迟直方图），并发出路由和扩缩决策。
   • 本地控制器：附加在每个工作节点上，接收策略更新并通过调整任务队列、限制调用或迁移 future 来执行这些策略。
4. 评估工作负载 – 作者构建了三个具代表性的代理应用（例如多工具规划、带外部 API 的对话助手，以及自主数据管道编排），并将 Nalar 与普通的 Python‑asyncio 基线以及商业无服务器编排器进行比较。

结果与发现

实验表明，Nalar 的自适应路由和状态管理能够防止长时间运行、对延迟敏感的代理流水线在突发流量模式下卡顿。

实际影响

• 简化的开发者体验 – 团队可以保留现有的 Python 代码库，无需将代理重写为微服务或嵌入自定义编排逻辑。
• 成本效益的扩展 – 通过自动限流和迁移工作，Nalar 减少了计算资源的过度配置，这对云原生 AI 服务非常有价值。
• 生产 AI 的鲁棒性 – 确定性的重试和状态迁移意味着当外部 API（例如支付网关、知识库）暂时不可用时，出现的“幽灵”故障更少。
• 用于 SLA 的策略钩子 – 运维人员可以直接在全局控制器中编码业务层面的策略（例如优先处理高级用户、强制每用户速率限制），而无需触及应用代码。
• “代理即服务”平台的基础 – 构建多代理市场的公司可以将 Nalar 接入，以在支持异构工具集（搜索、数据库访问、代码执行等）的同时，保证低尾延迟。

限制与未来工作

• 假设以 Python 为中心的工作负载 – 当前的存根生成和状态 API 与 Python 紧密耦合；扩展到其他语言或多语言环境将需要额外的工程工作。
• 控制回路延迟 – 虽然低于 500 毫秒的开销尚可，但超低延迟的使用场景（例如高频交易机器人）仍可能将控制延迟视为瓶颈。
• 外部工具可靠性 – Nalar 能够缓解但无法完全消除第三方服务导致的延迟峰值；未来的工作可以集成预测模型，以预先重新路由调用。
• 安全性与多租户隔离 – 本文侧重于性能；在多租户部署中对共享状态进行强健的沙箱化和细粒度访问控制仍是未解的研究方向。

总体而言，Nalar 提供了一个有说服力的蓝图，能够将复杂的、由 LLM 驱动的代理流水线转化为可投入生产的服务，同时不牺牲开发者的敏捷性。它将基于未来的编排、受管状态以及策略驱动的控制相结合，可能成为下一代 AI 基础设施的基石。

作者

• Marco Laju
• Donghyun Son
• Saurabh Agarwal
• Nitin Kedia
• Myungjin Lee
• Jayanth Srinivasa
• Aditya Akella

论文信息

• arXiv ID: 2601.05109v1
• 分类: cs.DC, cs.MA
• 发布时间: 2026年1月8日
• PDF: 下载 PDF