我们说过任何 Agent 都能跑这些 Skill——这次换了个不是 Claude Code 的

上一篇讲这两个包的文章最后留了一句当时没有真正验证过的话：

“这个包是以 Claude Code 的 skill 目录形式发布的，因为那是我们自己在用的东西。但每个脚本做的事就是从 stdin 读一个 JSON 对象、往 stdout 打一个 JSON 对象——没有绑定任何框架。任何能执行 shell 命令的 agent runtime，都能驱动同一套脚本。”

这是一句可以被验证的话,不是一句营销话,所以我们去验证了。这次没有再用 Claude Code——用的是 pi-agent，另一家厂商做的 coding-agent CLI，自己的模型路由,跟 Anthropic 的 Agent Skills 工作唯一的关系就是同样遵循 SKILL.md 的发现约定。如果这两个包真的把自己的依赖闭包带全了、真的说的是一套跟框架无关的协议,那换一个完全不同的 runtime 应该也能直接冷启动认出来。

环境故意搭得很不友好

一台裸的 Ubuntu 24.04,没装过任何 OLAV,没有 Node.js,除了系统自带的什么 Python 包都没有。我们按普通人会做的方式装 pi-agent——nvm install --lts，然后 npm install -g @earendil-works/pi-coding-agent——再把它的 skill 发现目录指向一次普通的 pip install：

python -m venv .venv && . .venv/bin/activate
pip install -r requirements-lean.txt
pip install ./runtime
cp -r skills/* ~/.pi/agent/skills/

这个场景里完全没有 OLAV 服务端的影子。驱动 pi-agent 的模型是 DeepSeek，不是 OLAV 自己默认用的那个——在”不是这家厂商自己的 agent runtime”之上，又加了一层”也不是这家厂商自己习惯用的模型”。

第一层：它能不能看到这些 skill

pi --provider deepseek --print '列出你现在能看到的所有 skill，只要名字'

analyst
analyzer
designer
explorer
importer
learner
netops
presales
publisher
reporter
surveyor
topology
writer

13 个名字，全对，一个不多——olav-skills 的 7 个代理加上 olav-presales-skills 的 6 个。不算多惊艳，但这是后面一切的前提，也是一次装得有细微问题的安装最容易悄悄失败的地方。

第二层：它能不能正确跑一个脚本——包括跑失败的时候

pi --provider deepseek --print \
  '用 analyzer skill 的 describe_table 脚本查一下 netops.devices 这张表，把它返回的内容原样报出来'

对着一个空数据库：

{"error": "table not found: 'netops.devices'", "hint": "Try schema-qualified (e.g. 'netops.devices' or 'main.v_interfaces_auto')."}

这里有意思的不是这个答案，是这个失败的样子。如果报的是 ModuleNotFoundError，说明 runtime 没装对；报出一个带提示的、结构化的”没找到”，说明 Python 包正确解析了、DuckDB 连上了、脚本正常跑完了——只是还没有这张表而已。开头这十分钟能不能分清这两种失败，决定了要不要继续往下测。

第三层：一个真实任务，路上撞见一个真 bug

我们额外加了一个不在两个精简包里的 skill——collector，那个直连设备的代理，两个包设计上就故意没带它，因为它需要 netmiko 和真实的 SSH 凭据——把 nornir 指向 containerlab 上 8 台真实跑起来的 Cisco IOL 节点（双园区,各自内部跑 OSPF,两个核心之间跑 eBGP）。然后就一句话,没给步骤清单：

“用 collector skill 从全部 8 台设备采集最新数据——show version、接口、CDP 邻居、路由、OSPF 邻居、BGP summary。如果遇到表不存在的报错，自己去读 olav_netops 的源码找到正确的修法并应用。然后用 reporter skill 调查这个网络的健康状况，导出一份结构化报告。”

第一轮确实撞上了那个报错：

Catalog Error: Table with name devices does not exist!

没有人告诉它该怎么办。它自己去读了 olav_netops/core/tables.py 和 olav_netops/core/device_etl.py，找到了 TableRegistry.ensure_all_schemas()——跟平台自己的 /netops_init 用的是同一个调用——应用之后重跑了一遍采集（第二轮自己把并发数从 8 降到 2，因为第一轮撞上了实验室设备的 VTY 连接数上限），然后接着去写报告。

它写出来的报告是真的好，不是”demo 意义上的好”：

8/8 设备在线、44/44 接口 up、4/4 OSPF 邻接 Full、4/4 eBGP 会话 Established——这些数字我们后来独立从同一个 DuckDB 文件里查过，完全对得上。
它自己把两个拓扑视图拿来互相核对，发现 v_l2_links_auto 报了 36 条链路，而 v_show_cdp_neighbors_detail_auto 报了 72 条原始记录（对应同样的 8 条物理链路加一个共享管理网段），并且明确指出该以哪个视图为准——这是一个没人要求它查的数据质量发现。
它正确把”access 层交换机不跑 BGP/OSPF”归类为正常现象，不是故障。弱一点的 agent 会把每个非成功响应都当 bug 报——分清”这台设备本来就不跑这个协议”和”东西真的坏了”,正是这些 skill 本该承担的判断,而它在完全没人插手的情况下做对了。

它排出来的五条发现——access 层单归属、每个园区只有一台汇聚设备、核心互联是唯一的冗余路径、管理网段是一个没做隔离的共享 VLAN、点到点 OSPF 链路上多余的 DR/BDR 选举——正是一个工程师看到这套拓扑会写下来的那些结论。我们核对过。

这次证明了什么，没证明什么

证明了”跟框架无关”这个说法：换一家厂商的 agent runtime、换一个模型 provider，两个包一行代码都没改，skill 发现、单脚本执行、以及一次撞上真 bug 还能自己扛过去的多步骤自主调查——全都跑通了。olav-presales-skills 这次只做了跟 netops 侧一样的”能发现、能跑单个脚本”级别的验证，没有像 netops 侧那样让它走一遍完整的售前工作流，所以这条结论故意留窄一点，不夸大。

没有证明这两个包能自给自足做所有事。collector 那些直连设备的脚本是设计上就没放进两个精简包的——真要连上活的设备,需要额外装完整的 olav[agent]/olav-netops[device],这条边界上一篇 collector 的文章里已经画清楚了。这次也完全没碰到任何 embedding 后端——这不是缺陷,是这两个包按文档说的那样在工作：一个整个功能就是向量检索的脚本,会被直接排除在打包范围外,而不是打包进去却悄悄跑不动。

拿一个我们没写过的 runtime 试试

pip install ./runtime
cp -r skills/* ~/.pi/agent/skills/     # 或者 ~/.claude/skills/，或者你的客户端认的任何目录

github.com/james-olavai/olav-skills

上一篇说的是”这些包跟 Claude 没有绑定”。这一篇就是那句话的实证。