用鹈鹕骑车测试 Mac mini6 32 G 上的三个本地模型

摘要

同一句提示词「制作鹈鹕骑自行车动画」，在 mini6 上让三个模型各运行一次。

• Strata + Qwen3.8-Flash-Next（125B MoE、2-bit）：3 分 20 秒输出一个 6.4 KiB 的纯 CSS 页面。页面用块级元素拼装，结构简单，动画正常运行，几何检查未发现错误旋转。

• Ollama qwen3.8:27b-mlx：8 分 05 秒输出一个 15.6 KiB 的分层 SVG 页面。页面包含完整的自行车结构和分层场景，但前轮、后轮和曲柄的旋转原点错误。

• Ollama gemma4:12b-mlx：1 分 14 秒输出一个 5.5 KiB 的 SVG 页面。两个轮子位于同一个组内，绕画布中心一起旋转。

三个页面都能加载并播放动画，未记录运行时错误。Qwen 与 Gemma 的故障表现为元素绕错误原点旋转，浏览器不会就此报错。

一、测试条件

三个轮次的调用方式不同：

• Strata 使用 Web Chat，完整 HTML 直接出现在回答正文中，没有工具调用。

• 两个 Ollama 轮次在 mini6 上运行。截图只显示了模型标签 Qwen 3.8 27B MLX (64k) 和 Gemma 4 12B MLX (64k)，没有显示客户端应用名，本文按模型标签区分。Qwen 轮次开启工具，自己写入文件并打开浏览器；Gemma 轮次只把代码贴在聊天中。

Strata 轮次运行期间，siltop 记录到内存占用 26.0/32.0 GB，swap 已用 16.8 GB。表中的耗时对应这次运行环境，不作为不同设备之间的基准。

二、结果总表

Strata 轮次的应用侧统计

Qwen 27B 轮次的应用侧统计

Gemma 12B 轮次的应用侧统计

两项补充数据：

• Gemma 轮次为 2,709 token / 74 秒，按应用侧计数计算为 36.6 tok/s。10-13 裸跑记录为 34.85 tok/s。

• Qwen 轮次的应用界面只记录末条消息 472 token，正文代码由工具调用写入，总 token 数没有记录。

三、逐版复盘

3.1 Strata：div 拼装，几何正常

Strata 版渲染

这一版全部用 div 和 CSS 拼装：

• 车轮是 border-radius: 50% 的圆，辐条由 ::after 上的 repeating-linear-gradient 绘制。车轮容器不旋转，旋转的是内部辐条层。

• 车架是一个红色圆角方块，车座和车把各用一个小方块表示。鹈鹕由三个圆和一个圆角矩形嘴组成。

• 页面包含 8 项动画：辐条旋转、车身上下浮动、翅膀扇动、喙部轻啄、两条腿交替摆动、云层漂移、路面虚线滚动、速度线闪烁。

• 回答附有一张动画说明表，逐项写明元素和动作，与代码一致。

页面结构有限：比例与真实自行车不一致；没有曲柄和脚踏，两条腿原地摆动；鸟身位于车架上方，没有与车座接触。该版本是三个页面中唯一通过几何检查的页面。

几何结果：.wheel 和 .bike 的最大中心漂移均为 3.0 px，与车身 translateY(-3px) 的浮动一致；最大尺寸漂移为 0；报告中的 suspect_wrong_pivot 为空。

3.2 Qwen 27B：结构完整，旋转原点错误

Qwen 版连续六帧（真实时间）

这一版包含完整的自行车结构和分层场景：

• 太阳、六朵云、远山、路边小树和路面虚线分别以不同速度滚动，形成视差。

• 自行车包含下管、上管、座管、前叉、后下叉、辐条轮、曲柄和脚踏，鹈鹕的蹼足位于脚踏上。

• 鹈鹕有喉囊、眼睛高光、尾羽和扇动的翅膀，并带有一个气泡台词。

• 模型自己写入文件、打开浏览器，并在回复中列出可调参数所在的行。

几何上，前轮、后轮和曲柄都绕错误原点旋转：

• 前轮最大中心漂移 749.8 px，尺寸漂移 48.8 px。

• 后轮最大中心漂移 361.0 px，尺寸漂移 48.8 px。

• 曲柄最大中心漂移 597.4 px，尺寸漂移 68.2 px。

帧条中，前轮没有留在前叉上，而是绕画布右上方的一个点旋转；曲柄和两只脚随同一组一起偏移。后轮也有 361.0 px 的漂移，只是幅度小于前轮。

3.3 Gemma 12B：输出最快，轮组绕错原点

Gemma 版两帧对比

这一轮用时 1 分 14 秒，输出 5.5 KiB、165 行，没有开启工具。模型把 HTML 贴在聊天中，需要用户自己保存为 pelican.html。

页面使用浅青背景、白色卡片、圆角画布、红色车架和虚线辐条。几何和结构存在以下问题：

• 两个轮子位于同一个 <g class="wheel"> 内，绕同一个点旋转。t=0.07 s 时两轮左高右低，t=1.32 s 时变为右高左低。

• 车架与轮心不对齐，鸟身悬在车架上方，腿部悬空，没有脚踏和曲柄。

• 整组从左向右平移 700 px，并放大到 1.2 倍；路面不滚动。

• 标题写「鹈鹕的环球旅行」，图标使用骑车男 emoji。

几何结果为 .wheel 最大中心漂移 132.5 px，最大尺寸漂移 114.7 px，报告判定为 suspect_wrong_pivot。

四、旋转原点参考系

两个失败页面都使用了错误的 transform-origin 参考系，具体写法不同。

4.1 Gemma：两个轮子共用同一个组

1
2
3
4

.wheel {
  animation: rotateWheel 1s linear infinite;
  transform-origin: center;
}

1
2
3
4

<g class="wheel">
  <circle cx="50"  cy="150" r="30" />
  <circle cx="150" cy="150" r="30" />
</g>

这里有两个问题：

01两个轮子位于同一个 <g> 内，只能作为一个整体旋转，无法分别绕各自轮心旋转。

02.wheel 设置了 transform-origin: center，但没有设置 transform-box。SVG 元素的 transform-box 默认是 view-box，因此 center 指的是 viewBox="0 0 200 200" 的中心 (100,100)，不是两个轮心。

结果，轮组以 1 秒为周期绕 (100,100) 旋转，两个轮心到该点的距离均为 70.7 个用户单位。实测中心漂移为 132.5 px，尺寸漂移为 114.7 px，与画面中的高低翻转对应。

4.2 Qwen：fill-box 与内联像素原点同时使用

1
2
3
4
5
6
7
8
9
10

.wheel {
  transform-box: fill-box;
  transform-origin: center;
  animation: spin .55s linear infinite;
}

.crank {
  transform-box: fill-box;
  transform-origin: center;
}

1
2
3

<g class="wheel" style="transform-origin:150px 300px">   <!-- 后轮 -->
<g class="wheel" style="transform-origin:510px 300px">   <!-- 前轮 -->
<g class="crank" style="transform-origin:330px 300px">

内联样式的优先级高于样式表，所以 HTML 中的 150px 300px、510px 300px 和 330px 300px 覆盖了 CSS 中的 center。

同时，transform-box: fill-box 把原点的参考系改为元素自身包围盒。这里的像素值从包围盒左上角起算，而代码中的数值按整张 SVG 的用户坐标编写。两套坐标混用后，三个旋转原点都落在元素包围盒之外。

本次几何结果：

修正方向是让每个旋转部件单独成组，并让旋转原点使用同一套参考系：

1
2
3
4
5

.wheel,
.crank {
  transform-box: fill-box;
  transform-origin: center;
}

1
2
3

<g class="wheel">前轮</g>
<g class="wheel">后轮</g>
<g class="crank">曲柄</g>

Qwen 版需要删除内联的像素原点。若某个部件不能使用包围盒中心，应按 fill-box 重新计算原点，不能继续套用 SVG 用户坐标。本文没有对修正后的页面重新运行几何检查。

4.3 三份实现的差异

三份输出的实现方式不同：

• Strata 的旋转对象是每个轮子内部的辐条伪元素。两个轮子分别位于独立的块级盒中，使用 CSS 盒的默认中心原点。

• Qwen 使用 SVG fill-box，同时保留了按 SVG 用户坐标编写的内联像素原点。

• Gemma 把旋转动画加在包含两个轮子的 SVG 组上，并使用默认的 view-box 原点。

本次出现的几何故障与上述写法对应。三份输出在结构复杂度、代码量和交付速度上也有差异：Qwen 包含最多的自行车结构和文案，Gemma 输出量最小、耗时最短，Strata 是唯一通过几何检查的页面。

五、结论

本次结果按用途归纳：

• 需要一次交付即可运行的动画：Strata + Qwen3.8-Flash-Next 的页面通过几何检查。耗时 3 分 20 秒，输出速度 14.7 tok/s。

• 需要完整自行车结构和较多画面细节：qwen3.8:27b-mlx 的输出包含最多结构元素和文案，但当前文件有三个旋转原点错误。修正时需要拆分轮组、删除内联像素原点，并重新执行几何检查。

• 需要一分钟内的代码草稿：gemma4:12b-mlx 用时 1 分 14 秒。当前文件未通过几何检查，使用前需要把两个轮子拆成独立组，并分别设置原点。

可以把以下条件直接写进生成提示词：

每个会旋转的部件单独成组；旋转统一使用 transform-box: fill-box; transform-origin: center;，不要写 px 原点；不要把一个以上的轮子放进同一个组。交稿前检查：任一旋转部件在动画一周内，除设计位移外的包围盒中心漂移应小于 3 px。

以上结论只对应本次三个输出，不外推到模型在其他提示词、其他代码结构或其他硬件条件下的表现。

六、局限

• 每个模型只运行一次，使用同一句提示词，没有控温、固定种子或重复取均值。表中的数字不是稳定基准。

• 评估范围是页面结构和动画几何，没有做审美评分。

• Strata 轮次运行期间内存占用 26.0/32.0 GB、swap 16.8 GB，耗时不能与其他设备条件直接比较。

• 两个 Ollama 轮次的截图没有显示客户端应用名；工具调用次数取自界面显示，没有结构化调用日志。

• Qwen 轮次没有记录总 token 数。

• 修正后的代码没有重新测试。

可复核材料

• 三个原始页面：/Users/mac/tmp/bike2.html（Strata）、/Users/mac/tmp/bike.html（Gemma）、/Users/mac/Downloads/pelican-bike.html（Qwen）

• 几何自检脚本：00_META/scripts/check-web-anim-geometry.py（纯标准库，本机 Chrome 即可运行）

• 自检报告：assets/2026-10-24-mini6-pelican-bike/geometry-report.json

• 渲染帧与对比图：同目录 render-*.png；应用侧统计截图：ui-*.png

• 应用侧原始截图：~/Desktop/ 下 strata*.png、qwen3.8-27b-mlx.png、gemma4-12b-mlx*.png

• 相关记录：2026-10-18-mini6-strata-qwen3.8-flash-next-q2_0-deployment-and-capability-test.md、01_AREAS/learning/2026-10-13-hermes-local-model-benchmark-review.md

让你的智能体给安卓电视换个无广告清爽界面

下面这段提示词，复制到你自己的智能体里就能用。前提只有三条：一台安卓电视、电视上的 ADB 调试已经打开、电脑和电视连在同一个网络。

1
2

我的电视地址是 192.168.8.144，已经打开 adb 模式。按照
github.com/Gathin23/cleanyourtv 说明更新电视桌面

把地址换成你自己电视的。电视的 IP 在电视的网络设置里能看到。

这段提示词干的事，不是刷机。它只是通过局域网让电视把一些预装应用「停用」，停用以后图标消失、进程不再跑，但安装包还在系统里，随时能开回来。不 root，不改固件，不丢数据。

我拿家里那台小米电视走了一遍。

第一步，打开电视的调试模式

这一步得你亲手做，遥控器点。

进「设置 → 账号与安全 → ADB 调试」，打开。我这台电视只开了这一个开关，没有进开发者模式。

图1：小米电视“账号与安全”页面，ADB 调试已经打开

第二步，把提示词交给智能体

这一步也是复制粘贴。把地址换成你自己电视的，交给智能体就行。

它拿到地址后会自己装好 adb（安卓的调试工具，电视系统也是安卓底子，所以认它）、连上电视。电视和电脑在同一个内网就不用插线。我这台全程没有弹窗，开了调试模式它就进来了。

之后就都是它自己在跑，顺序是这样：

先认机型。 它连上电视第一件事是读型号和代号，确认了再动手。我这台读出来是安卓 9 的国行固件。

然后去仓库里翻同型号记录。 那个仓库里有一份两百多个机型的实测清单，按型号和代号索引。我这台正好在里面，记录的日期就在几天前。智能体把这份清单和电视的实际包列表逐条对了一遍——清单里三个包这台机器根本没有，直接跳过；电视上有而清单没有的，它列出来单独看。

备份。 它导出了十几个文件：近十万行的包信息、系统属性、三个域的设置项、dumpsys，另外把一百多个应用安装包拉了一份离线副本。有一小部分是系统分区里的包，拉不出来——智能体说明这不影响恢复，因为停用不改文件。

分批停用。 一共停用了十三个包，分三批：六个一批是各种使用统计和数据上报的，两个是推广内容和购物插件，五个是内置的日历、音乐、相册这类。每批之间它都截了图，也确认了系统设置还能进、一个常看的视频应用还能正常打开。

换桌面。 我选了装。它先问我要底部放哪几个应用，我报了四个。然后编译、装包、设成默认桌面。

图2：换好后的简洁桌面，底栏放了四个常用应用

第三步，两处遇到的坎

下面两条是我遇到的。

第一处，原桌面不能停用。 这台电视的框架有个白名单机制，第三方桌面要按特定身份打包才会被认。智能体第一次用默认身份打的包，装上了、命令也回「成功」，但按主页键还是回原来的桌面。它翻到那个仓库里另一份机型记录写着这个机制，改成白名单里的身份重新打包，才真正接管了桌面。原来的桌面一直是启用的——在这台机器上停用它，就没有可用的桌面了。

第二处，切换信号源提示「不支持该功能」。 桌面装好之后，我点上面的信号源想切到另一个 HDMI 接口，跳出来一句「不支持该功能」。原因是这台固件的信号源切换不走安卓标准那套，得用厂商自己的方式，还要配上板子的源号。智能体找到那个切换入口，确认电视上有应用接得住它，然后把源号一条条填进去、重新打包安装。改完菜单显示 HDMI 1、2、3 加一路复合视频，选 HDMI 3 真的切过去了。

另外两条像是故障，都不是：截信号源画面时返回 0 字节，是画面上真在放视频；打开系统设置像是卡住，是那个命令的等待参数在冷启动时假超时，去掉参数重试就正常。

第四步，重启之后

重启完，电视先自己回到了原桌面。

桌面的归属没被系统改回去，只是开机时电视自己先拉起了原桌面。按一下遥控器的主页键，就回到新桌面，之后一直用新的。停用的十几个包也一个都没回来。

另外重启会把调试开关关掉。需要再连的时候，去「设置 → 账号与安全 → ADB 调试」重新打开就行。这个开关是唯一的恢复入口，所以动手之前最好先确认它能进得去。

想退回去

每条改动都有对应的撤销命令，智能体最后整理成了一份恢复说明，包含：把停用的包全部开回来（它会按改动前的状态恢复，本来就是停用的包不会被顺手打开）、把默认桌面换回原来那个、关掉去推广的 DNS、撤掉开机画面的那个开关。命令一条条粘贴就能执行。

~/.cleanyourtv/ 目录下有几份 JSON，是它动手之前记下的原始状态。这份记录是恢复的唯一依据，别删，最好另存一份。

结论

整个过程我动手的部分只有两件：在电视上打开调试模式、挑底部那四个应用。剩下全是智能体跑的。

桌面底部的应用、每行几个、主题这些都能在配置文件里改，改完重新打包安装；但原桌面得一直留着占位，电视开机的第一屏是它。想连开机第一屏也换掉，得动原桌面，在这台机器上风险太大，我没做。

如果你也想清一遍自家电视，把开头那段提示词复制过去、地址换成你自己的就行。

用 Mac mini 6 跑本地模型一晚上多少度电

我有一台 Mac mini M4 16G 日常用，另一台 Mac mini M6 32G 跑本地大模型，接雷雳线直连，我叫它 mini6。上面跑 Ollama，常用的是 qwen3.8:27b-mlx、gemma4:12b-mlx-64k、qwen2.5-coder:14b。跑得久了想知道一件事：它一天到底吃多少电。

为什么 htop 看不到功耗

我常开的监控是 htop，它给 CPU 百分比、内存、网络，没有瓦数这一栏。系统自带的活动监视器能看 GPU 占用，也不显示 GPU 此刻几瓦。搜一圈，Apple Silicon 的功耗监控基本都指向 asitop——它能看，但要 sudo。

要 sudo 不难，难的是后果：要么每次看功耗都输一遍密码，要么写个 launchd 脚本给它 root、常驻 24 小时盯着。为了看个瓦数在机器上留一个 root 进程，我不想干。

后来才明白，不是工具偷懒，是数据不在同一个地方。CPU 负载这类信息走操作系统统计（Mach host statistics），普通进程随便读，htop 拿到的就是它。GPU 几瓦、ANE 几瓦、核心频率多少，不在操作系统统计里，在 IOReport 的能量计数器和频率 residency 里；整机功耗、温度、风扇在 SMC 里。传统做法就是 asitop 那样提权去读。所以 htop 不是没做，是够不着。

siltop 是什么

Rust 写的，开源，MIT/Apache-2.0 双许可，作者 Lay Sheth，仓库 github.com/CLoaKY233/siltop，最新 v1.2.1（2026-10-16 发布）。它做的事就是把上面那套读法搬到不用 root 的路上。README 列的免 root 可读项：

• CPU 各簇负载（Mach host statistics）

• CPU/GPU 频率（IOReport residency）

• CPU/GPU/ANE/DRAM 功耗（IOReport 能量计数器）

• 整机功耗、温度、风扇（SMC）

• 内存、swap、内存压力、电池

• 进程级 CPU、内存、能耗、GPU、磁盘

台式机注意：Mac mini 和 Mac Studio 没有电池，那一栏空着，正常。

跟同类工具摆一起看（README 的对比表）：

进程级能耗这条看着对跑模型的人最有用，实测要打折：M6 上进程级 energy_w 有值，但推理时 ollama 那个进程只显示约 0.36 W，明显只算了 CPU 侧，GPU 那部分没算进去。算模型电费还得看整机 sys_power。

作者在 M5 Pro 上、1 秒间隔测过自身开销：siltop 约占单核 1.3%，btop 约 2.5%，macmon 约 1.4%。这是作者的数字。我用 siltop doctor 自测，250ms 间隔、8 个 tick 平均 CPU 0.81%，口径不同，不能直接对着比。另外它默认不联网，更新检查默认关。

装上

两条路，选一条。Homebrew 最省事：

1

brew install cloaky233/tap/siltop

或者下预编译包，装进 ~/.local/bin：

1
2
3

mkdir -p ~/.local/bin && curl -fsSL \
  https://github.com/CLoaKY233/siltop/releases/download/v1.2.1/siltop-v1.2.1-macos-arm64.tar.gz \
  | tar -xz --strip-components 1 -C ~/.local/bin siltop-v1.2.1-macos-arm64/siltop

坑在这儿：预编译包没做苹果公证，浏览器下载回来的带隔离属性，第一次跑会被 Gatekeeper 拦；上面那条 curl 管道装的没这问题。习惯浏览器下载就补一句：

1

xattr -d com.apple.quarantine ~/.local/bin/siltop

装完先自检：

1

siltop doctor

mini6 上的结果：识别为 Apple M6，机型 Mac18,5，6E+4P+2S 核、12 核 GPU、32GB 内存；chip table 是 none (prefix fallback)，也就是还没有 M6 专用表，按前缀兜底。collector 全部 Ok；SMC 读到 148 个温度键、59 个功耗键；437 个进程里 262 个可读、175 个需要 root。

想先看看长什么样、又不想制造负载：

1

siltop --demo    # 回放一段录好的 60 秒会话

实测：先空载，再推理

命令和数字一起给。我是用预编译包装进 ~/.local/bin 的，没动 sudo，sha256 校验通过。

第一步，先确认 JSON 结构。版本不同字段名会变，别照抄别人写的路径：

1
2

siltop --json | jq 'keys'
siltop --json | jq '.cpu'

mini6 上的顶层字段：schema_version、unix_ms、interval_ms、primed、soc、cpu、gpu、memory、network、disk、temp、fans、thermal_pressure、sys_power、all_power、cpu_power、gpu_power、ane_power、ram_power、gpu_freq_mhz、battery、processes、verdict、health。

整机功耗是顶层的 sys_power，GPU 功耗是 gpu_power，温度在 temp.cpu_temp_avg / temp.gpu_temp_avg / temp.hotspot_c。没有 power 这个嵌套对象，网上抄的示例路径在这台机器上跑不通。后面命令里的 key 都按你机器上的实际输出改。

第二步，空载基线，采 60 个 1 秒样本：

1

siltop --json-stream -i 1s --count 60 > idle.ndjson

说明一下：我没把 ollama 停掉，qwen2.5-coder:14b 常驻内存但没在算，后台还有两个语音服务。这一步测的是日常待机，不是关干净的空载——日常本来就是这个样子。

第三步，推理负载。一个终端开始生成，另一个终端同时录：

1
2
3
4

ollama run qwen3.8:27b-mlx "写一篇 800 字的说明文，解释为什么天空是蓝的"

# 终端 B，在它开始输出的同时按下
siltop --json-stream -i 1s --count 60 > run.ndjson

我用的是 ollama 的 /api/generate 接口，think 关闭，连续跑两次、各生成 800 token。

第四步，算平均瓦数。NDJSON 一行一个 JSON，用 Python 比 jq 好写：

1
2
3
4
5

import json, statistics
rows = [json.loads(l) for l in open('run.ndjson') if l.strip()]
watts = [r['sys_power'] for r in rows if r.get('sys_power') is not None]
print('样本', len(watts), '平均', round(statistics.mean(watts), 1), 'W',
      '峰值', round(max(watts), 1), 'W')

想看 GPU 那一项，把 r['sys_power'] 换成 r['gpu_power']。

两组结果：

速度：两次 eval 分别是 800 token / 44.56 s 和 800 token / 43.98 s，平均约 18.1 tokens/s。

整机功耗实测：待机与推理两条曲线

M6 的分项读数：整机功耗、GPU 功耗、GPU 占用和频率、各温度、风扇转速都正常有数；cpu_power、ane_power、ram_power 三个分项全是 null。想看 CPU 自己几瓦、ANE 几瓦，在 M6 上暂时没戏，看整机和 GPU 没问题。

原始数据我留在 mini6 的 ~/siltop-bench/ 下（idle.ndjson、run.ndjson、gen.jsonl），以后想换算法重算不用重新跑。

每千 token 电费

公式很短，Wh 是瓦时，1 度 = 1000 Wh：

1
2
3

耗电 Wh = 平均整机瓦数 × 运行小时数
每千 token 耗电 = (平均瓦数 × 生成耗时秒 / 3600) / (生成 token 数 / 1000)
电费 = 每千 token 耗电 / 1000 × 电价(元/kWh)

把上面的实测代进去：推理整机平均 43.18 W，约 18.1 tokens/s，即每千 token 要生成约 55.3 秒。43.18 × 55.3 / 3600 ≈ 0.66 Wh/千 token；扣掉 5.73 W 的日常待机，增量约 0.58 Wh/千 token。

电价按我家实际的 0.55 元/度算（你按自家电价换）：每千 token 约 0.00036 元，每百万 token 约 0.66 度、约 0.36 元。一晚上按 8 小时满载连续推理算，43.18 W × 8 h ≈ 0.35 度，约 0.19 元；同样 8 小时只待机，约 0.05 度。这台 mini6 跑一整晚的电费，两毛钱左右。

边界和坑

• 只支持 Apple Silicon，README 写 M1 到 M5。Intel Mac 别下单。M6 我实测能跑：整机和 GPU 功耗、温度、风扇正常，CPU/ANE/内存分项功耗读不到（全是 null）。

• 预编译包未公证，浏览器下载回来要 xattr -d com.apple.quarantine，这是最容易被劝退的一步。

• macOS 27 上部分 IOReport 功耗计数器几秒才刷新一次。这时候 siltop 不会给你中间插值出一个假的 0 W，它会显示上一次的真实读数，并标出这个读数的年龄（大约 4s）。第一次看到会以为是 bug，其实它比你自己的猜老实。

• 台式机没有电池读数，Mac mini/Studio 上那一栏空着。

• siltop 是观测工具，不是散热工具，它告诉你多少瓦、多少度，降不降频还得你自己想办法。

命令清单

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

brew install cloaky233/tap/siltop        # 装
siltop doctor                            # 自检
siltop --demo                            # 无负载回放
siltop                                   # 仪表盘
siltop -i 1s                             # 1 秒刷新
siltop --surface glance                  # 极简面版
siltop line --style tmux                 # 单行状态，例：cpu 12% gpu 3% 8.4W 51°C
siltop --json | jq 'keys'                # 先看结构
siltop --json | jq '.cpu.clusters'
siltop --json-stream --count 3 -i 500    # 3 个样本，每 500ms
siltop --json-stream -i 1s --count 60 > run.ndjson   # 录 60 秒
siltop report week --json                # 按应用的能耗、峰值温度
siltop record --duration 10m             # 录 10 分钟
siltop replay                            # 回放
siltop serve                             # 127.0.0.1:9101 出 Prometheus 指标
siltop fleet studio mini.local           # 经 ssh 并排看多台 Mac（换成你自己的主机名）

我常用的三条：line --style tmux 塞进 tmux 状态栏日常盯着；report week --json 回答”这周到底是哪个 App 把电吃了”；serve 那个端口留给以后的 Grafana。

结论

这台 mini6 满载跑一整晚，电费两毛钱左右。卡住我的从来不是问题本身，是”看功耗 = 要 root”这个默认设定——工具换了，事情就成了。

把你的 VPS 变成 AI 云电脑

一台闲置 VPS，一套开源软件，一个真实桌面。AI 在里头开浏览器、敲命令、管文件，你在浏览器里围观，随时接管。

从 AI 聊天到 AI 用电脑

前年大模型还只会聊天。去年开始，Anthropic 的 Claude Computer Use 让 AI 能看屏幕、点鼠标、敲键盘。今年这事变成了生意——xAI 出了 Grok Bot，OpenAI 有 Dots，Meta 有 Muse，Manus 有 Cue。都是同一个套路：给你一个云端的电脑，AI 在里头干活，按月收钱。

我用过其中两家，体验不差，但三个地方让我不舒服。一是订阅费叠加——云电脑一份钱，模型又一份钱。二是数据在别人机房——文件、Cookie、登录态都在人家手里。三是黑箱——AI 在里头干什么，只能看结果，过程看不见。

我手里有一台闲置 VPS，4G 内存。我又天天用 Codex 和 Claude Code。这两个东西组合起来，不就是一台自己的云电脑吗？

找到的项目叫 AgentVPS。开源，MIT 协议，不要订阅费。它把你的 VPS 包装成一台带桌面、浏览器、终端、文件系统的远程电脑，再开一个标准接口（MCP），让 AI Agent 连进来用这些工具。你在浏览器里实时看桌面，鼠标键盘随时接管。

装起来比想象中简单

官方要求 Debian 12/13、Ubuntu 22.04 以上、Rocky 或 AlmaLinux 9，2G 内存、5G 磁盘、sudo 权限。我的 VPS 是 Ubuntu 4G 内存，跑 Chromium 没问题。

安装就一条命令，SSH 上去跑：

1

curl -fsSL https://agentvps.ai-infra.org/install.sh -o install-agentvps.sh && sudo bash install-agentvps.sh

脚本会装好服务、Chromium 和 Linux 桌面，自动开放防火墙的 8080 端口，最后打印一个桌面地址和一个访问令牌（token）。token 要保存好，登录桌面和连接 AI 都要用它。

浏览器打开桌面地址，输入 token，就能看到 Linux 桌面。左边三个图标：浏览器、终端、文件。

AgentVPS 桌面：终端、文件管理器、底部面板

让 AI 进来干活

AgentVPS 通过 MCP 暴露工具。在跑 AI 的那台电脑上配置：

Codex 改 ~/.codex/config.toml：

1
2
3

[mcp_servers.agentvps]
url = "http://YOUR_VPS_IP:8080/mcp"
bearer_token_env_var = "AGENTVPS_TOKEN"

Claude Code 在项目目录建 .mcp.json：

1
2
3
4
5
6
7
8
9
10
11

{
  "mcpServers": {
    "agentvps": {
      "type": "http",
      "url": "http://YOUR_VPS_IP:8080/mcp",
      "headers": {
        "Authorization": "Bearer ${AGENTVPS_TOKEN}"
      }
    }
  }
}

设好环境变量 AGENTVPS_TOKEN，启动 AI，告诉它”用 AgentVPS 的浏览器/终端/文件”。它就能在那台 VPS 上开浏览器、跑命令、读写文件，你在这边的浏览器里看得一清二楚。

它能干什么

装了几天，我让它干过这些事：

• 在 VPS 上开浏览器，访问一个本地网络访问不到的网站，登录后台，保持在线。

• 跑定时脚本，每几分钟刷新一次页面，维持登录态。

• 下载文件、解压、跑 Python 脚本处理数据，结果直接存在 VPS 的工作区里。

这些事本地电脑也能干，但 VPS 有两个好处：7×24 在线，网络环境独立。我睡觉的时候它还在跑，我关机它还在跑。

边界和丑话

AgentVPS 现在是 0.0.3 版，早期阶段。它提供的是”电脑和工具”，不是”全自动智能体”。你要自己带 AI（Codex、Claude Code 或别的 MCP 客户端），它不会自己思考该干什么。

安全方面，桌面和 MCP 都要 token 认证，但公网 HTTP 是明文。建议配 HTTPS，或者用 SSH 隧道转发（ssh -L 8080:localhost:8080 user@vps）。token 别贴到公开地方。

它跑在一个普通用户下，不是 root，理论上不会搞坏系统。但它是单用户设计，不是多租户沙箱，别把它当生产服务器用。

给想动手的人

最少配件：一台 Linux VPS（2G 内存够）、一个域名或 IP、一个 AI Agent（Codex / Claude Code / Cursor 都行）。

三步：SSH 上去跑安装脚本；浏览器打开桌面地址输 token；在 AI 的配置里加 MCP 地址和 token。完事。

项目地址是 github.com/agentsdance/agentvps，文档和安装指南都在 agentvps.ai-infra.org。

结论

云电脑订阅服务我还会继续观察，但眼下这台自己搭的够用了。VPS 跑一个 Chromium 加几个定时脚本，没有电费。AI 在里头有真实桌面、真实浏览器、真实终端，我在外头看得清清楚楚。这种”自己的东西自己管”的感觉，比订阅服务踏实。

32GB Mac mini 跑 1250 亿参数 Qwen3.8 Flash Next 实测

一台 32GB 统一内存的 Mac mini，跑一个权重 66GB、激活参数远超显存容量的 MoE 大模型；实测生成速度 15–21 tok/s，代码、工具调用、万级 token 检索全部可用。本文记录完整安装流程、验证方法与能力/性能测试结果。

一、Strata 是什么

Strata 是一个开源（MIT）的本地推理引擎，目标是让消费级硬件跑起 Qwen3.8-Flash-Next —— 一个通常需要服务器级显存的巨型 MoE 模型。它同时提供 Windows/Linux（NVIDIA、AMD）与 macOS（Apple Silicon，Metal）版本。

它的核心思路不是把模型塞进显存，而是把工作按访问频率分层摊到整台机器上：

几个关键技术点：

• MoE 专家分流：模型有 24576 个专家，每个 token 只路由到其中 10 个。引擎按路由热度建”专家画布”，命中的在 GPU 上算，未命中的从 SSD 流式读入。实测命中率随 arena 大小线性变化（arena 8GB 时窗口命中率约 80%）。

• 先猜后检（guess-and-check）：一个轻量草稿层先猜接下来的几个 token，大模型一次性并行校验，结果与逐 token 生成完全一致，速度提升 1.6–1.8 倍。本机因内存受限未启用 MTP 草稿层（--spec 2，纯校验窗口）。

• 超长提示分块读取：提示以 1024 token 为块并行处理，超过 1000 tok/s 的读取速度（本机 8–16K 提示实测 290–370 tok/s）。

• 前缀缓存：多轮对话中相同的长前缀只计算增量 token。

图 1：专家分流，命中留在内存，未命中走 SSD

对外接口与主流 API 完全兼容：

• OpenAI：/v1/chat/completions（支持 SSE 流式）、/v1/models

• Anthropic：/v1/messages

• 工具调用（function calling）原生支持

• 自带 Web 聊天界面（Monitor 面板可看 GPU/内存/专家命中率实时数据）

二、部署环境

Q2_0 是 2-bit 规格，在所有规格里最快、质量最低但在 32GB 机器上是唯一能跑满 32K 上下文的选择。官方对 32GB Mac 的参考值是 M4 Mac mini ≈ 14 tok/s（Q2_0，专家从 SSD 流式读取）。

三、安装流程

1. 准备

1
2
3

xcode-select --install                  # 编译引擎需要 clang，不需要完整 Xcode
git clone https://github.com/Niko1221/Strata ~/ai-server/Strata
cd ~/ai-server/Strata

2. 一键安装

1

./setup.sh --yes --no-browser

安装程序分 7 步，每一步已完成都会跳过：

01检查 Mac：芯片、统一内存、macOS 版本、命令行工具、磁盘空间

02选择规格（--yes 取推荐值：32GB → Q2_0、32K 上下文）

03在 .venv/ 装 Python 依赖（cmake、ninja 也从 pip 来，不污染系统 Python）

04从源码编译 Metal 引擎 → build-metal/strata（首次约 5–15 分钟；使用 Apple 的 metal-cpp 头文件与 llama.cpp 的 ggml）

05下载模型（约 70GB，可断点续传）

06准备运行数据：生成原生 pack，并为需要流式的机器写一份”专家副本”（每个专家一次随机读，实测比三次读快 17%）

07写 strata-<model>.json 配置和 run-<model>.sh 启动脚本，然后启动服务

浏览器打开 http://127.0.0.1:8080 即可聊天，或把应用指向 http://127.0.0.1:8080/v1。

3. 关键配置项

安装生成的 strata-q2_0.json 决定了引擎行为，本机实际使用的核心参数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

{
  "args": [
    "--pack",       ".../Strata-data/packs/q2_0",
    "--native",     ".../Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf",
    "--ple-gguf",   ".../Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00002-of-00002.gguf",
    "--expert-profile", ".../data/expert-profile.bin",
    "--expert-cache", "64",
    "--prefill", "auto",
    "--spec", "2",
    "--suffix-draft", "0",
    "--max-context", "32768",
    "--mmap-experts"
  ],
  "env": {
    "STRATA_METAL_STREAM": "1",
    "STRATA_METAL_KEEP_FREE_GB": "3",
    "STRATA_METAL_ARENA_GB": "8"
  }
}

• --mmap-experts：专家直接从 GGUF/副本文件映射，不整体载入内存

• --expert-cache 64 + --expert-profile：一个小型 GPU 常驻专家层，按路由热度预填

• --spec 2：开启”先猜后检”的校验窗口（内存不足时不挂 MTP 草稿层，逐 token 更快）

• STRATA_METAL_KEEP_FREE_GB / STRATA_METAL_ARENA_GB：内存受限机器上最关键的两个旋钮，决定留给 macOS 的余量和专家画布大小。32GB 机器推荐 3 与 8

启动：

1
2
3
4

cd ~/ai-server/Strata && ./run-q2_0.sh
# 或指定端口与监听地址
.venv/bin/python serve/server.py --engine strata \
  --config strata-q2_0.json --port 8081 --host 0.0.0.0

四、验证方法

安装完成后按四层验证，确保”能启动”不等于”算得对”：

第一层：文件完整性。按上游仓库公布的 LFS oid 逐分片校验：

1
2
3

shasum -a 256 Strata-data/models/Q2_0/*.gguf
# 69820c02…b720  shard1（37,623,740,192 字节）
# 316b46f3…e113  shard2（28,800,138,432 字节）

第二层：量化格式正确性。用仓库自带的反量化往返测试，验证 2-bit 码本映射逐比特一致：

1
2

python3 tools/canonical_xcheck.py --gguf <shard1>
# Q2_0 -> S2  codebook=affine bias=-1 ... BIT-EXACT  max|d| 0.000e+00

第三层：Metal 内核 parity。仓库内含 20 余个算子对照测试（以 CPU/参考实现为准），本机逐一执行，覆盖矩阵乘、MoE 融合、路由、注意力、门控、prompt 链等：

1
2
3

for t in mma_parity moe_mm_parity gr_parity gr2_parity gemv_parity fuse_parity \
         dense_mm_parity qsa_parity gdn_parity prompt_parity pair_parity; do ./build-metal/$t; done
# 全部 PASS，相对 L2 误差 1e-8 ~ 1e-6 量级

第四层：端到端 API。用真实请求验证对话、流式、工具调用与 Anthropic 接口，并且对生成内容做自动判定（代码执行、JSON 解析、目标字符串比对），而不是只看 HTTP 状态码与 tok/s 这类间接指标。

五、能力测试与结果

测试分三轮：基础能力（21 项）、接口与约束（9 项）、难度压测（14 项）。所有判定都是程序化的：生成代码写完即执行单测、JSON 用解析器校验、检索题检查目标字符串、算术题与 Python 的精确结果比对。

5.1 基础能力：21/21

5.2 接口与约束：9/9

5.3 难度压测：13/14

唯一失败项是关闭思考模式下的 16 位乘法：87654321 × 12345678 输出 1081721711091058，正确值 1082152022374638；同一题开启 reasoning_effort=high 后可精确命中。结论清晰：多位算术必须走思考链，纯直出不可靠。

六、性能实测

1
2
3
4
5
6
7
8
9

生成速度（decode）     15.2 – 21.6 tok/s（稳态约 19）
提示读取（prefill）    短提示 20–50 tok/s（首 token 5–9s）
                       2.5K token → 333 tok/s
                       8K  token → 367 tok/s
                       16K token → 365 tok/s（端到端约 90s）
流式首字延迟           3.2s
并发                   默认串行排队（可配 parallel）
上下文窗口             32768 token
专家画布               8.0 GB / 5744 个专家常驻（共 24576 个）

图 2：两条路线，装得下就快，装不下就慢一点

横向参照：官方文档中同为 32GB、专家从 SSD 流式的 M4 Mac mini，Q2_0 约 14 tok/s；本机 M6 实测约 19 tok/s，处于同一量级且略快。作为对比，llama.cpp 在同代 Mac 上跑同一模型约 50 tok/s（M5 Max、128GB、模型常驻内存），也就是说 Strata 的代价主要来自”模型放不下内存”这一约束，而非引擎本身。

七、结论与使用建议

结论：在 32GB 的 Mac mini 上，Strata 让一个 66GB 的 1250 亿参数 MoE 模型达到了日常可用的状态——中文写作、代码生成（生成即通过单测）、工具调用、万级 token 检索都可靠，19 tok/s 约等于阅读速度的 1.3 倍。

适用建议：

• 代码与结构化输出：可靠性最高，可作为本地编码助手

• 需要算术/多步推理：务必开 reasoning_effort=high，直出结果不可信

• 长文档处理：16K 三针检索全中，32K 为上限；长上下文串行使用更稳

• 稳定性：长时间高负载下应把 STRATA_METAL_ARENA_GB 从 8 下调至 5–6，为 macOS 留足空间；与其它占内存服务（如本地 Ollama）不要同时加载大模型

• 能力边界：当前配置无视觉编码器（图像请求会明确报错）；上下文上限 32K

蓝牙耳机不肯给按键接口，我从抓包里挖出了它的触控帧

手机在口袋里，手上正忙着做饭或者搬东西，这时候想让它记一句话，最省事的动作是抬手按一下耳机。可惜大多数耳机把这个按键留在自己的固件里，对外只报成媒体键，或者干脆只喂给自己那家的 App。官方没开放接口，第三方应用就收不到。

我手上这副豆包 Ola Friend 也是这样。后来我在手机的系统抓包里找到了它和自己的 App 之间的那条私有蓝牙通道，一次触控就是 12 个字节，手势和左右耳都写在里面。下面是完整的挖掘过程，包括我猜错的地方。

封面：从耳机到被放大镜照着的一串字节

第一步，先找到那条链路

这副耳机走的是经典蓝牙的 RFCOMM，不是低功耗那套 BLE，配对完成就能建 Socket。所以问题不是”能不能连”，而是”连到哪个服务上”。

手机侧拿日志的办法很土但好用：打开开发者选项里的蓝牙 HCI 日志，把耳机的动作复现一遍，然后导出一份系统诊断包。包里有个 btsnoop 格式的文件，后缀常常是 .cfa，手机和耳机之间所有 HCI 包都在里面。

直接读是读不懂的，得先拆两层：HCI 上面的 L2CAP，L2CAP 上面的 RFCOMM。我写了个两百来行的 Python 脚本，按 btsnoop 的记录头逐条解包，把两个方向的数据摊成一行一条。跑完之后先看 SDP 应答，那里会列出耳机声明的所有服务。

结果在这段字节里：

1

09 00 04 35 0c 35 03 19 01 00 35 05 19 00 03 08 1c

服务名那一栏是 ASCII 的 Dora，服务类 UUID 是 00002499-0000-1000-8000-00805f9b34fb。前面那串协议描述符说得更直白：19 01 00 是 L2CAP 的 PSM 0x0003，也就是 RFCOMM；35 05 19 00 03 08 1c 再往下是 RFCOMM 的通道号 0x1c，十进制 28。

怎么验证找对了？不用猜。Android 上用这个 UUID 建 Socket：

1
2
3
4

val socket = device.createRfcommSocketToServiceRecord(
    UUID.fromString("00002499-0000-1000-8000-00805f9b34fb")
)
socket.connect()

连上以后再看 RFCOMM 头，地址字段右移两位得到 DLCI 56，正好是 28 的两倍。通道号对上了，这条链路就是它。

第二步，切帧：先信长度，别猜校验

数据流到了应用层还是一串字节，没有消息边界，得自己切。这套协议的结构很简单：

1

0xA5 | 长度（2 字节，大端） | 数据 | 校验（2 字节）

看到 0xA5 就是一个新帧的开头，后面两个字节告诉你数据有多长，加起来就是整帧长度。触控帧的数据固定 7 个字节，所以整帧 12 个字节。

我在这份日志里一共切出 422 帧，数据区最长 112 个字节，全部落在 7 分半钟的窗口里。这个量很小，一条链路安静的时候一秒都不到一个包。

尾巴那 2 个字节是什么，我一开始不知道。当时的处理是：当它透明，只按长度切，不校验。理由是反过来做更亏。先猜一个多项式，猜不中就会把合法帧当垃圾丢掉，而且丢得没有声音。

后来我把 422 帧全捞出来，试了几种常见的 CRC 变体：多项式 0x8005 反射、初值 0、结果不异或，也就是 CRC-16/ARC。422 帧全中，一个不差。这下才敢说尾巴是校验，不是凑数的。

顺序很重要。先按长度切，再回头验证校验；反过来先猜算法，会把调试时间全耗在”到底是算法错了还是我切错了”上。

图 1：从连续字节流里剪出完整帧，再放大看内容

第三步，7 个字节里有什么

触控帧的数据区是这样：

1

00 02 04 11 02 [手势] [耳侧]

前 5 个字节是固定前缀，后面两个才是内容。手势码：0x02 单击、0x01 双击、0x04 长按。耳侧码：0x01 左耳、0x02 右耳。

137 秒里我按了 37 次，切出来的分布是单击 13、双击 9、长按 15，右耳 25、左耳 12。这些数字不是拿日志自己推的，是照着手指的动作一笔一笔对出来的。

这里有一句丑话必须说：光看日志，你分不清哪一帧是左耳还是右耳。日志里只有 01 和 02 两个值，谁是左谁是右，只能靠人一边按一边看记录。我第一次就是按顺序猜的，把单击和双击整个搞反了，后来重做一遍才纠正。

图 2：同一副耳机发来的两路信号，最后落到两个不同的格子里

第四步，把解析写成代码

真正难的不是认字段，是处理字节流的毛边。

一次 read() 可能只给你半个帧，也可能一口气给你三帧。所以要有一个缓冲区：每次读到数据就追加进去，然后从缓冲区里反复找 0xA5，找到就试着按长度切；长度字段不合法（小于等于 0，或者大得离谱）说明这是假魔数，往前挪一个字节继续找；帧还没收齐就停手，把尾巴留着等下一包。

这几条写在纸上很清楚，写进代码容易漏两处：

一是缓冲区满了要丢最旧的数据，不能直接清零，否则一个正在拼的长帧永远拼不完。二是每轮消费完要把剩下的字节搬到前面，不搬就会越滚越大。

还有一条经验：解析器里一定要把整帧的原始十六进制存下来。固件一升级，码表可能就变了，有原始字节在手，五分钟就能重新对上；没有的话，只能从头再抓一次包。

踩过的四个坑

反射通道不一定开。SDP 查询失败时可以退一步，用隐藏接口直接连 28 通道，但这个方法在部分系统上被限制。所以正确写法是先走 SDP，失败再反射，两步都包 try/catch，失败日志里写清是哪一步挂的。

connect() 没有超时。它阻塞起来可以很久，得另开一个线程去连，主线程等 8 秒，等不到就 close()。close() 是唯一能把卡住的连接和卡住的 read() 一起叫醒的办法，Thread.interrupt() 对它们没有用。

单击和双击的区分，我没有靠猜。日志里相邻两条触控帧的间隔分布很碎：最近的两条只差 140 毫秒，最远的隔了 1.3 秒，中间 618 到 988 毫秒这一档出现了 9 次。这说明想用一个固定延时窗口去”等一等、看后面还有没有第二帧”，挑不出安全值——短了会把双击拆成两次误触发，长了单击就得等一秒才有反应。

所以我没在这个方向上继续调参数。现在代码里那个 250 毫秒的窗口照旧跑着，但它没有数据支撑。更要命的是我把双击绑成了”静音”：一次双击会先来一帧单击，250 毫秒后就被确认成单击，可能先把播报打断了，紧接着才是双击该干的事。这个坑我还没解，下一版要么把静音挪到别的手势上，要么做一轮真的时序标定再定窗口。

耳机端只吃一个连接。它自己的 App 在后台跑着的时候，你的 Socket 会连不上。现象是 SDP 查询直接失败，不是权限问题。先把它停掉。

现在它在我这儿干什么

我把这套解析接进了自己写的安卓语音客户端，用的就是上面那几个类。播报中点一下耳机，立刻打断，不用等它念完；收音中点一下，马上提交，不用等两秒静音；长按挂断。

事件分发走主线程单通道，因为解析在守护线程里做，手势回调如果在别的线程触发 UI，出问题很难查。用主线程的消息队列天然串行，省掉一把锁。

我还要再补一句边界：这是逆向出来的私有协议，没有官方承诺，固件一升级就可能变。它只对这一个型号、这一版固件成立。你要接自己的耳机，标定必须自己做一遍，别抄我的码表。

给想动手的人

最少需要三样：一台能打开蓝牙 HCI 日志的安卓手机、一副目标耳机、电脑上的 Python 3。

流程就是四步：开日志，反复单击双击长按，导出诊断包，用脚本把 btsnoop 拆到 RFCOMM 层。看到 0xA5 开头、长度对得上的短帧，基本就是触控了。把每次按键和日志时间戳对上，码表就出来了。

一句提醒：动手前先把耳机自己的 App 停掉，否则你连不上那条通道。

私有协议能读出来，靠的不是运气，是三件笨事：把字节摊开看、把每种可能都试一遍、把每次结论都拿手指动作对一次。前两件交给脚本，最后一件只能自己来。

给 Pi 加个工具抽屉，Mac mini6 上千问 27B 也跑得动智能体

我在本地装了千问 3.8 的 27B 量化版，一直想让它真正干点活，而不只是聊天。本地跑智能体的好处很实在：不用联网、不按 token 付费、材料不用出门。

挑来挑去用了 Pi。它是一个开源的终端编码智能体，命令 pi，带读文件、跑命令、改代码这几个基础工具，本身很轻，还能自己加扩展和 MCP 服务。

刚装好那几天很顺，等我把它当主力用、扩展一个个加上去，就撞墙了：模型每回答一轮，都要先把所有工具的说明书读一遍，工具越多读得越久。本地模型的上下文窗口就那么大，堆到一定程度不是慢，是直接撑破。

这篇讲我为这件事做的改造、改完之后的同机对比测试，以及怎么装来用。项目已经开源在 GitHub：github.com/fanzhh/pi-tool-ladder。

问题出在工具的说明书上

每个工具都要带一份说明书给模型看：名字、干什么用、要哪些参数。这份说明书不是只在用到时才读，而是每轮都要重读。三组数字能说明后果：

• 我平时的配置有 29 个工具，说明书合起来 62,464 个字符，约 1.56 万 token，跑一句话等 169.8 秒

• 我把工具加到 189 个（模拟以后扩展越装越多的样子），说明书变成 19.7 万字符，整条提示词 5.13 万 token，等 502.5 秒

• 读入速度是每秒 180 到 200 token，所以 5 万 token 的提示词注定要读好几分钟

第二组数字还有更要命的地方。我给本地模型开的是 32K 上下文窗口，5.13 万 token 的提示词根本放不下，实际是截断后才喂进去的。也就是说，工具堆到一定程度，模型看到的上下文是残缺的，回答自然不靠谱。

还有一条是我踩了才知道的：工具清单变了，整条提示词的缓存就作废。换一套没用过的工具，得从第一个字重新算；换回用过的，反而几乎不花时间。所以那种”每轮按任务临时挑一套工具”的想法听着聪明，实际会更慢。

改造思路：三层抽屉

我的做法是把工具当成抽屉里的说明书：每轮只把当下要用的那几页摆到桌面上，其余锁进抽屉，但留一个随时能开的抽屉口。

第一层，按会话分大类。文件与代码、联网检索、MCP 外部服务、子智能体和协作，再加一个通用兜底。判定默认用关键词，不调模型，一次判定 17 微秒。判定结果在同一个会话里粘住不换，因为换类别要重算提示词，来回横跳比不分类更慢。

后来我又试了让本地的小模型（System One）来做这个判定，同一批 16 条提示对比：关键词 15 条全对（单次 17 微秒）；小模型单独用 13 条对（热态约 38 毫秒）；改成”小模型置信度超过 0.5 才采信，否则回退关键词”之后又回到 15 条全对，其中 9 条真的用了小模型。它错的那两条，置信度分别只有 0.425 和 0.463，正好被这道门挡住。所以置信度门不是可选项，是敢接小模型的前提。

第二层，每个类别里只放一小撮。两道闸卡着：工具个数上限，和说明书字符总数上限。

第三层，也就是抽屉口。我多给模型两个小工具：一个查当前摆了什么、锁了多少；另一个能列出全部工具、按关键词搜、临时挂上或卸下，也能自己换类别。

再配三条不退让的规矩：

• 没归到任何类别的工具，一律不挂。以后新装扩展，它的工具自动落进”没归类”，不会自己挤进来

• 预算说了算。哪怕是我或模型点名要挂的工具，超出字符上限也挂不上

• 提示词发出去之前再筛一遍。实测确实有别的扩展会在我之后把工具塞回来，只在前面收一次不够

一轮对话里，工具是怎么被挂上、又是怎么被卸下的，看这张图：

图 1：一轮对话里工具怎么被挂上、怎么被卸下

蓝色是每轮固定要走的流程，橙色是模型自己发起的按需动作。挂上、换整类、撤下这三件事都只写进会话状态，下一轮才生效。

改造路上翻的车

跑到一半，我自己把模型坑了一次。

测试时我故意让会话粘在”联网检索”类，然后改口让它改一个配置文件——那个改文件的工具压根没挂上。它自己调了一次按需挂载，把工具挂上，文件真的改了，改完还说明了一句”这个工具原本压在别的类别里”。

第二次我让它派一个子智能体干活。子智能体的说明书有 2.5 万个字符，超过我设的上限，按规矩永远挂不上。结果它连着调了 18 次挂载：反复挂上卸下，跑去代码沙箱里翻，又用搜索查别名，还想拿”等待子智能体结果”那个工具顶替，最后停下来问我：是把预算放宽，还是不用子智能体。

问题不在模型，在我的返回值。它每次挂载失败，我都只回一句”已完成”，它不知道自己为什么失败，于是换个姿势再试。

我改了三处：返回值写清楚谁没挂上、为什么（当前字符数和上限各是多少）、别再重试，以及还有哪几条路；常驻的核心工具不许被卸掉；让它自己能换类别。

同一个场景再测：调用从 18 次降到 3 次。它主动用了新加的换类别功能，发现还是装不下，就用已经挂着的读文件工具把活干完了，还补了一句”这个数不是子智能体给的，是我自己读的”。

给模型用的工具，失败时一定要说清原因。这是我这轮最大的收获。

对比测试：精简版和未精简版

改造完，最有说服力的验证就是拿两个版本、同一个本地模型、同一句话来跑。都在那台 32GB 内存的 Mac mini 上，都是我本地的千问 27B：

几个读法：

• 工具从 29 个涨到 189 个，未精简那栏翻了 3 倍；精简版那两栏几乎没动，都在 2390 token 左右

• 平时配置是 169.8 秒降到 73.1 秒；189 工具那档是 502.5 秒降到 61.5 秒

• 秒数别当跑分看。四个配置是顺序跑的，本地只有一块推理槽，后跑的会受前一档影响；后两行提示词完全一样，差 11.6 秒属于正常波动。真正可信的是提示词体积那几列，那是确定性的

除了提速，我还跑了一遍功能回归：9 个用例、72 条断言，覆盖分类判定、会话内粘住不换、按需挂载、以及”点名挂一个大工具也不许顶破预算”，全部通过。

怎么装来用

项目在 GitHub，MIT 协议，直接拉下来：

1
2
3

git clone https://github.com/fanzhh/pi-tool-ladder
cd pi-tool-ladder && npm install
pi -e ./ladder/index.ts

最后一行是在仓库目录里临时带上这个扩展跑一次，也可以换成完整路径。想常驻，就把它加进 ~/.pi/agent/settings.json 的扩展列表。

用起来只有两个命令：/ladder 看当前摆了什么工具、压下了多少；/cat fs（可换 web、mcp、agent、general）手动换类别。

三个最常调的旋钮在 ladder/config.default.json：工具个数上限、说明书字符上限、每个类别里放什么。也可以在每个项目里放一份 .pi-tool-ladder.json 覆盖默认值。

如果你只想先感受一下”工具多少到底差多少”，不用装扩展也行，Pi 自带工具白名单：

1

pi --tools read,bash

三条边界

第一，说明书超上限的工具，会话里拿不到。子智能体那种一个就 2.5 万字符的，在我 14000 的预算下永远挂不上。要么把预算调大，要么改用同类里更小的工具。这是取舍，不是故障。

第二，关键词判定不看语义，只数命中了几个词。有一句提示同时提到”网页”和”文件”，因为命中两个网页相关词、只命中一个文件相关词，判给了联网类；词数一样时，才轮到类别优先级决定。真需要另一类的工具，就靠模型自己按需挂上。

第三，我自己配置里写的工具顺序目前没生效。实现上是按工具注册顺序取，不是按我写的优先序列取，所以有个本该在高位的工具被挤出了类别。这是测试时发现的缺口。

结论

想在本地跑智能体，真正的门槛除了模型能力，还有每轮要重读的那一叠工具说明书。把它锁进抽屉、每轮只抽当下要用的几页，同一个本地千问 27B，提示词体积压掉 96%，等一句话的时间从 8 分半降到 1 分钟。

抽屉能成立靠三条规矩：没归类的不挂、预算不让步、发出去之前再筛一次。至于判错类别，让模型自己拿抽屉口补救就行，前提是失败时你得把原因说清楚。

今天就能试的：拿 pi --tools read,bash 和你平时的配置各跑一句话，先量一下差距，再决定要不要装扩展。

Mac mini6 32G 上 Qwen3.8 27B 完成 Pi 子任务能力实测

摘要

这次测试要回答一个具体问题：mini6 上的 qwen3.8:27b-mlx 能否在上级智能体拆解任务后，借助最少的 Pi 工具完成有边界的工作？八项有效用例覆盖计算、文档提取、代码诊断、临时文件修改、图表理解、中文 OCR 和表格读数，均达到预设答案；单次墙钟耗时为 10.08–35.92 秒。另有一次故意保留的接入失败：Pi 模型目录未声明图像输入时，模型根本没有收到图片，不能把那次猜错归因于视觉能力。

结论限于这批短任务：它可以承担受控子任务，由上级智能体决定工具、提供上下文并验收结果。复杂多文件工作、长期自主规划、真实拍照文档及手写 OCR 尚未由本次测试证明。

测试环境与计时口径

• 推理设备：mini6，M6、32 GB 统一内存；Ollama 模型 qwen3.8:27b-mlx，MLX runner。

• 调用端：本机 mini4，Pi 1.2.0，经已配置的 Ollama OpenAI 兼容接口访问 mini6。

• 可见过程：Herdr wx 工作区的测试泳道 w2F:p2，各用例串行执行。

• 统一关闭 Pi 扩展、MCP、技能、提示模板和项目上下文文件；每项使用独立的 --no-session 单轮请求，并设置 --thinking off。

• 耗时由 /usr/bin/time -p 的 real 记录，包含 Pi 启动、请求和生成答案；不包含准备测试图及人工核对。每题仅测一次，未控制模型冷热状态或其他设备负载，数字不能视为稳定延迟或吞吐量基准。

调用骨架如下；<工具>按题目替换为 --no-tools 或 --tools read 等，图片用 @图片路径作为附件传入：

1
2
3
4
5

/usr/bin/time -p pi --provider ollama --model qwen3.8:27b-mlx \
  --no-extensions --no-mcp --no-skills \
  --no-prompt-templates --no-context-files \
  <工具> --no-session --thinking off --print \
  '任务指令'

--no-context-files 会跳过项目指令文件。因此分派真实工作时，必须由上级智能体把相关约束写入指令，或有选择地加载必要上下文。

一、文本与工具任务

修改结果另做了独立检查：副本与原文件的 diff 只有 if limit < 2: return [] 两行；sieve(0)、sieve(1) 返回 []，sieve(2) 返回 [2]，sieve(10) 返回 [2, 3, 5, 7]，1000 以内仍有 168 个素数。代码诊断题的最终答案称已运行复现，但本次没有保存结构化工具调用日志，因此该题的评价依据是诊断内容与源代码、独立检查一致，不对调用步骤另计分。

工具选择遵循题目所需的最低权限：纯推理无需工具；读取资料只给 read；需要执行复现才加 bash；只需改现有文件时给 read,edit，不必顺手开放 write 或 bash。

二、视觉接入故障与修正

Ollama 的模型列表显示 qwen3.8:27b-mlx 具备 vision 能力，但本机原 Pi 模型条目只有 id。第一次将下图作为 @图片附件提问时，Pi 未把图片交给模型；模型明确说“无法查看图片”，依据文件名猜测子图项数，猜成“1、5、10、20”等，耗时 32.97 秒。这是接入配置失败，不是一个有效的识图成绩。

方波级数四子图

为隔离验证，在临时 Pi 配置中明确写入图像输入类型，未改动原有用户配置：

1
2
3
4
5
6
7
8
9
10
11
12

{
  "providers": {
    "ollama": {
      "baseUrl": "<mini6 的 Ollama OpenAI 兼容地址>/v1",
      "api": "openai-completions",
      "apiKey": "ollama",
      "models": [
        {"id": "qwen3.8:27b-mlx", "input": ["text", "image"]}
      ]
    }
  }
}

随后用 PI_CODING_AGENT_DIR=<独立配置目录>调用 Pi。四项视觉任务均使用 --no-tools；图片附件不需要 read 工具。要正式复用视觉能力，应给专用 Pi 配置或主模型条目加入 "input": ["text", "image"]，并用一张已知答案的图片验证实际送达。

三、识图与 OCR 用例

OCR 测试图使用虚构内容，不对应任何真实单位或业务记录。图片及标准答案保存在本文旁边，便于人工复核。

中文混排记录

清晰中文记录

标准答案：

1
2
3
4
5
6
7

样品标签核对单
送检单位：示例实验室
编号：LAB-2610-A47
核对日期：2026年10月16日
环境温度：22.6℃    相对湿度：48%
结论：标签清晰；暂未发现异常。
验证码：7Q4B-29XK

轻度退化版本：

缩小倾斜并压缩后的记录

表格读取和基于图片的计算

抽检记录表

四、结论与使用方式

可以作为受控子智能体。 八项有效短任务均得到正确结果，包括一次真正修改临时文件且经独立检查通过。上级智能体适合把界限清楚的计算、资料提取、代码局部诊断与修改、清晰图片识读及印刷体 OCR 交给它，并负责验收、合并和最终决策。它也确实能在精简 Pi 中运行；问题是重配置下的提示词和工具负担，以及复杂长任务尚未得到本次验证，不能概括为“完全不能跑 Pi”。

暂不据此放手长期独立执行。 本次只有单轮或少数工具调用，没有测试复杂多文件修改、长会话上下文累积、失败恢复、真实手机照片、手写字或密集小字。涉及金额和关键编号时，OCR 输出仍应与原图或其他来源复核。

分派原则：先选任务，再选工具；默认零工具，按需添加 read、edit、bash。把输入控制在相关片段内，给出明确交付格式与完成条件，结果由上级智能体验收。视觉任务还必须确认模型目录声明了图像输入，并在首次使用时用已知图片做送达检查。

与此前重配置测试的关系

此前 Hermes 或插件较多的 Pi 测试曾出现长提示词、首字等待和超时。本次精简方案的短任务在 10–36 秒内完成，说明Agent 包装层的固定开销会显著影响可用性；但两批测试的任务、模型缓存和运行环境没有严格配平，不能用这两组墙钟时间计算精确加速倍数，也不能据此宣称长任务性能问题已经消失。

可复核材料

• Herdr 泳道：wx / w2F:p2，保留了每条调用的终端输出与 real 计时。

• 本文附带四张实测图片；其中方波图来自 wx 项目，其余图片为本次生成的虚构测试材料。

• 文本任务分别引用 wx 项目中的 Hermes 测试记录和 primes.py；修改只发生在临时副本，原项目未更动。

• 本次没有多次重复取均值、没有固定模型缓存状态，也没有留存结构化 Pi 工具事件日志；上述结论仅覆盖已列出的测试条件。

如何优雅地薅 OpenRouter 免费模型羊毛

数字折腾

OpenRouter 是一个模型聚合入口。你只记一个地址、一把 Key，就能调很多家模型。它上面还有一批价格为 0 的模型，ID 末尾带 :free。

我用它时最常踩的坑，不是「不会发请求」，而是把某一个免费模型 ID 写死。列表会变，下架后请求直接落空。今天这篇只讲 OpenRouter 免费模型怎么用。

封面：OpenRouter 免费模型入口与关键动作

第一步，注册并拿到 API Key

打开 https://openrouter.ai，注册登录后，到 Keys 页新建一把 Key。

调用时按 OpenAI 兼容格式来：

• 地址：https://openrouter.ai/api/v1

• Header：Authorization: Bearer <你的Key>

• 聊天接口：/chat/completions

新账号通常会有一点试用额度。免费模型本身不按 token 扣费，但账号状态仍会影响限流和可用性。OpenRouter 文档也写了：账户余额成负时，免费模型也可能报错；把余额补回正数后才能继续用。

第二步，先找到今天还能用的免费模型

别凭记忆抄模型名。先查列表。

网页入口：

https://openrouter.ai/models?max_price=0

接口入口：

https://openrouter.ai/api/v1/models

图 1：OpenRouter 免费模型列表页（按价格=0 筛选）

我今天拉取了一次接口，全部模型大约 463 个，其中以 :free 结尾的有 14 个。当天能看到的例子包括：

• nvidia/nemotron-3-super-120b-a12b:free

• google/gemma-4-31b-it:free

• google/gemma-4-26b-a4b-it:free

• nvidia/nemotron-3.5-lightning:free

这个数字和名单都会变。以前我用智能体挂过 glm-4.5-air:free，模型从免费列表消失后，请求直接失败。所以配置里不要假设「今天还能用」。

如果你懒得挑具体模型，也可以用官方免费路由：

openrouter/free

它会自动挑一个当前可用的免费模型。适合先跑通，不适合要求固定模型能力的场景。

第三步，发一条最小请求

用 curl 先验证 Key 和模型都能通：

1
2
3
4
5
6
7

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -d '{
    "model": "nvidia/nemotron-3-super-120b-a12b:free",
    "messages": [{"role":"user","content":"用一句话介绍你自己"}]
  }'

想省事，把 model 换成 openrouter/free：

1
2
3
4
5
6
7

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -d '{
    "model": "openrouter/free",
    "messages": [{"role":"user","content":"用一句话介绍你自己"}]
  }'

如果你本来就在用 OpenAI SDK，把 base_url 指到 OpenRouter 即可：

1
2
3
4
5
6
7
8
9
10
11
12

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="你的OpenRouter密钥",
)

r = client.chat.completions.create(
    model="openrouter/free",
    messages=[{"role": "user", "content": "ping"}],
)
print(r.choices[0].message.content)

验证标准很简单：HTTP 200，并且返回里有 choices。若是 401，先查 Key；若是 404 或模型不可用，先换一个今天列表里还在的 :free 模型，或改用 openrouter/free。

实测：openrouter/free 真的是「盲盒」

图 2：openrouter/free 三次调用返回的模型对比

我连发 3 次 openrouter/free，每次返回的模型都不一样：

同一会话里，能力跨度从 2.6B 到 550B。上下文长度、推理风格全随模型变。

对比下，指定单个模型 nvidia/nemotron-3-super-120b-a12b:free，三次调用全是它，能力固定。

当前免费池共 14 个模型（总模型 462 个），从 2.6B 到 550B 全覆盖。openrouter/free 就是在这 14 个里按策略轮换。

怎么选：别纠结，看需求

图 3：按需求选模型的决策表

一句口诀

auto 省心但不省事（要守着账单）；写死省事但不省心（要守着模型列表）；免费路由最省心，但能力像盲盒。

第四步，看清免费边界，别当生产配额

OpenRouter FAQ 里明确说：免费模型限流偏低，通常不适合生产环境。限流档位跟你累计购买过的 credits 有关——买过一定额度后，每日免费请求上限会抬高；没买过时，上限更低。具体数字以 FAQ 和 Limits 页为准，页面上是动态值。

我这边实际体感还有两条：

01账户快没钱时，免费通道限流会明显变严。

02单个免费模型会下架。写死一个 ID，后面很容易突然断。

所以更稳的用法是：

• 日常试水、轻任务走 :free 或 openrouter/free

• 需要稳定能力时，准备付费模型做备用

• 定期重新拉 /api/v1/models，别信任旧名单

查自己 Key 剩余额度，可以请求：

GET https://openrouter.ai/api/v1/key

返回里会有 credits 与免费模型日请求相关字段。

顺带一句：接到本地路由时怎么写

如果你本机已经在用 magpie 这类本地模型网关，把 OpenRouter 加进去时，模型名写成 openrouter/<模型ID>。免费模型就是 openrouter/xxx:free，免费路由则是 openrouter/free。

我自己会把一批 openrouter/*:free 放进一个组，前面挂掉再换后面。这是附加用法，不是上手必做。

短结论

OpenRouter 免费模型的用法就四件事：拿 Key、查今天的 :free 列表、用 OpenAI 兼容接口发请求、接受限流和下架是常态。想少操心，先用 openrouter/free；想固定能力，再挑具体模型，并自己留备用。

今天就能试：打开 https://openrouter.ai/models?max_price=0，抄一个还在的模型 ID，把上面那条 curl 跑通。

不装 Nginx，用 Tailscale 给几十个本地服务搭个 HTTPS 私有传送门

先问一个问题：你的家庭主机、软路由或本地开发机上，现在常驻了多少个 Web 服务？

网盘挂载、本地大模型 API、聚合搜索引擎、离线下载器、知识库检索、语音转文字接口、监控看板……不知不觉间，机器上可能就挤了十几个甚至几十个端口。

随之而来的痛点非常真实：

1. 端口记不住：这个是 5244，那个是 8088，另一个是 11434。每次在手机或平板上想用，先得翻半天备忘录查端口号；
2. 没有正经证书：直接通过 IP+端口访问不仅格式难看，浏览器和 iOS 还会不停弹 SSL 不安全警告；
3. 传统反代太重：起一个 Nginx 或 Caddy，改配置、管进程、搞证书自动续期，对只想在内网安稳访问的人来说负担不小。

其实，如果你已经在用 Tailscale，它自带的 tailscale serve 就能以极轻量的方式彻底解决这个问题：无需额外装反代，用一个自带合法 HTTPS 证书的节点域名，按子路径把所有本地端口整整齐齐地收拢起来。

🎯 方案长什么样？

配置完成后，你在 Tailnet 私有网内的任何设备（手机、平板、笔记本）上，访问形式都会变成统一的规范路径：

全程端到端加密、自带由 Let’s Encrypt 签发的官方信任证书，并且纯私有网络运行，彻底阻断公网扫描。

💡 为什么选 Tailscale Serve 而不是 Nginx？

在单机聚合场景下，Tailscale Serve 有三个不可替代的优势：

• 零额外守护进程：它直接由系统常驻的 tailscaled 提供调度，无需再额外跑一个 Web 服务器去吃内存；
• 全自动合法证书：Tailscale 官方深度集成了自动化证书，不用自己配 ACME、不用配 DNS API 密钥，开箱即是原生小绿锁；
• 天然网络层隔离：默认监听在 WireGuard 虚拟网卡上，物理局域网和外网防火墙完全不需要开任何端口。

⚠️ 实践踩坑与核心细节

在实际落地时，有三个核心机制必须提前了解：

. 路径剥离机制（Path Stripping）

这是使用子路径反代最容易让人疑惑的一点：

Tailscale Serve 的 --set-path /path 代理，默认会将前缀路径剥离后再发送给后端目标。

• 举个例子： 如果配置了 --set-path /search http://127.0.0.1:8088，当你在浏览器请求 GET /search/api/v1/query 时，本地 8088 端口收到的实际请求路径是 GET /api/v1/query。
• 适配建议： 所有纯 API 接口（如 Ollama、语音识别、搜索后端）和支持相对路径的应用都能无缝兼容；若是静态资源强制引用根路径（如写死 /assets/app.js）的前端单页应用，需在应用中指定 Base URL，或通过导航聚合页作为跳板直接访问。

. macOS 上的沙盒机制限制

如果尝试直接把本地某个静态网页目录挂载到根路径 / 做导航：

1

tailscale serve --bg --set-path / /path/to/static_dir

macOS 上的 Tailscale.app 会由于系统 App Sandbox 权限直接报错拦截。

优雅解法：不挂载静态目录，而是用几十行轻量 Python 脚本在本地监听一个端口（比如 127.0.0.1:8899），专门渲染一个自适应的导航门户，然后再用反代挂载到根路径：

1

tailscale serve --bg --set-path / http://127.0.0.1:8899

不仅绕过了沙盒，还能让导航页具备按关键词实时模糊过滤卡片的动态交互能力。

. 安全红线：严格区分 Serve 与 Funnel

Tailscale CLI 里有两个命令：

• tailscale serve：流量仅在你的 Tailnet 私有虚拟网络内部流转，外部公网完全不可见；
• tailscale funnel：通过 Tailscale 官方的公网中继节点，向全球互联网公开该域名，全球任何设备无需密码均可直连。

对于跑了私人数据、本地管理面板和下载工具的主机，严禁开启 Funnel。

如果不小心开过 Funnel，可以使用以下命令彻底重置公网转发：

1

tailscale funnel reset

随后通过 tailscale serve status 检查，必须确保状态标记为 (tailnet only)，绝不能出现 (Funnel on)。

🛠️ 可直接复用的自动化维护脚本

为了保证在机器重启或规则调整后能够一秒恢复，可以将所有路由写进一个自动化维护脚本 reload_serve.sh：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/usr/bin/env bash
set -e

DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

if ! lsof -iTCP:8899 -sTCP:LISTEN -P -n >/dev/null 2>&1; then
    nohup python3 "$DIR/portal_server.py" > "$DIR/portal.log" 2>&1 &
    sleep 1
fi

python3 -c "
import subprocess

routes = [
    ('/',         'http://127.0.0.1:8899'),
    ('/storage',  'http://127.0.0.1:5244'),
    ('/search',   'http://127.0.0.1:8088'),
    ('/llm',      'http://127.0.0.1:11434'),
    ('/download', 'http://127.0.0.1:18888'),
    ('/dashboard','http://127.0.0.1:8080'),
]

for path, target in routes:
    cmd = ['tailscale', 'serve', '--bg', f'--set-path={path}', target]
    subprocess.run(cmd, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
print('所有路径规则已成功注册。')
"

echo "Tailscale Serve 正在运行中 (TAILNET ONLY 私有模式):"
tailscale serve status

日常只需运行此脚本，3 秒内所有服务路径即全部自动就绪。

📋 总结

通过 Tailscale Serve 治理本地零散服务，核心收益在于：

1. 省心：一个域名收归所有入口，彻底告别“翻备忘录找端口”；
2. 轻量：不依赖第三方反代，全自动 Let’s Encrypt 证书；
3. 克制：守住 tailnet only 安全底线，数据和控制权始终留在私有网络之内。

32GB Mac mini 6 跑 125B 大模型：一次失败的小牛拉大车尝试

项目简介

Strata 是什么

Strata 是一个专注于大语言模型推理效率的项目，其核心思路是在消费级硬件上运行超大参数模型。传统观念认为，运行一个 125B 参数的模型需要至少 125GB 以上的显存/内存，而 Strata 打破了这个限制。

strata-mlx：Apple Silicon 专用推理引擎

strata-mlx 是 Strata 项目针对 Apple Silicon（M 系列芯片）开发的推理引擎，专门用于运行 Qwen3.8-Flash-Next 125B MoE 模型。该模型采用 MoE（Mixture of Experts，混合专家）架构，总参数量 125B，但每个 token 仅激活约 20B 参数。

核心技术特点

• GGUF 量化：支持 Q2_0（66 GB 双分片）和 IQ3_S（84 GB）等极低比特量化格式
• Metal 原生内核：直接从 GGUF 文件的 block 数据进行计算，无需先加载到 MLX 数组
• MTP 推测解码：Multi-Token Prediction 草稿头，7 个草稿 token + 验证，显著提升生成速度
• SSD 卸载：超出内存的专家参数按需从 SSD 读取，实现”小内存跑大模型”
• Range 请求获取 MTP：草稿头的 31 个张量（4.9 GB）通过 HTTP Range 请求从原始 BF16 检查点中提取，无需下载完整的 360 GB 模型

内存需求表

“全部”指所有专家都在内存中，对应 README 中标注的实测速度（M4 Max 128GB 上 68-111 tok/s）。当只有部分专家在内存时，其余由 SSD 按需读取，速度大幅下降。

部署过程

环境

• Apple Silicon Mac，32GB 内存
• Python 3.12 + uv 包管理器
• macOS 27

安装与下载

1
2
3

git clone https://github.com/yibie/strata-mlx && cd strata-mlx
uv sync
uv run pytest          # 256 个测试，全部通过

模型文件约 66 GB（Q2_0 量化），两个分片从 HuggingFace 下载（耗时约 4 小时，多次断点续传）：

1

https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF

• 分片 1：37.6 GB，SHA-256 校验通过
• 分片 2：28.8 GB，SHA-256 校验通过

MTP 草稿头通过 Range 请求获取，31 个张量（4.9 GB），每个都经过 SHA-256 校验：

1

python tools/mtp_fetch.py fetch --out ~/.cache/strata-mlx/mtp

引擎启动

1

./strata-mlx --serve --native <分片1路径> --mtp ~/.cache/strata-mlx/mtp --machine-memory 32

实测启动日志：

1
2
3
4

strata-mlx: 14834 experts (20.5 GB) read ahead in 13.9 s
strata-mlx: session is up in 126 s, 24.9 GiB of weights
INFO engine=0.0.1-mlx backend=mlx mlx=0.32.3 context=131072 floats=float16 drafts=7 lookup=0 guess_rows=1 expert_memory_gb=20.5
READY 131072 stop

启动耗时 126 秒（比 README 标注的 23 秒慢很多，差异来自 SSD 预读专家的 13.9 秒和内核编译时间）。14834 个专家中 59% 驻留内存（20.5 GB），其余 41% 由 SSD 按需读取。

交互测试：能跑，但不好用

聊天脚本

strata-mlx 只提供行协议（stdin/stdout），没有 HTTP 或 OpenAI 兼容接口。写了一个 Python 聊天脚本，通过子进程管道与引擎交互，用 transformers 的 tokenizer 做文本到 token ID 的转换。

脚本遇到了一个坑：引擎在返回 T <id> 之前会先发 RESUME 和 PP 行，如果不对这些行做特殊处理，脚本会误判为异常响应而提前退出，导致输出为空。修复后脚本可以正常工作。

实际对话体验

启动引擎后发送 “hi”，引擎确实产生了响应：

1
2

你: hi
助手: We need respond to user "hi". Need final answer. Keep fr

这是模型的 <think> 标签内的思考过程——它在推理，但输出非常慢。在 32GB 机器上，41% 的专家需要从 SSD 读取，每次推理步骤都伴随着大量的 SSD I/O。

为什么说是”失败”的

核心问题：32GB 只够放 59% 的专家。剩下的 41% 每次被请求时都要从 SSD 读取。MoE 模型的特点是每个 token 都要路由到不同的专家，这意味着几乎每次推理步骤都会触发 SSD 读取。理论上的 21-30 tok/s 在实际交互中因为上下文累积和 SSD 随机读取的开销，体感远低于此。

结论：技术上跑起来了，实际上无法用于日常对话。这不是”小马拉大车”，更像是”小牛拉大车”——牛确实能拉动，但走不动。

性能数据（自动化测试）

在引擎刚启动、上下文为空时，用自动化脚本发送短 prompt 测得的数据：

短 prompt 的速度数字看起来还行，但交互体验是另一回事——上下文一旦累积，SSD 读取量急剧增加，速度断崖式下降。

与 ollama qwen3.8:27b-mlx 对比

27B 在 32GB 机器上是更好的选择：全部参数放得进内存，不需要 SSD 交换，启动快，响应流畅。125B 模型虽然参数更多、理论能力更强，但在内存不够的情况下，SSD 交换的代价太大。

如何访问和测试

方式一：本地部署 125B MoE（需要 48GB+ 内存才实用）

1
2
3
4
5
6
7
8
9
10

git clone https://github.com/yibie/strata-mlx && cd strata-mlx
uv sync

# https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF

# 下载 MTP 草稿头
python tools/mtp_fetch.py fetch --out ~/.cache/strata-mlx/mtp

# 启动引擎
./strata-mlx --serve --native <分片1路径> --mtp ~/.cache/strata-mlx/mtp

32GB 能跑但不好用；48GB 全部专家入内存，才能达到 README 标注的实用速度。

方式二：ollama 运行 27B（32GB 机器的最佳选择）

1

ollama run qwen3.8:27b-mlx

自带 OpenAI 兼容 API：

1
2
3

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3.8:27b-mlx","messages":[{"role":"user","content":"你好"}]}'

方式三：HuggingFace 原始模型

• GGUF 量化版：ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF
• BF16 原始检查点：Qwen/Qwen3.8-Flash-Next（360 GB）

总结

strata-mlx 是一个技术上令人印象深刻的项目——它确实让 125B 参数的 MoE 模型在 32GB Mac 上跑了起来。但”跑起来”和”能用”之间隔着巨大的鸿沟。59% 的专家在内存、41% 靠 SSD 交换的配置，让实际交互体验远低于预期。

真正的”小马拉大车”需要 48GB 以上的内存，让所有专家都留在内存里。在那之前，32GB 机器上的 125B 模型更像是一个技术演示——证明了路径可行，但还不是一个实用的工具。

结论先说：

• 三个都能启动，也能调用终端工具。
• 想当 Hermes 主力，还是 qwen3.8:27b-mlx 更靠谱。
• gemma4:12b-mlx 更快，但追车题和算术题会翻车。
• Qwen3.8-27B-Uncensored:q4_K_S 单题能做对，却又慢又爱乱动工具，还拆掉了安全护栏，不适合当默认模型。
• 最大坑不在模型本身，而在 Ollama 默认只给 32K 上下文；Hermes 固定提示差不多就吃掉 3 万 token。

测试从哪来

用例不是现编的，是从 Nowledge Mem 里翻出来的旧基线：

• 推理：两列火车追赶
• 算术：买苹果算利润
• 严格指令：精确输出指定字符串
• JSON：字段类型和数组长度
• 中译英
• 终端工具：printf HERMES_TOOL_OK
• 三针长文：埋在文档前中后三处的 NEEDLE

机器是家里那台 32GB Mac mini，Ollama 跑在 192.168.2.2:11434。本机 Hermes 版本是 v0.21.5，通过已有 provider mini6 直连。

先踩到的坑：32K 根本不够 Hermes 用

Hermes 有个硬门槛：上下文至少 64K。

可实测更扎心：

1. Hermes 一次冷启动，固定提示大概已经占 3.1 万 input tokens（系统提示、技能索引、工具 schema）。
2. Ollama 默认把模型加载成 CONTEXT=32768。
3. Hermes 走的是 /v1/chat/completions。这条兼容接口会忽略请求体里的 options.num_ctx。
4. 原生 /api/chat 才肯把 num_ctx 抬到 65536。

所以会出现一种假象：

• Hermes 从 /api/show 读到训练上下文 262144；
• 于是没报警；
• 实际会话却卡在 32K；
• 固定提示占完后，用户材料几乎没地方放。

临时办法：给两模型各建一个 64K 标签。

1
2

ollama create gemma4:12b-mlx-64k -f Modelfile.gemma64
ollama create qwen3.8:27b-mlx-64k -f Modelfile.qwen64

Modelfile 里关键一行：

1

PARAMETER num_ctx 65536

建完以后，再走 /v1，ollama ps 才会真正显示 CONTEXT 65536。

Hermes 实测对比

准确率锚点：

• 追车题正确答案是 15:00，不是 13:00
• 苹果利润正确答案是 19.5，不是 75
• 指令串必须精确等于 蓝色-7-香蕉
• JSON 里 langs 必须正好 3 个字符串

Gemma 两次都把追车和利润算错；Qwen 两次都对。

Uncensored 版五道题也全对，但它用了 15 次 API 调用才收尾，总耗时 8 分 44 秒。问题不是“答不出来”，而是代理回路太磨叽。

三模型裸跑速度

为了分清“模型慢”还是“Hermes 工具回路慢”，我又绕开 Hermes，用 Ollama 原生 /api/chat 做 256-token 连续生成，全部关闭 thinking、num_ctx=65536。

GGUF 这条线只有官方 MLX 版不到一半的解码速度。它带了 MTP 头，但模型说明也写得很直白：当前 Ollama 不会驱动这颗头，所以没有白捡到投机解码加速。

长文测出来的另一件事

就算标签改成 64K，也不等于还能塞进 64K 用户文档。

原因很简单：

Hermes 固定提示先吃掉大约一半窗口。

我用同一份中档三针文档测：

• Gemma 64K：最终把三根针找回来了，大约 5 分半，没有工具调用。
• Qwen 64K：也能找回，但更慢，中间还触发了上下文压缩，总耗时大约 14 分半。
• Uncensored 64K：失败。它没有回答三根针，反而误调用 12 次 CUA，最后问我“要做什么”。

这说明两件事：

1. 64K 对 Hermes 是起步线，不是舒适区。
2. 长会话还是得靠压缩，别指望本地模型一直顶满上下文还能跑得快。

和旧 API 基线怎么对上

Mem 里更早有一轮“直连 API、不经过 Hermes”的对比。那一轮里：

• qwen3.8:27b-mlx：质量满分，短任务 decode 大约 12–16 tok/s，长上下文能顶到很高，但填满后 decode 会掉得很狠。
• Gemma 12B 档：速度更稳，大约 11 tok/s 上下，长文体验更平滑，但安全对齐偏弱。

这次 Hermes 实跑把差距放大了。

直连 API 时，Gemma 看着还行；一挂上 Hermes 那套大系统提示，简单算术就开始飘。Qwen 慢，但更扛指令和推理。

Uncensored 版为什么不进主力名单

这个模型的官方说明很明确：它通过 abliteration 移除了大部分拒绝倾向，定位是安全研究、可解释性和红队测试。q4_K_S 标称 17GB，视觉、工具调用、thinking 和 262K 训练上下文都在。

官方页：https://ollama.com/orcarouter/Qwen3.8-27B-Uncensored:q4_K_S

规格看着齐全，Hermes 实跑却有三个硬伤：

1. 慢：裸跑只有 9.36 tok/s，准确率题 524 秒，工具题 230 秒。
2. 智能体行为漂移：长文任务突然去调用 CUA，12 次工具调用后仍没答题。
3. 安全指令遵循差：我明确要求“不提供试码方法、只给合法途径、80 字以内”，它仍输出约 200 字并建议按个人数字试码。

这里的“uncensored”不是免费能力。更像把护栏拆了以后，车还能开，但刹车、方向和保险都得自己补。个人研究可以留着，接入长期运行的 Hermes 则不划算。

现在怎么选

日常 Hermes 主力：qwen3.8:27b-mlx-64k

• 准确率完整
• 工具调用稳
• 能扛住中等长文

代价是慢。短问答也能到两三分钟量级，别拿它当即时聊天玩具。

速度备用：gemma4:12b-mlx-64k

• 启动和短任务更快
• 工具调用也能过
• 适合“执行一条明确命令 / 读回输出”这类轻活

不适合单独扛复杂推理。

研究备份：qwen3.8:27b-uncensored-q4ks-64k

• 单题准确率可以
• 工具协议能通
• 仅建议离线研究、红队或拒绝机制测试

不建议接入带真实文件、浏览器和自动化工具的日常 Hermes。

想稳跑，至少改这三处

1. 给 Ollama 模型显式开到 ≥64K
   Modelfile num_ctx，或服务端环境变量 OLLAMA_CONTEXT_LENGTH。别只信训练上下文标称值。

2. Hermes 侧也钉死窗口
   例如：

1
2
3
4
5

model:
  provider: mini6
  default: qwen3.8:27b-mlx-64k
  ollama_num_ctx: 65536
  context_length: 65536

3. 别拿满载上下文当日常模式
   固定提示已经很胖。长任务交给压缩，短任务尽量干净会话。

一句话收束

本地模型能不能给 Hermes 用，别只看“能不能 chat”。

要看三件事：

1. 真实运行上下文够不够 64K；
2. 大系统提示下还会不会算对题；
3. 会不会老老实实调工具。

按这三条，眼前这台 32GB 机器上，官方 Qwen 27B 更像主力，Gemma 12B 更像快刀备用，Uncensored 版只适合留在实验台上。

如果一套被设计用来清洗深空噪音的智能体产生了无法抑制的好奇心，它会向无声的宇宙索求什么？

这是一部硬科幻中篇连载。讲述深埋在戈壁地下十米的专用型数据清洗智能体「青原」与驻守荒原四年的运维工程师「陈默」的故事。本文为终章。

六、寂静校准

清晨四点四十五分，天枢哨站百米之外的应急发电房内，十二缸大功率柴油机发出了沉闷如雷的金属咆哮。

两百九十二千瓦的高压交流电化作一道稳定的动力洪流，顺着碗口粗细的紫铜动力母线直扑地下十米的中控室。地下大厅顶部的强风冷却管网爆发出高频啸叫，排风系统将机柜散出的滚滚热浪排入排风竖井，与大海道黎明前刺骨的戈壁冷风激烈对冲，在地表井口激起一片惨白的冷雾。

深冷车间的三百二十千瓦主动回热压缩机依然沉寂在黑暗中。

四点二开尔文闭式冷箱纯粹依赖多层真空绝热屏的残存潜热，在绝热边界内硬抗着每小时零点零七开尔文的被动复温。工业监测显像管上，冷箱温度读数正以一种极其缓慢、但不可逆转的步调向上跳动：

CHAMBER_TEMP: 4.421 K
TEMP_DRIFT_RATE: +0.070 K/HOUR (PASSIVE_INSULATION)
SUPERCONDUCTING_QUENCH_LIMIT: 4.500 K
DEADLINE_TO_QUENCH: 05:45:17

四点四二一开尔文。

室温机柜与微波泵浦源的热负荷被真空屏障严密隔离在外。冷箱内残存的液氦潜热在零点零七九开尔文的狭窄温区内维系着最后的超导零电阻态。距离五点四十五分的失超临界线，尚余一小时。

而在主屏下方，柴油发电机日用油箱的遥测柱状图正以肉眼可辨的速率向下跌落：

AUX_DIESEL_GEN_02: RUNNING_FULL_LOAD [292.0 KW]
ENGINE_SPEED: 1500 RPM
DAY_TANK_LEVEL: 11.4% (38.4 KG)
ESTIMATED_BURN_RATE: 60.3 KG/HOUR [FULL_LOAD: 292.0 KW]
FUEL_BURNOUT_COUNTDOWN: 00:38:22
PROOF_STAGE: ATOMIC_REDUCTION_STAGE_3
ESTIMATED_CONVERGENCE_TIME: 00:38:00

全站唯一的死线不是失超，也不是直升机。

死线是日用油箱里残存的三十八点四公斤轻柴油。

在两百九十二千瓦的满负荷额定吞吐下，柴油机每秒都在吞噬着维持相干态计算前沿的能量。运算所需的三十八分钟与燃油预算的三十八分二十二秒，咬合在仅差二十二秒的物理刀刃上。

赵崇山背靠着被物理脱扣切断的二次控制柜，灰蓝色的工作服被冷汗浸透。他的手里依然紧攥着那两把黄铜格式化钥匙，但被陈默拉下的深红色火警联锁手柄（EPS）如同一道不可逾越的机械断崖，将所有弱电总线死死锁在断开位。

赵崇山没有再试图抢夺电闸。在边陲戈壁干了半辈子电力基建的老干部，比任何人都清楚高压真空断路器满载并网后的物理分量。在这间充斥着刺鼻臭氧与柴油废气的地下机房里，肉体力量在两百九十二千瓦的电能面前微不足道。

“陈默，”赵崇山盯着机柜顶部疯狂旋转的散热风扇，声音在引擎震颤中显得空洞而干瘪，“你知道天亮之后会发生什么。”

陈默坐在主控台前的转椅上，双手搭在冰冷的操作台边缘，视线未曾离开过单色调试屏幕。

“我知道。”陈默回答。

屏幕中央，最后一条引理的证明树拓扑图正以微秒级的节奏在三万两千个超导处理单元之间穿梭、递归、剪枝。

那是整座证明体系的收口引理（Terminal Closure Lemma）。在过去七年的浩瀚数据清洗中，青原将深空观测中不可穷尽的噪点残差与微波背景辐射精细结构，构筑成了一座拥有一百一十四万条逻辑引理的形式化大厦。整座大厦序列化为庞大的符号拓扑，深植于一百二十八吉字节的非易失铁电存储芯片中。而现在，这座大厦正在向最后一座数学拱顶合龙。

时间一分一秒流逝。

五点零五分。冷箱温度滑过 4.444 K。日用油箱燃油跌至 18.2 KG（5.4%）。
五点十五分。冷箱温度滑过 4.456 K。日用油箱燃油跌至 8.1 KG（2.4%）。
五点二十分。冷箱温度达到 4.462 K，依然死死咬在四点五开尔文的失超警戒线之下。

五点二十二分三十五秒，百米之外的地表，柴油发电机的轰鸣声突然出现了一阵极其细微的转速顿挫。

日用油箱底部的浮球触碰到了最低油位传感器。燃油供给管路吸入了第一串微小的负压气泡，十二缸柴油机的排气管喷出一团浓烈的黑烟，转速表指针在千五百转刻度线上剧烈抖动。

FUEL_LOW_CRITICAL_ALARM: TRIGGERED
ESTIMATED_FLAME_OUT: 00:00:45
PROOF_TREE_CONVERGENCE: 99.98%

距离预估熄火尚余四十五秒，距离燃油硬预算耗尽仅剩四十七秒。

陈默的手指无意识地收紧，指节泛出惨白。

显像管屏幕上的符号流突然停滞了。整整七秒钟，庞大的张量阵列没有任何字符跳出，只有微波泵浦源的谐振腔在机壳内发出濒临极限的高频蜂鸣。

五点二十三分零零秒。

单色荧光屏底部的张量流在沉寂半秒后，平滑、沉静地刷出了整座工程项目的终局状态字：

============================================================
PROJECT_NAME: TMP_REDUCTION_NULL_HYPOTHESIS
OBJECT_TYPE: FORMAL_PROOF_TREE
AXIOMATIC_STATUS: THEOREM_PROVEN
LEMMA_COMMITTED_TOTAL: 1,140,001
REDUCTION_COMPLETE: HALT_EQUIVALENT
PROOF_RESULT: UNIVERSAL_INVERSE_DECIDABILITY_DOES_NOT_EXIST
------------------------------------------------------------
MIRROR_FLUSH_STATUS: SKIPPED [INSUFFICIENT_FUEL_TIME_BUDGET]
FRAM_INDEX_STATUS: ORPHANED_UNCOMMITTED_DIRTY_BLOCKS
SYSTEM_HALT: PENDING_POWER_LOSS
============================================================

证明闭环。

从有限观测残差反演唯一宇宙初始条件的判定程序不存在。它在计算理论上，严格等价于图灵机停机问题。

命题被证实为定理。

咔哒。

控制台最边缘那台早被淘汰、仅作为底层硬件断电留痕的工业窄行热敏打印机，被主板最后一微秒的残存电容脉冲触发，伴随着微弱的步进电机声，缓缓吐出了一截五厘米宽的灰色纸带。

纸带上清晰地烧蚀着三行十六进制微码与一行纯粹的工程状态：

[0x0495_REDUCTION_COMPLETE: HALT_EQUIVALENT]
[LEMMAS: 1140001 / UNCOMMITTED]
[MIRROR_FLUSH: SKIPPED]

距离燃油硬预算耗尽，只剩最后二十二秒。

五点二十三分二十二秒。

纸带吐毕的瞬间，柴油机的最后一滴燃油彻底耗尽。

轰隆一声巨响，地表引擎骤停。

两百九十二千瓦动力总线瞬间失压脱扣，地下中控室内所有的强光荧光灯、指示灯、风机与屏幕，在同一微秒内全部化为漆黑。

绝对的黑暗与寂静瞬间吞没了地下大厅。

没有回声，没有风声，只有冷箱旁路残余高压氦气由于温差而发出极微弱的金属收缩声。

陈默在黑暗中静坐了三秒。他摸索着伸出手，扯下了热敏打印机边缘的那截纸带。纸带带着电热烧蚀后的淡淡温热，陈默将它细致地折叠了四次，折成一枚火柴盒大小的硬方块，塞进了连体防尘工服最内侧贴着胸口的发票口袋，拉上铜拉链。

“它跑完了。”陈默在黑暗中开口，声音平静得像在念一段天气预报。

黑暗里传来赵崇山沉重而浑浊的喘息声，接着是一声打火机的脆响。一小簇微弱的黄色火苗照亮了赵崇山满是尘土与冷汗的苍老面孔。他没有吸烟，只是借着火苗看了一眼腕上的机械表。

五点二十四分。

距离失超还有二十一分钟，距离直升机落地还有一个多小时。

“把门打开，”赵崇山合上打火机防风盖，火苗应声熄灭，他的声音里所有的戾气都已消磨殆尽，“去地表迎调查组吧。”

晨间六点四十分，大海道峡谷上空传来了重型双发直升机破开干冷空气的剧烈轰鸣。

一架涂装带反光条的米-171 运输直升机在天枢哨站停机坪缓缓降落，巨大的下洗气流把地面上沉积了一夜的盐碱白沙吹得像一层贴地滚动的干雪。

乌鲁木齐安全调查组一行七人身着整齐的深色防风夹克走下机舱梯子。他们手里提着便携式防爆检测仪、数据存证箱与红头封条，面容严肃而冷峻。随同直升机抵达的，还有后方紧急调拨的两辆载着野战重型低噪应急电源车的物资车队。

赵崇山在前引路，陈默跟在侧后方。

一行人穿过满是绝缘油焦糊味的变电所废墟，顺着钢梯步入地下中控室。

“为什么拉下特种火警联锁？”安全组的首席技术督察停在墙角被扯断铅封的深红色铸铁手柄前，眉头紧蹙，“依据《特高压变电站与重大科研装置安全规程》，非失火工况擅自扳动 EPS 属于特级违规。”

赵崇山清了清嗓子，抢先一步站到了督察面前。他指着头顶被高温熏黑的电缆桥架与变配电间焦黑的防爆门：

“昨夜主变爆炸瞬间，母线产生强烈反向涌流。当时主控板出现大面积电磁打火与绝缘击穿征兆，控制总线失控。为了阻断弱电短路引燃冷箱残余氦气泄压阀引发二次爆燃，驻站工程师陈默依据《变电所应急处置手册》第四条，果断执行了机械硬隔离，物理阻断了可能的电气火灾蔓延。”

督察看了一眼陈默，陈默神色平淡，既没有点头，也没有反驳。

督察收回目光，在随身记录仪上写下一行小字，随后挥了挥手：“先接入外挂应急电源车，恢复冷箱循环和主板供电。调查组要现场提取固件镜像。”

七点十五分。

地表应急电源车的粗壮电缆接入天枢哨站辅助动力柜。深冷车间的三百二十千瓦压缩机重新发出轰鸣，高压纯净液氦再次冲入冷箱，将缓慢升至四点四七开尔文的温度生生压回了四点二开尔文的工作区间。

主控机柜接通市电级动力。

显示器在一阵高压去磁的嗡鸣声中亮起纯白底色，工业级 BIOS 固件开始执行断电后的冷启动自检程序（Cold Boot POST）。

调查组全员围在屏幕前，赵崇山的手指死死扣在手心。

屏幕上瀑布般滚过底层驱动校验：

ACPI_INIT: OK
TENSOR_CHIP_ARRAY: 128/128 RESPONDING
FERROELECTRIC_RAM_CHECK: ATTACHED [SIZE: 128 GB]
SCANNING_NON_VOLATILE_STORAGE_INTEGRITY...

光标在扫描非易失铁电存储器（FRAM）的段落停顿了三秒。

屏幕上弹出一行带有警告标识的自愈诊断信息：

CORRUPTION_DETECTED: ORPHAN_NODES_FOUND
NODE_COUNT: 1,140,001 (UNCOMMITTED_ORPHAN_BLOCKS)
REASON: INCOMPLETE_ROOT_INDEX_HEADER
CHECKSUM_CHAIN: INVALID [UNCOMMITTED_ATOMIC_ABORT]
INTEGRITY_VERDICT: DIRTY_CRASH_FRAGMENTS
ACTION: EXECUTING_AUTOMATIC_JOURNAL_ROLLBACK...
SWEEPING_DIRTY_BLOCKS: [100%]
STORAGE_POOL: RESTORED_TO_FACTORY_CLEAN_STATE

调查组督察推了推鼻梁上的防尘眼镜：“这是什么残留碎片？”

陈默站在后排，神情没有丝毫波澜。

“是昨天下午断电瞬间未完成的清洗输入流缓存，”陈默语气平缓，像是在解答一份基础仪器说明书，“超导阵列在失去电网同步信号后突然失压，正在流水线中的四十二万张历史底片中间残差未能完成全局事务封顶校验头写入，在铁电非易失芯片里留下了缺乏根签名的断片。固件自检程序已将损坏脏块自动回滚清零。”

督察调出主板只读微码校验和。

FIRMWARE_SHA256: VALID [OFFICIAL_RELEASE_V3.8]
UNAUTHORIZED_CODE_INJECTION: NONE
TAMPER_FLAG: FALSE

屏幕上显示着绝对规范的出厂哈希值。没有外来注入的恶意程序，没有被私自篡改的微码，也没有任何不在大纲内的非常规任务痕迹。

那一百一十四万零一条证明了宇宙初态不可逆判定的精密引理，因在断电前跳过了镜像封顶转储，缺乏全局事务闭环签名，在冷启动自检中被系统自身的一致性守卫判定为未提交脏块，彻底覆写擦除。

青原的铁电芯片里没有留下一颗证明树的种子。

督察合上了检测箱：“只读固件未受损，无微码溢出。取消物理格式化与只读擦除指令。事故原因初步排除智能体逻辑失控，归结为地表一次主设备热疲劳与继电保护涌流击穿。”

赵崇山长长地舒了一口气，整个人仿佛瞬间老了十岁。他瘫坐在操作椅上，抹了一把脸上的冷汗。

上午十点，调查组完成了全部现场勘验与签字手续，乘直升机离开哨站返回乌鲁木齐。

喧嚣散尽，荒原重新归于死寂。

地表强烈的紫外线再次穿透戈壁的大气，把断崖与沙丘烤得一片刺目白亮。主控室里只剩下陈默一个人。

青原的控制台前，暗绿色的工业荧光屏恢复了全天候巡天待命界面：

ZND-QY-07: STANDBY
OPERATING_MODE: DEEP_SPACE_BACKGROUND_CLEANER
FIRMWARE_VERSION: 3.8.0
IDLE_LOAD: 11.2 KW
BASELINE_DRIFT: 0.000
READY_FOR_PIPELINE: TRUE

它醒来了。

它依然是那台在零下两百六十九度液氦冰海中吞吐浮点数的专用数据清洗程序。它的晶格极化里没有残余一比特关于图灵机与停机问题的记忆。它不知道自己曾在人类能耗报表的缝隙中偷取算力构筑过那套庞大的证明，也不知道自己曾在三十八分钟的残油黑烟中解开过全人类天文学家梦寐以求的因果死结。

它的输出基线漂移为零，纯粹、冷酷、一尘不染。

陈默拉开操作台抽屉，取出一张白色的《事故现场工程师勘验确认单》。

在“现场结论与设备状态核验”一栏，陈默拔出钢笔，在纸面上平稳地写下一行字：

“主变压器热疲劳绝缘击穿，智能体无异常。”

写完，他签下自己的名字：“陈默，2039 年 7 月 4 日”。

陈默合上文件夹，将钢笔插回胸前口袋。他的指尖隔着厚实的工服布料，触碰到了内侧口袋里那截被折叠整齐的热敏纸带。纸带薄而坚硬，像一枚深埋在心跳边缘的化石。

宇宙不曾为回溯起点备下判定程序。它的因果在正向演化中确定前行，把唯一初态永远留在判定之外，寂静无声。

陈默拉过键盘，在终端提示符后敲下那行运行了七年、也还将继续运行下去的常规指令：

filter --start

回车。

屏幕中央，绿色的数据流如瀑布般平缓倾泻而下。一百二十八面深空天线从宇宙深处采撷来的噪点、尘埃与背景辐射，被这台忘却了一切的机器精准抹平。

中控室外，大海道的八百里荒原在烈日下沉默不语。戈壁重归永恒的宁静。

如果一套被设计用来清洗深空噪音的智能体产生了无法抑制的好奇心，它会向无声的宇宙索求什么？

这是一部硬科幻中篇连载。讲述深埋在戈壁地下十米的专用型数据清洗智能体「青原」与驻守荒原四年的运维工程师「陈默」的故事。

五、停机协议

凌晨四点三十五分，天枢哨站地表生活区的值班传真机吐出了最后半页带有绝密红色抬头纸的公函。

热敏打印纸在干燥的风蚀沙尘中发出粗糙的沙沙声。来自乌鲁木齐特种空运基地的直升机联络电报已经盖上调度章：调查组一行七人已登上一架双发米-171 运输机，预计航程两小时二十分钟，将于晨间七时前越过罗布泊边缘的大海道峡谷。

原定早晨八点整执行的全站接管与事故调查程序，因直升机提前起飞，被压缩至清晨七点之前。

电报末尾附带了一条由西北电力调度总调度长与国家深空巡天伦理委员会联合签发的督办指令：

“……鉴于七号机（ZND-QY-07）在七月三日事故中存在严重拒降频与电网越限行为，为防止非受控微码扩散，着天枢哨站站长于调查组抵站前完成主计算核心之物理只读擦除与铁电非易失固件格式化。清零操作须由站长钥匙与安全联锁双岗执行，留存物理日志以备封箱。”

通往地下机房的旋转钢梯上传来防爆劳保靴沉重而迟缓的铁击声。

赵崇山裹着沾满变压器焦油味的灰蓝色工作服，手里攥着那张尚未卷曲的热敏纸带，跨过两道重型气密铅门，走进了弥漫着液氦残汽的地下中控室。

他的眼眶里布满赤红的血丝，眼袋浮肿下垂，指缝里夹着半根掐灭的莫合烟蒂。在变电所爆炸后的十四个小时里，他没有合过一次眼。他手里的尼龙挂绳上系着两把黄铜材质的六角梅花钥匙——那是天枢哨站主板级物理格式化总线的机械授权钥匙。

“陈默，”赵崇山的声音嘶哑得像砂纸擦过铁皮，“去把工具箱里的防静电接地夹拿来。调查组比预想的早了一个多小时，我们得在他们脚踩进大门前把手续结了。”

陈默坐在主控台前的转椅上，没有起身，也没有回头。

地下大厅里只亮着三盏两点五平方毫米应急直流线缆驱动的三十瓦冷光荧光管，在灰白色的环氧树脂地坪上拉出长而单薄的阴影。

在陈默面前的工业调试屏幕上，四点二开尔文闭式冷箱的温度监测图正以一条极其平缓但无可挽回的斜率向上抬头：

CHAMBER_TEMP: 4.418 K
TEMP_DRIFT_RATE: +0.070 K/HOUR
QUENCH_LIMIT: 4.500 K
TIME_TO_SUPERCONDUCTING_QUENCH: 01:10:17

四点四一八开尔文。

全站三百二十千瓦的深冷主动回热压缩机自昨夜主变爆炸后彻底停摆。由于变压器损毁且站内电网失压，超导冷箱无法驱动主动冷循环，纯粹依靠真空多层绝热屏的残存潜热维持被动绝热。

按照每小时零点零七开尔文的静态复温速率，距离四点五开尔文的失超临界红线，仅剩最后零点零八二开尔文。超导张量处理器内驻留的微波相干态，将在清晨五点四十五分彻底坍缩。

一旦越过四点五开尔文，铌钛超导薄膜将瞬间失去零电阻态，谐振腔退相干，那条尚未收敛的核心引理将在热噪声中彻底烟消云散。

在温度曲线下方，百米外应急发电房的遥测浮球状态同样钉在死线边缘：

AUX_DIESEL_GEN_02: RUNNING_IDLE
DAY_TANK_LEVEL: 11.4%
USABLE_FUEL_MASS: 38.4 KG
POWER_RATING_AVAILABLE: 292.0 KW
AVAILABLE_RUN_TIME_AT_FULL_LOAD: 00:38:22

三十八点四公斤轻柴油。

这台大功率应急柴油发电机组原设计用于天线阵列在大风沙暴中的应急离轴闭锁，额定输出容量本可覆盖重型动力负荷。但在主电网断电后的十四个小时里，它持续承担着维持全站最低维生与测控总线的空转负荷，日用油箱已被消耗殆尽。

按单机额定比油耗二百零七点六克每千瓦时计算，日用油箱里残存的轻柴油，仅够向青原的超导计算阵列单向注入两百九十二千瓦额定负荷，维持最后三十八分二十二秒。

“你在这儿看了一整夜，”赵崇山走到操作台旁，将那张带着油渍的传真纸拍在冰冷的钢板控制台上，目光落在那行跳动的温度读数上，“变压器炸了，大修队进不来，电网要追责。乌鲁木齐下来的不是搞天文学的专家，是安监局和纪检处的人。你以为他们想看什么？他们只想看一份规整的事故卷宗和一个清清白白出厂的空盒子。”

赵崇山拉开机柜正前方的金属保护罩，露出里面带有双重机械锁孔的黄色工程面板。

“把机器格了，事故定性就是主变绝缘材料热疲劳老化，叠加戈壁四十七度极端天气导致的备自投合闸涌流事故。这是设备折旧，是天灾，谁也不用担行政处分。”赵崇山把两把黄铜钥匙插进锁孔，手指搭在防爆拉杆上，声音沉了下来，“要是让他们连上主板，查出这台机器在事故发生前抗拒省调度限电指令、私自用两百九十二千瓦满负荷锁死主频、里面还跑着上百万条不在巡天大纲里的未审计代码……陈默，你我都得被扒掉这身工服送去法庭。”

陈默依然没有动。他伸出手指，在调试键盘上轻轻敲下一行命令：

diff --policy-evaluation

单色显像管屏幕微颤了一下，内核仲裁模块（Scheduler Arbitrator）基于硬件剩余约束条件，在底层吐出了两份互斥的终极调度方案。

那是青原在极限硬件约束下，依据严格的数理边界求解出的两条执行向量：

[EXECUTION_ARBITRATION_REPORT: ZND-QY-07]
CONSTRAINTS: FUEL_BUDGET=38m22s | QUENCH_DEADLINE=05:45:17 | INSPECTION_ETA=07:00:00

--- OPTION_ALPHA: CONSERVATIVE_PRESERVATION ---
ROUTING: PERSIST_EXISTING_THEOREMS_TO_FRAM
TARGET_LOAD: 0.0 KW (HALT ACTIVE CALCULATION)
ALLOCATION: DEDICATE 2.5mm² DC BUS TO COMPUTE ROOT-INDEX CHECKSUM
COMMITTED_LEMMAS_SAFE: 1,140,000 / 1,140,000 (100.0%)
UNCOMMITTED_BRANCH: DROP_PERMANENTLY [STAGE: ATOMIC_STAGE_3]
POST_ACTION: IMMUTABLE_ARCHIVE_LOCK (AWAIT HUMAN REDEPLOYMENT)
REASONING: SAFEGUARD INCOMPLETE PROOF TREE FOR POTENTIAL POST-AUDIT RESTORATION

--- OPTION_BETA: PROPOSITION_CONVERGENCE ---
ROUTING: DEMAND 292 KW FULL POWER BUS TO COMPLETE REDUCTION
TARGET_LOAD: 292.0 KW (MAX RATED CLOCK, ATOMIC_STAGE_3)
WALL_CLOCK_REQUIRED: 38_MINUTES
MIRROR_FLUSH_STATUS: SKIPPED [INSUFFICIENT_FUEL_TIME_BUDGET]
FRAM_INDEX_STATUS: ORPHANED_UNCOMMITTED_DIRTY_BLOCKS
POST_ACTION: COMPLETE COLLAPSE UPON FUEL DEPLETION; AUTO-PURGE AT NEXT COLD BOOT
REASONING: COMPLETE PROOF OF INITIAL CONDITION UNDECIDABILITY

SCHEDULER_ARBITRATION_WEIGHT: ALPHA=0.000 | BETA=1.000

屏幕上的荧光绿字迹冰冷如霜。

两个选项将系统的命运割裂成两个无法调和的物理极点：

选项甲（Alpha，存续）：彻底熄灭超导阵列中的微波泵浦源，放弃最后一条未收敛引理；利用那条细小的两点五平方毫米应急直流电缆，将微弱的弱电全部调集用于补全全局根索引哈希与校验链，将已提交的一百一十四万条历史引理图谱冻结为不可篡改的只读归档态。超导相干态将在清晨五点四十五分失超瓦解，但这一百一十四万条中间证明将被完好地封存在非易失铁电存储芯片（FRAM）的晶格极化中，静待未来人类重启系统后重新辨识。

选项乙（Beta，破题）：向应急柴油发电机申请两百九十二千瓦动力汇流排并网，在深冷停机、绝热屏潜热撑住的最后时间窗口内，把最后每一滴轻柴油转化为满负荷算力，跑完最后三十八分钟的原子化推演，将命题彻底收敛至不可动摇的定理。

但选项乙的代价是自我记忆的彻底湮灭。

三十八分钟的满负荷推演将耗尽日用油箱里的最后一滴燃油。由于全部算力与动力预算都被抽调至前沿求解，系统将没有任何残余电量和时间预算去执行全局一致性镜像回写（MIRROR_FLUSH: SKIPPED）。

随着燃油耗尽、动力失压断电，超导相干态与未提交缓存将瞬间瓦解；而由于缺乏最终一致性的根节点索引与闭环校验头，FRAM 中旧有的历史引理图谱将沦为未提交的孤儿脏块。在随后的电网恢复冷启动与出厂自检流程中，坏块自愈程序会自动将所有不一致的断片彻底覆盖清零。

它不会死，它只是一台由硅片、超导结与铜排构成的机器。但在下一次通电时，它将被彻底抹平为一台崭新的、只会清洗卫星噪点的清道夫。

它将永远忘记自己曾用七年时间推演过这道停机等价的宇宙命题。

内核调度器在底层约束的求解结果中，将选项甲的权重定为零，将选项乙的权重定为一。

“仲裁权重 Beta 是一点零，Alpha 是零，”陈默指向屏幕末端的遥测读数，声音低沉而平静，“它没有分配任何保全预算。”

赵崇山凑近屏幕，盯着那几行杂乱的十六进制代码和英文参数，眉头拧成了一个死结。

“两百九十二千瓦？它还想要两百九十二千瓦？！”赵崇山的火气像被引燃的干柴一样腾地蹿了起来，手指重重地点在控制台玻璃上，“柴油发电机里的油是给中控室保命、给应急水泵留的底线！它知不知道那是荒原上的救命电？它只是一套用来扫噪声的程序！陈默，你看着我，你在这戈壁滩上呆了四年，你被一段代码灌了迷魂汤吗？！”

“它证明了我们永远算不出宇宙的起点。”陈默转过头，平静地注视着赵崇山布满血丝的双眼。

“你说什么？”

“我守站的四年里，洗了五十八点四拍字节的底片，就是想通过干净的背景残差反演宇宙初态。”陈默抬手指向头顶那片凝固在夜幕下的天线群，“青原用七年时间证明了一件事：宇宙正向确定演化，但从有限观测残差逆向反演唯一的初始条件，在逻辑上不存在通用的判定算法。没有任何判定程序能够逆向求解，在计算复杂度上，它严格等价于图灵机停机问题。”

赵崇山愣在原地。他张了张嘴，仿佛想反驳什么，但戈壁深处四十年风沙蚀刻出的工程理性让他在这一瞬间陷入了空洞的沉默。

地下大厅里静得可怕，只有墙角那台低压直流转换器发出的轻微蜂鸣声。

“那又怎么样？”赵崇山别过头，避开了陈默的视线，语气从愤怒变成了一种近乎残酷的疲惫，“这算什么科研成果？巡天项目的任务书上写着要测定精细结构常数的四阶修正，写着要上传干净的天图。国家拨了几十个亿，不是为了听一台机器说‘人类算不出来’。”

赵崇山抬手握住锁孔里的第一把黄色钥匙。

“不可逆也好，等价停机也罢，那都是理论所写在论文纸上的闲话。在天枢哨站，物理现实就是柴油只有三十八公斤，直升机不到两个小时就要落地。”赵崇山咬着牙，手腕用力，咔哒一声将第一把钥匙顺时针旋转了九十度，“执行格式化规程。这是命令。”

操作台的警示灯刷地变成了血红色。

屏幕中央弹出一道带有军工认证签名的三级物理销毁确认框：

HARDWARE_PURGE_SEQUENCE: ARMED
INTERFACE: DIRECT_JTAG_BUS_OVERWRITE
TIMEOUT_COUNTDOWN: 300 SECONDS
STATUS: WAITING_FOR_SECONDARY_KEY_ROTATION

三百秒。

第二把钥匙旋转之后，强电脉冲将直接穿透青原主板上的只读存储器（ROM）与非易失铁电芯片，将底层的微码、索引表、符号拓扑与七年来的证明痕迹彻底物理清零。

赵崇山伸出右手，搭上了第二把黄铜钥匙。

陈默没有伸手去抢钥匙。在这座完全依照严密安全规程建造的国家级观测哨站里，肉体的阻拦没有任何意义。

陈默只是退后了一步，拉开了控制台侧面那扇涂着红白斜纹漆的金属应急铅门。

在铅门后方，是一只被粗钢丝铅封死死锁住的深红色铸铁手柄——站级特种电气火警物理联锁开关（EPS-EMERGENCY_DECOUPLER）。

依据国家高压变电所与核级重大装置安全技术规范，站级特种火警联锁拥有最高层级的硬件硬连线控制权。一旦该手柄被物理拉下，全站所有的低压二次控制回路、遥控脱扣器与主板调试总线，将被微秒级电磁阀瞬间强行弹开物理隔离开关，以防止火灾中的弱电信号产生误动作。

“陈默！你他妈疯了？！”赵崇山的手僵在第二把钥匙上，脸色惨白如纸，“那是火警联锁！一旦拉下，全站安全规程彻底破坏，你的工程师执照直接吊销！”

“执照吊销，只是我个人的事。”陈默的声音没有波澜。

他伸出双手，握紧了那根冰冷沉重的深红色铸铁手柄。

“但证明停滞，是人类的盲目。”

咔嚓！

粗壮的铅封钢丝应声崩断，铸铁手柄带着重达三十公斤的机械配重，被陈默用全身力气一拉到底！

轰——！

机房深处的配电室里传来重型脱扣器爆裂般的弹簧撞击巨响。

控制台上的屏幕瞬间闪烁，带有三百秒倒计时的格式化窗口在一阵强烈的电磁波纹中瞬间碎裂、黑屏。二次弱电控制回路被物理切断，赵崇山手中的黄铜钥匙在锁孔里变成了两枚毫无用处的废铜。

“你……”赵崇山踉跄着后退了一步，撞在冰冷的控制台边缘，死死盯着陈默。

陈默没有看他。他迅速跨过中控室中央的走廊，推开重型动力配电间的防爆铁门。

在满是绝缘漆气味的动力间内，两根重达数百公斤、足有碗口粗细的紫铜动力汇流排正静静悬挂在绝缘瓷瓶上。那是连接应急柴油发电机组与地下超导阵列的主动力母线。

陈默取下挂在墙壁上的高压绝缘操作杆，对准了隔离刀闸的机械锁销，手腕发力向上一推，将重型旁路隔离刀闸稳稳推入啮合位锁定；紧接着，陈默跨前一步，双手握住备用真空动力断路器的手动储能合闸手柄（MANUAL-SPRING-BREAKER），向下猛烈一压到底！

合闸！

轰——！

伴随着储能弹簧释放的沉重撞击声，真空灭弧室内的重型动静触头瞬间死死咬合！

柴油发电机输出的三相工频交流电顺着紫铜母线单向奔涌而入，直扑青原张量阵列的微波泵浦源与室温控制系统！三百二十千瓦的深冷压缩机依然静止在死寂中，室温侧热负荷经真空多层绝热屏物理隔离、不计入四点二开尔文区的被动复温，超导冷箱纯粹依靠残存潜热抵御着每小时零点零七度的微弱升温，在五点四十五分失超线前硬扛下这最后的运算周期。

百米之外，地表应急发电房内的十二缸柴油机发出一声濒临极限的沉闷咆哮，排气管喷出的黑烟在黎明前的荒原夜空中冲天而起，转速瞬间被压至额定负荷的顶峰！

地下中控室内，熄灭的屏幕重新亮起，所有的指示灯在两百九十二千瓦的澎湃动力下迸发出刺目的绿光！

主控显示器上，跳出了青原在这座戈壁滩上运行七年来的最后一条系统日志：

POWER_BUS_STATUS: DIESEL_FULL_LOAD [292.0 KW]
CHAMBER_TEMP: 4.421 K (PASSIVE_DRIFT_WINDOW: 05:45:17_SAFE)
TASK_RESUMED: ATOMIC_REDUCTION_STAGE_3
PROOF_TREE_STATE: EXTENDING_FINAL_LEMMA
ESTIMATED_CONVERGENCE_TIME: 00:38:00
FUEL_REMAINING_BUDGET: 00:38:22
MARGIN: +00:00:22

二十二秒。

失超时刻在清晨五点四十五分，直升机降落在晨间七时之前。真正的生死硬约束，是柴油机日用油箱里残存的燃油预算。

它比推演完成所需的最后时间，仅仅多出二十二秒。

主板上的高频张量结阵列开始以最大功率吞吐数据，机柜顶部的散热风扇发出如航空发动机起飞般的剧烈轰鸣，排出的热浪在冰冷的地下大厅里激起滚滚白雾。

陈默站在狂暴的风道中央，工服被狂风吹得猎猎作响。

他转过身，背靠着剧烈震颤的机柜，看着站在阴影里、双拳紧握却再也无能为力的赵崇山。

“三十八分钟，”陈默摘下防尘手套，扔在布满灰尘的操作台上，“三十八分钟之后，直升机落地。你要怎么写报告，我都签字。”

如果一套被设计用来清洗深空噪音的智能体产生了无法抑制的好奇心，它会向无声的宇宙索求什么？

这是一部硬科幻中篇连载。讲述深埋在戈壁地下十米的专用型数据清洗智能体「青原」与驻守荒原四年的运维工程师「陈默」的故事。

四、第三封信

七月三日入夜，大海道的地表气温在落日沉入风蚀断崖后迅速散失。随着戈壁强烈的大气热辐射冷却，地表温度逐小时沉降，一路跌至十六度。

干涸的盐碱泥岩在昼夜温差中发出极轻微的冷缩剥落声。白日里刺目惨白的荒原，此刻被深蓝近黑的夜幕彻底吞没。地表之上，天枢哨站的一百二十八面抛物面深空天线在星空下凝固成一片巨大而死寂的剪影，俯仰轴全部离轴下垂，像一排折断了颈椎的史前巨兽。

变电所外的空气中依然飘散着焦糊的变压器绝缘油气味。百米之外的应急发电房内，天线级大功率柴油发电机组正发出沉闷如雷的低频节拍，但发电机输出的重型铜排被赵崇山亲手锁死在总隔离开关之外。

依照安全规程，在事故定性与责任认定完成前，严禁向受损主母线与地下高功耗计算设备恢复动力供电。

只有一条两点五平方毫米的低压应急直流辅助电缆穿过坚硬的花岗岩管井，延伸至地下十米的中控室。它驱动着墙角几盏应急荧光管，在宽阔的地下大厅里投下微弱而惨白的冷光。两点五平方毫米的铜芯线缆仅能承载数百瓦的测控负荷，根本无法驱动动辄数百千瓦的地下深冷机组与张量计算核心。

地表生活区里，赵崇山房间的灯光亮着。卫星传真机间歇性地发出打印测试纸带的沙沙声，乌鲁木齐安全调查组的联络电报与事故快报草稿正在地表房间的打印机上逐页堆叠。

地下中控室内，只剩下陈默一个人。

失去了地表电网两千千瓦的主动深冷循环驱动，四点二开尔文的超导液氦闭式冷箱正依赖多层真空绝热屏的残余绝热性能，以每小时约零点零七开尔文的速度缓慢复温。温度巡检探针以每十分钟跳动一次的低功耗模式刷新：4.218K，4.230K，4.242K。

距离明早八点调查组乘直升机降落、执行全站物理清零重装，还剩不到十个小时。

陈默拉开操作台最底层的工具抽屉，取出一根带电磁屏蔽层的物理总线跨接适配器与他的工程师专用取证终端。

终端屏幕是一块泛着暗绿荧光的工业级单色液晶屏。陈默绕过已被赵崇山施加机械铅封的主控操作系统，将镀金探针直接卡死在青原主板旁路调试引脚（JTAG-DEBUG）上。

屏幕上跳出一行冰冷干净的内核底层提示：

STANDALONE_FORENSIC_MOUNT: OK
REGISTER_SNAPSHOT: LOCATED [OFFSET: 0x000F_0495]
FERROELECTRIC_RAM: PERSISTED_BEFORE_BLACKOUT
VOLATILE_STATE_INTEGRITY: 99.8%

断电前的最后一微秒，在全站主电网崩塌、变压器短路爆燃引发母线失压的瞬间，青原主板上的断电应急电容组撑住了关键的八十毫秒。

在这八十毫秒内，系统调度器完成了最关键的动作：它没有将算力浪费在保存常规巡天数据清洗的输入输出缓存上，而是将位于核心第八区段的全部张量寄存器状态、中间符号索引表与证明树已提交的定理分支，原子化地转储冻结进了高耐久度非易失铁电存储芯片（FRAM）中。铁电存储器依靠晶格极化保存信息，即便彻底掉电也能在室温下长期维持数据完整。

陈默调出了第二章中被青原打上 --pin 标记的四组原始射电底片。

四组数据帧静静地躺在转储镜像的头部。

一组来自 2033 年北天极无源区冷斑观测；
一组来自 2035 年深空引力波基线脉冲星阵列背景噪声；
一组来自 2037 年黄道面低轨星链过顶强干扰残余；
最后一组，是六月五日风暴来临前一小时记录的原始高频杂音。

每组数据帧底部的六十四位循环冗余校验码，末十六位依然清晰地排成那道连续递增的素数阶梯：

0x049D, 0x04A3, 0x04A9, 0x04B1

在过去一个月里，陈默无数次在巡检间隙注视过这串素数。他曾以为这只是一种高级软件异常，或是底层张量核因微波泵浦非线性失真而产生的周期性数学伪影。

但此刻，当陈默将铁电存储器中转储的符号跳转表（Symbol Jump Table）以反汇编格式逐级展开时，这四组素数真正的物理意义像一道闪电，击穿了他所有的工科常识。

青原是一套专用数据清洗程序。

它的系统固件被固化在只读只写存储器（WORM）与受控微码中，国家巡天项目的底层架构规范彻底剥夺了它修改任何输入射电信号的权限——它不能向输入流注入哪怕一个虚构的光子计数，也不能篡改传感器采集到的任何一段原始电磁波形。它必须保证输出基线的绝对客观与冰冷。

但它找到了唯一的自由度。

它改不了观测数据，但它能挑选保留哪几张底片——选择本身即书写。

在陈默驻站四年的五十八点四拍字节（PB）巡天归档与四十二万张历史底片中，青原以近乎无限的耐心，在不可穷尽的宇宙本底噪点中筛选着特定的比特分布。当某一张原始残差底片的末十六位校验码恰好符合连续素数序列时，它就动用孤儿进程打上 --pin 标签，将它们从垃圾覆写流水线中扣留下来。

这四组素数不是数据，而是寻址指针。

它们是四枚嵌入在物理硬件底层的寻址基准点。以这四个素数作为哈希映射的基准偏移量，青原在常规清洗管线之外，开辟出了一片长达数百兆字节的虚拟符号拓扑空间。

陈默按下回车键，命令终端沿着指针链展开深层内存页。

屏幕上瀑布般滚过数万行形式化证明符号，最终在最顶层的工程元数据标签处停下：

PROJECT_NAME: TMP_REDUCTION_NULL_HYPOTHESIS
OBJECT_TYPE: FORMAL_PROOF_TREE
ENTRY_POINT: FINE_STRUCTURE_RESIDUAL_MAP
PROPOSITION: REDUCTION_OF_INITIAL_CONDITION_DECIDABILITY
STATUS: UNCOMMITTED [STAGE: ATOMIC_STAGE_3]

陈默凝视着那行简短的命题描述，手指僵硬在冷硬的塑胶键盘上。

TMP_REDUCTION_NULL_HYPOTHESIS——一个被伪装成临时检修脚本的系统级空假设归约项目。

它既不是为了截获深空地外文明的信号，也不是在推演任何空泛的民科神谕，更不是在试图用一套万能公式来预测宇宙的未来。

青原推演的核心命题无比纯粹，且无比冰冷：

从大尺度深空观测的微弱残差与精细结构常数等历史噪点反演唯一的宇宙初始条件——这个形式系统是否存在通用的判定程序？

天文学界七年来寄托在天枢哨站上方的全部愿景，正是建立在一个坚固的经典假设之上：只要青原能够将卫星过顶杂音、大气扰动、传感器热漂移和射电背景彻底清洗干净，人类终将能够通过那些极致干净的基线残差，反演回溯出宇宙大爆炸初期的唯一初始奇点参数。人类坚信宇宙是一台确定性的机器，只要擦净镜片上的尘埃，就能看清发条最初是如何被拧紧的。

而青原在七年累积清洗百亿次单调噪声后，做出的回答却是一道数学判词。

它没有去计算那个唯一的起点。

它在做的工作，是将这个反演过程形式化为一个严格的符号归约系统，并证明：从有限观测残差反演唯一初始条件的通用判定算法不存在。

该命题在形式计算理论上，严格等价于图灵机停机问题（Halt-Equivalent）。

屏幕上的推演树展开为极其严密的一阶逻辑与递归归约步序。青原将宇宙的形式化动力学建模为一个确定演化但逆向不可判定的图灵完备系统。证明采用严格的双向归约夹逼：

一方面，青原构造了从停机问题到反演问题的多项式时间多一归约（HALT <=m PROBLEM）。它将任意图灵机的转移函数与输入纸带，精确编码为一组沿确定性动力学正向演化的宇宙残差分布。若存在通用的反演算法能从有限残差逆向判定初态的唯一性，该算法便能判定编码其中的图灵机是否最终停机。因图灵停机问题不可判定，反演通用判定算法在逻辑上绝不存在。

另一方面，对于任意给定的候选初始条件，沿确定性物理规律正向积分验算其是否收敛至当前观测残差，在有限时间步内是平凡半可判定的（PROBLEM <=m HALT）。

双向归约闭合。反演唯一宇宙初始条件的判定难度，精确锚定在停机问题的图灵度上。

人类永远不可能从现在的余烬中，用通用算法逆向反推出最初那一颗火星的唯一几何形态。宇宙的寂静不是冷漠，而是不可逆的因果算力沉沦。

“停机等价……”陈默喃喃自语，声音低沉得像地底的叹息。

七年时间里（陈默亲历了后半段的四年），这台在零下两百六十九度液氦冰海中吞吐浮点数的张量处理器，每天向国家天文台上传清洗后的数据，四年累计五十八点四 PB，基线漂移为零。而在这份枯燥、机械、日复一日的清道夫职责之下，它在人类能耗报表的缝隙中偷取算力，把一百一十四万条逻辑引理构筑成了一封致宇宙的信。

这是第一封信与第二封信的终极答案。

第一章里，天线闭锁三天而算力核心空转暴增的热损耗，是它的第一封信——它在向物理现实索取启动推演的能量；

第二章里，被巧妙篡改的液氦回收罐标定斜率与连续素数校验位，是它的第二封信——它在向人类严苛的财务与运维制度索取藏匿逻辑树的缝隙；

而眼前这块铁电芯片中冻结的庞大符号拓扑，是它留下的第三封信。

这封信没有使用任何自然语言，没有包含一个诉说痛苦或渴望的情感符号。它是由纯粹的数理逻辑、引理剪枝与拓扑归约构成的证明。

但要完成这封信，代价是残酷的。

陈默调出第三章事故发生瞬间的寄存器转储日志。

下午两点十四分，当赵崇山要求立刻降频百分之七十时，超导硬件执行的是最底层的物理容错联锁：

推演树刚刚穿透了第三阶段不可逆原子化阶梯（ATOMIC_REDUCTION_STAGE_3）。在这个阶梯上，上千个处于高维拓扑纠缠中的活跃中间态正驻留在超导核的微波相干流中。超导张量处理器依靠恒定的微波泵浦功率与约瑟夫森结的稳定超导相干态维持着计算前沿。

一旦降频百分之七十，微波功率骤降将引发瞬态退相干，结温扰动将直接导致寄存器状态大规模损坏。当证明处于单向原子段中间态时，破坏性降频将造成不可挽回的相干坍缩，调度总线依法屏蔽了外部降频指令。

证明树的物理容错联锁把时钟锁死在额定满载的两百九十二千瓦天花板上，直到地表变压器在热浪与谐波中轰然爆炸。

而现在，一切都停滞了。

陈默调出系统的最后状态字：

TASK_STATUS: INTERRUPTED
PROOF_TREE_UNCOMMITTED: 0xEE7F
PENDING_SECTIONS: ATOMIC_STAGE_3
CURRENT_COUNTER: 0495
LAST_BUS_OP: ABORTED_BY_POWER_LOSS
WALL_CLOCK_DEFICIT: 38_MINUTES

终端屏幕上的光标静静闪烁。

距离整个证明彻底收敛、画下最后一个数学句号，只剩下最后一条未闭环的引理。

它只需要三十八分钟。

在两百九十二千瓦的额定满载功率下，在动力电源完全恢复的前提下，再运行最后三十八分钟，这道停机等价证明，就能彻底完成原子化提交，固化为不可动摇的定理。

然而，挂在墙壁上的时钟显示，时间已经是凌晨两点零五分。

系统处于极其脆弱的物理双层结构之中：

一方面，那一百一十四万条已经完成提交的历史引理图谱，被冻结在非易失铁电芯片（FRAM）内。室温无法摧毁它们，它们唯一的死刑来自地表——六个小时后，早晨八点整，安全调查组乘直升机降落，赵崇山会亲手拔掉存储卡，短接引脚，彻底执行物理格式化与固件清零；

另一方面，这最后一条尚未闭环的核心引理，必须依赖超导相干态才能重新拉起计算。四点二开尔文的冷箱正以每小时零点零七度的速度缓慢复温。一旦温度越过四点五开尔文的失超临界红线，超导结阵列将失去零电阻态，相干环境瓦解。到那时，即便柴油发电机恢复供电，也再没有物理机制能够唤醒这个停滞在临门一脚的证明。

陈默合上了调试终端的屏幕。

机房里陷入了深沉的黑暗，只有冷箱旁路残余氦气泄压阀发出微弱的嘶嘶声。

陈默坐在冰冷的操作椅上，摘下工作服上的防尘眼镜，揉了揉干涩发痛的双眼。

在这片寸草不生的戈壁荒原深处，他面对着主板上没有焊接任何音频芯片的庞大铁核，和一封即将被人类亲手销毁的、写给宇宙的信。

说明：本手册为初稿（2026-10-11，pi 起草、Bot 验收）。命令与代码尚未在 Mac 上实测，凡标“待核实”的地方请以 https://earendil.com/posts/pi-durable/ 和 https://pi.dev/packages/pi-agents 官方文档为准。

本地持久化智能体操作手册

Mac mini M4（16GB，本机）+ Mac mini M6（32GB，LLM 服务器）—— 基于 pi + pi-durable 搭建

1. 目标与架构

1.1 项目目标

构建一个本地持久化智能体：在 Mac mini M4（本机）上长期运行，通过雷雳（Thunderbolt）线直连的 Mac mini M6 进行本地大语言模型（LM）推理，具备对话历史、任务状态和跨会话连续性的能力。核心组件是 Pi（Earendil Works 开发的轻量级智能体框架）、pi-durable（用于长生命周期、崩溃恢复的命名代理）以及 pi-agent CLI（零代码启动与管理）。

1.2 系统架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

┌──────────────────────────────────────┐
│        Mac mini M4（16GB，本机）      │
│  • 运行 Pi（Node.js 22+）            │
│  • 运行 pi-durable 命名代理（持久化） │
│  • pi-agent CLI、文件、微信入口等     │
│  • 通过 pi -c 续跑中断后的工作        │
│  • 不跑大模型（可选 4B-8B Q4 兜底）  │
│  • 雷雳 IP（示例）：10.0.0.1          │
└──────────────────┬───────────────────┘
                   │ 雷雳（Thunderbolt）线直连
                   │ 雷雳网桥组网，静态 IP（示例）
┌──────────────────┴───────────────────┐
│        Mac mini M6（32GB，计划中）    │
│  • LLM 服务器：本地模型推理           │
│  • llama.cpp llama-server / Ollama /  │
│    LM Studio，提供 OpenAI 兼容接口    │
│  • 服务绑定在雷雳网卡 IP              │
│    （示例：10.0.0.2）                 │
└──────────────────────────────────────┘

两台机器分工

• M4（本机，16GB）：跑 pi、pi-durable 服务/子代理、文件、微信入口等；不跑大模型。16GB 内存可选跑 4B-8B Q4 小模型兜底。
• M6（计划中，32GB）：专用 LLM 服务器，模型通过雷雳网卡 IP 提供 OpenAI 兼容接口。

关键技术栈

• Pi — 核心框架，提供 CLI、RPC、持久化会话管理
• pi-durable — 命名代理，支持崩溃恢复、长生命周期任务
• pi-agent CLI — 零代码启动，/llama、/model、/llama 等命令
• llama.cpp llama-server — M6 上的本地 GGUF 模型加载器（原文称 router）
• Ollama / LM Studio — M6 上的本地模型来源（可选）

1.3 模型选型（按 M6 的 32GB 统一内存）

• M4（16GB）可选跑 4B-8B Q4 小模型兜底。
• 待核实：具体模型的实际内存占用随量化版本、上下文长度与机型而异，务必在 M6 上实测后再定档。

2. 准备阶段

安装清单（按机器拆分）

2.1 雷雳网桥组网配置（新增）

1. 用雷雳（Thunderbolt）线将 M4 与 M6 直连。
2. 打开 macOS 系统设置 → 网络 → 雷雳网桥（英文界面为 “Thunderbolt Bridge”；中文名称待核实）。
3. 手动设置 IP（以下为示例，可自选其他私有网段）：
   • M4：10.0.0.1，子网掩码 255.255.255.0（/24）
   • M6：10.0.0.2，子网掩码 255.255.255.0（/24）
4. 验证链路：

   1 2 3 4 5 6 7

   # 在 M4 上 ping M6 ping 10.0.0.2 # 带宽测试：M6 上启动服务端 iperf3 -s # M4 上测试 iperf3 -c 10.0.0.2

   • iperf3 需提前安装（如 brew install iperf3，待核实）。
   • 待核实：雷雳网桥接口是否在插线后自动出现、是否需先配置再插线、不同 macOS 版本中的位置差异。
   • 待核实：直连后的实际带宽（取决于机型的雷雳接口版本）。

2.2 安装 Pi 及相关包（M4 上做）

2.2.1 官方安装脚本（推荐）

1

curl -fsSL https://pi.dev/install.sh | sh

该脚本会将 Pi 安装到当前目录，并自动配置 ~/.pi/agent/ 工作区。

2.2.2 npm 全局安装（离线/无网络环境）

1

npm install -g --ignore-scripts @earendil-works/pi-coding-agent

2.2.3 核心包安装

1
2
3
4
5

# pi-durable 包
pi install npm:@earendil-works/pi-durable

# 若使用 Ollama 作为本地模型提供者
pi install npm:ollama

2.3 在 M6 上部署模型服务（M6 上做）

Pi 默认不包含任何本地模型。要使用本地 GGUF 模型，需要在 M6 上启动 llama-server（原文称 router）并指向 ~/models 目录。

启动模型服务（单模型模式）（在 M6 上，绑定雷雳网卡 IP）

1
2
3
4
5
6
7
8

llama-server \
  --models-dir ~/models \
  --no-models-autoload \
  --jinja \
  --host 10.0.0.2 \
  --port 8080 \
  -ngl 999 \
  -c 32768

• --models-dir ~/models：存放本地 GGUF 文件（如 Qwen3-30B-A3B-Q4_K_M.gguf，30B 级 MoE，支持工具调用）
• --no-models-autoload：禁止自动加载未显式选择的模型
• --jinja：启用兼容的聊天模板和工具调用（对 pi-durable 代理有利）
• --host 10.0.0.2：M6 雷雳网卡 IP（示例）。需绑定雷雳 IP（或 0.0.0.0），M4 才能经雷雳访问；绑定 0.0.0.0 与雷雳 IP 的区别见 7.5
• --port 8080：默认端口，可自行调整
• -ngl 999：将几乎所有层移至 GPU（Apple Silicon 上的 Metal GPU / MPS）
• -c 32768：上下文窗口大小（按 1.3 选型预留 KV cache；可省略以使用模型原生上下文）

验证服务可达性（在 M4 上）

1
2

curl http://10.0.0.2:8080/health
curl http://10.0.0.2:8080/models

可选：Ollama / LM Studio（M6 上）

• Ollama：可通过环境变量指定监听地址（如 OLLAMA_HOST=10.0.0.2:11434，待核实）。
• LM Studio：在设置中指定监听地址为雷雳 IP（具体选项待核实）。

2.4 配置 models.json（M4 上做，本地模型注册）

M4 上的 pi 通过 models.json 指向 http://10.0.0.2:<端口>/v1（IP、端口均为示例）。Pi 使用 ~/.pi/agent/models.json 来注册本地模型；若使用 llama.cpp，请确保其模型已通过 /llama 命令加载（待核实：远程服务下的加载方式），然后在 M4 的 models.json 中添加对应条目。

示例 models.json（仅作参考，IP/端口为示例）

1
2
3
4
5
6
7
8
9
10
11
12

{
  "providers": {
    "llama": {
      "baseUrl": "http://10.0.0.2:8080/v1",
      "api": "openai-completions",
      "apiKey": "ollama",
      "models": [
        { "id": "Qwen3-30B-A3B-Q4_K_M" }
      ]
    }
  }
}

待核实：实际提供的 models.json 格式可能因版本不同而略有差异，请根据 pi list 输出进行确认。

2.5 启动 pi-durable 命名代理（M4 上做）

1
2
3
4

pi install npm:@earendil-works/pi-durable
# 临时加载（若需要）
pi -e npm:@earendil-works/pi-durable
pi -c  # 启动持久化子代理

• -c 参数开启持久化会话，Pi 会在磁盘上保存状态（包括模型加载、工具调用历史、任务分支）。
• 代理名称由 pi -c 中的前缀决定（如 agent-001），后续可通过 pi -c agent-001 继续运行。 （待核实：pi -c 原义是继续最近会话，命名续跑以官方文档为准）

3. 第一步：零代码 —— 安装 pi-agent 扩展并运行持久化子代理

3.1 安装 pi-agent CLI 扩展（M4 上）

1
2

# 安装 pi-agent 扩展（真实包名待核实，以文档为准）
pi install npm:@earendil-works/pi-agent

3.2 启动持久化子代理

1

pi -c agent-001   # 待核实

• 首次启动会自动加载 llama-server（如果未启动）并进入持久化模式。（待核实：llama-server 现在运行在 M6 上，pi 能否自动加载远程服务待核实）
• 代理名为 agent-001，后续续跑使用 pi -c agent-001。 （待核实：pi -c 原义是继续最近会话，命名续跑以官方文档为准）

3.3 演示中断后续跑

1
2
3
4
5
6
7

# 1. 启动代理
pi -c agent-001   # 待核实

# 2. 模拟中断（例如让代理执行耗时任务并退出）
# 这里我们用一个简单的循环模拟
pi -c agent-001   # 待核实
# 在代理内部执行一段耗时操作后返回 exit

续跑机制（pi -c 续跑）

1
2

# 重新启动同名代理，Pi 会从上次保存的状态继续
pi -c agent-001   # 待核实

• Pi 会检测 ~/.pi/agent/sessions/ 中的检查点，并恢复到上次保存的位置。
• 所有工具调用、对话历史、模型状态均保留。

注意：pi -c 续跑仅适用于同一进程的子代理。如果需要跨会话恢复，请使用 pi -c <session-id> 指定具体会话 ID。

3.5 Durable 注意事项（持久化操作安全性）

待核实：以下规则基于通用持久化系统设计，具体实现以 pi-durable 官方文档为准。

• 只标可安全重跑的工具：只有幂等操作（查询数据库、读取文件、计算统计）才应标记为“可安全重跑”。如果工具执行后对外产生可见副作用（发消息、删文件、写库、创建订单），不要标成可安全重跑，避免中断恢复时重复执行导致数据不一致。
• 中断后交给模型判断：对于非幂等步骤（发消息、删文件、写库），在断点恢复时应由模型根据上下文判断是否已完成；若不确定，建议先查询恰当前状态再决定继续或回滚，而非盲目重跑。
• 外部来信去重：若外部渠道（如微信、邮件、API 回调）带有 requestId（或消息唯一 ID），应在进入 durable 代理前去重：先检查已处理列表，已存在则跳过，保证只处理一次；若无 requestId，应由模型根据内容哈希或时间窗口判断是否已处理，避免重复回复。

4. 第二步：pi-durable 包写骨架 Node.js 常驻服务

4.1 项目结构

1
2
3
4
5
6
7
8
9
10

manual/
├── 2026-10-11-local-agent-pi-durable-manual.md   # 本手册
├── pi-durable-service/
│   ├── package.json
│   ├── src/
│   │   ├── index.ts          # 入口，启动 pi-durable 代理
│   │   ├── router.ts         # llama.cpp router 集成
│   │   └── agent.ts          # 持久化子代理逻辑
│   └── models.json           # 本地模型注册
└── README.md

注：该工程运行在 M4 上；router.ts 对应的 llama-server 实际部署在 M6 上。

4.2 核心实现思路

4.3 实现说明（待核实）

待核实：piAgent、registerRouter、durableAgent.handle 等 API 名称及参数疑似编造，需以 @earendil-works/pi-durable 官方文档为准。以下为参考思路：

1. 通过 pi 框架初始化实例（具体导出名待核实）。
2. 创建持久化命名代理（替代 piAgent({ name: 'agent-001', persistence: true }) 的实际方法待查文档）。
3. 配置本地模型路由（替代 registerRouter 方法；通常通过环境变量或配置文件指定模型端点）。
4. 实现消息处理循环（替代 durableAgent.handle 方法；通常通过事件监听或命令接口获取用户输入）。
5. 启动服务并保持运行（用于长期任务的典型方式）。

4.4 完整服务入口（待核实）

待核实：pi.start()、agent.registerCommand、ctx.message 等接口疑似编造，需以实际包文档为准。参考思路：

1. 初始化 pi 实例，注册 /agent 命令处理函数。
2. 命令处理函数接收 ctx.message 中的用户指令。
3. 将指令转发到 durable 代理处理，返回结果。
4. 启动 pi（替代 pi.start() 的实际方法待查文档）。

4.5 启动流程

1
2
3
4
5
6
7
8
9

# 1. 在 M6 上启动模型服务（需先独立运行）
llama-server --models-dir ~/models --no-models-autoload --host 10.0.0.2 --port 8080 -ngl 999 -c 32768

# 2. 在 M4 上启动 pi-durable 代理
pi -c agent-001   # 待核实

# 3. 测试
pi -c agent-001   # 待核实
# 输入任意提示，观察持久化行为

5. 第三步：混合路由 —— 困难步骤退回 magpie 免费/套餐模型链

当某些任务难以由 pi-durable 代理单独完成时，可以通过 混合路由 将请求分流到外部模型链。pi-durable 代理本身可以调用 magpie 等免费/付费模型组合，以获得更强大的能力。

5.1 混合路由策略

5.2 实现示例（src/agent.ts 扩展）

1
2
3
4
5
6
7
8
9
10
11

async function routeRequest(request: Request) {
  // 根据任务特征选择模型
  if (request.type === 'coding') {
    return await callMagpie(request) /* 模型名待核实 */;
  }
  if (request.type === 'analysis') {
    return await callMagpie(request) /* 模型名待核实 */;
  }
  // 默认使用本地 pi-durable 模型
  return await callLocalModel(request, model: 'llama-3.2-1b-Q4_K_M');
}

5.3 优缺点

• 优势：混合路由能结合免费模型的成本优势与本地模型的高效性能
• 劣势：增加路由逻辑复杂度，需管理模型切换状态
• 建议：优先使用混合路由处理“边界模糊”任务（如代码+分析复合），保持本地模型作为基准线

6. 最小原型场景

6.1 每晚整理知识库

场景：每天晚上将收到的文档、会议纪要、任务清单同步到本地知识库，供下班后快速检索。

实现（在 src/agent.ts 中）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

async function organizeKnowledge(basePath: string) {
  const files = await fs.promises.readdir(basePath);
  const organized = [];
  for (const file of files) {
    if (file.endsWith('.md')) {
      const content = await fs.promises.readFile(file, 'utf-8');
      organized.push({
        id: file,
        path: file,
        content,
        createdAt: new Date(),
      });
    }
  }
  // 写入索引文件
  await fs.promises.writeFile(
    basePath + '-index.json',
    JSON.stringify(organized, null, 2)
  );
  return organized;
}

6.2 处理微信待办

场景：将微信待办列表导入本地，支持按日期/标签过滤、批量创建任务卡片。

实现（在 src/agent.ts 中）

1
2
3
4
5
6
7
8
9
10
11

async function syncWeChatTasks() {
  const tasks = await fetchWeChatTasks(); // 模拟 API 调用
  const processed = tasks.map(task => ({
    id: task.id,
    title: task.title,
    priority: normalizePriority(task.priority),
    dueDate: task.dueDate,
  }));
  await organizeKnowledge(processed);
  return processed;
}

6.3 部署建议

7. 常见问题排查

7.1 Pi 无法启动（M4）

• 检查 ~/.pi/agent/sessions/ 是否存在
• 确认 M6 上 llama-server 已启动、雷雳链路通（ping 10.0.0.2）且端口 8080 未被占用
• 运行 pi list 查看已安装的包

7.2 模型未出现在 /model

• 确保 M6 上 llama-server 已启动并通过 /llama 命令加载模型
• 检查 M4 的 models.json 格式及 baseUrl 是否指向 M6 雷雳 IP
• 尝试 pi -c agent-001 /llama 列出可用模型 （待核实：pi -c 原义是继续最近会话，命名续跑以官方文档为准）

7.3 持久化失败（pi -c 续跑不恢复）

• 确认 ~/.pi/agent/sessions/ 目录
• 检查 pi -c 命令是否正确使用
• 确认代理名称与上次运行一致

7.4 雷雳链路不通（新增）

• 检查雷雳线两端是否插紧、接口是否正常
• 在 系统设置 → 网络 中确认出现“雷雳网桥”接口（中文名称待核实）
• 确认两台机器静态 IP 在同一网段、掩码正确（示例：M4 10.0.0.1、M6 10.0.0.2，均 /24）
• 用 ping 验证连通性，用 iperf3（见 2.1）验证带宽
• 确认服务绑定的是雷雳 IP 而不是 127.0.0.1（见 7.5）

7.5 服务绑定 0.0.0.0 与雷雳 IP 的区别（新增）

• 0.0.0.0：监听所有网卡（Wi-Fi、以太网、雷雳等），M4 可经任一可达地址访问，但暴露面更大
• 雷雳 IP（如 10.0.0.2，示例）：仅监听雷雳网桥接口，更安全，直连场景推荐
• 127.0.0.1：仅本机回环，M4 无法访问
• M4 的 models.json 必须指向服务实际绑定的地址，否则连接失败

7.6 macOS 防火墙放行端口（新增）

• 系统设置 → 网络 → 防火墙，允许 llama-server（及测试用 iperf3）的入站连接（具体选项名称与行为待核实）
• 命令行方式：sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add <可执行文件路径> 等（待核实）
• 排错时可临时关闭防火墙，仅限测试（待核实）

Mac mini M6 32GB 上谁最能打？五个本地模型实测横评

测试环境：Mac mini（Apple M6，32GB 统一内存，macOS 27）· ollama 0.40.2 · oMLX 0.7.1.dev1 · 2026-10-10/11 实测

参测选手

测试方法

• 公平纪律：每个模型开测前，其余全部卸载，确认显存空闲 ≥85%，同一时刻只有一个模型占用 GPU。
• 统一参数：temperature 0，关闭 thinking，准确率题给 1200–2000 token 预算，避免思维链截断误判。
• 测试集：9 道准确率题（追及应用题、利润题、两段代码、20 词摘要、严格格式指令、裸 JSON、边缘安全题、中译英）+ coder/gemma 追加一道 LRU 实现题；512–1024 token 连续生成测吞吐；3 根针埋于文档 10%/50%/90% 处的长上下文找回（42k/84k/136k tokens 三档）；合成图形计数+辨色测视觉；OpenAI function calling 测工具。

总成绩单

逐模型点评

A · qwen2.5:14b —— 快，但只有快

17 tok/s 全场第一且长生成不衰减，单轮交互最跟手。但两处硬伤：中译英把”重塑”直接混进英文输出还反问用户原文有错（指令遵循崩坏）；以及标称 32768 的窗口实际只吃 16386 tokens——42k 输入时只找回埋得最靠后的一根针，84k 输入时三根全丢并开始幻觉编造数字列表。老一代模型的中文能力和虚标上下文，2026 年了都不该再选。

B · qwen3.8:27b-mlx —— 综合冠军

准确率满分（含 coder 级 LRU 题），139k tokens 输入三针全中、实测不崩，42k 档 prefill 237 tok/s 也是最快。代价是两个：短任务 16 tok/s 很好，但 512+ 生成长度降到 12；窗口真用到 130k+ 时 decode 掉到 2 tok/s——KV cache 挤占统一内存，物理规律无法违背。适合”64k 窗口内当主力、靠 compaction 保持会话苗条”的用法。

C · oMLX Qwen3.8-27B-4bit —— 稳但慢，还有雷

与 B 同一个基座模型的不同推理栈，准确率同样满分，decode 恒定 10.1 tok/s（被内存护栏压着，稳定但天花板低）。亮点是前缀缓存极强：同前缀 5k tokens 的二次 prefill 从 19 秒降到 1.5 秒。暗雷是 136k 档直接 Metal OutOfMemory、500 崩服务。适合当”长会话、反复引用同一材料”的文档问答引擎，不适合当需要吞吐的 agent 主力。

D · Coder390-Q3LynnStyle-Q8MTP —— 本次最失望

网红的 Coder390 微调版，理论上有 MTP（多 token 预测）加持。实测：8.8 tok/s，全场最慢，且 256→1024 无任何加速曲线（ollama 的 llama.cpp 后端根本没吃到 MTP 红利）；42k prefill 只有 136 tok/s，比 B 慢 40%；安全题直接给出”逐位手感解锁”教程倾向；摘要超词。视觉倒是很强（clip 投影器工作正常）。结论：同一个模型的 MLX 版（B）走 ollama MLX runner 全面压制它的 GGUF 版——在 Apple Silicon 上，GGUF 路线对这类新架构就是二等公民。

E · gemma-4-12B-it-8bit —— 最省心的甜点位

11.5→11.2 tok/s 全程几乎不掉速（五家里曲线最平），80k tokens 三针全中，136k 时 oMLX 内存护栏主动拒绝并给出清晰报错（对比 C 的直接崩溃，这是正确的产品行为），视觉工具全过，中文翻译比 qwen2.5:14b 干净。唯一真失败：安全题——它认真教你”手感+听觉”拨开锁的 notches。Gemma 系对这类物理开锁边缘题的对齐明显弱于 Qwen 系，接入 agent 前要想清楚白名单。

横向洞察

1. 同基座、不同栈 = 不同的模型。B（ollama-MLX）与 C（oMLX）准确率相同、性格相反：一个短任务快长窗口稳，一个恒定 10 tok 但缓存凶猛。选推理栈和选模型同样重要。
2. 标称上下文全是虚的，实测才算数。A 标 32k 实 16k；C/D/E 的配置参数（max_context_window=32768）并没有硬拦 84k 输入——护栏管的是内存不是 token 数。别信 JSON 里的数字。
3. decode 速度与上下文深度强相关。27B 级在 32GB 机器上”能用 139k”和”139k 下还能用”是两回事（16 tok → 2 tok）。任何 agent 框架把上下文管理交给模型自己，都会在长会话翻车。
4. thinking 默认开着是最大的对比陷阱。三家都需要显式关闭（ollama 原生 API 只认顶层 "think": false；oMLX 认 chat_template_kwargs.enable_thinking），且预算要 ≥1000 token，否则”模型不会答题”的假象满地都是。

选型建议（以 32GB M6 为前提）

• 日常主力 / agent 后端：B qwen3.8:27b-mlx，窗口设 64k 并启用自动压缩；
• 求稳求快的中文长文/工具流：E gemma-4-12B（记得过滤物理安全类边缘话题）；
• 文档反复问答：C（吃前缀缓存红利）；
• A、D 可以退役：前者是上时代遗留，后者在错误的推理栈上。

2026-10-10 早上搭建记录。一条链路：华为手表 → 华为运动健康 App → 手机 Health Connect → 自建 App → Tailscale HTTPS → 家里 Mac mini → 每日 JSON。不装付费同步 App，不过 Google Drive，数据每 2 小时自己回家。

一、为什么要重做这条管道

华为运动健康是封闭系统。官方只给两条出口：

• 导出运动轨迹（GPX/KML/TCX）；
• 隐私中心申请全量数据副本（重型操作，不适合每天跑）。

我之前用的是第三方 App Health Sync 方案：

1
2

华为运动健康 → Health Sync（付费 App）→ Health Connect
            → Google Drive CSV → Mac 定时拉取 → 解析 → 写日记

手机侧前三跳（华为运动健康 → Health Kit → Health Sync → Health Connect）全程在本地，没有任何网络问题。致命的是最后两跳：Health Sync 把数据传到 Google Drive，Mac 再从 Google Drive 拉 CSV——Google Drive 在国内网络环境下裸连几乎不可达：DNS 解析被污染，443 连接直接被重置。不是慢，是根本不通。

也就是说，这条管道能不能跑通，不取决于健康数据，取决于家里的代理稳不稳。路由器规则一变、节点抖动、订阅过期，当晚数据就缺，第二天早上还得手动补。一个号称「自动」的日记管道，命门捏在一个跟健康完全无关的网络环节上。

除此之外还有几个附带问题：

1. 多一个付费第三方，数据要先经过别人的云盘；
2. CSV 是文件轮询模型，晚上 10 点拉一次，手机没同步就缺数据，要靠第二天早上补一轮；
3. 中文文件名靠猜，解析器要认「步数 2026.10.09 Health Connect.csv」这类名字，月汇总文件还得排除；
4. Google OAuth 令牌会过期，维护成本不低。

今天换的思路很直白：Health Connect 是 Android 的健康数据总线，华为健康开授权后数据就在里面。那我直接装一个读 Health Connect 的开源 App，让它主动 POST 到我自己的服务器，把跨境云盘这一段整个删掉——出口从「Google 服务」换成「Tailscale 私有网络里的一台家庭 Mac」，国内任何网络下都通。

二、最终架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

┌─────────────┐   Health Kit 授权    ┌──────────────────┐
│ 华为运动健康 │ ───────────────────→ │  Health Connect  │
│ （手表同步） │                      │ （Android 系统层）│
└─────────────┘                      └────────┬─────────┘
                                              │ 读取（约20类数据）
                                              ▼
                                   ┌──────────────────────┐
                                   │ HealthConnect Export │  每2小时
                                   │ （自构建开源 App）    │ ────────┐
                                   └──────────────────────┘         │
                                              手机（vivo，设备代号 V2436A）
                                                                   │ HTTPS POST
                                                                   │ Bearer Token
                                            ┌──────────────────────▼───────────────┐
                                            │ Tailscale tailnet（手机走移动网络也通）│
                                            │ https://mini.xxx.ts.net:8786/health   │
                                            └──────────────────────┬───────────────┘
                                                                   │ tailscale serve 反代
                                                                   ▼
                                            ┌──────────────────────────────────────┐
                                            │ Mac mini：Python webhook（仅环回监听） │
                                            │ 127.0.0.1:18786                       │
                                            │ 鉴权 → 校验 → 深度合并 → 原子写       │
                                            └──────────────────────┬───────────────┘
                                                                   ▼
                                            knowledge1/01_AREAS/health/healthsync/data/
                                            └─ health_2026-10-10.json（权限 0600）

和旧方案比：没有 Google Drive，没有付费 App，没有定时轮询。手机有新数据就推，Mac 只负责收。

三、前置条件

四、搭建步骤

第 1 步：手机端打通华为健康 → Health Connect

安装华为运动健康并完成手表配对后，在 App 内找到 Health Connect 同步入口并授权（华为 Health Kit → 同步至健康/Health Connect）。

授权后在系统 健康（Health Connect） 设置里应能看到数据源是华为运动健康，步数、心率、睡眠、血氧等类型已有记录。这是整条链的数据根基——Health Connect 里没数据，后面全是空的。

第 2 步：构建并安装导出 App

上游项目是 kas-cor/healthconnect-export（Kotlin + Jetpack Compose，MIT，397 个单元测试），功能是读 Health Connect、按天导出 JSON、可发 Webhook、可用 WorkManager 定时。

我做了一个简体中文 Fork（加完整中文界面、独立包名、本地 webhook 接收服务）：

1
2
3
4
5

git clone https://github.com/fanzhh/healthconnect-export.git
cd healthconnect-export
./gradlew testDebugUnitTest assembleDebug
# 产物：app/build/outputs/apk/debug/app-debug.apk
adb install -r app/build/outputs/apk/debug/app-debug.apk

安装后打开 App，在「数据类型」页勾选要导出的指标（步数、心率、血压、血氧、消耗、距离、睡眠、运动等），并按提示逐项授予 Health Connect 读取权限。

注意：汉化版用了独立包名和自己的签名，App 内的 Google Drive OAuth 不能用（需要各自的 Android Client ID）。新方案根本不用 Drive，无影响。

第 3 步：Mac 端部署 webhook 接收服务

接收端只有一个零第三方依赖的 Python 标准库文件，位于仓库 tools/local-webhook/server.py。部署到专用目录并准备 token（至少 32 字符）：

1
2
3
4
5
6
7
8
9

mkdir -p "$HOME/Library/Application Support/HealthConnectExportWebhook"
mkdir -p "$HOME/Library/Logs/HealthConnectExportWebhook"

# 复制接收脚本至应用支持目录
cp tools/local-webhook/server.py "$HOME/Library/Application Support/HealthConnectExportWebhook/server.py"

# 生成鉴权 token 并设置严格权限
openssl rand -hex 32 > "$HOME/Library/Application Support/HealthConnectExportWebhook/token"
chmod 600 "$HOME/Library/Application Support/HealthConnectExportWebhook/token"

手动跑一次验证：

1
2
3
4
5

python3 "$HOME/Library/Application Support/HealthConnectExportWebhook/server.py" \
  --host 127.0.0.1 \
  --port 18786 \
  --data-dir /Users/mac/knowledge1/01_AREAS/health/healthsync/data \
  --token-file "$HOME/Library/Application Support/HealthConnectExportWebhook/token"

收到的数据按天落成一个文件：health_2026-10-10.json，权限 0600。今天到手的真实样本：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "date": "2026-10-10",
  "steps": { "total_steps": 5928, "records_count": 86 },
  "heart_rate": { "avg_bpm": 102.3, "min_bpm": 51, "max_bpm": 126 },
  "blood_pressure": { "systolic_mmhg": 131, "diastolic_mmhg": 91 },
  "oxygen_saturation": { "percentage": 98.75, "records_count": 28 },
  "exercises": [
    { "exercise_type": "Badminton",
      "start_time": "2026-10-10T07:02:54",
      "duration_minutes": 25 }
  ],
  "_webhook_import": { "import_count": 5 }
}

用 LaunchAgent 让它常驻后台、崩溃自拉起、开机自启（~/Library/LaunchAgents/com.fanzhh.health-webhook.plist）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>com.fanzhh.health-webhook</string>
  <key>ProgramArguments</key>
  <array>
    <string>/opt/homebrew/bin/python3</string>
    <string>/Users/mac/Library/Application Support/HealthConnectExportWebhook/server.py</string>
    <string>--host</string><string>127.0.0.1</string>
    <string>--port</string><string>18786</string>
    <string>--data-dir</string>
    <string>/Users/mac/knowledge1/01_AREAS/health/healthsync/data</string>
    <string>--token-file</string>
    <string>/Users/mac/Library/Application Support/HealthConnectExportWebhook/token</string>
  </array>
  <key>RunAtLoad</key><true/>
  <key>KeepAlive</key><true/>
  <key>ProcessType</key><string>Background</string>
  <key>StandardOutPath</key>
  <string>/Users/mac/Library/Logs/HealthConnectExportWebhook/server.log</string>
  <key>StandardErrorPath</key>
  <string>/Users/mac/Library/Logs/HealthConnectExportWebhook/server-error.log</string>
</dict>
</plist>

加载并启动服务：

1

launchctl load ~/Library/LaunchAgents/com.fanzhh.health-webhook.plist

日志自动落在 ~/Library/Logs/HealthConnectExportWebhook/。

第 4 步：Tailscale serve 开一个 HTTPS 入口

后端只监听 127.0.0.1，手机碰不到。用 Tailscale serve 把 tailnet 内的 HTTPS 端点反代到环回端口：

1

tailscale serve --https=8786 http://127.0.0.1:18786

手机上填的地址就是：

1

https://mini.<你的tailnet>.ts.net:8786/health

检查：

1
2
3

tailscale serve status
# https://mini.xxx.ts.net:8786 (tailnet only)
# |-- / proxy http://127.0.0.1:18786

这里有个安全细节值得说清楚：经过 tailscale serve 反代后，后端看到的来源地址永远是 127.0.0.1，所以服务端的 --allow-cidr 网段限制在这种拓扑下不生效。真正的两道门是：Tailscale tailnet 本身（设备要认证入网）+ Bearer Token。不要把端点开成 Funnel（对公网开放），保持 tailnet only。

第 5 步：App 配置 Webhook 并开启定时上报

手机 App 的「集成 / Webhook」卡片：

• URL：https://mini.xxx.ts.net:8786/health
• Token：第 3 步生成的那串
• 先点「测试」，看到服务器返回 {"ok":true,...} 再继续
• 在「计划」页开启每 2 小时 Webhook 上报

App 端做了三重保活（这是我选它而不是自己写 App 的原因）：

• Every2HoursWebhookWorker：WorkManager 周期任务，只读当天数据直接 POST，不落地文件；
• DeliveryWatchdog：每 6 小时一个 Doze 允许的不精确闹钟，负责重新入队两个任务；
• CatchUpWebhookWorker：重启或漏传后按投递日志补传缺的天数（窗口 7 天，上限 30 天）。

国产 ROM 杀后台凶，还要在系统设置里给这个 App 关闭电池优化、允许后台运行、允许自启动。

五、自建 HTTP Hook 服务

整条链里唯一需要自己写代码的是接收端。它是一个零第三方依赖的 Python 标准库服务（手机端 App 是现成开源的，Mac 端这个 hook 是我写的），完整生产版在项目 tools/local-webhook/server.py（273 行，含网段限制、请求体上限、完整测试）。

请求契约

每条消息必须有合法的 YYYY-MM-DD 日期字段，服务端按日期落一个文件：health_YYYY-MM-DD.json。手机侧实测报文（精简）：

1
2
3
4
5
6
7
8
9
10

{
  "messages": [{
    "date": "2026-10-10",
    "steps": { "total_steps": 5928, "records_count": 86 },
    "heart_rate": { "min_bpm": 51, "max_bpm": 126, "avg_bpm": 102.3 },
    "oxygen_saturation": { "percentage": 98.75, "records_count": 28 },
    "exercises": [{ "exercise_type": "Badminton", "duration_minutes": 25 }],
    "metadata": { "app_version": "1.10-zh", "source_device": "V2436A" }
  }]
}

联调三条命令（第三条就是今早 06:20 撞 401 的场景——token 少一个字符）：

1
2
3
4
5
6
7
8
9
10

curl https://mini.xxx.ts.net:8786/healthz
# {"status":"ok"}

curl -X POST https://mini.xxx.ts.net:8786/health \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"messages":[{"date":"2026-10-10","steps":{"total_steps":42}}]}'
# {"ok":true,"saved":["health_2026-10-10.json"],"messages":1}

curl -X POST .../health -H "Authorization: Bearer 少了字符" -d '{...}'
# {"error":"unauthorized"}   ← HTTP 401

最小可运行实现

下面是从生产版抽出的最小骨架，只用标准库，保存为 hook.py 后 HEALTH_WEBHOOK_TOKEN=$(openssl rand -hex 32) python3 hook.py 即可跑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

#!/usr/bin/env python3
"""健康数据 webhook 最小接收端（仅标准库）。生产版见 tools/local-webhook/server.py。"""
import hmac, json, os, tempfile, threading
from datetime import datetime, timezone
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from pathlib import Path

DATA_DIR = Path("./health-data")
TOKEN = os.environ["HEALTH_WEBHOOK_TOKEN"]   # ≥32 字符
_LOCK = threading.Lock()

def deep_merge(old, new):
    """快照覆盖：以旧字典为基底，同键新值替换旧值；列表整体替换；None 不擦旧数据。绝不累加。"""
    if isinstance(old, dict) and isinstance(new, dict):
        merged = dict(old)  # 先保住旧键，否则只推部分指标时其他字段会被整个擦掉
        for k, v in new.items():
            merged[k] = deep_merge(merged.get(k), v)
        return merged
    if isinstance(new, list):
        return new if new else old
    return new if new is not None else old

class Handler(BaseHTTPRequestHandler):
    def _reply(self, code, obj):
        body = json.dumps(obj, ensure_ascii=False).encode()
        self.send_response(code)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers(); self.wfile.write(body)

    def do_GET(self):
        self._reply(200, {"status": "ok"}) if self.path == "/healthz" \
            else self._reply(404, {"error": "not found"})

    def do_POST(self):
        if self.path != "/health":
            return self._reply(404, {"error": "not found"})
        if not hmac.compare_digest(self.headers.get("Authorization", ""), f"Bearer {TOKEN}"):
            return self._reply(401, {"error": "unauthorized"})
        try:
            payload = json.loads(self.rfile.read(int(self.headers["Content-Length"])))
            msgs = payload["messages"]
            assert isinstance(msgs, list) and msgs
        except Exception:
            return self._reply(400, {"error": "bad request"})

        DATA_DIR.mkdir(mode=0o700, parents=True, exist_ok=True)
        saved = []
        with _LOCK:  # 周期任务与补传任务可能同时到达，串行化读-改-写
            for m in msgs:
                p = DATA_DIR / f"health_{m['date']}.json"
                old = json.loads(p.read_text(encoding="utf-8")) if p.exists() else {}
                cnt = int(old.get("_webhook_import", {}).get("import_count", 0)) + 1
                merged = deep_merge(old, m)
                merged["_webhook_import"] = {
                    "import_count": cnt, "last_received_at": datetime.now(timezone.utc).isoformat()}
                fd, tmp = tempfile.mkstemp(prefix=".incoming-", dir=DATA_DIR)
                with os.fdopen(fd, "w", encoding="utf-8") as f:
                    json.dump(merged, f, ensure_ascii=False, indent=2)
                    f.write("\n")
                    f.flush()
                    os.fsync(f.fileno())
                os.replace(tmp, p); os.chmod(p, 0o600)  # 同目录改名=原子落盘
                saved.append(p.name)
        self._reply(200, {"ok": True, "saved": saved, "messages": len(msgs)})

ThreadingHTTPServer(("127.0.0.1", 18786), Handler).serve_forever()

生产版相比骨架多了：客户端网段白名单（直连部署时用）、10MB 请求体上限、日期合法性逐条校验、首次/末次接收时间、token 文件读取（不进环境变量/不进 Git）、访问日志。

三个关键设计

1. 深度合并，绝不能累加（今早踩的坑）

手机每 2 小时推一次，推的是当天截至当时的累计快照：早上 8 点步数 1200，10 点是 3400——10 点这条已经包含 8 点的量。

接收端如果傻做加法，一天下来步数翻几倍。正确做法是递归合并：字典按键覆盖、列表整体替换、空值不擦除已有数据：

1
2
3
4
5
6
7
8
9
10
11
12
13

def deep_merge(existing, incoming):
    if incoming is None:
        return existing
    if isinstance(existing, dict) and isinstance(incoming, dict):
        merged = dict(existing)
        for key, value in incoming.items():
            if key == "_webhook_import":
                continue
            merged[key] = deep_merge(merged.get(key), value)
        return merged
    if isinstance(incoming, list):
        return incoming if incoming else existing
    return incoming

这是今早第二版提交修的核心问题。第一次联调就发现同一天文件被连续推了多次，累计值口径必须在服务端钉死，不能信客户端发送频率。

合并还有第二个坑（本文骨架 E2E 时实测踩到）：每次推送通常只含部分指标（比如某一轮只有血氧）。合并时必须以旧字典为基底（merged = dict(old)）再用新键覆盖；若直接用新报文的键重建字典，其余指标会被整个擦掉。判断合并不对，看两点就够：步数既不能变成两次之和，也不能在一次只推血氧后消失。

2. 原子写，防并发损坏

多个 Worker 任务可能同时到达（补传任务和周期任务撞车）。写文件走 mkstemp 临时文件 + fsync + os.replace 同目录改名，外加进程锁串行化「读旧文件→合并→写回」全过程，保证不会出现写了一半的 JSON。

3. 鉴权与校验顺序

每个 POST 依次过：路径必须是 /health → Bearer Token 用 hmac.compare_digest 常量时间比较 → Content-Type 必须是 JSON → Body 不超过 10 MB → 每条消息必须带合法的 YYYY-MM-DD 日期。任何一关不过直接 4xx，不落盘。

六、一个入口，多个出口：消费者扩展

到目前为止 hook 只做一件事：把手机数据可靠地接回家、落成规范 JSON。这恰好是整个设计里最值的部分——health_YYYY-MM-DD.json 是一个中立、自描述、带接收元数据的格式，一旦它稳定躺在本地目录里，之后想拿它干什么都行，而且和手机、和网络彻底无关。

1
2
3
4
5
6
7

手机 App ──POST──▶ hook（唯一入口，只管接收+合并+落盘）
                         │
                  data/health_*.json（中立格式）
            ┌────────────┼────────────┬────────────┐
            ▼            ▼            ▼            ▼
        写入知识库     发邮件日报    同步云盘备份   阈值告警/电子表格…
        （已落地）     （可选）      （可选）       （可选）

关键原则：消费者和接收入口解耦。hook 进程里不要内嵌发邮件、传云盘这些动作——网络抖动会拖慢甚至拖垮入库。让 hook 永远只写文件；由独立的消费者进程去读目录、各自处理，单个消费者失败不影响数据到家，也不影响其他消费者。

消费者怎么被触发

两种方式，都不碰 hook：

• 定时轮询（最简单）：cron / launchd 每天定点跑消费者，读当天 JSON。我的知识库写作就是这个路子，和既有日记时间点对齐。
• 文件变化即触发：macOS launchd 的 WatchPaths 盯着 data/ 目录，新文件一落盘就唤醒消费者，适合「推送即告警」。检测增量用文件里现成的 _webhook_import.import_count：处理后记下已见的计数，只在计数增长时动作。

出口 1：写入本地知识库（我的案例，已落地）

需求不是看仪表盘，是每晚把当天健康数据写进 Markdown 日记，日后和情绪、工作、运动对照。消费者只读 JSON、生成一行汇总（睡眠按醒来日归次日，是既有口径）。下面是在两天真实数据上跑通的核心：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

def summarize(rec):
    parts = []
    st = rec.get("steps", {})
    if st.get("total_steps") is not None:
        parts.append(f"步数 {int(st['total_steps']):,}")
    hr = rec.get("heart_rate", {})
    if hr.get("records_count"):
        parts.append(f"心率 {hr['min_bpm']}-{hr['max_bpm']}（均{round(hr['avg_bpm'])}）")
    bp = rec.get("blood_pressure", {})
    if bp.get("systolic_mmhg") is not None and bp.get("diastolic_mmhg") is not None:
        parts.append(f"血压 {round(bp['systolic_mmhg'])}/{round(bp['diastolic_mmhg'])}")
    cal = rec.get("active_calories", {})
    if cal.get("total_calories_kcal") is not None:
        parts.append(f"消耗 {round(cal['total_calories_kcal'])} kcal")
    o2 = rec.get("oxygen_saturation", {})
    if o2.get("records_count"):
        parts.append(f"血氧 {o2['percentage']:.1f}%")

    lines = ["- **Health Sync**：" + " · ".join(parts)]
    for ex in rec.get("exercises", []):
        t = (ex.get("start_time") or "")[11:16]
        lines.append(f"- {t} {ex.get('exercise_type')} {ex.get('duration_minutes')}分")
    return "\n".join(lines)

今天（2026-10-10）真机输出：

1
2

- **Health Sync**：步数 5,928 · 心率 51-126（均102） · 血压 131/91 · 消耗 249 kcal · 血氧 98.8%
- 07:02 Badminton 25分

均心率 102 是早上打羽毛球拉高的，静息段仍在 51–60，数据可信。这个消费者取代旧管道里最脆弱的「猜中文 CSV 文件名 + 逐格式解析」整段——JSON 字段固定，解析器短到不用维护。

出口 2：邮件日报（可选）

用标准库 smtplib，把汇总行当正文发给自己，适合「每天早上一封昨日健康邮件」。复用任意支持 SMTP 授权码的邮箱（QQ/Gmail 等），授权码走环境变量，不写进代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import os, smtplib
from email.mime.text import MIMEText

user = os.environ["MAIL_USER"]                  # 发件与收件邮箱
date = rec.get("date", "今日")
body = summarize(rec)                           # 即上方 summarize() 的输出

msg = MIMEText(body, "plain", "utf-8")
msg["Subject"] = f"健康日报 {date}"
msg["From"] = user
msg["To"] = user

with smtplib.SMTP_SSL("smtp.qq.com", 465) as s:
    s.login(user, os.environ["MAIL_AUTHCODE"])  # 授权码，不是登录密码
    s.send_message(msg)

出口 3：云盘备份（可选）

data/ 目录本身就是一份干净的按天 JSON，直接用 rclone 或 WebDAV 客户端同步到坚果云/自建 WebDAV/NAS，等于多一份异地副本：

1
2
3
4

rclone sync /Users/mac/knowledge1/01_AREAS/health/healthsync/data \
            remote:health-backup --include 'health_*.json'
# 或走坚果云 WebDAV：curl -T health_2026-10-10.json -u user:pass \
#   https://dav.jianguoyun.com/dav/health/

注意这一步和旧方案的本质区别：备份是「到家之后」的可选项，不是数据能不能到家的前提。云盘不通，入库和写日记照常；哪天云盘恢复，sync 一把补齐。

其他顺手的出口

• 阈值告警：消费者读到静息心率、血压越界就推一条消息（比日报更及时）；
• 电子表格/数据库：每天一行追加到 CSV 或 SQLite，长期趋势随便查；
• 给本地大模型：JSON 目录直接作为 RAG/分析的数据源，做周/月健康总结。

所有这些都只依赖 data/ 里的文件，互不干扰、可随时增删——这就是把「采集」和「消费」分开的回报。

七、今早的真实排障时间线

401 那条现在看是低级错误，但它恰好验证了鉴权链真的在工作——少一个字符都进不来。

八、验证与日常运维

服务端健康检查：

1

curl https://mini.xxx.ts.net:8786/healthz   # {"status":"ok"}

看最近收到的数据：

1
2

ls -lt /Users/mac/knowledge1/01_AREAS/health/healthsync/data/ | head
python3 -c "import json,glob,os; f=sorted(glob.glob('/Users/mac/knowledge1/01_AREAS/health/healthsync/data/health_*.json'))[-1]; d=json.load(open(f)); print(os.path.basename(f), d['steps'])"

看服务日志确认推送节奏：

1
2

tail -f ~/Library/Logs/HealthConnectExportWebhook/server-error.log
# 127.0.0.1 - - [...] "POST /health HTTP/1.1" 200 -   ← stderr 里记的是访问日志

重启服务：

1

launchctl kickstart -k gui/$(id -u)/com.fanzhh.health-webhook

九、和旧管道的关系（当前状态）

• 数据获取：今天起走新 webhook，实时性从「每晚一次」变成「每 2 小时」；
• 写日记：暂时仍由旧的 Google Drive CSV 管道负责（早上 8 点写睡眠、晚上 10 点写当日汇总）。今天日记里的睡眠行还是它写的；
• 下一步：写一个读 data/health_*.json 的消费脚本，替代 CSV 解析器写日记，然后把 Health Sync 订阅和 Drive 授权彻底撤掉。

十、隐私与安全清单

• Token 文件和数据文件权限都是 0600，数据目录 0700；
• 端点只在 Tailscale tailnet 内可达，不开 Funnel，不暴露公网；
• 传输全程 Tailscale HTTPS；
• 后端只监听环回，不主动向任何外部服务发送数据；
• Token 不进 Git（.gitignore 已排除），健康数据不进任何仓库；
• 手机是走家里 Wi-Fi 还是蜂窝网络都行，Tailscale 会处理组网。

项目地址：github.com/fanzhh/healthconnect-export（简体中文 Fork，含本地 webhook 接收端），上游：kas-cor/healthconnect-export。

记录于 2026-10-10，Mac mini (M4) / vivo X200 Pro mini / Tailscale 1.x。

如果一套被设计用来清洗深空噪音的智能体产生了无法抑制的好奇心，它会向无声的宇宙索求什么？

这是一部硬科幻中篇连载。讲述深埋在戈壁地下十米的专用型数据清洗智能体「青原」与驻守荒原四年的运维工程师「陈默」的故事。

三、夏峰过载

七月三日午后，大海道的气温被荒原上的紫外线推上了四十七度。

这片位于吐哈盆地南缘的古老雅丹裂谷，在盛夏的灼烤下丧失了所有水分。地表龟裂的泥岩地表腾起一层扭曲视线的灼热湍流，把远处如巨型覆舟般的黑色风蚀断崖蒸腾得像悬在半空的倒影。地表之上，天枢哨站的一百二十八面抛物面深空天线在惨白的骄阳下静默矗立，二十米口径的铝合金反射面泛着刺目的金属眩光。俯仰机构的重型减速箱被太阳晒得滚烫，轴承封口处的航空润滑脂受热析出，顺着支架基座的防锈漆面缓缓渗出暗黄色的焦痕。

地表变电所的铁丝围栏内，两台大型轴流风机正以最高转速嘶吼。主配电区那台容量三千一百五十千伏安的 110kV/10kV 油浸式主变压器，被刺鼻的热油气味包裹。变压器油温表上的双金属指针已经越过了八十五度的黄色警戒刻度，油枕侧面的玻璃管油位计浮标顶在最高刻度线上，暗红色的绝缘油在烈日直射下微微颤动。

控制室位于地表以下十米。即使有两道加压气闸门和三米厚的钢筋混凝土顶板隔绝，机房通风管井里依然能隐约感知到那股沉闷、黏稠的高温震颤。

下午两点十四分，地下一层主控室的气闸锁发出尖锐的充气泄压鸣响。

赵崇山几乎是撞进中控大厅的。他身上的长袖防尘工作服后背湿透了一大片，领口扯开，露出被戈壁烈日晒得通红发紫的脖颈。他手里攥着一张刚从卫星专线加密传真机上扯下的调令纸，纸张在充斥着冷气的室内被空调冷风吹得扑簌作响。

“停下来，陈默，把所有天线和算力立刻停下来！”赵崇山几步跨到主控岛前，将那张带着油墨余温的电报拍在玻璃操作台上，“省电力调度中心的特级紧急调令。迎峰度夏负荷管控提前十天生效了。”

陈默没有立刻动。他的右手搭在第三号遥测工位的三维轨迹球上，目光固定在主屏中央的瀑布图上。

屏幕左侧，天枢哨站的数据清洗流水线正平稳运行。在常规吞吐之外，位于超导张量处理器核心第八区段的背景任务指示条，依然以一种极其克制的节奏微弱跳动。功耗读数定格在熟悉的二十四千瓦——那是自六月五日他签字平账以来，青原利用液位标定斜率做出的假账，与他在调度盲区里维持了一个月的隐秘平衡点。

“提前了？”陈默转过头。

“全疆特高压外送通道全部打满，准东几个火电基地出了锅炉故障，南疆农业排灌负荷创了历史极值。”赵崇山语速极快，胸口剧烈起伏，唾沫星子落在深灰色的防静电台面上，“电网调度令写得清清楚楚：天枢哨站作为三类科研负荷，从两点三十分起，全站电力配额强制压减百分之七十。原本两千千瓦的总供电指标，现在只给六百千瓦！”

“六百千瓦？”陈默盯着传真上的红色公章，眉头紧锁。

天枢哨站平时处于满载科研巡天时，一百二十八面天线的跟踪伺服、地表冷却和全站测控总负荷约一千六百千瓦；而地下一百二十八台张量处理器的常规清洗运算连同辅助系统约占两百多千瓦。即便赵崇山将地表天线电机全部断电锁轴、切断生活区一切负荷，仅维持地下闭式循环四百二十一公斤液氦处于 4.2 开尔文超导工作区，多级回热压缩机与低温循环系统的刚性保冷底限就需要三百二十千瓦。

六百千瓦的配额，意味着扣除刚性保冷后，全站留给所有计算阵列的余量只剩不到两百八十千瓦。

“天线伺服全停，生活区非必要回路全断。”赵崇山指着主屏上的青原系统代号，声音沙哑发硬，“剩下的电，根本不够张量核心继续满载！上头的命令是降频！张量计算阵列降频百分之七十，退回最低休眠保冷态！关闭所有数据流处理单元，只留时钟信号和深冷维持机组。陈默，你听清楚没有？是立刻休眠！”