1. 为什么要在路由器上折腾AI提示流编排
把AI引擎塞进华硕路由器这件事，第一次跟朋友提起来的时候，对方看我的眼神就像在看一个非要给自行车装涡轮增压的人。但如果你手头正好有一台刷了Merlin固件的华硕路由器，又恰好对本地AI编排有点兴趣，这个组合其实比想象中合理得多。路由器是家里唯一7×24小时不关机的设备，功耗低、网络位置天然居中，所有设备的流量都从它这里过。把轻量级的AI提示流编排器部署在上面，意味着你不需要额外开一台常驻的迷你主机或者NAS，就能拥有一个随时在线的边缘AI网关。
这个项目的核心目标很明确：用Go语言写一个轻量的提示流编排器，编译成华硕路由器（ARM架构）能跑的二进制文件，通过Merlin固件的插件机制或者自定义启动脚本让它常驻运行，对外暴露一个HTTP接口，接收请求后按预设的流程调用不同的AI后端（可以是云端API，也可以是局域网内的本地模型服务），把结果编排好再返回。听起来像是把LangChain或者Dify那套东西压缩成一个几MB的二进制塞进路由器，实际上确实就是这个思路，只不过要砍掉所有不必要的依赖，只保留最核心的编排能力。
适合谁来参考这篇内容？如果你满足以下任意一条，这篇东西对你就有的聊：手里有华硕路由器并且刷了Merlin固件，想找点新玩法；写过一点Go但没做过交叉编译到嵌入式的项目；对AI提示工程和流程编排有基本概念，想搞一个低成本的常驻服务；或者纯粹好奇一个路由器到底能扛住什么样的计算任务。不需要你是内核专家，也不需要你懂电路，会SSH、会改配置文件、能看懂Go的基础语法就够了。
我前后折腾了大概两周，中间踩了不少坑，从交叉编译的CGO问题到路由器上存储空间不够，再到Merlin固件的启动脚本执行时机，每一个环节都有值得记录的东西。下面按实际操作的顺序，把整个从0到1的过程拆开讲。
2. 整体架构设计与技术选型思路
2.1 为什么选Go而不是Python或Node
在路由器上跑东西，第一个要面对的现实就是资源极其有限。我手上这台华硕AX88U，Broadcom四核1.8GHz处理器，1GB RAM，256MB Flash。Flash空间是最大的瓶颈，Merlin固件本身加上各种插件之后，可用的JFFS分区通常只剩几十MB。Python解释器加上pip装几个包，轻松就上百MB，而且Python在ARM上的启动速度和内存占用都不太适合常驻服务。Node的情况类似，node_modules的体量在嵌入式环境里是灾难。
Go的优势在这里非常明显：静态编译，单个二进制文件，没有运行时依赖，交叉编译极其方便。一个功能完整的提示流编排器，用Go写出来编译后大概8到15MB，strip掉符号表之后可以压到6MB左右。内存占用方面，空载时大概20到30MB，处理请求时根据并发量浮动，对于1GB RAM的路由器来说完全可以接受。而且Go的标准库自带HTTP服务器和JSON处理，不需要引入额外的Web框架，进一步减小了体积。
另一个考虑是并发模型。提示流编排的本质是多个AI调用的串行或并行组合，Go的goroutine和channel天然适合这种场景。比如一个流程需要同时调用两个不同的模型然后合并结果，用goroutine几行代码就搞定了，不需要引入复杂的异步框架。
2.2 边缘网关的定位与职责边界
这个编排器在架构上扮演的是边缘网关的角色，但它不是传统意义上的API Gateway。传统的API Gateway主要做路由、鉴权、限流这些事情，而这里的边缘网关核心职责是提示流的编排和执行。具体来说，它要处理以下几件事：
接收来自局域网内其他设备的请求，请求体里包含一个流程标识和输入参数。根据流程标识找到预定义的编排逻辑，这个逻辑描述了要调用哪些AI后端、以什么顺序调用、每一步的输出如何传递给下一步。执行编排逻辑，调用后端的AI服务（可能是云端的OpenAI兼容接口，也可能是局域网内另一台机器上跑的本地模型），收集结果。对结果进行后处理，比如格式化、过滤、拼接，然后返回给调用方。
它不做模型推理本身，路由器也扛不住。它的价值在于把复杂的多步AI调用逻辑集中管理，让局域网内的其他设备只需要发一个简单的请求就能获得编排好的结果。比如你的智能家居系统想做一个“根据天气和日程生成出行建议”的功能，不需要在智能家居控制器里实现整个逻辑，只需要调用路由器上的编排器，传一个流程ID和参数就行。
2.3 提示流编排器的核心抽象
编排器的核心抽象我设计了三个概念：Step、Flow和Backend。Step是最小执行单元，代表一次AI调用或者一次数据处理操作。每个Step有类型（比如llm_call、template_render、condition、merge）、配置参数和输入输出映射。Flow是一组Step的有序或无序集合，定义了执行拓扑。Backend是AI后端的抽象，封装了不同API的调用细节，对外暴露统一的接口。
这种抽象的好处是扩展性强。想加一个新的AI服务商，只需要实现一个Backend接口。想加一种新的处理逻辑，只需要加一种Step类型。整个编排器不关心具体调用的是哪个模型，只关心输入输出和流程控制。
用Go的interface来描述就是：Backend接口定义Call方法，接收prompt和参数，返回结果和错误。Step接口定义Execute方法，接收上下文，返回输出。Flow结构体持有Step列表和依赖关系，提供Run方法按拓扑顺序执行。
2.4 部署形态的选择：插件还是独立进程
Merlin固件支持两种方式运行第三方程序：一种是做成标准的Merlin插件（.tar.gz格式，通过软件中心安装），另一种是直接放一个二进制到JFFS分区，通过启动脚本拉起。我两种方式都试过，最终选择了独立进程加启动脚本的方式，原因如下。
Merlin插件的打包和安装机制有一套固定的目录结构和元数据要求，对于快速迭代开发来说太笨重。每次改代码都要重新打包、上传、安装，调试效率很低。而且插件机制对进程管理有自己的逻辑，有时候会和我的需求冲突。独立进程的方式更灵活，我可以直接scp二进制上去，改启动脚本，重启服务，整个过程几十秒搞定。
但独立进程也有代价：需要自己处理开机自启、进程守护、日志轮转这些事情。Merlin固件基于Asuswrt，底层是BusyBox，没有systemd，init系统比较简单。我的做法是在/jffs/scripts/目录下添加services-start和services-stop脚本，Merlin固件在启动和停止服务时会调用这两个脚本。在services-start里用nohup拉起二进制，在services-stop里kill掉进程。进程守护用一个简单的while循环脚本配合cron定时检查，如果进程不在了就重新拉起。
3. 开发环境搭建与交叉编译实操
3.1 Go开发环境的安装与版本选择
开发机我用的是Ubuntu 22.04，Go版本选的1.21。为什么不用最新版？因为路由器上的内核版本比较老，Go 1.21对Linux 4.x内核的兼容性经过充分验证，而且编译出来的二进制体积比1.22略小一点。安装Go的方式很简单，直接从官网下载tar.gz包解压到/usr/local，然后把/usr/local/go/bin加到PATH里。
wget https://go.dev/dl/go1.21.6.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.21.6.linux-amd64.tar.gz echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bashrc source ~/.bashrc go version如果你之前装过其他版本的Go，注意清理旧的GOPATH和GOROOT环境变量，避免版本冲突。我一开始就是因为环境变量里残留了旧版本的路径，导致go build的时候报了一堆莫名其妙的错误，排查了半天才发现是版本混用。
3.2 交叉编译到ARM架构的关键参数
华硕AX88U的CPU是Broadcom BCM4908，四核ARM Cortex-A53，64位架构。所以目标平台是linux/arm64。交叉编译的命令本身很简单：
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -ldflags="-s -w" -o ai-orchestrator .这里有几个关键点需要解释。CGO_ENABLED=0是必须的，因为路由器上没有glibc，开启CGO会导致编译出来的二进制依赖动态链接库，在路由器上跑不起来。-ldflags="-s -w"的作用是去掉符号表和调试信息，能把二进制体积减小30%左右。我实测一个15MB的二进制加上这个参数后变成9MB左右。
但这里有个坑：如果你的代码里用了net包或者os/user包，在某些Go版本下即使CGO_ENABLED=0也可能会有问题。net包在纯Go模式下会使用Go自带的DNS解析器，这个通常没问题。os/user包在纯Go模式下功能受限，如果你需要获取用户信息，最好避开这个包。
另一个坑是GOARM参数。对于32位的ARM路由器（比如一些老款的华硕型号），需要设置GOARM=7来指定ARMv7指令集。AX88U是64位的，不需要这个参数，但如果你用的是其他型号，一定要先确认CPU架构。用uname -m在路由器上执行，返回aarch64就是64位，返回armv7l就是32位。
3.3 依赖管理与二进制体积优化
Go的依赖管理用go mod就够了。我的项目依赖很少，主要是标准库，外加一个yaml解析库用来读配置文件。为什么不用JSON做配置？因为YAML写起来更直观，特别是流程定义这种嵌套结构比较多的配置。但YAML库会增加大概1MB的体积，如果你对体积极度敏感，可以换成JSON，标准库自带，零额外依赖。
体积优化的几个手段我按效果排序：第一是-ldflags="-s -w"，效果最明显。第二是用upx压缩，能把9MB压到3MB左右，但upx压缩后的二进制在运行时需要解压到内存，会增加启动时间和内存占用，路由器上要权衡。我最后没有用upx，因为启动时间从0.5秒变成了3秒多，对于常驻服务来说启动时间不太重要，但内存占用增加了大概10MB，在1GB RAM的路由器上还是能省则省。
第三是检查有没有引入不必要的包。比如你如果用了fmt包来做日志输出，可以考虑换成更轻量的log包或者自己写一个简单的日志函数。fmt包的格式化功能很强大，但也会增加不少体积。我最后把所有的fmt.Printf换成了自定义的log函数，体积又减了大概500KB。
3.4 在路由器上准备运行环境
路由器上需要准备的东西不多，但每一步都要小心，因为Flash空间有限。首先确认JFFS分区已经启用并且有足够空间。在Merlin固件的管理界面里，Administration -> System -> Enable JFFS custom scripts and configs要选Yes。然后SSH登录路由器，用df -h查看JFFS的可用空间。我的AX88U上JFFS总大小大概60MB，固件和一些插件占了之后还剩40MB左右。
创建目录结构：
mkdir -p /jffs/ai-orchestrator/bin mkdir -p /jffs/ai-orchestrator/conf mkdir -p /jffs/ai-orchestrator/logs把交叉编译好的二进制scp上去：
scp ai-orchestrator admin@192.168.50.1:/jffs/ai-orchestrator/bin/然后SSH上去加执行权限：
chmod +x /jffs/ai-orchestrator/bin/ai-orchestrator这里有个注意事项：JFFS分区在路由器重启后内容会保留，但如果你刷了新的固件或者恢复了出厂设置，JFFS会被清空。所以配置文件最好在本地也留一份备份，方便恢复。
4. 提示流编排器的核心代码实现
4.1 配置结构设计与YAML解析
配置文件是整个编排器的灵魂，它定义了有哪些AI后端、有哪些流程、每个流程包含哪些步骤。我用YAML来写配置，结构上分三个顶层字段：backends、flows和server。
backends字段是一个map，key是后端名称，value是后端配置。每个后端配置包含type（比如openai_compatible、ollama、http）、base_url、api_key、model等字段。flows字段也是一个map，key是流程名称，value是流程定义。流程定义包含steps列表，每个step有name、type、config、input_mapping、output_mapping等字段。server字段配置HTTP服务器的监听地址和端口。
backends: cloud_gpt: type: openai_compatible base_url: "https://api.example.com/v1" api_key: "sk-xxxx" model: "gpt-4o-mini" local_llama: type: ollama base_url: "http://192.168.50.100:11434" model: "llama3:8b" flows: daily_briefing: steps: - name: get_weather type: http_request config: url: "http://192.168.50.100:8080/weather" method: GET - name: generate_advice type: llm_call config: backend: cloud_gpt prompt_template: "根据以下天气信息，生成一段出行建议：{{.get_weather}}" input_mapping: weather: "{{.get_weather}}" output_mapping: advice: "{{.result}}" server: listen: "0.0.0.0:8090" log_level: "info"YAML解析用gopkg.in/yaml.v3，这个库很成熟，解析嵌套结构很方便。定义对应的Go结构体时，注意字段的yaml tag要和配置文件里的key对应上。我一开始因为tag写错了，导致配置解析出来全是零值，排查了好一会儿。
4.2 Backend接口与多AI后端适配
Backend接口的设计要足够抽象，才能适配不同的AI服务。我定义了这样一个接口：
type Backend interface { Call(ctx context.Context, prompt string, params map[string]interface{}) (string, error) Name() string }openai_compatible类型的后端实现，就是构造一个符合OpenAI Chat Completions格式的HTTP请求，发送到base_url指定的地址，解析返回的JSON，提取choices[0].message.content。这个实现可以适配所有兼容OpenAI接口的服务，包括各种云端API和本地部署的兼容服务。
ollama类型的后端实现，调用的是Ollama的/api/generate接口，请求体和响应格式跟OpenAI不一样，需要单独处理。http类型的后端最灵活，直接把prompt作为请求体POST到指定URL，把响应体作为结果返回，适合对接自定义的AI服务。
每个后端实现里都要处理超时、重试和错误。超时我设置的是30秒，对于LLM调用来说通常够用，如果超时了返回一个明确的错误信息。重试策略是简单的指数退避，最多重试2次。错误处理要注意区分网络错误和API返回的错误，前者可以重试，后者通常重试也没用。
4.3 Step执行引擎与流程控制
Step执行引擎的核心是一个递归的拓扑执行器。每个Flow的steps列表定义了执行顺序，但step之间可以有依赖关系。我用input_mapping来表达依赖：如果一个step的input_mapping里引用了另一个step的输出，那么它必须等那个step执行完才能开始。
执行器的逻辑大概是这样的：维护一个context map，key是step name，value是step的输出。从没有依赖的step开始执行，每执行完一个step就把输出放进context map。然后检查哪些step的依赖已经全部满足，继续执行，直到所有step都执行完或者遇到错误。
type StepResult struct { Name string Output string Error error } func (f *Flow) Run(ctx context.Context, input map[string]interface{}) (map[string]interface{}, error) { results := make(map[string]interface{}) completed := make(map[string]bool) for len(completed) < len(f.Steps) { progress := false for _, step := range f.Steps { if completed[step.Name] { continue } if !dependenciesMet(step, completed) { continue } output, err := step.Execute(ctx, results, input) if err != nil { return nil, fmt.Errorf("step %s failed: %w", step.Name, err) } results[step.Name] = output completed[step.Name] = true progress = true } if !progress { return nil, fmt.Errorf("circular dependency detected") } } return results, nil }这段代码里有个细节：dependenciesMet函数检查step的input_mapping里引用的所有step name是否都在completed里。如果是，说明依赖满足。这个设计简单但有效，避免了引入复杂的DAG库。
4.4 HTTP服务层与请求路由
HTTP服务层用标准库的net/http就够了，不需要gin或者echo这些框架。路由设计很简单：POST /flow/{flow_name}执行指定流程，GET /health返回健康状态，GET /flows列出所有可用流程。
请求体是JSON格式，包含一个input字段，里面是流程的输入参数。服务层解析请求体，找到对应的Flow，调用Run方法，把结果序列化成JSON返回。
func (s *Server) handleFlow(w http.ResponseWriter, r *http.Request) { flowName := strings.TrimPrefix(r.URL.Path, "/flow/") flow, ok := s.flows[flowName] if !ok { http.Error(w, "flow not found", http.StatusNotFound) return } var req struct { Input map[string]interface{} `json:"input"` } if err := json.NewDecoder(r.Body).Decode(&req); err != nil { http.Error(w, "invalid request body", http.StatusBadRequest) return } result, err := flow.Run(r.Context(), req.Input) if err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(result) }服务层还要加一些中间件：请求日志、panic恢复、简单的鉴权。鉴权用一个固定的token放在Header里，对于局域网内部使用来说足够了。日志用标准库的log包，输出到文件，配合logrotate做轮转。
5. Merlin固件集成与开机自启配置
5.1 JFFS分区目录规划与文件部署
JFFS分区的目录结构我规划成这样：
/jffs/ai-orchestrator/ ├── bin/ │ └── ai-orchestrator ├── conf/ │ └── config.yaml ├── logs/ │ └── orchestrator.log └── scripts/ ├── start.sh └── stop.shstart.sh的内容：
#!/bin/sh BIN=/jffs/ai-orchestrator/bin/ai-orchestrator CONF=/jffs/ai-orchestrator/conf/config.yaml LOG=/jffs/ai-orchestrator/logs/orchestrator.log if [ -f /tmp/ai-orchestrator.pid ]; then PID=$(cat /tmp/ai-orchestrator.pid) if kill -0 $PID 2>/dev/null; then echo "already running" exit 0 fi fi nohup $BIN -config $CONF >> $LOG 2>&1 & echo $! > /tmp/ai-orchestrator.pidstop.sh的内容：
#!/bin/sh if [ -f /tmp/ai-orchestrator.pid ]; then PID=$(cat /tmp/ai-orchestrator.pid) kill $PID 2>/dev/null rm -f /tmp/ai-orchestrator.pid fi注意PID文件放在/tmp目录下而不是JFFS里，因为/tmp是内存文件系统，读写速度快，而且重启后自动清空，不会残留过期的PID文件。
5.2 services-start脚本的编写与调试
Merlin固件在启动时会执行/jffs/scripts/services-start脚本。这个脚本的执行时机是在网络服务启动之后，所以可以安全地发起网络请求。但要注意，这个脚本执行时可能有些服务还没完全就绪，所以最好加一个短暂的延迟。
#!/bin/sh sleep 30 /jffs/ai-orchestrator/scripts/start.sh为什么是30秒？我实测下来，路由器启动后大概20到25秒网络才完全就绪，如果编排器启动太早，它尝试连接局域网内的本地模型服务时可能会失败。30秒是一个比较保险的值，如果你觉得启动太慢可以适当减少，但不建议低于15秒。
services-stop脚本：
#!/bin/sh /jffs/ai-orchestrator/scripts/stop.sh这两个脚本都要加执行权限：
chmod +x /jffs/scripts/services-start chmod +x /jffs/scripts/services-stop调试的时候有个技巧：不要每次都重启路由器来测试。可以直接手动执行services-start脚本，观察日志输出。如果启动失败，日志里通常会有明确的错误信息。
5.3 进程守护与日志轮转方案
路由器上的进程可能会因为各种原因挂掉：内存不足被OOM Killer干掉、网络异常导致panic、或者代码本身的bug。所以需要一个简单的守护机制。我的做法是用cron每分钟检查一次进程是否存活：
# 在/jffs/scripts/services-start里添加 cru a ai-orchestrator-guard "* * * * * /jffs/ai-orchestrator/scripts/guard.sh"guard.sh的内容：
#!/bin/sh if [ -f /tmp/ai-orchestrator.pid ]; then PID=$(cat /tmp/ai-orchestrator.pid) if kill -0 $PID 2>/dev/null; then exit 0 fi fi /jffs/ai-orchestrator/scripts/start.sh日志轮转用BusyBox自带的logrotate或者自己写一个简单的脚本。我的做法是在guard.sh里顺便检查日志文件大小，超过5MB就截断：
LOG=/jffs/ai-orchestrator/logs/orchestrator.log if [ -f $LOG ]; then SIZE=$(wc -c < $LOG) if [ $SIZE -gt 5242880 ]; then tail -c 1048576 $LOG > $LOG.tmp mv $LOG.tmp $LOG fi fi这个逻辑是保留日志的最后1MB内容，前面的截掉。简单粗暴但有效，对于路由器这种存储空间有限的环境来说够用了。
6. 常见问题排查与实战避坑指南
6.1 交叉编译与运行时报错速查
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 编译时报undefined reference | CGO未禁用 | 设置CGO_ENABLED=0 |
| 路由器上执行报No such file | 架构不匹配 | 确认GOARCH与CPU架构一致 |
| 执行报Permission denied | 没有执行权限 | chmod +x |
| 启动后立即退出 | 配置文件路径错误 | 用绝对路径，检查文件是否存在 |
| 请求超时 | 网络不通或后端地址错误 | 在路由器上用curl测试后端连通性 |
| 内存占用持续增长 | goroutine泄漏 | 检查HTTP客户端是否复用了Transport |
这个表格里的每一行都是我实际踩过的坑。特别是最后一条，goroutine泄漏在嵌入式环境里特别致命，因为内存本来就少。我一开始每次请求都创建一个新的http.Client，导致连接池无法复用，goroutine数量持续增长。后来改成全局共享一个http.Client，问题就解决了。
6.2 路由器存储空间不足的处理
JFFS空间不足是最常见的问题之一。除了二进制本身，日志文件也会慢慢吃掉空间。我的建议是：二进制用strip和upx压缩到最小，日志文件严格限制大小，配置文件尽量精简。如果实在不够用，可以考虑把二进制放在U盘上，通过Merlin固件的USB挂载功能访问。但U盘的读取速度比JFFS慢，启动时间会变长。
另一个技巧是把不常用的后端配置和流程定义拆分成多个文件，按需加载。比如把云端API的配置放在一个单独的文件里，只在需要的时候读取。这样主配置文件可以保持很小，减少解析开销。
6.3 网络请求超时与重试策略
路由器上的网络环境比服务器复杂得多，WiFi信号波动、DNS解析慢、上游服务不稳定，这些都会导致请求失败。我的重试策略是这样的：对于连接超时和5xx错误，重试2次，间隔分别是1秒和3秒。对于4xx错误，不重试，直接返回错误。对于DNS解析失败，重试1次，因为有时候只是临时的解析问题。
超时时间设置要区分场景。调用云端API时，30秒通常够用，因为云端服务响应比较快。调用局域网内的本地模型时，如果模型比较大，可能需要60秒甚至更长。我在配置里给每个后端单独设置超时时间，默认30秒，可以在YAML里覆盖。
6.4 提示流编排的调试技巧
调试编排流程最有效的方法是在每个step执行前后打日志。日志里包含step name、输入、输出和耗时。这样当流程出错时，一眼就能看出是哪个step的问题。
另一个技巧是提供一个dry_run模式，在这个模式下，step不实际调用AI后端，而是返回一个模拟的响应。这样可以快速验证流程的拓扑结构是否正确，而不需要等待真实的AI调用。实现方式是在配置里加一个dry_run字段，step执行时检查这个字段，如果为true就返回模拟数据。
if s.dryRun { return fmt.Sprintf("[dry-run] %s", s.Name), nil }这个功能在开发阶段非常有用，可以节省大量等待AI响应的时间。
6.5 安全加固与访问控制
路由器上的服务虽然只在局域网内暴露，但基本的安全措施还是要做。第一是鉴权，所有请求都要带一个token，token在配置文件里设置。第二是限制请求体大小，防止恶意的大请求打爆内存。第三是限制并发数，用一个带缓冲的channel做信号量，最多同时处理10个请求。
sem := make(chan struct{}, 10) func (s *Server) handleFlow(w http.ResponseWriter, r *http.Request) { sem <- struct{}{} defer func() { <-sem }() // ... }第四是不要在日志里打印API key和完整的请求体，只打印必要的调试信息。API key在配置文件里明文存储是不可避免的，但至少要保证配置文件权限是600，只有root可读。
7. 实际运行效果与性能观察
7.1 资源占用实测数据
在AX88U上运行了一周之后，我记录了以下数据：空载时CPU占用率在0.5%到1%之间波动，内存占用稳定在25MB左右。处理一个包含3个step的流程（一次HTTP请求加两次LLM调用），CPU峰值到15%，内存峰值到45MB，整个流程耗时取决于LLM后端的响应速度，编排器本身的开销大概在50毫秒以内。
二进制体积最终是8.7MB，JFFS分区剩余空间还有30MB左右，足够后续添加新的流程和配置。日志文件每天增长大概200KB，按照5MB的轮转阈值，大概25天轮转一次。
7.2 典型使用场景演示
我目前配置了三个流程。第一个是daily_briefing，每天早上7点由cron触发，获取天气和日历信息，调用云端LLM生成出行建议，推送到家庭群组。第二个是smart_reply，智能家居系统检测到有人按门铃时调用，根据访客留言生成几个回复选项。第三个是code_review，我在局域网内的开发机上写完代码后，调用这个流程让本地模型做一次初步的代码审查。
这三个流程覆盖了云端API调用、本地模型调用、HTTP请求编排、条件分支等不同的编排模式，基本验证了编排器的通用性。
7.3 稳定性与长期运行观察
一周的运行时间里，编排器本身没有崩溃过。唯一一次异常是路由器因为固件更新重启，services-start脚本正常拉起了服务。日志里有一些请求超时的记录，都是因为本地模型服务在加载新模型时响应变慢导致的，编排器的重试机制成功处理了这些情况。
内存方面没有观察到泄漏的迹象，一周下来内存占用曲线很平稳。这得益于http.Client的复用和goroutine的及时回收。如果你发现内存持续增长，重点检查这两个地方。
8. 后续扩展方向与个人体会
这个编排器目前还是一个比较基础的版本，但架构上留了不少扩展空间。比如可以加一个缓存层，对相同的输入直接返回缓存结果，减少重复的AI调用。可以加一个Webhook通知机制，流程执行完成后主动推送结果到指定的URL。还可以加一个简单的管理界面，用HTML加JavaScript做一个配置编辑器，不用每次都手动改YAML。
我个人在实际操作中的体会是，在嵌入式设备上做开发，最大的挑战不是代码本身，而是对资源限制的敬畏。每加一个依赖、每开一个goroutine、每写一行日志，都要想想这会不会成为压垮路由器的最后一根稻草。这种约束反而让代码变得更干净、更高效。另一个体会是，交叉编译和部署的自动化很重要，我后来写了一个Makefile，把编译、scp、重启服务串成一条命令，开发效率提升了很多。
最后分享一个小技巧：如果你在路由器上调试时发现二进制跑不起来，但错误信息很模糊，可以试试在开发机上用qemu-user静态模拟ARM环境来运行，这样能看到更详细的错误输出。安装qemu-user-static之后，用qemu-aarch64 ./ai-orchestrator就能模拟运行，配合strace可以看到系统调用层面的问题。这个手段帮我定位了好几次难以排查的运行时错误。
