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

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

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

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

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

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

一句话概括：

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

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

这就很离谱。

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

这不是说 Sekiro 不好。

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

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

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

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

这就是 r0rpc 要补的空。

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

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

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

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

这次 r0rpc 的过程很典型。

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

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

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

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

这一步很关键。

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

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

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

有些加密链路非常长：

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

RPC 的思路就很直接：

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

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

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

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

原来你要解决的是：

换成 RPC 后，问题变成：

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

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

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

不一定最漂亮，但能打。

不过 RPC 也有自己的硬伤。

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

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

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

r0rpc 的核心目标很简单：

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

整体链路大概是这样：

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

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

设备在不在线？

哪个 group 有设备？

哪个 action 最近失败多？

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

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

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

后台能管理：

这对 RPC 来说提升非常大。

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

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

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

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

r0rpc 的规则更硬：

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

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

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

action 是 RPC 的核心入口。

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

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

这样做的好处是：

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

一种是指定设备：

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

另一种是不指定设备：

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

r0rpc 两种都支持：

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

RPC 调试最怕什么？

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

到底传了什么参数？

设备返回了什么？

中间耗时多少？

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

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

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

这对实战太重要了。

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

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

真正有用的是：

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

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

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

因为手机不是服务器。

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

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

r0rpc 的设备连接使用 WebSocket。

设备端定期心跳：

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

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

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

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

这个点很实用。

设备不是只断几秒。

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

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

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

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

单台设备没问题。

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

r0rpc 的重连思路是：

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

小工具只要连得上。

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

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

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

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

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

现在至少能看见：

看得见，才能管得住。

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

示例：

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

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

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

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

Python 调用大概是这种感觉：

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

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

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

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

测试环境：

压测结果：

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

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

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

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

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

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

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

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

这个结果也很符合预期。

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

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

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

Sekiro 测试接口：

对比结果如下：

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

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

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

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

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

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

这就是 r0rpc 最能打的地方。

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

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

r0rpc 能稳，主要靠几件事：

Go 写这种服务很舒服。

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

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

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

手机不是无限并发机器。

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

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

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

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

调用方只管发 HTTP 请求。

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

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

性能问题不可怕。

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

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

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

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

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

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

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

我提需求，它先拆。

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

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

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

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

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

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

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

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

它都能顺着项目往下查。

这就是 Hermes 真正的价值。

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

这个话题必须说实话。

AI 很强，但不是魔法。

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

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

更直观一点：

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

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

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

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

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

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

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

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

配置独立出来非常重要。

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

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

MySQL 和 Redis 也不应该绑定死：

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

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

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

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

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

再写客户端，调 WebSocket。

再写 HTTP 转发。

再补后台。

再补数据库。

再处理断线。

再处理并发。

再写压测。

再定位为什么设备离线。

再想办法统计成功率。

一圈下来，时间就没了。

这次不一样。

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

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

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

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

这就是它最牛的地方。

RPC 不是银弹。

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

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

Sekiro 证明了这条路能走。

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

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

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

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

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

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

这就是 Hermes。

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

项目地址：

[内核课程]《Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。