1. 为什么要在路由器上跑 AI 提示流
把 AI 引擎塞进一台华硕路由器，听起来像是极客的恶趣味，但真做过一轮之后你会发现，这个方向解决的是一个非常具体的痛点：家庭和小型办公网络里，越来越多的智能请求需要"就近处理"，而不是全部甩到云端。
我最初动这个念头，是因为家里那台常年开着的路由器其实一直处于"算力闲置"状态。它每天做的事情无非是拨号、转发、跑个轻量级服务，CPU 占用长期在个位数徘徊。而与此同时，我手头有一堆零散的 AI 调用需求：定时把某些文本做摘要、把设备日志做归类、把语音转写后的内容做结构化整理。这些任务单个都不重，但全都依赖外部服务，一旦网络抖动或者服务限流，整条链路就断了。
于是就有了这个项目：用 Merlin 插件做载体，用 Go 写一个轻量边缘网关，在路由器本地完成 AI 提示流的编排与调度。所谓"提示流编排器"，说白了就是把"输入 → 预处理 → 调用模型 → 后处理 → 输出"这一串动作，做成可配置、可组合、可复用的流水线，而不是每次都在代码里硬编码。
这个项目适合谁？如果你满足下面任意一条，那这篇内容对你会很有用：
- 手里有华硕路由器，刷了 Merlin 固件，想榨干它的剩余价值；
- 写过一些 Go，想找一个真实的小项目练手，而不是停留在语法层面；
- 对边缘计算感兴趣，但不想一上来就搞 FPGA、搞通信测试终端那种重资产方案；
- 需要把 AI 能力下沉到本地，减少对外部服务的强依赖。
需要提前说明的是，路由器上的资源非常有限。我用的这台是 ARM 架构、内存 512MB 级别的机型，能跑起来的东西必须足够轻。所以整个方案的核心思路是：Go 编译成静态二进制，网关只做编排和转发，真正的模型推理要么走本地小模型，要么走可配置的远端接口。这个边界一定要先划清楚，否则后面会不断踩坑。
2. Merlin 插件机制与运行环境摸底
2.1 Merlin 固件的插件加载逻辑
Merlin 固件本质上是华硕官方固件的一个增强分支，它保留了官方的底层框架，同时开放了一些扩展点。插件通常放在/jffs/分区下，这个分区是可读写的，掉电后内容保留，是放自定义程序的最佳位置。
插件要能被系统识别，一般需要满足几个条件：有一个可执行的入口脚本、有对应的配置声明、能被services-start之类的启动钩子调用。我实测下来，最省事的做法是把自己的二进制和启动脚本都丢进/jffs/scripts/和/jffs/下的自定义目录，然后在services-start里加一行调用。
这里有个容易忽略的点：Merlin 的启动脚本执行时机比较早，此时网络可能还没完全就绪。如果你的网关启动时要绑定端口或者做 DNS 解析，直接跑会失败。我的处理方式是在启动脚本里加一个等待循环，检测到默认路由可用之后再拉起网关进程。
#!/bin/sh # /jffs/scripts/services-start 片段 while ! ip route | grep -q default; do sleep 2 done /jffs/ai-gateway/start.sh &2.2 ARM 环境下的 Go 交叉编译要点
路由器是 ARM 架构，而我的开发机是 x86 的，所以必须交叉编译。Go 在这方面非常友好，设置好GOOS和GOARCH就行：
GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-s -w" -o ai-gateway .几个关键参数解释一下。GOARM=7对应 ARMv7 指令集，绝大多数中高端华硕路由器都是这个。-ldflags="-s -w"是去掉符号表和调试信息，能把二进制体积压下来不少，我实测从 12MB 压到了 8MB 左右，对路由器那点存储空间来说很关键。
注意：如果你的路由器是较新的型号，可能是 ARM64，那就把
GOARCH换成arm64，并且不需要GOARM。编译前最好先uname -m确认一下目标架构，别想当然。
还有一个坑：Go 默认会动态链接一些库，但路由器上的 libc 版本可能和编译机不一致。解决办法是加CGO_ENABLED=0，强制静态编译，这样二进制不依赖目标机的任何动态库，扔过去就能跑。
CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-s -w" -o ai-gateway .2.3 存储与内存的现实约束
路由器上能用的存储通常只有几十 MB 的 JFFS 空间，内存也就几百 MB。这意味着：
- 二进制不能太大，8MB 已经是比较舒服的上限；
- 不能把模型文件放本地，除非是极小的量化模型；
- 运行时内存占用要控制，Go 的 GC 虽然好用，但默认参数在低内存环境下可能过于激进。
我做过一次内存压测，网关在空闲时占用约 15MB，处理请求峰值到过 40MB。这个数字在 512MB 内存的机器上是安全的，但如果你的路由器只有 256MB，就要更谨慎，可能需要限制并发数。
3. 提示流编排器的核心设计
3.1 把"提示流"抽象成可组合的节点
编排器的核心思想，是把一次 AI 处理拆成若干个节点（Node），每个节点做一件小事，节点之间用数据流连接。这样设计的好处是，新增一种处理逻辑只需要加一个节点，而不用改动整条链路。
我定义的节点类型主要有这几类：
| 节点类型 | 作用 | 典型场景 |
|---|---|---|
| Input | 接收原始输入 | HTTP 请求体、文件内容 |
| Transform | 对数据做转换 | 模板填充、字段提取 |
| Model | 调用模型 | 本地推理或远端接口 |
| Condition | 条件分支 | 根据内容长度走不同路径 |
| Output | 输出结果 | 返回响应、写入日志 |
每个节点实现一个统一的接口，输入是上一步的输出，输出传给下一步。这种设计参考了管道（Pipeline）的思路，但在 AI 场景下多了"模型调用"这个异步环节，所以接口设计上要支持超时和重试。
type Node interface { Name() string Process(ctx context.Context, input []byte) ([]byte, error) }接口保持极简，只有Process一个方法。上下文用来传递超时和取消信号，这在边缘环境下特别重要——网络不稳定时，一个卡住的请求可能拖垮整个网关。
3.2 用配置文件描述一条完整的流
节点定义好之后，怎么把它们串起来？我的选择是用 YAML 配置文件描述，而不是写死在代码里。这样改流程不用重新编译，直接改配置重启即可。
flow: name: log-summarize nodes: - name: input type: input - name: clean type: transform params: template: "请对以下日志做归类：{{.content}}" - name: infer type: model params: endpoint: "http://127.0.0.1:8080/v1/chat" timeout: 30s retry: 2 - name: output type: output这个配置描述了一条"日志归类"的流：先接收输入，然后用模板把内容包进提示词，再调用模型，最后输出。整个过程对调用方来说就是一个 HTTP 接口，内部怎么编排是透明的。
提示：模板里的
{{.content}}是 Go 的 text/template 语法，用起来很顺手。但要注意对输入做转义，避免用户输入的内容破坏模板结构。
3.3 为什么选 Go 而不是 Python
这个问题我被问过很多次。Python 写 AI 相关的东西确实生态好，但在路由器这个环境下，Go 有几个压倒性的优势：
第一是部署简单。Go 编译出来就是一个静态二进制，扔过去就能跑，不需要装解释器、不需要配虚拟环境。路由器上装 Python 环境本身就是个麻烦事，各种依赖还可能编译不过。
第二是资源占用低。Go 的运行时开销比 Python 小得多，启动速度快，内存占用可控。在 512MB 内存的机器上，这个差距是决定性的。
第三是并发模型适合网关场景。Go 的 goroutine 处理大量并发请求非常自然，而网关的核心工作就是转发和编排，天然是高并发的。
当然，Go 也有短板，比如做复杂的文本处理不如 Python 顺手。但在这个项目里，复杂的处理都交给模型了，网关本身只做轻量的编排，所以这个短板影响不大。
4. 边缘网关的请求处理链路
4.1 从 HTTP 入口到节点调度
网关对外暴露的是一个标准的 HTTP 接口，调用方不需要知道内部有多少个节点。请求进来之后，处理链路大致是这样的：
- 解析请求，提取流名称和输入数据；
- 根据流名称加载对应的配置；
- 按顺序执行节点，把上一步的输出传给下一步；
- 收集最终结果，返回给调用方。
这里有个设计决策值得说一下：我选择了同步执行而不是异步队列。原因是路由器上的任务大多是轻量的、实时的，引入队列会增加复杂度和内存占用，收益不明显。如果某个流确实很慢，那应该在配置里设置合理的超时，而不是靠队列来缓冲。
func (e *Engine) Run(ctx context.Context, flowName string, input []byte) ([]byte, error) { flow, ok := e.flows[flowName] if !ok { return nil, fmt.Errorf("flow not found: %s", flowName) } data := input for _, node := range flow.Nodes { var err error data, err = node.Process(ctx, data) if err != nil { return nil, fmt.Errorf("node %s failed: %w", node.Name(), err) } } return data, nil }这段代码是整个引擎的核心，逻辑很直白：按顺序跑节点，任何一步出错就中断并返回错误。错误信息里带上节点名称，方便排查问题。
4.2 超时、重试与降级策略
边缘环境最大的特点就是不稳定。网络可能断，远端服务可能限流，本地资源可能被抢占。所以网关必须有一套完整的容错机制。
超时是最基本的。每个模型节点都应该有独立的超时设置，我一般设 30 秒，因为大部分文本处理任务在这个时间内都能完成。超时之后，根据配置决定是否重试。
重试策略我用的是指数退避：第一次失败等 1 秒，第二次等 2 秒，第三次等 4 秒。这样既能应对偶发的网络抖动，又不会在服务真的挂掉时疯狂重试把资源耗光。
func (n *ModelNode) Process(ctx context.Context, input []byte) ([]byte, error) { var lastErr error for i := 0; i <= n.retry; i++ { if i > 0 { time.Sleep(time.Duration(1<<uint(i-1)) * time.Second) } result, err := n.call(ctx, input) if err == nil { return result, nil } lastErr = err } return nil, lastErr }降级策略则是最后一道防线。如果模型调用彻底失败，可以配置一个兜底节点，返回一个默认结果或者原始输入，至少保证调用方不会拿到一个硬错误。
4.3 本地模型与远端接口的混合调度
这个项目里，模型调用有两种模式：本地和远端。本地模式适合轻量任务，比如简单的文本分类、关键词提取；远端模式适合复杂任务，比如长文本摘要、多轮对话。
混合调度的关键在于路由规则。我在配置里加了一个route字段，可以根据输入的特征决定走哪条路：
- name: infer type: model params: routes: - when: "len(content) < 200" endpoint: "http://127.0.0.1:8080/v1/chat" - when: "len(content) >= 200" endpoint: "https://api.example.com/v1/chat" timeout: 60s短文本走本地，长文本走远端，这样既节省了本地算力，又保证了复杂任务的处理质量。when条件用的是简单的表达式求值，我实现了一个极简的解析器，支持长度比较和关键词匹配，够用就行。
5. 实测中的性能与稳定性问题
5.1 内存泄漏的排查过程
项目跑起来之后，我遇到过一个很典型的问题：网关运行几天后内存占用越来越高，最后被系统 OOM 杀掉。这个问题在开发机上完全复现不出来，因为开发机内存大，跑几天也看不出异常。
排查过程是这样的。首先确认不是配置问题，因为重启后内存会回落。然后怀疑是 goroutine 泄漏，用pprof抓了一份 goroutine 快照，发现数量确实在缓慢增长。顺着调用栈找下去，问题出在模型节点的 HTTP 客户端上——每次调用都新建了一个http.Client，而旧的客户端没有被回收。
修复方法很简单，把http.Client做成全局单例，复用连接池：
var httpClient = &http.Client{ Timeout: 60 * time.Second, Transport: &http.Transport{ MaxIdleConns: 10, MaxIdleConnsPerHost: 5, IdleConnTimeout: 90 * time.Second, }, }改完之后，内存占用稳定在 20MB 左右，连续跑一周没有明显增长。这个坑的教训是：在资源受限的环境下，任何"每次新建"的操作都要警惕，连接、缓冲区、临时对象，能复用就复用。
5.2 高并发下的请求堆积
第二个问题是并发。我做了个压测，同时发 50 个请求，结果发现响应时间急剧上升，部分请求直接超时。
原因有两个。一是模型调用本身是串行的，本地模型一次只能处理一个请求；二是网关没有做并发限制，请求全堆在内存里等着。
解决办法是引入信号量机制，限制同时执行的流数量：
type Engine struct { sem chan struct{} } func (e *Engine) Run(ctx context.Context, flowName string, input []byte) ([]byte, error) { select { case e.sem <- struct{}{}: defer func() { <-e.sem }() case <-ctx.Done(): return nil, ctx.Err() } // ... 执行流程 }信号量的容量根据路由器性能设置，我设的是 4，也就是最多同时跑 4 条流。超出的请求会等待，等待时间超过上下文超时就直接返回错误。这样虽然牺牲了一部分吞吐，但保证了系统的稳定性，不会因为突发流量而崩溃。
5.3 日志与可观测性的取舍
路由器上的存储空间有限，日志不能无限写。我的做法是只记录关键事件：请求开始、请求结束、错误发生。每条日志包含时间戳、流名称、耗时、状态，格式尽量紧凑。
log.Printf("flow=%s status=%s cost=%dms", flowName, status, cost.Milliseconds())不记录完整的请求和响应内容，因为那会迅速把存储写满。如果确实需要调试，可以临时开启详细日志，排查完再关掉。
注意：日志文件要配置轮转，否则再小的日志也会把 JFFS 写满。我用的是一个简单的按大小轮转策略，超过 1MB 就切分，保留最近 3 个文件。
6. 从能跑到好用：几个关键优化
6.1 启动速度的优化
网关的启动速度直接影响路由器的可用性。最初的版本启动要 5 秒以上，主要时间花在加载配置和初始化模型客户端上。
优化思路是延迟初始化：配置在启动时加载，但模型客户端等到第一次真正调用时才创建。这样启动时间压缩到了 1 秒以内，路由器重启后网络恢复得更快。
type ModelNode struct { clientOnce sync.Once client *http.Client } func (n *ModelNode) getClient() *http.Client { n.clientOnce.Do(func() { n.client = &http.Client{ /* ... */ } }) return n.client }sync.Once保证了客户端只创建一次，同时又是线程安全的，非常适合这种场景。
6.2 配置热更新的实现
每次改配置都要重启网关，体验很差。所以我加了一个简单的热更新机制：监听配置文件的变化，检测到修改后重新加载。
实现上用的是文件修改时间轮询，每 10 秒检查一次。虽然不够优雅，但在路由器这种环境下足够可靠，而且实现简单，不引入额外的依赖。
func (e *Engine) watchConfig(path string) { var lastMod time.Time for { info, err := os.Stat(path) if err == nil && info.ModTime().After(lastMod) { lastMod = info.ModTime() e.reload(path) } time.Sleep(10 * time.Second) } }重载的时候要注意加锁，避免正在执行的请求读到半成品配置。我用的是读写锁，读操作（执行流）加读锁，重载操作加写锁。
6.3 二进制体积的进一步压缩
前面提到用-ldflags="-s -w"压缩体积，但 8MB 对某些路由器来说还是偏大。进一步压缩可以用 UPX，能把二进制压到 3MB 左右。
不过 UPX 有个代价：启动时需要解压，会稍微慢一点。在路由器上这个差异大概是几百毫秒，可以接受。如果你的存储特别紧张，值得一试。
upx --best --lzma ai-gateway提示：UPX 压缩后的二进制在某些环境下可能被杀毒软件误报，路由器上一般没这个问题，但心里要有数。
7. 这套方案还能怎么扩展
跑通基础版本之后，我陆续加了一些扩展，这里挑几个有代表性的说说。
第一个是 WASM 插件支持。Go 对 WASM 的支持不错，可以把一些自定义的处理逻辑编译成 WASM 模块，在网关里动态加载。这样扩展功能不需要重新编译整个网关，只需要替换 WASM 文件。这个方向我还在摸索，目前跑通了一个简单的文本替换插件。
第二个是多路由器协同。如果家里有多台路由器，可以让它们各自跑一个网关，然后通过一个轻量的协调层做任务分发。这个思路和边缘计算的分布式架构是一致的，只是规模小很多。
第三个是和 NAS 的联动。我手头有一台飞牛 NAS，上面跑着一些存储服务。网关可以把处理结果直接写到 NAS 的共享目录，形成一个完整的"采集 → 处理 → 存储"链路。这个组合在实际使用中很顺手，尤其是做日志归档和内容整理的时候。
需要提醒的是，扩展要克制。路由器资源有限，每加一个功能都要评估它对内存和 CPU 的影响。我踩过的坑是加了一个看似轻量的缓存层，结果因为缓存策略没设计好，内存占用翻了一倍。后来把缓存改成固定大小、LRU 淘汰，才把问题解决。
8. 我在实际部署中总结的几条经验
第一，先在开发机上把逻辑跑通，再往路由器上搬。路由器上调试很不方便，没有完整的调试工具，日志也有限。把能在本地验证的部分都验证完，能省下大量时间。
第二，二进制一定要静态编译。动态链接在路由器上是个大坑，libc 版本不匹配的问题会让你怀疑人生。CGO_ENABLED=0是必须的。
第三，并发限制宁小勿大。路由器不是服务器，别指望它能扛高并发。我一开始设的信号量容量是 10，结果系统频繁卡顿，降到 4 之后就稳定了。
第四，日志要克制。JFFS 空间宝贵，日志写满了会导致整个系统出问题。关键事件记录，详细内容按需开启，用完就关。
第五，配置和代码分离。把流程定义放在配置文件里，改流程不用重新编译。这个习惯在边缘设备上尤其重要，因为编译和部署的成本比服务器高得多。
这套方案我从最初的想法到稳定运行，前后折腾了大概两周时间，中间踩的坑基本都写在上面了。如果你也在琢磨怎么把 AI 能力下沉到边缘设备，希望这些经验能帮你少走点弯路。路由器这个平台虽然资源紧张，但正因为限制多，反而逼着你去思考什么才是真正必要的，这个过程本身就很有价值。
