/2,306 字/阅读约 8 分钟
从"事后看"到"事中拦"：给流量观测工具装上告警规则引擎
一个自维护的本机流量观测工具，被三次真实事故各推着长出一个能力：20 小时静默停摆催生看门狗，单日 124GB 上行催生代理哨兵，一次 207GB 事故催生"本机连接"面板。最新一轮把写死阈值的哨兵泛化成告警规则引擎：任意进程 × 可组合条件 × Web 配置。本文记录这条演进路径与三个设计决策：为什么只告警不处置、为什么规则要能解释、以及为什么出口必须能兜底。
共 4 篇
System-design
- /2,299 字/阅读约 8 分钟
不杀，先让路：内存守护的降级档是怎么长出来的
一台 32GB 的开发机长期在 10% 可用内存附近徘徊——"临界才杀进程"意味着天天在悬崖边保持不动。这一轮改版给守护脚本加了降级档：警告线以下不杀，先把最大的非前台进程降优先级、交还工作集；再加"你正在看的应用全家豁免"、和一次真实搁浅事故修出来的状态落盘。三个决策都不是设计阶段想出来的，而是上线后逐次事故长出来的。
- /2,659 字/阅读约 10 分钟
最后一道内存防线：内存守护脚本的设计取舍与真实战报
32GB 开发机被 Electron 全家桶吃干、一天在 3% 可用内存附近挣扎之后，我写了一个只做一件事的守护脚本：内存临界前杀掉占用最大的进程。难点不在杀谁，而在什么时候动手、谁不能杀、守护者自己死了怎么办。附真实战报与一次杀-重生循环的根因复盘。
- /1,617 字/阅读约 6 分钟
Agent 健壮性设计：工具调用与模型调用失败的容错与兜底
错误分类（确定性 vs 瞬时）→ 确定性错误回传模型自我修复、瞬时错误指数退避+随机抖动重试 → 多次失败熔断 → 按能力等级优雅降级（备用工具 / 业务降级 / 转人工）。模型侧另需识别「API 返回成功但业务结果错误」的潜在失败，并在切换备用模型后持续评估。