从OpenClaw说起:Agentic AI时代CPU价值的回归

2025年，是一个曾被寄予厚望的“Agentic AI元年”，它确实也没让人失望，但也没有想象中的激荡：

• 年初，Manus横空出世，展示了Agent无缝协作的惊艳效果，但随后并未在大众市场上掀起多大的波澜，直到年末，团队被Meta收购。

• 年中，豆包手机将个人Agent深度嵌入操作系统，功能强大，但随之带来的权限和安全问题，让它胎死腹中。

• 年末，千问Agent让你用一句话便丝滑到手一杯奶茶；但奶茶虽好，能帮我再解决些其他硬核的痛点不？

而当我们推开2026年的窗口， 最先看到的是一只龙虾与Mac Mini的“破圈组合" 引爆了AI圈：开发者将轻量级Agent部署于售价不足万元的Mac Mini，作为其24小时私人助理，通过短消息交互（e.g.，WhatsApp），让它写Bash脚本整理照片，调用本地知识库解答问题，甚至控制智能家居。这个Agent的名字由最初的ClawdBot（蹭Claude Bot谐音）改为MoltBot（有点饶舌），最后又从“MoltBot”成OpenClaw。开源，部署方便，再加上短消息交互的特性，使得这只龙虾与之前的Agent如此不同，但又如此的贴近用户。包括AWS，阿里云，火山引擎在内的各大CSP纷纷下场，支持OpenClaw的部署。 或许，Agentic AI时代的大门就这样被龙虾 "Claw Open"。

那么，为什么是现在? 为什么是OpenClaw？它能在Mac Mini上部署意味着什么？ Agentic AI时代真的开启了吗？CPU的春天来了么？Hold on，我们从源头开始捋一捋。

Agent的牛津词典定义有两个意涵：

1. A person who acts on behalf of another person or group.

2. A person or thing that takes an active role or produces a specified effect.

前者译为代理，强调的是动作的自主性；后者有推动者之意，强调的是目标导向。 而在AI 语境下Agent（中文称为智能体）是两种意思兼而有之，它是能够自主感知环境、进行决策并采取行动以实现特定目标的智能系统。它与AI助理和ChatBot之间的区别如下表所示：

Source：https://cloud.google.com/discover/what-are-ai-agents?hl=zh-CN

可以看到与AI助理和ChatBot相比， AI智能体的最大特点在其自主性，以及为实现给定目标的独立决策和多步复杂性操作。而要实现这些，就要求AI智能体具有如下细分能力：

• 感知（Perception）： 接收文本、语音、图像或来自外模式， 减少Reasoning过程中出现的幻觉，并能够根据环境反馈进行调整。

• 记忆（Memory）： 保存短期对话和长期经验，以便在后续任务中利用历史信息。这不一定要通过大模型本身来实现，但需要它支持长上下文。

• 行动（Action）： 通过调用外部工具（如搜索、计算器、代码解释器）来执行具体的物理或数字任务。 

图1. Agentic AI的实现模式。图片来源于 ^[3]，并在其基础上做了改动。

基于上述定义，我们认为AI智能体的实现方式上，需要具备三方面特征： LLM Orchestrated （工具调用由模型发起，而非其他工具）；动态路径（每次工具调用，工具选择不唯一）， 多步骤（支持工作链路上，LLM多次调用工具），如上图右侧虚线框所示。 举个例子： LLM-orchestrated (由模型调度) vs Host-orchestrated (由 Python 代码调度)。前者高度依赖 CoT，模型自己思考该干什么；而后者，若基础模型没有 CoT，开发者必须在外部编写极其复杂的 Python 逻辑（比如，if-else分支）来告诉模型：第一步干什么，第二步干什么。因此，在这种情况下，AI 不再是个“智能体”，而仅仅是一个被程序反复调用的“文本补全工具”，它失去了 Agent 应有的自主性和灵活性。所以，CoT是AI智能体的基础。

Chain-Of-Thought (CoT) 思维链引导大模型将复杂的任务分解为一系列逻辑步骤，最终得出解决方案而非一步给出答案。 它最初的目的是通过逻辑推理，提升回答的准确性，减少幻觉。而在智能体中，CoT的具体作用体现在以下四个方面：

智能体面临的目标通常是宽泛的（例如：“帮我买一个500元左右的床头柜”）。CoT 允许智能体将长期目标拆解为可执行的子目标。思维链能帮助智能体诱导（Induce）、跟踪（Track）和更新动作计划。它通过“内心独白”决定下一步该去搜寻信息还是该执行购买动作。

智能体在与外部环境（网页、数据库、API）交互时会遇到不可预见的情况。当行动失败或观察到非预期结果时，CoT 提供了一个逻辑缓冲区。Reasoning traces 能帮助智能体处理异常，根据当前环境反馈调整计划（例如：“既然抽屉里没钥匙，那我就该去桌子上看看”），而不是陷入死循环。

智能体的决策过程往往很复杂，用户需要知道它为什么这么做。CoT 为人类提供了一个“观察窗口”：如果智能体出错了，我们可以查看它是哪一步推理错了（例如：是算错了钱，还是误解了用户的颜色要求），甚至可以通过“编辑思维链（Thought Editing）”来纠正智能体的行为，实现人机协作。

这是智能体CoT高阶框架ReAct的核心 ^[1]，即：

• Reason to Act (推理指导行动)：通过CoT决定调用哪个工具（如搜索、计算器、Python解释器）。

• Act to Reason (行动补充推理)：通过行动获取外部事实，再将事实带回思维链中进一步推理。这种闭环使智能体更可靠。

那么CoT如何实现的呢？CoT 并不是某种特定的算法代码，它在模型中的实现通常有三种实现方式：

a. 提示词工程：利用“自注意力机制”的补全

这是最普遍，成本最低，也是较浅层的实现，通常有两种实现模式：

• Few-shot CoT： 在提示词中，给模型看几个“问题 -> 理由 -> 答案”的例子，然后，让模型有样学样。

• Zero-shot CoT：只要在问题后面加一句“让我们一步步推理”。

之所以这种提示词工程可以形成CoT，原因如下： 大模型本质是“下一个 Token 预测器”，当提示词中出现了逻辑推导的格式时，模型的自注意力（Self-Attention）机制会被引导到（如“因为”、“所以”、“首先”）逻辑词上。推理步骤产生的 Token 会进入模型的上下文，作为后续预测的条件。这实际上是让模型在给出最终答案前，先为自己生成更多的“有效背景信息”。这一方面实现了复杂问题的分步解答，另一方面，更多的背景信息也减少了模型幻觉发生的概率。 但是，需要指出的是，提示词工程实现的CoT 是大模型的一种涌现能力（Emergent Ability），在模型参数达到一定量级之前，若用同样的 Prompt，模型也只会生成“流畅但无逻辑”的废话。

b. Supervised Fine Tuning (SFT) ：逻辑模式的内化

如上所述，仅靠 Prompt 并不总是有效的，这对于中小规模的模型来说尤为突出。这就需要后训练微调的方式让逻辑推理显示的内化成为模型固有的能力。 通常通过如下两种方法实现：

• Rationale Augmentation： 通过在后训练数据中加入带有推理过程（Rationale）的文本进行监督微调（SFT）。

• STaR（Self-Taught Reasoner）^[6]： 这是一种迭代式有监督微调。模型生成多个理由，并以最终答案为判据，若正确，则将相对应的理由作为微调数据喂回给模型。模型在学会了这些逻辑后， 能解开更难的题，从而产生更多高质量的 CoT 数据，模型就在“自我产生数据 -> 结果验证 -> 自我学习”中不断进化。通过这种方式，模型“学会”了如何推理，而不仅仅是“模仿”Prompt 的格式。

c. Reinforcement Learning (RL): SFT之上

SFT的一个问题是需要有大量的标注过的文本样本。尽管通过STaR缓解了对标注样本的需求，但是，它的迭代周期长，计算需求高，微调效率低下，因此难以胜任大规模参数模型的CoT微调。所幸的是，以DeepSeek-R1-Zero/DeepSeek-R1为代表的RL技术路径证明了CoT可以在纯强化学习的不断试错中产生。具体来说，它通过Group Relative Policy Optimization (GRPO)，使用奖励函数对每个推理路径进行打分，计算推理回答的相对优势，并根据这个相对优势来更新模型参数。这避免了传统RL中使用的Critic 模型所带来的额外显存开销和评分不稳定问题。 这里训练的是CoT的“神”，但要使CoT能够以一定的格式和一致的语感呈现出来（即CoT的“形”），还需要用 RL 训练好的模型生成大量数据，筛选出其中逻辑最完美、答案最正确的数据（几十万条），对模型进行一次大规模 SFT。

需要指出的是，即便在实现了CoT逻辑内化后，模型还是需要有提示词来激活这部分能力。因此，在CoT模式下，大模型推理CPU和GPU上的工作分工如下图所示。CPU主要负责预处理和后处理，其中前者包含了Prompt Templating， Tokenization 和相关KV Cache的查找等主要步骤，而后者包含了Detokenization 和格式化。这里Tokenization负责将包括Prompt Template和实际Query在内的整个文字序列转换成Token ID序列；而接下去的KV Cache 查找则是将Token 序列分块（比如16个词分块）进行哈希，并据此在Radix Tree查找匹配的哈希值，若找到了就继续在树的下一层看是否能匹配接下去一个分块的哈希， 否则查找结束。此时，CPU 获取了从开头到第 N 个Token块对应的KV Cache所在的地址，可让GPU直接读取，而剩下的部分，则需要现场计算（Prefill）。

图 2. CoT 模式下的CPU-GPU交互模式

虽然 CoT 开启了推理的大门，但离构建真正的 AI智能体，它还存在几个关键缺陷，需要其他技术来补齐：

• 错误传播与幻觉（Error Propagation）：如果思维链的第一步算错了（例如 1+1=3），模型会基于这个错误的中间结果极其自信地推导出后面的荒谬结论，即CoT 内部没有“事实核查”机制。大模型虽然有强大的推理逻辑，但其内部记忆是“冻结”的，且依然会产生幻觉。

• 缺乏外部反馈（Closed-loop Gap）：CoT 是“闭门造车”，而在智能体场景下，环境是动态的。例子： 一个修代码的智能体（SWE-Agent）光靠自言自语形成的CoT并无很大用处，它必须尝试运行代码，看到报错信息，再根据报错修正思维链；光有 CoT 无法实现这种“思考-行动-感知”的闭环。

如果说 CoT 是智能体的“推理引擎”，那么 RAG（Retrieval Augmented Generation）就是它获取“外部知识库”的途径。两者结合解决了 CoT 无法独自解决的三个问题：

• 逻辑与事实的解耦（Logic vs. Fact）：RAG 负责提供实际证据。它让模型从“凭空脑补”转向“根据材料作答”，解决了知识过时和不可靠推理的问题。

• 克服“思维孤岛” (Self-Correction via Feedback) ：模型先思考，发现缺信息，立刻去RAG检索，拿到结果后再修正思维。这种“思考 -> 观察反馈 -> 调整思考”的闭环，是单纯靠增加 Prompt 步数实现不了的，它也是 ReAct 框架的核心。

• 性能与成本的权衡：CoT 属于Test Time Scaling，会消耗大量的推理 Token，增加延迟。如果某些知识可以通过 RAG 直接精准命中，就不需要模型进行复杂的长链条推理。RAG 可以通过低成本的传统检索减轻大模型昂贵的逻辑负担。

图3. RAG工作流程

RAG 工作流程如上图所示，其核心流程是依据Query，从数据库查询和获取与该Query相关的信息，并将这部分信息作为上下文和Prompt和Query一起输入给大模型。 由于数据库中的相关信息更为及时准确，大模型给出的回答也就避免了知识过时的问题变得更加准确可靠。 这里，最关键的就是如何获取与Query相关的信息，而RAG通过以下三个步骤来实现：

1. 文本向量化（Embedding）：模型使用一个特定的神经网络（Encoder）将一段文本 T 映射为一个高维实数向量（比如，768 或1536维）。在这个高维空间，语义相似的文本在几何距离上也更接近。

2. 相似度度量（Similarity Metrics）：RAG对应的数据库为向量数据库，它通过计算查询向量 Q（Query）与库中向量 D（Document）之间的几何关系来判定相关性。最常用的两种数学度量是：

• 余弦相似度（Cosine Similarity）：它衡量的是两个向量在方向上的夹角。在语义搜索中，向量的方向比长度（文本长短）更能代表含义。

• 欧几里得距离（L2 Distance）：, 衡量两点之间的绝对空间距离。

3. 最近邻搜索：在 RAG 系统中，我们需要从数百万个向量中找出与Query向量最接近的T个。如何找到这些向量呢？最简单的就是采用精确最近邻搜索算法，暴力计算Query向量与每个向量的距离，但显然会带来严重的 CPU 瓶颈。 为了提升搜索效率，通常采用ANN (Approximate Nearest Neighbor) 算法，比如，使用 K-means 聚类将空间划分为不同的区域，查询时计算Query向量与K个中心点之间的距离，选取离得最近的若干个簇，然后再精细化计算Query向量与这些簇内每个向量的距离，选取距离最小的T个返回。

在传统RAG模式下，大模型推理CPU和GPU上的工作分工如下图所示，即在CPU的预处理中，还加入了RAG部分。该部分还包含了Query的Embedding计算，向量数据库查询，信息读取和格式化等操作。 传统RAG模式遵循的是 “检索 -> 阅读” 的线性流程，在这个过程中，模型本身并没有通过推理来决策是否进行检索的这个动作；它是系统预设好的，模型只是一个被动的“资料总结者”，没有“决定去检索”的过程。

图4. 在传统RAG模式下的 CPU-GPU交互模式

与传统RAG相对应的是智能体RAG。在这里，检索动作是由模型的CoT驱动的，模型自主决定何时检索、检索什么、以及如何根据检索结果修正自己的思维。它所遵循的是一个典型的ReAct 流程，比如：

1. Thought (CoT)： “我知道 A，但我不知道 B 是谁，我需要去搜一下。”

2. Action： 调用RAG搜索B。

3. Observation： 看到检索回来的 RAG 片段。

4. Thought (CoT)： “根据刚才搜到的资料，B 原来是 C 的学生，现在我可以回答了。”

在这样一套“思考-行动-感知”流程中，CPU与GPU的交互如下图所示。CPU更加积极的参与到模型的决策链条中，承担起不适合GPU操作的向量数据库查询操作。智能体RAG只是智能体应用的一个例子；可以想象，在一个更为通用的智能体应用设定中，RAG可能被替代为代码编译，Web搜索，Python解析和执行等等。CPU成了智能体与环境交互的一个关键渠道。

图5. 在智能体RAG模式下的 CPU-GPU交互模式

26年年初，DeepSeek 提出了一种条件记忆模块 Engram^[2]，它通过现代化经典 N-gram 嵌入，利用确定性哈希实现静态模式的 O(1) 常数时间查找，并结合上下文感知门控将检索到的静态记忆与动态隐藏状态融合，解决了传统 Transformer中 缺乏原生知识查找，被迫通过昂贵计算低效模拟知识检索的问题。

那么，它与Agentic AI有关系吗？ 有！通过将静态知识存储与动态推理计算分离，Engram有效减轻了大模型早期层的重建负担。也就是说，本来用来从FFN中提炼/重构静态知识的推理步骤直接被哈希表查询替代，减少“知识重构”带来的幻觉。

这样大模型的“有效推理深度”增加了，可以更加高效的进行逻辑推理，这也意味着 Agent 可以把有限的计算层数全部用在复杂的逻辑规划上，而不是浪费在回忆基础事实上。另一方面，在引入 Engram 后，模型在“大海捞针（NIAH）”测试中的得分从 84.2 提升到了 97.0 ^[2]。这让 Agent 在处理复杂任务流时，不容易“忘记”之前的关键细节。这种长上下文处理能力对于那些需要处理超长对话历史或庞大代码库的Agent来说至关重要。

某种程度上来说，Engram有点像RAG，它一定程度上是RAG的内化，但它们也有显著的不同，如下表所列。 两者相辅相成，不能取代彼此。

除了对模型本身推理能力的提升以外， Engram对推理硬件的架构也带来了深远的影响。Engram 的特性允许它将庞大的静态知识表存放在主机内存中，而在 GPU 执行推理时异步预取（比如，GPU推理第5层时，CPU开始查找第12层所需的信息，CPU查找延时几乎被GPU 5-12层推理延时完全隐藏）。这意味着我们可以给 Agent 挂载一个上百GB 甚至更大 的知识库，却几乎不占用昂贵的 GPU 显存，也不显著增加延迟。这为AI智能体的普及提供了一条极具成本效益的路径。在有了Engram之后， CPU-GPU之间的交互模式如下图所示。 和之前的交互模式的一个显著区别是， CPU在GPU做推理的过程不再闲置而是参与其中：CPU不再局限于预处理和后处理， 其整体的利用率显著提升。

图6. 在CoT+RAG+Engram 推理下的 CPU-GPU交互模式

综上，我们可以看到Agentic AI的诞生不是一蹴而就的，而是随着大模型分步逻辑推理能力的提升而逐步演进的（这也解释了为什么Agentic AI在LLM爆发几年后，才逐步进入人们的视野）。从CoT Prompting到基于ReAct的RAG再到Engram，其本质上在解决一个核心问题：如何降低大模型幻觉，进一步高效地提升大模型的逻辑推理能力。这里，获取Ground-Truth的知识，及时的信息以及来自模型外部真实的反馈是解决该问题的关键。比如，CoT在HotpotQA中因内部知识错误导致56%幻觉率^[1]，而ReAct通过外部检索将幻觉率压至6%。而所有这些方案都有赖于CPU计算，并且CPU的参与程度在不断提升。 这还只是模型演进层面， 如果我们把智能体的工具调用，代码执行等任务执行时间也算上，CPU侧的延时甚至会成为影响系统性能的关键，比如，在SWE-Agent中，CPU执行的Bash/Python调用占延迟可达 78.7%^[3]。换句话说，智能体实质是一个对GPU和CPU同步施压的混合型负载。过去我们对大模型的优化都聚焦在GPU上， 而在智能体时代，我们更需要关注CPU以及CPU-GPU协同优化上，具体来说大概有如下几个方面：

当智能体RAG成为标配，LLM从文本生成向重型检索与数据管理转型，CPU 必须具备处理大规模的知识提取能力：一方面，为了降低单个 RAG任务的响应时间，CPU 需要在大量文档中进行高速向量比对、排序（Reranking）和上下文压缩（Context Compression）；另一方面，对于智能体Serving的场景， 会存在多个RAG任务同时执行的情况。 这些都要求 CPU 不仅仅具有很高的单核性能，还需要具备极高的多线程并发能力。

Agentic AI 需要调用各类工具，比如，Python 解释器、运行 Shell 脚本、执行 SQL 查询或调用 Web API。这些工具所对应的进程一旦启动，通常都需要保持一段时间，以避免每次工具调用所带来的进程冷启动开销。这也意味着系统需要维护大量活跃的进程上下文。与此同时， 每个工具进程对CPU的资源需求是不同的。如何在众多活跃进程间调配资源，尤其是在CPU还需要承担RAG甚至Engram查询的情况下，确保各自运行的SLA/Fairness亦或是整个系统的吞吐量最大化，是Host侧所面临的另一个迫切的问题。

Engram 架构彻底改变了模型参数的存放方式，它允许将庞大的静态知识表存放在 Host DRAM（系统内存） 中。CPU 必须在 GPU 运算的同时，利用确定性的哈希算法进行预取。这就需要Host具有庞大的DDR内存容量和带宽。同时，CPU还需要通过PCIe总线与GPU进行数据交换，确保在GPU执行相关逻辑层之前，所需的知识向量已经从内存搬运到了显存。这些并不是新问题，但却盘活了一些一度被认为与LLM不怎么相关的CPU侧互连技术，比如CXL。

因此，CPU价值的回归并非孤立存在，它重度依赖于以CXL为核心的通用互连技术，因为 Agentic AI 对存储和内存的要求已经跨越了单机界限。没有CXL带来的内存池化与一致性互连，CPU将空有大脑而无血脉，无法支撑起 Agentic AI 所需的“通算超节点”架构。

首先，利用CXL Memory Expansion来扩展数百GB的内存可以在不增加DDR通道（进而减少CPU Pin脚数压力）的前提下提升系统内存带宽和内存容量，其次，CXL还可以连接SCM/HBF/SSD等Persistent存储介质，与CXL Memory一起为Engram打造一个分层的高效的存储空间。同时，我们还可以探索将CPU与GPU之间的PCIe互连替换成CXL（或者轻量化的CXL），实现CPU与GPU内存间的Unified Memory，就像采用NVLink-C2C那样，从而提升CPU-GPU间数据搬移的效率。总之，这些技术在传统的大模型应用场景下可能显得鸡肋，但在Agentic时代却是竞争力的来源。

上述是从数据中心提供集中式推理服务的视角来看的。未来AI智能体很可能是云端协同的：端侧部署一个中小规模的模型，负责理解用户需求，并对日常任务进行本地化处理， 而对于那些复杂任务，则由本地模型通过调用数据中心大模型，来指导任务拆解。那么，从端侧视角来看，CPU已经事实上回归到了中心位置，就像OpenClaw运行在Mac Mini上那样。

从OpenClaw的火爆出圈到千问订单流量挤爆线下奶茶店，一个迟来的Agentic AI时代正在迎面扑来。表面上看，这是商业模式的探索，或是流量入口的争夺，但这背后是大模型分步逻辑推演的成熟以及计算范式的再次迁移：从绝对的GPU主导，回归到CPU-GPU协同。在此进程中，CPU不再是只负责预处理和后处理的沉默的搬运工，而是决策环路中的重要节点。这需要我们重新审视在新场景下的CPU在涵盖算法-系统-硬件多个层次上的优化：

• 算法层：比如，优化RAG及Engram查询、静态知识处理、工具调用，提升其在CPU上的运行效率；

• 系统层：比如，优化CPU-GPU交互，尽可能实现计算-通信-检索的Overlapping；

• 硬件层：比如，利用CPU大内存带宽优势，设计分层存储策略（DRAM→SCM→HBF/SSD）；利用硬件加速单元卸载部分CPU负荷。

这里可能有部分是新瓶装旧酒，但反映的却是在Agentic AI这类应用特性引导下的CPU算力价值的回归，以及CPU与GPU协同并进的系统思维。这何尝不是一种Molt呢？