vLLM 内网离线部署：脱敏后的服务端与客户端脚本
前面整理这套 vLLM 私有源部署方案时，我把重点放在了思路复盘上。这次换个更直接的版本：不改原始脚本文件，只做脱敏，把服务端部署脚本和客户端部署脚本的可公开版本贴出来，方便自己归档，也方便后续复用。
先说明一下边界：仓库里的原始脚本我没有修改，这篇文章里的代码块是单独整理出来的脱敏版本。处理方式主要是把内网 IP、固定端口、默认账号、硬编码 API Key 以及过于贴近生产环境的目录替换成占位写法，保留脚本结构和部署逻辑。
分类 筑码 下的文章
把经验写进项目：AI Coding 如何用文档、技能和工具摆脱上下文依赖
很多人用 AI coding 一段时间之后，都会遇到同一个问题：刚开始很好用，但项目一复杂、上下文一长、对话一断开，体验就迅速下滑。模型并不是突然变笨了，而是项目本身没有把“该知道的事情”沉淀下来，导致每次协作都像重新开工。
所以，AI coding 真正要解决的，不只是提示词怎么写，而是怎样把项目知识、约束、流程和工具组织进仓库里，让 AI 不再严重依赖即时上下文。换句话说，重点不是“如何喂更多上下文”，而是“如何让项目自己带着上下文”。
本地化 AI Agent 平台落地：模型、MCP 与运维系统的连接方式
很多团队在谈 AI Agent 落地时，最先想到的往往是“接一个大模型，再连几个工具”。但真正做进本地环境以后，很快就会发现问题不在于模型会不会回答，而在于这套系统能不能接进真实工作流：能不能接 IM，能不能调本地工具，能不能访问内网资源，能不能区分开发、测试、生产环境，能不能把动作和审计收进现有运维体系。
所以，本地化 AI Agent 建设真正要解决的，不是“让模型更像人”，而是把模型、工具、上下文、权限、执行和观测拼成一条可持续运行的链路。只有当 Agent 能稳定接入模型服务、MCP、技能包、工具包和企业内部平台，它才会从一个 Demo 变成一套基础设施。
从点状工具到体系协同：一套运维体系化建设思路
很多团队在运维建设早期，往往都是“先把工具装起来”：日志上 ELK，可视化上 Grafana，指标监控上 Zabbix，网络流量用 sFlow，配置备份交给 Oxidized，资产管理再补一个 NetBox。单看每个工具都没问题，但真正到了线上，最常见的问题反而不是“工具不够多”，而是这些工具彼此之间没有形成闭环。
体系化建设的关键，不是再继续加工具，而是先回答清楚三个问题：什么是权威数据源，什么负责实时观测，什么负责变更留痕。只有资产、日志、指标、流量、配置和告警被串成一条统一链路，运维平台才会从“工具集合”变成“可持续运转的系统”。
用 Oxidized 自动备份网络设备配置文件
网络设备的配置备份，最怕的不是“没有工具”，而是设备数量慢慢变多以后，备份动作开始依赖人工记忆：有人改了交换机配置却忘了留档，有人调了防火墙策略却没有版本记录，真到回滚和排障的时候，才发现手上没有一份可信的基线。
Oxidized 这类工具的价值，就在于把这件事做成一条自动化流水线：定时登录设备、抓取 running-config、检测变更、写入 Git 仓库，并通过 Web 界面或 API 做统一查看。对中小规模网络来说，它足够轻，落地成本也很低。