[原创] 我让 Hermes 把古法 RPC 重新炼成了高并发调度平台：r0rpc 实战-AI 助力安全-看雪安全社区

> RPC 没有死。  
> 它只是从热闹处退到了角落里，继续替很多逆向、爬虫、自动化场景扛最硬的活。

这篇文章不打算写成一本说明书。

说明书讲“怎么用”，但我更想讲清楚另一件事：为什么在协议逆向越来越重、风控链路越来越长、真机环境越来越难复刻的今天，RPC 这种看起来有点“古法”的方案，反而还有生命力。

更重要的是，这次不是单纯拿 Sekiro 改一改，也不是写一个能转发请求的玩具 demo。

这次我让 Hermes 参与设计和实现了一套自己的 RPC 调度平台：**r0rpc**。

它有后台，有权限，有账号，有 group，有 action，有设备在线状态，有请求缓存，有成功率统计，有 WebSocket 长连接，有 Xposed demo，有 Python 模拟端，有性能压测脚本，也能一键部署。

一句话概括：

> r0rpc 不是“把手机开个口子给外面调一下”。  
> 它更像是把一批手机设备接进后端体系里，变成可管理、可观测、可压测、可扩展的 RPC 资源池。

而 Hermes 最让我震惊的地方也在这里：我不是让它补一个函数，不是让它写一段示例代码，而是把一个偏工程化、偏系统设计、偏实战落地的需求丢给它，它真的能把事情拆开、推进、验证，再持续修正。

这就很离谱。

## 先说结论

如果你只想看结论，可以直接看这一段。

这不是说 Sekiro 不好。

恰恰相反，Sekiro 是这个方向里非常重要的先行者。没有它，很多人甚至不会意识到“反向长连接 + 真机执行 + 服务端调度”这条路可以这么顺。

但工具用久了，需求会变。

刚开始我们只想“能调通”。后来就会想：

- 当前到底哪台设备在线？
- 哪台设备成功率低？
- 某个 action 最近是不是异常？
- 请求参数和结果能不能回看？
- 设备断了一天再回来，能不能自动连上？
- 一堆手机同时重连，会不会把服务端打穿？
- 不想指定设备时，能不能自动轮询？
- group 不存在或者没启用，能不能直接拒绝？
- 后台能不能给别人用，还能分账号、改密码、管权限？

这些问题堆在一起，就不再是一个“RPC 客户端库”的问题，而是一个**设备 RPC 调度平台**的问题。

这就是 r0rpc 要补的空。

## Hermes 是什么

Hermes 是一个运行在终端里的 AI Agent。

普通 AI 更像问答助手，你问一句，它答一句；Hermes 更像一个能长期协作的工程同伴。它能读项目、改代码、跑命令、定位问题、补测试、调配置，并且在多轮对话里持续理解你的偏好和项目上下文。

它最强的不是“会写代码”。

会写代码的工具现在很多，但真正难的是：

- 需求很乱，它能先把需求拆清楚；
- 项目已经有代码，它能顺着已有结构改；
- 线上报错，它能从接口、路由、服务端、客户端一起排；
- 你临时改想法，它能跟着调整；
- 做完后还能压测、对比、解释结果；
- 发现硬编码、配置遗漏、重连问题，它能继续补。

这次 r0rpc 的过程很典型。

一开始我的需求其实非常长，甚至有点像“我全都要”：

```text
参考 Sekiro RPC 框架，我想写一份属于自己的 RPC。
需要高并发，有后台，后台用 Go。
能权限管理，能管理账号，能管理 action。
能缓存请求数据及结果 30 天。
能分析单个设备成功率。
能看 group 下有哪些设备。
能指定设备请求，不指定设备就轮询。
MySQL / Redis 可 Docker 安装，也能接外部。
后台界面能看到手机请求成功率。
group 后台创建好了且状态可用，才能被 app 调用。
用 WebSocket 连接。
app 断开后自动重连。
防止瞬间很多台手机打上去导致雪崩。
给 Xposed demo，给 Python 模拟 app 端。
PC 端接口也能转发。
心跳 5 秒一次，20 秒连不上就显示断开。
名字叫 r0rpc。
```

正常人工接到这种需求，第一反应大概率不是马上写代码，而是先皱眉。

因为这里面不止一个功能点，而是混着几类问题：

| 问题类型 | 实际要解决的事 |
| :-- | :-- |
| 长连接 | 手机和服务端保持 WebSocket 通道 |
| 调度 | 请求来了以后，分配给哪台设备 |
| 并发 | 同一台设备能承载多少 in-flight 请求 |
| 保活 | 心跳、超时、断线、重连 |
| 防雪崩 | 多设备同时断开后不能同时重连打爆服务 |
| 管理 | group、action、账号、权限 |
| 可观测性 | 在线状态、成功率、耗时、错误 |
| 存储 | 请求参数、响应结果、统计数据 |
| 部署 | MySQL、Redis、配置文件、Docker |
| 客户端 | Xposed、Python、PC 调用方 |

Hermes 最像人的地方就在这：它不是直接开写一个“大泥团”，而是先判断这不是普通 WebSocket 转发服务，而是一个设备 RPC 调度系统。

这一步很关键。

方向对了，后面才会越写越顺。

## 为什么 RPC 在安卓逆向里还活着

做安卓逆向和数据自动化的人，对 RPC 这条路一般都不陌生。

很多时候，我们不是不想纯协议，不是不想把加密完全还原出来，而是现实情况不允许。

有些加密链路非常长：

- Java 层有参数拼接；
- Native 层有签名；
- 设备环境参与计算；
- 登录态、滑动、心跳、风控状态互相影响；
- 一次请求前后还有上下文状态；
- 甚至同一个参数在不同机型、不同版本上表现都不一样。

这时候硬抠协议当然可以，但成本可能非常高。

RPC 的思路就很直接：

> 既然目标 App 自己能算，那就让它自己算。  
> 我们只负责把请求送进去，把结果拿出来。

它的价值不是优雅，而是有效。

在真实业务里，有效往往比优雅重要。

### RPC 的优势

RPC 最大的好处，是把复杂问题换了一个维度。

原来你要解决的是：

- 怎么复刻 App 的加密环境；
- 怎么补齐设备指纹；
- 怎么模拟行为链路；
- 怎么绕过复杂风控；
- 怎么同步版本变化；
- 怎么保证签名结果一致。

换成 RPC 后，问题变成：

- 怎么把手机接进服务端；
- 怎么稳定调度请求；
- 怎么让设备在线；
- 怎么处理并发；
- 怎么记录结果；
- 怎么发现失败。

后者仍然不简单，但它更工程化，也更可控。

尤其在下面几类场景里，RPC 很香：

说白了，RPC 是一种很实战的路线。

不一定最漂亮，但能打。

### RPC 的老问题

不过 RPC 也有自己的硬伤。

早期很多 RPC 方案更像“能用就行”的工具，单人调试很舒服，一旦进入多设备、多 action、多调用方、多并发，问题就开始暴露：

- 设备是不是在线，不够直观；
- 请求到底发给了哪台设备，不够清楚；
- group名称随便写，越用越乱；
- 成功率只能凭感觉；
- 某台设备异常，很难第一时间发现；
- 断线重连没有统一策略；
- 一堆设备同时上线，服务端容易被瞬时流量冲击；
- 没有后台权限，给别人用不方便；
- 请求参数和结果不沉淀，事后排查困难；
- 没有统一配置，部署迁移麻烦。

这些问题不解决，RPC 就永远停在“小工具”阶段。

r0rpc 要做的，就是把它往“平台”方向推一步。

## r0rpc 做了什么

r0rpc 的核心目标很简单：

> 把手机端能力，通过 WebSocket 长连接，稳定地变成服务端可调用的 RPC 能力。

整体链路大概是这样：

它不是只追求“能调通”，而是把真实使用中最容易痛的地方都补上。

### 1. 有后台，不再盲调

早期 RPC 工具最难受的一点，是很多状态只能靠猜。

设备在不在线？

哪个 group 有设备？

哪个 action 最近失败多？

某台手机是不是已经卡住？

调用方只看到“失败”，但不知道失败发生在哪里。

r0rpc 做了后台之后，这些东西就可以直接看。

后台能管理：

- 账号；
- 密码修改；
- group；
- action；
- 设备；
- 请求记录；
- 成功率；
- 在线状态；
- 请求耗时；
- 错误信息。

这对 RPC 来说提升非常大。

因为 RPC 最大的问题从来不是“跑一次”，而是“跑久了之后怎么知道哪里坏了”。

### 2. group 必须后台创建并启用

很多 RPC 工具里，group 是调用时直接传的。

这样很自由，但也很容易乱。

比如今天写 `idlefish`，明天有人写 `idle_fish`，后天又有人写 `xianyu`。短期能跑，长期就是灾难。

r0rpc 的规则更硬：

> group 必须先在后台创建，并且状态为可用，app 端才能加入。  
> 如果 group 不存在或未启用，直接提示没有这个 group。

这个设计看起来只是多了一道校验，其实是在给系统立边界。

有边界，后面才能统计、权限、审计、限流、隔离。

### 3. action 可管理，不再野蛮生长

action 是 RPC 的核心入口。

如果 action 没有管理，最后一定会变成一堆没人敢删的字符串。

r0rpc 把 action 放进后台管理，让它从“随便传一个名字”变成“平台内的受控资源”。

这样做的好处是：

- 哪些 group存在，一眼能看；
- 哪些 action 在高频调用，可以统计；
- 哪些 action 失败率高，可以定位；
- 后续要做权限控制，也有落点；
- 文档和后台能对应起来。

### 4. 支持指定设备，也支持自动轮询

真实场景里，调用方式一般有两种：

一种是指定设备：

```text
这次请求必须打到某一台手机。
```

比如这台设备登录了某个账号，或者只有它有某个状态。

另一种是不指定设备：

```text
只要 group 下有可用设备，谁空闲就谁处理。
```

这时候就需要轮询和调度。

r0rpc 两种都支持：

- 传设备 ID：指定设备处理；
- 不传设备 ID：在 group 可用设备中轮询；
- 设备不在线：直接返回明确错误；
- group 不可用：直接拒绝。

这才像一个可以长期跑的 RPC 调度层。

### 5. 请求参数和结果可回看

RPC 调试最怕什么？

最怕线上失败后只剩一句“调用失败”。

到底传了什么参数？

设备返回了什么？

中间耗时多少？

是服务端超时，还是设备端报错？

如果没有记录，排查就只能靠复现。

r0rpc 会把请求参数、响应结果、耗时、状态等信息沉淀下来。默认保留策略可以配置，文章里按 30 天这个目标设计，也支持通过配置控制保留条数。

这对实战太重要了。

RPC 一旦接入业务，就不只是“能不能请求成功”，而是要能解释每一次失败。

### 6. 成功率按设备统计

多设备场景里，总成功率没那么有用。

真正有用的是：

- 哪台设备成功率低；
- 哪台设备延迟高；
- 哪台设备经常超时；
- 哪个 action 容易失败；
- 是整体服务问题，还是单设备问题。

r0rpc 后台可以看设备维度的成功率。

这意味着你不用再靠感觉判断“这台手机是不是不太行”，而是能拿数据说话。

## 保活：RPC 平台的命门

RPC 方案真正跑起来以后，保活比很多功能都重要。

因为手机不是服务器。

它会锁屏，会断网，会被系统杀后台，会切网络，会卡死，会重启，会因为目标 App 状态异常导致 action 不响应。

所以 r0rpc 在保活上做了几件事。

### 心跳 5 秒，20 秒判离线

r0rpc 的设备连接使用 WebSocket。

设备端定期心跳：

```text
心跳间隔：5 秒
离线判定：20 秒无响应
```

这个配置的好处是上下线足够灵敏。

5 秒心跳能比较快感知设备还活着；20 秒判离线又不会因为一次网络抖动就误杀。

对后台来说，这个体验很关键。

你看到设备在线，就应该基本可信；设备掉了，也应该尽快显示出来。

### 断开一天，也应该能自动重连

这个点很实用。

设备不是只断几秒。

它可能断一分钟，断一小时，甚至断一天。

r0rpc 的客户端重连逻辑不是“一次失败就结束”，而是持续重试。只要进程还在、网络恢复、服务端可达，就会继续尝试连回去。

这才符合移动端 RPC 的真实环境。

### 防止重连雪崩

很多人写重连，会写成这样：

```text
断了 -> 立刻重连
失败 -> 立刻再连
```

单台设备没问题。

但如果是几十台、几百台设备同时断网又同时恢复，就会变成一波重连洪峰。

r0rpc 的重连思路是：

- 失败后退避；
- 加随机抖动；
- 避免所有设备同一时间打上来；
- 服务端用在线状态和超时控制兜底；
- 客户端 in-flight 有上限，避免单设备被压爆。

这就是从“小工具”到“平台”的区别。

小工具只要连得上。

平台要考虑连不上、断了、一起断、一起回来、回来以后还有大量请求排队。

## Sekiro 与 r0rpc：保活和可观测性对比

这里还是要说明一下：我使用和对比的主要是早期 Sekiro 体验，后续新版如果已经增强了后台、性能和管理能力，不在本文结论范围内。

但从我这次实测和迁移体验看，r0rpc 的优势非常直观。

我最喜欢的是可观测性这块。

以前 RPC 调不通，经常像在黑盒里摸。

现在至少能看见：

- group 是否存在；
- group 是否启用；
- 哪些设备在线；
- 请求打到了哪台设备；
- 返回是否成功；
- 失败原因是什么；
- 单设备成功率怎么样；
- P95 延迟是否升高；
- 是否已经接近设备 in-flight 上限。

看得见，才能管得住。

## 调用方式

服务端对外提供 HTTP API，调用方不用关心设备怎么连，只管发请求。

示例：

```http
POST http://159.75.100.225:9876/rpc/invoke/idlefish/decrypt
Content-Type: application/json

{
  "payload": {
    "encode_str": "v7eNwdELBmc1hOkagpP6NQ=="
  }
}
```

服务端收到请求后，会根据 group 和 action 找到可用设备。

如果你不指定设备，它会在在线设备里轮询。

如果你指定设备，它会直接发给目标设备。

响应里会带回业务结果，也会带回请求参数和耗时信息，方便调试和记录。

Python 调用大概是这种感觉：

```python
import requests

url = "http://159.75.100.225:9876/rpc/invoke/idlefish/decrypt"
seller_id = "v7eNwdELBmc1hOkagpP6NQ=="
data = {
    "payload": {
        "encode_str": seller_id,
    }
}

resp = requests.post(url, json=data, timeout=5)
resp.raise_for_status()
print(resp.json())
```

如果是 Xposed 侧，客户端初始化也尽量保持干净：

```java
RelayClient relayClient = new RelayClient(
        "159.75.100.225",
        9876,
        "admin",
        "123456",
        androidId,
        "idlefish"
);
```

`Build.MANUFACTURER` 这种平台信息不需要每次显式传，客户端默认自己取。

`maxInFlight` 默认 256，不用每次写一串链式调用，让调用代码看起来像堆配置。

这点虽小，但很影响使用体验。

## 性能测试：单设备压测

测试环境：

```text
接口：POST http://159.75.100.225:9876/rpc/invoke/idlefish/decrypt
body：{"payload":{"encode_str":"v7eNwdELBmc1hOkagpP6NQ=="}}
在线设备：1 台 Xiaomi
clientId：360e24c72173aa04
maxInFlight：256
```

压测结果：

| 并发 | 请求数 | 成功率 | 吞吐 | 平均延迟 | P95 | 结论 |
| :-- | :-- | :-- | :-- | :-- | :-- | :-- |
| 1 | 20 | 100% | 28.6 req/s | 34.8ms | 44.2ms | 很稳 |
| 5 | 50 | 100% | 113.8 req/s | 42.1ms | 88.5ms | 很稳 |
| 10 | 100 | 100% | 224.8 req/s | 41.8ms | 62.5ms | 很稳 |
| 20 | 200 | 100% | 404.9 req/s | 46.0ms | 80.6ms | 很稳 |
| 50 | 500 | 100% | 855.6 req/s | 53.7ms | 76.9ms | 效果很好 |
| 100 | 1000 | 100% | 873.6 req/s | 105.0ms | 168.8ms | 稳 |
| 200 | 2000 | 100% | 922.5 req/s | 200.1ms | 228.3ms | 稳，延迟上升 |
| 256 | 2560 | 100% | 872.1 req/s | 269.8ms | 314.2ms | 到设备上限，仍可用 |
| 512 | 1024 | 100% | 275.3 req/s | 423.0ms | 1083.3ms | 不推荐，尾延迟明显变差 |

这个结果比我预期还要好。

单台 Xiaomi 跑 decrypt，最舒服的并发区间在：

```text
推荐并发：50 - 200
可用上限：256
不建议：512
```

注意 512 并发虽然没有失败，但吞吐掉了，P95 也上来了。

这说明瓶颈不在 Go 服务端，而是在设备处理、网络排队、调用端调度和 HTTP 并发上。

所以生产环境不是并发越大越好，而是要找到设备最舒服的区间。

对这台设备来说，`maxInFlight = 256` 是一个比较合理的默认值。

## 性能测试：两台设备

后来又接了 2 台 Xiaomi，每台 `maxInFlight = 256`，理论总 in-flight 是 512。

| 并发 | 请求数 | 成功率 | 吞吐 | 平均延迟 | P95 | 结论 |
| :-- | :-- | :-- | :-- | :-- | :-- | :-- |
| 100 | 1000 | 100% | 706.9 req/s | 105.4ms | 248.6ms | 稳 |
| 200 | 2000 | 100% | 919.1 req/s | 196.8ms | 457.8ms | 稳 |
| 400 | 4000 | 100% | 982.4 req/s | 337.7ms | 592.1ms | 可用 |
| 512 | 5120 | 100% | 930.4 req/s | 485.6ms | 673.0ms | 到上限，尾延迟变高 |
| 800 | 1600 | 93.69% | 270.2 req/s | 932.1ms | 5007.9ms | 不建议，调用端连接超时 |

两台设备情况下，推荐业务并发控制在：

```text
推荐并发：200 - 400
极限可用：512
不建议：800
```

这个结果也很符合预期。

设备数上来以后，吞吐确实能继续提升，但不是无限线性增长。因为每台手机本身就是一个有限执行器，最终还是会被 CPU、目标 App、网络、Hook 逻辑、调用超时共同限制。

r0rpc 做得好的地方，是在这个限制内尽量稳定地调度，而不是让请求乱飞。

## r0rpc vs Sekiro：单设备性能对比

为了更直观，我又用同一台手机对 Sekiro 做了压测。

Sekiro 测试接口：

```python
import requests

sekiro_url = "http://159.75.100.225:5602/invoke"
data = {
    "group": "idlefish",
    "action": "decrypt",
    "encode_str": "v7eNwdELBmc1hOkagpP6NQ==",
}

resp = requests.post(sekiro_url, data=data)
print(resp.json())
```

对比结果如下：

| 并发 | r0rpc 成功率 | r0rpc QPS | r0rpc P95 | Sekiro 成功率 | Sekiro QPS | Sekiro P95 | 结论 |
| :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- |
| 1 | 100% | 28.6 | 44ms | 100% | 11.1 | 143ms | r0rpc 更快 |
| 5 | 100% | 113.8 | 89ms | 100% | 40.3 | 249ms | r0rpc 更快 |
| 10 | 100% | 224.8 | 63ms | 100% | 112.9 | 132ms | r0rpc 约 2 倍吞吐 |
| 20 | 100% | 404.9 | 81ms | 100% | 211.0 | 177ms | r0rpc 约 2 倍吞吐 |
| 50 | 100% | 855.6 | 77ms | 100% | 243.0 | 1148ms | r0rpc 明显领先 |
| 100 | 100% | 873.6 | 169ms | 24.1% | 119.8 | 5034ms | Sekiro 已明显过载 |
| 200 | 100% | 922.5 | 228ms | 未继续测 | - | - | r0rpc 仍稳定 |
| 256 | 100% | 872.1 | 314ms | 未继续测 | - | - | r0rpc 到单机上限仍可用 |

这张表最关键的不是 QPS 数字有多漂亮，而是趋势非常明显。

在低并发下，r0rpc 延迟更低。

在 10-20 并发区间，r0rpc 吞吐大概能到 Sekiro 的 2 倍左右。

在 50 并发时，r0rpc 仍然稳定，Sekiro 的 P95 已经超过 1 秒。

到 100 并发时，r0rpc 仍然 100% 成功，而 Sekiro 成功率掉到 24.1%，并且出现大量 `no enable device online` 这类问题。

如果按“舒服可用区间”看：

| 框架 | 舒服区间 | 可用上限 | 过载表现 |
| :-- | :-- | :-- | :-- |
| r0rpc | 100 - 200 并发 | 256 仍可用 | 512 开始尾延迟变差 |
| Sekiro | 10 - 20 并发 | 50 已明显吃力 | 100 并发成功率明显下降 |

这就是 r0rpc 最能打的地方。

它不是只在单次调用里快一点，而是在并发上来以后，仍然能保持成功率和可观测性。

## 为什么 r0rpc 能稳

这里不吹玄学，只看设计。

r0rpc 能稳，主要靠几件事：

### Go 后端适合长连接

Go 写这种服务很舒服。

一个设备一条连接，一个请求一个上下文，goroutine 的模型很适合处理 WebSocket 长连接和并发调度。

相比把线程池、事件循环、连接管理混在一起调，Go 的心智负担更低。

对 r0rpc 这种“长连接 + 请求分发 + 状态统计 + 后台管理”的项目来说，Go 是很合适的选择。

### in-flight 限制避免设备被打爆

手机不是无限并发机器。

你给它 1000 个请求，它不会真的变强，只会排队、超时、抖动。

r0rpc 给客户端设计了 `maxInFlight`，默认 256。

这相当于给单设备设了上限。

超过设备承载能力后，系统应该排队、拒绝或者调度到其他设备，而不是无脑继续塞。

### 服务端调度不把压力甩给调用方

调用方只管发 HTTP 请求。

设备选择、在线状态、group 校验、action 校验、超时处理，都交给服务端。

这让调用方更轻，也让平台有机会做统一治理。

### 请求结果可沉淀

性能问题不可怕。

可怕的是性能问题发生后没有证据。

r0rpc 会把请求和结果记录下来，再配合成功率和延迟统计，就能知道问题到底出在哪里。

这比“感觉今天有点慢”强太多。

## Hermes 在这个项目里到底牛在哪里

如果只看最终代码，你可能会觉得：

不就是 Go + WebSocket + MySQL + Redis + 后台吗？

但真正难的是从一个很乱的需求出发，把它变成一个能跑、能部署、能压测、能继续改的项目。

Hermes 在这个过程中很像一个不会喊累的工程搭子。

我提需求，它先拆。

我说接口 404，它去查本地路由。

我说 app 断一天会不会重连，它去看客户端重连逻辑。

我说成功率算不算设备掉线请求，它去看统计口径。

我说保留多少条请求记录，它把硬编码挪到配置。

我说 Java 初始化太丑，它把 IP 和端口拆开，把平台参数内置，把默认 `maxInFlight` 收进去。

我说要压测，它补 Python 脚本，跑 r0rpc，再跑 Sekiro，再做对比表。

这不是单次问答，这是连续工程协作。

更离谱的是，很多改动不是“写出来就完了”，而是能继续追问：

- 这个 token 过期多久？
- 每次带用户名密码会不会慢？
- 12 小时是不是太久？
- 登录接口为什么 404？
- 服务器是不是没更新？
- 本地有没有这个接口？
- Xposed APK 能不能打包？
- Python 客户端断线一天会不会重连？

它都能顺着项目往下查。

这就是 Hermes 真正的价值。

它不是替你敲几行代码，而是把你的想法推进成一个工程结果。

## AI 写代码和人工写代码的差别

这个话题必须说实话。

AI 很强，但不是魔法。

就 r0rpc 这个项目来说，AI 的优势非常明显：

- 速度快；
- 覆盖面广；
- 能快速铺出前后端和客户端；
- 能连续处理多个问题；
- 能补文档、补脚本、补配置；
- 能边压测边修。

但人工工程经验仍然重要：

- 要审架构边界；
- 要看安全细节；
- 要确认统计口径；
- 要控制配置泄露；
- 要压测极限；
- 要检查异常路径；
- 要判断哪些功能该做，哪些该收。

更直观一点：

所以我的感受不是“AI 取代工程师”。

更准确地说，是工程师多了一台非常夸张的加速器。

以前你需要先学 Go、学前端、学 WebSocket、学 Docker、学 MySQL、学 Redis、学 Xposed 接入，再一点点拼起来。

现在你可以先提出目标，让 Hermes 帮你铺出一版能跑的系统，然后你再围绕真实问题不断打磨。

这对个人开发者太友好了。

## r0rpc 当前能力清单

整理一下，当前 r0rpc 已经具备这些能力：

- Go 后端；
- WebSocket 设备长连接；
- HTTP 调用入口；
- 管理后台；
- 登录和账号管理；
- 登录后修改密码；
- group 管理；
- action 管理；
- 设备管理；
- group 启用校验；
- 指定设备调用；
- 不指定设备自动轮询；
- 请求参数回显；
- 请求结果记录；
- 请求记录保留配置；
- 单设备成功率分析；
- group 在线设备查询；
- MySQL 配置独立；
- Redis 配置独立；
- Docker Compose 一键启动；
- 支持接外部 MySQL / Redis；
- Xposed demo；
- Python app 模拟端；
- Python HTTP 调用 demo；
- Python 性能测试脚本；
- app 断线自动重连；
- 心跳 5 秒；
- 20 秒离线判定；
- 默认 `maxInFlight = 256`；
- r0rpc 与 Sekiro 性能对比数据。

这已经不是“一个 RPC demo”了。

它是一套可以继续往生产形态演进的 RPC 平台雏形。

## 一键部署和配置

配置独立出来非常重要。

数据库、Redis、保留策略、服务端口、登录账号、token 时间、请求记录保留数量，这些都不应该散落在代码里。

尤其是准备部署到不同服务器时，配置化能少踩很多坑。

MySQL 和 Redis 也不应该绑定死：

- 本地测试，可以直接用 Docker Compose；
- 线上已有数据库，可以接外部 MySQL；
- 线上已有缓存，可以接外部 Redis；
- 密码、库名、端口都通过配置改。

示例配置建议写成这种风格：

```yaml
mysql:
  host: mysql
  port: 3306
  database: new_demo
  username: root
  password: "改成自己的密码"
  charset: utf8mb4
  connMaxLifetime: 300s

redis:
  host: myredis
  port: 6379
  password: "改成自己的密码"
  db: 8

rpc:
  heartbeatInterval: 5s
  offlineAfter: 20s
  defaultMaxInFlight: 256
  requestRetentionDays: 30
  rawRequestKeepLatestPerScope: 100
```

这里建议公开文章里不要直接放真实密码。

配置可以展示结构，但密码最好用占位符。

## 这次最大的感受

以前做这类东西，流程大概是：

先找项目，跑起来，改一堆配置。

再写客户端，调 WebSocket。

再写 HTTP 转发。

再补后台。

再补数据库。

再处理断线。

再处理并发。

再写压测。

再定位为什么设备离线。

再想办法统计成功率。

一圈下来，时间就没了。

这次不一样。

我把目标说清楚，Hermes 开始拆，拆完开始写，写完开始跑，跑不通就查，查完继续改，改完继续压测。

整个过程最爽的地方是：我不需要一次性成为 Go 后端、前端、Android、Xposed、运维、压测全栈高手。

我只需要知道我要什么，然后持续提出判断和修正。

Hermes 负责把大量工程体力活推过去。

这就是它最牛的地方。

## 结语

RPC 不是银弹。

它解决不了所有问题，也不适合所有场景。

但在安卓逆向、真机自动化、复杂加密调用、强风控链路里，它仍然是一条非常有价值的路线。

Sekiro 证明了这条路能走。

r0rpc 想做的是，把这条路继续往工程化、平台化、可观测、高并发方向推一步。

而 Hermes 让我最直观地看到了一件事：

> 个人开发者的工程上限，正在被 AI Agent 重新抬高。

以前一个人想做一套 RPC 平台，可能需要很长时间。

现在你可以先做出来，再压测，再修，再完善。

从想法到能跑，从能跑到能看，从能看到能压，从能压到能对比，这个链路被大幅缩短。

这就是 Hermes。

这也是 r0rpc 这次最值得记录的地方。

项目地址：

```text
https://github.com/manyuegong33/r0rpc
```

感谢 r0ysue 大佬的指导，也感谢 virjar 大佬和 Sekiro 项目给这个方向提供的启发。

没有这些开源和经验铺路，很多新人要多走非常多弯路。

附：

```text
Sekiro 新版文档：https://sekiro.iinti.cn/sekiro-doc/
```

如果后续反馈不错，我会继续完善保活 App、事件重放、更多设备调度策略、更多后台统计能力，把 r0rpc 继续往真正可用的设备 RPC 平台方向推进。

## 附录一：Hermes 安装与配置

前面讲了这么多 r0rpc，其实还有一条暗线更值得记录：这套东西不是我一个文件一个文件硬啃出来的，而是 Hermes 一路参与拆需求、写代码、改配置、跑压测、修问题推出来的。

所以这里把 Hermes 的安装过程也放出来。不是为了写成工具手册，而是想让读者能复刻这个体验：先把 Agent 跑起来，再把一个复杂工程目标丢给它，让它陪你把东西真正落地。

本次环境：

- Python 3.12.0
- Windows + cmder：<mark class="encrypted">9beK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0L8h3c8W2M7W2)9J5k6h3q4H3M7q4)9J5c8R3`.`.</mark>

安装步骤很简单：

```bash
git clone https://github.com/NousResearch/hermes-agent.git
cd hermes-agent
pip install .
```

![](upload/attach/202606/917874_K7Z9AJN4JE2J8U2.webp)

接下来准备模型 API。这里我用的是 DeepSeek，注册入口如下：

```text
https://platform.deepseek.com/usage
```

流程大概是：注册账号 -> 充值 -> 进入 API keys -> 创建 key。

注意一点：API key 通常只在创建时完整显示一次，创建后先保存好，再关闭页面。公开文章、截图、仓库配置里都不要直接放真实 key。
 ![](upload/attach/202606/917874_UH7ZZSFJDK8DSBH.webp)

Hermes 配置示例：

```bash
hermes config set api_key sk-xxxxxxxxxxxxxxxx
hermes config set provider deepseek
hermes config set model deepseek-v4-pro
hermes config set base_url https://api.deepseek.com
```

如果你用的模型名和我不一样，把 `model` 改成自己账号当前可用的模型即可。这里重点不是绑定某个模型，而是让 Hermes 能稳定接上模型服务。

![](upload/attach/202606/917874_JK5Z37ND3VUKNXB.webp)

配置完成后，直接进入对话模式：

```bash
hermes chat
```

我这里随手让它写一个 Python 单例，能正常输出，就说明环境已经跑通了。

![](upload/attach/202606/917874_BHXYBG722WMWYUY.webp)

到这一步，Hermes 就不是一个“网页聊天框”了，而是能在本地终端里参与工程协作的 Agent。它能读项目、执行命令、修改文件、看报错、继续追问题。r0rpc 后面那些 Go 服务端、后台、WebSocket、Xposed demo、Python 模拟端、压测脚本和配置修正，都是在这种协作方式下被一点点推起来的。

## 附录二：r0rpc 后台展示

r0rpc 搭起来之后，后台默认访问地址是：

```text
http://你的服务器 IP:9876/
```

为了方便大家先看效果，我这里临时搭了一个演示地址：

```text
http://159.75.100.225:9876/
```

真正部署到自己服务器时，建议第一时间修改默认账号密码，检查 MySQL / Redis 密码，避免把管理后台长期裸露在公网。

登录页长这样：

登录后能看到后台主界面。这里不是单纯做了一个“能登录的壳”，而是把 RPC 最需要管理的东西都摆到了台面上：账号、group、client、action、请求记录、在线状态和统计数据。

![](upload/attach/202606/917874_46ZS2UYP5QMB5JE.webp)
在 group / client 这些页面里，可以很直观看到当前设备接入情况。哪些设备在线、属于哪个 group、最近状态怎么样，不再靠日志里翻，也不再靠调用方自己猜。

![](upload/attach/202606/917874_BYPV6UE9JQEUV92.webp)

这几张后台截图其实很关键。

早期 RPC 工具最容易给人的感觉是“能用，但黑盒”。请求发出去了，设备有没有在线、action 有没有配置、group 写没写错、失败到底发生在哪一层，都需要自己排。

r0rpc 想解决的就是这个痛点：

- group 在后台创建并启用后，客户端才能加入；
- client 在线状态可以直接看；
- action 能统一管理，不再靠字符串野蛮生长；
- 请求参数、返回结果、耗时、成功率都能沉淀；
- 多设备场景下，可以按设备看表现，而不是只看总成功率；
- 服务端统一调度，请求方不用关心背后是哪台手机在处理。

所以我前面一直说，r0rpc 不是“又写了一个 RPC 转发 demo”。

它真正想做的是把真机 RPC 这件事，从临时工具推进到平台形态：能接设备，能看状态，能管资源，能压并发，能定位问题，也能继续扩展。

这也是 Hermes 在这次项目里最让我有感觉的地方。它不是只把某个函数写出来，而是一路把“我想要一套自己的 RPC 平台”这个很散的想法，推成了一个有后台、有部署、有客户端、有压测数据、有截图证据的工程结果。

登录后可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 2026-6-1 11:37 被manyuegong33编辑，原因：直接全部可见

上传的附件：

r0rpc.md （34.76kb，25次下载）

最新回复 (10)
Noguess9 雪币： 17 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 30 粉丝 0 关注私信	Noguess9 2 楼 6666 好文 2026-6-1 10:19 0
天道happy 雪币： 227 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 23 粉丝 0 关注私信	天道happy 3 楼大佬带带弟弟 2026-6-1 10:21 0
727 雪币： 53 活跃值： (477) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 11 粉丝 11 关注私信	727 4 楼 2026-6-1 10:31 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 693 粉丝 7 关注私信	mb_ldbucrik 5 楼好东西，感谢分享 2026-6-1 11:03 0
roysue 雪币： 3907 活跃值： (7346) 能力值： ( LV12，RANK：200 ) 在线值：发帖 108 回帖 517 粉丝 727 关注私信	roysue 3 6 楼 666 2026-6-1 11:04 0
看雪高研雪币： 176 活跃值： (7830) 能力值： (RANK：10 ) 在线值：发帖 15 回帖 110 粉丝 208 关注私信	看雪高研 7 楼 666 2026-6-1 11:06 0
Imxz 雪币： 112 活跃值： (9435) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 754 粉丝 9 关注私信	Imxz 8 楼 tql 2026-6-1 16:30 0
manyuegong33 雪币： 427 活跃值： (340) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 59 粉丝 11 关注私信	manyuegong33 9 楼 Imxz tql 互相学习 2026-6-1 22:08 0
manyuegong33 雪币： 427 活跃值： (340) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 59 粉丝 11 关注私信	manyuegong33 10 楼 mb_ldbucrik 好东西，感谢分享看的人多我后面继续更自动化这块 2026-6-1 22:08 0
git_29595xiaozhimengmengda 雪币： 348 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 3 粉丝 0 关注私信	git_29595xiaozhimengmengda 11 楼学习了，感谢分享 2026-6-16 16:45 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复