AEROS
让具身智能体真正可部署。
一台机器人，一个常驻 Agent，一套运行时。
AEROS 补上了具身智能真正缺失的那一层：
执行控制、策略约束、故障恢复与审计追踪。
v0.10.0 已发布 · 2,239 个测试通过 · 每个 PR 跑 identity-hash 回归
不只停留在 Demo，而是走向真实部署。
Sim G1 在 AEROS 上端到端行走：Runtime → ECM → Governance → Embodiment。 实时 HUD 是 bridge 真实 emit 数据形态 — identity hash、ECM 派发、policy gate、watcher tick、审计链 block。 看完整 chain →
模型会思考了，机器人会行动了，
但智能体还缺少真正可上线的运行机制。
模型能力在快速提升，机器人形态也越来越丰富。但一旦进入真实环境，问题就来了：Agent 如何持续运行？任务中断后怎么恢复？能力升级会不会影响线上系统？出现异常谁来接管、谁来追溯？这些问题，不能只靠模型解决，还需要一套专门的运行与治理机制。
会规划，不等于能稳定运行
Agent 给出一个计划，并不意味着它就能持续执行。状态丢失怎么办？任务卡住怎么办？环境变化后如何恢复？这些都属于运行时问题，不是模型推理本身能解决的。
硬件越多，系统越容易碎片化
人形、四足、AMR、机械臂……如果每类机器人都单独搭一套 Agent 栈，成本高、复用差，也难以规模化。行业需要的是一套位于硬件之上的通用运行时，而不是一堆彼此割裂的工程实现。
要真正上线，就必须管得住
在仓储、医院、酒店、工厂等真实场景中，Agent 的每一次能力调用都必须可控、可回滚、可追踪。谁授权、谁执行、出了问题如何处理，都需要有明确机制。
AEROS 如何让智能体真正跑起来
AEROS 不只是让 Agent "执行一次任务"，而是让每一次执行都具备准入、校验、监控、恢复和留痕能力。
每一次动作，都先经过运行时
Agent 想做什么，由它自己决定；但这个动作能不能执行、是否符合契约、是否满足策略约束、执行过程中谁来监控、出问题后如何恢复，这些由 AEROS 统一负责。
规划器可以替换，模型可以演进，能力可以升级；但只要进入执行阶段，就必须先经过运行时治理。
没有通过运行时，就不会直接触达硬件。
AEROS 不是又一个机器人操作系统
Linux 给机器提供了系统层。
Kubernetes 给分布式应用提供了控制层。
AEROS 给具身智能体提供运行与治理层。
五层架构，分清智能、执行与治理的边界
治理不是补丁，
而是运行时的一部分
传统机器人系统通常在部署完成后，再补监控、补策略、补审计。AEROS 从一开始就把治理作为运行时内置能力：每次能力调用在到达硬件之前，都必须先经过治理引擎。
这样带来的结果是：安全不是事后补救，而是架构内生；升级不是高风险操作，而是受控演进；审计不是事后拼凑，而是全链路可追踪。
深入架构设计 →这五层架构把"智能"与"执行纪律"分开，也把"执行纪律"与"硬件依赖"分开。
每一个组件，都带版本号
v0.9.0 是公开基线。v0.10.0 在 main 分支推进中：身份、人格、记忆、反思、人形 — 五个子系统，一个不变的 identity hash。
运行时核心
生命周期、调度、执行回路、故障处理。Apache 2.0。
ECM 能力包系统
六维 typed contract、v1/v2 dispatcher、shadow executor。Apache 2.0。
治理层
Policy DSL、Watcher、四级 recovery、Ed25519 审计链。
身份冻结（Frozen Identity）
七字段 IdentityManifest；identity_hash 在升级中保持字节相等。HR-1 在 CI 每次回归。
自适应人格
不对称信任：tighten 自动 emit，relax 必须 operator 副签。20/天 cap + floor-clamp 指标。
Layer 2 语义记忆
4 种 fact kind、确定性 SQL 聚合、outbox 持久化保证 emit 不丢。可重放。
Active Dreaming（离线反思）
离线 reflection runner + scheduler。占位 LLM 自动 refuse，避免脏 dream。
Unitree G1 人形
ONNX 双足步态（AGPL-clean）。骨盆推进 ≥0.4 m / 1.5 s。Live integration 测试覆盖。
面向不同角色，选择合适的入口
具身智能体运行与治理平台。