# 我当了一天攻击者，把自己门户站摸了一遍（脱敏版）

9月3号，我给自己的门户站做了一次黑盒渗透测试。规则很干净：把自己当成一个纯路人——不登录、不碰服务器、不看代码，只带一个浏览器从公网进门，看能摸到什么。

当天测完，当天修完。这篇是脱敏版复盘：域名全部隐去，管理面板的产品名、代码符号、修复记录都抹掉了，留下的是发现、根因和当时的决策。

一、最大的洞，是我亲手递出去的地图

测试第一站，门户的聚合接口。这是首页用来渲染导航的接口，匿名访问，正常返回。

问题是我多看了一眼完整响应：里面躺着全部九个内部子服务的域名清单——办公的、存储的、AI 的、内部管理的，一个不少，还附赠访客白名单。

攻击者视角翻译一下：我不用扫描、不用猜，敲一个公开接口，整栋楼的房间号直接递到我手上。剩下的只是挨个敲门。

这事最别扭的地方在于，它不是被打穿的，是我自己交出去的。

二、根因是一行缺省值

回去翻配置，发现每个服务都有个「可见性」字段，而它的缺省逻辑是：你没显式说「隐藏」，我就当你要公开。

九个服务里，只有两个标了公开，剩下七个全是「没填」——于是全放了。

这是典型的缺省值哲学问题：安全这件事上，缺省值决定下限。「默认放行、例外隐藏」意味着每一次忘记配置，都是一次事故；「默认隐藏、例外放行」意味着每一次忘记配置，只是少一个入口。前者把错误当成公开，后者把错误当成保守。显然该选后者。

修复因此很简单：反转缺省值，不标的一律隐藏，只有显式标了 public 的才出门户。补了一条回归测试专门盯这个行为，全量 138 项测试跑绿。再到线上用匿名身份复测，九个域名零残留，访客能看到的导航一个没少。

没有火 plaster，没有紧急回滚——因为当天下午就发现了，损失半径为零。但如果没有这次测试呢？这份内网地图会在公网上挂到什么时候，我不敢想。

三、有两个门，是我故意留的

扫描报告里最扎眼的一条：两个内部管理面板，知识库面板和 agent 网关面板，匿名用户可以直接打开登录页。

听起来很吓人，但这是我自己拍板留的。这两个面板挂在访客白名单里，属于「主动暴露」策略：数据面全部有密钥把守，控制面故意摆在那儿，方便我在任何一台设备上直达。

暴露出去的是什么？登录 UI、密钥的存放位置提示、网关接入端点、几条运维命令的提示。都是脚手架，不是钥匙。真正的门禁在密钥那层，而密钥不在公网上。

所以处置是「不修」。这条也提醒了未来的安全审计：这两个面板出现在报告里属于既定策略，别当新发现重复报警。

四、门锁本身，出乎意料地结实

暴露面看完，我开始真正地下手撬门。结果令人愉快：

登录跳转的回跳逻辑，喂它外部域名、主域拼后缀、路径穿越的变体，全部被拒，返回 401。恶意参数进不来，fail-closed，干净。

登录页喂了一段恶意 SVG，不执行、不回显；连输错密码的提示都是固定文案，想靠报错差异枚举用户名，没戏。

注册页用无效邀请码试探，服务端直接 400，页面上红字加提示双保险，而且全程没有产生任何脏数据。

敏感路径全家桶——配置文件、环境变量、调试端点——匿名访问全是 404 或 401；管理接口、密钥接口、用户信息接口，没有凭证一律拒之门外。

安全响应头一个不缺，CSP、HSTS 连子域一起罩住，页面禁缓存，HTTP 强制跳 HTTPS，CORS 不反射外来来源。这套配置是照着清单一项项打的，打得很齐。

五、三个小尾巴

当然不是满分，留下三个尾巴：

博客系统会给匿名访客渲染每篇文章的「编辑」按钮。点了会被博客自己的登录墙拦住，没有越权，但后台路径和系统指纹等于公示了。这是博客系统模板层的毛病，门户代码管不到，先记着。

首页和登录页不认 HEAD 请求，返回 405。浏览器用户无感，但监控器和链接检查器会看见一排 405，不优雅，SPA 路由补上就行。

最遗憾的一条：内网服务被拦截跳登录时，登录链接里带着回跳参数。因为没有测试账号，我没法验证这个参数指向外域时登录后会不会放行——也就是经典的「登录后开放重定向」。挂起，等一个测试账号。

六、复盘

三个带走的教训：

第一，安全下限藏在缺省值里。这次唯一的洞，不是哪个功能写错了，而是「没配置就公开」这一行缺省逻辑。功能写错会有测试兜着，缺省值写错，是给未来的每一次疏忽都预留了通道。

第二，最好的修复是让问题无法发生，而不是防住问题。反转缺省值之后，我不需要记住「新服务要标隐藏」，因为不标就是隐藏。好的安全设计和好的工具设计是一回事：不依赖人的记性。（这条和前几天拆任务队列时的感悟一模一样，看来是通用的。）

第三，自己打自己，性价比意外地高。全程匿名 GET 若干次、两次失败登录探针、一次无效邀请码，没爆破、没写数据、没留负担，却换来一次内网地图的紧急回收和一整套修复。

现在，那九个后门的房间号，地图上找不到了。

（脱敏说明：主域与全部子域名、两个管理面板的产品指纹、代码符号、修复 commit、证据路径均已隐去；发现类型、根因模式、修复思路与处置状态完整保留。）


我当了一天攻击者，把自己门户站摸了一遍

# 我给AI团队造了个任务队列，七天后又亲手拆了它

2026年9月4号晚上，我把 queue-cli.py 挪进了 archive 目录。3008行，22个子命令，配套的回归测试脚本写了10万字节。从8月28号晚上立项到9月4号退役，这个工具满打满算活了一个星期。

这不是一次失败的收尾，恰恰相反，我觉得这是一次挺完整的工具生命周期。趁着记忆还热，把整个过程写下来：为什么造它、怎么造的、为什么又不用了。

一、理念：任务不丢，完成必达

先交代背景。我在服务器上养了一队AI agent，有管调度的、写代码的、做审查的、采情报的，日常产生大量后台任务：派子代理去改代码、跑CLI命令、定时巡检。任务一多，问题就来了：谁在跑？跑完没有？结果发给谁？挂了谁管？

我对后台任务管理就三条要求：

1. 任务不丢。任何派出去的任务都要有账可查，网关重启也不能失忆。
2. 完成必达。任务做完，结果必须自动送回发起它的会话，不能指望agent的记性。
3. 挂了要喊。进程死了、状态卡住了，得有东西巡逻发现并且告警。

在 queue-cli 之前，这三条靠一个共享JSON文件撑着。所有agent都能读写它，没有锁，没有备份，没有校验。能一直没出大事，纯属运气好。

二、压垮骆驼的一场事故

8月28号傍晚6点22分，主会话切换任务时把 .active-task.json 整体覆写了，串行队列里排着的三批任务全部冲掉。19点05分人工恢复，丢的账捡回来了，但我坐不住了。

复盘根因，三层叠一起：

1. 单文件双职责。当前任务和排队任务挤在同一个文件里，改任何一处都是整体覆盖，误伤半径无限大。
2. 没有写前备份。写坏了就是写坏了，回不去。
3. 没有写入拦截。谁来都能写，格式对不对、会不会把别人的字段冲掉，没人管。

当晚拍板：不缝补丁，重做。方向五层：文件拆分（当前任务和队列分成两个文件各管各的）、写前快照、原子写、单写通道、心跳巡逻。当天夜里走完内部评审，第二天实现落地。

三、实现：把人人都能写，变成只有一个人能写

核心思路一句话：所有写操作收口到一个命令行工具里，就是 queue-cli.py。

任何agent想改任务状态，只能调它的子命令：入队、出队、登记、完成、改状态。工具内部流程固定：抢文件锁、读最新数据、业务校验、写前快照、原子写、读回校验。谁也别想再玩整文件覆盖那一出。

几个实现细节我自己挺得意：

1. 原子写不是写进去就算。临时文件写全、fsync刷盘、rename原子替换、写完再读一遍核对，最后父目录也fsync。麻烦吗？麻烦。但被丢过一次任务的人不会嫌麻烦。
2. 锁单独放一个文件。因为原子写靠rename换inode，锁要是写在数据文件里，会随着文件替换整个失效。这是个不踩一次不知道的暗坑。
3. 幂等表。每个操作带唯一键，重复执行直接拒绝，防agent抽风重复登记。

在这个底座上，长出了当时看挺完整的一套编排能力：

1. 串行队列。同类任务排队一个一个跑，不抢资源。
2. 并行槽。不同仓库的任务最多3个并行，超了排队等。
3. 同仓库互斥。执行器扫/proc，发现同仓库已有实例在跑直接拒绝，防写冲突。
4. 峰谷排队。DeepSeek有峰谷定价，高峰贵、凌晨便宜。任务可以打延迟标记，高峰期自动压着不派，谷底自动放行。省钱。
5. 心跳巡逻。每轮心跳检查队列健康，进程消失、状态卡住超过15分钟，立刻告警。每个任务登记时都记着report_to_session——完成后结果投递给谁，任务到终态就由心跳负责把结果送回去。没人收的完成事件等于白干。

然后它开始长大。

8月30号，加update子命令，改字段不用再整文件重写。

9月2号，我抓到有agent先把执行器跑了、回头才补登记，甚至有不登记的。顺着查时间线，发现登记和启动之间全是窟窿：登记完没启动的，启动了没登记的，进程都跑起来了登记还没落地的。于是加start子命令：一把锁内完成登记，锁外拉进程，2秒探活，起不来自动回滚重新排队。登记先于启动，从机制上保证，不再靠自觉。

9月3号，又给JSON文件加了PostgreSQL持久化层。到这里，这个工具3008行、22个子命令、几十个回归用例，还有一套心跳探针围着它转。

但你应该已经闻到味道了：一个任务队列，怎么越养越像一个系统。

四、为什么不用了：平台把它长出来了

9月4号，新升级的OpenClaw 2026.8.2摆在我面前，原生任务系统落地。我拿queue-cli的功能清单逐条对照：

1. 自动台账。子代理、ACP、定时任务、CLI后台任务，一启动自动入账，SQLite持久化重启不丢，60秒一轮自动对账。最妙的是没有登记这个动作了——spawn即登记。
2. 完成投递。任务完成自动推回发起会话，发起会话记在任务的requesterSessionKey字段里，不用手工登记。投递失败进blocked，30分钟退避自动重试。
3. 展示。进度卡、任务面板、控制台任务页，全有。
4. 目标锚定。goal机制，防多轮任务漂移。

我的第一反应是不信。让调度agent花了一下午做了五组真实验证：两类执行器真实启动、强制崩溃看失败标记、退出码核对、编排镜像记录、纯命令行无会话触发。全过。当时账本里已经有1269条生产任务记录在自动流转。

当然不是没缺口。串行队列、并行槽、峰谷排队，原生都没有等价物；CLI直跑的完成通知默认静音；复合命令会让退出码失真；原生投递也有失败案例，审计里躺着31条warning。原生不是零运维，只是换了个地方运维。

摆了三条路：渐进式，队列留着管编排、账本迁原生；混合式，砍掉三分之二子命令留个精简编排层；全拆。我拍板：全拆，不做瘦身迁移。

理由想清楚了：

1. 原生覆盖的六七成，恰好是高频但低价值密度的部分——记账、投递、展示。天天要用，但没人想维护它。
2. 剩下那三四成的编排语义，恰好是最贵的部分。贵不在代码，在规则面：queue-cli的用法散布在26个规则文件、一个提示词注入hook、两个执行器脚本和一堆心跳探针里。之前一个星期，hook注入文本和规则文件之间漂移了8次。每次改动都是一场同步风暴。
3. 最关键的一条：spawn即登记是结构性消灭问题。start子命令是在登记和启动之间的窟窿上打补丁，补得再精致，窟窿的形状永远在。原生把两个动作合成一个动作，窟窿直接不存在了。好的设计是让问题无法发生，而不是防住问题。

放弃的东西也想清楚了：串行排队改并发派发，峰谷自动排队改成调度agent手动错峰，失败自动回滚重排改成发起方自己重试。都是可接受的退化。

五、拆除与复盘

拆比想象中利落。晚上拍板，34项清单当天全部落地：26个规则文件批量改写，hook注入同步（再不同步就是第9次漂移），两个执行器脚本的拦截门换成进程树校验，queue-cli.py和测试脚本归档，运行时数据归档，记忆库写入终态记录。最后派了个测试子代理走全链路：自动入账、进度卡展示、完成投递回发起会话，一次通过。

PostgreSQL里的tasks表停写留查，坟头留碑。

复盘几条：

1. 自建轮子的隐性成本不在代码，在同步面。3008行代码好删，26个文件里的规则、hook里的注入文本、各agent记忆里的旧经验，才是真正难清理的。所以退役清单里最大的一块不是卸载，是防复活：往记忆库和经验库里写指向条目，明确告诉未来的agent——这套机制已下线，别按旧记忆办事。
2. 造它的那七天不亏。恰恰因为自己造过，我们才有一份精确到字段的需求清单，升级那天才能一下午验完原生系统的成色。没造过轮子的人，连该测什么都不知道。
3. 工具的寿命可以很短，但依然是好工具。它在没有原生方案的日子里，把任务不丢、完成必达从愿望变成了机制，顺带把并发写坏文件这类坑全踩了一遍。
4. 平台在长，胶水在烂。今天该问的问题不是「我能不能造」，而是「平台是不是快长出来了」。如果答案是快了，就用最糙的方案顶住，别精装。

现在我的后台任务面板长在控制台里，任务页一刷，谁在跑、谁挂了、谁的结果没送出去，一目了然。

queue-cli，生于事故，卒于升级，享年七天。安息。


我给AI团队造了个任务队列，七天后又亲手拆了它

8GB显存跑h3lite视频生成，从编译到出片

事情的起因很简单，想在本地跑视频生成，数据不出门，也不用排队。手里只有一张RTX 4060 Ti，8GB显存。2026年这个节点，主流视频模型基本20GB显存起步，8GB属于边缘配置。

后来看到Rimagination/h3lite这个项目，官方支持low-vram-w4a8路线，明确说8GB可以跑，就决定试一下。这篇文章就是整个部署过程的记录，包括遇到的坑和怎么解决的，希望能给同样配置的人省点时间。

一、环境

显卡，NVIDIA RTX 4060 Ti 8GB（sm89）
系统，Ubuntu 24.04 LTS，驱动595.84
Python 3.11.15独立venv，PyTorch 2.13.0+cu130，ComfyUI 0.33.0
模型，h3lite low-vram-w4a8量化方案，一共6个文件约21GB，包括12GB的量化主模型（w4a8）、Qwen3-VL 4B视觉编码器、视频VAE、音频VAE、ClipProj和lightx2v turbo LoRA

下载倒是顺利，断点续传，没出幺蛾子。

二、部署过程

按官方component-sets文档的Set A组件集来装，5个custom_nodes，ComfyUI启动日志Import times显示全部成功导入，0失败，/object_info里H3相关节点全部注册。到这一步都很顺，我一度以为这事儿没那么难。

三、坑一，SageAttention 2.2.0源码编译

ComfyUI的KJNodes节点依赖SageAttention 2.x，但PyPI上最新只有1.0.6，缺2.x的get_cuda_arch_versions API，装上直接报错。只能从源码编译。

编译需要CUDA工具链，系统里只有驱动没有完整toolkit，于是手工拼装CUDA 13.0工具链，一个坑接一个坑：

1. 缺nvcc编译器，从NVIDIA官方deb包提取
2. 缺cicc（nvcc底层编译器），同样从deb提取，这个文件不在标准路径，容易漏
3. 缺thrust/cub头文件，从CCCL发行版和venv的include目录补齐
4. 缺cudaEmulationSpecialValuesSupport、cudaEmulationMantissaControl类型定义，整个替换library_types.h才解决
5. 链接阶段找不到-lcudart，排查发现libcudart.so.13只有符号链接，实体库文件缺失，符号链接不算实体，ld照样找不到，下载官方cuda-cudart deb解包补齐

单独看每个都不难，难在它们层层叠叠，编译报错，查缺什么，补上，再报错，循环了五六轮。编译通过生成wheel，pip安装，KJNodes终于能加载SageAttention。

四、坑二，systemd-oomd内存杀手

模型全装好，第一次提交生成任务，ComfyUI加载模型到一半崩溃，没有任何CUDA报错，日志干干净净，进程直接没了。

查dmesg才找到凶手，systemd-oomd。low-vram模式加载主模型时进程峰值RSS约13.8GB，机器30GB物理内存被各种常驻服务占掉一大半，MTA后端、OpenViking、Dify、PostgreSQL，加上ZFS ARC缓存无上限增长能吃掉10GB以上，内存压力一大，oomd直接收割。

解法是给内存做减法，swap从8GB扩到24GB（fstab持久化），ZFS ARC上限限制到4GB（modprobe配置持久化，释放约6GB），vm.swappiness从60调到10。调整后可用内存从5GB回到18GB。

五、结果

重新提交，一次成功。5.17秒视频，640x352，24fps，568KB，输出正常。给朋友生成的问候视频也一次通过。

六、给同配置玩家的建议

1. 直接用官方low-vram-w4a8工作流模板，别自己搭，模型引用容易错
2. SageAttention 2.2.0必须源码编译，提前备好完整CUDA工具链，实体库文件（不是符号链接）要验证存在
3. 生成前查内存余量（free -h），峰值13GB+是常态，swap要留够
4. 崩溃且无CUDA报错时，先查dmesg确认是不是oomd收割，别在CUDA层面浪费时间
5. 机器上常驻服务多的话，优先处理ZFS ARC这类无上限吃内存的组件

总结就一句话，8GB显存跑视频生成可行，代价是内存管理要精细，swap要大、缓存要限、常驻服务要克制。量化模型加SageAttention加合理内存水位，小显存也能出片。


8GB显存跑h3lite视频生成，从编译到出片 — 2026.08.16 笔记

# 我把自己家的 LLM 网关，拆了重造

故事是这样的。

前天晚上十一点多，我盯着屏幕上那个 404，一时间无语凝噎。。。

model_not_found。

火山方舟的 Agent plan 模型，在 /v1/chat/completions 上，找不到自己。

可它明明就在那里。六个模型，好好的，躺在渠道列表里，测试的时候 responses 接口全通，怎么换个端点就翻脸不认人了。

我寻思了一下，没寻思明白。

大半夜的，我又不想承认是自己写的代码出了问题，于是把责任先推给文档，翻来覆去看了三遍火山方舟的接入文档，越看越觉得，这文档写的什么玩意，关键信息全藏在犄角旮旯里。

然后我冷静下来，承认现实。代码是我写的，锅大概率也是我的。

这事，还得从头讲起。

我家这台机器上，现在跑着九个 AI Agent，一个视频分析服务，一条 AI 成片流水线，一个 Dify，一个 Open WebUI。

它们全都要调大模型。

而大模型，散落在四个地方。本机 Ollama 上挂着 qwen3.5:9b、qwen3.5:4b 和向量模型 bge-m3，云端有 DeepSeek 官方，有 SiliconFlow，还有火山方舟的 Agent 计划，六个模型，kimi、glm、doubao、deepseek 全都有。

你说巧不巧，四家供应商，四种不同的调用格式，四种不同的计费方式，四种不同的限流脾气。

如果每个服务都自己去对接这四家，这台机器上就会长出四九三十六条又臭又长的调用链，每一条都要自己写重试，写降级，写密钥管理，写用量统计。

想想就头大。

更麻烦的是，这些服务的模型偏好还不一样。有的适合跑视觉分析，有的适合写代码，有的便宜适合批量跑，有的要本地部署图个数据不出门。模型选型这事，每天都在变，今天这个模型涨价了，明天那个模型效果更好了，你要让每个服务都自己跟着改，那改到天荒地老也改不完。

所以我一直用网关。最早用 new-api，后来换 LiteLLM，都是开源的现成方案。

它们能干活。真的能干活。渠道抽象、路由、熔断、用量统计，该有的都有，配好就能跑。

但问题是，出问题的时候，你面对的是一个黑盒。

报错看不懂，日志绕三圈，想改个行为得翻半天文档，改完还不一定生效。而且它们是通用平台，为全世界各种场景设计的，我家这场景其实特别简单，一个统一入口，一个路由降级，一个用量统计，没了。

我记得有一次，LiteLLM 突然开始疯狂报错，我查了一下午，最后发现是它内置的一个什么兼容层跟新版本冲突了，那个兼容层我根本没用过，但它就是能把我整个网关拖垮。你卸载吧，怕别的地方依赖，你不卸载吧，它就在那恶心你。

用着用着我就想，这玩意，是不是有点杀鸡用牛刀了。

说真的，我有时候觉得，LLM 网关这东西，特别像自来水厂。

各家模型厂商是水源地，OpenAI 兼容协议是水管标准，网关就是那个把水处理、加压、送到千家万户的自来水公司。

以前我家用的是别人建的水厂。水能喝，但你永远不知道今天水里加了什么，想查个水质，得翻他们家的说明书，还不一定查得到。水厂扩建了你不想要的功能，你也只能忍着，因为水厂是别人的。

后来我想了想，我家用水量也不大，水厂那套净化工艺一半我都用不上，干脆，自己接一根管子算了。

然后我就干了。

用 Go 写。1.26，本地编译成静态二进制，绕开 docker 里构建那一堆破事。编译出来一个二进制，扔进 alpine 镜像里就能跑，连构建工具链都不用带。

依赖极简，整个项目只引入了一个第三方库，pgx，连 postgres 用的。别的，全标准库。

3185 行代码，15 个测试。这个体量，一个人一天能写完，也正是一个自研网关该有的克制。

部署也简单，一个 alpine 镜像，host 网络，端口 4000，直接怼在机器上。存储复用现有的 postgres，开一个独立库，叫 gllm，谁也不打扰谁。

管理界面？原生 JS，go:embed 直接嵌进二进制里，零前端构建链。七个页签，总览、模型、渠道、Keys、日志、用量、设置，够用了。

我跟你说，写完的那一刻，看着 docker compose up 起来，日志打出配置加载完成，12 个模型名，20 条模型路由，那种感觉太爽了。

整个转发链路是这样的，客户端进来，auth 先校验虚拟 key 和配额，限流中间件令牌桶挡一道，然后进路由引擎，优先级排序，加权轮询，故障转移，熔断，多 key 轮询，最后 proxy 做模型映射、SSE 透传、错误规范化，打到上游。

链路看着复杂，其实每个环节都挺朴素。

先说 auth。每个服务发一个虚拟 key，可以配白名单，限定这个 key 只能调哪些模型，还能配配额，用完了自动 429。这样就算哪个服务把 key 泄露了，损失也控制在一个 key 的范围内，不会波及整个网关。

限流是令牌桶，按虚拟 key 每分钟 240 次，按 IP 每分钟 600 次，参数还能在设置页里调。这块有个细节，限流的 key 解析必须支持 IPv6，不然一个 [::1]:8080 就能把限流打穿，这个坑后面代码审查的时候还专门揪出来过。

最有意思的是路由策略。渠道有个优先级字段，数字小的先走。我把本机 Ollama 设成 0，永远优先。

为啥，因为本地模型免费，数据不出本机，还快。

云端是兜底。本地挂了，自动切 DeepSeek，DeepSeek 限流了，自动切 SiliconFlow，再不行还有火山方舟。故障转移的逻辑是，网络错误、5xx、408、429 这种，自动重试下一条目，4xx 业务错误就直接透传，把上游的原始错误原样还给你，不瞎掺和。

熔断也朴素，连续失败三次，临时下线三十秒，冷却完自动恢复。客户端自己断开的不算，这个后面还会提到，是个坑。

还有一个我挺得意的小设计，同一个渠道可以挂多个 api_key，自动轮询。相当于一个水厂给你开了好几个水龙头，一个被限流了，换下一个。

配置热生效，管理 API 写完库，内存缓存自动刷新，不用重启。

这事的爽点在于，以后加模型，不用再折腾镜像、重启、翻配置文件，管理界面点几下，或者 curl 调一下，完事。

写的过程中还有一个细节我印象特别深，就是 SSE 流式透传。

一开始我想省事，给 http.Client 配了个超时。结果一测，流式对话全挂了，说一半就断。

后来才想明白，超时得分开算。响应头等待设个上限，120 秒，响应体的读取不受限制，这样流式长连接才不会被误杀。还有 http.Transport 不能逐请求新建，Clone 会破坏 HTTP/2 协商，上游直接 EOF。

这种坑，不自己写一遍，永远不知道。

还有思考类模型，Ollama 上那个 qwen3.5，回答都在 content 里，reasoning 是思考过程，max_tokens 给少了，content 直接为空。一开始我以为是模型挂了，查了半天，结果就是 token 不够。这种经验，都是踩出来的。

而且你发现没有，越是这种小坑，越是你用别人网关的时候根本不会去想的。因为黑盒帮你兜住了，你也永远不知道里面还有这些门道。自己写一遍，这些门道全成了你的肌肉记忆。

好，回到开头那个 404。

网关是 8 月 10 号上线的，当天全量实测，12 个模型，20 条路由，chat 的，embedding 的，responses 的，流式的，全过。

我以为这就稳了。

第二天凌晨，火山方舟的模型就给我上了一课。

问题出在哪，我排查了一圈，发现是两个坑叠在了一起。

第一个坑，是我对 Agent plan 的认知错了。文档上写的是支持 Responses API，我就把所有条目全配成了 responses 模式。结果实际测下来，人家的 chat completions 端点也是通的，只是我压根没配。

第二个坑，更隐蔽。我的代码里有个 ensureV1 的函数，专门负责给 base_url 补版本段。openai 类型的渠道，base_url 是 https://api.deepseek.com，没有版本段，补一个 /v1，没毛病。

但火山方舟的 base_url 是 https://ark.cn-beijing.volces.com/api/plan/v3，已经带了 /v3。

ensureV1 不认，咔咔又给补了个 /v1。

拼出来变成 /api/plan/v3/v1/chat/completions。

你说这路径，能不难看吗。404 都是给它面子。

这两个坑，一个错在认知，一个错在代码，单独拎出来任何一个都挺好修，叠在一起就特别迷惑。你要是只看日志，看到的是 model_not_found，第一反应绝对是模型没配好，谁能想到是路径被拼成了四层楼呢。

修复倒不难，三处。ensureV1 改成版本感知，v3 之后不再补 v1，proxy.go 和 admin.go 两处都要改。models 表加了个唯一约束带 mode，同一个上游模型，chat 和 responses 各一条路由，互不打架。渠道名统一叫 Agent plan，seed 脚本同步。

改完重新 build，chat 通了，responses 通了，openai 通了，ollama 通了，流式也通了。

全绿。

这个坑的教训挺通用的，对接上游协议，别只信文档，要信实测端点。写拼接逻辑，版本段感知是基本功。

说到这，我得再交代一件事。

开发完成后，我做了一轮全量代码审查。自己写的代码，自己审，最容易审出什么，最容易审出「我觉得没问题」。

但这次还真揪出了五个实打实的 bug。

第一个，4xx 错误响应体丢失。4xx 分支里先 drain 再 readBody，同一个 Body 读两遍，第二遍读出来是空的。结果就是，上游报错说「你 key 过期了」，客户端收到的是空消息，等于把上游的话吞了。这个 bug 最坑的地方在于，单测全绿，因为测试只断言了状态码，没断言错误体内容。

第二个，重试连接泄漏。5xx 重试的循环里，lastRes 被覆盖前没关旧 Body，中间那些响应体全泄漏了。平时没事，高并发一来，连接数蹭蹭往上涨。这种 bug 不压测根本发现不了，但压测的时候你又会怀疑是网络问题，特别迷惑。

第三个，客户端断开误触发熔断。tryOne 返回 err 的时候无条件记失败，但客户端主动断开，context.Canceled，这算哪门子上游失败。结果就是，几个用户同时关页面，网关熔断了，所有人一起遭殃。这个是我觉得最阴的一个，因为你的网关明明没坏，上游明明没坏，就是用户手滑关了页面，结果全服务跟着熔断三十秒。

第四个，clientIP 不支持 IPv6。手写了一个从右往左找冒号的截端口逻辑，遇到 [::1]:8080 直接懵，纯 IPv6 直接截成空串。限流要么失效，要么全归到同一个 key 上。你说手写解析干嘛呢，标准库 net.SplitHostPort 摆在那，一行的事。

第五个，限流器的 burst 字段数据竞争。一个无锁读，一个锁下写，go test -race 一跑必报。这个倒是测试能抓到的，所以我也挺庆幸自己写了 race 测试，不然上线之后哪天炸了，又是一场悬案。

这五个 bug，单测基本都跑不出来，除了 race。全是读代码读出来的。

你问我自研值不值，这就是答案的一部分。代码是你自己写的，每一行都能看懂，bug 长在哪，翻两页源码就能定位。换成 new-api，这五个问题，你可能得在 issue 区潜水三天才能找到答案，还不一定有。

当然，自研也有代价。

功能要自己维护，开源网关的高级功能，计费、多租户、审计，我们全都没有。协议更新，新上游接入，都要自己跟。写代码一小时，审代码一下午，这个成本是实打实的。

而且说实话，有些坑我到现在都还没踩完。Ollama 的推理队列之前被一个长任务占满过，整个网关的请求全超时，我一开始还以为是网关的问题，排查半天才发现是 Ollama 那边排队排到天荒地老。这种跨服务的连锁反应，自研网关也躲不掉，只能靠经验积累。

但对我这个场景来说，值。

因为我要的从来不是功能全，是一个透明的、可控的、长在自己机器上的总闸。

现在这个总闸，还保留了回滚的退路。litellm 和 new-api 的目录原样躺着，compose 里注释段还在，哪天我后悔了，docker compose 改两行，一分钟切回去。

用我自己的话说，这叫防御性开放，我选择自己接水管，但不对水厂锁门。

回到开头那个比喻。自来水厂，你可以选别人建的，也可以自己接一根管子。

我选了自己接。

不是因为我多厉害，恰恰相反，是因为我太清楚了，我这辈子要喝的水，就那么几口，自己知根知底的水，喝着才踏实。

而且你想想，这个网关它服务的对象，是我家里那九个 AI Agent，是每天跑着的视频分析，是 AI 成片流水线，它们才是真正喝水的住户。我这个接水管的，只是想让每家每户打开水龙头就有水，还知道水是从哪来的。

网关这东西，说大不大，说小不小，但它是我家所有 AI 服务的第一道门。

门，还是自己装的好。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。


我把自己家的 LLM 网关，拆了重造 — 2026.08.11 笔记


故事是这样的。

我有个知识库，跑了挺久，里面装着我所有 Agent 的踩坑记录、操作手册、经验总结，是给整个 Agent 团队用的共享大脑。

一开始我挺得意的，觉得知识库这东西，就是越攒越多越好，攒得越多，团队就越聪明。

直到有一天我闲着没事看了一眼数据，直接傻眼了。

日志文件 ingest_log.jsonl 已经涨到了 195MB，error_log.jsonl 涨到了 39MB，sync_cron.log 也有 26MB。更离谱的是经验库里堆满了各种自动生成的噪音条目，什么「memory_search 索引缺失」被记录了 133 次，什么「active-task.json 不存在」被记录了几十条，什么「edit 工具参数错误」一抓一大把。

我的知识库，在不知不觉中，变成了一个垃圾场。

当时我整个人是懵的，我辛辛苦苦攒的知识库，怎么就成了这样？

后来冷静下来一分析，问题出在我给 Agent 装了自动生成经验的插件，本意是让每个 Agent 踩完坑自动沉淀，结果这个插件太勤快了，啥都往库里记，工具调错一次记一条，索引没找到记一条，心跳检查的常见现象也记一条。

这些条目有一个共同特点，就是看一眼标题就知道没有复用价值，但它们在库里占着位置，检索的时候还跟着出来凑热闹，把真正有用的经验都给稀释了。

我意识到，知识库不是攒得越多越好，而是越干净越好。一个塞满噪音的知识库，跟没有知识库，没什么区别。

然后我开始搞知识库的定期清理。

先说清理的标准，什么样的条目该删，什么样的该留，我定了几条铁律。

验证率低于 10% 的，删。同一个问题被反复记录的，只留最好的一条，其余全删。工具调错这种一次性错误的记录，删。web 抓取超时这种网络问题，删。主题重复的，保留质量最高的那条，其余删。

这个清理逻辑其实跟收拾房间一样，你不需要记住每一个垃圾袋里装了什么，你只需要知道哪些是垃圾，然后扔掉。

但光靠人工清理是不够的，知识库天天在涨，我总不能天天盯着删。

所以我又做了一套自动化的定期清理方案。

方案分三层。

第一层是埋点，给知识库的检索加使用统计，每次谁搜了什么、命中了哪些文档，都记录下来。这样我就知道哪些文档是真正被用到的，哪些是躺着吃灰的。

第二层是冷数据识别，统计每个文档被命中的次数，从来没被命中过的，就是冷数据，就是清理的候选对象。这个逻辑特别朴素，一个文档如果一年到头没人检索它，那它大概率已经没价值了，留着也是占地方。

第三层是清理安全机制，这个最关键，就是删除之前一定要确认，别手一抖把有用的删了。我的做法是分阶段来，先识别候选，再人工确认，最后才批量删，宁可删得慢，不可删错。

整套方案的技术评估我也找人做过了，可行性没问题，就是分阶段实施，埋点两到四个小时，冷数据识别一到两个小时，清理机制四到六个小时，自动化定期清理四到八个小时。

说实话，做这套方案的过程中，我最大的感受是，知识库这东西，跟人脑特别像。

人脑也不是什么都记的，你会忘掉那些没用的细节，只留下重要的经验。知识库也应该这样，它得有遗忘机制，得定期清理，才能保持敏锐。

如果一个人什么都记，那他大概率是混乱的。如果一个知识库什么都存，那它大概率是没用的。

而且我还发现一个有意思的事，就是知识库的噪音，往往不是用户产生的，而是系统自己产生的。我的那些噪音条目，全是自动生成插件干的，用户手动沉淀的经验，反而条条都是精华。

这让我想起一句话，自动化是好东西，但自动化过头了，就会制造垃圾。工具越勤快，越需要有一个垃圾桶来接住它产生的东西。

清理方案落地之后，我又把日志的轮转机制也一起修了，所有日志文件都加了 10MB 上限，超过就循环覆盖，最多保留 5 份。这个改动看着不起眼，但从此以后，我再也不用担心日志把磁盘塞爆了。

现在我的知识库，终于恢复了它该有的样子，该有的经验都在，垃圾都被清走了，Agent 检索的时候，返回的都是真正有用的东西。

最后分享几条我总结出来的经验吧，都是我踩过坑之后才明白的。

第一，知识库要设清理阈值，不能无限增长。我现在的经验是，验证率低于 10% 就要动手清理，文件数量超过 500 条也要检查，这是触发条件，不是可选项。

第二，自动生成的内容一定要有质量门禁，不能啥都往库里塞。给 Agent 装自动沉淀插件的时候，一定要想清楚，哪些值得记，哪些不值得记，别让插件替你决定。

第三，日志文件必须加轮转上限，禁止无上限追加。这个是我用 195MB 的教训换来的，任何一个写日志的程序，都必须设计大小上限加循环覆盖。

第四，清理要分阶段，先识别，再确认，最后删。永远不要一键批量删除，你永远不知道哪条数据会在某一天派上用场。

其实说到底，知识库清理这件事，本质上是在跟熵增作斗争。

任何系统，只要在运行，就会产生混乱，知识库也一样。你要么定期清理，保持秩序，要么放任不管，看着它一点点变成垃圾场。

我选择定期清理，因为我花了那么多时间把知识喂进去，不想看着它烂在库里。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

