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 的过程很典型。

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

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

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

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

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 能力。

整体链路大概是这样：

调用方
  |
  | HTTP API
  v
r0rpc Go 服务端
  |
  | group / action / device 调度
  v
在线设备池
  |
  | WebSocket
  v
Xposed / Python / App 客户端
  |
  | 执行业务 action
  v
返回结果、耗时、错误、请求参数

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

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. 支持指定设备，也支持自动轮询

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

一种是指定设备：

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

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

另一种是不指定设备：

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

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

r0rpc 两种都支持：

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

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

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

RPC 调试最怕什么？

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

到底传了什么参数？

设备返回了什么？

中间耗时多少？

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

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

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

这对实战太重要了。

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

6. 成功率按设备统计

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

真正有用的是：

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

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

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

保活：RPC 平台的命门

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

因为手机不是服务器。

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

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

心跳 5 秒，20 秒判离线

r0rpc 的设备连接使用 WebSocket。

设备端定期心跳：

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

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

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

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

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

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

这个点很实用。

设备不是只断几秒。

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

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

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

防止重连雪崩

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

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

单台设备没问题。

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

r0rpc 的重连思路是：

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

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

小工具只要连得上。

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

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

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

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

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

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

现在至少能看见：

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

看得见，才能管得住。

调用方式

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

示例：

POST fc0K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5#2z5g2)9J5k6e0M7#2i4K6u0W2x3e0l9H3i4K6u0W2x3U0t1#2i4K6y4m8z5e0R3%4y4W2)9J5c8Y4u0H3j5#2)9J5c8X3W2F1N6X3!0C8k6g2)9J5c8X3W2V1L8r3g2X3K9i4y4Z5i4K6u0r3k6r3g2U0M7Y4W2H3N6l9`.`.
Content-Type: application/json

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

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

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

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

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

Python 调用大概是这种感觉：

import requests

url = "fccK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5#2z5g2)9J5k6e0M7#2i4K6u0W2x3e0l9H3i4K6u0W2x3U0t1#2i4K6y4m8z5e0R3%4y4W2)9J5c8Y4u0H3j5#2)9J5c8X3W2F1N6X3!0C8k6g2)9J5c8X3W2V1L8r3g2X3K9i4y4Z5i4K6u0r3k6r3g2U0M7Y4W2H3N6l9`.`."
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 侧，客户端初始化也尽量保持干净：

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

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

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

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

性能测试：单设备压测

测试环境：

接口：POST 1a9K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5#2z5g2)9J5k6e0M7#2i4K6u0W2x3e0l9H3i4K6u0W2x3U0t1#2i4K6y4m8z5e0R3%4y4W2)9J5c8Y4u0H3j5#2)9J5c8X3W2F1N6X3!0C8k6g2)9J5c8X3W2V1L8r3g2X3K9i4y4Z5i4K6u0r3k6r3g2U0M7Y4W2H3N6l9`.`.
body：{"payload":{"encode_str":"v7eNwdELBmc1hOkagpP6NQ=="}}
在线设备：1 台 Xiaomi
clientId：360e24c72173aa04
maxInFlight：256

压测结果：

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

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

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

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

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

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

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

性能测试：两台设备

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

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

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

这个结果也很符合预期。

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

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

r0rpc vs Sekiro：单设备性能对比

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

Sekiro 测试接口：

import requests

sekiro_url = "946K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5#2z5g2)9J5k6e0M7#2i4K6u0W2x3e0l9H3i4K6u0W2x3U0t1#2i4K6y4m8y4e0j5H3x3W2)9J5c8X3W2F1N6X3!0C8k6b7`.`."
data = {
    "group": "idlefish",
    "action": "decrypt",
    "encode_str": "v7eNwdELBmc1hOkagpP6NQ==",
}

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

对比结果如下：

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

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

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

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

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

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

这就是 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；
• 密码、库名、端口都通过配置改。

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

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 这次最值得记录的地方。

项目地址：

03eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0j5h3&6&6N6h3g2Y4L8$3&6Y4x3K6y4Q4x3V1k6J5x3s2u0H3j5H3`.`.

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

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

附：

Sekiro 新版文档：8caK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6K6k6h3E0A6M7X3!0Q4x3X3g2A6K9h3&6@1K9g2)9J5k6h3y4F1i4K6u0r3M7$3g2C8K9i4u0G2i4K6u0V1k6r3!0U0i4K6u0r3

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

附录一：Hermes 安装与配置

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

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

本次环境：

• Python 3.12.0
• Windows + cmder：ffdK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0L8h3c8W2M7W2)9J5k6h3q4H3M7q4)9J5c8R3`.`.

安装步骤很简单：

git clone 870K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6z5L8%4g2K6f1X3g2K6k6h3q4J5j5$3S2Q4x3V1k6Z5k6i4u0E0k6i4y4Q4x3X3c8S2k6$3g2F1N6q4)9J5k6h3N6A6N6l9`.`.
cd hermes-agent
pip install .

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

882K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6H3L8r3q4@1k6X3!0J5L8g2)9J5k6h3c8W2k6i4m8K6k6h3g2C8i4K6u0W2j5$3!0E0i4K6u0r3N6i4y4S2k6$3f1`.

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

注意一点：API key 通常只在创建时完整显示一次，创建后先保存好，再关闭页面。公开文章、截图、仓库配置里都不要直接放真实 key。

Hermes 配置示例：

hermes config set api_key sk-xxxxxxxxxxxxxxxx
hermes config set provider deepseek
hermes config set model deepseek-v4-pro
hermes config set base_url d34K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2M7r3W2Q4x3X3g2V1k6h3g2H3M7$3g2W2K9#2)9J5k6h3y4G2L8b7`.`.

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

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

hermes chat

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

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

附录二：r0rpc 后台展示

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

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

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

ef1K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5#2z5g2)9J5k6e0M7#2i4K6u0W2x3e0l9H3i4K6u0W2x3U0t1#2i4K6y4m8z5e0R3%4y4W2)9J5c8R3`.`.

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

登录页长这样：

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

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

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

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

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

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

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

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

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

上传的附件：

• r0rpc.md （34.76kb，0次下载）