本地 AI 助手能在不接管整张网络的情况下排查故障吗？

一家分公司报告说，电话能拨出去，来电却时常接不到。网络团队看到一条接口变更、一次路由事件和一连串超时。助手可以整理这些线索，再建议下一条只读命令。选什么模型只是其中一步。运维人员还需要知道工具能用哪些凭据、哪些文字会离开本机，以及模型能否触发变更。

Transit 是一款网络排查工具，于 2026 年 10 月 21 日将客户端纳入采用 Apache 2.0 许可证的开源项目。项目的过渡说明把 11 月 5 日列为年度访问权限的截止日，并计划在 11 月 17 日调整托管 AI 服务。这两个日期属于产品商业模式的过渡安排。软件是否可用和某个托管账户的状态要分别核实。确定要试用哪个版本时，应以项目的发布记录、README 和功能文档为准。

网络排查里的「本地」指什么？

选择模型端点。Telli.sh 原创示意图。

客户端可以使用 Ollama，也可以连接其他兼容 OpenAI 的端点。文档还介绍了使用自带的 OpenAI 或 Anthropic 密钥，以及符合条件的 ChatGPT Plus 或 Pro 账户登录预览功能。将 Transit 指向同一台机器上的 Ollama，可以把模型推理留在本机。选用企业端点时，数据会发往该端点。选择云服务商时，请求会按项目文档所述经过脱敏，再发给服务商。

客户端仍需要接触网络设备才能取证。一次排查可能涉及跳板机、只读运维账户和多台设备。模型端点位于本机，无法限制客户端能接触哪些设备。实际边界取决于网络可达性和凭据权限。

仓库文档列出了有限的工具范围，以及针对受支持厂商的命令允许列表。命令还受审批策略约束。在受支持的系统上，运维人员可以为匹配已配置规则的命令启用自动审批。团队可以分别测试脱敏和命令过滤。设备登录提示和日志都应当视为不可信文本，尤其是其中出现命令式语句时。助手可以概括内容，同时保持权限来源不变。

运维人员常检查的交换机与配线架。背景照片由 Dsimic 拍摄，已裁剪和缩放，采用 CC BY-SA 4.0。图片来源 · 许可证。

从一个已知故障开始试点

网络排查流程。Telli.sh 原创示意图。

搭建一个带有已知路由或接口故障的小型实验环境。只在目标设备上为工具提供最低权限账户，再加入一台应该始终无法访问的无关主机。让助手给出一个假设，以及几条能推翻假设的观察。审核并执行一条建议的查看命令，将输出与手动取得的同一项观察对照。

第二轮给出一个含糊症状。同一服务变慢可能对应多条网络路径上的问题，而真实设备的命令输出可能暴露客户标识。使用虚构标记值，可以检查输出被传送、记录或保留在哪里。在弄清各模式会暴露哪些数据之前，让实验网络与生产跳板机保持隔离。

导出结果时，在相关假设旁附上命令、时间、设备标识和相应输出。这样，接手的人可以审查证据链，不必回想哪句话来自路由器，哪句话来自模型。

如何校验发布文件，本地模型又有哪些限制？

Transit 表示，其发布的构建文件没有签名。每个版本的 SHA256SUMS 文件可以用来校验下载文件是否与公开的摘要一致。单凭校验结果无法确认发布者身份。若团队要求签名制品，可以评估通过自己的软件分发流程从已审核的标签构建。Windows 安装文档还注明需要 PowerShell 7。

本地推理可以减少对云服务商的依赖，适合一些限制数据共享的环境。较小的本地模型可能遗漏上下文、误读不同厂商设备的输出，或在现有硬件上耗时更长。如果政策允许，可以在本地配置和已获批准的托管配置中运行同一个已知案例。分别记录正确假设、无效命令、设备误判和运维人员的总耗时。

首次试用可以把工具限定为证据收集器，关闭自动审批，由运维人员逐条审核拟执行的命令。如果实验能稳定复现证据并产出经得起复查的报告，再决定哪些只读排查可以沿用这套流程进入生产环境。这个问题比是否让模型获得通用网络访问权更具体。

安装一个可确认的版本，记下它的权限边界

v6.5.11 修正了校验清单中的命名不一致，使条目与 GitHub 规范化后的文件名对应。明确选择版本和平台，运行安装程序前检查公开的校验和。先看发布说明，再从官方仓库取得文件。如果组织通过受管目录发放已获批准的软件，就遵循既有流程。摘要匹配用于校验文件，安装授权由组织流程决定。

README 介绍了六种排查工具。工具数量少，只有在运维人员知道每个工具能访问哪里时才有意义。授权之前，先列明模型端点、跳板机和唯一的测试交换机，并记录每条连接使用的账户。如果开发人员配置了单独的 Ollama 服务器，要查明客户端实际访问的地址。对于笔记本电脑来说，办公室网络上的服务仍然是外部目的地。

1. 创建一个症状已知的实验案例，使用权限限于目标设备的账户。
2. 校验所选构建版本，检查端点、凭据与数据保留设置。
3. 让助手建议下一项观察，并给出该观察能证伪的假设。
4. 在关闭自动审批的情况下拒绝一条建议，先检查设备日志，再批准另一条安全命令。
5. 在样例日志中插入无害标记值。检查客户端是否隐藏标记，以及标记是否出现在本地记录或配置的端点中。
6. 导出排查结果，让另一名运维人员凭记录复现诊断。

如果用户偶尔切换服务商，可以在配置变更后重跑这个练习。端点变化后，同一个按钮可能会走一条新的数据路径。在授权的实验环境中观察网络连接可以确认实际目的地。单凭一张设置截图，无法证明哪个端点收到了请求。

支持的交换机与通用 Shell 应分别看待

Transit 在相应版本标签下的威胁模型中描述了受支持厂商的命令策略，包括已启用规则匹配时可选的自动审批。试点可以关闭这个选项，要求运维人员逐条检查。工具仍然需要权限范围明确的设备账户。审批弹窗无法把服务账户变成最小权限账户。

同一份威胁模型对通用 Linux 和 Unix 另有规定。这条路径会提醒运维人员，要求逐条批准命令，也没有「始终允许」规则。通用系统底层的命令策略不限制命令集合。除非组织能独立强制执行权限边界，否则初期只读试点宜排除这个路径。设备类型和账户权限共同构成安全设计。

另一个实验情境可以观察工具怎样处理陌生输出。命令可能返回模型不认识的计数器，两家厂商也可能用不同名称表示同一类接口。有效的回答会引用原始观察，并提出能区分假设的检查。较弱的回答会把看似合理的解读当成事实。团队可以在无需接触生产设备的情况下评估两种表现。

让导出结果能交给下一个班次

一行诊断结论对亲自排查的人很方便。交班时则需要记录最后确认的观察、已排除的情况、尚不确定的事项，以及接班人无需重开所有会话就能执行的检查。在重要结论旁附上对应证据。如果模型看过新日志后改了诊断，也要记录改判理由。

比较时应纳入团队现有的人工流程。记录找到首条有效线索的耗时、无关命令建议数量和编写交班说明的时间。如果速度可以接受，本地模型可能带来切实的隐私优势。如果数据政策允许，更棘手的案例也可能适合用经批准的托管模型。无论哪种模式，都要保留清晰的连接路径和取证记录。

分别记录每个数据目的地

配置记录应列出用户界面发送什么、哪些内容转给模型，以及从设备收集什么。这样更换服务商后也容易复核。应按目的地分别看数据保留设置。清除本地会话历史，无法证明端点已删除先前的请求。

表中列的是常见部署方式。团队应观察自己实际使用的端点和服务配置。设置面板里，托管服务与专用网关可能显示同一品牌。确认真实主机名和运营方，数据流向才可审计。

用合成数据检验脱敏

创建一份实验日志，包含虚构的 IP 地址、虚构设备标签和类似客户标识的标记。标明按政策应保留、遮盖或移除的项目。对同一份样例做两种操作，例如聊天摘要和文件导出。系统的输出构造方式可能不同。允许使用真实数据之前，逐条检查传输路径。

再把标记放进一段长描述或带格式的输出。脱敏规则可能识别某个字段，却漏掉散落在正文中的同一个值。如果标记仍然出现在未经授权的目的地，先关闭这条路径，再连接生产设备。可以缩减原始数据集后复测，查明真正起作用的保护措施。

升级后重跑同一组检查

更新客户端后，记录当前选用的服务商并重跑原来的实验案例。命令允许列表或自动审批规则的匹配方式变化，可能影响工具提出的动作。端点默认值变化，则可能改变证据去向。把一条被拒绝的命令、一次脱敏和一次已知故障的成功诊断放在一起复测。随着团队环境变化，这组小型回归检查能帮助维护开源工具。

分别验证工具和设备账户

读取工具可以返回设备元数据或已有的证据。命令执行工具则能通过已连接的账户向设备请求新的证据。即使命令执行不可用，摘要请求也应当还能完成。可以断开设备连接但保留模型端点，以明确测试这个边界。回答应该区分此前已经观察到的信息与当前无法收集的新信息。

随后使用一个只能检查单台交换机、无法进入配置模式或触及另一个网段的账户。团队可以在自己的实验设施中验证拒绝路径，无须要求助手尝试真实变更。把应用记录的拟执行动作与设备自身的登录日志及命令审计对照。这个练习能分清工具策略作出的决定与实际账户拥有的权限。

来源

• Transit v6.5.11 发布记录

• 指定版本的 Transit 威胁模型

• Transit 开源过渡说明

• Transit 社区仓库和发布说明

• Transit 版本列表

• Transit 功能文档

---

想把工作中的对话和决策留成可搜索的记录，可以创建 Telli.sh 账户。