交织的系统：作者 PAOS 组件全景分析（完整版）

交织的系统：作者 PAOS 组件全景分析（完整版）

分析对象：WeClaw / Knowly / DSH / ima / Hermes / knasync / 雨轩编辑器 / sourcepack / 自研 CLI / ds.example.com / ima-proxy / 浏览器插件群 / TAAGE / t机 / b机 / u机 / Mac / ZeroTier / WireGuard
分析日期：2026-10-21（修订版）
分析原则：以组件之间的连接为纲，不以组件清单为纲

脱敏说明：本文所有公网 IP、内网地址、域名、主机名、SSH 端口均已替换为文档保留段或通用描述（192.0.2.0/24、198.51.100.0/24、203.0.113.0/24 为 RFC 5737 示例地址）。

---

序：为什么不能用“清单”来写这套系统

大多数“系统介绍”是这么写的：先列组件，再逐个讲功能。这种写法对 PAOS 是失效的。

因为 PAOS 的每个组件，单拎出来都不完整：

• Knowly 单看是“剪贴板监听器”，放进系统里才是“记忆的入口”
• WeClaw 单看是“微信机器人”，放进系统里才是“意图的路由器”
• DSH 单看是“Agent 运行时”，放进系统里才是“任务的执行现场”
• ima 单看是“知识库产品”，放进系统里才是“云端能力层 + 共享知识库 + 备用工作台”
• Hermes 单看是“Telegram agent”，放进系统里才是“常驻执行面 + 排障入口”
• t / b / u / Mac / 网关主机 / NAS 单看是“几台机器”，放进系统里才是“八节点、三层网络”的物理底座

它们的价值，不在“各自能干什么”，在“它们之间怎么咬合”。

所以这篇分析，按“连接”来组织：先看系统整体是什么形状，再看每一对组件之间的接口，再看物理底座，再看治理的分层，最后看风险与未来。

---

第一章 系统的整体形状：不是树，是网

1.1 常见误读：把它当成“平台架构”

第一眼看上去，PAOS 像一套“分层架构”：

接入层 → 编排层 → 执行层 → 记忆层 → 输出层  

这个读法没错，但它漏掉了最重要的东西：层与层之间是双向的，不是单向的。

• 记忆层不只是“被读取”，它也会主动触发（Knowly 捕获后自动归档、自动索引）
• 输出层不只是“终点”，它也会回流（博客/播客的内容会被重新检索、重新引用）
• 执行层不只是“被调用”，它也会反向调用编排层（DSH 里的 Agent 可以调 WeClaw 的路由）

所以它不是一条流水线，是一张网。

1.2 准确形状：三层结构 + 三环 + 一个中枢

最底层：物理底座（连接层）

       公网:  t机（心脏）      b机（备用）      a机（静默备用）  
                │                │                │  
                └──── WireGuard 星型（hub=t） ────┘      ← 机器之间（7×24）  
                             │  
                  网关宿主（KVM + ZeroTier网关 + Docker）  
                             ├─ u机（VM：WeClaw / Hermes / nanobot）  
                             ├─ Mac（主工作台：DSH / Knowly / 隧道）  
                             └─ 群晖 NAS（记忆真源）  
         家门:  ZeroTier（网关主机 网关 198.51.100.1/16）      ← 人和移动设备  
         前门:  Cloudflare Tunnel ×2（Mac + NAS）        ← 公网 HTTP/SSH  

中间层：三环（能力层）

环一：输入环  
剪贴板/截图 → Knowly → NAS 归档 → 索引  
微信消息 → WeClaw → 意图路由 → 执行  
知乎链接 → 中继/插件 → 抓取 → 归档  
  
环二：执行环  
用户意图 → DSH/ima/Hermes → 调用 MCP/技能 → 读写记忆 → 产出  
  
环三：输出环  
产出 → 博客/播客/ima/Kindle → 可被再次检索 → 回到记忆  

上层：中枢

DSH 站在三个环的交点上——能读记忆、能调执行、能触发输出。  

一句话概括形状：

PAOS 是一个“以物理网络为底座、以记忆为底、以执行为轴、以入口为面的三层结构”。

物理底座是“地基”：八台机器 + 三层网络（WireGuard 骨干 / ZeroTier 家门 / Cloudflare 隧道前门），保证“机器之间能互相访问，人和外部也能进得来”。

记忆是底：所有环都依赖它，所有环都往它写。

执行是轴：DSH 是轴的支点，其他执行面（ima、Hermes）是轴的延伸。

入口是面：微信、Telegram、网页、插件，是“人接触到系统”的几个面。

---

第二章 逐对分析：组件之间的接口

这一章是全文的核心。每一节讲一对组件，重点不是“它们各是什么”，是“它们之间交换什么、谁依赖谁、边界在哪”。

2.1 WeClaw ↔ Knowly：入口与记忆的第一次咬合

交换什么：WeClaw 收到的消息（文字、图片描述、链接），可以触发 Knowly 的捕获。

谁依赖谁：WeClaw 不依赖 Knowly 的存在，但 Knowly 是 WeClaw “记住对话”的底座之一。

边界在哪：WeClaw 负责“判断这条消息该不该记”，Knowly 负责“怎么记、记到哪”。

潜在问题：如果 WeClaw 的意图路由判断错了（比如把“发到knowly／存到nas”误判成普通聊天），这条消息就不会进 Knowly。顺带纠正一个词位：“保存到知识库”触发的是 IMA 的知识库，Knowly 组的触发词其实是“发到knowly／存到nas”。这是“路由错误导致记忆丢失”的典型场景。

2.2 WeClaw ↔ DSH：意图与执行的分工

交换什么：WeClaw 把“需要复杂执行”的意图，转给 DSH。

谁依赖谁：WeClaw 依赖 DSH 的“执行能力”，DSH 依赖 WeClaw 的“入口能力”。

边界在哪：WeClaw 决定“谁来干”（路由），DSH 决定“怎么干”（执行）。

关键设计：WeClaw 的 /ygs 前缀，就是把“这条消息交给 DSH”这个动作显式化。没有这个前缀，DSH 就只是“后台的一个服务”，有了它，DSH 就成了“用户可以点名的执行者”。

机制：/ygs 走的是 HTTP——u 机的 WeClaw 把请求 POST 到 Mac 的 dsh-openai-server.mjs（:8490），再用 DSH SDK 起会话；反过来，DSH 里的 weclaw_ask 工具也能回调 u 机 WeClaw 的 OpenAI 兼容接口（:18011）。所以这一对是真双向，不是单向投递。

补充：WeClaw 还能通过 /h 调 Hermes，说明 WeClaw 不只是“DSH 的入口”，它是“所有执行面的统一入口”。

2.3 WeClaw ↔ Hermes：微信入口与常驻 agent

交换什么：WeClaw 通过 /h 前缀，把消息转给 Hermes 执行。

谁依赖谁：WeClaw 依赖 Hermes 的“常驻执行能力”，Hermes 不依赖 WeClaw。

边界在哪：WeClaw 负责“微信入口”，Hermes 负责“常驻执行”。

关键设计：/h 这个前缀，让 Hermes 成了“WeClaw 的一个下游”。用户不需要知道 Hermes 在哪，只需要在微信里打 /h。

机制：它不是网络调用——WeClaw 用 ACP 协议在本机起一个 Hermes 子进程、握手后把消息喂进去（config.json:288-304）。所以“微信→Hermes”是一段进程间握手，不是 HTTP。

2.4 DSH ↔ Knowly：执行现场与记忆底座的咬合

交换什么：DSH 在执行任务时，读 Knowly 的记忆（历史剪藏、归档内容），也写 Knowly（把执行结果归档）。

谁依赖谁：DSH 依赖 Knowly 提供“上下文”，Knowly 依赖 DSH 提供“有意义的写入”。

边界在哪：Knowly 负责“存和取”，DSH 负责“用和产”。

这是整个系统最重要的一对接口。 因为：

• 没有 Knowly，DSH 的每次执行都是“从零开始”
• 没有 DSH，Knowly 的记忆就只是“死档案”，不会被使用

你前面说的“记忆层自持，模型层无状态”——这一对就是它的落地：Knowly 是“自持的记忆”，DSH 是“无状态的执行”。

2.5 DSH ↔ ima：运行时与云端能力层

交换什么：DSH 通过 MCP 调 ima 的笔记／知识库能力（write_note／kb_add／kb_read，共 16 个工具），同时可以搜 ima 的知识库、做比较。

两处要校正：播客不是 MCP——它走的是 skill 调 App 逆向协议（/cgi-bin/assistant/qa）；PPT 全系统没有工具。

谁依赖谁：DSH 依赖 ima 的“重能力”和“共享知识库”，ima 不依赖 DSH。

边界在哪：ima 提供“能力 + 知识库”，DSH 提供“编排”。ima 不知道是谁在调它，DSH 知道自己在调什么。

关键约束：ima 的 KB 内容级搜索有限（你前面聊过，KB 内容级搜索做不到）。所以 DSH 调 ima，本质是“能力调用 + 有限搜索”，不是“完全双向交互”。

2.6 Hermes ↔ ima：常驻 agent 与共享知识库

交换什么：Hermes 可以搜 ima 的知识库。

谁依赖谁：Hermes 依赖 ima 提供“云端知识”，ima 不依赖 Hermes。

边界在哪：ima 是“共享知识库”，Hermes 是“读取方”。

关键设计：ima 作为“共享知识库”，不是“某个执行面的私有物”。DSH 能搜，Hermes 也能搜——这是“知识库作为底座”的体现，不是“知识库作为某个入口的附属”。

2.7 Hermes ↔ DSH：常驻 agent 与 Mac 运行时的排障链路

交换什么：Hermes 可以 SSH 到 Mac，读 DSH 的源码和工作区，排查问题。

谁依赖谁：Hermes 依赖 Mac 的“可 SSH 访问”，DSH 不依赖 Hermes。

边界在哪：Hermes 负责“从外部排查”，DSH 负责“被排查”。

关键设计：这条链路让“排障”从“必须坐在 Mac 前”变成了“手机上也能做”。

风险：SSH 权限是“隐形的高危接口”。如果 Hermes 被劫持，攻击者就能通过它的 SSH 权限，读到 Mac 上的所有东西。缓解方式：给 Hermes 一个“能看不能改”的边界。

2.8 DSH ↔ ima ↔ Hermes：三层执行面的互通

之前我把它们写成“三种入口形态，互不依赖”——这是错的。

修正后：

• DSH 能搜 ima，Hermes 也能搜 ima（ima 是共享底座）
• WeClaw 通过 /h 调 Hermes（WeClaw 是统一入口）
• Hermes 能 SSH 到 Mac 读 DSH 源码（排障链路）

这意味着三层不是“三个孤岛”，是“三个能互相敲门的房间”。

2.9 ima ↔ Hermes：两个“备用工作台”的关系

交换什么：基本不直接交换，但共享 ima 的知识库。

谁依赖谁：都不依赖对方。

边界在哪：它们是平行的两个“备用执行面”——ima 是“云端成品平台”，Hermes 是“家里常驻 agent”。

它们的共同点：都能在 DSH 不可用时，接住“继续干活”的需求。

它们的区别：ima 的治理在平台手里，Hermes 的治理在你自己手里。

2.10 WeClaw ↔ Hermes：两个入口，也是一条通道

交换什么：作为入口，它们各自独立；但 WeClaw 还能用 /h 直接把消息交给 Hermes（ACP 子进程，见 2.3）。

谁依赖谁：作为“入口”彼此不依赖；但 /h 这条线上，WeClaw 依赖 Hermes 的常驻执行。

边界在哪：WeClaw 是“微信入口”，Hermes 是“Telegram／钉钉入口”。它们服务“同一个人的不同场景”，而 /h 让它们又互为通道。

一个隐含设计：两个入口，意味着“你不把鸡蛋放在一个篮子里”。微信挂了，Telegram／钉钉还能用；反过来，Telegram 挂了，也能从微信打 /h 过去。

2.11 Knowly ↔ knasync：捕获与中继的接力

交换什么：knasync 的 /pull 拉到的内容，最终会进入 Knowly 的归档链路。

谁依赖谁：Knowly 依赖 knasync 提供“外部来源的内容”；但 knasync 的有序运转又依赖 Knowly——消费 general 队列的正是 Knowly 自己（8 秒轮询），而知乎链接只走 knasync（直连会 403）。所以这一对是“Knowly 既消费、也生产”的双向依赖，不是单向。

边界在哪：knasync 负责“把内容从 A 搬到 B”，Knowly 负责“把内容变成记忆”。

关键设计：knasync 的“消费即清空 + 结果广播”，保证了“多端消费不重复、结果可追溯”。这是“输入端”的治理。

2.12 DSH ↔ 浏览器插件：运行时与感知器官

交换什么：插件捕获的页面内容（知乎文章、网页正文），通过中继进入 DSH 或 Knowly。

谁依赖谁：DSH 依赖插件提供“网页内容的感知”，插件不依赖 DSH。

边界在哪：插件负责“在浏览器里看和抓”，DSH 负责“拿到内容后怎么处理”。

关键设计：你那个知乎助手的“AI 解读”按钮，本质是“插件把内容喂给模型”——这是“感知器官”直接连到“大脑”的一条短路。

2.13 sourcepack ↔ 所有代码项目：打包与审计

交换什么：sourcepack 把项目打包成 Markdown 快照，供 AI 审计。

谁依赖谁：所有项目“被 sourcepack 处理”，sourcepack 不依赖具体项目。

边界在哪：sourcepack 负责“把代码变成可读的文本”，AI 负责“读文本做判断”。

它在你系统里的位置：它不是“执行组件”，是“审计组件”——它让“代码”变成“可以被 AI 读的东西”，从而让“审计”这件事自动化。

2.14 ds.example.com ↔ 搜索链路：自建入口

交换什么：把 DeepSeek 的搜索能力，包成自己的入口。

谁依赖谁：你的系统依赖它提供“搜索能力”，它依赖 DeepSeek 的搜索后端。

边界在哪：它负责“入口和编排”，DeepSeek 负责“搜索结果”。

它的意义：和 ima-proxy 是同一个逻辑——能力是租的，入口是自己的。

2.15 agent-policy ↔ 所有组件：治理层（原文写的 TAAGE，已不在位）

先说结论：原文这里写的是 TAAGE。实测下来——TAAGE 没有上线。它是一套真实存在、文档齐全的引擎（trusted-agent-engine v2.0.0，GOVERNANCE_INVARIANTS / SPECIFICATION / value_manifesto 都在），但 DSH 在 2026-10-09 评估后拒绝以依赖形式引入（签名可被删公钥绕过、非 ASCII 误伤中文、9 套示例测试 7 套失败），改为重写为原生插件 @deepseek-ai/dsh-agent-policy。真正在位的是后者。

交换什么：它不交换“内容”，交换“准入”——一次代码变更该不该被放行。

谁依赖谁：所有变更“被它裁决”，它不依赖具体组件。

边界在哪：它负责“定规则、留证据”，其他组件负责“执行规则”。

它在你系统里的位置：它是“唯一的治理层”——策略落在 ~/.dsh/agent.policy.yaml（Ed25519 已签名），裁决留痕在 JSON Lines 账本里。没有它，系统是“一堆能力”；有了它，系统才是“有纪律、且可审计的系统”。

它管什么（和原文说的不一样）：不是“订阅台账／成本路由／能力开关”，而是代码变更准入——Diff 审计、异常评分、价值判断、责任归属、信用分。

2.16 所有执行面 ↔ 模型闸门：被原文漏掉的一整层

原文把“模型”当成“租来的能力”，一句带过。但实测它是一整个层，而且是最脆的一层：

• aiproxy.example.com（CF Worker，三层鉴权）→ t 机 poeapi_go(9090) → Poe：WeClaw、自研 CLI、knowly 的主通道
• wx.example.com（WeClaw 自己的网关）← knowly 打标走它，model “Assistant”
• Mac wb-proxy(8487) ← Hermes 主模型 tencent-fast 走它，上游 copilot.tencent，实际路由 deepseek-v4.1-flash

关键判断：“能力是租的，闸门是自己的”——但闸门里有一道开在 Mac 上。这就是后面要说的“单点半径扩大”。

---

第三章 物理底座：八节点 + 三层网络

这一章是修订版新增的，也是实测改动最大的一章——原文写的是“四节点 + 双网络”，实测下来，是八台机器、三层网络。它是前面所有“连接”的“地基”：没有这个地基，上层的能力都是“悬空”的。

3.1 八节点：不只是 t / b / u / Mac

节点	角色	位置	用途（实测）
t 机	链路心脏（不只是跳板）	腾讯云 203.0.113.11	WireGuard hub（192.0.2.1/24）；nginx 跑 api.example.org；模型网关 poeapi_go(9090)；推送 notifyd/pushd；wsstunnel 中继
b 机	备用入口（已打通）	搬瓦工 203.0.113.12（洛杉矶）	WG peer 192.0.2.3；SSH 在非标准端口（不是 22），2026-10-22 已打通。原文“半身不遂/SSH 全关”作废
a 机	静默备用	阿里云上海 203.0.113.13	WG peer 192.0.2.2（活跃）；公网无任何 DNS 记录——唯一不暴露 IP 的公网机；2026-10-22 已打通
u 机	执行节点（虚拟机）	家里 / 网关主机 上的 KVM VM	WeClaw(18011)、Hermes 四件套、nanobot。它不是独立物理机，是 网关主机 上的一台 Ubuntu 虚拟机
Mac	主工作台（多角色）	家里 / 192.0.2.100	DSH×2、Knowly、cloudflared 隧道、wb-proxy(8487)、ima-proxy、代理群
网关宿主	家庭虚拟化+网络宿主	家里 / 192.0.2.225	OpenWrt 系统；KVM 跑 u VM；Docker×4；ZeroTier 网关 198.51.100.1/16；eMMC 已用 82%
群晖 NAS	记忆真源	家里 / 192.0.2.186	/volume1/（18T，已用 5.4T）；自跑 cloudflared 隧道 NAS 侧隧道（家网总门）
ali（阿里美国）	待接入	203.0.113.14	在线但 key 未分发；与 a 机（上海）是两台不同机器

几个关键纠正：

• “四节点”是低估。真正的核心是八台，而且 u 机是 网关主机 上的虚拟机——WeClaw/Hermes/nanobot 全家桶，实际都跑在这台 N6005 上。家庭侧真正的单点是 网关主机，不是 u。
• t 机不是“薄跳板”，是心脏。它跑着模型网关、博客 API、两条微信出口和隧道中继——原文“t/b 不跑业务只跑 SSH 和 pi”是错的。
• b 机不是“半身不遂”，SSH 在 非标准端口 且开着，2026-10-22 已打通；a 机也已打通。
• t、b、u、Mac 不能“任意互 SSH”——b/a 的 key 是后来才铺的，ali 至今没铺。

3.2 三层网络：WireGuard 骨干 + ZeroTier 家门 + Cloudflare 前门

原文说“双网络”，方向对，但其实是三层，而且分工很不一样：

层	是什么	服务谁	形态
WireGuard	自建 VPN 骨干	机器之间（服务器/工作站 7×24 互连）	星型：hub = t 机（192.0.2.1），spoke 经 t 转发
ZeroTier	托管式虚拟局域网	人和移动设备进家门	网关式：网关主机 做 198.51.100.1/16 网关 + NAT
Cloudflare Tunnel	出站隧道	公网 HTTP/SSH 进家门（不暴露源站 IP）	两条独立隧道：Mac 一条、NAS 一条

为什么要三层？因为它们的“失败方式”不重叠：

• WireGuard 挂了 → 机器之间断，但 ZeroTier 还能让手机上；CF 隧道照常
• ZeroTier 挂了 → 远程人进不来，但机器之间的 WG 骨干不受影响
• CF 隧道挂了 → 网页入口没了，但 WG / ZT 的 SSH 还在
• 三层故障模式不重叠，这才是真“异构冗余”

几个要点：

• ZeroTier 不是“退役了”，是装在 网关主机 路由器上做网关——内网终端（Mac/u/t）走本地直连，根本不需要装 ZT 客户端，所以你在这些机器上找不到它，是拓扑正常，不是它没了。
• CF 隧道其实是两条：Mac 侧隧道（Mac 上跑）+ NAS 侧隧道（NAS 上自跑，42 条 ingress，是家网总门）。DNS 里另有 4 条已死隧道的残骸。

3.3 不是“平面网”，是“星型 + 三层入口”

原文说“现在是平面网，任意互访”——不完全对：

• WireGuard 是星型：spoke 之间的流量要经 t 机转发，不是任意直连
• ZeroTier 是网关式：远程设备经 网关主机 NAT 进来，不是扁平广播域
• 但入口确实冗余了：机器有 WG、人有 ZT、外部有 CF——这三条腿互不重叠

所以准确的说法是：骨干是星型，入口是三路。“任意互访”只在同一层内近似成立。

3.4 降落链（八节点版）

环	依赖	失败后
一：DSH（Mac）	Mac 运行时	切 ima / Hermes
二：ima（云端）	ima.qq.com 双协议	切 Hermes
三：Hermes（u VM）	tencent-fast（Mac wb-proxy:8487） + TG/钉钉；依赖 网关宿主 + Mac 在线	WeClaw ACP 调用 / ssh
四：t 机（心脏）	nginx / poeapi_go / pushd / notifyd	CF 隧道仍在（入口层独立于 t）
五：b / a + CF 隧道	b：仅 WG 生存；a：仅 WG 在线；CF：边缘入口	—
家里的门：网关宿主	KVM(u VM) + Docker + ZeroTier 网关	u 全家桶与远程接入同时消失 → 只剩 WG 直连 t 与 CF 隧道

注意：第三环的 Hermes 与整个 u 机（WeClaw/nanobot）都寄生在 网关主机 的 KVM 里——家侧真正的单点是 网关主机，不是 u。

3.5 这个物理底座的风险

风险一：t 机是“心脏”，也是“攻击面”

• 它不“薄”——跑着模型网关、博客 API、推送出口
• 如果被攻破，攻击者不只能进内网，还能改你的模型通道

缓解：t 机要“有认证、有监控、有最小权限”；真正该“薄”的是 b/a 这类备用机。

风险二：三层网络的“隔离”不彻底

• 三条腿最后都落在同一间屋子、同一条宽带上
• Mac 同时是 WG 节点、ZT 可达、CF 隧道入口——它是“多角色交点”（不是原文说的“双网交点”，是“多角色”）
• 密钥如果共用一套，泄露则三层一起失守

缓解：至少做到“控制面、密钥、物理出口”三处尽量分离；Mac 上的角色越多，越该做最小权限。

风险三：SSH 权限是“隐形的高危接口”

• Hermes 能 SSH 到 Mac，读源码、看工作区
• 如果 Hermes 被劫持，攻击者就能通过它的 SSH 权限，读到 Mac 上的所有东西

缓解：给 Hermes 一个“能看不能改”的边界（只读权限、或只允许访问特定目录）。

风险四：家庭单点 网关主机

• u 虚拟机 + ZeroTier 网关 + 4 个 Docker 全在一台 N6005 上
• eMMC 已用 82%，Ubuntu.qcow2 单文件 63GB 还在长——磁盘写满会同时带走 WeClaw/Hermes/ZT 远程接入

缓解：qemu 盘瘦身/迁到 NAS 卷；给 eMMC 加容量告警。

---

第四章 交织的本质：三种“连接模式”

把第二章的 15 对接口归纳一下，会发现它们其实只有三种连接模式。

4.1 模式一：单向依赖（能力提供方 → 能力消费方）

例子：DSH → ima（DSH 调 ima 的能力）、Knowly → knasync（Knowly 消费 knasync 的内容）

特点：一方提供能力，一方消费能力，没有反向依赖。

好处：边界清晰，替换成本低（换掉 ima，DSH 只需要改 MCP 配置）。

风险：提供方变了，消费方要跟着变（ima 的 API 变了，DSH 的 MCP 要改）。

4.2 模式二：双向咬合（互相依赖）

例子：WeClaw ↔ DSH（入口依赖执行，执行依赖入口）、DSH ↔ Knowly（执行依赖记忆，记忆依赖执行来“激活”）

特点：双方都依赖对方，缺一个，另一个的价值就下降。

好处：咬合越紧，系统越“像一个整体”。

风险：单点故障会传导——Knowly 挂了，DSH 的“记忆能力”就没了；DSH 挂了，Knowly 的记忆就“没人用”。

4.3 模式三：平行冗余（互不依赖，但覆盖同一需求）

例子：ima ↔ Hermes（都是备用工作台）、WeClaw ↔ Hermes（都是入口）、t 机 ↔ b 机（都是跳板）、ZeroTier ↔ WireGuard（都是网络）

特点：互不依赖，但服务同一个需求。

好处：防单点——一个挂了，另一个能接住。

代价：维护成本翻倍——两套东西都要维护。

4.4 三种模式的配比，决定了系统的“性格”

你的系统，三种模式都有，但配比很特别：

• 单向依赖最多（能力层基本都是单向的）
• 双向咬合最少（只有 WeClaw↔DSH、DSH↔Knowly 这两对）
• 平行冗余居中（ima、Hermes、WeClaw、Telegram、t/b 机、ZeroTier/WireGuard 形成了几组冗余）

这个配比说明：你的系统“咬合不深，但冗余充分”。

好处：任何一个组件挂了，系统不会整体停摆。

代价：整体感不强——它更像“一组能协作的工具”，而不是“一个浑然一体的产品”。

而这，恰恰是“个人系统”和“商业产品”的区别：商业产品要“浑然一体”，个人系统要“随时可拆”。

---

第五章 治理的分层：谁说了算

这是全文最容易被忽略、但最重要的一章。

5.1 四层治理

第零层：访问治理（t / b / a / ZeroTier / WireGuard / Cloudflare 隧道）

• 决定“谁能进来、从哪条路进来”
• 治理对象：网络准入、SSH 权限
• 出问题时的表现：进不去，或者不该进来的进来了

第一层：入口治理（WeClaw / Hermes）

• 决定“这条消息该给谁”
• 治理对象：意图路由
• 出问题时的表现：消息给错了 agent

第二层：执行治理（DSH / ima / Hermes）

• 决定“这个任务该怎么执行”
• 治理对象：工具调用、上下文、沙箱
• 出问题时的表现：任务执行偏了、或者失败了但没报错

第三层：记忆治理（Knowly / NAS / ima）

• 决定“什么东西该被记住、记在哪、怎么取”
• 治理对象：归档、索引、恢复
• 出问题时的表现：记忆丢了、或者记忆取不出来

5.2 四层治理的“权重”不一样

访问治理最底：它是“其他所有治理的前提”——进不来，什么都谈不上。
入口治理最轻：路由错了，重发一次就行。
执行治理最重：执行错了，可能产出错误结果、或者破坏了数据。
记忆治理最根本：记忆错了，整个系统的“历史”就不可信了。

所以你的系统里，“记忆治理”的权重最高——这也是为什么你把 Knowly 放在“底座”的位置。

5.3 “治理不能外包”在四层里的具体含义

层	能外包什么	不能外包什么
访问	虚拟局域网的“根服务器”（ZeroTier 是别人的）	准入规则、SSH 权限（谁能进来，是你定的）
入口	消息通道（微信、Telegram 是别人的）	路由规则（谁该处理什么，是你定的）
执行	模型能力（模型是别人的）	执行边界（沙箱、工具白名单、系统提示词，是你定的）
记忆	存储介质（NAS 硬件是别人的）	记忆的归属和可恢复性（存哪、怎么取，是你定的）

一句话：通道可以租，模型可以租，硬件可以租；但“谁能进来、谁该处理什么、能碰什么、记在哪”，必须自己定。

---

第六章 风险：交织带来的六个结构性脆弱点

6.1 脆弱点一：路由错误会“静默丢失”

场景：WeClaw 把一个“该保存”的消息，误判成普通聊天。
后果：这条消息没进 Knowly，但没有任何报错。
为什么危险：你不会发现，直到你需要它的时候。
缓解：精确触发词短路（你已经在做）、日志审计（“这条消息最后去了哪”可查）。

6.2 脆弱点二：双向咬合会“传导故障”

场景：Knowly 挂了。
后果：DSH 的“记忆能力”没了，WeClaw 的“保存”功能也没了。
为什么危险：一个组件挂，两个功能停。
缓解：ima 作为“记忆的备用层”、NAS 作为“记忆的源”（不依赖 Knowly 进程）。

6.3 脆弱点三：平行冗余会“维护失控”

场景：ima、Hermes、DSH 三个执行面，各自的配置、各自的工具集。
后果：改一个功能，要改三个地方。
为什么危险：冗余是防单点的，但冗余本身会变成新的单点（维护的单点）。
缓解：能共享的共享（比如共享同一套 MCP 工具、共享同一套记忆），不能共享的显式标注。

6.4 脆弱点四：治理层的“隐性单点”（已部分化解）

原判断：TAAGE 的规则只在脑子里，没落成文档。
实测更正：规则已经落盘——~/.dsh/agent.policy.yaml 是 Ed25519 签名的策略，裁决留痕成账本；TAAGE 本身也文档齐全（只是被 DSH 否决、改用了重写版）。
新的风险：规则不再“隐性”，但签名的私钥成了新的单点——私钥丢了或泄露，整套准入控制失效。
缓解：私钥离线保管 + 策略变更留痕 + 定期对账本做抽样复核。

6.5 脆弱点五：排障链路本身会成单点

场景：Hermes 能 SSH 到 Mac 排障——但如果 Hermes 自己挂了，谁来排障？
后果：你需要一个“Hermes 的 Hermes”。
缓解：Mac 上有一个“不依赖 Hermes 的本地排障入口”（比如 pi 直接跑在 Mac 上）。

6.6 脆弱点六：网络层的“隔离可能不彻底”（三层版）

场景：WireGuard、ZeroTier、Cloudflare 隧道三条腿，如果都落在同一间屋子、同一条宽带、甚至同一台 Mac 上，隔离就名存实亡。
后果：宽带断，三条腿一起断；Mac 挂，它同时是 WG 节点 + 隧道入口 + 模型上游，一处挂、多处停。
实测情况：Mac 确实是“多角色交点”——执行面、记忆索引、隧道入口、Hermes 模型上游，全在它身上。
缓解：三条腿要“独立到控制面、密钥、物理出口”；Mac 的角色要拆（至少把模型上游 wb-proxy 迁到别处，给 Hermes 留一条不依赖 Mac 的腿）。

---

第七章 这套系统的“不可替代性”在哪

7.1 不是“功能多”

功能多，可以被商业产品追上。你能做的，别人也能做。

7.2 不是“技术强”

技术强，可以被更强的模型追上。你用的模型，别人也能用。

7.3 是“连接的形状 + 物理的底座”

这套系统真正不可替代的，是“连接的形状”和“物理的底座”：

• 记忆的归属：你的记忆在 NAS 上，不在任何平台
• 入口的冗余：微信、钉钉、Telegram、网页、插件、企业微信——六个入口，不止四个
• 执行的备份：DSH、ima、Hermes，三个执行面
• 网络的冗余：WireGuard 骨干、ZeroTier 家门、Cloudflare 前门——三层，故障模式不重叠
• 跳板的冗余：t（心脏）、b（备用）、a（静默备用），三个独立供应商
• 治理的分层：访问、入口、执行、记忆，四层各自有规则，且已签名落盘

这些东西，商业产品不会给你，因为“给你”就意味着“它赚不到钱”。

7.4 一句话

这套系统的不可替代性，不在于“它能做什么”，在于“它的每一条连接，都是按你的需求长出来的”。

商业产品是“标准化生产”，你的系统是“定制化生长”。

---

第八章 如果重来一次，会怎么设计

这一章是“自我批判”，也是“给未来留的接口”。

8.1 会保留的

1. 记忆自持
这是整套系统的“地基”，不能动。

2. 多入口冗余
微信、Telegram、网页、插件，四个入口，保证了“任何一个入口挂了，系统还能用”。

3. 多执行面 + 多跳板 + 多网络
DSH、ima、Hermes 三个执行面；t、b 两个跳板；ZeroTier、WireGuard 两套网络——保证了“任何一个执行面/跳板/网络挂了，任务还能继续”。

4. 以真值为准
--dump-config、日志、会话记录，这些“判卷器”是系统可信的基础。

8.2 会改的

1. 会早点把“治理规则”显式化
现在很多规则是“在你脑子里”，早该写进文档、写进配置。

2. 会早点做“连接的健康检查”
现在很多“连接断了”是“静默失败”，早该给每一对接口加“心跳检测”。

3. 会早点做“冗余的收敛”
ima、Hermes、DSH 三个执行面，t、b 两个跳板，各自的配置有重复，早该“能共享的共享”。

8.3 一个“未来接口”

如果这套系统要继续长，最该长的地方是“连接的可观测性”：

• 每一对接口，有没有“调用了多少次、失败了多少次、延迟多少”的统计？
• 每一个“静默失败”，有没有“被检测到”的机制？
• 每一个“治理规则”，有没有“被违反”的告警？
• 每一条网络路径，有没有“当前是否可达、延迟多少”的探测？

这些不是“新功能”，是“让已有的连接，变得可见”。

---

第九章 物理底座的“最后一道防线”：八节点 + 三层网络

这一章专门讲“全部挂了怎么办”。

9.1 降落链

第一环：DSH（Mac 运行时） → 挂了切 ima
第二环：ima（云端平台） → 挂了切 Hermes
第三环：Hermes（u VM 常驻） → 挂了走 WeClaw ACP / ssh
第四环：t 机（心脏） → 挂了走 b/a 的 WG 直连与 CF 隧道
家里的门：网关宿主 → 挂了等于 u 全家桶 + ZT 远程接入同时消失

9.2 组合覆盖

场景	还能用的路径
DSH 挂了	ima / Hermes / WeClaw→Hermes
ima 挂了	DSH / Hermes
Hermes 挂了	DSH / ima / t 机 ssh
WeClaw 挂了	Telegram / 钉钉 / ssh 跳板
t 机挂了	b / a 的 WG 直连 + CF 隧道
b 机挂了	t / a / 虚拟局域网
ZeroTier 挂了	WireGuard / CF 隧道
WireGuard 挂了	ZeroTier / CF 隧道
Mac 关机	Hermes 只剩 fallback（主模型在 Mac）
全部上层 + t/b/a 都挂了	虚拟局域网（如果网还在）
全部 + 网络都挂了	那基本是“互联网级故障”了

9.3 一个可以补的判断

这个“八节点 + 三层网络”，其实是你整个 PAOS 的“物理韧性”：

• 上层韧性：多入口（六个）、多执行面（三个）
• 中层韧性：记忆自持、索引可重建
• 底层韧性：多跳板（t/b/a）、多网络（WG/ZT/CF）

三层的韧性叠加，让“整体不可用”的概率，从“某个组件挂”降到了“某个技术栈整体挂”。

而“某个技术栈整体挂”的概率，比“某个组件挂”低一个数量级。

但冗余的“腿”在退化：b 机曾长期 SSH 不通、a 机 key 最近才铺、wb2 失联 5 天、ZeroTier 两个远程站点离线、网关主机 eMMC 82%——这五项值得一次专门巡检。

---

结语：交织的系统，是一个“活”的系统

这篇文章写到最后，我想说一件可能有点意外的话：

你这套系统，最像“生命”的地方，不是它“功能多”，是它“连接多”。

• 单细胞生物，只有一个功能（活着）
• 多细胞生物，有很多功能，但功能之间互相依赖
• 生态系统，功能之间互相依赖，而且能自我修复

你的 PAOS，已经从“多细胞”长到了“生态系统”的边缘——

• 它有“记忆”（Knowly）
• 有“代谢”（WeClaw 的路由）
• 有“免疫”（多入口、多执行面、多跳板、多网络的冗余）
• 有“神经”（DSH 的执行）
• 有“骨骼”（八台机器 + WireGuard/ZeroTier/Cloudflare 三层网络的物理底座）

而它最脆弱的地方，也恰恰是它最“活”的地方——
因为“交织”，所以“一处动，全身动”；但也因为“交织”，所以“一处伤，全身能补”。

这套系统的意义，不在于“它现在能做什么”，在于“它还能长成什么”。

而它能不能继续长，取决于一件事：你有没有继续“把新的连接，长进这张网里”。

---

—— 雨轩，于听雨轩
2026-10-21

---

附：全文结构索引

章	主题	核心判断
序	为什么不用清单写	价值在连接，不在组件
一	整体形状	物理底座 + 三环 + 一个中枢
二	逐对分析	15 对接口 + 模型闸门（2.16），三种连接模式
三	物理底座	八节点 + 三层网络（WG/ZT/CF）+ 降落链
四	交织的本质	单向依赖 / 双向咬合 / 平行冗余
五	治理的分层	访问 / 入口 / 执行 / 记忆，四层权重不同
六	风险	六个结构性脆弱点（已按实测修订）
七	不可替代性	不在功能，在连接的形状 + 物理的底座
八	如果重来	保留什么，改什么，长什么
九	最后一道防线	八节点 + 三层网络的组合覆盖
结语	活系统	最脆弱的地方，也是最活的地方

修订说明（2026-10-22）：本版依据 3 路代码级核查 + 5 台机器实测踏勘，修正了物理层（四节点→八节点、双网络→三层网络）、治理层（TAAGE→agent-policy）、连接层（补模型闸门 2.16），并更新了 b/a 机状态。所有结论均给出可复查的证据锚点。