2026-10-12
Linux 启动基准：来自 #1998 的社区快照
@CassieFox23 发表了 Linux 上 REA 服务启动有多快（讨论创建于 2026-10-12；针对 6.4.0 与 main 尖端 13e03e943 更新）。本页转述方法并抄录已公布数字——不编造基准。若未本地复现，表格视为社区报告，待你复现。
方法（作者所述）
- 宿主：Linux；计时为自进程启动的秒数。
- 先预热，再取 5 次计时中位数；括号为已公布的最小–最大。
- 以 node + 包脚本启动（非 npx 路径），确保 Node 版本确定。
- 启动表未接客户端配置，未接 Ghidra／Hopper／IDA。
- 未跑：macOS／Windows、冷磁盘缓存、其他 Node、npx 路径。
Tool-list 表（抄自 #1998）
| 目标 | 工具数 | Node | Tool list 中位（最小–最大） | Init 中位 |
|---|---|---|---|---|
| 6.3.0 | 139 | 22 | 1.90（1.88–1.91） | 1.68 |
| 6.3.0 | 139 | 24 | 1.59（1.56–1.61） | 1.39 |
| 6.3.0 | 139 | 26 | 1.38（1.37–1.42） | 1.21 |
| 6.4.0 | 170 | 22 | 2.16（2.12–2.17） | 1.84 |
| 6.4.0 | 170 | 24 | 1.75（1.72–1.80） | 1.48 |
| 6.4.0 | 170 | 26 | 1.55（1.52–1.58） | 1.31 |
main 13e03e943 | 170 | 22 | 1.78（1.76–1.80） | 1.47 |
main 13e03e943 | 170 | 24 | 1.47（1.46–1.50） | 1.21 |
main 13e03e943 | 170 | 26 | 1.30（1.28–1.33） | 1.06 |
main 相对 6.4.0 的 list（作者推导列）
| Node | 6.4.0 | main | 节省 | 加快 |
|---|---|---|---|---|
| 22 | 2.16 s | 1.78 s | 0.38 s | 17.8% |
| 24 | 1.75 s | 1.47 s | 0.28 s | 16.0% |
| 26 | 1.55 s | 1.30 s | 0.26 s | 16.5% |
讨论解读（转述）：6.4.0 的 list 比 6.3.0 慢 0.17–0.26 秒，同时多 31 个工具（170 vs 139）。main 尖端 list 比 6.4.0 快 16–18%。每个目标上 Node 26 最快、Node 22 最慢。反向顺序复查未使 tool-list 中位移动超过 0.04 秒。
首个真实任务（仅 Node 24）— 抄录
自进程启动到任务回复的秒数；5 次中位；括号为任务本身（回复减 tool-list 回复）：
| 任务 | 6.3.0 | 6.4.0 | main 13e03e943 |
|---|---|---|---|
| 浏览器捕获 | 1.76（0.49） | 1.89（0.50） | 1.91（0.71） |
| 脚本分析 | 3.35（2.10） | 3.95（2.51） | 3.63（2.46） |
| Android 应用扫描 | 失败 | 2.03（0.66） | 1.79（0.64） |
| Ghidra 概览 | 7.49（6.31） | 7.62（6.30） | 7.45（6.36） |
作者说明：main 上将 Playwright 加载从启动挪到首次捕获（#1691 语境）；首次捕获可能吃掉 list 节省。6.3.0 Android 失败信息：路径碰撞 res/2f.xml vs res/2F.xml。同一 Coffee 应用文件上 6.4.0／main 成功。
#1998 点名的开源夹具
| 任务 | 夹具（原文） | 备注 |
|---|---|---|
| 脚本分析 | Stretchly 1.22.1 的 app/main.js（BSD-2-Clause） | 整包回复超 10 MiB；单文件 + REA_MCP_MAX_RESPONSE_BYTES=268435456 |
| Android 扫描 | Coffee 2.27（coffee_47.apk，Apache-2.0） | 讨论公布 SHA-256 |
| Ghidra 概览 | 自写 3 行 C → ELF（t.c） | 讨论公布 SHA-256 |
如何重跑（讨论附录）
mkdir -p /tmp/rea-bench/6.4.0
npm install --no-save --prefix /tmp/rea-bench/6.4.0 [email protected]
# 作者使用本地 mcp-time.mjs（1 次预热 + 5 次计时）。
# 请优先用讨论 #1998 链接的脚本，不要自造计时器冒充数据。
main：归档 13e03e943，npm ci && npm run build，再计时 scripts/rea.mjs。负载门控示例：负载均值 ≤ 2.0 才开跑（文中提及 24 线程机器）。
运维读法
- 更多工具 ≠ 业务更慢——6.4 的 Android 扫描变好，即使 list 更贵。
- Node 对齐上游支持线（讨论用 22／24／26；README 脉动常见 22.19+／24.11+／26+）。
- 交叉 /zh/docs/linux-fedora/#startup 与 /zh/blog/rea-agents-6-4-0/。
- 公开基准勿塞商业二进制。
合规
- 引用 @CassieFox23；不编造行。
- 公开文仅用开源夹具。
- 扩展基准时仅授权／自有目标——/zh/compliance/。
来源
数字核对清单
- 工具数是否仍写 139／170，并链到 #1998？
- 是否写明预热 + 5 次中位，而非单次玄学？
- 是否区分 list 延迟与首任务？
- 夹具是否仅 Stretchly／Coffee／自写 C？
- 未跑项（macOS／Windows／冷缓存／npx）是否列出？
- 有无「待你复现」免责声明？
把本页当作引用层：对外分享时附讨论链接与 commit 13e03e943；若你复现出不同数字，以你的环境日志为准并开 issue／讨论更新，而不是改写他人表格却不署名。
与 /zh/blog/rea-agents-6-4-0/ 对照：list 变慢可以与 Android 扫描变好同时成立——这正是运维需要两张表的原因。
我们拒绝编造什么
- macOS vs Linux 的绝对排名（#1998 启动表未覆盖）。
- npx 路径计时（作者明确未在主表跑）。
- 商业 APK 基准。
- 超出 #1998 对 #1691 定性描述的逐 commit 微基准。
若社交截图秒数不同，先问 Node 版本、commit／tag、热／冷缓存与负载——讨论已表明同一机器在不同轮次可打出 6.4.0 list 的 1.75 s 与 1.38 s。
完整引用格式建议：CassieFox23 / morluto/rea discussion #1998 / 2026-10-12 / main tip 13e03e943。二级传播时保留该字符串，避免数字变成「听说」。
运维落地：把 list 中位与 Android 首任务中位写进内部 runbook 的「预期区间」栏，并标注来源；新机器入职先复现两行（Node 24 的 6.4.0 list + Android scan），再谈优化。
把 #1998 变成内部验收清单
- 记录机器型号、CPU、RAM、磁盘类型与当前负载。
- 安装 Node 22、24、26（或团队允许的子集）并用
node -v写入日志。 - 对每个 Node：冷启动
npx -y [email protected]与本地 clone tip（若有），各跑 ≥3 次 list／version。 - 表格列：Node、分发、命令、秒数、是否热缓存、备注。
- Android 行：仅授权设备／模拟器；记录首次
android_device_info／android_scan_apk墙钟。 - 与 #1998 对照：方向一致即可签字；方向相反则贴负载与版本再开讨论。
与 6.4.0 发行页交叉引用
启动秒数解释「为什么升级／钉住」；发行页解释「升级后能做什么（ADB、JEB BYO、compact schema）」。两篇应一起链给新同学，避免只看营销句。
合规（基准篇再声明）
基准夹具必须是自有构建、公开无 DRM 样本或书面授权目标。禁止把他人商业 APK 的秒数发到公开渠道当「成绩」。REA 与本站不背书破解排行。