作者：Odin Shen，Arm首席解決方案架構師
隨著AI應用從單次推論轉向持續運作的代理系統，CPU扮演的角色日益重要。許多關於AI的討論仍聚焦於模型規模、推論速度，或單次生成回應的品質。但對於持續運作的裝置端AI代理而言，關鍵挑戰通常不在單次推論呼叫，而在於系統能否持續接收事件、保留脈絡、協調記憶、觸發檢索，並維持穩定的執行環境。這些職責與系統協同調度（orchestration）的關聯，遠大於獨立的模型執行。
在這類系統中，CPU不只是通用運算資源，更是管理多個步驟之間的狀態、記憶、檢索及控制流程的控制層。CPU 的工作不僅是產生單次回應，更要維持執行環境的邏輯，讓整體代理架構能長時間持續運作。
為何持續運作的AI代理需要不同的系統設計思維
目前許多裝置端AI的討論仍圍繞一個簡單問題：模型能否在本機執行？這個問題固然重要，卻只涵蓋系統的一部分。
對持續運作的AI代理而言，真正的挑戰在於系統能否長時間維持運作、做出回應、保有記憶、執行檢索，並讓各個元件保持一致的行為。
從這個角度來看，代理系統的關鍵挑戰不只有模型本身，還包括協調模型運作的執行環境。由誰驅動事件觸發的工作流程？由誰讓記憶與檢索持續連結至系統其他部分？由誰管理脈絡、狀態與任務流程？每次事件發生後，又由誰決定下一步行動？這些都是系統協同調度的問題，而不只是模型的問題。
隨著 AI 代理從展示原型走向持續運作的裝置端執行環境，關注焦點也從模型如何執行，轉向整個系統如何運作。這項轉變讓 CPU 變得更加重要。
CPU的價值不只在於執行，更在於協同調度
下圖呈現核心執行環境模式：事件進入系統後，由Arm CPU協調調度與控制流程；記憶系統提供持續保留的脈絡，而模型推論則是整體代理循環中的一個環節。
我們強調CPU在代理系統中的重要性，並不只是因為它能執行程式碼。更重要的問題是，它在整體架構中扮演哪些角色。
對持續運作的裝置端AI代理而言，CPU非常適合處理以下工作：
- 協調事件驅動的工作流程
- 維護執行環境的狀態與脈絡
- 協調語意記憶的讀取與寫入
- 將檢索流程與後續推理流程連結
- 在長時間的互動過程中維持系統行為的一致性
這些功能相互配合，讓代理系統得以持續運作。
從這個角度來看，CPU並非取代其他元件，而是天生適合負責協同調度、控制流程、狀態管理及系統層級的協調工作。當AI 代理持續運作，而非只回應單一提示時，CPU就不再只是背景運算資源，而是穩定、可靠執行環境的重要組成部分。
這個概念不只是架構上的構想，也已在相對應的實作中，建置成為可執行的最小可行產品（MVP）執行環境。這顯示CPU端的協同調度並不限於某一組特定工具，而是一種可延伸至不同推論與記憶後端的系統模式。
裝置端 AI 的下一步不只是裝置端推論，而是裝置端執行環境
這也說明了為何許多裝置端AI展示看似令人驚艷，卻未能成為真正可用的系統。只要系統仍聚焦於單次推論，就無法解決更實際的問題：能否長時間保留脈絡？能否記住先前事件？能否適應工作環境？能否在多個階段中維持穩定的代理循環？
要回答這些問題，裝置端AI就必須超越裝置端推論，走向裝置端執行環境。AI代理不能只產生回應，還必須維持狀態、接收提示、協調工作流程，並在持續運作的過程中連結記憶與檢索功能。
想像在企業環境中部署一套裝置端 AI 助理。它不只是等待員工輸入提示，而是持續追蹤新的專案文件、會議紀錄、內部知識庫更新、支援服務單，以及團隊溝通摘要，再將這些資訊整理成可搜尋的記憶系統。當員工詢問專案背景、決策歷程或待辦事項時，系統無須從頭重建資訊，而能從已儲存的內容中檢索相關脈絡。隨著時間推移，它會檢視累積的資訊、找出反覆出現的問題、標示尚未解決的議題，並產生摘要、提醒與行動建議。此時，系統提供的就不只是個別問題的答案，而是一套能監測資訊、維護記憶、檢索相關脈絡，並支援企業內部知識共享的裝置端執行環境。
這正是 CPU 發揮關鍵作用之處：它的角色不是產生單次回應，而是維持協同調度，讓AI代理持續運作。
為何值得在DGX Spark上探討這個觀點
DGX Spark是研究這項轉變的實用平台，因為它讓協同調度層成為系統中可見的一部分，而不是隱藏在模型執行背後。在此情境下，關鍵問題不是模型能否執行，而是持續運作的AI代理執行環境如何建構，包括如何協調工作流程、連結記憶與檢索，以及維護執行環境的狀態。
這也凸顯了相應的Learning Path的重要性。它探討持續運作的AI執行環境架構，包括使用Hermes進行執行環境協同調度、語意記憶、情境檢索，以及自主工作空間認知。這些元素共同讓DGX Spark成為實際探索CPU端協同調度如何支援持續運作的裝置端代理系統的環境。
因此，在研究持續運作的裝置端AI代理時，分析整體系統往往比只分析模型更有價值。關鍵在於系統如何維持狀態、記憶、檢索與工作流程控制。這項 DGX Spark Learning Path 特別值得關注，因為它聚焦於持續運作的AI執行環境架構、Hermes協同調度執行環境、語意記憶、語意檢索、情境推理及自主工作空間認知，而非單次推論展示。
學習目標也進一步強化了這個觀點。開發者不僅要了解單一模型如何執行，還會學習持續運作的AI執行環境如何結合協同調度、語意記憶與裝置端推論；如何建置持續運作的裝置端 AI 代理；以及如何部署語意記憶與情境檢索流程。這些目標共同說明，重點不只是個別推論能力，而是讓多項能力持續協同運作的執行環境機制。
重要的不是模型能否在平台上執行，而是協同調度層如何支援持續運作的系統。從這個角度來看，Arm CPU不只是另一項運算資源，更是讓AI代理執行環境得以順利運作的控制層。
實際案例：從Hermes到代理工作流程中的語意記憶
這項 Learning Path 展示了如何在實務中落實這項架構。它不是從執行模型開始，而是先介紹持續運作的 AI執行環境架構、建立執行環境基礎，再部署Hermes Agent進行協同調度、加入裝置端LLM推論、建立持續保留的語意記憶，最後擴展至語意檢索、情境推理與自主工作空間認知。這樣的安排反映了系統優先的設計方法：將AI代理視為一組執行環境元件，而非只關注模型。
這對開發者很重要，因為它提供的不只是展示，而是一套建置完整系統的藍圖。它示範如何分階段加入協同調度、記憶、檢索與更高階的推理能力，組成持續運作的代理功能。這項 Learning Path 也說明更廣泛的趨勢：隨著AI代理系統變得更加持續運作、更能理解脈絡，CPU 端協同調度的重要性也持續提升。
對開發者而言，重要的不只是工具，更是設計的起點
對開發者而言，其價值不僅在於學習Hermes、Ollama與Qdrant如何協同運作，更在於鼓勵開發者思考系統層級的問題：
- 代理系統的控制層應設置在哪裡？
- 記憶與檢索應如何協調？
- 有什麼機制能跨步驟維持狀態與脈絡？
- 當執行環境從僅供推論轉為持續運作時，究竟有哪些根本性的改變？
這些問題一再帶領我們思考CPU的協同調度角色。因此，這項工作不應只被視為另一份AI教學指南，更應被理解為一個系統設計案例。
結論：重新思考CPU在AI代理中的角色
許多AI展示都著重於證明模型能在本機執行。然而，這項Learning Path更深層的價值，在於鼓勵開發者提出一個更重要的問題：是什麼讓 AI 代理得以持續運作？答案不只有模型本身，還包括執行環境將協同調度、記憶、檢索、脈絡與工作流程整合為一致系統的能力。
從這個角度來看，CPU的角色已超越模型執行，還涵蓋協同調度、狀態管理、記憶協調及執行環境控制。這項轉變也說明了為何這個主題值得更多關注。隨著AI從獨立展示走向持續運作的代理系統，CPU將成為執行環境架構的核心部分。
若要實際了解這些概念，可先從 DGX Spark Learning Path 著手，了解持續運作的執行環境、語意記憶與 AI 代理協同調度，再探索 GitHub 程式碼倉庫，看看這些概念如何實作成可運作的 MVP 執行環境。
(參考原文：Rethinking the role of CPUs in AI: Agent orchestration on DGX Spark，本文中文版由作者Arm首席解決方案架構師Odin Shen-沈綸銘本人校閱；責編:Judith Cheng)
- 【Arm的AI世界】重新思考CPU的角色：DGX Spark上的AI代理協同調度 - 2026/11/06
- 【Arm的AI世界】運用Web AI以瀏覽器實現裝置端智慧 - 2026/10/14
- 【Arm的AI世界】運用功能安全、容器與DDS打造安全且可擴展的汽車系統 - 2026/10/02
訂閱MakerPRO知識充電報
與40000位開發者一同掌握科技創新的技術資訊！
