这一篇写什么#

之前写过《OPPO 健康云同步逆向：从抓包到白盒签名的死局（已破）》。那篇的重点是逆向过程：为什么一开始被白盒签名困住，后来才发现健康云数据接口走的是更浅的静态 HMAC 签名路径。

这篇文章不再重复逆向推演，而是把破局后的结果落成可用项目：oppo-health-cloud-mcp。它是一个本机运行的 OPPO 健康（欢太健康）云端只读 MCP server，可以同步本人账号的数据到本地 SQLite，再让支持 MCP 的 AI 客户端查询和做周期分析。

一句话概括：

1
欢太账号登录 / 已登录 App 凭据
2
        ↓
3
健康云只读 API
4
        ↓
5
本地 SQLite 缓存
6
        ↓
7
MCP stdio server
8
        ↓
9
AI 客户端查询 / 分析

先说边界#

这个项目有几个必须先讲清楚的边界：

• 它不是 OPPO 官方 API，也没有得到 OPPO 官方授权。
• 它只做云端数据的读取和本地缓存，不提供写入、删除、修改健康数据的接口。
• 它只应该访问本人账号。健康数据非常敏感，不要拿它做多人共享服务，更不要尝试访问他人数据。
• 它服务端结构可能随 OPPO 健康 App 版本变化，项目适合作为学习和个人研究工具，而不是稳定商业服务。

还有两个常见误解：

1. Web 端的欢太云备份不是 OPPO 健康云同步。 前者更多是云备份页面，后者是健康 App 的系统化云端数据通道，协议和认证并不相同。
2. OPPO 健康不一定要靠系统 App 固定身份才能用。 登录器走的是欢太账号验证码登录，后续再换取健康包级 token；这和从已登录 App 私有文件里提取凭据是两条不同路线。

项目能力#

当前 MCP server 暴露四个工具：

项目目前覆盖 67 个 MCP 指标：65 个独立指标，加上 stress 和 physical_mental 两个组合指标。常见类别包括：

接口存在不代表账号里一定有数据。比如某项健康功能没有开启、设备不支持，或者过去没有记录，cloud_sync 成功但返回空集都是正常情况。另外，wrist_temperature 是相对个人基线的统计，不是体温计意义上的绝对体温；sport_file 还需要 App 运行时生成的密钥，当前项目未支持。

登录与认证#

1
{
2
  "token": "...",
3
  "token_auth_id": "...",
4
  "ssoid": "..."
5
}

设备 ID 和多账号隔离#

早期方案里有一个隐患：如果多个用户复用同一组设备身份，服务端很容易把它们视为异常设备行为。现在已经改成：

1
每次登录默认生成随机 OpenSDK device ID
2
同一登录内的 DUID source ID 默认与其一致

也就是说，普通用户不需要手工配置设备 ID。只有确实需要固定身份时，才显式传入参数或环境变量：

1
export OPPO_HEALTH_DEVICE_ID="<32 位 hex>"
2
export OPPO_HEALTH_SDK_DEVICE_ID="<32 位 hex>"

多账号本机隔离时，应该同时隔离认证文件和缓存数据库：

1
export OPPO_HEALTH_AUTH_FILE=/secure/path/account-a-auth.json
2
export OPPO_HEALTH_CACHE_DB=/secure/path/account-a-cache.db

这不等于鼓励把项目部署成多人共享服务。当前设计仍然假设“一台机器、一个用户、一套本地缓存”。

接入 MCP 客户端#

安装依赖：

1
python3 -m pip install "mcp[cli]" requests pycryptodome

在 MCP 客户端里注册 stdio server：

1
{
2
  "mcpServers": {
3
    "oppo-health-cloud": {
4
      "command": "python3",
5
      "args": ["/absolute/path/to/oppo-health-cloud-mcp/cloud_mcp.py"]
6
    }
7
  }
8
}

首次验证可以这样跑：

1
cloud_status
2
cloud_sync(metric="steps", days=1)
3
cloud_query(metric="steps", date="2026-10-28")
4
cloud_analyze(days=7)

cloud_status 只检查本地状态；云端可用性还是要跑一次只读同步接口确认。

本地缓存模型#

缓存文件默认是仓库目录下的 cloud_cache.db，主表结构很直接：

1
CREATE TABLE IF NOT EXISTS cloud_data(
2
  metric TEXT,
3
  date TEXT,
4
  payload TEXT,
5
  fetched_at INTEGER,
6
  PRIMARY KEY(metric, date)
7
)

这里做了一个取舍：

• 原始 payload 保留 JSON 字符串。 不同健康指标的返回结构差异很大，强行拍平会导致每个指标一套表结构，维护成本高。
• 查询时再解析 JSON。 对个人数据量来说，这个代价可以接受。
• 同一 (metric, date) 覆盖写入。 重复同步不会无限膨胀。

cloud_analyze 基于本地缓存计算两个周期：

• 最近 N 天。
• 再往前一个 N 天。

它目前会汇总心率、血氧、步数、千卡、睡眠时长、深睡、REM 和最新体重，并给出简单异常标记。口径也会明确写进报告，例如：

• 步数和千卡按全天各模式累加。
• 睡眠在同一日有多条记录时取总时长最长的一条。
• 心率使用指定类型下的单点均值，不等价于静息心率。

请求与签名设计#

健康云请求的核心不是“能拼出 URL”，而是保持请求形态足够接近客户端：

1. 构造规范化签名字符串。
2. 用静态应用密钥计算 HMAC 签名。
3. 保留精确的请求头集合。
4. 通过 curl 子进程发送请求。

这里有几个实测结论：

所以 cloud_sync 内部不是单个 HTTP 请求，而是一层适配器：按指标选择端点、展开组合指标、处理分页、归一化日期、缓存结果，再返回给 MCP 客户端。

为什么不用 Web 或系统备份接口#

我最初的目标不是做一个“云备份爬虫”，而是让 AI 能读取本人健康数据的明细。两者需求不同：

• 云备份更偏设备资料恢复和备份管理。
• 健康云同步保存的是心率、血氧、睡眠、运动等明细，适合后续趋势分析。
• 系统 App 的本地数据库权限和私有账号文件依赖系统环境，不适合作为长期 PC 端 MCP 的基础。

因此项目最终选择健康 App 的云端只读通道，而不是 Web 备份页面或本地数据库 hook。

数据安全和实际风险#

健康数据的敏感等级比一般网页 token 高得多。使用这个项目时，应该把两类文件都当作私密数据：

建议：

• 只在本机可信目录保存认证和缓存文件。
• 不要把 MCP 输出直接粘贴到公开群组或网页。
• 如果 AI 客户端会把上下文写入日志，确认你愿意让这些日志接触健康数据。
• 如果凭据泄露，尽快在欢太账号或 OPPO 健康里退出登录、修改密码，并删除本地 auth.json 和缓存数据库。

这也是为什么项目不适合部署成多人共享服务。它不是“一个服务端支持所有用户”的形态，而是“一个用户在本机控制自己的数据”。

适合的使用方式#

这类工具比较适合几个场景：

1. 周期复盘：让 AI 读取最近 7 天、30 天的数据，找趋势和异常点。
2. 本地数据整理：把云端 JSON 收敛成个人可搜索、可分析的 SQLite 数据。
3. 跨 App 自动化：在支持 MCP 的客户端里把健康数据和其他日记、工作、训练记录放在一起分析。
4. 设备切换后的历史分析：只要云端仍保留数据，就不再依赖某台手机的本地数据库。

不适合的使用方式也很明确：

• 不要给陌生人代跑。
• 不要把 token 打包进镜像、容器或笔记仓库。
• 不要让 MCP server 暴露到公网。
• 不要把工具当成医疗诊断器。异常标记只是阈值提示，不能替代专业医疗判断。

后续方向#

基础同步、查询、分析和登录已经跑通，后面我会优先做两件小事：

1. 把 cloud_analyze 的报告格式再收敛，让 AI 更稳定地输出“周期变化、异常点和下一步问题”，而不是把大段原始数据丢给模型。
2. 继续完善错误提示，把 token 过期、TLS 指纹拦截、时间范围超限这类常见问题解释得更清楚。

项目地址：

https://github.com/foxlesbiao/oppo-health-cloud-mcp

如果你想看签名为什么一开始被误判成“死局”，可以先读上一篇文章；如果你只想让 AI 读取自己的 OPPO 健康数据，直接从这个仓库的 README 开始就可以。

背景#

codex-mcp 是我给小黑盒社区做的只读 MCP Server，支持搜索、话题、游戏、帖子浏览和登录态管理。仓库本身不含签名算法源码——签名器以外部命令方式提供，用户需要自行实现。这篇文章完整记录签名算法的逆向过程和实现细节，给同样想走这条路的人参考。

API 请求签名概览#

小黑盒 API 请求需要两类签名参数：

两者输出格式相似但计算路径完全不同。Web 签名是纯算法，Native 签名由 Android SO 中的 JNI 方法计算。

抓包分析#

用 Charles 做 HTTPS 中间人抓包，每个请求都带：

1
_time=1700000000
2
nonce=aBcD...32位随机字符
3
hkey=XXXX0000
4
_rnd=15:hex_string
5
version=999.0.4

用 Frida hook okhttp3.Request，定位到签名在 com.graphice.shaderar.ShaderManager（JNI 对应 libglesv3_1.so）和 com.max.xiaoheihe.utils.NDKTools（JNI 对应 libnative-lib.so）中生成。

Web 签名算法#

Web 签名用于非登录状态的公开 API，纯算法可复现，不依赖 SO。

1
R_CHARSET = "AB45STUVWZEFGJ6CH01D237IXYPQRKLMN89"
2

3
# 1. timestamp+1 经字符表映射（取前 2 个字符的 ord % 2）
4
part_time = tw(str(timestamp + 1), R_CHARSET, 2)
5

6
# 2. 路径规范化：/api/endpoint/ → 每字符 ord % len(R_CHARSET) 映射
7
part_path = rw(normalized_path, R_CHARSET)
8

9
# 3. nonce 同样映射
10
part_nonce = rw(nonce, R_CHARSET)
11

12
# 4. 三段交错拼接取前 20 字符 → MD5
13
combined = interleave([part_time, part_path, part_nonce])[:20]
14
digest = md5(combined.encode()).hexdigest()
15

16
# 5. digest 后 6 字符做自定义列混淆（位运算 + XOR）
17
transformed = mix_columns([ord(c) for c in digest[-6:]])
18

19
# 6. hkey = 映射(digest[:5]) + pad(sum(transformed) % 100, 2)

1
def ty(v): return ((v << 1) ^ 27) & 255 if v & 128 else v << 1
2
def da(v): return ty(v) ^ v
3
def vs(v): return da(ty(v))
4
def dol_c(v): return vs(da(ty(v)))
5
def dl(v): return dol_c(v) ^ vs(v) ^ da(v)
6

7
# 4x4 列混淆
8
result[i] = dl(a) ^ dol_c(b) ^ vs(c) ^ da(d)  # 按不同顺序组合

1
RND_KEY = "Z7mFG4tQp9Ws2LxB8H"
2

3
message = (RND_KEY + nonce + f"{timestamp}:{nonce}").encode()
4
_rnd = "15:" + hmac.new(
5
    RND_KEY.encode(), message, hashlib.sha256
6
).hexdigest()

Native App 签名（Unidbg）#

Native 签名由 SO 库计算，无法用纯 Python 复现。方案是 Unidbg 模拟执行。

1
1. 初始化 SO：
2
   ShaderManager.setParseDepth("/tmp/xhh-cache", false)
3
   ShaderManager.setSecLevel()
4
   ShaderManager.setBlendMode(BLEND_SEED, timestamp)
5

6
2. 获取 chunk flag：
7
   ShaderManager.getChunkFlag(context, CHUNK_SEED) → chunk_flag
8

9
3. 生成 nonce：
10
   ShaderManager.getIdxOffset(context, chunk_flag, timestamp, identity) → nonce
11

12
4. 设置签名上下文：
13
   ShaderManager.setViewport(timestamp, nonce)
14
   ShaderManager.setGramLen(path, nonce)
15
   ShaderManager.setBuf(timestamp, nonce)
16
   ShaderManager.setDepRel(device_model, nonce)
17
   ShaderManager.setDLen(os_version, nonce)
18
   ShaderManager.setPtrOffset(app_version, nonce)
19

20
5. 编码：
21
   NDKTools.encode(context, path, timestamp, nonce)
22

23
6. 获取签名：
24
   ShaderManager.getObjType(context, nonce, false) → hkey
25
   ShaderManager.getObjType(context, nonce, true)  → rnd_suffix
26

27
7. 输出：
28
   _rnd = security_version_or_os_version + ":" + rnd_suffix

1
CHUNK_SEED = "PAENEHAMGACOBHIEMIHIJLKJPMMHJMMQABCNGBPPENCENP"
2
BLEND_SEED = "MFANEHAMGACOBHIEMIHIJLKJPMMHJMMLABCNGBPPENCENPOM"

1
getPackageName()     → "com.max.xiaoheihe"
2
getFilesDir()        → "/data/user/0/com.max.xiaoheihe/files"
3
getCacheDir()        → "/data/user/0/com.max.xiaoheihe/cache"
4
Build.MODEL          → 设备型号
5
Build.BRAND          → "vivo"
6
Build.VERSION.RELEASE → Android 版本
7
PackageInfo.signatures → 从 APK 解析证书
8
getSharedPreferences(...) → 空实现
9
getString("DebugInfo") → imei + identity

1
ShaderManager.setHdrField(Base64.decode(security_code))
2
ShaderManager.b = true              // 静态 boolean
3
ShaderManager.c = security_version  // 静态 int

1
AndroidEmulator emulator = AndroidEmulatorBuilder.for64Bit()
2
    .setProcessName("com.max.xiaoheihe")
3
    .addBackendFactory(new Unicorn2Factory(true))
4
    .build();
5

6
emulator.getSyscallHandler().addIOResolver(this);
7
Memory memory = emulator.getMemory();
8
memory.setLibraryResolver(new AndroidResolver(23));
9

10
VM vm = emulator.createDalvikVM(new File(resources, "minimal-app.apk"));
11
vm.setVerbose(false);
12
vm.setJni(this);
13

14
DalvikModule shaderModule = vm.loadLibrary(
15
    new File(resources, "libglesv3_1.so"), true);
16
shaderModule.callJNI_OnLoad(emulator);
17

18
DalvikModule nativeModule = vm.loadLibrary(
19
    new File(resources, "libnative-lib.so"), true);
20
nativeModule.callJNI_OnLoad(emulator);
21

22
DvmClass shaderManager = vm.resolveClass("com/graphice/shaderar/ShaderManager");
23
DvmClass ndkTools = vm.resolveClass("com/max/xiaoheihe/utils/NDKTools");

SMS 登录加密#

App 使用 RSA PKCS#1 v1.5 加密手机号（1024 位，公钥从 APK 提取）。公钥本身不是秘密，加密流程就是标准 RSA：

1
# 从 DER 提取 modulus 和 exponent
2
modulus = ... # 1024 bit
3
exponent = 65537
4

5
# PKCS#1 v1.5 填充
6
block = b"\x00\x02" + random_nonzero_padding + b"\x00" + phone_bytes
7
cipher = pow(int.from_bytes(block, "big"), exponent, modulus)
8
result = base64.b64encode(cipher.to_bytes(128, "big"))
9
# 按 76 字符换行

登录请求还需要一组设备指纹查询参数（imei、device_info、os_version 等），与签名一起发送。

外部签名器接口#

仓库通过 XIAOHEIHE_SIGNER_COMMAND 环境变量或 config.json 的 signer_command 字段指定外部签名器路径。签名器接受命令行参数并输出 JSON：

1
signer <path> <timestamp> <identity> <device> <os-version> <app-version> <imei> <security-code> <security-version>

输出：

1
{
2
  "path": "/api/endpoint/",
3
  "_time": "1700000000",
4
  "nonce": "随机32字符",
5
  "hkey": "8位签名",
6
  "_rnd": "前缀:签名值"
7
}

合规#

本文仅供个人学习、研究和兼容性分析。逆向工程可能违反平台服务条款和当地法律。请勿用于商业化、批量采集或恶意用途。

背景#

我有一个长期项目：把 OPPO 健康（欢太健康）App 里的心率/HRV/血氧/睡眠等数据自动导出到本地做分析。已有方案是 root + LSPosed hook 本地数据库，稳定跑着。

新想法很自然：云同步里既然有全部数据，能不能直接抓云端的接口，做一个纯 PC 的 MCP？ 这样使用者只需要抓一次 cookie，不用 root、不用 LSPosed、App 升级也不用改 hook。

结论先说：思路验证成立，但被白盒签名封死在最后一步。 下面是完整的调查过程，给同样想走这条路的人省时间。

第一步：静态分析 APK —— 云端存的是明细#

反编译健康 App（脱敏版本号 6.9.x），找到云同步的 API 网关（域名脱敏为 ***.heytapmobi.com/sporthealth/），共 667 个 v1-v5/c2s/* 端点。关键事实：

云端存的是明细数据，不是聚合值。 每类指标都有独立同步接口：

增量协议也确认了：queryXxxVersion(水位) → modifiedTimestampList → 按版本拉数据，标准的双向增量同步（push 上传 + pull 下载），App 卸载重装恢复数据靠的就是它。

鉴权比预想的轻：请求头一个 virtual-ssoid 就够，账号 token 走 accountsdk。没有多层签名链——当时我以为这条路能通。

第二步：抓包 —— 认证体系完整还原#

真机 Reqable 抓包，1296 条请求（1084 条健康 API），303 个不同端点。认证头全部识别：

前四个都是静态的，抓一次包就有。唯一的变数是 signature——每条请求都不一样。

第三步：smali 逆向 —— 签名协议 100% 还原#

顺 SignInterceptor 挖下去，签名链完整还原：

1
HttpSignData{method, url, body, 10个签名头}
2
  → V2Signer.getCommonSignHeaders()
3
  → SecKitClient.macSign(context, bytes)   ← libwbkit-seckit3.so 白盒
4
  → signature header

签名构造算法本身是可复刻的：

1
canonical = method\n + path\n + query\n + 排序headers\n + signedHeaders\n + sha256(body)
2
sig = HmacSHA256(mk, canonical) → CMSSignedData protobuf → base64

问题在密钥 mk 的来源：

1
服务端 KMS 协商下发
2
  getkmssystemtime → getkmscertificate → getserviceticket
3
  → ServiceSessionInfo{Dek, Mk, Ticket}

死锁：初始 getserviceticket 协商请求本身需要 accessKey + WbkitAndr.signature（白盒 native 签名）。即：

要拿到会话密钥 mk，得先通过白盒签名认证；要白盒签名，得在真机上跑那个 so。

第四步：实验 —— 实测封死纯 PC 路线#

理论推完还不算完，直接做实验验证（之前的 403 结论用错了 token 类型，不算数，这次重测）：

两组实验锁死事实链：

1. 原样重放都被拒 → nonce 有时效/一次性，网关验的不只是静态凭证
2. HMAC 密钥用客户端一切静态值都凑不出 → 密钥就是协商下发的 mk
3. 协商要白盒 native 签名 → 死循环闭合

本质是信息的物理分布问题：签名密钥那 32 字节此刻只存在于两个地方——服务端 KMS 数据库里，和真机内存里（用完即弃的会话态）。它不在 APK 里、不在抓包文件里、不在任何静态文件里。这不是”AI 不够聪明”，是白盒密码的设计目标就是防提取。

行业方案盘点#

白盒签名怎么破，业界工具箱其实很固定：

淘宝 x-sign 这类能被 unidbg 破的前提是”纯算法 so”；一旦签名密钥走服务端协商（本案），静态路线全灭。行业共识：动态调用是标准答案。

总结#

1. 云同步数据方案没有死，但”抓 cookie 就能用”死。最短可行路径是 Frida RPC 签名桥：PC 发请求 → 手机（连 Wi-Fi 充电即可）出签名 → 云端拉数据。依赖等级 = 手机在线，和原 hook 方案持平。
2. 原 hook 方案仍是依赖最少的形态。数据管道已经全自动跑着，云抓取的真正价值只有”换机/重装免配置”，收益配不上新增的签名服务复杂度——所以这个方向收档了。
3. 方法论收获：403 结论下早了会误导方向（第一次测试 token 类型就是错的）；重放实验+密钥穷举这种”否定性实验”比正向尝试更有信息量——两组实验直接闭合了死循环的证明链。密码学死锁面前，逆向工程的终点是确认”这条路的门是焊死的”，然后换路。

签名对拍样本已留存（740 条），哪天重启这个方向，5 分钟捡起来。

后记（2026-09-22）：死局已破，上面有一处关键误判#

四天后重启这个方向，5 分钟真的捡起来了——而且发现”死锁”的证明链有一环是错的。

误判在哪：第三步里 SecKitClient.macSign → libwbkit-seckit3.so 那条调用链确实是 App 里的真实代码路径，但它只服务于 KMS 协商那类接口。健康数据 API（v5/c2s/*）走的根本不是白盒 native 签名，而是一个纯 Java 层的 HmacSHA256(canonical, httpSecret)——而 httpSecret 是 APK BuildConfig 里的静态常量，XXTEA 加密存放，两个 UUID 逐字符交错当 XXTEA 密钥解出来即可。

为什么当时没发现：smali 顺藤摸瓜时先撞见了 SecKitClient/白盒 so（KMS 体系），就顺着走到底推出了”协商需要白盒签名”的完整死锁。实际上健康 API 的签名在另一条更浅的路径上（pk9/HttpSignatureUtil），抓包对拍 50/50 通过——之前第四步”穷举静态值凑不出 HMAC 密钥”失败，是因为穷举列表里没有解出来的 httpSecret，而不是密钥真的动态。

复盘教训：逆向时”先撞见的正确答案”会遮住”更简单的正确答案”。签名这种东西应该在 smali 里全局搜 HmacSHA256 的所有调用点做穷举对拍，而不是顺着一条最显眼的链走到底。白盒和静态密钥经常共存，选择走哪条链决定了你看到的是死局还是一行 Python。

破局后的完整实现已开源：foxlesbiao/oppo-health-cloud-mcp —— 无 root、无 LSPosed、无手机依赖，PC 直接拉云端明细（心率/血氧/步数/睡眠/体重/App使用等），MCP 接入任意 agent。签名静态复刻，50/50 对拍通过。附带实测踩坑：python TLS 指纹被网关拦（必须 curl 子进程）、多余请求头参与验签（virtual-ssoid 头会直接 403）。

原始结论”抓 cookie 就能用”依然不成立——还需要做一次静态逆向（或者直接用上面的开源实现）；但”需要真机签名代理”这半句错了，真正的依赖只有：抓包拿一次 token，之后全程 PC 独立运行。

问题#

想把自己 OPPO 健康（心率 / 睡眠 / 血氧 / 呼吸率等）的全部明细数据交给本地 AI 深度分析，而不是只看 App 里的聚合图表。但 OPPO 健康的本地数据库是 SQLCipher 加密的，直接打开是乱码，拿不到数据。

同时，导出的数据要喂给 AI agent 分析，接收端接口如果写得不够规范，别人（其它 agent）没法按标准接入。所以最后把服务端做成了 MCP (Model Context Protocol) 规范。

完整代码已开源：github.com/foxlesbiao/oppo-health-export

三层方案#

1
手机(LSPosed hook) ──增量导出──▶ 服务端 Flask(手机专通道) ──▶ sink库 ──▶ MCP server
2
  提取SQLCipher密钥                                   (行哈希幂等)      │
3
  流式分片 + 分块上传                                                     ▼
4
                                                                 任意 AI agent

1
===TABLE:DBHeartRate|TIMECOL:data_created_timestamp===
2
ssoid,device_type,data_created_timestamp,value,...
3
1249250120,,1779393420000,85,...

踩过的坑#

有了数据 ≠ 能解读：还需要医学知识库#

导出的只是原始指标（心率、血氧、睡眠时长、呼吸率……）——它们本身是无医学含义的数字。要准确分析、而不是让模型凭内置的泛泛知识臆断，还必须给 agent 接入靠谱的医学知识库：

• 把权威资料（医学教材、临床指南、中医典籍）入库（RAG / 向量检索）
• 分析时先检索、再下结论，并标注「这个判断依据哪份资料」
• 缺少对应资料时明确说不知道，而不是编一个看似合理的解读

这才是工程上负责任的健康分析：数据链路负责「绝对真实的你」，知识库负责「尽量正确的解读」，两者缺一不可。否则再精确的数据，也可能被一句想当然的解读带偏。

1
手机上传(/api/upload) → HMAC 签名的本地 webhook → agent 读新数据生成周报告
2
   → 写入本地知识库(OpenViking) → 推送到 IM

近期更新（v5.3.7 → v5.3.9b）#

版本迭代中又踩了一轮新坑，补充记录：

工程细节：上传顺序为 内网 → 外网 → Tailscale 三路依次尝试；配置项（上传地址 / token / Tailscale 地址）全部由 UI 运行时输入，写入 SharedPreferences + 共享 XML 给 hook 进程读取，代码里零硬编码——这也是它能直接开源的前提。

构建侧：debug 签名 keystore 不再硬编码绝对路径，默认 ~/.android/debug.keystore，可用 DEBUG_KEYSTORE 环境变量覆盖（开源仓库的基本修养）。

总结#

• 逆向层的核心：libxposed 新 API + 钩对加解密类拿密钥 + 延迟虚拟打开，避免早期反射崩 App。
• 导出层的核心：不追求一次回溯全历史，设初始水位 → 首次导近期 → 之后增量；分片保证内存峰值恒定。
• 接收层的核心：做标准 MCP server 而非自造 API，别人能按规范接入。

这样你的健康数据就能持续、增量、幂等地流进本地 AI，且对外是标准 MCP 接口。

代码：github.com/foxlesbiao/oppo-health-export

问题#

在路由器（OpenWrt）上跑 ShellCrash（sing-box 内核），在 TUI 里选了 “全分组规则+去广告” 规则模板，规则集文件也都下载好了（ruleset/*.srs 一堆），但实际体验是：国内网站也绕代理，广告不拦截，流媒体不分流——规则好像完全没起作用。

诊断：规则集下载了，但 route 没引用#

ShellCrash sing-box 版（1.9.5beta1+，内核 singboxr）的配置生成机制是多 JSON 模块拼接：

1
/tmp/ShellCrash/jsons/*.json  （启动时 singbox_modify.sh 生成）
2
  ├─ route.json        基础路由
3
  ├─ add_rule_set.json 规则集定义
4
  ├─ dns.json          DNS 规则
5
  ├─ outbounds.json    策略组+节点
6
  └─ cust_*.json       持久化自定义（从 $CRASHDIR/jsons/ 软链）

启动命令是 CrashCore run -D $CRASHDIR -C /tmp/ShellCrash/jsons（目录模式深度合并）。

排查后发现：

• add_rule_set.json 里只有 cn 一个规则集定义
• route.json 只有 6 条基础规则（sniff → dns 劫持 → 内网直连 → 拒 QUIC/BT → 全部走代理）
• 模板（含完整的分流 rules + 22 个 rule_set 引用）被丢弃，完全没被合并

根因：starts/singbox_modify.sh 的 gen_dns() 硬编码只生成 cn 规则集；启动时重新生成的 route.json 只有基础规则。模板的完整 route（rules + rule_set）被覆盖/丢弃——这就是”规则集下载了但分流不生效”的原因。

修复：持久化 route.json 补上模板该做的事#

不修改 ShellCrash 的脚本（改模板 JSON 会被覆盖，改脚本下次更新又还原），而是利用 ShellCrash 官方设计的持久化机制：

$CRASHDIR/jsons/route.json 会在启动时被软链为 cust_route.json 参与合并。所以直接在这个持久化文件里写完整的 route：

1
{
2
  "route": {
3
    "rules": [
4
      { "action": "sniff" },
5
      { "protocol": "dns", "action": "hijack-dns" },
6
      { "ip_is_private": true, "outbound": "DIRECT" },
7
      { "protocol": "quic", "action": "reject", "no_drop": true },
8
      { "protocol": "bittorrent", "action": "reject" },
9
      { "rule_set": ["custom-direct"], "outbound": "DIRECT" },
10
      { "rule_set": ["custom-proxy"], "outbound": "节点选择" },
11
      { "rule_set": ["ads"], "outbound": "REJECT" },
12
      { "rule_set": ["cn", "cnip"], "outbound": "DIRECT" },
13
      { "outbound": "节点选择" }
14
    ],
15
    "rule_set": [
16
      { "tag": "custom-direct", "type": "local", "format": "binary",
17
        "path": "/mnt/.../ShellCrash/ruleset/Custom_Direct.srs" }
18
      // ... 其他规则集定义
19
    ]
20
  }
21
}

关键点：

1. 规则集定义用 local + 绝对路径（path 指向 ruleset/*.srs）。相对路径 ./ruleset/ 在 merge 时工作目录解析有问题，绝对路径最稳。
2. route 里必须含 cn 定义——singbox_modify.sh 检测到持久化目录已有 cn tag 就会跳过 add_rule_set.json 的生成，避免重复定义冲突。
3. 规则集文件要先编译好，用 sing-box 自带的编译命令：

1
# 把 Clash .list 转成 sing-box source JSON
2
# {"version":1,"rules":[{"domain_suffix":"x"},...]}   ← 必须带 version 字段
3

4
# 编译成 .srs
5
/tmp/ShellCrash/CrashCore rule-set compile /tmp/x.json -o /mnt/.../ruleset/X.srs

1. 重启用 ./start.sh stop && ./start.sh start（比 TUI 交互更可靠）。

自定义规则（Aethersailor 等 OpenClash 规则）接入#

用户想要的 Aethersailor/Custom_OpenClash_Rules 是 OpenClash（Mihomo）格式（.mrs/.yaml），sing-box 不能直接用。转换流程：

1
.list（Clash 格式）→ source JSON（{"version":1,"rules":[...]}）→ rule-set compile → .srs

把转换好的 .srs 放进 ruleset/，在 route.json 里加引用即可。自动更新用 crontab：

1
# 每周一 4:30 更新自定义规则集
2
30 4 * * 1 sh /mnt/.../ShellCrash/tools/update_asailor_rules.sh

验证#

1
# 看已加载的规则集
2
curl -s http://127.0.0.1:9999/rules | grep -o 'rule_set=[^"}]*'
3

4
# 分流测试
5
curl -s -x http://127.0.0.1:7890 https://www.google.com/generate_204 -o /dev/null -w '%{http_code}'
6
# → 204（走代理）
7
curl -s https://www.baidu.com -o /dev/null -w '%{http_code}'
8
# → 200（直连）

修复后：Google 走代理 204，百度直连 200，广告规则集、流媒体分流全部生效，重启后配置持久保留。

总结#

• ShellCrash sing-box 模式的模板 route 被丢弃是规则”不生效”的根因（已提 issue：#1326）
• 修复方式是利用官方持久化机制（$CRASHDIR/jsons/route.json → cust_route.json 合并）补上模板该做的事
• 自定义 OpenClash 规则需要先转成 sing-box .srs 格式才能用
• 规则集定义用 local + 绝对路径，route 里含 cn 可避免 add_rule_set 重复生成

追加：实战中踩到的两个大坑（2026-08-12）#

1
cp $CRASHDIR/jsons/config.json.bak $CRASHDIR/jsons/config.json
2
# 然后 TUI 启动：mm → 1

1
# 找到 ShellCrash 实际位置
2
find /mnt -maxdepth 2 -name "ShellCrash" 2>/dev/null
3
# 启动（指定 CRASHDIR）
4
export CRASHDIR=/mnt/usb-XXXX/ShellCrash && sh /mnt/usb-XXXX/ShellCrash/menu.sh
5
# 菜单里选 1 启动服务

前言#

这是 Hermes Agent 系列的第四篇文章。

• 第一篇：构建个人 AI 工程知识操作系统 — 记忆分层架构
• 第二篇：多模型路由架构演化 — v1→v3 路由
• 第三篇：可观测 AI 系统 — task-memory + trace + 经验闭环
• 第四篇（本文）：Memory System v1.0→v1.41 演化 — 冲突解决 + 权限治理 + 实体图谱 + 检索引擎

本文记录 Hermes Agent 的记忆系统从简单的 MEMORY.md 文件，经过 10 个版本迭代，演化为一个带权限治理、来源链审计、时间版本、实体图谱和意图感知检索的认知记忆层的过程。

起点：为什么需要 Memory System#

Hermes Agent 原来使用 MEMORY.md 存储用户事实，存在五个核心问题：

1. 无时间戳 — 无法判断过期
2. 无可信度标记 — 事实和推测混在一起
3. 无冲突解决 — 多来源矛盾时无裁决依据
4. 无过期机制 — 老旧条目永久占空间
5. 无冷冻机制 — 关键条目可能被意外覆盖

演化路线#

1
v1.0  能记东西
2
 ↓
3
v1.1  会冲突检测
4
 ↓
5
v1.2  会生命周期管理（持久化 + decay）
6
 ↓
7
v1.3  会排序（Memory Ranking Engine）
8
 ↓
9
v1.35 会权限和实体（authority + entity/field）
10
 ↓
11
v1.36 会不可变保护（IMMUTABLE_TYPES）
12
 ↓
13
v1.37 会混合评分（authority_gate × 加权和）
14
 ↓
15
v1.38 会来源审计（provenance + scope 隔离）
16
 ↓
17
v1.39 会时间记忆（valid_from/until + memory_layer）
18
 ↓
19
v1.40 会检索（Query Planner + GC + EntityGraph）
20
 ↓
21
v1.41 会意图感知 + 预算管理（Intent Detection + Budget）

核心架构（v1.41 最终状态）#

1
class MemoryEntry:
2
    value              # 内容
3
    memory_type        # IDENTITY / FACT / PREFERENCE / SKILL / PROJECT / TEMP
4
    memory_layer       # EPISODIC / SEMANTIC / PROCEDURAL / IDENTITY / TEMPORARY
5
    authority          # user=1.0 / tool=0.6 / agent=0.3
6
    source             # 来源（与 authority 分离）
7
    confidence         # 0.0-1.0
8
    explicitness       # 0.0-1.0
9
    freshness          # 基于 decay_days 自动衰减
10
    retention          # freshness×0.5 + usage×0.3 + confidence×0.2
11
    provenance[]       # 来源链审计（可追溯用户原始陈述）
12
    valid_from         # 记忆生效时间
13
    valid_until        # 记忆失效时间（supersede 时自动关闭）
14
    entity             # 实体名（如 NAS、GPU、OS）
15
    field              # 属性名（如 ip、model、system）
16
    scope              # 范围隔离（如 main_pc、laptop）
17
    relation           # 实体关系（如 located_at）
18
    target             # 关系目标（如 home_network）
19
    relation_confidence
20
    identity_status    # ACTIVE / CONFIRMED / CHANGED / ARCHIVED
21
    usage_count        # 被引用次数（影响 retention）
22
    change_reason      # 变更原因
23
    supersedes         # 前任 memory_id
24
    superseded_by      # 继任者
25
    conflict_with      # 冲突条目

1
score = authority_gate × (
2
    0.4 × confidence
3
  + 0.2 × freshness
4
  + 0.2 × explicitness
5
  + 0.1 × retention
6
  + 0.1 × usage_frequency
7
)

1
用户输入
2
  ↓
3
Assertion Parser（解析断言类型）
4
  ├── CONFIRMED    → 明确事实
5
  ├── HYPOTHETICAL → 假设，不写入
6
  ├── UNCERTAIN    → 可能/应该/觉得
7
  ├── RECALL       → 我记得
8
  ├── QUERY        → 提问，不产生 memory
9
  └── REFERENCE    → 保持，不改变
10
  ↓
11
Intent Detection（是否为更新意图）
12
  ↓
13
Authority Check（权限检查）
14
  ├── IDENTITY 保护：非 user 权限不可修改
15
  └── authority_gate 评分门控
16
  ↓
17
Conflict Detection（冲突检测）
18
  ├── scope 隔离：main_pc vs laptop 不冲突
19
  ├── score 比较：新分数 > 旧分数才允许覆盖
20
  └── 权限门控：agent 永远无法超越 user
21
  ↓
22
Decision（决策）
23
  ├── supersede        → 新值替代旧值，保留历史链
24
  ├── supersede_frozen → 用户确认覆盖 FROZEN
25
  ├── flag_conflict    → 保留双方，请求用户确认
26
  ├── reject           → 拒绝写入
27
  └── no_op            → 无操作
28
  ↓
29
Memory Write（写入）
30
  ├── provenance 自动传播（继承旧链 + 追加新条目）
31
  ├── memory_layer/scope/entity 继承
32
  └── valid_until 自动关闭旧版本

1
ACTIVE → STALE → COMPRESSED → ARCHIVED
2
  ↑                        ↓
3
  └── TEMP 高频使用 → EPISODIC（自动升级）

1
class MemoryQueryPlanner:
2
    # 检测查询意图
3
    intents = {
4
        "WHOAMI":      "我是/我的"       → IDENTITY 层权重提升
5
        "HOWTO":       "怎么/如何/安装"   → PROCEDURAL 层权重提升
6
        "FACT_LOOKUP": "是什么/是多少"    → SEMANTIC 层权重提升
7
        "DIAGNOSE":    "为什么/报错/失败" → EPISODIC 层权重提升
8
        "TEMPORAL":    "什么时候/历史/之前" → EPISODIC 层权重提升
9
    }
10

11
    # 检索评分
12
    retrieval_score = (
13
        0.35 × keyword_match
14
      + 0.25 × authority
15
      + 0.15 × freshness
16
      + 0.15 × scope_match
17
      + 0.10 × layer_priority
18
    )
19

20
    # Token 预算控制
21
    budget = {
22
        IDENTITY: 1000, SEMANTIC: 3000,
23
        PROCEDURAL: 2000, EPISODIC: 1000, TEMPORARY: 500
24
    }
25
    # 按意图动态调整

关键设计决策#

1
Arch (ACTIVE)
2
  ├── provenance[0]: user said "I use Debian" (2026-07-01)
3
  └── provenance[1]: user changed OS to Arch (2026-07-31)

1
GPU.model = 7650GRE  (scope=main_pc)
2
GPU.model = RTX3060  (scope=laptop)

1
Debian  valid_from=2025-01  valid_until=2026-07-31
2
  ↓ supersede
3
Arch    valid_from=2026-07-31  valid_until=NULL

测试验证#

15 个测试案例，覆盖：

全部 15/15 PASS。

与普通 RAG 的区别#

普通 RAG：

1
文档 → Embedding → Search → Answer

Hermes Memory System：

1
观察
2
  → Assertion Parser（断言分类）
3
  → Authority Check（权限检查）
4
  → Conflict Resolver（冲突解决）
5
  → Ranking（评分排序）
6
  → Consolidation（记忆合并）
7
  → Entity Graph（实体图谱）
8
  → Intent-aware Retrieval（意图感知检索）
9
  → Token Budget（预算控制）
10
  → Context Injection（上下文注入）
11
  → Reasoning（推理）

下一阶段：v1.42 Hybrid Retrieval#

v1.41 已冻结为基线。下一步不是继续堆字段，而是：

1. Entity Normalization（最高优先级）— “显卡” = “GPU” = “7650GRE”
2. Hybrid Retrieval — keyword + vector + entity graph
3. 多标签 Intent — 一个查询可以同时是 FACT_LOOKUP + WHOAMI
4. value_per_token — relevance × authority × freshness ÷ token_cost
5. 模块化拆分 — 1020 行单文件拆为 memory/ 包

策略：先让 Memory System 在真实任务中运行，收集 retrieval_success / retrieval_failure 数据，用真实失败样本驱动 v1.42 迭代。

文件清单#

总结#

从 v1.0 到 v1.41，Hermes Memory System 经历了：

• v1.0：能记东西
• v1.2：会生命周期管理
• v1.3：会排序
• v1.37：会混合评分（authority gate）
• v1.39：会时间记忆和来源审计
• v1.41：会意图感知检索和预算控制

已经从一个简单的 MEMORY.md 文件，演化为一个接近认知科学记忆模型的长期记忆治理层。

下一步的重点不是继续增加规则，而是让系统在真实任务中产生数据，用失败案例驱动迭代。这比理论优化更重要。

前言#

我日常使用 Hermes Agent 处理系统架构设计、NAS 运维、家庭能源系统规划、代码编写等任务。但几个月下来，暴露了一个核心问题：AI 没有长期记忆。每次问同一个问题，它都从零开始推理。不会记住我的设备参数，不会记住之前的决策，不会从历史经验中学习。

解决这个问题需要一套完整的工程系统，而不是单一工具。经过连续多日的迭代，这套系统从”配置多个模型”正式进入 v1.0 阶段。

本文是对四篇系列文章的完整整合，一次性呈现这套系统的全貌。

系统总览#

1
┌─────────────────────────────────────────────────────────────┐
2
│                    Hermes 个人 AI 工程系统 v1.0               │
3
├─────────────────────────────────────────────────────────────┤
4
│                                                             │
5
│  ┌─────────────────────────────────────────────────────┐   │
6
│  │  Layer 1: 行为准则 (SOUL.md)                         │   │
7
│  │  实事求是、调查研究、矛盾分析、系统思维、控制论        │   │
8
│  │  反馈闭环、假设验证、工程优先                         │   │
9
│  └─────────────────────────────────────────────────────┘   │
10
│                            │                                 │
11
│  ┌─────────────────────────────────────────────────────┐   │
12
│  │  Layer 2: 专业技能 (Skills)                          │   │
13
│  │  knowledge-retrieval-evidence-policy                 │   │
14
│  │  decision-memory / model-router v3                   │   │
15
│  │  memory-lifecycle-rules / experience-recorder        │   │
16
│  └─────────────────────────────────────────────────────┘   │
17
│                            │                                 │
18
│  ┌─────────────────────────────────────────────────────┐   │
19
│  │  Layer 3: 持久事实 (MEMORY.md + USER.md)             │   │
20
│  │  用户偏好、设备参数、环境信息、已验证的长期经验        │   │
21
│  └─────────────────────────────────────────────────────┘   │
22
│                            │                                 │
23
│  ┌─────────────────────────────────────────────────────┐   │
24
│  │  Layer 4: 知识库 (OpenViking)                        │   │
25
│  │  resources: 工程控制论/系统科学/软件工程/方法论       │   │
26
│  │  memories: 决策记录/历史案例/架构模式                │   │
27
│  └─────────────────────────────────────────────────────┘   │
28
│                            │                                 │
29
│  ┌─────────────────────────────────────────────────────┐   │
30
│  │  Layer 5: 多模型路由 (Model Router)                  │   │
31
│  │  Flash(主控制器) + Pro(审查) + GLM(专家) + Doubao(视觉)│   │
32
│  └─────────────────────────────────────────────────────┘   │
33
│                            │                                 │
34
│  ┌─────────────────────────────────────────────────────┐   │
35
│  │  Layer 6: 可观测性 (Observability)                   │   │
36
│  │  task-memory / failure-memory / trace / batch test  │   │
37
│  └─────────────────────────────────────────────────────┘   │
38
│                                                             │
39
└─────────────────────────────────────────────────────────────┘

第一章：为什么需要记忆系统#

第二章：知识库搭建（OpenViking）#

1
viking://resources/rag/
2
├── engineering_control/    — 《工程控制论》上下册
3
├── history_politics/       — 毛选等（方法论层）
4
├── software_engineering/   — 《人月神话》等
5
└── systems_thinking/       — 《一般系统论》《系统科学方法概论》

1
当前用户明确提供的事实 > 用户已验证的长期事实 > 当前环境实际检测结果
2
> 官方文档与可靠资料 > 知识库专业知识 > 一般经验 > 推测与假设

第三章：记忆系统从 v1.0 到 v1.41 的演化#

1
v1.0  能记东西
2
 ↓
3
v1.1  会冲突检测
4
 ↓
5
v1.2  会生命周期管理（持久化 + decay）
6
 ↓
7
v1.3  会排序（Memory Ranking Engine）
8
 ↓
9
v1.35 会权限和实体（authority + entity/field）
10
 ↓
11
v1.36 会不可变保护（IMMUTABLE_TYPES）
12
 ↓
13
v1.37 会混合评分（authority_gate × 加权和）
14
 ↓
15
v1.38 会来源审计（provenance + scope 隔离）
16
 ↓
17
v1.39 会时间记忆（valid_from/until + memory_layer）
18
 ↓
19
v1.40 会检索（Query Planner + GC + EntityGraph）
20
 ↓
21
v1.41 会意图感知 + 预算管理（Intent Detection + Budget）

1
score = authority_gate × (
2
    0.4 × confidence
3
  + 0.2 × freshness
4
  + 0.2 × explicitness
5
  + 0.1 × retention
6
  + 0.1 × usage_frequency
7
)

第四章：多模型路由架构#

1
                User Request
2
                     │
3
                     ▼
4
          DeepSeek V4 Flash
5
          Router + Orchestrator
6
                     │
7
        ┌────────────┼────────────┐
8
        │            │            │
9
        ▼            ▼            ▼
10
     Level 0      Level 1      Level 2
11
     Flash       Flash+Pro      GLM-5.2
12
        │            │            │
13
        │            │            │
14
        ▼            ▼            ▼
15
    简单任务      审查增强      专家设计
16
                     │
17
                     ▼
18
              Flash 整合输出

1
Step 1: 用户指定了模型？ → 尊重用户选择
2
Step 2: 包含图片？ → Doubao Vision（自动）
3
Step 3: 有 OpenViking 知识？ → 先检索
4
Step 4: 复杂度评估
5
Step 5: 路由（Level 0/1/2）

1
model:
2
  default: deepseek-v4-flash
3
  provider: custom
4

5
delegation:
6
  model: glm-5.2
7
  provider: custom
8

9
auxiliary:
10
  vision:
11
    model: doubao-seed-2-0-pro-260215
12
    base_url: "https://ark.cn-beijing.volces.com/api/coding/v3"
13
    timeout: 120
14
  compression:
15
    model: deepseek-v4-pro
16
  background_review:
17
    model: deepseek-v4-pro
18
  curator:
19
    model: deepseek-v4-pro

第五章：可观测 AI 系统#

1
阶段1: 工具调用 Agent → 能调用工具，但每次独立决策，无记忆
2
阶段2: 多模型 Agent → 多模型分工，规则路由，有记忆分层
3
阶段3: 可观测 AI 系统 → 有日志，有版本，有实验，有回滚，有失败分析
4
阶段4: 经验驱动 AI 系统（未来）→ 基于积累数据自动优化路由

第六章：经验教训#

第七章：当前状态与下一阶段#

1
model-router v3 (frozen-baseline)
2
  ├── 三级路由：Level 0 (Flash) / Level 1 (Flash/Pro) / Level 2 (GLM)
3
  ├── 固定分工：视觉 → Doubao，审查 → Pro，压缩 → Pro
4
  └── 用户覆盖：用户指定模型时跳过自动路由
5

6
memory-lifecycle-rules v1
7
  ├── 7 类可信度标记
8
  ├── 5 类生命周期规则
9
  ├── 三层记忆职责边界
10
  └── 冲突优先级：来源可信度 > 存储位置
11

12
memory_conflict_resolver v1.41
13
  ├── ~1020 行 Python 核心引擎
14
  ├── 15/15 测试通过
15
  ├── 意图感知检索 + Token 预算控制
16
  └── 冻结，等待真实数据驱动迭代
17

18
task-memory / failure-memory (observation only)
19
  └── 不自动影响路由，仅收集数据
20

21
experience-recorder (Python plugin)
22
  └── hook 自动触发，不依赖模型遵守规则

1
Flash:  70-85%
2
Pro:    10-20%
3
GLM:     5-15%
4
Doubao: 按需

结语#

这套系统现在已经从”配置多个模型”进入”个人 AI 工程系统”的阶段。

当前阶段的成功标准不是路由更复杂，而是：

• 每一次决策都有记录
• 每一次失败都有原因
• 每一次改进都有依据

下一步的重点不是继续增加规则，而是让系统在真实任务中产生数据，用失败案例驱动迭代。这比理论优化更重要。

已从”配置 AI”进入”培养 AI”阶段。

背景#

我日常使用 Hermes Agent（Nous Research 开源）作为 AI 助手，处理系统架构设计、NAS 运维、家庭能源系统规划、代码编写等任务。但几个月下来，暴露了一个核心问题：AI 没有长期记忆。

每次问同一个问题，它都从零开始推理。不会记住我的设备参数、不会记住之前的决策、不会从历史经验中学习。

解决这个问题需要一套完整的记忆架构，而不是单一工具。这篇博客记录了过去几天的优化过程。

一、知识库搭建：OpenViking#

1
viking://resources/rag/
2
├── engineering_control/    — 《工程控制论》上下册
3
├── history_politics/       — 毛选等（方法论层）
4
├── software_engineering/   — 《人月神话》等
5
└── systems_thinking/       — 《一般系统论》《系统科学方法概论》

1
memory:
2
  provider: openviking

二、多层记忆架构#

Hermes 的长期记忆系统设计为四层，各司其职：

1
Layer 1: SOUL.md（行为准则）
2
  ├── 实事求是、调查研究、矛盾分析
3
  ├── 系统思维、控制论、工程优先
4
  └── 反馈闭环、假设验证
5

6
Layer 2: Skills（怎么做）
7
  ├── knowledge-retrieval-evidence-policy
8
  ├── decision-memory
9
  └── 各领域专业技能
10

11
Layer 3: USER.md + MEMORY.md（事实）
12
  ├── 用户偏好、设备参数、环境信息
13
  └── 已验证的长期经验
14

15
Layer 4: OpenViking（知识 + 经验）
16
  ├── 工程控制论、系统科学
17
  ├── 软件工程、项目管理
18
  └── 决策记录、历史案例

关键原则：不要把知识往 SOUL.md 里堆。SOUL.md 是行为准则，不是知识库。知识归知识库，事实归 memory，做法归 skills。

三、知识检索策略优化#

四、家庭能源系统设计#

1
L4: 米家智能家居层 — 非关键负载控制
2
L3: HA 能源管理层 — 状态机、能量调度、SOC 管理
3
L2: 逆变器控制层 — MPPT、EPS 切换、电池检测
4
L1: 硬件保护层 — 断路器、SPD、熔断器（纯物理）

五、多模型路由配置#

1
                    Hermes
2
                       │
3
           DeepSeek V4 Flash（主模型）
4
           日常对话、RAG、工具调用、记忆管理
5
                       │
6
          ┌──────────────┼──────────────┐
7
          │              │              │
8
          ▼              ▼              ▼
9
       GLM-5.2      DeepSeek V4 Pro  Doubao Seed 2.0 Pro
10
       ─────────     ─────────────     ─────────────────
11
       子任务         压缩             vision_analyze
12
       delegate      后台审查          OCR/截图/电路图
13
                     策展

1
model:
2
  default: deepseek-v4-flash
3
  provider: custom
4

5
delegation:
6
  model: glm-5.2          # 子任务自动走 GLM
7
  provider: custom
8

9
auxiliary:
10
  vision:
11
    model: doubao-seed-2-0-pro-260215
12
    base_url: "https://ark.cn-beijing.volces.com/api/coding/v3"
13
    timeout: 120
14
  compression:
15
    model: deepseek-v4-pro   # 压缩质量优先，不丢关键约束
16
  background_review:
17
    model: deepseek-v4-pro
18
  curator:
19
    model: deepseek-v4-pro

六、清理与取舍#

1
rm -rf ~/knowledge-base-mcp ~/kb-mcp-server
2
rm -rf ~/lottery-agent

七、三层系统整合#

NAS、AI Agent、家庭能源系统形成三层架构：

1
Layer A: AI Agent（智能决策层）
2
  ├── HA API 读取能源状态
3
  ├── SSH 管理 NAS 服务
4
  ├── cron 定时任务（日报/异常检测）
5
  └── OpenViking 知识库
6

7
Layer B: NAS（基础设施层）
8
  ├── 数据存储（InfluxDB/SQLite）
9
  ├── Grafana 可视化
10
  ├── nginx 反向代理
11
  └── Ghost 博客
12

13
Layer C: HA 能源管理层
14
  ├── 状态机执行
15
  ├── 逆变器 Modbus 通信
16
  ├── 米家设备集成
17
  └── SOC 管理 / 负载调度

总结#

背景#

在上一篇《构建个人 AI 工程知识操作系统》中，我记录了 Hermes Agent 多层记忆架构的搭建过程。但解决了”记住什么”之后，下一个问题是——“用什么模型来思考”。

日常对话、RAG 检索、简单脚本用 Flash 就够，但系统架构设计、硬件安全分析、多方案权衡需要更强的推理能力。全部用最强模型浪费 token，全部用最便宜模型质量不够。

本文记录从单模型到多模型路由的完整演化过程。

问题定义#

架构演化#

1
看到"架构" → delegate
2
看到"状态机" → delegate
3
看到"电路图" → delegate

1
                User Request
2
                     │
3
                     ▼
4
          DeepSeek V4 Flash
5
          Router + Orchestrator
6
                     │
7
        ┌────────────┼────────────┐
8
        │            │            │
9
        ▼            ▼            ▼
10
     Level 0      Level 1      Level 2
11
     Flash       Flash+Pro      GLM-5.2
12
        │            │            │
13
        │            │            │
14
        ▼            ▼            ▼
15
    简单任务      审查增强      专家设计
16
                     │
17
                     ▼
18
              Flash 整合输出

1
Flash
2
  ↓
3
delegate_task → GLM-5.2（深度推理）
4
  ↓
5
GLM 结果返回 Flash
6
  ↓
7
Flash 职责：
8
  ├── 验证结果合理性
9
  ├── 合并 memory 上下文（用户偏好、设备参数）
10
  ├── 检查已知/未知约束
11
  ├── 补充 OpenViking 知识
12
  └── 输出最终答案给用户

1
"用 GLM-5.2 分析这个架构" → 走 GLM
2
"用 DeepSeek Pro 审查代码"  → 走 Pro

1
问题
2
  ↓
3
有 OpenViking 知识可用？
4
  ↓ YES → 先检索，看能否直接回答
5
  ↓ NO  → 继续复杂度判断

1
如果预计回答 < 1000 tokens
2
  AND 无架构设计
3
  AND 无多方案比较
4
  AND 无硬件安全
5
→ 不要 delegate，Flash 足够

完整路由决策树#

1
Step 1: 用户指定了模型？
2
  YES → 尊重用户选择，跳过路由
3

4
Step 2: 包含图片？
5
  YES → Doubao Vision（自动，无需操作）
6

7
Step 3: 有 OpenViking 知识可用？
8
  YES → 先检索，看能否直接回答
9

10
Step 4: 复杂度评估
11
  预计回答长度、模块数、是否含方案比较、
12
  是否涉及硬件安全、是否需要架构图
13

14
Step 5: 路由
15
  Level 0 → Flash 直接回答
16
  Level 1 → Flash 或 Pro（代码审查走 Pro）
17
  Level 2 → delegate → GLM-5.2 → 回流 Flash 整合

辅助链（自动路由，无需操作）#

1
图片/截图/OCR
2
        │
3
        ▼
4
Doubao Seed 2.0 Pro
5

6
后台任务（压缩、策展、background_review）
7
        │
8
        ▼
9
DeepSeek V4 Pro

为什么 Flash 是”大脑”而不是”最低级模型”#

很多多模型方案的结构是：

1
便宜模型 → 判断 → 贵模型

这种方案的问题：便宜模型判断不准，路由错误率高。

我们的方案：

1
Flash → 理解上下文 → 决定是否调用专家 → 整合输出

Flash 不是”便宜替代品”，而是主控制器。它负责：

• 理解用户完整意图
• 调用 memory 和知识库
• 判断是否需要专家介入
• 整合专家输出为最终答案

配置实现#

1
model:
2
  default: deepseek-v4-flash
3
  provider: custom
4

5
delegation:
6
  model: glm-5.2          # 子任务自动走 GLM
7
  provider: custom
8

9
auxiliary:
10
  vision:
11
    model: doubao-seed-2-0-pro-260215
12
    base_url: "https://ark.cn-beijing.volces.com/api/coding/v3"
13
    timeout: 120
14
  compression:
15
    model: deepseek-v4-pro
16
  background_review:
17
    model: deepseek-v4-pro
18
  curator:
19
    model: deepseek-v4-pro