基于NVIDIA DGX Spark的智能体编排实践解析

沈纶铭，作者、Arm 首席解决方案架构师；李翊玮，作者、Arm 解决方案架构师

人工智能 (AI) 应用由单次模型推理发展为持续运行的智能体系统后，有必要重新认识 CPU 的作用。以往讨论 AI 系统时，人们通常关注模型规模、推理速度，或某次生成效果是否足够出色；然而，本地智能体若需长期运行，重点往往并非一次推理，而是系统能否不断接收事件、维持上下文、管理记忆、启动检索，再将这些能力组织成稳定的运行时 (runtime)。这类任务的本质更偏向编排，而不是执行单个模型。

因此，不能只把 CPU 在 AI 工作负载中的作用视作通用计算资源。智能体需要长时间运行并具备状态、内存、检索及跨步骤控制流时，CPU 更适合充当整个系统的控制层。它所提供的并非一次回应，而是支撑完整智能体架构持续运转的处理能力。

重新审视系统分工

当前不少有关本地 AI 的讨论，依旧集中于“模型能否在本地运行”。这个问题虽然重要，却只覆盖了其中一部分。对于持续运行的智能体，真正需要解决的是系统能否不断运转、及时响应、保存记忆并完成检索。

将问题提升到系统层面后，开发者很快会意识到，智能体的核心不仅是推理，更在于完整运行时的协调水平。事件驱动工作流由谁负责，内存和检索的流程由谁维系，上下文、状态与任务流向由谁掌控，系统又如何从一个事件推进至下一个行动，这些问题都无法单靠模型回答，而属于系统编排范畴。

换言之，AI 智能体由演示转向真正能够持续工作的本地运行时后，关注点会自然地从“模型执行”变为“系统如何运行”。这正是需要重新认识 CPU 的原因。

承接编排而非单纯执行，才是 CPU 的价值所在

讨论 CPU 对智能体系统的重要性时，重点不只是它能够处理多少工作，更要看它在整体架构中承担什么角色。

持续运行的本地 AI 智能体通常需要完成以下核心工作：

协调事件驱动工作流；

维护运行时状态和上下文；

协调语义记忆的读写操作；

连接检索流水线与后续推理流程；

在长时间运作过程中，让不同元件的控制逻辑保持稳定且可预测。

只有把这些能力结合起来，智能体系统才具备真正持续存在的基础。

从这个角度看，CPU 的价值在于它天然适合承接编排、控制流、状态管理与系统级协调。当一个智能体需要持续运作，而不是只做一次提示词响应时，CPU 就不再只是背景角色，而是整个运行时是否成立的关键之一。

本地运行时而非仅有本地推理，才是本地 AI 的下一步

这也解释了为什么许多本地 AI 内容看似亮眼，却不一定能成为开发者可使用的系统。系统若仍局限于一次性推理，就很难解决实际问题：能否保存上下文，能否记住此前发生的事情，能否随工作环境持续调整，以及能否在不同步骤间形成稳定的智能体循环。

要真正回答这些问题，就必须从本地推理往前走到本地运行时。这意味着智能体不只是会“生成”，还要会“保持存在感”；不只是会“回答”，还要会“维持状态”；不仅能够处理提示词，还需要能够串联完整的工作流。

当本地 AI 助理部署于企业内部环境后，可检索的企业知识记忆系统会持续接收新的专案文件、会议记录、内部知识库更新、工单内容与团队沟通摘要，而不再由助理被动等候员工提问。基于这些持续沉淀的信息，员工询问某个专案的待办状态、决策脉络或背景时，助理能够快速调取先前累积的上下文及相关资讯，不必每次从零开始理解，从而给出更完整且具备上下文的信息回复。近期累积的内容也会被它定期回顾，以辨识跨团队资讯落差、尚未解决的议题和重复出现的问题，再整理为执行建议、提醒或摘要。至此，“回答一个问题”已不再是 AI 系统的全部价值；它会成为企业内部的本地运行时，借助持续检索、持续监看与持续记忆，协助维持工作脉络和知识流动。

DGX Spark 为何尤其值得从这一角度审视

AI 智能体从单次推理迈向持续工作的运行时后，系统技术重心将由“模型能否给出回应”转到“完整流程如何协调”。在这样的架构中，需要解决事件的接收和分派、上下文在各步骤间的维持、记忆与检索的衔接，以及运行时如何在多个元件之间保持统一的控制逻辑。单次推理调用无法处理这些问题，因为它们属于编排范畴。所以，分析持续运行的本地 AI 智能体时，与其只看某个模型，不如关注整个系统怎样承载状态、内存、检索和工作流控制。

这篇 Learning Path 面向 DGX Spark，值得推荐之处并非展示单次推理，而是把自主工作空间认知、语义检索与上下文推理、语义内存、Hermes 编排运行时，以及持续运行的 AI 运行时架构，明确列为关注的系统层能力。

Learning Path 链接：https://learn.arm.com/learning-paths/laptops-and-desktops/dgx_persistent_agent/

真正需要建立的是一套运行时机制，使不同能力能够持续协同运作，而不是形成单点推理能力；页面列出的学习目标共同说明了这一点。开发者完成学习后，应能部署语义内存和上下文检索流水线，利用基于 Arm 架构的 Grace CPU 对事件驱动的 AI 工作流进行编排，建立持续运行的本地 AI 智能体，并描述编排、语义内存与本地推理如何在持续运行的 AI 运行时中结合。

也就是说，重点不在于模型运行于哪个平台，而是系统持续工作时，编排层必须接手哪些能力。由此来看，基于 Arm 架构的 CPU 不仅是普通计算资源，更是决定智能体运行时能否成立的关键控制层。该 Learning Path 还将目标读者直接界定为希望在 DGX Spark 上利用基于 Arm 架构的 Grace CPU 进行编排的进阶开发者，使这一技术观点拥有明确落点。

智能体工作流实作案例：语义内存与 Hermes 的结合

要将这一观点落实到具体技术路线，这篇 Learning Path 给出了很有代表性的例子。其起点并非运行模型，而是探索持续运行的 AI 运行时架构；随后建立运行时基础，部署 Hermes 智能体作为编排运行时，引入本地大语言模型 (LLM) 推理，构建持续运行的语义内存，再扩展至语义检索、上下文推理和自主工作空间认知。这样的章节结构把智能体系统划分成多个可分别构建、管理的运行时组件，而没有把全部价值集中在模型上。

对开发者而言，这种设计的重要性在于，它给出的并非孤立演示，而是一条较为完整的系统建构路线。开发者可由此看到持续运行的智能体系统如何形成：首先设置编排，再加入持续记忆，继而建立上下文检索，最终使系统获得更高层次的工作空间认知能力。这些内容让 Learning Path 成为有力的实作依据，并支撑更大的结论：当智能体系统走向持续运行，同时拥有上下文和记忆后，CPU 编排会比以往更加重要。

设计起点而非工具本身，才真正对开发者有用

从开发者视角出发，这篇内容的核心价值不只在于掌握 Hermes、Ollama 或 Qdrant 的连接方法，还在于促使你以系统设计视角重新提出问题：

智能体系统的控制层应设置在什么位置？

怎样协调记忆和检索之间的流程？

应该由谁维护状态和上下文？

在设计方面，持续运作的运行时与一次性推理存在哪些不同？

最终，这些问题的答案都会指向 CPU 所承担的编排职责。因此，与其把这篇内容视作普通的 AI 指导，不如将它理解为一个系统设计案例。

结语：CPU 在 AI 智能体中的角色再认识

“模型可以在本地执行”是过去很多 AI 内容所证明的事情；该 Learning Path 的学习目标与章节安排，则把问题推进到如何让 AI 智能体真正持续运作。关键答案并不落在单一模型本身：只有整个运行时将工作流、上下文、检索、内存和编排连接起来，才能形成一个可持续存在的系统。这正是这篇 Learning Path 最值得开发者关注和思考之处。

这篇 Learning Path 之所以最值得延伸成文章，是因为它呈现了另一种架构图景：AI 由演示迈向持续运作的智能体系统之后，CPU 在智能体 AI 系统中的定位，比过去一般 AI 更接近整个架构的中心。由此也应重新审视 CPU 在 AI 里的角色——除了承担一般工作负载的执行，它还要在持续运行的本地 AI 智能体架构中负责运行时控制、内存协调、状态管理与编排等更高层次的系统能力。