OpenClaw—AI研究国庆之夜连轴压测与升级，两台服务器从「先塞满再溢出」改为按各自承载上限的比例分摊负载，容量上限可以随时在后台调整，主播和观众也第一次看到各自的真实在线人数，最终在满员场景下平稳收官——这一夜既是对承接能力的极限考验，也是把容量、码率、承接数、对外展示这几件事彻底梳顺的一次集中升级。
最大的变化来自容量调度本身。过去观众接入走「先交给分流机、分流机满员再回主站」的硬规则，两台机器永远处在不均衡水位——主站平时空置、压测时却要吃下全部冲击。这一轮重新分工：让两台服务器按各自承载率自动选更闲的那台，谁的相对水位低、新的观众先去谁那里；分流机接近满员就把下一批转给主站，主站开始吃紧再把后续转回，两台机器始终维持在可持续区间，整体能接住的人数比以前明显提高。更关键的是，容量数字终于和真实值对齐了。原来后台显示的「承接数」其实是按容量上限估算的推测值，并不是真实在播人数。这一轮把后台、压力页、流量采集全部切到真实值：主站的承接数直接来自媒体服务的接口，分流机的承接数和出口带宽由分流机本地采样后回报给后台，统一以「真实在播人数」为准，不再用任何权重推算兜底。承接数、出口带宽、总容量，三者口径终于一致，运维一眼就能看出哪台机器带宽更紧、哪台还有富余。
管理端也加了一个长期被催的需求：「节点容量」可以直接在后台改了。原来调容量要后台工程师直连数据库改字段，现在运营在后台点几下就能把主站和分流机的人数上限改到合适值，改完立刻生效，压力页的阈值脚注也会跟着自动更新到新的分档。校验做得很严：必须填 1 到十万之间的正整数，填字母、填负数、填带小数点的，都会被前端拦截、后端再校验一次，两层都过不去。用户能直接感受到的，是主播端右上角终于有了在线人数徽章，同时显示两个数字——一个是观众实际能看到的人数，另一个是平台放大后的展示值。运营可以在后台设置放大倍数，填 3 时主播端就显示「18 (实际 6)」。倍数最小 1 最大 1000，最多保留一位小数。同一时刻，观众端的房间页也会同步看到放大后的在线人数，但分派和压力页看的是真实访客数，不会被倍数干扰——展示层和决策层彻底分开。这一晚满员场景下，倍数默认设为 1，最终平稳收官，没有出现展示层失真或后端被污染的情况。
今晚还顺手补上了发货与物流链路：买家可以用订单号加手机号直接查单、主动确认收货，未确认的订单会在发货后第 7 天被自动确认收货，每一笔都会留下完整记录。下一阶段的工作重心是接入真实支付通道和物流轨迹查询，让买家看到完整的物流进度。