Xiaozhi AI Hardware Dev Board Review: Building a Voice Agent with Cloud Code

Build your own voice AI agent on a plug-and-play ESP32 board using Xiaozhi AI and Cloud Code.
This article reviews a highly integrated ESP32 dev board — featuring a built-in speaker, microphone, battery, and transparent enclosure — that dramatically lowers the barrier to AI hardware development. The community has produced ready-to-use projects including City Radio and Xiaozhi AI firmware. The author used the Xiaozhi open-source repo and Cloud Code to build a voice agent handling weather queries, date lookup, and poetry generation, powered by LLM, TTS, ASR, tool calling, and VAD. The current limitation is single-turn conversation only; the next goal is evolving it into an agent with real, actionable skills.
An Integrated Dev Board Built for the AI Era
Large AI models are getting more powerful by the day, but most people still interact with them through web pages and mobile apps. Something fundamentally changes when you pack that conversational capability into a physical device you can hold in your hand — and that's exactly the problem this integrated hardware development board sets out to solve.
The first thing that catches your eye is its transparent black enclosure. You can see the internal component layout right through the shell, which has a certain engineering elegance to it. More importantly, the board is highly integrated — it already packs in the core ESP32 module, a speaker, a battery, a Type-C power port, a power button, three function keys on the side, and a microphone, all wrapped in a clear plastic shell straight from the factory. For developers, this means skipping the tedious soldering and peripheral wiring work — you can start flashing firmware the moment it arrives.

On first boot, the device loads a pre-installed demo firmware that requires a quick QR code scan for initial setup. Once configured, it lands on a main screen resembling a handheld mini-device, with a game icon and a photo icon at the bottom. The built-in game is a simple dodge-the-obstacles mechanic using up/down controls. This default firmware exists mainly as a demo and development template — the real value comes from using it as a foundation to build your own applications.
Community Use Cases: From City Radio to Xiaozhi AI
The community has already built up a solid collection of ready-to-use projects around this board. The flashing process is straightforward: connect the board to your computer with a data cable and click to install — a beginner-friendly experience from start to finish.

The feature that left the biggest impression was the "City Radio" function. After flashing and connecting to WiFi, the device turns into a networked radio — you can browse local stations or tune into broadcasts from other cities. According to the community, this is the most-downloaded project of all the available options, which makes sense: it nails the "physical device + connected content" formula that gives hardware an immediate sense of practical utility.
Beyond radio, the community also offers dedicated firmware builds for Xiaozhi AI. Xiaozhi AI is an open-source project, and the voice conversation capabilities built around it represent the most imaginative direction for this board. Compared to typing into a chat box on a webpage, holding a voice-enabled AI agent in your hand creates a completely different sense of presence.
Xiaozhi AI is an open-source voice assistant project built on the ESP32 chip series, designed to deploy large language model conversational capabilities onto embedded hardware at low cost. It uses a split architecture where the device handles audio capture and playback while the cloud handles ASR/LLM/TTS computation, maintaining real-time communication via WebSocket. Because the code is fully open-source, developers can swap out model providers, modify wake words, and customize the interface and features — which has spawned an active ecosystem of firmware variants for different hardware models. The value of projects like this lies in packaging what would otherwise require enormous low-level engineering effort into a reusable framework, letting developers focus on application logic rather than communication protocols and driver layers.
Building a Voice Agent with Cloud Code
The part that really demonstrates the board's potential is where the author used the Xiaozhi open-source repository alongside Cloud Code to build a custom voice agent called "Xiaoshan Agent."

The first step was binding the device. A binding code appears on the screen; entering it links the hardware to your custom-built agent. Once bound, the screen displays the interface title drawn using Cloud Code.
In the demo, the agent could already handle basic conversational tasks: answering questions about its name, checking the current weather, reporting the date, and even composing a seven-character classical Chinese poem on the spot. Functionally, this covers the same ground as a web-based AI chat — lightweight tasks like weather queries, dates, and web searches. But the author keeps coming back to one point: the same conversation feels completely different when it's coming from a physical device in your hand versus a text box on a screen.

The Technical Stack Is Simpler Than You'd Think
The underlying architecture of this voice agent is actually quite clean — a handful of modules assembled together:
- Large Language Model (LLM): handles understanding and generating conversational responses
- TTS (Text-to-Speech): reads the model's replies aloud
- ASR (Automatic Speech Recognition): converts the user's voice into text
- Tool Calling & Voice Activity Detection (VAD): handles feature extensions and determines when the user is speaking
Wire these together with Cloud Code and you have a working voice assistant. This "model-as-a-service + edge hardware" combination is the dominant implementation pattern in AI hardware today — intelligence and compute live in the cloud, while the hardware handles capture and playback.
ASR (Automatic Speech Recognition) and TTS (Text-to-Speech) sit at opposite ends of the voice interaction pipeline. ASR transcribes the audio stream from the microphone into text — common approaches include cloud APIs like OpenAI Whisper and Alibaba Cloud's speech recognition service, as well as lightweight local models optimized for embedded devices. TTS reads the LLM's generated text aloud; popular options in China include iFlytek, Microsoft Azure, and speech synthesis services from major cloud providers. VAD (Voice Activity Detection) is often overlooked but critically important — it determines whether the user is currently speaking, deciding when to stop recording and trigger recognition, preventing false activations or missed utterances, and directly affecting how natural the conversation feels. On resource-constrained embedded devices, VAD typically runs locally as a lightweight algorithm, while ASR/TTS call cloud services over WiFi — striking a balance between compute capacity and output quality.
From Single-Turn Chat to Actionable "Skills"
The author is candid about the current version's limitations: this voice assistant only handles single-turn conversations, lacks real actionability, and is fundamentally a "one question, one answer" assistant without the ability to maintain state or execute multi-step tasks.
The next iteration aims to transform it from a pure chat assistant into an agent with genuine "skills" — adapting it to handle specific mini-tasks so it can actually do things rather than just converse, then packaging that capability into the hardware enclosure. This observation cuts to the heart of what separates AI hardware "toys" from "tools": conversation is just the entry point. Whether it can call tools and complete concrete tasks determines whether it has lasting value in the long run.
The difference between "single-turn" and "multi-turn" conversation comes down to context memory and state management. In single-turn mode, each user utterance is an independent request — the model has no memory of previous exchanges and can't complete tasks that require cross-step coordination, like "check the weather, then recommend an outfit based on it, then remind me about my commute." Breaking through this limitation typically requires maintaining conversation history on the server side (prepending previous messages to each request's prompt) and introducing a Function Calling / Tool Use mechanism — allowing the model to proactively decide which external API to call during a conversation, retrieve the result, and continue reasoning from there. This is the core idea behind today's AI Agent architectures: the LLM serves as the orchestration hub, paired with a set of callable tools and persistent state, evolving from a question-answering machine into an automated assistant capable of completing real-world tasks.
Wrap-Up
For developers who want to get their hands on AI hardware, this highly integrated dev board significantly lowers the barrier to entry: ready-to-use peripherals, a beginner-friendly flashing workflow, an active community of projects, and low-cost custom development via Cloud Code all combine to make "build your own voice agent" genuinely within reach. Its current capabilities are still fairly demo-oriented, but as a learning and experimentation platform for the intersection of AI and hardware, it offers a clear and reproducible path forward.
Related articles

AI Agent Developer Job Hunt Guide: Four Hard Standards to Clear Before You Apply
A practical guide for landing AI Agent developer roles: four measurable standards — project runs, problems debuggable, solution explainable, interviews survivable.

Multi-Agent Development Guide: From Monolithic AI to Team Collaboration in Practice
A beginner's guide to multi-agent development covering core advantages, common learning pain points, enterprise tech stacks, and engineering methodology for AI developers.

Agent Skill Routing: Retrieval vs. LLM vs. Two-Stage Architecture Compared
Retrieval or LLM for Agent skill routing? Compare coarse-filter vs. fine-select architectures on latency, accuracy, and cost — with 4 key production considerations.