产品架构
Myrm 由两层产品加可选云端控制平面组成。理解这一划分有助于部署、排错，以及从其他 Agent 迁移。分层
通俗说法： 前端是你点击的界面；服务端是进入工作空间的门；Harness 是沙箱内的「大脑与双手」。
Harness 公开 API（集成契约）
开源 Server 只能通过myrm_agent_harness.api 集成 Harness，禁止深 import 内部模块。
myrm-agent-server 的 architecture CI 禁止 from myrm_agent_harness.*._* 导入，保证 Harness 内部可演进而公开 api.__all__ 保持稳定。发行 wheel 为可读 .py 壳 + 编译 core 扩展。
对 SaaS 的意义： 控制平面按用户沙箱滚动 runtime Docker 镜像 tag（镜像内打包 server + harness）。Server 胶水层仅 import api.hooks / api.skills，镜像滚动时 glue 层保持稳定——多数开源 Agent 单体架构做不到这一点。
请求流（典型对话）
- 用户在前端（或经服务端接入的 IM 渠道）发送消息。
- 服务端认证、加载 Agent 配置，向 UI 流式推送事件。
- Harness 运行 Agent 循环：工具、记忆召回、子 Agent、上下文压缩。
- 结果经服务端 → UI 回传（并可选择推送渠道通知）。
在哪里配置什么
部署模式（同一功能，不同打包）
设备与硬件层：今天能用什么，什么还没做
「随身 AI 伴侣」这类竞品路线指的是把 Agent 塞进你自己的板子、手表或旧手机。我们把现状分三段说清，不含糊：
与竞品的诚实差别：Hermes Gadget 已经交付了开放 SDK、桌面模拟器（同一份固件核心跑在桌面窗口，没有硬件也能开发和验收）以及逐型号的实机验证矩阵。这条路径我们认同，也按同样的口径规划（构建通过 ≠ 真机可用，未验证项必须显式写出），但今天还没有交付，所以这里不宣传。
平台支持与验证状态：每条能力都标状态
三个平台上的实现深度并不相同，我们不写「全平台都支持」，而是逐条标验证状态：
口径：✅ 有真栈 / 真二进制实测记录；⚠️ 代码就位但没有真机验证记录；❌ 该平台显式关闭或未实现。单元测试与 CI 通过不等于真机可用，未标注即未验证。
未验证项的完整清单已列入路线图；这条纪律本身就是能力验证矩阵与支持标签纪律。
从其他 Agent 迁移
- 配置： Hermes / OpenClaw 风格导出的导入路径（见快速开始）。
- 记忆： Myrm 使用结构化 DB 记忆 + GUI——不是单个
MEMORY.md文件。 - 技能： 预置 + 社区发现；进化需审批。
- 渠道： 26 内置提供商——在设置中重新绑定 OAuth/Token。
下一步
快速开始
几分钟内本地运行。
记忆系统
跨会话记忆如何工作。
沙箱运行时
工具实际执行的位置。
桌面应用
Tauri 打包与更新。