企业官网建设流程全解析

第 22 篇：推理引擎服务上线之后：状态、守护、重启（零门槛入门系列）

上一篇：第 21 篇《为什么大家都兼容同一个接口》 ｜ 下一篇：第 23 篇《怎么证明"内容没被改过"：哈希与标准答案》

关键词：推理引擎入门、大模型推理、守护进程、看门狗、管理面、状态、重载

前一篇把服务这层壳立起来了。可只要它真的上线，下一个问题立刻出现：它会挂。挂掉之后，有没有人发现、有没有人把它拉起来、以及你想知道它现在什么状况时，去哪里看？这一篇讲的是同一件事的两面：自动守护和人工管理。

① 一句话概念

上线之后，拼的是"它挂了谁发现"。

② 起点：一家店开张之后

一家店开张那天，最显眼的是收银台——客人排队、钱进钱出。但真正让店能开下去的，是收银台之外的三样东西。

第一是值班经理。他不上手收银，他每隔一阵就走一圈：灯还亮着吗？后厨还有人吗？后厨如果没人了，他立刻把班次补上，让店继续开。他不关心今天卖了多少，他关心"现在是活的"。

第二是监控屏。屏幕上几行字：现在开着吗、开了多久、备货还够不够、刚才有没有报过警。这些字不需要漂亮，但缺了它们，你就只能靠猜。

第三是应急流程：真出事了按什么顺序处理、找谁。流程的意义是——不靠当班那个人的心情。

收银台是"业务"，这三样是"运维"。业务做得再好，没有值班经理，一次意外就能让店关一整晚。而且他盯的是这家店的命，不是某一个订单；判断依据也不只是"店里看起来有人"，而是"后厨真的还在出货"。

③ 伪代码：守护循环 + 管理面

如图 1 所示：左边是一条守护循环——检查引擎是否活着，挂了就拉起，然后隔一段时间再查；右边是给人看的入口——管理面（状态、配置、动作），动作指的是触发加载 / 转换 / 重载。

图 1守护进程 + 管理面：左侧是守护循环——每 N 秒检查一次"引擎进程还活着吗"，不在了就重启，再沿"一直守着"回到开头；右侧是给人看的入口——管理面（状态 / 配置 / 动作：触发加载、转换、重载），它和左边的循环是两条独立的线：守护在后台自动跑，管理面由你手动调用。

函数 守护循环(引擎名, 间隔秒): 当 真: 若 进程不存在(引擎名): # 名字要精确匹配，别认错人 启动(引擎名) 每隔 间隔秒 再检查 # 看状态接口，不只看进程表 # 管理面（人手动调用的入口） 读状态() -> { 是否在跑, 已运行时长, 缓存占用, 最近错误 } 改配置(项, 值) -> { 是否成功, 是否需要重载 } 触发重载() -> { 是否成功, 用时 }

逐行要点

• 当 真:：守护本身是一个死循环，跟第 20 篇的服务循环是同一个形状，只是它管的不是请求，而是另一个程序的命。
• 若 进程不存在(引擎名):：这里的判断要精确。“引擎名"匹配错一个字，就会出现两种坏结果——把别的程序当成引擎（守护成了摆设），或者永远以为它还活着（其实早挂了）。拉起来之后也别马上又判一次，先等它把启动做完，否则会刚拉起就判它"不在”、无限重启。
• 每隔 间隔秒 再检查：不能只看进程表。进程在、但已经卡住不出货，进程表照样显示"活着"。所以要看状态接口的返回——那才是"还能干活"的证据。
• 读状态() / 改配置() / 触发重载()：这三条是运维的眼睛和手。能不停服改配置，就不要停；改完要求重载的，如实告诉调用方。
• 一个克制的边界：自动拉起要有限度。程序反复崩时，无脑重启会变成"重启风暴"，连日志都看不清——这类策略属于实现细节。

④ 纸笔实验（必做）

题目：设计 3 条管理接口——状态、配置、重载。每条写出它需要的请求字段和响应字段，各不超过 4 个字段。

一个参考答案（只写字段名，值由实现填）

① 读状态 请求: （无，或一个"要不要详细"开关） 响应: { 是否在跑, 已运行时长, 缓存占用, 最近错误 } ② 改配置 请求: { 配置项, 新值 } 响应: { 是否成功, 是否需要重载 } ③ 触发重载 请求: （无） 响应: { 是否成功, 用时 }

自查清单

1. 三条接口里，"状态"是不是只读的？只读接口永远不该有副作用。
2. 「改配置」的响应里有没有"是否需要重载"？没有它，调用方不知道下一步该做什么。
3. 字段数是否都 ≤ 4？字段一多，接口就难稳定。

这一步要体会的事：接口设计不是写得越全越好，而是恰好够回答一个问题。状态接口回答"现在还活着吗"，配置接口回答"我改了没有"，重载接口回答"改完生效了吗"。三个问题，三张表。

可选 REPL 版

状态={"是否在跑":True,"已运行时长":"...","缓存占用":"...","最近错误":None}配置={"配置项":"最大长度","新值":"..."}重载={"是否成功":True,"用时":"..."}print(list(状态),list(配置),list(重载))

用列表把字段名打印出来，逐个核对是否和上面三张表一致。

⑤ 进阶锚点

进阶锚点：本篇概念在《30 天手搓推理引擎》Day 22里被真正实现——
22-1 chat.html：前端如何消费 SSE/22-2 /admin API：状态、配置、加载、转换/22-3 vllm_mgr.py：进程守护与看门狗。
入门版到这里就够了；进阶版会多出：守护脚本与管理接口的真实源码位置、一次 admin 状态页的实测返回（口径见进阶系列与仓库 docs），以及"进程名精确匹配"这类真实踩坑。
想动手 → 仓库https://gitee.com/pei-xiaoguang/kestrel-llm，从 Day 1 开始。

下篇预告：怎么证明一段内容"没被改过"——从指纹这件小事说起。