设备端记忆外设（EdgeHippo）
市场调研与产品战略报告

一、执行摘要：五条结论

1.1 一句话概括战略转向

注：最后一行的差异是决定性的。上一版方案的最大结构性问题不是技术不可行，而是"单个用户在没有他人加入时不获得任何价值"。外设形态根治了这一点。

二、品类定义：从"算力共享"到"器官"

2.1 产品的一句话定义

2.2 四项不可替代资产（用户已确认的价值定位）

2.3 为什么叫"器官"而不是"产品"

本报告建议把自我定位从终端品类调整为设备器官。三个理由：

1. 品类的失败率极高。Limitless、Humane Ai Pin、Rabbit R1 都在证明：一个"什么都能记住"的通用消费硬件，往往卡在"没有一件高频必做的事"。而"器官"依附于宿主已有的高频行为。
2. 品类直面红海。一旦某个场景跑通（如 AI 录音卡），华强北在 12 个月内将其压到 120–150 元水平 （界面新闻、36氪，2026）。作为器官供货方，我们赚的是能力差价而非终端价格战。
3. 器官天然"适用各行业"。用户希望这套能力能通用于各个场景和行业——只有器官形态能做到：同一套固件，适配不同宿主（机器人主控、AGV、巡检仪、PC、手机、医疗设备）。

2.4 名字建议

建议：技术/引擎侧沿用 EdgeMemory / eXtremeDB 双品牌；终端硬件（α/β/γ/δ 全部端侧形态）统一命名为 EdgeHippo 短名，不要再混用「EdgeMemory Peripheral / Link」之类的旧叫法。

三、市场验证：四个证据与一个尸体

本章回答一个问题："给 AI 硬件装记忆"是不是一个真需求？答案是肯定的，而且证据密度在最近三个月陡然上升。

3.1 证据 A｜Plaud：AI 外设的商业模型已经跑通

来源：亿恩网、出海网、闪豚出海、界面新闻、36氪，2026 年 9–10 月报道。注意：不同报道对"出货 200 万台"与"用户 250 万"的表述口径不完全一致，本表按各来源公开原文并列，未做统一校正。

3.2 证据 B｜红熊 AI 笔记熊：需求的最强近证，以及它的架构缺口

2026-10-24，WTCC 2026 西岸国际科技消费嘉年华，红熊 AI 发布"笔记熊"，自称全球第一款有"记忆"的智能录音卡。距本报告成稿仅 2 天。

来源：IT之家、新京报、钱江晚报（潮新闻）、新华网上海频道，2026-10-24 至 10-25。

同时注意它对本项目的三个正面信号：

• "记忆"已经成为独立卖点。不再是"转写准确率高 5%"，而是"这款硬件会记得你"。
• 它的叙事与我们高度同频（海马体、工作/短期/长期三层、遗忘机制、更新闭环），说明市场语言已经被教育出来了，我们不需要重新发明术语。
• 它已经把 MCP 铺到生态。这提示我们：设备侧也应该原生暴露 MCP / Agent 接口，而不是自定义私有 API（见第 7 章）。

3.3 证据 C｜Oki Home / Violoop / Ghost：高端"本地记忆"支付意愿已验证

3.4 证据 D｜ObjectBox：技术侧已经有人在证明"端上向量库"可行

ObjectBox（德国，2015 年成立）是目前最贴近本项目技术定位的商业产品，其公开资料：

来源：objectbox.io 官方 vendor map（2026）、iTechGuides / shouldiuse 第三方评测（2026）。第三条评测指出其团队规模约 5 人、总融资 $3.39M、约 $688K 营收。

3.5 那具尸体｜Limitless：死于场景缺位，而非技术

3.6 小结：需求侧已确认的五件事

四、技术论证：时序 + ANN 闭环

4.1 什么是"闭环"

本项目的核心不是"一个能查向量的 MCU"，而是一条会自我加固的记忆循环。它把"刚刚发生什么"（时序）与"我记得什么"（语义）绑在同一个事务边界里。

闭环的三个商业含义：

1. 遗忘机制有了物理实现。原始时序按小时滚动覆盖（数据量太大），但被第 5 步判定为"有价值"的窗口会以向量形式永久留存。这就是"忘了细节、留下了教训"，也是笔记熊被追问而答不上来的那部分（第 3.2 节所列第四项质疑）。
2. "记得越久越值钱"是真的。设备运行时间越长，向量库覆盖的历史工况越全，异常识别与答案质量越高——这是无法被后来者靠"同款硬件"追平的资产。
3. 它天然解释了"为什么不共享算力"。共享算力要求节点间传输模型权重或中间激活，对 MCU 而言不经济（上一版报告已论证）；而共享记忆碎片只需要传输几百 KB 的向量包，且碎片本身是自洽、可离线验证的。这正是"碎片/接力"模式的物理基础。

4.2 与 McObject 官方技术叙述的对照

2026-09-01，McObject CEO Steve Graves 发布文章《How eXtremeDB ANN indexes and time series / sensor data fusion work together》，公开给出的路径：

传感器数据（IMU / 振动 / 声学 / 热，各自不同采样率）
    ↓ eXtremeDB 时序处理（按共同时间窗对齐/重采样）
    ↓ 数组与数学/统计函数提取特征；可选外部 ML 模型
    ↓ 多传感器特征合并为单个归一化向量
    ↓ HNSW 或 Vamana 索引做相似性检索
    ↓ 与传统索引上的精确条件组合过滤
    ↓ ANN 命中可直接回溯到生成它的那段传感器历史

4.3 四项能力齐备性：为什么是 eXtremeDB

用户给的产品定义有四个限定词，逐项对照现有候选引擎：

注：上表依据各厂商 2026 年公开自述资料整理。ObjectBox 官方 vendor map 自评 ~0.25–0.27 ms/query；sqlite-vec 官方定位为 "brute-force only (no ANN yet)"、Pre-v1。主流 TSDB 均未提供 MCU 级运行时。eXtremeDB 的 footprint / Edge Client 8KB 数据来自 McObject 官方 SeedOps 公司页。

4.4 MCU 级 ANN 的工程约束（来自官方白皮书，必须遵守）

《ANN Indexes for Resource-Constrained Devices》明确了 MCU 上不能照搬服务器做法：

4.5 "不共享算力"之后：计算分层表

既然明确不做算力共享，就必须说清楚每一层算力从哪来：

这张表建议在对外技术文档中直接公开——它能在一页内回答"那本地还是不本地"的全部质疑，且每条都有明确的理由。

五、硬件形态矩阵

5.1 四形态定义

5.2 β 形态的工程可行性：已实证，且有两个官方捷径

ESP-IDF 的 USB 设备栈基于 TinyUSB，公开文档给出：

来源：Espressif ESP-IDF v6.0/6.1 官方中文文档、ESP-IoT-Solution 官方演示。

5.3 无线通道的分工

原则：无网状态下，设备的全部核心能力必须完整可用。Wi-Fi/BLE 只用于搬运与管理，绝不承载检索路径。这条要写进产品规格书——它是与云端记忆产品最直观的差异。]

六、容量与延迟测算

6.1 资源预算基线

关键洞察：N16R8 相对 N8R8 多出的是 Flash（4→11 MB），内存一样。而 flash-backed ANN 的主要成本是 I/O 与存储，不是 RAM。因此 N16R8 能装的记忆条数约为 N8R8 的 2.75 倍，而查询延迟二者接近。结论：容量靠选 N16R8 拉开（2.75×）；延迟则主要靠第 4.4 节的离线布局与 IVF 优化，与选哪款 Flash 关系不大。

6.2 向量容量矩阵（384 维）

链接开销按常见估计 每层 ~2M 个邻居 ID × 4 B ≈ 128 B/节点。注意：在低维（384）场景下链接开销占比会明显高于高维场景——这是压缩之外的第二个容量杠杆（降 M 到 8 可再省 64 B/条，代价是召回与遍历效率）。

6.3 原文侧：不能被忽略的一半预算

向量之外还要存"答得出来"所需的原文/摘要，否则 ANN 命中了也不知道该说什么。

6.4 "知识碎片"的物理定义

既然单板只能装万条级而不是百万条级记忆，就必须放弃"全量知识库"的想象，改用碎片（fragment）模型：

这套数字决定了对外叙事必须诚实：我们卖的不是"随身带一个图书馆"，而是"随身带一个记得你/记得这台机器/记得这套工艺的专科大夫"。这句话比任何参数表都更能命中需求，也更不容易在交付时许诺过度。

6.5 检索延迟估算

6.6 时序留存策略（三级分层）

仍以 16 通道 × 100 Hz、列式 + delta 压缩约 1.2–1.8 B/点为例：

七、碎片与接力机制

7.1 碎片包（.emf）的建议结构

my-fragment.emf                    ← 一个自洽、可离线验证的记忆单元
├── manifest.json                  ← schema 版本、条目数、维度、量化方式、领域标签
├── vectors.bin                    ← int8 量化后的向量（顺序布局，按 IVF 簇排列）
├── graph.bin                      ← HNSW 链接（离线构建，已优化落盘顺序）
├── payload.bin                    ← 每条记忆的摘要正文（≤150 B/条，可选加密）
├── timeseries.bin                 ← 附带的时序特征历史（可选）
└── signature                      ← 来源签名 + 完整性校验（防篡改、可审计）

设计三原则：

1. 自洽（self-contained）。一个碎片包必须能被独立加载、独立检索、独立验证。不能出现"装了这个碎片还依赖另一个碎片"的情况——这会摧毁"可拔插"的价值主张。
2. 离线可验证。接收方在没有网络、没有 Hub 的情况下也能校验包的完整性与来源。这是"物理接力"成立的前提。
3. 模式统一。打包必须用统一的 schema 语言，与 eXtremeDB 的 schema 语言同源，避免 PC 侧与板侧两套定义漂移。

7.2 三种接力模式

7.3 为什么"碎片接力"比"分布式算力共享"更容易落地

7.4 对外接口原则

• 优先暴露 MCP。笔记熊已把记忆服务上架魔搭 MCP 并向硬件生态开放；各类记忆 MCP 服务器在 2026 年已是常见形态。自定义私有 API 会被生态惩罚。
• 拖拽即灌库。见第 5.2 节的 UX 提案，这是"外设"这个形态最该有的交互。
• 查询向量由宿主提供。板侧不做 embedding，模型能力由宿主侧决定、可随时更换（这是把 LLM 生态的不确定性隔离在系统外的最佳位置）。

八、竞争定位

8.1 四类参与者全景

8.2 差异化：必须建在 ObjectBox 做不到的地方

8.3 定位陈述

8.4 三条护城河（按可持续性排序）

1. 许可证壁垒（最强）：eXtremeDB 在 MCU 上的 Timeseries + ANN + ACID 组合，短期内没有第二个商业替代品。这是 McObject 三十年的积累，不是钱能马上砸出来的。
2. 策略层 Know-how（中）：遗忘曲线、冲突消解、去重边界这些策略需要在真实长期运行里调参，抄不走。先积累者为王。
3. 工具链与格式（中）：一旦 .emf 碎片格式与离线构建工具成为团队习惯，迁移成本会很高——但也不该把它做封闭，见风险 6。

九、跨行业场景表

用户的要求是"能应用于各个场景和行业"。下表按我们的能力嵌入位置排序，每个都标注 α（模组）/ β（USB 外设）两种切入方式与付费方。

十、单位经济模型

10.1 单位成本测算

10.2 定价与毛利

10.3 与上一版方案的直接对比

10.4 组合收入模型（第 18–24 个月目标口径）

说明：软件类收入占比约 34%，且毛利质量远高于硬件。这与上一版报告"先框架后引擎"的漏斗思路一致——只是入口从开发者换成了"记忆器官"。

10.5 灵敏度：最该盯的三个变量

十一、18 个月路线图与 Go/No-Go

十二、风险登记册

十三、待验证清单（按优先级排序）