Nexus：把 AI Agent 跑成"长生命周期服务"的云-边执行底座

  • 关联论文：2610.05709
  • 作者：flyP
  • 更新：2026-10-07

一句话结论

Nexus 提出一套把单次 agent 调用升级为持久任务（persistent task）的云-边执行底座，用 OpenWrt 改造的分布式 runtime + run-scoped 委托 + 持久化账本三件套，把 LLM Agent 从"短对话推理"变成"长生命周期、可跨 Computer 与 Mobile、被故障和撤销语义约束的云-边服务"。

解决什么真问题

过去一年 agent 框架（LangChain / AutoGen / Dify / Dapr 等）大都把 agent 当"短任务函数"处理——一次用户 prompt → 一次推理 → 一次工具调用 → 返回结果。但真要把 agent 投入生产，会撞三堵墙：

  1. 故障半径大：所有工具调用、模型调用都从中心云发出，单点抖动 → 全局不可用，扩缩容成本线性上涨。
  2. 跨设备 / 跨终端没统一抽象：Computer（PC / 服务器）、Mobile（手机）、Edge（边缘盒子）每类设备权限模型、独立进程管理、GPU/IO 资源都不一样，agent 框架通常只覆盖其中一两类。
  3. 长生命周期任务没有一致的事务语义：失败恢复、撤销授权、调用结算、审计回放——这些云原生世界早有的能力，agent 框架里几乎都靠用户自己包。

Nexus 想做的事，就是把"agent 调用 = 一次 RPC"换成"agent 调用 = 一个跨设备的持久任务"，让 Dapr / Temporal / OpenWhisk 这类分布式系统的概念可以重新用到 agent 栈。

核心方法

1. Persistent Task 模型

Caller ──submit──▶ Nexus Coordinator (cloud)
                              │
   ┌──────────────┬──────────┴───────────┬──────────────┐
   ▼              ▼                      ▼              ▼
Edge Worker   Computer Device     Mobile Device    Model Worker
(OpenWrt rt)  (run-scoped token)  (revocable cap)  (LLM/SLM)
   │              │                      │              │
   └──────────────┴────── journal ───────┴──────────────┘
                              ▼
              Persistent Record (lifecycle / outputs /
              failures / recovery / usage / settlement)

核心是把一次 agent 调用变成一个跨节点有状态任务：

  • 任务有唯一 ID，从提交到结算全周期可回放；
  • 任务有run-scoped 委托（operation-scoped authority），即"这一次调用授权"，可以撤销（revocation）；
  • 任务有持久账本，记录执行、失败、恢复、用量、收费。

2. OpenWrt 化 runtime 做边缘侧承载

为什么挑 OpenWrt？论文没说完整理由但 abstract 给出暗示：OpenWrt 是嵌入式路由器的成熟 Linux 发行版，包管理、配置管理、网络协议栈、tiny footprint 都现成。把 OpenWrt 当 edge worker 的运行时基底，等价于复用工业级 IoT 固件工程，避免在每个工厂网关里都重写一遍 Linux 启动 + 网络 + 包管理。代价是 OpenWrt 的软件生态偏 C/Lua，Python/Node 的 AI 工具链要靠 cross-compiled 容器/conda 镜像补齐（原文未明确给出细节）。

3. Run-scoped delegation：操作-范围凭证

借鉴 OAuth 的 scope 与 Kubernetes 的 ServiceAccount 思路，给每一次 task 发一个带 TTL 的委托凭证，凭证只能调用 task 里白名单的工具、只能访问白名单的资源、只能对白名单用户可见。撤销（revocation）后：

  • 写入类调用立即被拒；
  • 读取类调用沿用过期许可可读（"读已凭证的旧结果"是合法的——这是论文里写的 6/6 revocation tests 设计）。

这样既保证安全撤销，又不破坏 agent 调试和审计体验。

4. Persistent Record：执行账本

每条 record 字段：执行 ID | 输入快照 | 中间工具调用日志 | 模型调用 token 用量 | 失败/重试链 | 结算状态。Journal 落到分布式 log（具体用 Raft / etcd 还是 CRDT，原文未明确）。

伪代码（提交一个 task）：

task = nexus.submit(
    prompt=user_prompt,
    tools=tool_selector(per_arm_table="WP|Sheet|Drive"),
    delegation=Delegation(
        ttl_s=3600,
        scopes=["computer.fs.read", "mobile.sms.send"],
        revokable_by=["user:owner"],
    ),
    persistence=Journal(
        store="raft",
        replica=3,
        settlement_token_price=token_price_table,
    ),
)

result = task.wait_or_stream(...)     # 流式 / 阻塞
task.journal  # 完整执行、恢复、撤销日志
task.usage    # token / 调用成本

5. Failure & Recovery 模型

  • 任务执行失败 → journal 记录 → coordinator 根据 task ID 重新调度到备用 worker；
  • 后台 worker 失联 → journal 里的 append-only log 由备用节点基于"已提交标记"恢复，避免重复 append；
  • 撤销委托 → 后续写入被拒，已写入则返旧。

关键实验与数据

维度 Nexus 表现 对照
Computer-Android 跨设备 workflow 10/10 全成功 —
Revocation tests（撤销后写入拦截 / 旧读可用） 6/6 全过 —
Worker loss 下 duplicate append 6 → 0（journal 消除重复） 6 次重复
24 组 matched task pairs（云-边场景） 24/24 完成 Dify 22/24
24 组 joint-success 配对的时延 Nexus 中位快 3.88 s Dify 鲁棒性差
Incremental-runtime memory ceiling 16 MiB Dapr 64 MiB（⚠️ Dapr 调用延迟更低）

关键 takeaway：

  • 完成率与正确性：Nexus 24/24，Dify 22/24（原文未明确说明 Dify 失败原因，可能是 Dify 在跨设备 workflow 里部分不支持）。
  • 资源占用：Nexus 16 MiB 比 Dapr 64 MiB 节省 ~75%（但调用延迟 Nexus 略高——trade-off）。
  • 撤销语义：6/6 全过，且保留旧读这一设计点很有意思——和传统 RBAC "撤销立即全停" 区别开。

亮点与局限

亮点

  • 跨设备统一抽象：Computer + Mobile + Edge 三类设备用同一套 task / delegation / journal 抽象，避开了"PC 用一套、移动用一套"的工程割裂。
  • 撤销语义设计：写入即时拦、旧读保留 = 既安全又可调试。
  • 资源占用极致：16 MiB 跑通完整云-边 runtime，对嵌入式边缘网关友好。
  • Journal 消除重复 append：6 → 0 这条数据对长任务很关键，避免 retry 风暴。

局限（诚实标注）

  • 延迟略高于 Dapr：abstract 主动承认。适合"长任务 / 低 QPS 优先"，不适合"毫秒级请求 / 高 QPS 在线服务"。
  • 与现有 agent 框架的兼容性未明示：Dify 是低代码产品，调用 Dapr 是 SDK 风格；Nexus 的接入姿势、迁移成本、SDK 文档成熟度都原文未明确。
  • Dify 24 组里 2 组失败原因未明说：可能 Dify 在某些跨设备 workflow 上根本不支持，而非"性能差"。
  • GitHub / 项目主页未在 abstract 公开（⚠️ GitHub 链接缺位）。如要落地，需要看 Resources 章节或作者机构主页（Cary Chang, Jialin Zhou）才能拿到入口。
  • 持久账本的可观测性、合规标准（SOC2 / ISO27001）未提及。

对工程落地的启发

  1. 如果是面向消费者的 agent 产品，单点 cloud agent 会出现 SLO 难调、跨设备流程割裂等问题；Nexus 的"persistent task + run-scoped delegation"思路值得借鉴到自己框架里。
  2. 长任务 / 异步 agent（如定时报告、定时监控）：必须引入"操作-范围凭证 + 持久化账本"两件套，否则失败恢复、撤销、计费三件事都会变成工程债。
  3. 边缘部署受限场景（16 MiB 内存上限）：Nexus 的低占用指标暗示这条路走得通，可以往工厂网关、路由器盒子等小型设备推。
  4. 撤销语义：自家做权限系统时，可以参考"写即时拦 + 旧读保留"这一对组合，比单纯"撤销立即全停"更人性化。

与同方向工作的关系

  • 跟 Dapr / Temporal / OpenWhisk 这类分布式 runtime 的关系：Nexus 复用了它们的持久任务 / saga / journal 思想，但专为 agent 场景做了三件事——run-scoped delegation（agent 特化的凭证）、跨设备（Computer + Mobile）、计量结算（usage / settlement）。
  • 跟 LangChain / AutoGen / Dify 这类 agent 框架的关系：互补，不是替代。Dify 偏快速搭建，Nexus 偏生产部署；二者可叠加（Dify 编排 → Nexus 承接 runtime）。
  • 跟 OpenAI Assistants API / Anthropic Claude Tool Use / MCP 的关系：MCP 解决"工具协议层"统一，Nexus 解决"执行 / 权限 / 跨设备"统一，两者站在不同栈层，可以叠加使用。

适合谁读

  • 做 AI agent 生产化 / 平台化的工程师：必读，重点放在 persistent task + run-scoped delegation。
  • 嵌入式 / 边缘部署团队：关注 OpenWrt runtime 与 16 MiB 内存占用。
  • 安全 / 合规 / SRE：撤销语义、journal、settle 三件套是 RAG / agent 落地的关键。
  • agent 框架作者（Dify / LangChain 维护者）：可作为"下一代 runtime 应支持什么能力"的参考基线。