那天傍晚六点零九分，我发了一句话工单。
“API连不上了，你去检查一下。”
九分钟后，修好了。
但真正让我后背发凉的不是这九分钟，是它前面的六十八分钟——那个成员从下午五点零一分就开始全链路报错，到我把工单派出去，中间整整一个小时零八分钟，整支军团没有一个成员知道，没有任何一条报警，没有任何一个哨兵拉响。
它是瘫着的。
绿灯亮着。
我说“你去检查一下”，其实是在替整套系统认错：本该机器先叫，结果是我先叫。
修的过程很快。查容器、查网关、查日志，九分钟定位：上游平台改了模型代码，主链路开始报“模型不存在”，于是流量掉进备用链——而备用链的那把钥匙，压根没写进这个成员自己的配置文件里。主路一抖，备用路是个空壳，全链 401，成员哑掉。
一个成员，两层保险，两层都是纸糊的。
更难堪的是修完之后。我把这次事故顺着日志往下挖，挖出三层真相，每一层都适用于全部十三个成员：
第一层，上游会抖。模型服务平台批量调整模型代码，这不是阴谋，是常态。你挡不住上游，你只能保证掉下来时有东西接住。
第二层，接住的那层从来没被测过。备用链从配置那天起，一次都没有被真实触发过。配置文件里写着它，监控里看不见它，演练里没有它。它是写在纸上的灭火器。
第三层，钥匙在漂移。同一把钥匙有多份独立拷贝，散在各成员自己的配置文件里。给一个成员配了，不等于给其他成员配了；配置里引用了，不等于文件里存在。没有任何机制保证它们同步。
六十八分钟、九分钟、三层纸糊的保险。
我那天晚上没有睡好。不是焦虑，是算账：如果这次瘫的不是最闲的那个成员，而是正在对外服务的那几个呢？如果上游抖的是白天而不是傍晚呢？如果我不在家呢？
军团这个词，我说了很多次。那天我才承认：我有的是一群会干活的成员，没有一支有后勤的军队。
军队打仗，从来不是靠士兵多勇。靠的是后勤线。
粮草、岔路、名册、哨兵。
这四样补齐之前，成员数量只是故障的放大器。
这篇文章就是那四层后勤线。全部是我自己机器上真跑过、真炸过、真修过的东西。参数给全，你可以直接抄，也可以拿去检查自己的军团。
先杀掉三个旧信仰
在讲四层之前，先埋掉三个我曾经真心相信的东西。它们不是蠢，它们曾经是对的。所以才危险。
旧信仰一：模型越强，军团越强。
错。军团强度的瓶颈根本不在单个模型的智力。一个成员再聪明，它的钥匙配错一样全哑；备用链再华丽，没触发过一样是纸。军团强度取决于最弱的那层后勤，不取决于最亮的那个模型。
旧信仰二：要扩容，就多开账号。
我曾经给每个成员都挂外部接口，以为这就是规模化。这次事故把这张账单拍在我脸上：外部接口意味着整支军团的生命线握在上游手里，上游改一次模型代码，我就得挨个成员翻配置。成员越多，翻得越久。这不叫扩容，这叫把单点故障复制十三份。
旧信仰三：本地跑大模型，消费级硬件不配。
这个信仰我杀得最疼，因为我亲自给它交过学费。我最早按参数量选型，挑了个又大又全的稠密模型搬上机器，实测每秒七点八个字。七点八。你对着它说一句话，它想想再回你，像越洋电话。那台机器不是不行，是我违反了物理。
物理是什么？往下看。
粮草层：速度是带宽决定的，不是参数
先讲清楚一件事，很多天天聊模型的人其实没算过：
本地推理的解码速度，先算一道除法。
模型每生成一个字，都要把它“激活”的参数从头到尾读一遍。所以：
每秒输出字数 ≈ 内存带宽 ÷ 每 token 需要读取的字节数
就这么朴素。带宽是分母上的固定资产，你买什么硬件它就定多少；分子上你能动的只有一个变量——每 token 读多少字节。
稠密模型没法动这个变量。270 亿参数就是每 token 读 270 亿参数，量化到 4 比特也还是那么多字节，卡在带宽上就是七点八个字。这不是优化问题，是天花板问题。我当时不该骂机器，该骂自己没做除法。
MoE 把这个变量劈开了。
混合专家模型的架构是：总参数量很大，但每个 token 只激活其中一小部分——比如一个总参 350 亿、激活 30 亿的模型，每 token 真正要读的只有 30 亿参数的权重，剩下 320 亿在旁边站着，这个 token 用不上。
注意这个魔法的本质：“模型存了多少”和“每个字要读多少”，第一次解耦了。
存储靠硬盘和内存，便宜、量大管饱；带宽靠显存和内存通道，贵、就是那么宽。MoE 等于让你用便宜的存储囤一支庞大的专家队伍，每次只请真正被点到名的那几位上场。专家下沉技术把这个思路推到极限：
- 注意力层、共享专家、KV 缓存——这些每个 token 都要用的，驻进显存；
- 路由专家——那些被按需点名的，整批放在系统内存；
- 每 token 只把被激活的少数专家从内存搬进显存算一下。
llama.cpp 里就是一行参数的事：–n-cpu-moe 24 表示最上面 24 层的路由专家放内存。真实效果是有人在一张 12G 显存的消费级卡上，把 35B 总参的 MoE 模型跑到 17 万字上下文、稳定每秒六十个字。12G 显存，跑 350 亿参数。搁三年前这是笑话，现在是 README 里的标准操作。
为什么专家下沉能成立？因为路由不是均匀的。社区里有人给 MoE 的激活做过画像，结论很硬：解码时专家的点名高度偏斜，基尼系数零点七六，而且相邻两个 token 有百分之四十四的概率点同一批专家。翻译成人话：专家有冷热，热的就那几个，冷的常年没人理。 把冷的放内存里睡觉，一点不亏；热的反复被搬进显存，PCIe 总线喂得饱。后来甚至有人做了显存里的专家缓存，命中率稳定后速度又翻了几倍——同一张 8G 卡，纯 CPU 卸载一秒半个字，加了缓存一秒十几个字。
这就是我说的“按带宽养，不按参数养”。
再加一味料：MTP，多 token 预测，工程上叫投机解码。原理不玄：让模型自己先草拟接下来两三个字，主模型一次验证，验证通过就整批收下。因为草拟的字也要过主模型的数学检验，输出和逐字生成在数学上等价——这不是牺牲质量换速度，是白捡速度。实测数据摆在这：一张 16G 的消费级卡，27B 模型不开 MTP 每秒五十四个字，开 MTP 之后九十四个字，提升百分之七十三，代价是零点六个 G 的显存。
注意甜点：草拟两个字收益最大，草拟六个几乎不再涨——因为瓶颈转到了验证算力上。参数不是越大越好，连投机解码的参数都不是。
到这里，粮草层的账算完了，给你抄的结论：
- 选型先做除法：拿你硬件的内存带宽，除以候选模型“激活参数 × 量化位宽”，商就是你的理论每秒字数，除不上去的别碰；
- 稠密大模型在消费级硬件上没有前途，这不是信仰是物理；
- 低激活 MoE + 专家下沉 + MTP，三个乘数叠起来，消费级硬件就能养出交互级速度。
军营经济学：并发才是军团的真指标
单机速度只是粮草，军团要算另一本账：并发分摊。
单个成员对话，每秒二十个字就够用——这是交互体验的及格线，再快你的眼睛也读不过来。军团的算法完全不同：十三个成员同时干活，每个都要二十，加起来就是二百六。这时单流跑分一百的模型，作为军团底座反而不够看。
反过来看一个真实数字：有人在小型一体机上跑这个级别的 MoE 模型，单流每秒六十八到七十个字，同时开十六个 Agent 并发，聚合吞吐三百八十五。除一下：十六个成员同时干活，每个还分到每秒二十四个字。
二十四个字，刚好卡在交互及格线上面。
这就是本地底座的经济账：一台机器、一个模型、十六个成员并发，每个成员的速度还够用。对比给十六个成员开十六份外部接口的账单，这笔账怎么算都不用犹豫。
所以我的军团架构现在分两级：
- 日常层：成员的对话、工具调用、日常巡检，走本地 MoE 底座。速度够，成本为零，数据不出门。
- 攻坚层：重活、长链路复杂任务，升级到最强的外部模型。外部接口从“生命线”降级成“特种装备”。
分级不是拍脑袋，我定了三条可执行的路由标准：
- 按链路长度分。三步以内的任务——查个状态、改个配置、回句话——本地层包了，这类任务量化模型成功率不输外部接口，没必要烧配额。五步以上的长链路任务，先本地跑一遍，成了记下，败了自动升级攻坚层重跑，并把失败样本存下来——这些样本就是你下一轮“二十遍成功率”测试的题库。
- 按隐私等级分。碰配置、碰钥匙、碰内部数据的任务，永远不出本地门，外部接口再强也不行。这一条不是效率条款，是主权条款。
- 按可验证性分。任务结果能被机器自动验证的（测试通过、命令返回零、文件哈希对得上），放心交给本地层跑，错了会自己暴露；结果要靠人眼判断质量的（长文、方案、对外承诺），升级攻坚层。可验证的活不需要聪明的模型，需要的是老实的验收。
这个路由跑顺之后会出现一个副产品：你会攒下一份自己军团的“任务-成败”台账。哪个成员、哪类任务、哪个模型、成功率多少，一目了然。到那时，选型不再靠发布帖和信仰，靠自己的账本。这才是本地底座真正的复利——不是省了几个 token 的钱，是你终于有了别人没有的数据：你自己的活，什么模型干得最好。
生命线必须握在自己手里，特种装备可以租。这个分级还有个隐藏好处：外部接口的调用次数暴跌，配额、限额、上游抖动，这些过去的日常噩梦，现在只是攻坚层的偶发摩擦。
但注意，这套架构成立有一个前提：本地底座不能是个跑分漂亮的花架子。这就接到岔路层了。
岔路层：备用链路必须被触发过一次
现在回到那次事故的第二层真相：备用链配了三个月，一次都没被触发过。
我后来去翻了业界把故障切换做到生产级的开源网关文档，人家把这个当成宪法级的常识，白纸黑字三条：
- 先重试，再切换。主路失败，先在同一路径上重试几次，别把一次网络抖动升级成一次链路切换。切换是有代价的，不是免费的。
- 失败要冷却。刚失败的路径进冷却期，路由自动绕开它，别让下一个请求又撞上同一堵墙。
- 最重要的一条：fallback 配置必须在非生产环境主动触发一次验证。文档原话的意思就是——把主路人为弄坏，然后发一条正常请求，亲眼看着它掉到备用路、再亲眼看着备用路把活干了。
第三条是我们全缺的。我们的备用链是静态配置：文件里写了，系统信了，从来没人看过它到底通不通。等上游真抖的那天，备用链第一次被真实触发，也是第一次暴露它没钥匙。
这就像消防演练从来不做，演习当天下楼才发现安全通道堆满了杂物。
我的补法很土，但闭环：
给每条备用链做一次“断路演练”。在低峰期，人为禁用主路（改配置或断掉该成员的外部接口），然后从该成员的正常入口发一条真实任务，全程盯着三个观察点：
- 流量真的掉到备用链了吗？（没掉，切换逻辑是坏的）
- 备用链的钥匙真的能用吗？（401，就是这次事故的死法）
- 任务真的完成了吗？（有响应不等于干了活）
三问全过，才允许这条备用链在配置里标“已验证”，否则标“纸糊”。演练记录留档，任何人改动链路配置，状态自动降回“纸糊”，必须重新演练。
演练频率也定死：每季度一次例行断路，任何一次上游真实抖动之后加练一次。备用链是肌肉，不练会萎缩——配置文件不会变，钥匙会过期，模型代码会被下线，你上一次验证通过的世界，已经不是这一次要应对的世界。
升级演练也照此办理。我后来给每个容器化成员建了升级机制，流程是死的：升级前一致性备份、锁死镜像版本号、只动这一个成员、跑验收清单、任一项不过就回滚。第一次真实演练就抓到一个端口冲突——新旧版本都报同样错误，说明那雷不是新版埋的，是一直都在，只是从没人做过升级演练。机制立起来的当天，雷排掉了。
岔路层的结论一句话：没被触发过的备用链，等于没有备用链。写在配置里的可靠性不是可靠性，是被验证过的可靠性才是。
名册层：钥匙必须只有一个真源
第三层真相最隐蔽：钥匙漂移。
事故里那个成员，配置文件里写着“我要用这把钥匙”，但它自己的环境文件里根本没有这把钥匙。钥匙存在于别的成员的文件里。十三个成员，一人一份环境文件，同一把钥匙被手工复制了 N 份，没有任何机制保证它们一致。
这是典型的配置漂移，而且是最危险的那种——因为它平时完全不表现。主路通着的时候，谁也不碰备用钥匙；主路一抖，你才发现名册上写着的人根本不在营里。
业界的标准解法几十年前就有了：密钥集中管理，按需声明式下发。核心三条：
- 单一真源。每把钥匙只存一份，在一个受保护的 主文件里，权限收紧到只有管理者能读。
- 声明式分发。每个成员声明“我需要哪几把钥匙”，启动前由同步机制从真源把钥匙注入它自己的环境，需要几把给几把——最小权限，不搞人手一份万能钥匙。
- 缺失拒启。声明的钥匙在真源里不存在？启动失败，大声报错，拒绝半死不活地起来。
容器化环境里这套特别顺手：初始化脚本在任何服务启动之前跑，正好做“同步钥匙 → 校验完整性 → 不全就拒启”这三步。改一处，全体生效；新增成员，声明即得；钥匙轮换，真源一改，全员下次启动自动跟上。
这套东西落地之后，“手动给某个成员补钥匙”这种事就永远不需要再发生。因为名册只有一份，营里每个人要么都在册，要么启动时就会喊出来。
名册层再往深一步是身份。这次事故让我意识到，一个持续运行的成员，它的身份不只是名字和记忆，还包括它“醒来后必须能读到的那几个文件”。配置、状态、配对资料，这些东西散在哪儿、归谁管、断了谁先知道——这是名册层的另一半。我的原则现在很硬：成员的生存必需品放本地持久盘，共享存储只放可再生的交换材料。你的心脏不能挂在别人家的电线上。
哨兵层：一次两万，一次二十
修完那天晚上，我翻验证记录，看到一个数字差点笑出声。
我修完之后验证那次修复，是对着成员自己的接口发了一句“回复两个字：收到”。返回的账单写着：本次消耗两万零三百四十一个输入 token。
两万个 token，验证一句“收到”。
为什么？因为打成员自己的对话接口，系统会把它的完整上下文——记忆、技能、历史——全部构建进去。等于为了量个体温，把人全身 CT 做了一遍。
而同样这次验证，绕开成员上下文，直接拿同一把钥匙对模型端点发一模一样的五个字，成本是多少？
二十个 token 左右。
一千倍。
这个数字差就是我哨兵层的设计依据。健康检查有两个铁律：
铁律一：哨兵必须直连，不许经过成员的上下文。哨兵测的是“钥匙能不能开模型这扇门”，不是“这个成员聪不聪明”。用最小请求打端点，五个 token 封顶，别把体检做成全身体检。
铁律二：哨兵必须覆盖全部链路，包括备用。只盯主路的哨兵是这次事故的翻版——主路绿灯，备用路空壳。哨兵要对每个成员的主链和全部备用链各发一条独立探针，任何一条非正常返回就报警。
哨兵的成本账：十几个成员、每人两三条链路、每小时一轮、每条约二十五个 token——一天五千 token 上下，一个月十几万 token，按本地底座算成本为零，按外部接口算也就是几杯咖啡。对比那次六十八分钟的失聪，这笔钱是白捡的。
哨兵的排布我定成三班：
- 实时哨：每分钟一轮进程级检查——活着吗。便宜，抓硬死。
- 小时哨：每小时一轮链路级探针——钥匙还能开门吗。直连、小请求、全链路覆盖。
- 日哨：每天一轮身份级自检——重启后能读到自己的配置和状态吗，能回一句带时间戳的确认吗，能完成一个只读小任务吗。
第三班就是复工检查，我单独说过它，这里不重复。三班哨兵各司其职，合起来保证一件事：下一次有成员瘫掉，是机器先叫，不是我先叫。
那次事故是六十八分钟。哨兵上线后，同类故障的发现时间上限是一小时哨的一轮间隔——六十分钟。实时哨把硬死压到一分钟级。这就是后勤线买回来的东西：不是不出事，是出事时你知道。
报警分级：哨兵最大的死法是被人关掉
哨兵建起来只是半件事，另一半是让报警一直有人信。
误报是哨兵的第一杀手。链路闪断三十秒、上游限流抖一下、探针自己超时——这些都会叫。头两次你会认真看，第十次你会烦躁，第五十次你会把报警群静音。从静音那一刻起，你的哨兵制度就死了，比没有哨兵更坏：没有哨兵你知道自己裸奔，静音的哨兵给你穿着铠甲裸奔的错觉。
所以报警必须分级，我定三档：
- 红：主链与备用链同时失败，或身份自检失败——成员确认失能。即时推送，允许叫醒人。
- 黄：单链失败但备用接住，或同一条链连续两轮失败——降级运行。进日报，不叫醒人。
- 蓝：单次抖动后自愈——只记数，不打扰任何人。
配套两条纪律：静默必须带过期时间，不许永久静音；每条报警必须带上下文——哪个成员、哪条链、错在哪一步、上一次同类报警是什么时候。不带上下文的报警等于让人半夜起床后再从零排障，那不叫报警，叫转嫁。
还有一条最容易被忽略：哨兵自己也要被哨兵盯。探针脚本是会坏的：环境变量改了、依赖升级了、接口字段变了，探针可能悄悄死掉，然后给你报一整年的“全部正常”。死掉的哨兵报平安，是所有监控系统里最安静的凶案。所以哨兵自身要有心跳：每小时哨自己也要上报“我还在跑、我上一轮真的发了探针”，连续三轮没有心跳，按红警处理。
点名册：断电那天才是真考试
后勤线还有最后一场考试，多数人从来没让它考过：整营断电重启。
日常的重启是有序的：停一个成员，修，再起。真正的考验是无序的——停电、搬迁、主机死机之后，电一回来，十几个成员、几层依赖、一堆本地服务，要按正确的顺序全部自己站起来，还都要通过自己的复工检查。
这不是理论风险。断电、死机、迁移，对一台长期服役的机器来说是必然事件，问题只是发生在哪一年。而大多数人的配置里藏着一个尴尬的事实：服务都设了自启，但依赖顺序没排。数据库还没起来，成员先醒了，读不到状态，按自己的逻辑判定“存储损坏”，然后开始走恢复流程——一顿操作把小事故放大成大事故。或者更常见：网关比网络先起，成员连不上模型，把钥匙错报成失效。
所以我的冷启动验收不是“开机后服务都在”，是一张真实的点名流程：
- 断电前：确认所有成员的生存必需品都在本地盘，没有谁的心脏挂在共享路径上；
- 粗暴断电：不优雅关机，直接断——因为真实停电不会给你保存现场的机会；
- 来电后：全程不碰键盘，只观察。谁先起、谁等谁、超时的怎么办；
- 逐个点名：每个成员过复工检查——身份可读、链路可通、能回话、能干一件只读小活；
- 记录真实冷启动时长：从来电到最后一个成员复工，一共几分钟。这个数字要写进档案，它是你灾后恢复的能力上限。
第一次做这个演练，大概率会抓到东西：起不来的、起了但不回话的、回话但钥匙失配的、还有全家都活着但互相在等对方的死锁。全都要修，修完再断一次，直到断电变成一件“可以睡得着”的事。
军团的可靠性不是写在配置里的自启开关，是断电重来一遍之后，点名册上一个不缺。
跑分是绿灯，任务成功率才是复工
技术长文，最后必须泼自己一盆冷水。
前面所有参数——专家下沉、MTP、量化、并发分摊——全都是速度故事。而速度故事有个巨大的陷阱：官方跑分全部来自全精度权重，你本地跑的是量化版。
四比特量化对闲聊几乎无感，对长链路任务——一个 Agent 连续规划、调用工具、读报错、改方案的那种五步十步任务——是有真实折损的。别人的每秒六十个字是速度数据，不是质量结论。你拿量化版的跑分去对标官方全精度的能力，等于拿翻拍剧照对标原片票房。
顺便说透量化这件事，因为它是本地派最常自我欺骗的地方。量化本质上是用更少的字节存每个权重：四比特大约是十六分之一的原始体积，代价是每个权重都带一点存储误差。闲聊时这点误差被上下文平滑掉，你感觉不到；但在长链路任务里，误差会累积——第一步工具调用的参数错一个字，第二步就基于错误结果继续走，第五步的失败你根本查不到源头是量化。这叫误差的复利。
所以看量化报表要看两个数，不是只看体积省了多少：一看困惑度变化（模型整体还“懂不懂”语言），二看目标任务成功率（模型还“会不会干活”）。前者几乎不变，后者可能掉得吓人。社区里那些“量化后几乎无损”的结论，九成是用第一种测的。
所以我的验收最后一关不是 tok/s，是任务成功率，方法笨到没法再笨：
同一个五步真实任务，全精度版和量化版各跑二十遍，比成功率。
为什么是二十遍？因为个位数抽样的噪音太大——成功率九成的模型，连挂三次的概率并不罕见，你会把好模型冤枉死；二十遍之后，成功率的置信区间收窄到正负一成左右，够做决策了。任务要选你军团真实干的活，不要选玩具题——玩具题测出来的是背书能力，不是干活能力。跑的时候温度、提示词、工具环境全部固定，只换模型，不然你比的不是模型是运气。
速度达标、成功率掉太多，量化就没意义，换更轻的量化或者上攻坚层。速度慢一点但成功率稳，那才是真粮草。这套方法论也适用于选模型：新一代模型发布帖里那些漂亮的百分比，全部默认它是在全精度、理想提示词下跑出来的；你上机的第一件事不是复测跑分，是把你自己的五步任务跑二十遍。
这也把军团问题推到了终点：跑分是绿灯，任务成功率才是复工。单成员的速度上限再高，二十遍成功率上不去，它在军团里就是个快嘴低能儿，故障率会顺着链路传染给所有依赖它的兄弟。
四层后勤，一层都不能外包
回头盘点一下这套东西的全貌：
- 粮草层（算力）：按带宽选型，低激活 MoE + 专家下沉 + MTP，本地底座承接军团日常，外部接口降级为攻坚装备；
- 岔路层（fallback）：备用链必须断路演练过才配叫备用链，配置改动自动降级重验；
- 名册层（配置）：钥匙单一真源，声明式下发，缺失拒启，生存必需品放本地盘；
- 哨兵层（验收）：三班哨兵，直连小探针，全链路覆盖，日哨含复工检查，外加二十遍任务成功率的量化验收。
四层没有一层是模型能力，全部是工程。这也是我这次最大的认知更新：军团的天花板，从一开始就不写在模型发布帖里，写在你自己的后勤账本上。
而且我要预先承认这套东西的反噬，免得它变成新的迷信：
哨兵会误报，误报多了人会麻木，麻木的哨兵比没有哨兵更危险——所以报警必须分级、必须带上下文、必须可一键静默但要留痕。量化省钱省显存，但它伤长链路任务，你省下的每一分硬件钱都可能变成成功率里的暗账。本地化买回了主权，也把平台风险换成了硬件风险——一台机器现在绑着整支军团，它的硬盘、电源、散热都成了新的上游，冷启动演练一次都不能少。钥匙同步机制自己会成为新的单点，它坏的时候全员拒启，所以它自己也要有哨兵。
每一层保险，都会生出新一层需要保险的东西。后勤线不是修完的，是永远在修的。
回到那六十八分钟
现在再看我发那句工单的傍晚。
五点零一分，成员哑掉。绿灯亮着，没人知道。
六点零九分，我派单。
六点一十八分，修好。
现在同样的事故重演一遍，剧本是这样的：小时哨上一轮探针已经证明全链健康；主路抖动发生，流量按演练过的路径掉进备用链——备用链有钥匙，因为名册层保证它和主路同源；任务完成，哨兵记录一次成功切换，第二天日报里出现一行“昨日主路抖动一次，自动切换，无人工介入”。
我可能到晚上才看见这行字。
或者根本不用看见。
这就是后勤线全部的意义：不是让军团不出事，是让出事变成一件军团自己消化掉的小事，而不是一件等我发话的大事。
那天有人问我：现在让你建一支 AI 军团，还难吗？
当时的我大概会说：不难，容器一拉就是一个。
现在的我会先反问四句：
你的粮草算过除法吗？
你的备用链断路演练过吗？
你的钥匙有几份拷贝？
你的哨兵直连吗？
四问全答上来，军团才配叫军团。
答不上来，你养的只是一群绿灯。
我还想补最后一句。这四层后勤线，看起来全是给机器修的，其实每一条都在修人——修我这个当家的。
粮草层的除法，逼我在下单买硬件之前先承认物理，不许用情怀骗预算。岔路层的演练，逼我把“应该没问题”这五个字从嘴里戒掉。名册层的单一真源，逼我承认自己手工复制钥匙的那天，就已经在给未来埋雷。哨兵层的直连，逼我承认那次两万 token 的体检不是系统的浪费，是我压根没算过账。
六十八分钟之前，我以为军团的能力等于成员的智商。六十八分钟之后我才知道，军团的能力等于它的后勤，而后勤的上限，是当家人愿意把多少“下次再说”变成“这次就验”。
机器不会自己变可靠。是人先可靠了，机器才有机会。
最后，给你的军团留一张点名表
如果你也在养一支 AI 军团，别先问模型榜单，先把下面这张表填完：
- 每个成员的主链路是什么，备用链路是什么？
- 主链失败时，备用链最近一次真实接住任务是什么时候？
- 每把钥匙到底有几份，谁是真源，谁负责轮换？
- 成员失能后，最迟多久能被机器发现？
- 报警响起时，能不能直接看到成员、链路、错误和最近一次同类故障？
- 整机断电重启后，成员能否在无人碰键盘的情况下全部复工？
- 本地模型的速度是跑分，还是你的真实任务成功率？
- 外部模型在你的架构里，到底是生命线，还是攻坚装备？
这八个问题，如果有一个只能回答“应该可以”，那一项就还没有完成。 这张点名表还有一个用法：每次新增成员、换模型、换钥匙、改路由、升级镜像，都重新填一次。旧答案不能证明新配置，昨天的绿灯也不能替今天担保。真正能留下来的不是某次漂亮跑分，而是一套任何成员接手都能重复执行的验收动作。军团越大，这张表越不能靠人脑记；能写进机制的，不留给记性，能交给机器叫醒的，不等人偶然发现。
所以，别把成员数量当规模，别把配置存在当可靠，也别把一次成功当长期有效。
别相信绿灯。
相信演练，相信点名，相信真实完成过的那一次任务。
