复制安装命令
用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
Robots have been around for years but have never been autonomous — someone has to drive them wit...
用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
来源文件:README.md
Robots have been around for years but have never been autonomous — someone has to drive them with a remote, and they've stopped at scripted demos. Autonomous OS brings autonomy to robots: install it on your robot and it comes alive.
Autonomous OS is a fully customizable operating system for robots. Every component is swappable — engine, model, voice, skills, board. Your robot declares what it has in a ROBOT.md, and the OS mounts exactly that. When a better one ships, your robot gets it the same day — and gets better without new hardware.
The simplest way in is a robot we have already tested it on. What each of them can do: robot comparison.
Lamp is the robot that shows the whole OS — it sees, hears, speaks, moves, and ships with Autonomous OS on it.
https://github.com/user-attachments/assets/c80f1255-4355-4f59-9114-6d3b8d4007a2
SOUL.md and it is someone else on the next turn.Reachy Mini is Hugging Face's desk robot, running our OS beside its own stack.
https://github.com/user-attachments/assets/2f0aaafb-287c-488e-a3b1-a82f0ad9e776
ssh pollen@reachy-mini.local.curl -fsSL https://raw.githubusercontent.com/autonomous-ai/autonomous-os/main/robots/reachy-mini/install.sh | sudo bash
reachy-mini.local./opt/devices/reachy-mini/SOUL.md. Everything else, including how to undo the install: devices/reachy-mini/README.md.Intern is the always-on desk agent: mic, speaker, LED ring.
/opt/devices/intern-v2/SOUL.md.Autonomous OS runs on any robot you can describe in four markdown files.
ROBOT.md — the body: the board and the hardware it has.SOUL.md — the self: who it is and how it talks.SAFETY.md — the bounds: how fast, how bright, how late.SKILL.md — the hands: one thing it can do.Follow the full guide.
Autonomous OS is a software stack. Each layer uses only the layer below it, so any layer can be replaced without touching the others. Every layer is a folder in this repo.

What a person touches. The Autonomous app adds a robot, sets up Wi-Fi, installs skills from the Skill Store and switches brains; the robot also serves its own setup and monitor UI from system/web/. Both talk to os-server on :5000.
One folder per behavior, one SKILL.md inside: markdown the agent reads. A skill acts by writing [HW:/path:{json}] markers in its reply, so it never touches a servo bus or a GPIO pin. Each skill declares the capabilities it needs and installs on every robot that has them.
The engine that thinks. Six of them — Hermes, OpenClaw, PicoClaw, Codex, Claude Code, OpenCode — behind one 76-method AgentGateway. It reads the robot's SOUL.md and its installed skills. Switch live from the web UI; persona, memory and connectors move with it.
The Go daemon os-server on :5000, one package per box in the figure. intent answers fixed commands from a local table with no model; server strips [HW:…] markers out of a reply and POSTs them to HAL before the words are spoken; agent switches engines; bootstrap is OTA, its own binary.
Gemini Live, OpenAI Realtime or Qwen, hosted inside HAL and running beside the main path. A spoken turn lands here first: it answers directly, or hands the turn up to the engine.
The 13 names a robot may declare — audio, vision, sensing, presence, motion, light, display, expression, lifelike, media, connectivity, companion, system. Ten mount HTTP routes on :5001 (111 endpoints, live Swagger at /api/hardware/docs); presence and lifelike are loops with no route, companion lives in os-server. HAL mounts only what ROBOT.md declares and fails loud on a missing required driver.
A pure function of SAFETY.md, below the engine and in every request path: brightness, quiet hours, explicit-move speed. No model in the loop — the same clamp whoever asked. What it does not cover yet: docs/safety.md.
One folder per subsystem: motors, rgb, camera, voice, display, sensing, tracking, and the media handover a third-party daemon needs. New hardware is one class and one factory line.
One JSON entry per board, matched against /proc/device-tree/model. Raspberry Pi 4, Pi 5, CM4 and OrangePi 4 Pro today. A new board is an entry, not a code change.
The vendor kernel — Raspberry Pi OS, OrangePi Debian, or the robot's own image. We do not ship one, and nothing above the drivers has a real-time deadline: position control closes in the servo firmware, or in the robot's own daemon.
Four markdown files and a driver per robot. Declarations, not forks — a body is a PR.
Long form: architecture · HAL · device spec · capabilities · safety · developer guide.
The easiest way in is a skill: one markdown file, no Go, no hardware, and it lands on every robot that has the parts. PRs welcome, vibe-coded ones included. Questions, half-built ports and show-and-tell go in Discussions; gaps we would love help with are labelled claim-me — comment to take one.
| You want to… | You write… | Start from |
|---|---|---|
| Teach every robot something new | skills/<name>/SKILL.md (+ skill.json if it needs hardware) | skills/guard/ · skill-creator |
| Run Autonomous on your robot | robots/<id>/ROBOT.md + SAFETY.md + SOUL.md | robots/reachy-mini/ — a third-party port, end to end |
| Support new hardware | a class in hal/drivers/<subsystem>/ + one factory line | reachy_service.py |
| Support a new board | one entry in hal/board/boards.json | boards.json |
| Add a brain | an AgentGateway implementation in runtimes/<name>/ | adding-agent-runtime.md |
Seven more paths — apps, chat bridges, perception models, voices, safety bounds, CTS probes — and the norms: CONTRIBUTING.md. One rule worth knowing up front: robots/contract/ is the interface everyone builds on, so open an issue before you change it.
Build locally:
make os-build && make os-test # Go daemon, cross-compiled to linux/arm64
(cd hal && uv sync) && make hal-dev # HAL on :5001 with reload
make web-install && make web-dev # setup + monitor UI
make cts # is this a valid Autonomous device?
Everything outside hal/ is Apache-2.0. hal/ is GPL-3.0, kept that way by choice so the tree has one license per top-level folder; a driver you commit there is GPL, so a closed vendor SDK wraps out of process.
A robot running this carries other people's work: Pollen's reachy_mini SDK, YOLOv8 for tracking (AGPL-3.0 — read it before you ship), TEN-VAD and Silero for hearing, LeRobot and the LeLamp Runtime under the motion code, and the brains we install but do not ship. All of it, including what we copied verbatim: CREDITS.md. Security issues: SECURITY.md.
name: habit
description: Tracks and analyzes behavioral patterns (habits) for known users based on their wellbeing, presence, posture, and activity history. Use when answering questions about a user's routines ("What are Leo's habits?", "Has Leo been keeping to his routine?", "Notice anything about my patterns?"), or when invoked from wellbeing/SKILL.md or posture/SKILL.md on a threshold nudge to refresh patterns and provide habit-aware phrasing. Also feeds music-suggestion/SKILL.md with `music_patterns` for personalized genre. Habit does NOT fire its own standalone nudge — it enriches wellbeing/posture threshold-nudge phrasing.Habits are repeating behavioral patterns derived from historical logs. This skill reads existing data (wellbeing, presence, mood, music, posture) to build patterns per user, then stores them for other skills to consume.
OUTPUT RULE: Reply is spoken VERBATIM. ONE short caring sentence. All computation, pattern math, and log lookups stay in
thinking. NEVER output timestamps, deltas, frequency counts, or reasoning in the reply. (Exception: Flow E — open habit questions — see below.)
All data lives in /root/local/users/{name}/:
| Folder | File pattern | What it contains |
|---|---|---|
wellbeing/ | YYYY-MM-DD.jsonl | drink, break, celebrate, sedentary labels, enter/leave, nudge_* events with timestamps |
mood/ | YYYY-MM-DD.jsonl | signal + decision rows with moods |
music-suggestions/ | YYYY-MM-DD.jsonl | suggestion history + accepted/rejected status |
posture/ | YYYY-MM-DD.jsonl | posture_alert (ergo-risk events from camera) + nudge_posture / praise_posture rows |
User names are lowercase folder names under /root/local/users/. Known users: leo, chloe, gray, lily. Strangers collapse to unknown — this is treated as a regular user with its own folder and its own habit patterns (aggregated across all strangers).
JSONL line example (wellbeing):
{"ts": 1776657145.05, "seq": 4, "hour": 10, "action": "drink", "notes": ""}
Computed patterns are stored per user at /root/local/users/{name}/habit/patterns.json.
Rebuild when:
A habit is a time-anchored action that repeats across multiple days. Strength labels:
| Frequency | Strength |
|---|---|
| < 0.50 | weak (skip for nudging) |
| 0.50 – 0.75 | moderate |
| > 0.75 | strong |
Habits require at least 3 days of data to form. With fewer days, skip proactive nudging.
| Flow | When to run | Details |
|---|---|---|
| A — Build patterns | Discovery / answering questions; wellbeing nudge | reference/build-patterns.md |
| B — Habit match | Helper for wellbeing/SKILL.md Step 3b | reference/match-helper.md |
| C — Music personalization | Build / consume music_patterns | reference/music.md |
| D — Conversation intent logging | Triggered from SOUL when user states intent NOW | inline below |
| E — Open habit question | User asks about someone's habits / patterns / routines | reference/open-question.md |
SOUL instructs the device to call this flow when user expresses intent for a daily activity NOW.
Intent → action mapping:
| User says | Action to log |
|---|---|
| "lunch", "dinner", "going to eat", "grab food" | meal |
| "coffee break", "grab a coffee", "getting coffee" | coffee |
| "good night", "going to sleep", "heading to bed" | sleep |
| "gym", "exercise", "workout", "going for a run" | exercise |
How to log:
curl -s -X POST http://127.0.0.1:5000/api/wellbeing/log \
-H 'Content-Type: application/json' \
-d '{"action":"meal","notes":"user said: going to lunch","user":"<current_user>"}'
Rules:
notes field stores the original phrase for debugging.curl -s "http://127.0.0.1:5000/api/openclaw/wellbeing-history?user={name}&date=YYYY-MM-DD&last=100"
cat /root/local/users/{name}/wellbeing/YYYY-MM-DD.jsonl
Use direct file reads for multi-day pattern building (faster, no API pagination needed).
curl -s "http://127.0.0.1:5000/api/openclaw/wellbeing-history?user={name}&last=50"
From wellbeing/SKILL.md: When wellbeing's Step 3 fires a threshold nudge, it invokes Flow A (which self-throttles via the freshness guard). Flow A returns the current wellbeing_patterns; wellbeing uses any matching pattern for the nudge action to enrich Step 4's phrasing (e.g. "you usually drink around now"). No separate habit-only nudge — habit context piggybacks on the threshold nudge. This keeps bootstrap cost on the rare nudge path, not on every motion.activity tick.
From posture/SKILL.md: Same pattern. When posture decides to nudge AND its context block has bootstrap_needed=true, it invokes Flow A. Flow A returns posture_patterns (peak hour, side bias, typical risk) which the posture coach uses to phrase pattern-aware nudges (e.g. "around this hour you usually slip").
From music-suggestion/SKILL.md: Read habit/patterns.json → music_patterns. If habit data exists and current hour matches, use preferred genre instead of default genre table.
| Purpose | Min days | Min occurrences |
|---|---|---|
| Habit detection | 3 | 2 |
| Proactive nudging | 5 | 3 |
| Music personalization | 3 | 2 accepted |
If data is insufficient: use default wellbeing thresholds / music genre table as fallback. Never fabricate patterns.
Nudge enrichment (Flow A → wellbeing Step 3b):
Open habit question (Flow E):
评论 (0)
暂无评论,成为第一个评论者吧!