企业官网建设流程全解析

1. 为什么要在路由器上跑 AI 提示流

把 AI 能力塞进一台华硕路由器，听起来像是极客的恶趣味，但真做过一轮之后你会发现，这个方向解决的是一个非常具体的痛点：家庭和小型办公网络里，越来越多的智能请求需要就近处理，而不是全部甩到云端。比如本地设备的语音指令预处理、内网日志的语义归类、IoT 传感器的异常描述生成，这些场景对延迟敏感、对隐私敏感、对成本也敏感。如果每次都把原始数据打包发到远端大模型，光是往返延迟就够让人抓狂，更别提流量费用和数据出域的顾虑。

我这次做的事情，是在华硕 Merlin 固件的路由器上，用 Go 写一个轻量边缘网关，再配一个提示流编排器，把多个 AI 引擎的调用逻辑做成可配置的流水线。整条链路跑在路由器本地，对外只暴露一个统一入口。路由器本身算力有限，所以核心思路不是“把大模型搬上去”，而是“把编排和路由逻辑放上去”，真正的推理仍然可以走本地小模型或者按需转发到内网其他节点。这样既拿到了边缘就近处理的低延迟，又不会把路由器压垮。

这套东西适合谁？如果你手上有一台刷了 Merlin 的华硕路由器，懂一点 Linux 和 Go，想让家里的 AI 请求走一条自己可控的链路，那这篇内容就是写给你的。如果你只是想了解边缘网关和提示流编排的设计思路，里面的架构拆解和踩坑记录同样有参考价值。下面我按实际搭建顺序，把设计考量、核心实现、实操步骤和排查经验完整讲一遍。

2. 整体架构设计与方案选型

2.1 为什么是 Merlin 插件加 Go 网关这个组合

华硕 Merlin 固件本质上是基于华硕官方固件做的增强版，保留了原厂的稳定性和硬件驱动，同时开放了更多可操作空间，比如自定义脚本、JFFS 分区、entware 包管理。这意味着你不需要刷一个完全陌生的第三方固件，就能在路由器上跑自己的程序。对于边缘网关这种需要长期稳定运行的服务来说，底层固件的稳定性比什么都重要，Merlin 在这点上比很多纯开源固件更让人放心。

选 Go 作为网关的实现语言，理由很直接。第一，Go 编译出来是静态二进制，不依赖一堆动态库，扔到路由器的 JFFS 分区里就能跑，部署成本极低。第二，Go 的并发模型天然适合做请求编排，goroutine 加 channel 处理多路 AI 调用的聚合和超时控制非常顺手。第三，交叉编译简单，在开发机上一条命令就能出 ARM 架构的可执行文件，不用在路由器上折腾编译环境。相比之下，用 Python 写虽然开发快，但运行时依赖和内存占用在路由器上都是负担；用 C 写性能好但开发效率太低，提示流这种逻辑经常要改的东西不适合。

插件部分我采用的是 Merlin 的services-start和nat-start脚本机制，把网关的启动、守护和端口转发规则挂进去。这样路由器重启后服务能自动拉起，不需要手动干预。整个方案的分层是这样的：最底层是 Merlin 固件和 JFFS 分区，中间是 Go 编写的边缘网关进程，上层是提示流编排配置和各个 AI 引擎的适配器。每一层职责清晰，出问题的时候容易定位。

2.2 提示流编排器的核心设计思路

提示流编排器要解决的核心问题是：一个用户请求进来，可能需要经过多个处理步骤，每个步骤可能调用不同的 AI 引擎，步骤之间有依赖关系，还要处理超时、降级和结果聚合。如果把这些逻辑硬编码在代码里，改一次流程就要重新编译部署，在路由器上这么干太痛苦。所以我把流程做成了配置驱动，用一份 YAML 描述整个提示流，网关启动时加载配置，运行时按配置执行。

一个典型的提示流配置包含几个要素：输入解析规则、步骤列表、每个步骤的引擎类型和参数、步骤之间的数据传递方式、超时和重试策略、最终输出的组装规则。比如一个“内网日志语义归类”的流，第一步可能是用本地小模型做初步分类，第二步根据分类结果决定是否调用更强的引擎做细化，第三步把结果格式化成结构化 JSON。这些都在配置里描述，代码只负责执行引擎。

引擎适配器是另一个关键设计。我把每个 AI 引擎封装成一个统一的接口，输入是标准化的请求结构，输出是标准化的响应结构。这样编排器不需要关心底层是本地模型还是远端服务，换引擎只需要换适配器配置。目前我实现了三类适配器：本地进程调用型（通过标准输入输出和本地模型交互）、HTTP 调用型（对接内网其他节点的推理服务）、以及规则型（不调用模型，纯做数据转换和条件判断）。规则型适配器看起来不起眼，但在流程里做分支控制和数据清洗非常有用。

2.3 边缘网关的资源约束与应对策略

路由器的资源是硬约束，我手上这台是 ARM 双核加 256MB 内存的配置，跑一个 Go 网关加上几个适配器，内存占用要控制在 30MB 以内才安全。这个约束直接影响了几个设计决策。第一，网关不做任何模型推理，只做编排和转发，把重活留给内网其他节点。第二，请求处理采用流式而非全量缓冲，避免大请求把内存吃满。第三，连接池和并发数都要设上限，防止突发流量把路由器打挂。

还有一个容易被忽略的点是存储。JFFS 分区容量有限，日志不能无限写。我的做法是日志分级，INFO 级别只保留最近若干条在内存环形缓冲里，需要排查问题时通过一个调试接口拉取，WARN 和 ERROR 级别才落盘，并且做了大小轮转。这样既保证了可观测性，又不会把分区写满。实测下来，这套策略让网关在连续运行两周后内存占用依然稳定在 25MB 左右，没有出现泄漏导致的缓慢增长。

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

3.1 路由器环境准备与 Merlin 插件挂载

动手之前先确认几件事。路由器必须已经刷好 Merlin 固件，并且开启了 JFFS 分区和自定义脚本支持。这两项在 Merlin 的管理界面里能找到，开启后需要重启一次。JFFS 分区建议格式化为支持可执行权限的文件系统，否则放进去的二进制跑不起来。我一开始就踩了这个坑，二进制拷进去执行报权限错误，查了半天才发现是挂载参数的问题。

接下来是 entware 环境。Merlin 上装 entware 有标准流程，装完之后你就有了一套包管理工具，可以按需安装一些辅助工具，比如用于调试的网络工具。但要注意，entware 装在外部存储上更稳妥，如果路由器有 USB 接口，插一个 U 盘专门放 entware 和网关程序，比放在 JFFS 里更安全，也不会因为固件升级把数据冲掉。我的做法是 U 盘分两个区，一个放 entware，一个放网关程序和配置。

插件挂载的核心是 Merlin 的脚本钩子。services-start在服务启动时执行，适合放网关的启动逻辑；nat-start在网络地址转换规则重建时执行，适合放端口转发和防火墙规则。我把网关的启动脚本放在services-start里，用nohup后台拉起，并写了一个简单的守护逻辑，进程挂了自动重启。这里有个细节：脚本里要用绝对路径，因为执行时的环境变量和交互式登录不一样，相对路径会找不到文件。

注意：修改 Merlin 脚本后，一定要用chmod +x给脚本加执行权限，否则钩子不会触发。这个坑我见过太多人踩。

3.2 Go 网关的交叉编译与部署

在开发机上写 Go 代码，编译目标要指定为路由器的架构。华硕路由器常见的是 ARMv7 架构，编译命令大致是设置GOOS=linux、GOARCH=arm、GOARM=7，然后go build出静态二进制。如果你的路由器是 ARM64，对应调整GOARCH=arm64。编译时建议加上-ldflags "-s -w"去掉调试信息，能把二进制体积缩小不少，对存储紧张的路由器很有意义。

部署的时候，我习惯先在开发机上把二进制和配置文件打包，通过安全文件传输工具传到路由器的 U 盘目录，然后在路由器上解压、赋权、启动。启动前先用ldd检查一下有没有动态依赖，静态编译的话应该显示“not a dynamic executable”，看到这个就放心了。如果显示缺库，说明编译时没关掉 CGO，需要设置CGO_ENABLED=0重新编译。

配置文件的路径我建议用环境变量传入，而不是写死在代码里。这样同一份二进制可以在不同路由器上用不同配置，也方便做多环境切换。启动脚本里 export 一个GATEWAY_CONFIG指向配置文件，程序启动时读取。配置热加载我也做了，收到特定信号后重新读取配置，不用重启进程，改流程的时候体验好很多。

3.3 提示流配置的字段设计与语义

提示流配置是整个系统的灵魂，字段设计得好不好直接决定用起来顺不顺手。我的配置顶层有三个部分：input定义输入解析，steps定义步骤列表，output定义输出组装。input里可以指定从 HTTP 请求的哪个位置取数据，支持 JSON 路径和表单字段，还能做简单的类型转换和校验。校验失败直接返回错误，不会进入后续步骤，省得脏数据往下传。

每个 step 的字段包括name、engine、params、input_from、timeout、on_error。input_from指定这个步骤的输入来自哪里，可以是原始输入，也可以是前面某个步骤的输出，还能用模板语法做字段拼接。on_error定义出错时的行为，可选fail（整个流失败）、skip（跳过这步继续）、fallback（走备用引擎）。这个设计让流程的容错能力大大增强，比如某个远端引擎临时不可用，可以自动降级到本地规则引擎，用户几乎无感知。

output部分负责把各步骤的结果组装成最终响应。支持字段映射、条件包含和格式转换。我经常用条件包含来做响应裁剪，比如调试模式下返回所有中间结果，生产模式下只返回最终字段。这个开关通过请求头控制，排查问题时特别方便，不用改配置。

3.4 引擎适配器的接口约定与实现

引擎适配器的接口我定义得很简单，一个方法：接收上下文和标准化请求，返回标准化响应和错误。标准化请求里包含提示文本、参数键值对、以及可选的流式回调。标准化响应里包含结果文本、元数据（比如耗时、token 数）和错误信息。这样编排器只跟这个接口打交道，具体引擎怎么调是适配器自己的事。

本地进程调用型适配器适合对接那些以命令行方式运行的小模型。适配器启动子进程，把提示通过标准输入传进去，从标准输出读结果。这里要注意超时控制，子进程卡死的话必须能杀掉，否则会拖垮整个网关。我用context加超时来做，超时后发送终止信号，再等一小段时间强制杀掉。另外子进程的并发数要限制，同时跑太多会把路由器 CPU 打满。

HTTP 调用型适配器对接内网其他节点的推理服务。这里的关键是连接复用和超时设置。Go 的默认 HTTP 客户端连接池对路由器场景来说偏大，我调小了最大空闲连接数和每主机连接数，避免占用过多文件描述符。超时分为连接超时和读取超时，读取超时要给足，因为推理可能比较慢，但连接超时要短，快速失败好过长时间等待。

规则型适配器不调用任何模型，纯做数据转换。它支持几种操作：字段提取、正则替换、条件分支、常量注入。看起来简单，但在流程里做数据清洗和分支控制非常实用。比如把上一步的自由文本结果用正则提取出关键字段，再根据字段值决定下一步走哪个分支，这些都不需要模型参与，用规则型适配器又快又稳。

4. 实操过程与核心环节实现

4.1 从零搭建开发与调试环境

开发环境我建议在本地用容器或者虚拟机搭一个跟路由器架构一致的 Linux 环境，方便调试。直接在路由器上调试效率太低，每次改代码都要交叉编译再传上去，来回折腾。本地环境里可以跑一个模拟的 HTTP 服务来替代真实 AI 引擎，先把编排逻辑调通，再对接真实引擎。

调试网关的时候，日志是第一手资料。我在网关里内置了一个调试接口，可以通过 HTTP 请求动态调整日志级别，还能拉取最近的请求处理轨迹。每条请求都有一个追踪 ID，从入口到各个步骤的执行情况都记录在案，出问题的时候顺着追踪 ID 一看就知道卡在哪一步。这个追踪机制在排查复杂流程问题时价值巨大，强烈建议一开始就做进去。

本地调通之后，交叉编译传到路由器上做集成测试。集成测试的重点是资源占用和稳定性。我会用压力测试工具模拟并发请求，观察路由器的内存和 CPU 变化，找到系统的承载上限。实测下来，这台路由器上网关能稳定处理每秒十几个请求，再高就开始出现超时。这个数字因路由器型号而异，你需要自己测一下自己的设备。

4.2 编写第一个提示流的完整过程

第一个提示流我选了一个简单的场景：接收一段文本，先做敏感词过滤（规则型），再做情感倾向判断（本地小模型），最后根据情感结果生成一句回复建议（规则型模板）。这个流程涵盖了三种适配器类型，适合用来验证整条链路。

配置写起来大概是这样：input从请求体取text字段并校验非空；steps里第一步是规则型适配器做过滤，第二步是本地模型做情感判断，第三步是规则型适配器根据情感标签选模板；output把最终建议和中间的情感标签一起返回。整个配置不到五十行，但已经能跑通完整的编排逻辑。

写完配置后，用调试接口发一个测试请求，看追踪日志里每一步的输入输出是否符合预期。第一次跑大概率会有字段名对不上或者类型不匹配的问题，对着日志改就行。调通之后，把这个流注册到网关的路由表里，对外暴露一个路径，就可以从内网其他设备调用了。

4.3 多引擎协同与降级策略落地

真实场景里，一个流往往要协调多个引擎，还要考虑某个引擎不可用时的降级。我拿一个“设备日志智能摘要”的流来举例。这个流第一步用本地规则引擎做日志清洗和关键行提取，第二步把提取结果发给内网的一个推理节点做摘要生成，第三步用规则引擎把摘要格式化成告警卡片。如果第二步的推理节点超时或者返回错误，降级策略是跳过摘要，直接把提取的关键行作为结果返回，并标记为降级模式。

降级策略在配置里通过on_error: fallback加fallback_engine来指定。fallback 引擎可以是另一个适配器，也可以是一个常量响应。关键是降级后的结果要能让下游感知到，所以我在响应元数据里加了一个degraded标志，调用方可以根据这个标志决定是否要重试或者提示用户。这个细节看起来小，但在生产环境里很重要，静默降级会让问题被掩盖。

多引擎协同还有一个坑是数据格式的兼容。不同引擎返回的字段名和结构可能不一样，编排器需要在步骤之间做适配。我的做法是在每个步骤的输出上定义一个 schema，下一步的输入按 schema 取值，schema 不匹配就在配置加载阶段报错，而不是等到运行时才炸。这样配置写错能早发现，省得线上出问题。

4.4 性能调优与资源占用实测

性能调优我主要做了三件事。第一是减少内存分配，Go 的 GC 在内存紧张的环境下压力不小，我尽量复用缓冲区，避免在热路径上创建临时对象。第二是控制并发，网关层面限制同时处理的请求数，引擎层面限制每个引擎的并发调用数，两层限流防止雪崩。第三是优化序列化，JSON 编解码在请求量大时是瓶颈，我用了更高效的编解码方式，减少了不必要的字段拷贝。

实测数据方面，在空载情况下网关内存占用约 18MB，处理请求时峰值到 28MB 左右，稳定后回落到 22MB 上下。CPU 占用在空闲时几乎为零，处理请求时单核能到 40% 左右。连续跑了一周，内存没有明显增长，说明没有泄漏。这些数字给你一个参考，具体因路由器和负载而异，但量级上应该差不多。

提示：调优的时候一定要用真实负载测，不要用理想化的测试数据。真实请求的字段长度、并发模式跟测试数据差别很大，用测试数据调出来的参数上线后往往不够用。

5. 常见问题与排查技巧实录

5.1 网关启动失败与进程守护问题

网关启动失败最常见的原因是权限和路径。二进制没有执行权限、配置文件路径写错、依赖的目录不存在，这三个占了八成。排查的时候先在命令行手动执行一次，看报什么错，比看日志快。如果手动执行正常但开机不启动，那就是 Merlin 脚本的问题，检查脚本有没有执行权限、路径是不是绝对路径、环境变量有没有设置。

进程守护我用的是一个简单的看门狗脚本，定期检查进程是否存在，不存在就重新拉起。这里有个坑是看门狗自己也可能挂，所以我把看门狗也放进了 Merlin 的服务管理里，让它跟着系统服务一起启动。另外看门狗重启进程要有频率限制，否则进程因为配置错误反复崩溃，看门狗会疯狂重启，把日志刷爆。我设了每分钟最多重启三次，超过就停止并记录错误，等人来查。

5.2 请求超时与引擎无响应的排查

请求超时是边缘网关最常见的故障。排查思路是从外到内逐层定位：先看网关有没有收到请求，再看请求卡在哪个步骤，然后看那个步骤对应的引擎有没有响应。追踪日志在这里是神器，每个步骤的开始和结束都有时间戳，一眼就能看出是哪一步慢。

引擎无响应分几种情况。本地进程型引擎可能是子进程卡死，需要检查子进程的资源占用和输出。HTTP 型引擎可能是网络不通或者远端服务挂了，先用网络工具测连通性，再看远端服务的健康状态。规则型引擎一般不会无响应，如果卡住多半是正则表达式写得太复杂导致回溯爆炸，这种要优化正则或者加超时。

还有一种隐蔽的超时是连接池耗尽。请求量大的时候，如果连接没有及时释放，后续请求会排队等连接，表现为整体变慢而不是单个超时。排查方法是看网关的连接数指标，如果持续接近上限，就要检查是不是有连接泄漏，或者调大连接池并优化释放逻辑。

5.3 配置加载错误与字段映射问题

配置加载错误大多出在字段名拼写和类型上。YAML 对缩进敏感，缩进错了会导致解析出意料之外的结构。我的做法是在配置加载后做一次完整的校验，把每个步骤引用的字段、每个引擎的参数都检查一遍，有问题直接报错并指出具体位置。这样配置写错能立刻发现，不用等到运行时。

字段映射问题更隐蔽，因为配置能加载但运行时取不到值。常见原因是上游步骤的输出字段名跟下游引用的不一致，或者数据类型不匹配导致转换失败。我在追踪日志里把每个步骤的输入输出都打出来，对照着看就能发现。另外建议给字段引用加上默认值，取不到的时候用默认值而不是报错，这样流程更健壮。

5.4 常见问题速查表

这张表是我踩坑之后整理的，基本覆盖了日常会遇到的问题。遇到新问题的时候，先对照这张表看有没有相似的，没有的话再按从外到内的思路逐层排查。排查的核心是缩小范围，不要一上来就怀疑最复杂的地方，往往问题出在最简单的环节。

6. 后续扩展与个人经验体会

这套东西跑稳之后，能扩展的方向不少。我目前在试的是把提示流配置做成可远程下发的，这样多台路由器可以共享一套流程定义，改一处全部生效。另一个方向是加一个简单的管理界面，用网页配置流程和查看运行状态，不用每次都改 YAML。还有就是引擎适配器的插件化，让第三方可以自己写适配器接进来，不用改网关主体代码。

我个人在实际操作中的体会是，边缘网关这种东西，稳定性比功能丰富重要得多。路由器不是服务器，它首先要把网络转发做好，你的网关是搭便车的，不能喧宾夺主。所以资源占用要克制，异常处理要周全，宁可功能少一点，也不要让网关成为整个网络的单点故障。我见过太多人一上来就想在路由器上跑大模型，结果把路由器跑死，网络都断了，得不偿失。

最后再分享一个小技巧：给网关加一个“安全模式”开关，通过一个物理按键或者特定的启动参数触发，进入安全模式后网关只加载最小配置，不启动任何引擎，只提供一个健康检查接口。这样万一配置改错了导致网关起不来，还能进安全模式把配置改回去，不用拆机重刷固件。这个开关救过我好几次，强烈建议你也加上。