OLAV 快速上手：网络数据进,答案出 —— 全程本地模型

这是精简版:从一台干净机器到一次经过校验的网络变更,只需几步,全程跑在本地 ~30B 模型上 —— 不上云,而且(如果你愿意)完全不需要 SSH 到生产。以下所有步骤都在一台机器上完成,并已在 gemma4-31b 上端到端验证。

模型:请使用 gemma4-31b

这里每一步都跑在 gemma4-31b 上 —— 一个本地、支持视觉的 ~30B 模型(QAT Q4 量化)。这是我们推荐的模型,而且当前只推荐它:更小的 “flash”/tiny 模型在 agent 任务上会失控(测试中某模型在同一任务上调用了 146 次工具,而 gemma4 只用 16 次)。请用 gemma4-31b —— 不要用更小的。

在本地以 OpenAI 兼容端点提供服务。我们验证过的上下文配置(llama.cpp server)是 64K 窗口 + 量化 KV cache 以塞进显存:

# gemma4-31b-it-qat —— 验证过的 server 参数
--ctx-size 65536          # 64K 可用上下文(训练上限 256K)
--cache-type-k q8_0       # 量化 KV cache,让 64K 装进显存
--cache-type-v q8_0
--batch-size 1024
--ubatch-size 256
# 推测解码,提升吞吐(推荐):
--model-draft gemma-4-31B-it-qat-assistant.gguf
--spec-type draft-mtp --spec-draft-n-max 3

在 .olav/config/api.json 里把 OLAV 指向它:

{
  "llm": {
    "provider": "openai",
    "model": "gemma4-31b-it-qat",
    "base_url": "http://<你的-host>:11433/v1",
    "api_key": "local",
    "timeout": 600
  }
}

第一步 —— 安装并自检

mkdir ~/olav && cd ~/olav
python3 -m venv .venv && source .venv/bin/activate
pip install olav "olav-netops[sim]"   # [sim] 拉取 pybatfish,后面变更校验会用到
olav agent install olav-netops        # 部署网络 agent;首次运行会问一次 LLM key
olav doctor                           # 9 项零-LLM 检查 —— 全部 ✓

olav doctor 在你提问之前,就先证明整条链路是通的 —— agent、子代理、工具、记忆、召回、workspace 完整性。运维会信任一个能自诊断的工具。

第二步 —— 把设备数据导入(两种方式)

OLAV 需要网络状态进它的快照数据库。有两种导入方式,按你的环境挑一种。

方式 A —— 在线 SSH 采集(Nornir)

把 OLAV 指向你的设备,让它自己去采。先声明清单:

cp .olav/workspace/netops/collector/config/nornir/hosts.yaml.example \
   .olav/workspace/netops/collector/config/nornir/hosts.yaml
cp .olav/workspace/netops/collector/config/nornir/defaults.yaml.example \
   .olav/workspace/netops/collector/config/nornir/defaults.yaml
chmod 600 .olav/workspace/netops/collector/config/nornir/defaults.yaml

hosts.yaml —— 设备清单:

R1:
  hostname: 192.168.100.101
  platform: juniper_junos
  groups: [border, juniper_junos]

R2:
  hostname: 192.168.100.102
  platform: cisco_ios
  groups: [core, cisco_ios]

defaults.yaml —— SSH 凭据(已 gitignore,切勿提交):

username: your_ssh_username
password: your_ssh_password
port: 22

然后运行初始化流水线(先用 --dry-run 校验):

olav --agent netops "/netops_init --dry-run"   # 环境 + 清单检查,不 SSH
olav --agent netops "/netops_init"             # SSH 采集 → 入库 → ETL → 拓扑

/netops_init 会按平台下发命令(IOS 走 show ip interface brief、show cdp neighbors detail 等;Junos 走 show interfaces terse、show lldp neighbors 等),解析它们,并自动从 CDP/LLDP 构建拓扑。

方式 B —— 离线导入(无需接触设备)

不能 SSH 到生产?把一份采集导出或备份归档丢给 OLAV,剩下的它来:

olav --agent netops "Import the network backup at <备份归档路径>.tar.gz"

importer 会解压、归一、解析(TextFSM)并构建拓扑 —— 数百台设备零设备接触就落进数据库,因此对生产备份运行也很安全。

第三步 —— 创建一次新快照

状态会过期。要按需重新抓取实时数据,启动 TUI 并让 collector 采一次新快照:

olav          # 启动交互式 TUI

给 R1 和 R2 采一次新快照

collector 会并行下发 show 命令(Nornir),对照命令白名单校验,把结果写入快照库。之后你的每一个提问都读这份最新状态。

第四步 —— 用大白话提问,拿到 CSV

直接敲进 TUI —— 默认编排器会路由:

我们导入了多少台设备,都是什么平台?
列出每台设备的型号和管理 IP,并导出为 CSV

自然语言问题被转成对已解析清单的 SQL,并落一份真实的 exports/*.csv。不用学查询语言,数据精确 —— 不是编出来的。

第五步 —— 画核心拓扑

把核心网络拓扑画成 draw.io 图

在 diagrams.net 里打开生成的 exports/diagrams/core_topology_*.drawio —— 一张范围收敛、准确的拓扑(真实邻接、厂商图元),可以直接贴进 Confluence。

第六步 —— 起草变更,再正式校验

先把校验引擎拉起来,再让 netops 起草并校验 —— 全程在 TUI 里用 /workspace 切换:

/workspace services
部署 batfish/allinone,端口 9996 9997
/workspace netops
写一份变更计划,内容为 <在这里描述你的变更>

把 <在这里描述你的变更> 换成你的真实需求 —— 比如新增一个 BGP peer、一个 VLAN、一个接口,或一条冗余上联。配置层校验建议聚焦 BGP/OSPF 这类变更,Batfish 对它们建模最好。

这一条请求会扇出成三段堆叠、各自经过验证的内容:

草案 —— analyzer 读取设备真实的 running-config(不是模板),找到真实状态,产出镜像式 CLI + 回滚,存到 exports/change_plans/。
预检 —— 对照实时状态做设备/接口/IP 合理性检查,外加一个独立的爆炸半径数字(“移除它会孤立 N 个节点”)。
正式验证 —— 子网/重叠冲突、协议兼容性、可达性,在 agent 自己部署的 Batfish 上核验。

一个 AI 能从一句话里既写出变更、又把它正式证明成立,这已经是另一个品类的工具了。

第七步 —— 晨检

/workspace audit
跑 interface_health 审计 profile,把发现给我

一个 Profile(一份带严重度规则的 SQL 健康检查 YAML)会被确定性地对状态库执行,返回一段执行摘要外加一份存档报告(exports/audit_reports/*.md + 一份 findings JSON)。Profile 是纯文本、可版本化的文件:工程师审阅、扩展它,并用 olav cron 排期 —— 就是你 NOC 每天早上跑的那套巡检,但以可审计的产物形式存在。

这就是全程

本地 30B 模型。设备数据进来 —— 走 SSH 或从备份 —— 出来的是:答案、一份 CSV、一张拓扑图、一次经过校验的变更,以及一次晨间 NOC 巡检。不上云,不用盯着。

OLAV 基于 BSL-1.1 开源 —— github.com/james-olavai/olav。