基于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，它把焦点明确放在持续运行的 AI 运行时架构、Hermes 编排运行时、语义内存、语义检索与上下文推理，以及自主工作空间认知等系统层能力，而不是停留在单次推理展示。

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

从学习目标来看，这个技术重点也非常一致。页面明确指出，完成后开发者将能描述持续运行的 AI 运行时如何结合编排、语义内存与本地推理；建立持续运行的本地 AI 智能体；利用基于 Arm 架构的 Grace CPU 编排事件驱动的 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 的学习目标与章节安排，都清楚指向这一点。

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

• ARM ARM 关注

  关注

  135

  文章

  9676

  浏览量

  397850