使用AI编码代理构建开源树莓派机器人

我能否利用人工智能作为主要的软件开发接口，来构建一个完整的机器人?不仅仅是用AI实现自动补全，也不只是偶尔让它生成函数。我希望整个开发过程本身由提示和AI编程代理驱动。

PHOS正是这一实验的成果。它是一个基于树莓派构建的开源机器人，集成了计算机视觉、环境传感器、运动感知、表情眼睛、视觉反馈、基于网页的管理界面以及模块化的Python架构。

但在这所有功能之下，还有一个项目：

一项针对资源受限硬件的代理驱动型软件开发实验。

开发模式

我为PHOS采用的基本工作流程如下：

我先确定PHOS应执行的任务，然后向ChatGPT描述目标和约束条件。这个想法被转化为更详细的实施提示。Codex随后直接在代码仓库上工作，读取现有架构，实施修改，并运行相应的测试。重要的是，当代码编译完成后，整个过程并不会停止。PHOS 是一个物理系统。

最终，代码必须在真实的树莓派上运行。

为什么选择 PHOS?

PHOS 被设计为一个模块化的开源机器人平台。其理念是逐步为机器人提供多种感知、响应和与物理世界交流的方式。其主要组成部分包括：

•以树莓派作为主要计算平台

•树莓派摄像头

•计算机视觉

•环境传感器

•运动/姿态感知

•表情生动的动画眼睛

•RGB视觉反馈

•模块化Python服务

•基于浏览器的管理界面

与其一开始就尝试构建一个完整的机器人，我选择逐步添加功能。这使得PHOS成为机器人技术和人工智能辅助开发的实用测试平台。

为什么树莓派让AI实验变得有趣

当目标是普通的桌面或网页应用时，使用AI编程代理来开发软件相对简单。

该代理通常可以：

全部运行在同一台机器上。但PHOS不同。

我的开发环境在MacBook上，而实际应用程序运行在树莓派上。而树莓派是一种受限设备。

•CPU性能重要。

•内存大小重要。

•依赖项数量重要。

•摄像头分辨率重要。

•机器学习推理频率重要。

一个在开发者笔记本电脑上完美运行的解决方案，可能完全不适合目标硬件。

这意味着提示工程已成为系统工程的一部分。

将提示作为工程规范

对于PHOS，我很少给出Codex这样的指令，例如：

这会留下太多未决定的选项。相反，提示中包含架构和硬件方面的限制。例如，一个视觉实现的提示可以指定：

该提示还告诉代理哪些内容不得更改。

例如：

这已成为PHOS最重要的经验之一：代理所获得的边界越清晰，生成的实现就越有用。提示不再仅仅是代码请求，而逐渐演变为一种小型工程规范。

让PHOS“看见”

第一个主要子系统之一是Vision。其架构大致遵循以下流程：

摄像头捕捉功能由一个独立的提供程序负责，面部检测与系统其他部分相分离，表情推理则采用另一个可替换的提供程序。这使得后续可以更换实现方式，而无需重新设计整个机器人。首个实现方案有意保持轻量，因为它必须在树莓派上运行。例如，面部检测和表情分类无需以相机帧率的最高速度运行。摄像头预览可以运行得更快，而更耗时的处理任务则执行频率较低。此类优化必须直接体现在AI开发说明中。

观察不等于情绪

视觉子系统还有另一条重要规则：PHOS可以分析可见的面部特征，但不应声称了解一个人的内在情绪状态。它不应在内部表示：

PHOS可以表示更接近以下内容：

这一区别在向AI代理提供的开发说明中明确指出。我希望这类设计约束能在代码生成前就已存在，而非后期添加。此外，该系统默认避免人脸识别，并不会持久保存生物识别数据。

提升PHOS的环境意识

计算机视觉只是信息获取的一种方式。PHOS还通过传感器来观察周围环境。当前的传感器应用包括以下组件：

BME280

用于测量：

•温度

•湿度

•大气压力

CCS811

用于空气质量相关测量，例如：

•eCO₂

•TVOC

运动/方向感知

陀螺仪/惯性传感器可提供PHOS移动或位置的信息，从而为PHOS带来多个来自物理世界的信息来源。

概念上：

有趣的是，挑战并不在于简单地读取传感器数据。系统需要建立一致的抽象层，使得PHOS的其他部分无需直接依赖于各个硬件库。这一点同样需要编码代理在实现功能前先理解清楚。

显示机器人的状态

PHOS还需要向外传递信息的方式。其中一种机制是WS2812B RGB LED灯环，它能即时提供机器人状态的视觉反馈。例如，不同颜色或动画可以表示以下状态：

眼睛则提供了另一层通信手段。它们正逐渐成为PHOS最具辨识度的部分之一。我的目标是最终让这些眼睛能够整合起来：

•表达

•视觉注意力

•追踪

•机器人状态

•交互反馈

机器人不仅应接收信息，还应能够使自身状态变得可理解。

PHOS的网页界面

另一个正在开发的部分是基于浏览器的管理界面。其理念是提供一个集中位置，以便我能够查看和控制机器人。该界面将围绕以下区域进行组织：

仪表盘

PHOS的快速概览及其主要运行信息。

PHOS状态

有关机器人及其当前运行状态的详细信息。

控制

机器人行为的命令和配置。

传感器

来自环境和运动传感器的实时读数。

眼睛

视觉表达系统的控制。

这对正常运行和开发都非常重要。

在进行物理硬件实验时，能够从另一台计算机观察状态和传感器值极为有用。

PHOS 还具备 API 层

由多个独立子系统构成的机器人，需要一种方式让这些子系统与外部工具进行交互。

PHOS 的工作还包括面向 API 的接口，用于暴露机器人的状态、环境信息以及控制指令。

在开发和测试方面，该系统可以从多个层面进行访问：

预期的 API 接口示例包括机器人状态、环境信息和运动信息。

关键部分：让代理能够访问机器人

这正是人工智能辅助开发变得尤为有趣的地方。Codex 在我的开发机上的仓库中运行，但真正的硬件却位于别处。那么，代理如何验证其自身的实现呢?我正在尝试的解决方案很简单：

SSH。

树莓派已配置为通过密钥认证的方式，使开发机可以访问它。

概念上：

无需输入交互式密码。

这使得AI代理能够被远程指令执行命令。

例如：

但还有一个问题。

最新的代码存在于我的 MacBook 上。

树莓派在测试之前需要这个代码。

部署、测试、观察、重复

因此，工作流程的下一步是自动化的代码同步。一个脚本可以将当前的工作树传输到树莓派上。

例如：

然后，远程测试脚本可以执行所需的验证。最终的流程如下：

这是我发现PHOS中最有趣的部分之一。编码代理不再仅在IDE中运行，而是跨两台机器工作，并最终与实际硬件进行交互。

双层测试

我不希望每个测试都依赖于树莓派。那样会导致开发过程缓慢且脆弱。因此，PHOS试图将与硬件无关的逻辑与硬件适配器分开。例如，自动化测试可以使用：

而不是真正的硬件。这提供了两个互补的层次：

AI代理可以持续使用本地测试，只有在需要实际硬件验证时才转移到树莓派上。

API 与测试

该架构支持以编程方式暴露机器人状态和数据，测试内容包括浏览器/API 检查、对树莓派执行的命令以及硬件无关的自动化测试。

而且或许最重要的是：

AI辅助的开发工作流程

PHOS 正被用于优化一个可重复的过程，以实现以下目标：

路线图

该路线图不仅涉及增加更多机器人功能，更在于使整个开发工作流程变得越来越可复现。

1. 完善核心PHOS子系统

持续改进：

•幻想

•环境感知

•运动感知

•视觉反馈

•机器人状态管理

2. 扩展管理界面

将当前的网页界面转变为一个实用的控制与诊断环境。

目标是让用户无需直接连接到树莓派终端，即可了解PHOS正在执行的操作。

3. 提升实时交互能力

更紧密地连接感知、机器人状态与视觉行为。

例如：

4. 增强API功能

为外部应用程序及未来的PHOS组件创建清晰的接口。WebSocket风格的事件特别适合报告运动状态等变化，无需持续轮询。

5. 使硬件验证代理更友好

继续为以下任务编写脚本：

目标是让AI代理拥有安全、可重复的操作流程，而不是对树莓派的无限制访问。

6. 优化设备端AI性能

探索在资源受限的树莓派硬件上，哪些实用的AI工作负载能够实际运行。挑战不仅在于运行更大的模型，更在于找到以下方面的最佳平衡：

本文编译自hackster.io