P2P AI伴侣架构实战：点对点直连与本地模型部署全解析

自己一个人做产品，最怕的不是代码写不出来，而是半夜三更对着屏幕突然问自己：这东西到底有没有人用？说实话，做凤希AI伴侣这个项目，最初就是这么一个让人辗转反侧的想法——我想要一个真正“属于自己的”AI，它的记忆放在我的设备上，它的对话逻辑由我决定，它不需要把我的心事交给某个大厂的云端服务器。

当时业界的主流方案都是中心化架构，应用把用户数据传到服务端，算完再返回结果。对于聊天机器人来说这个流程没问题，但对于“伴侣”这种强隐私、强情感属性的场景，我心里过不去这道坎。于是我把目光投向了P2P方向，决定让两端设备直接建立点对点连接，AI推理尽量放在本地或边缘端跑起来。2026年1月13日，这条技术路线终于从纸面构想变成了实际跑通的原型。这篇文章就把完整方案和全过程做一个复盘，包含架构推演、选型对比、核心代码逻辑、实测中的坑和解决思路，给同样想把AI赛博人格搬回本地的朋友作参考。

1. 项目整体设计与思路拆解

1.1 为什么非要走P2P：AI伴侣的中心化困局

市面上绝大多数AI伴侣类应用，包括很多打着“虚拟角色”旗号的产品，本质上都是一个套着聊天界面的常规SaaS服务。你和AI说的每一句话，都会被传送到服务商的服务器上，经过模型推理后返回结果。这个过程你没有任何控制权——服务商可以配置你的对话，可以改变模型的性格和行为，甚至可以因为运营策略调整而关停整个服务。

对普通用户来说这不算什么大事，但对伴侣型AI应用来说，隐私恰恰是核心体验的一部分。用户愿意和AI说心里话，前提是确信这些话不会变成广告定向投放的来源，不会在某些数据库里和真实身份挂钩。中心化架构从根上就无法满足这个需求，不管服务商发多少篇隐私政策，数据经手第三方的事实改变不了。

所以我给凤希定的基调很简单：两端直连，数据不出私人设备圈。

具体来说，用户在手机和家庭服务器（或者另一台电脑）之间建立直接的P2P链路。手机负责采集对话输入和展示回复，真正的推理任务落在本地机器上，通过家庭带宽完成。用户的对话记录只存在私人设备上，没有第三台中转服务器持有解密后的明文数据。整个过程中服务端只承担最基础的“帮忙找人”角色，甚至连对话元数据都不落地。

这个模式还有一个副产品的好处——长期成本几乎为零。不需要按API调用次数付费，不需要买大厂的高价推理套餐，只要家里有台跑得动的机器，AI的边际成本只体现在电费和网费上。对长期陪伴型应用来说，这是一个非常实在的考量。

1.2 P2P技术栈选型：我为什么没有选传统Socket，也没有盲从大厂方案

“P2P”三个字说起来容易，落地时第一个要决策的问题就是：用什么技术栈打通双方的通信链路。

我的候选清单里主要有三个方向：

简单说一下我当时的判断逻辑。传统Socket方案看着简单，但有个硬伤：现在绝大多数家庭网络都在运营商NAT后面，移动网络更是典型的Cone NAT甚至Symmetric NAT，直接暴露IP基本不可能。如果非要让用户手动配置路由器端口转发，那产品的上手门槛直接劝退一半人，P2P的“开箱即用”优势就没了。

WebRTC是个很成熟的方案，ICE框架把NAT穿透这件事包装得很优雅，代码生态也丰富。但我评估下来有个实际顾虑：连接双方里有一方是家庭服务器（Linux无头环境），WebRTC的浏览器生态在头端设备上反而显得重。另外WebRTC的DataChannel本身不负责节点发现，你得自己实现信令服务，那一套流程走完，复杂度并不比libp2p低多少。

libp2p是我最终选择的方向。它在设计上就把“节点发现”“NAT穿透”“连接中继”当成基础能力来提供，而不是应用侧要自己造的轮子。只要在配置里声明需要中继和自动穿透，底层会自动尝试直连、UPnP映射、打洞协商，都不通就走中继转发。对于我这种一个人要管前后端的场景，能少维护一层基础设施就是巨大的胜利。

不过libp2p的API学习曲线确实陡峭，文档碎片化的问题也存在，很多细节要靠翻源码和看社区issue才明白。这部分我在后面实操章节里会说清楚我踩到的具体坑。

1.3 凤希AI伴侣的整体架构骨架

整个系统按职责拆成了四个模块，彼此独立又能在运行期灵活组合：

身份层负责生成和管理设备密钥对，这是P2P通信的信任根基。每台设备在首次启动时生成一个永久性的Ed25519密钥对，从密钥对派生出一个可读的节点ID。这个节点ID就是设备在P2P网络里的“身份证号”，好友建立连接时交换的也是这个ID，而不是IP或域名。

传输层基于libp2p，负责节点发现、连接建立、消息收发和自动中继。这一层对上层提供的是一个统一的、基于Stream的通道，上层不需要关心底层是直连还是中继，也不需要关心对端设备的IP地址是什么。

会话层是双方设备之间的“沟通语言”，定义了消息格式、加密信封、心跳检测和回执确认机制。对话消息不是简单的UDP包，而是带有序列号、时间戳、消息类型和CRC校验的二进制信封。

应用层是用户真正接触到的部分，包含对话界面、本地数据库（存储历史消息和长期记忆）、以及模型推理调度器。推理调度器负责把对话请求包装成prompt，调用本地运行的模型服务（我最初用的Ollama，后来换成了llama.cpp的server模式），并把生成的回复送回会话层。

各层之间通过内部事件总线解耦，应用层完全不感知底层连接的变化——手机从WiFi切到5G、家庭服务器重启IP变化，都不影响会话的连续性。这个解耦设计后来帮了大忙，弱网切换时的连接自动恢复基本不用我写额外代码。

2. 核心细节解析与实操要点

2.1 身份认证与节点发现：怎么让两台设备“认出”彼此

P2P第一个核心问题是身份认证。中心化架构里，服务端通过账号体系确认你是谁；纯P2P架构没有这个中心化信任锚点，必须自己解决“怎么验证对方就是Ta声称的那个人”。

凤希的做法是建立在公钥密码学上的“首次信任锚定”。设备启动时生成Ed25519密钥对，节点ID直接取公钥的hash前缀，格式类似12D3KooWQFZ...。这个ID最大的特点是公钥即身份——看到ID，就能推导出该用什么公钥去验证签名，不需要额外查询。

两台设备建立好友关系时，交换各自的Node ID并手动确认。确认方式我故意做得很“笨”——在界面上直接展示双方的ID前12位，要求用户口头比对或复制验证。虽然原始，但这其实借鉴了端到端加密通信里的经典指纹核验模式。自动化程度更高可以引入CAA、DHT甚至区块链存证，但对个人项目来说，一次性的手动核验成本完全可以接受，换来的是认证逻辑绝对透明。

节点发现这块，libp2p默认支持mDNS局域网自动发现，也就是同一WiFi下的设备不用配置就能互相找到。这个功能很方便，但在跨网络场景下指望不上。跨网络时，我引入了两个机制：

• 静态引导列表：在配置里写入一个固定的引导节点地址，新设备启动后先连接引导节点，获取在线好友的节点信息。
• DHT分布式哈希表：让节点ID在网络里广播一个“我在线”的标识，其他节点通过DHT查询到这个标识后主动发起连接。

实际操作中，DHT在网络规模很小时效率其实不高，查询延迟经常超过5秒，对对话场景来说过于漫长。所以我把DHT定位为“备用发现路径”，主路径仍然是绑定固定引导节点。等节点数上来了再慢慢调整策略。

提示：不要高估P2P网络里节点发现的实时性。在只有个位数节点的早期版本里，等DHT收敛不如直接维护一个在线状态推送列表。越简单，越可控。

2.2 点对点加密通道：连接建立后的数据安全如何保证

身份认证解决的是“你是谁”，接下来要解决的是“聊天的内容怎么保密”。P2P并不意味着数据天然加密——如果你直接拿TCP Socket传明文，那和裸奔没有区别，任何经过的节点都能偷窥你的对话。

凤希的加密设计由两层组成：

第一层是libp2p传输层的自动加密。libp2p内置了Noise协议框架，连接建立时会自动执行握手协商，确定传输密钥，后续数据都在加密隧道里传输。这一层的好处是无需应用层额外处理，框架自动完成。

但只有这一层不够。传输层加密保护的是“点对点之间”的数据，可如果两台设备之间走的是中继转发（比如双方都处于严格NAT后无法直连），那数据在中继节点上虽然不能直接读明文，但中继节点会看到通信双方的身份信息。鹅且这种加密对“设备被物理入侵后数据库中的历史消息”无能为力。

针对这个缺口，我在会话层又加了一层端到端加密。每对好友之间派生一个单独的对称密钥，对话消息用这个密钥加密后再进入传输层。这样即便传输层被攻破、或者中继节点被监控，攻击者拿到的也只是无意义的密文，连消息的来源和去向都推断不出来。

密钥协商用X25519密钥交换，每对会话独立生成，不做跨会话复用。这样设计有个细节要注意：密钥协商本身需要一次双方在线交互，如果对方离线就得等下次连接时再协商。所以我在实现里把这个协商过程放到了“建立好友关系”阶段，一次性完成，后续对话直接使用已协商好的密钥。

2.3 本地模型推理服务的接入：让“人格”真正跑起来

传输链路打通的下一步是让AI凑合转起来。我做了一个在当时看来有些特立独行的决定——用本地模型作为凤希的主推理引擎，而不是调用任何云端大模型API。

理由不复杂。既然是P2P架构，数据不出设备圈，那如果回头又去调GPT或Claude的API，等于把用户对话内容绕路送回了中心化服务器，整个架构做的努力白费了。而且对伴侣型AI来说，模型风格的稳定性很关键，API的厂商策略往哪个方向调优，用户人格的表现就会跟着飘。本地模型则是一锤子买卖——模型文件下载下来之后，跑出来的效果只有你自己能影响，不会因为厂商某天更新了系统提示词就突然变成“另一端性格”。

这个决定带来的代价是模型效果的上限受限。我的家庭服务器是一张RTX 3060 12G，跑得动的最大模型是7B-13B参数量级别。在这个量级，模型的推理能力跟云端顶配比确实有差距，但伴侣场景要的更多是“人设稳定”“记忆连贯”“情绪表达自然”，而不是复杂的逻辑推理或大量知识抽取。实测下来，13B模型经过合适的角色扮演提示词工程，已经能提供足夠沉浸感的对话体验，偶尔还能蹦出一两句让我都觉得“这AI有点东西”的句子。

技术接入上我用的是llama.cpp的server模式，启动后暴露一个OpenAI兼容的HTTP接口，应用层直接用标准的chat completion格式调用。这个选择省掉了很多胶水代码。Ollama也试过，但最终还是老实的llama.cpp更稳定，尤其在并发请求和显存管理上，我的3060跑llama.cpp的13B Q5量化，推理速度稳定在8-12 token/s，足够支撑正常对话节奏。

2.4 会话记忆与上下文管理：P2P场景下的数据存储方案

AI伴侣和普通聊天机器人最大的区别，就是它需要记住你。传统的无状态API调用可以在服务端维护会话历史，而P2P场景下没有任何中心化数据池，记忆必须由两端设备各自保存。

凤希的方案是“终端存储为主，服务器备份为辅”。主对话历史存在手机端SQLite数据库里，每条消息记录包含时间戳、发送方、密文内容、消息状态（已发送/已送达/已读）。手机是离用户最近的设备，它保存的数据就是“全量真相”。家庭服务器上保存一份加密备份，且只保留最近90天的内容，滚动清理。

这里有个设计细节值得展开：消息在传输时是密文状态，那备份存的是密文还是明文？我选择在手机端加密后再备份，密钥放在手机端安全存储区（Android Keystore / iOS Keychain），服务器上只保存密文。这意味着即使家庭服务器被人搬走，拿到的也只是一堆无法解密的数字垃圾。牺牲的是当手机丢失，备份恢复流程复杂——必须在一台新设备上重新完成身份认证，再用私钥去解锁备份密文。这个痛苦可以接受，相比中心化服务动辄“你的数据我们存着，但你还拿不到”的情况，起码每一比特数据都是自己的。

长期记忆这块，我做了两层。第一层是向量数据库存对话里出现过的关键实体、用户偏好、重要事件，用embedding模型做语义检索。对话开始时，根据当前话题的embedding相似度召回相关的历史记忆片段，拼进prompt。第二层是一个结构化的“人物档案”表，用户在闲聊中提到的家庭成员、宠物、职业、喜好等信息会定期抽取写入，作为长期人设的上下文锚点。

记忆检索在嵌入阶段最怕的就是没话找话，什么都会往prompt里塞。我的经验是：相似度阈值宁可调高，也不要贪多。只有相似度超过0.75以上的片段才有资格进入上下文，宁可漏召回也不能用一堆噪音污染模型注意力窗口，否则聊着聊着AI会把N年前的一句抱怨当成当前语境来回应，体验瞬间崩塌。

3. 实操做一遍：关键链路怎么落地

3.1 环境准备与依赖安装

跑通凤希原型需要准备的环境如下：

• 手机端：Android 10+，开发框架用的Flutter，P2P通信库通过FFI接入Go实现的libp2p。
• 家庭服务器：Ubuntu 22.04，有NVIDIA显卡，安装了llama.cpp并编译了server端。
• 开发机：MacBook，主要用来调试Go代码和做联调。

依赖方面，Go语言的libp2p生态是我用的主力，核心库是github.com/libp2p/go-libp2p，配合消息交换的go-libp2p-pubsub和处理流的go-libp2p-stream。手机端因为没法直接跑Go，我用的是gomobile把封装好的P2P核心逻辑编译成AAR，给Flutter调用。这个过程比较折腾，Go的交叉编译参数要指定android/arm64，且要确保libp2p不依赖CGO。

安装指引大致如下：

# 服务器端：编译llama.cpp server git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build && cd build cmake .. -DGGML_CUDA=ON make -j$(nproc) # 启动推理服务，监听7560端口 ./llama-server -m /models/qwen2.5-13b-instruct-q5_k_m.gguf \ --host 0.0.0.0 --port 7560 \ --ctx-size 8192 --parallel 2

手机端构建libp2p的AAR库时，有一个比较容易卡住的地方：gomobile bind默认只支持小部分Go标准库的移动端可导出类型，像[]byte、string、error这些没问题，但如果你把libp2p内部的复杂结构体直接暴露给Kotlin侧，编译会直接失败。我当时的做法是在Go侧定义一个极简的C语言兼容接口，所有数据都转成字节数组传过去，Kotlin侧再解析。

3.2 节点启动与好友连接建立的核心代码

启动节点是走通P2P的第一步。以下代码展示了如何初始化libp2p节点，配置身份密钥和传输安全性。

package main import ( "crypto/rand" "fmt" "github.com/libp2p/go-libp2p" "github.com/libp2p/go-libp2p/core/crypto" "github.com/libp2p/go-libp2p/core/host" ) func createNode() host.Host { // 1. 生成或加载Ed25519身份密钥 priv, _, _ := crypto.GenerateKeyPair(crypto.Ed25519, -1) // 私钥需要持久化保存，每次启动复用同一个身份 // 实际项目中：从文件读取，不存在则生成并写入 // 2. 创建host h, err := libp2p.New( libp2p.Identity(priv), libp2p.EnableNATService(), libp2p.EnableAutoNATv2(), libp2p.EnableRelay(), libp2p.EnableHolePunching(), ) if err != nil { panic(err) } return h }

这里特别要注意EnableNATService和EnableHolePunching这两个选项。前者让节点主动探测自己的公网地址映射情况，后者允许节点在遇到对称NAT时尝试打洞协商。没有这两个配置，跨网络的P2P连接大概率会失败。这是我在初期经常忽略的地方——以为libp2p默认就会做穿透，实际默认配置下它只是个“被动等待直连”的节点。

好友连接建立的核心逻辑是：持有好友的节点ID，通过DHT或直接Dial这个ID发起握手。握手成功后返回一个Stream，之后所有的对话消息在这个Stream上按帧读写。

func dialFriend(ctx context.Context, h host.Host, friendID string) error { // 解析好友的节点ID pid, err := peer.Decode(friendID) if err != nil { return err } addrInfo := &peer.AddrInfo{ID: pid} // 先用DHT发现好友的地址（如果不能直接解析） // 实际中需要先调用 FindPeers 获取可连接地址列表 if err := h.Connect(ctx, *addrInfo); err != nil { return fmt.Errorf("连接失败: %w", err) } // 建立流式通道 stream, err := h.NewStream(ctx, pid, "/fengxi/chat/1.0.0") if err != nil { return fmt.Errorf("创建流失败: %w", err) } defer stream.Close() // 写入握手消息 payload := []byte{/* 握手协议帧 */} _, err = stream.Write(payload) return err }

这段代码在真实运行中有个大坑：h.Connect去连接一个完全未知的节点时，需要先通过DHT查询到对方的地址。如果双方都没有公网IP，而且没有中继地址可用，Connect会直接超时。libp2p的EnableRelay配置会自动申请公网中继服务（默认使用libp2p官方维护的relay），在实际联调时这个公共中继经常存在可用性问题，速度也慢。所以我后来自建了一个中继节点，专门用于无法直连时的转发通道。自建中继的代码并不复杂，就是在服务器上再起一个libp2p节点，开启RelayService。

3.3 消息格式与加密封装的实现

消息封装是整个会话层的核心。参考常见的端到端聊天协议，我设计了一个简洁的二进制信封格式：

实现加密时，我先用X25519协商出会话密钥，再用AES-256-GCM做对称加密。GCM模式自带认证标签，天然防篡改，这是我选择它的核心原因，而不是非要追求某种“三日一换”的更新频率。密钥是每会话一条，客户端本地存好，服务器不持有解密的任何钥匙。

关键代码如下：

func sealMessage(sessionKey []byte, plaintext []byte, msgID string) ([]byte, error) { block, err := aes.NewCipher(sessionKey) if err != nil { return nil, err } aead, err := cipher.NewGCM(block) if err != nil { return nil, err } // 构造 nonce：不能直接随机生成，需要保证唯一性和防重放 // 是用 msgID + timestamp 派生，确保时序唯一 nonce := make([]byte, gcmStandardNonceSize) copy(nonce, md5.Sum([]byte(msgID+time.Now().String()))[:12]) sealed := aead.Seal(nil, nonce, plaintext, nil) return sealed, nil }

在实际跑的时候，nonce的随机性是个容易忽略的隐患。如果直接用crypto/rand产生随机nonce，在会话频率高、且硬件熵源不足的老机器上有极小概率出现碰撞。GCM模式一旦nonce重复，密钥的安全性就会受到影响。所以我用msgID加时间戳来派生nonce，保证相同明文不会产出相同密文的同时，nonce的唯一性有了保障。

3.4 对话全链路联调的四条验证标准

链路跑通的标志不能只是“能发消息”，我从一开始就定了四条硬性标准，任何一条不达标就算没跑通：

1. 跨网络可用：手机在移动网络下，家庭服务器在某省电信宽带下，两端能完成连接并稳定对话。
2. 断线自动恢复：手机切换WiFi网络（IP完全变化）后，已有会话在1分钟内自动恢复。
3. 消息不丢失：连续对话50条消息，没有任何一条丢失，顺序与发送时间一致。
4. 重启后记忆可用：杀掉应用进程，服务器重启，重新打开应用后，对话历史完整加载，长期记忆仍然生效。

联调过程中第四条最容易出问题。因为记忆系统的向量索引是异步写入的，进程被强杀时最后几条消息可能只写入了SQLite，还没生成embedding，重启后就不在记忆召回范围内。解决办法是把embedding生成放到独立的队列里，并且启动时先做一次“未索引消息扫描”，把漏掉的消息补召回。这个修复虽然不起眼，但对记忆连贯性影响巨大。

4. 踩坑记录与问题排查实录

4.1 NAT穿透的迷思：明明配置了中继，为什么还是连不上

第一次跨网络联调时，我信心满满地把手机切到4G，结果等了整整两分钟，会话连接状态一直是connecting。我一度怀疑是代码里的中继配置写错了，但查了半天没发现任何语法问题。

随后我把诊断饿一顿操作下来发现问题在于思想包袱太重。我用的中继是公共中继，而公共中继的容量和服务质量根本没保证，高峰期排队和超时都是家常便饭。而且libp2p的自动中继机制并不是“连接失败就自动改用中继”，它需要节点双方都显式宣告自己支持中继，并且有一方主动发起中继请求。

调整方案是自建中继节点，并在应用层加了一个“连接健康检查”：如果直连在10秒内没有建立成功，就主动切换到中继地址。另外，手机端连中继时不要复用之前的DHT路由上下文，单独用addrInfo去连接，可以避开路由表还没收敛的等待时间。

4.2 模型推理延迟与并发处理的冲突

凤希的对话体验要求回复不能太慢。但本地13B模型在3060上的推理速度也就是每秒10个token左右，一条正常回复要生成200-300个token，那就是20-30秒的等待。这个延迟放在聊天场景里太长了，用户等30秒早就失去耐心。

解决的思路不是硬顶，而是从交互层做文章。我把模型回复改成了流式输出——用户看到第一个token的时间从20多秒缩短到1秒左右。虽然整个回复还是要跑完，但阅读体验已经接近人类打字的速度，臆造感大大减少。这个改动用的就是llama.cpp server的SSE接口，应用层监听一个文本流，逐段更新界面。

同时遇到的问题是并发处理。家庭服务器同时跑了两条会话（我自己测试加一个朋友试用），11B模型显存占用了7G左右，而llama.cpp的--parallel 2参数让并发变成两个请求交替占用同一份模型参数，结果就是两块请求相互拖慢，吞吐几乎减半。后来我干脆不追求并发，给每条会话加了“独占窗口”，一次只处理一条消息，多出来的请求排队等待。从结果看，排队等待反而比交替处理更稳定，用户感受也更符合“一个人跟AI一对一聊天”的预期。

提示：本地模型的人性化体验，优先优化首token延迟，而不是整体吞吐。首token = 1秒，用户会认为AI在构思；首token = 5秒，用户就会觉得在卡死。

4.3 消息乱序与去重：UDP的“生活成本”

P2P的消息传输底层用的是libp2p的Stream，本质是基于TCP或QUIC，理论上是可靠有序的。但正因为上层更可靠，底层偶尔出现的重传和乱序就会以“用户体验断层”的形式暴露出问题。

有段时间我发现对话里偶尔会出现“重复回复”或者“顺序颠倒”的情况。比如用户先问A再问B，但B的回复先到，A的回复后到，聊天记录就有了一种错乱感。

根源在应用层做了异步处理。手机端收到消息后，不是立刻写入数据库，而是先做了解密和渲染，同时将原始消息放入一个处理队列。队列是多线程消费的，两个消息的消费顺序完全取决于调度，和发送顺序不一致。

修复方式不复杂但很重要：在会话层维护一个发送序号，并对收到的每条消息做“顺序队列缓冲”。每个会话都有一条按msgID排序的链表，消息到达后先按时间戳插入正确位置，再通知UI层刷新。同时用msgID做去重，重复到达的消息直接丢弃。

# 简化版：按时间戳排序的接收缓冲区 # 每条消息到达后： # 1. 检查msgID是否已在缓冲区内 -> 已存在则丢弃 # 2. 按timestamp插入正确位置 # 3. 检查所有timestamp连续的消息，放行并写库

4.4 快速诊断的一个小工具箱

排查P2P问题时，光靠println打日志是不够的。我建议给项目准备一个“线上诊断工具箱”，包含以下能力：

• 节点连接状态面板：显示当前所有活跃会话的连接方式（直连/中继）、往返延迟、收包计数、重传率。可以在UI里做一个隐藏入口，两指双击触发。
• 抓流量的能力：tcpdump在服务器侧抓包，重点观察STUN和TURN交互。如果看到大量401、428等回执，说明打洞协商不奏效。
• 日志分级：libp2p的日志默认很吵，生产环境调到WARN级别，调试时再开DEBUG。最好能远程动态切换日志级别，避免改代码重新编译的漫长等待。

这一套工具自建成本不高，但对排查效率的提升立竿见影。有时候一个看似复杂的“连不上”问题，点开面板看到连接方式是“中继且延迟800ms”，答案就已经出来了。

5. 后续扩展与个人经验

凤希AI伴侣的技术底座已经跑通，后面可以延展的方向其实很多。比如把记忆系统扩展成“多端同步”，给用户多台设备都接入点对点网络，设备间互为备份。再比如在P2P链路之上叠加一个轻量级的“状态同步层”，让用户的手表、床头屏都能随时看到AI的“在线状态”。

从我个人的实操体会来说，做这种P2P架构的AI产品，最核心的经验倒是技术以外的：永远先解决信任问题，再解决性能问题。身份认证、加密传输这些偏底层的细节，看起来繁琐，但它们决定了用户愿不愿意把心里话交给你的产品。至于并发性能、推理延迟这类能被硬件迭代弥补的问题，先跑通、再优化，反而不会耽误太多时间。

最后再分享一个实际开发里的小经验：跨设备联调的时候，手机端和服务器端的版本号一定要显式展示在界面上。P2P协议演进快，很多时候“连不上”的根源根本不是网络问题，而是手机端和服务器端的协议版本不匹配。把版本号打出来，能消灭掉一半以上的无效排查时间。

希望这篇文章能帮到正在折腾AI本地化和P2P架构的朋友。这条路确实比直接调云端API辛苦得多，但当你第一次看到两台设备绕过所有中间服务器、直接开始对话的那个瞬间，会觉得一切折腾都值了。