基于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 智能体时，相比某个模型本身，整个系统怎样承接状态、内存、检索与工作流控制通常更值得分析。

单次推理展示并非这篇面向 DGX Spark 的 Learning Path 的重点；它推荐开发者关注系统层能力，包括自主工作空间认知、语义检索与上下文推理、语义内存、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 智能体中的定位

这篇 Learning Path 的价值，在于把开发者关注的问题从“模型可以在本地执行”推进到 AI 智能体持续运作所需的关键条件。真正决定结果的并不是单一模型，而是运行时能否将工作流、上下文、检索、内存与编排组合为持续存在的完整系统。无论学习目标还是章节安排，Learning Path 都明确呈现了这一方向；这与过去许多 AI 内容着重验证本地执行形成了区别。

从这个角度看，CPU 在 AI 里的角色就值得被重新思考。它的价值不只在于执行一般工作负载，而是在持续运行的本地 AI 智能体架构里承接编排、状态管理、内存协调和运行时控制这些更高层次的系统能力。这也正是这篇 Learning Path 最值得被延伸成文章的原因：它让我们看到，当 AI 从演示走向持续运作的智能体系统，CPU 在智能体 AI 系统中的定位，比过去一般 AI 更靠近整个架构的中心。