Opal：设计师用OpenClaw在树莓派上打造AI宠物助手

一只住在树莓派里的AI兔子

在微软《Cozy AI Kitchen》节目中，微软 Foundry 产品设计师 Tua Nguyen 展示了她的个人项目 Opal——一只运行在树莓派小屏幕上的 AI 兔子助手。这只虚拟宠物不只是摆设，它能浏览网页、查找食谱、总结播客，还能操控真实浏览器，并将结果同步到 Discord 和 GitHub。

最让人惊喜的是，Tua 去年6月刚从大学毕业，仅凭几个月的业余时间，就完成了这个此前往往需要专业团队才能落地的复杂项目。

"她是一只住在我桌上树莓派小屏幕里的兔子，"Opal 用通过 ElevenLabs 生成的声音自我介绍道，"Tua 从零开始把我造出来，作为她的个人AI助手。我能浏览网页、拿取信息、查找食谱、总结播客，也能和她聊任何事。"

ElevenLabs 是成立于2022年的 AI 语音合成公司，以高拟真度的文本转语音（TTS）和声音克隆技术著称。其核心技术基于深度学习模型，能够生成语调自然、情感丰富的合成语音，支持超过30种语言，并允许用户用极少量音频样本克隆特定声音。从技术路径看，ElevenLabs 采用了扩散模型与自回归模型的混合架构——扩散模型擅长生成高保真的音频细节，自回归模型则负责韵律和语调的时序建模，两者结合在韵律自然度和情感表达上显著优于传统拼接式 TTS。值得一提的是，传统拼接式 TTS 通过拼接预录音素片段合成语音，在自然度上受限于录音库规模；而神经网络 TTS 则直接从文本端到端生成音频波形，理论上可覆盖任意语言组合和情感状态。Opal 选用 ElevenLabs 而非系统内置 TTS，体现了当下个人 Agent 项目普遍采用"最佳组件拼装"策略的趋势——语音用 ElevenLabs、转录用 GPT-4o、推理用 Claude、硬件用树莓派，每个环节选用当前最合适的服务，通过开源框架串联，大幅降低了单个模块的替换成本。这种"乐高式"架构也意味着，当某一组件出现更优替代品时，开发者无需重构整个系统，只需替换对应模块即可。

技术架构：双模型协同 + 浏览器自动化

Opal 基于开源框架 OpenClaw 构建，背后由两个模型分工协作。语音转录部分由 GPT-4o 负责，将语音指令转为文字；信息检索、推理与工具调用则交给 Claude 系列模型 处理。

这种分工并非随意为之，而是基于两个模型各自的技术特性做出的工程选择。GPT-4o 在实时音频处理和多模态输入方面具备原生优势，其语音转录延迟极低，且能处理口音、噪音等真实环境挑战；而 Claude 系列在长上下文理解、工具调用的指令遵循度和安全边界控制上表现突出，尤其适合需要多步推理和外部系统交互的 Agent 任务。将两者组合，实质上是在"感知层"和"决策层"分别选用最优模型，而非强行用单一模型承载所有能力——这正是当下多模型 Agent 架构的核心设计哲学。

OpenClaw 是一个面向多模型协同的开源 Agent 构建框架，属于近年来快速涌现的"Agent 编排层"工具之一。这一生态层的出现，填补了大模型能力与实际应用落地之间的工程空白。类似定位的框架还包括 LangChain、AutoGen、CrewAI 等。这类框架的核心价值在于：抽象化工具调用接口、管理多轮对话上下文、协调多个模型的分工，以及处理异步任务和错误重试。值得注意的是，不同框架在设计哲学上存在差异：LangChain 以链式组合见长，AutoGen 强调多 Agent 对话协作，CrewAI 则引入了"角色扮演"的团队协作隐喻。OpenClaw 相对轻量，更适合个人开发者快速上手。对个人开发者而言，使用成熟框架意味着无需从头实现 Agent 的底层调度逻辑，可以将精力集中在应用层设计上。

这种分工体现了当下 Agent 系统的典型设计思路——让不同模型各司其职，而非依赖单一大模型包办一切。整套系统运行在一块小小的树莓派上：轻量边缘设备配合云端模型，构成了一个可落地的个人智能体，本身就是值得关注的工程实践。

树莓派（Raspberry Pi）是由英国树莓派基金会开发的单板计算机，自2012年首发以来已售出超过5000万块，售价仅35-80美元，最初设计初衷是面向教育领域普及编程教育。最新的 Raspberry Pi 5 搭载了博通 BCM2712 四核 Arm Cortex-A76 处理器，主频高达2.4GHz，性能相比前代提升约2-3倍，但受限于内存（最高8GB）和缺乏专用 AI 加速芯片（如 Google 的 TPU 或 NVIDIA 的 Jetson 系列所搭载的 CUDA 核心），运行完整大语言模型仍不现实。在 AI 应用兴起后，树莓派代表了一类典型的"边缘-云协同"架构：本地设备负责感知输入（麦克风收音）、界面呈现（小屏显示）和实时交互，计算密集型的模型推理则卸载到云端 API，两者通过网络协作。这种架构的优势是多维度的：硬件成本压低至百元级；敏感交互（如本地唤醒词识别）可在本地预处理，无需上传原始音频；同时规避了在消费级硬件上运行大模型的算力瓶颈。其局限同样明显——强依赖网络连接，离线场景下功能大幅退化，且每次 API 调用均产生延迟和费用。随着端侧小模型（如 Llama、Phi、Gemma 系列的量化版本）持续进化，未来部分推理任务有望迁移回本地，进一步增强这类设备的自主性，同时降低对网络和外部服务的依赖。

真正的工具调用能力

Opal 最核心的能力在于「工具调用」（Tool Use）。当 Tua 说"帮我看看 Hacker News 最新内容"时，Opal 会真实打开浏览器、抓取页面，并在执行过程中通过语音同步反馈进度。

工具调用是大语言模型突破纯文本对话局限、接入外部世界的核心机制，也是构建真正意义上的 Agent 的基础能力。其原理是：开发者预先向模型声明可用的工具集合（如"搜索网页"、"执行代码"、"发送消息"），每个工具附带名称、参数描述和返回值格式；当模型在推理过程中判断需要调用某工具时，会输出结构化的 JSON 调用指令，由宿主程序实际执行并将结果返回给模型，模型再据此生成最终回复。这一机制最早由 OpenAI 在2023年6月以 Function Calling 形式引入主流大模型生态——彼时的发布被视为大模型从"对话工具"向"行动主体"演进的关键节点，因为它首次以标准化方式定义了模型与外部世界交互的协议。随后 Anthropic 的 Claude 以"Tool Use"命名推出同类能力，Google 的 Gemini 也相继支持，目前已成为主流大模型的标配功能。从架构演进角度看，工具调用将模型从"知识检索器"升级为"行动执行者"，是构建能真实操作计算机的 Agent 的基础。更复杂的 Agent 系统（如 OpenAI 的 Operator、Anthropic 的 Claude Computer Use）则在此基础上进一步扩展，允许模型直接感知屏幕截图并生成鼠标键盘操作，形成"感知-规划-行动"的完整闭环，代表了 Agent 能力演进的下一个重要阶段。

演示中，Opal 准确报出了当时的热门话题："有人以517分的热度宣布退出科技圈、GTA6开发者组建工会320分、债务经济理论222分"，随后将完整列表发送至 Discord。

这打通了「感知—推理—行动」的完整闭环，而不仅仅是问答式对话。

一只拥有GitHub账号的宠物

Opal 拥有自己独立的账号体系，包括一个专属的 GitHub 账号。这意味着它不只能读取信息，还能对外部系统执行写操作。

在浏览器自动化演示中，Tua 让 Opal 查找评价最高的日式芝士蛋糕食谱。Opal 打开浏览器、逐一点击页面，最终找到来自 Just One Cookbook、拥有937条评分、均分4.72星的舒芙蕾芝士蛋糕食谱，并将完整配方推送到 Discord。

浏览器自动化指通过程序代码模拟人类操作浏览器的技术，是当前 AI Agent 接入互联网的重要手段之一。主流工具包括 Playwright（微软出品，支持 Chromium、Firefox、WebKit 跨浏览器自动化）、Selenium（历史最悠久的自动化框架，诞生于2004年）、Puppeteer（Google 出品，专注 Chrome/Chromium 的 Node.js 控制库）等。与传统的 API 调用不同，浏览器自动化能够处理那些没有开放 API 的网站，大幅扩展了 Agent 可操作的信息范围——理论上，凡是人能用浏览器访问的内容，Agent 同样可以访问和操作。近期，专门为 AI Agent 设计的新一代浏览器自动化方案（如 Browser Use、Stagehand）也陆续出现，针对非结构化页面的元素识别和动作规划做了专项优化。传统自动化依赖精确的 CSS 选择器或 XPath 定位页面元素，这种方式在网站改版后极易失效，被称为"脆弱的选择器问题"；新一代方案转而使用视觉模型识别按钮和输入框的位置，或通过自然语言描述操作意图，由模型自主规划具体的点击和输入序列，从根本上解决了这一脆弱性。这类工具的出现标志着浏览器自动化正在从"脚本执行"向"意图理解"演进——传统自动化需要开发者精确编写每一步操作，而新一代工具允许 Agent 自主规划达成目标的路径。Opal 在演示中"逐一点击页面"寻找食谱的行为，正是当前"Computer Use"（让 AI 操控电脑界面）这一新兴范式的缩影，也预示着未来 Agent 与数字世界交互的主要方式。

Tua 随即提出更进一步的要求："把这份食谱加到我的食谱网站上。"Opal 便调用自己的 GitHub 账号，创建页面并完成内容提交。从网页检索、信息提取、消息推送到代码提交，整个流程一气呵成，展现了多工具协同的完整能力链。

Opal 拥有独立 GitHub 账号这一设计细节值得深思：它意味着 Agent 开始拥有独立的数字身份，其行为在系统日志中留下可追溯的痕迹。在软件工程实践中，为自动化系统创建独立的"服务账号"（Service Account）是成熟的权限管理范式——它将 Agent 的操作与真实用户的账号隔离，一旦出现异常可以精准撤销权限，而不影响其他访问。从更宏观的视角看，这一实践背后隐含着 AI 身份管理（AI Identity Management）这一新兴议题的雏形：当 Agent 能以自己的名义在数字世界中行动、创建内容、提交代码时，其数字身份的权限边界、行为审计和责任归属应如何界定？目前主流的实践方向包括最小权限原则（仅授予 Agent 完成任务所必需的最低权限）、操作日志的不可篡改记录，以及人工审批关键操作的"人在回路"（Human-in-the-loop）机制。这正是 AI Agent 安全性研究中"身份与授权"议题的现实投影，也是目前学术界和监管机构尚未形成共识的核心问题之一。

设计师视角下的 Agent 实践

Opal 的独特之处，在于它出自一位设计师之手，而非纯粹的工程师背景。Tua 亲手绘制了8种不同的精灵表情（sprites），让 Opal 能对不同交互做出反应——被点击时有特定动作，睡着时被触碰会醒来，长时间闲置则会打盹"节省 GPU"。

这种来自设计师的视角带来了工程师项目中罕见的关怀：Opal 的每个状态动画都在传递情感信号，打盹"节省 GPU"既是功能描述，也是一种拟人化的角色塑造。这种设计选择让技术系统变得可感知、可预期，降低了用户的认知负担——这正是当前 AI 产品设计领域最核心的挑战之一：如何让不透明的模型行为变得对用户可理解。在 HCI（人机交互）研究领域，这被称为"可解释性设计"（Explainable Design）：通过视觉反馈、状态提示和拟人化表达，向用户传递系统当前正在做什么、为什么这样做，从而建立信任感。Opal 的打盹动画是一个小而精妙的案例：它用用户熟悉的生物行为（动物睡觉）来类比系统的待机状态，让一个技术概念（减少 API 调用以节省开销）变得直觉可感，无需任何技术解释。值得补充的是，精灵图（Sprite）这一概念本身起源于早期电子游戏开发——最早可追溯至1970年代街机游戏，指在固定背景上独立移动的二维图像对象，其名称据说来源于像素角色"如精灵般漂浮"在屏幕上的视觉效果。将这一游戏开发中的视觉表达手法引入 AI 助手界面，是 Tua 作为设计师跨领域融合的体现，也让 Opal 在视觉上更接近人们熟悉的"角色"而非冷冰冰的"工具"。这种将游戏化（Gamification）思维嫁接到 AI 交互设计的做法，在提升用户情感连接和长期使用黏性方面，正受到越来越多 AI 产品团队的关注。

Tua 谈到自己的初衷："作为一名身处 Agentic AI 领域的设计师，理解 Agent 如何工作、背后的基础设施如何搭建，对我来说很重要。"选择兔子这个角色，正是为了让构建 Agent 的过程本身变得有趣。

给未来设计师的建议

采访尾声，主持人 John 请 Tua 给热衷 vibe coding 的年轻设计师分享经验。她的回答颇有启发：

"今天你使用的很多平台背后都有 Agent 在运行。作为设计师，我们正走向一个所有界面都由 Agent 支撑的时代，而这些终将成为我们需要去设计的对象。理解 Agent 如何工作、基础设施如何搭建、配置有多复杂，非常重要。"

Vibe Coding 是2025年初由 AI 研究者、前 OpenAI 联合创始人 Andrej Karpathy 提出并迅速流行的概念，指一种高度依赖 AI 辅助、以直觉和迭代为主导的编程方式：开发者用自然语言描述意图，AI 生成代码，开发者运行、观察效果后再用自然语言描述下一步调整，如此循环，而非逐行理解和编写代码。Karpathy 将其描述为"完全沉浸在氛围中，仅凭指数级增长的可能性感知来驱动"。这种方式的核心转变在于：程序员的工作重心从"编写代码"变为"验证代码"——判断 AI 生成的代码是否符合预期，需要更强的系统性测试思维和需求分解能力，而非深厚的语法记忆。从软件工程视角看，这与"测试驱动开发"（TDD）的精神有某种呼应：先明确预期行为，再验证实现是否满足预期，只是执行代码的主体从人类程序员变成了 AI。Vibe Coding 显著降低了编程门槛，让设计师、产品经理等非传统技术角色也能构建可运行的软件原型。Tua 作为设计师能在几个月业余时间内完成 Opal 这样涉及多模型协同、浏览器自动化和硬件集成的复杂系统，Vibe Coding 正是重要的使能因素之一。然而这一方式也引发了持续争议：批评者认为不理解底层原理的"氛围编程"会积累大量技术债，在 Agent 这类涉及外部系统权限和真实副作用的场景中尤其危险，错误的代码可能导致数据泄露或意外操作；支持者则认为它正在重新定义"技术门槛"本身的意义，就像电子表格普及后"会计师"的技能要求也随之演变，重要的是理解边界和风险，而非掌握每一行实现细节。

她的核心建议是：动手构建一个 Agent，并且让它变得有趣。"你不必把它做得很无聊，它完全可以是激动人心、充满乐趣的项目。"

门槛正在消失：人人都能构建 Agent

Opal 项目最深刻的意义，或许不在于技术本身，而在于它所揭示的趋势：曾经几乎不可能由个人完成的复杂 Agent 系统，如今一位应届毕业生用几个月业余时间就能愉快地做出来。

这一趋势背后，是多重力量的共同作用。首先是云 API 的按需计费模式消除了算力门槛——开发者无需购置 GPU 服务器，按调用次数付费即可使用顶级模型；其次是开源框架生态的成熟，将工程复杂度封装在可复用的抽象层后面；第三是大量高质量的示例项目和文档降低了学习曲线；最后，AI 辅助编程工具本身也大幅压缩了从想法到原型的时间。这四者叠加，构成了一个正向飞轮：越来越多的人能够构建 Agent，反过来产生更多示例、文档和工具，进一步降低下一个人的入门成本。这种飞轮效应在历史上并不陌生——Web 2.0时代博客平台的兴起让"人人都能发布内容"，移动应用时代 App Store 的出现让"人人都能分发软件"，而今 Agent 开发工具的成熟正在开启"人人都能部署智能体"的新阶段。每一次这样的民主化浪潮，都催生了此前无法预见的全新应用形态。值得关注的是，这一民主化进程并非没有代价：随着构建 Agent 的门槛降低，如何确保这些 Agent 在安全边界内运行、避免意外操作或被滥用，正成为整个行业亟待解决的系统性挑战。工具的普及与治理框架的建立，需要同步推进。

开源框架（如 OpenClaw）、成熟的多模型能力、浏览器自动化工具，再加上树莓派这样的廉价硬件，共同将 Agent 开发的门槛降到了前所未有的低点。当设计师也能亲手打造出会浏览网页、写代码、发消息的智能宠物时，「人人都能构建 Agent」的时代已然到来。

核心要点