来源、许可与阅读说明

• 原文：docs/cn/build/chapter10/index.md
• 来源：datawhalechina/hello-claw；固定提交：adcfc5ee72ff
• 署名：Datawhale 社区 Hello Claw 项目及固定版本记录的全体贡献者；本站为独立的非商业学习编排，不代表 Datawhale、OpenClaw 或文中第三方对本站的合作、认证或背书。
• 许可证据：固定提交的 README 明确声明 CC BY-NC-SA 4.0 并链接官方协议，但该提交没有独立 LICENSE/COPYING 文件；本站依该声明进行署名、非商业、相同方式共享。
• 适配范围：移除 VitePress 导航元数据，将折叠块与少量 HTML 转为安全 Markdown，并把图片、跨章链接固定到该提交；不改变原文的技术论述顺序。本站新增来源说明同样按 CC BY-NC-SA 4.0 提供。
• 时效与安全：模型、价格、命令、平台能力和第三方服务可能变化；涉及密钥、远程访问、自动执行或生产部署时，请先查阅最新官方文档并在隔离环境验证。
• 授权、更正或删除请求请通过本站首页公开联系方式提出，收到有效请求后先下架再核查。

第十章 硬件方案——让 Agent 跑在「虾」上

核心问题：如果 Agent 可以跑在 10 美元的硬件上，它会打开什么新的可能性？

1 从「机房」到「口袋」

1.1 Agent 的「瘦身」之路

回想一下前几章的内容：

• OpenClaw：通常配桌面级设备或云服务器
• NanoClaw：可以跑在普通 Linux 服务器或 SBC 上
• ZeroClaw：面向极低资源占用的硬件部署
• IronClaw：面向企业场景的安全加固，需要 PostgreSQL

它们都在做一件事：让 Agent 更轻、更便宜、更容易部署。

但 PicoClaw 走到了极致——它让 Agent 跑在了「虾」上。

1.2 为什么是「虾」？

PicoClaw 的名字来源于「皮皮虾」（Pippi Shrimp），吉祥物也是一只虾。这个名字很形象：

• 虾很小：README 的 headline 是 <10MB，但最近的上游说明也提醒，近期构建可能在 10-20MB RAM 区间
• 虾很便宜：目标是跑在 10 美元级硬件上
• 虾很灵活：支持多种架构（ARM、RISC-V、MIPS、x86）

1.3 $10 硬件是什么概念？

$10 能买到什么？

• 一杯星巴克咖啡
• 一个月的 Netflix 订阅
• 或者……一个能运行 AI Agent 的完整计算机

PicoClaw 可以在 LicheeRV-Nano 上运行——常见版本大约在 $10-13 区间，尺寸比信用卡还小，但足以运行 Linux 和 PicoClaw。

让我们对比一下：

低单位数瓦的功耗意味着什么？

以 10000mAh 充电宝为例，如果板卡和负载都比较克制，续航大致可以按半天量级去估算。这种量级已经足以支撑“随身带着跑”的原型验证。

注意：功耗数据为理论估算值，基于 LicheeRV-Nano 硬件规格和 PicoClaw 软件资源占用计算，实际续航取决于具体工作负载和使用环境。
* PicoClaw README 仍保留 <10MB 的项目 headline，但也明确提示：近期构建可能在 10-20MB RAM 区间。

2 PicoClaw：为硬件而生的 Agent

2.1 项目背景

PicoClaw 由 Sipeed（矽速科技） 开发——这是一家知名的开源硬件公司，专注于 RISC-V 和 ARM 架构的嵌入式开发板。

有趣的是，项目方称 PicoClaw 的核心代码里大约 95% 是由 AI Agent 生成的。按 PicoClaw README 的说法，这套 Go 代码是从零写起的，只是在架构思路上参考了 NanoBot 等更早的 Agent 项目，而不是逐行 fork 或重写某个现成仓库。

说明："95% 代码由 AI 生成" 为项目方（Sipeed）的声明，详见 PicoClaw 官方 README。

这本身就是 Agent 编程的一个典型案例：

• AI 生成（按项目方说法）：大约 95% 的代码由 Agent 编写
• 人类审核：关键逻辑和安全检查由人工确认
• 持续优化：上游目前仍明确把它标成 pre-v1.0 阶段，不建议在这里把它直接写成生产就绪

2.2 极致的性能优化

PicoClaw 的数字非常惊人：

注意：启动时间和内存占用数据来自项目 README 或它引用的对比快照，更适合被理解成上游定位，而不是统一 benchmark；实际性能仍取决于硬件配置和工作负载。

亚秒级启动真正有意义的地方，不是追求一个漂亮数字，而是让设备更适合"唤醒 -> 执行 -> 再休眠"的工作节奏。README 和相关演示会强调这一点，但具体时间仍取决于时钟频率、存储介质和启用的服务。

2.3 架构设计：为什么选 Go？

PicoClaw 选择 Go 语言有几个关键原因：

① 编译成单个二进制文件

Go 可以交叉编译成静态链接的二进制文件，不依赖运行时。这使得部署极其简单——只需复制一个文件即可。

② 内存占用低

Go 的内存管理比 Python/JavaScript 更高效。PicoClaw 的设计目标是把常驻 RAM 压到十几 MB；按当前 README 的说明，近期构建可能在 10-20MB 左右，而不是所有版本都稳定低于 10MB。

③ 跨平台支持

Go 原生支持交叉编译到多种架构：

• x86_64（Intel/AMD）
• ARM64（树莓派、M1/M2 Mac）
• ARMv7（旧版树莓派）
• RISC-V（LicheeRV、HiFive 等）
• MIPS（路由器、嵌入式设备）

④ 并发模型

Go 的 goroutine 是轻量级线程，可以在有限的内存下支持大量并发任务。这对于需要同时处理多个请求的 Agent 很重要。

3 硬件选型：为什么低功耗架构更合适？

3.1 架构战争：x86 vs ARM vs RISC-V

在嵌入式领域，有三种主要的处理器架构：

x86（Intel/AMD）

• ✅ 性能强、生态成熟
• ❌ 功耗高、价格贵、发热大
• 适合：桌面电脑、服务器

ARM

• ✅ 功耗低、价格便宜、选择多
• ✅ 生态成熟（树莓派、手机、IoT）
• 适合：嵌入式、移动设备、IoT

RISC-V

• ✅ 开源、免授权费、可定制
• ⚠️ 生态较新，软件支持相对较少
• 适合：教育、研究、特定用途芯片

3.2 为什么 ARM 常被当作默认选择？

PicoClaw 支持所有三种架构。如果你追求最成熟的通用路线，ARM 往往是默认选择；如果你更在意成本、开放指令集或 Sipeed 的现成板卡，RISC-V 同样很有吸引力。原因如下：

① 生态成熟

树莓派已经卖出数千万台，围绕 ARM Linux 的软件生态非常丰富。你能想到的功能，基本上都有现成的方案。

② 性价比

$10-50 就能买到性能不错的低功耗开发板。对 ARM 阵营来说，树莓派 Zero 2W、Orange Pi Zero 等都很典型；如果你跟着 Sipeed 生态走，RISC-V 的 LicheeRV-Nano 也属于同一类思路。

③ 功耗控制

低功耗架构在合适板卡上常见于亚瓦到几瓦区间，更适合电池供电；x86 做到同级别通常更难，也更依赖散热和整机设计。

④ 社区支持

遇到问题很容易找到解决方案——因为太多人用 ARM 了。

3.3 PicoClaw 支持的硬件

PicoClaw 官方推荐的硬件：

入门级（约 $10）

• LicheeRV-Nano：RISC-V 板卡，常被 PicoClaw 用作低成本入门示例

KVM / 开发板档（几十到一百美元级）

• NanoKVM 家族：展示 PicoClaw 运行在紧凑远控板卡上的一类例子
• MaixCAM / MaixCAM2 一类设备：偏视觉与 maker 场景的板卡路线

手机级（废物利用）

• 部分 Android 设备：PicoClaw 文档里同时出现了 APK 路线和 Termux 路线
  • 自带屏幕、电池、网络
  • 更适合被理解成兼容路径，而不是“任何旧手机都稳跑”的承诺

4 功耗优化：让 Agent 跑在电池上

4.1 为什么功耗很重要？

想象一下这些场景：

在这些场景下，每毫瓦都很重要。

4.2 PicoClaw 的功耗优势

数字对比：

~3.5W 是如何做到的？

1. Go 语言高效：没有虚拟机开销，垃圾回收开销较小
2. 精简功能：只保留核心功能，去掉不必要的依赖
3. 事件驱动：没有任务时进入休眠，有事件时快速唤醒
4. 轻量级模型：支持本地小模型（如 TinyLlama），减少网络请求

4.3 实战：延长电池续航的技巧

如果你要让 PicoClaw 跑在电池上，可以考虑这些优化：

① 间歇运行

不需要 24/7 一直运行。可以设置定时唤醒（比如每 15 分钟检查一次），其他时间休眠。

② 降低 CPU 频率

大多数开发板允许你降低 CPU 频率。如果任务较轻，可以逐步下调频率换续航；具体能降到多少，要看板卡、模型大小和你能接受的响应延迟。

③ 关闭不必要的外设

• 不用 HDMI？关闭显卡输出
• 不用 USB？关闭 USB 控制器
• 不用 WiFi？用有线网络或间歇连接

④ 使用低功耗模式

Linux 有多种省电模式：

• powersave：始终最低频率
• ondemand：需要时提升频率
• conservative：缓慢提升频率

对于 Agent 场景，conservative 通常是最佳选择。

5 离线能力：没有网络的 Agent

5.1 为什么要离线？

你可能会问：现在的设备不都有网络吗？为什么要离线？

5.2 本地模型选项

PicoClaw 支持多种本地模型部署方案：

① Ollama

# 1) 拉一个足够小的本地模型
ollama pull tinyllama

# 2) 启动本地推理服务
ollama serve

# 3) 另开一个终端确认服务真的起来了
curl http://127.0.0.1:11434/api/tags

如果 api/tags 能返回模型列表，说明本地 Ollama 已经可达。接下来再把 PicoClaw 指向这个本地端点。

{
  "model_list": [
    {
      "model_name": "local-tinyllama",
      "model": "ollama/tinyllama",
      "api_base": "http://127.0.0.1:11434/v1"
    }
  ]
}

这是 PicoClaw README 当前采用的 OpenAI-compatible provider 配法：重点不是写一个 provider: ollama，而是把本地模型挂进 model_list，并把 api_base 指向 http://127.0.0.1:11434/v1。

建议按这个顺序做一次 smoke test：

• 先在设备本机完成 ollama pull 与 curl /api/tags
• 再启动 PicoClaw，确认日志里能看到成功连接本地模型端点
• 最后用一个离线可回答的小任务测试，例如“把这段文本压缩成三句话”

② llama.cpp

针对嵌入式设备优化的推理引擎，支持量化模型（4-bit、5-bit）。7B 量化模型约需 4GB 内存，1B 以下的小模型（如 TinyLlama）可在 1-2GB 内存的设备上运行（2-bit 量化可在 512MB 设备运行，但性能受限）。

③ vLLM

如果你已经转向更强的 Linux/GPU 机器，vLLM 能提供更高吞吐的推理服务；它更适合服务器级或桌面级部署，不应把它当作嵌入式板卡上的默认路线。

5.3 离线 Agent 的能力边界

本地模型很强，但也有局限：

✅ 本地模型擅长的：

• 文本生成、摘要
• 简单问答
• 代码补全
• 格式转换

❌ 本地模型不擅长的：

• 需要最新知识的任务（如「今天的新闻」）
• 复杂推理
• 多语言翻译（小模型质量较差）

混合方案：

PicoClaw 可以通过配置做成「本地优先」策略：

• 简单任务 → 本地模型处理
• 复杂任务 → 调用云端 API
• 无网络时 → 完全本地运行（功能降级）

6 小结：Agent 的「平民化」

PicoClaw 代表了 Agent 技术的一个新方向：极致的轻量化和低成本。

它证明了几件事：

1. Agent 不一定需要昂贵硬件 — 10 美元级设备也能跑一个范围收敛的 Agent 原型
2. 电池场景是可能的 — 单位数瓦级甚至更低的功耗，让便携式验证变得现实
3. 离线运行是可行的 — 本地小模型足以覆盖一部分基础任务

这对整个行业意味着什么？

对于开发者：你可以把 Agent 嵌入到以前不可能的场景——智能家居、可穿戴设备、机器人……

对于用户：AI 助手不再只能是「云端服务」，而是可以更接近你自己“拥有和运维”的软件。当你把模型、工具和数据都尽量本地化时，它确实能降低订阅和联网依赖，也能让更多数据留在设备侧；但具体的隐私与成本边界，仍取决于你的实际配置。

对于社会：AI 技术的民主化。不是只有大公司才能运行 AI，普通人也可以用 $10 的设备体验这项技术。

看到这里，前面几章关于"系统为什么这样设计"和"不同路线怎么取舍"的讨论，基本已经铺够了。下一步如果你真的想开始扩自己的能力面，最合适的切入口通常不是继续停留在概念层，而是先做一个能落地的小扩展。

所以接下来这一跳，会从"看系统"转到"开始扩系统"：

→ 实战章：Skill 编写：从最常用、门槛最低的定制入口开始，把一项新能力真正封装出来，并为后面的“龙虾大学”场景案例打基础。