1. 为什么要在路由器上跑 AI 提示流把 AI 引擎塞进一台华硕路由器听起来像是极客的恶趣味但真做过一轮之后你会发现这个方向解决的是一个非常具体的问题家庭和小型办公网络里越来越多的智能请求需要就近处理而不是全部甩到云端。我最初动这个念头是因为家里那台常年开着的路由器其实算力大量闲置。它 7×24 小时在线、功耗只有几瓦、网络位置又处在所有流量的必经之路上。如果能把一些轻量的 AI 提示编排逻辑直接放在这里很多场景就不用再绕一圈公网了。比如局域网内的设备想做文本摘要、格式转换、简单的意图分类完全可以在本地完成编排只把真正需要大模型的部分转发出去。这个项目的核心目标是做一个AI 提示流编排器它能把用户输入按预设的流程拆解成多个步骤每一步可以调用不同的处理单元本地规则、轻量模型、或者远端大模型 API最后把结果拼装返回。整个编排器跑在华硕路由器上通过 Merlin 插件的形式加载同时对外暴露一个轻量边缘网关接口让局域网设备用标准 HTTP 请求就能调用。适合谁来参考这篇内容三类人。第一类是玩华硕路由器、刷过 Merlin 固件、想找点新玩法的折腾党第二类是做边缘计算、想了解在资源受限设备上跑 AI 编排的开发者第三类是对 Go 语言实战感兴趣想看看一个真实的小型服务怎么从零搭起来的人。哪怕你只是好奇“路由器到底能不能干这个”跟着走一遍也会有收获。需要先说明一个前提路由器不是服务器它的 CPU 算力、内存、存储都非常有限。所以这里的“AI 引擎”不是指在路由器上跑一个几十亿参数的大模型那不现实。我们做的是编排层——把请求路由到合适的处理单元本地能做的本地做本地做不了的转发出去。这个定位想清楚了后面所有技术选型就顺了。2. 整体架构与方案选型拆解2.1 三层结构插件层、编排层、网关层整个系统我拆成了三层这样职责清晰出问题也好定位。最上面是Merlin 插件层。华硕 Merlin 固件支持通过插件机制扩展功能插件本质上是一组脚本加二进制程序挂在固件的服务管理框架下。这一层负责随路由器启动而启动、随路由器关闭而关闭做好进程守护和日志落盘。它不关心业务逻辑只关心“我的编排器进程活着没有”。中间是编排层也就是核心的提示流引擎。它读取一份流程定义我用的是一份 JSON 配置按步骤执行。每个步骤有类型local_rule表示本地规则处理local_model表示调用本地轻量模型remote_api表示转发到远端大模型。步骤之间可以传递上下文前一步的输出可以作为后一步的输入变量。最下面是边缘网关层。它对外提供一个 HTTP 服务监听局域网某个端口接收请求、做鉴权、限流然后交给编排层处理最后把结果返回。这一层是局域网设备真正打交道的入口。三层之间通过内部函数调用串联没有引入消息队列之类的重组件——在路由器这种资源环境下多一个组件就多一份内存和稳定性风险。2.2 为什么选 Go 而不是 Python 或 Node这是被问得最多的一个问题。在路由器上跑服务语言选型直接决定成败。Python 的问题在于运行时太重。一个带常用库的 Python 环境轻松吃掉几十兆内存路由器那点 RAM 经不起这么造而且启动慢固件重启后要等好几秒服务才可用。Node 稍微好点但事件循环在单核低主频的 MIPS/ARM 路由器上表现不稳定内存占用也不小。Go 的优势在这个场景下非常突出。编译出来是单个静态二进制没有运行时依赖扔到路由器上就能跑。内存占用可以压到几兆级别启动是毫秒级的。goroutine 处理并发请求很轻标准库自带 HTTP 服务器不用引第三方框架。交叉编译也方便在开发机上一条命令就能编出路由器架构的可执行文件。我实测过同样一个简单的 HTTP 编排服务Go 版本常驻内存在 6 到 8 兆Python 版本要 40 兆往上。这个差距在路由器上就是“能跑”和“跑不动”的区别。2.3 边缘网关的定位与边界这里要特别说清楚边缘网关的边界否则容易做成一个四不像。它不是一个通用反向代理也不是一个完整的 API 网关。它的职责就三件事接收局域网请求、按编排流程处理、返回结果。鉴权用简单的预共享密钥就够了不需要 OAuth 那套。限流用令牌桶防止某个设备把路由器打满。日志只记关键信息因为路由器的存储空间有限写太多日志很快就把 flash 写满了。注意路由器 flash 的写入寿命有限日志一定要控制量最好写到内存文件系统如 /tmp重启即清空避免频繁写 flash 导致存储损坏。把边界划清楚代码量能控制在很小的范围维护起来也轻松。我整个网关层加上编排层核心代码不到两千行这对于一个能长期稳定运行的服务来说是很舒服的规模。3. 开发环境搭建与交叉编译实操3.1 开发机上的 Go 环境准备先在开发机上把 Go 装好。我用的是比较新的稳定版本装完之后配置好GOPATH和GOROOT确保go version能正常输出。go version # 确认输出类似 go version go1.22.x linux/amd64然后建项目目录初始化模块mkdir ai-flow-orchestrator cd ai-flow-orchestrator go mod init github.com/yourname/ai-flow-orchestrator项目结构我建议这样组织清晰且便于交叉编译ai-flow-orchestrator/ ├── cmd/ │ └── orchestrator/ │ └── main.go ├── internal/ │ ├── engine/ # 编排引擎 │ ├── gateway/ # HTTP 网关 │ ├── steps/ # 各类步骤实现 │ └── config/ # 配置加载 ├── configs/ │ └── flow.json # 流程定义 └── build.sh # 交叉编译脚本3.2 确认路由器的 CPU 架构交叉编译前必须搞清楚目标路由器的架构编错了架构二进制根本跑不起来。华硕路由器常见的架构有几种较老的型号用 MIPS中端用 ARMv7新一些的用 ARMv8aarch64。确认方法有两个一是查路由器型号的官方参数二是如果能登录路由器 shell直接执行uname -m输出armv7l就是 ARMv7aarch64就是 ARMv8mips就是 MIPS。我手上这台是 ARMv7所以后面以GOARCHarm GOARM7为例。3.3 交叉编译与体积优化交叉编译命令本身不复杂CGO_ENABLED0 GOOSlinux GOARCHarm GOARM7 go build -o orchestrator-arm7 ./cmd/orchestrator这里几个参数都有讲究。CGO_ENABLED0是关键关掉 CGO 才能编出纯静态二进制不依赖路由器上的 C 库兼容性最好。GOOSlinux因为 Merlin 固件底层是 Linux。GOARCH和GOARM对应目标架构。编出来的二进制可能有好几兆路由器存储紧张的话可以进一步瘦身CGO_ENABLED0 GOOSlinux GOARCHarm GOARM7 \ go build -ldflags-s -w -o orchestrator-arm7 ./cmd/orchestrator-s -w去掉符号表和调试信息体积能小百分之二三十。如果还嫌大可以用 upx 再压一道但 upx 压缩后的二进制启动时会解压到内存对内存紧张的路由器要权衡。我一般不用 upx保持启动速度和内存占用的平衡。编完之后用file命令确认一下file orchestrator-arm7 # 应输出 ELF 32-bit LSB executable, ARM, EABI5 ...3.4 部署到路由器与权限处理把二进制传到路由器上可以用 scp也可以用 U 盘拷。放到一个可写的目录比如/jffs/分区下这个分区在 Merlin 固件里是可读写的重启后数据还在。scp orchestrator-arm7 admin192.168.1.1:/jffs/ai-flow/传上去之后要加执行权限chmod x /jffs/ai-flow/orchestrator-arm7先手动跑一下确认能起来/jffs/ai-flow/orchestrator-arm7 -config /jffs/ai-flow/flow.json如果报错说找不到动态库那说明 CGO 没关干净回去检查编译参数。如果报权限错误检查文件属主和执行位。手动能跑起来再考虑做成开机自启。4. 提示流编排引擎的核心实现4.1 流程定义的数据结构设计编排引擎的核心是一份流程定义。我用 JSON 来描述因为解析简单、可读性好、改起来不用重新编译。一份典型的流程定义长这样{ name: text_summarize_flow, steps: [ { id: clean, type: local_rule, rule: trim_and_normalize, input: {{request.text}}, output: cleaned }, { id: classify, type: local_model, model: intent_classifier, input: {{cleaned}}, output: intent }, { id: summarize, type: remote_api, endpoint: https://api.example.com/v1/chat, input: {{cleaned}}, output: summary, condition: {{intent}} long_text } ], response: {{summary}} }每个步骤有id、type、输入输出变量名。{{...}}是变量引用语法引擎在执行时会把上一步的输出替换进去。condition字段是可选的满足条件才执行这一步这样能实现简单的分支逻辑。4.2 变量上下文与模板替换变量上下文我用一个map[string]interface{}来存键是变量名值是任意类型。模板替换是引擎里最核心也最容易出 bug 的部分。替换逻辑是这样的扫描字符串里所有{{...}}片段取出里面的变量名去上下文里查值然后替换。如果变量不存在替换成空字符串并记一条警告日志而不是直接报错——因为流程定义里经常有可选变量。func renderTemplate(tpl string, ctx map[string]interface{}) string { re : regexp.MustCompile(\{\{\s*([\w\.])\s*\}\}) return re.ReplaceAllStringFunc(tpl, func(m string) string { key : re.FindStringSubmatch(m)[1] if v, ok : ctx[key]; ok { return fmt.Sprintf(%v, v) } log.Printf(warn: variable %s not found, key) return }) }实操心得模板替换一定要做边界处理。我踩过的坑是用户输入里本身带了{{字符结果被当成变量引用解析了。解决办法是在替换前先对用户原始输入做转义把{{替换成一个占位符替换完再还原。4.3 本地规则步骤的实现local_rule类型的步骤是最轻量的纯字符串处理不涉及任何模型调用。常见的规则有去首尾空白、统一换行符、截断超长文本、正则提取关键字段。这类步骤的价值在于把脏活累活在本地干掉减少后面模型调用的输入体积。比如一段用户输入可能带了很多无意义的空白和特殊字符先清洗一遍再送给模型既省 token 又提高效果。实现上就是一个规则注册表每个规则名对应一个处理函数var ruleRegistry map[string]func(string) string{ trim_and_normalize: func(s string) string { s strings.TrimSpace(s) s strings.ReplaceAll(s, \r\n, \n) return s }, truncate_2000: func(s string) string { r : []rune(s) if len(r) 2000 { return string(r[:2000]) } return s }, }4.4 本地轻量模型步骤的接入local_model步骤是让路由器真正“有 AI 味”的地方。这里说的本地模型不是大语言模型而是轻量级的分类器或小模型比如意图分类、情感判断、关键词抽取。在资源受限设备上跑模型我推荐两种方式。一种是纯 Go 实现的简单模型比如基于关键词权重打分的分类器代码量小、无依赖、速度快。另一种是把模型编译成 ONNX 或者用轻量推理库但这在路由器上部署比较重除非路由器性能足够好。我实际用的是第一种。一个意图分类器本质就是一组关键词和权重的映射表输入文本分词后匹配关键词累加权重取最高分的类别。听起来简陋但在特定垂直场景下准确率够用而且零延迟、零内存压力。type IntentClassifier struct { keywords map[string][]string } func (c *IntentClassifier) Classify(text string) string { scores : map[string]int{} for intent, kws : range c.keywords { for _, kw : range kws { if strings.Contains(text, kw) { scores[intent] } } } best, bestScore : unknown, 0 for intent, score : range scores { if score bestScore { best, bestScore intent, score } } return best }4.5 远端 API 步骤的转发与超时控制remote_api步骤负责把请求转发到远端大模型。这里的关键是超时控制和错误处理。路由器网络环境不一定稳定远端 API 也可能慢。如果不设超时一个卡住的请求会占着 goroutine 不放请求多了直接把路由器拖垮。我给每个远端调用设了 15 秒超时用context.WithTimeout控制。ctx, cancel : context.WithTimeout(context.Background(), 15*time.Second) defer cancel() req, _ : http.NewRequestWithContext(ctx, POST, endpoint, body) resp, err : httpClient.Do(req) if err ! nil { log.Printf(remote api error: %v, err) return fallbackResult, nil // 降级返回不中断整个流程 }注意这里的降级处理远端调用失败时不直接让整个流程失败而是返回一个兜底结果让流程继续走下去。这样用户体验上至少能拿到部分结果而不是一个错误页面。5. Merlin 插件封装与开机自启5.1 Merlin 插件机制的基本原理Merlin 固件的插件机制本质是在固件的服务管理框架里挂一个自定义服务。它通过几个约定好的脚本钩子来管理生命周期启动、停止、状态查询。插件目录一般放在/jffs/下固件启动时会扫描并执行。插件不是随便扔个二进制就行需要按固件的约定提供脚本。核心是一个启动脚本固件在开机流程里会调用它。脚本里负责拉起我们的编排器进程并做好进程守护。5.2 编写插件启动脚本启动脚本我放在/jffs/scripts/下命名遵循固件约定。脚本内容大致如下#!/bin/sh PROG/jffs/ai-flow/orchestrator-arm7 CONFIG/jffs/ai-flow/flow.json PIDFILE/var/run/ai-flow.pid LOGFILE/tmp/ai-flow.log start() { if [ -f $PIDFILE ] kill -0 $(cat $PIDFILE) 2/dev/null; then echo already running return fi $PROG -config $CONFIG $LOGFILE 21 echo $! $PIDFILE echo started } stop() { if [ -f $PIDFILE ]; then kill $(cat $PIDFILE) 2/dev/null rm -f $PIDFILE fi echo stopped } case $1 in start) start ;; stop) stop ;; restart) stop; sleep 1; start ;; *) echo usage: $0 {start|stop|restart} ;; esac日志写到/tmp/下这是内存文件系统重启清空不伤 flash。PID 文件也放/tmp/同样道理。5.3 进程守护与异常重启光有启动脚本还不够进程万一崩了得能自动拉起来。我在启动脚本外面套了一层守护逻辑用一个简单的循环检测while true; do if ! kill -0 $(cat $PIDFILE) 2/dev/null; then start fi sleep 30 done这个守护循环本身也要能被固件管理。我的做法是把守护逻辑也放进插件脚本由固件的服务框架统一调度。这样路由器重启后固件拉起插件脚本脚本再拉起守护循环和编排器进程整条链路就活了。注意守护循环的检测间隔别设太短30 秒比较合适。设太短会频繁唤醒 CPU路由器本来就低功耗设计没必要为了秒级恢复牺牲功耗。而且进程崩溃往往有原因频繁重启反而掩盖了问题日志里要能看出崩溃原因。5.4 资源限制与稳定性保障路由器资源有限必须给编排器进程设资源上限防止它失控拖垮整个路由器。可以用ulimit限制内存用nice调整优先级让它在 CPU 紧张时让路ulimit -v 65536 # 限制虚拟内存 64MB nice -n 10 $PROG -config $CONFIG $LOGFILE 21 ulimit -v限制的是虚拟内存超过就分配失败进程会收到错误而不是把系统内存吃光。nice -n 10让进程优先级略低于系统关键服务网络转发这种核心功能永远优先。另外编排器内部也要做自我保护限制并发处理的请求数超过就排队或直接拒绝。我用一个带缓冲的 channel 做信号量容量设为 8意味着最多同时处理 8 个请求超出的等待。sem : make(chan struct{}, 8) func handle(w http.ResponseWriter, r *http.Request) { select { case sem - struct{}{}: defer func() { -sem }() // 处理请求 default: http.Error(w, busy, http.StatusServiceUnavailable) } }6. 边缘网关的接口设计与安全6.1 HTTP 接口的路径与参数约定网关对外就暴露一个主接口路径设计得简单直接POST /v1/flow/{flow_name} Header: X-Auth-Key: 预共享密钥 Body: {text: 用户输入内容}flow_name对应流程定义里的name字段这样一套网关可以挂多个不同的流程按名字路由。请求体用 JSON字段根据流程需要定义引擎会把整个请求体塞进上下文流程里用{{request.text}}这种方式引用。响应也是 JSON{ ok: true, result: 处理结果, elapsed_ms: 123 }带上耗时字段方便调用方做性能监控。6.2 鉴权与限流的最小实现鉴权用预共享密钥简单但够用。密钥放在配置文件里请求头里带上网关比对一下就行。局域网环境下不需要太复杂的鉴权机制密钥泄露的风险很低。func authMiddleware(next http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { if r.Header.Get(X-Auth-Key) ! cfg.AuthKey { http.Error(w, unauthorized, http.StatusUnauthorized) return } next(w, r) } }限流用令牌桶每个来源 IP 一个桶桶容量 10每秒补充 1 个令牌。这样单个设备突发最多打 10 个请求持续速率限制在每秒 1 个。实现用golang.org/x/time/rate这个标准扩展库几行代码搞定。limiter : rate.NewLimiter(1, 10) if !limiter.Allow() { http.Error(w, rate limited, http.StatusTooManyRequests) return }6.3 请求日志与隐私处理日志要记但要注意隐私。用户输入的内容可能包含敏感信息不能原样落盘。我的做法是日志只记请求的元信息——时间、来源 IP、流程名、耗时、状态码不记请求体内容。如果调试需要看内容加一个开关开启后只记前 50 个字符且明确提示这是调试模式。log.Printf(flow%s ip%s elapsed%dms status%d, flowName, clientIP, elapsed, status)这样既能在出问题时定位又不会把用户数据留在日志里。路由器上的日志本来就该精简这个约束反而帮我们养成了好习惯。7. 常见问题与排查技巧实录7.1 二进制跑不起来怎么办这是新手最容易卡住的地方。排查顺序我总结成一张表现象可能原因排查方法提示 not found架构编错用 file 命令看二进制架构对比 uname -m提示 permission denied没有执行权限chmod x 加执行位提示 no such file动态库缺失确认 CGO_ENABLED0 重新编译段错误架构不兼容换 GOARM 版本重编试 6 或 7启动即退出配置解析失败前台运行看报错输出我遇到最多的是架构问题。有一次编了个 ARMv7 的二进制扔到 MIPS 路由器上直接报格式错误。所以部署前一定先uname -m确认清楚。7.2 内存占用过高被系统杀掉路由器内存小进程被杀是常事。表现是服务跑一会儿就没了日志里可能有 OOM 相关记录。排查思路先看进程实际内存占用用top或cat /proc/pid/status看VmRSS。如果确实高检查几个点是不是并发请求太多导致 goroutine 堆积是不是某个步骤缓存了太多数据没释放是不是日志缓冲太大。我的经验是编排器常驻内存应该稳定在 10MB 以内。如果超过 20MB基本可以确定有泄漏或者设计问题。最有效的办法是给进程设ulimit -v让它超限时自己崩掉重启而不是拖垮整个路由器。7.3 远端 API 调用超时拖垮流程远端 API 慢或者不通会导致请求堆积。前面说的超时控制是必须的但还有几个细节要注意。一是 HTTP 客户端要复用不要每次请求都新建 client那样连接池用不上性能差还费内存。全局建一个 client设好超时和连接池参数var httpClient http.Client{ Timeout: 15 * time.Second, Transport: http.Transport{ MaxIdleConns: 10, MaxIdleConnsPerHost: 5, IdleConnTimeout: 30 * time.Second, }, }二是远端失败要有降级策略。我一般准备一个兜底回复远端不通时返回它保证流程不中断。三是监控远端调用的成功率如果持续失败说明网络或对端有问题日志里要能看出来。7.4 开机自启不生效的排查插件脚本写了但重启后服务没起来这种情况排查起来有几个固定步骤。先确认脚本有没有执行权限ls -l看一下。再确认脚本路径和命名是否符合固件约定不同 Merlin 版本约定可能略有差异要对照对应版本的文档。然后手动执行一遍脚本看有没有报错。最后看固件日志dmesg或者固件自己的日志文件里通常会有插件加载的记录。我踩过的坑是脚本里用了固件不支持的 shell 语法。路由器上的 shell 往往是精简版不支持某些 bash 特性。所以脚本尽量用最基础的 POSIX sh 语法别用 bash 特有的东西。7.5 常见问题速查表问题快速定位解决方向服务起不来前台手动运行看报错按报错信息对症处理请求超时看日志耗时字段检查远端 API 和超时设置内存持续增长看 VmRSS 趋势排查 goroutine 泄漏和缓存日志写满 flash看 /jffs 剩余空间日志改写到 /tmp并发高时崩溃看是否触发 ulimit降低并发上限加限流重启后配置丢失检查配置文件位置配置放 /jffs 持久分区8. 性能调优与扩展方向8.1 在低算力设备上压榨性能路由器 CPU 主频低、核心少性能调优的空间其实不大但有几个点值得做。第一是减少不必要的内存分配。Go 的 GC 在低内存设备上比较敏感频繁分配会触发频繁 GC拖慢整体。字符串拼接用strings.Builder而不是能复用的 buffer 就复用。第二是避免阻塞主流程远端调用这种耗时操作要能并发就并发但并发度要控制别把 CPU 占满影响网络转发。第三是精简流程步骤能合并的步骤合并能本地做的别转发。我实测下来一个三步流程清洗、分类、转发在 ARMv7 路由器上平均耗时 200 到 400 毫秒其中大部分时间花在远端调用上本地处理只占几毫秒。所以优化重点应该放在远端调用的并发和缓存上而不是本地计算。8.2 流程定义的动态加载一开始流程定义是启动时加载一次改流程要重启服务。后来我改成了支持动态加载监听配置文件变化变了就重新加载不用重启。实现上用fsnotify监听文件或者简单点用定时轮询文件修改时间。路由器上我用的轮询每 10 秒检查一次开销可以忽略。加载新配置时用读写锁保护正在处理的请求用旧配置新请求用新配置平滑过渡。这个功能在实际使用中很实用调流程的时候不用反复重启服务改完存盘等几秒就生效。8.3 后续可以扩展的方向这套东西跑通之后能扩展的方向不少。一是多路由器协同。家里如果有多个路由器组网可以让它们各自跑编排器互相转发请求做负载均衡。二是本地缓存。相同的输入如果频繁出现可以缓存结果减少远端调用。三是更丰富的步骤类型比如加一个webhook步骤把结果推送到其他服务。四是可视化流程编辑做一个简单的网页界面来编辑流程定义不用手写 JSON。不过要提醒一句扩展要克制。路由器资源有限功能堆太多必然影响稳定性。我个人的原则是核心编排能力做扎实扩展功能按需加加一个就要确保它不会拖累整体。9. 我在实际部署中的几点体会这套东西我从动手到稳定运行前后折腾了大概两周中间踩的坑比预想的多。最大的体会是在资源受限设备上做开发克制比聪明更重要。很多在服务器上理所当然的做法在路由器上就是灾难。比如随手开个 goroutine 不回收服务器上无所谓路由器上跑一天内存就满了。另一个体会是日志和监控要前置。路由器上出问题不像服务器那样方便调试很多时候只能靠日志回溯。所以日志字段要设计好关键路径都要有记录宁可多记一点元信息也别出问题时两眼一抹黑。还有就是别追求一步到位。我一开始想做得功能很全结果代码越写越复杂稳定性反而差。后来砍掉一半功能只保留最核心的编排和转发反而跑得又稳又快。先把最小可用版本跑通再按实际需求慢慢加这个节奏在嵌入式开发里特别重要。最后分享一个小技巧调试阶段可以给编排器加一个/debug/pprof接口用 Go 自带的性能分析工具看 CPU 和内存热点。这个接口只在调试时开正式运行关掉。它能帮你快速定位性能瓶颈比盲目猜测高效得多。