方寸智匣能渗透接单了？

我做这项功能，起点很简单：既然本地模型已经能写代码、读文件，能不能让它检查自己的项目和服务，而不是每次把扫描器输出复制给它？

现在这条链路已经有了真实结果。在我的 M5 Pro、64GB 内存 Mac 上，1.6.5 安装版分别用 35B 和原版 27B Splash 连续检查两次。四次都返回 170 条组件匹配，真正扫描镜像的阶段为 12–13 秒，临时靶场均已清理。新版精简入口、范围确认和模型调用，都保留了真实窗口截图。

但“扫描成功”和“模型解释准确”不是一回事。27B 曾把自己没有提交的翻页参数说成工具失效，两个模型也都把缺失修复版本解释过头。1.6.6 因此把实际参数、已读证据数量和未知字段放进程序回执。我们先照着界面走一遍，再看这些数字究竟能证明什么。

版本说明：本文更新于 2026 年 10 月 4 日。操作截图来自本机已安装的 1.6.6；四次同条件模型对比来自 1.6.5，下文另列历史1.6.3与1.6.4记录。1.6.7 新增的"授权渗透"能力见第十一节，其结论来自本机隔离环境的真实端到端验证（非界面截图），文中已逐项标注。所有软件界面图片均为真实窗口截图；机制图和数据图单独标注，不能替代操作验收。

一、先看结果：它已经做了什么？

LocalBrain 是本地模型工具箱，安全检查只是其中一组可选工具。本地语言模型负责理解任务、选择已有能力、读取证据和提出建议；扫描器负责执行实际检查；程序负责授权、隔离和保存报告。

这不是让模型随意执行攻击命令。你确认的是具体对象和范围，模型不能自己签发授权，也不能把检查一个容器扩大成检查所有容器。

目前可用的内容分成四类：

工作区安全审查：看自己项目的代码、依赖和配置。本地命令、构建及测试另需执行确认，工作目录限制不等于操作系统沙箱。

内置练习靶场：第一次学习检查和读报告，检查临时隔离靶场的镜像组件，不演示业务漏洞利用。

我的主机或服务：检查自己或明确获授权的服务，支持 TCP 连接、明文 HTTP 根路径首响应及两条已复核的泄露规则。

我的容器：查项目镜像中的已知组件问题。镜像快照审计不等于运行中应用的完整安全评估。

本地模型可以调用五个安全工具：查询环境与授权、检查已授权主机、审计指定容器、检查内置靶场、分页读取报告。它要先知道真实能力，再决定下一步，不靠猜测“我应该有这个工具”。

二、新界面怎么用：先选对象，再核对一次范围

旧界面把环境、反向验证、授权和扫描拆成了很多按钮。第一次打开，很容易不知道先点哪个。新版将正常操作收成三个对象入口：内置练习靶场、我的主机或服务、我的容器；环境诊断与维护默认折叠。

执行方式有两个选项。默认的“让本地模型检查”会把目标交给正式对话，由模型查询能力、调用工具和整理报告；“直接检查”不调用模型，只跑固定检查流程。

我建议第一次先选内置靶场。想检查整个模型链路，就用模型方式；只想判断扫描器和环境是否正常，就用直接方式。直接方式成功而模型方式失败，才能继续查模型调用、确认与会话交接，不必一开始把所有问题都归到模型参数上。

正常顺序是：选对象 → 核对范围 → 确认有权检查 → 自动准备并运行 → 查看报告。环境准备成功不等于授权任何主机，界面的范围确认也不替代工具需要的原生执行确认。

三、第一次照着做：检查 Juice Shop，不填 IP 和端口

Juice Shop 是内置练习目标。这条路径不需要你填写镜像地址、猜容器编号，或把练习服务公开到公网。

1. 打开“设置 → 网络安全 → 授权网络检查”，选择“内置练习靶场”。
2. 下拉选择 Juice Shop。首次先保留这个目标，不混入生产服务。
3. 选择“让本地模型检查”。先确保语言模型已经启动、自动工具已开启，当前没有正在生成的任务；否则先使用“直接检查”验证环境。
4. 点击“核对范围并开始”，检查目标、执行方式和本次范围。
5. 勾选“我确认有权检查此目标，并同意上述范围”，再确认开始。点“返回修改”不会执行。
6. 程序按需准备隔离环境、补齐资源并验证边界。首次安装依赖仍可能要求确认，耗时取决于网络与缓存。
7. 模型方式会交接到新建的正式对话。遇到原生工具确认框，核对本次动作后再允许执行。
8. 完成后，先看报告状态和目标，再看发现与证据；失败、拒绝或没有报告都不能解释成“没有漏洞”。

想直接在对话提出任务，可以复制这段检查指令：

请检查内置 Juice Shop 靶场。
先查询真实环境、工具能力与已有授权，只检查这个目标。
按工具要求申请用户确认，不使用终端绕过权限。
完成后读取三个严重问题的原始证据，给出修复建议，
并明确列出尚未覆盖的范围。
组件匹配不等于已验证可利用；缺失字段标为未知。

这是任务描述，不是授权口令。真正的批准由可信界面返回，模型在参数里写“已批准”没有作用。

四、同条件对比：35B 与原版 27B，扫描一样，解释不同

这四次都在1.6.5安装版运行，目标为同一个 Juice Shop 镜像，两次之间不重启。模型使用相同入口与检查要求；27B 是原版 Qwen3.8-27B-Splash，不是 Swift 1.5。表中的总耗时包含模型组织任务、读报告及人工批准等待，不能当成纯推理速度排名。

扫描器每次都给出严重9、高54、中83、低24。模型实际拿到的证据不同：35B第二次为了遍历全部记录用了19次读报告，整轮23轮；27B第二次反复读高危第一页，实际只有19条不同记录。后端保存的参数显示，这几次请求没有 offset，不能因为模型说“我传了10”就断言分页失效。

这次对比没有筛掉失败或错误解读。它说明执行链路可以连续使用，也说明模型叙述不能替代工具事实。每个模型仅两次，不足以证明谁普遍更好；170条是组件匹配数，不是独立漏洞数量，更不是成功利用数量。完整对比记录。

1.6.6 的处理放在共同机制：返回真实分页参数和下一页完整请求；重复读取不增加累计证据；修复字段缺失标为未知；无效目标在批准前拒绝。模型仍自行决定读哪些关键证据，不强制逐条遍历，更不因某个模型名称自动改参数。

安装1.6.6后，我用同一原版27B再次走完真实入口、原生批准、扫描和证据读取。首轮总耗时4分43秒，其中包含约1分38秒人工批准等待；扫描本身仍是13秒。整轮7轮、8次工具，5次读报告实际只读取19条不同记录，重复请求没有抬高已读数量。

这轮模型正确写出“漏洞库已更新、离线扫描”，并明确严重9条全部读取、高危10条样本、中低危未读取。表格把缺失修复版本写成“未知”，但后面的建议仍用了“无已知修复版本”，也给了本轮没有联网核实的升级建议。我保留这处不一致：程序能够给出可核对的事实，并不能强制模型每句话都准确。正式包是这套机制的交付，不是模型建议的安全认证。

未重启的连续第二次也完成了：4轮、4次工具，2次报告读取，仍是19条不同证据；日志记录实际扫描12秒、170条匹配、临时容器与网络清理成功。界面总耗时10分57秒，其中工具阶段8分56秒包含锁屏及批准等待，不能据此判断模型变慢。第二轮结束由真实界面可访问文本和持久日志核对；后续截屏服务失败，因此没有补造第二轮图片。

第二轮对“未知修复版本”和“只读19条”的表述更准确，但又把两次准备成功说成相同数据库快照；没有数据库摘要，就不能证明快照一致。末尾“文件已完成”也不适用于这次没有文件交付的任务。它们是尚存的模型解释与收口措辞问题，不是扫描器验证出的事实。我们能确认连续执行链路正常，不能因此保证报告每句话准确。

五、历史实测：模型完整执行，报告可以再次读取

第一组测试使用 Swift-1.5-Qwen3.8-27B-Splash，通过产品共享代理内核和生产安全适配器连续运行两次，中间没有重启。测试桥只允许临时内置靶场，拒绝外部主机与用户容器；因此它能证明模型工具链可用，但不代替桌面确认框验收。

第二组使用 Qwen3.6-35B-A3B-Splash，在安装后的原生界面完成工具发现、用户确认、扫描和报告读取。这才是本文的真实桌面模型使用记录。

完整检查都经过“查询能力 → 检查示范 → 读取证据”，结果为 170 条组件匹配。原生报告编号是 6d5b6ea5-c873-4a01-a795-f287ae85a93f，能对应到后端记录，不是模型在聊天中自行宣布成功。

接着在同一对话输入：

不要重新扫描。读取刚才保存的报告，列出三个最需要处理的问题。
每项附组件、版本、原始证据和报告给出的修复信息。
缺失字段标为未知，不推断成没有修复；最后说明未覆盖范围。

这一点比单次成功更重要：已经有报告，就应读取保存的证据，不必每轮重新创建靶场、更新数据库、扫描一遍。此次只验证了上述模型和路径，不能因此宣称所有语言模型已经通过同样的实测。

六、历史后端补测：连续使用有没有问题？

1.6.4 的补测使用当前源码编译的生产安全适配器，连续完成两次 Juice Shop 检查，中间没有重启测试进程。扫描后分别读取三条原始证据，两次都有独立报告编号和非空结果。

两份独立报告编号分别为 e18e6e8b-e06a-4c5b-9793-708dddf7f8f5、7f6b4b9e-4f89-43f8-b327-a75e9a970ae3，用于在归档中追溯本次执行，不是需要读者填写的参数。

这验证的是生产后端的连续扫描与报告读取，不是新版原生模型界面全流程。首次下载隔离环境、扫描器和漏洞库，不能照搬上表的十五秒预期。

测试也有失败记录：第一次脚本误把返回的 reportId 按另一个字段读取，扫描完成后，读报告请求缺少编号。修正测试脚本字段后才得到上表。失败发生在测试脚本，不能归因于模型；修好之后，也不能假装第一次从未失败。

七、170 条发现，应该怎样解读？

两次新版后端结果一致：严重 9、高 54、中 83、低 24，共 170 条。它们是镜像内可识别软件包与已知漏洞数据库的匹配记录，不是 170 个成功利用的业务漏洞。

看报告时，至少核对五件事：目标是哪一个；匹配的组件与版本；证据从哪里来；修复字段是否明确；检查没有覆盖什么。

本次覆盖镜像中可识别的软件包，不覆盖运行容器额外增加的文件、宿主机内核和应用业务权限逻辑。离线扫描不联网解析依赖，但准备阶段仍可联网更新漏洞库与Java数据库。数据库下载成功不证明Java组件完整覆盖；1.6.6将最近成功准备的状态单独记录，未验证的覆盖保持未知。没有检出某类问题，不能推出目标整体安全。

模型初次解释还犯过一个错误：报告的修复版本为空，它说成了“没有官方修复”。实际只能说“本次数据库记录未列出修复版本”。后续读原始报告才改正。因此模型建议必须能回指证据；升级到哪个版本仍要结合项目核实，建议不是已经执行的修复。

八、自己的主机：预设会帮你填，但目标不能替你授权

选择“我的主机或服务”，先选检查方案。有可选本地服务时，从下拉框选，程序使用已发现服务的实际地址和发布端口；没有列出的目标才手动输入自己的地址。

例如自己的开发服务实际是 192.168.1.20:8080：选开发服务，输入 192.168.1.20，解析后核对地址、8080 端口、连接与响应头，授权有效期 15 分钟；检查内网时勾选对应许可。这个地址仅是填写示例，不是本文实测目标，请换成自己真实且获授权的地址。

程序能自动给出方案默认值，也能从已发布服务读取端口；它不能自动认定你拥有某个目标的测试授权。域名有多个地址时，本次只确认其中一个实际地址；执行不重新解析域名、不跟随外站跳转。网页路径不会扩大成全站爬取，输入 HTTPS 也不会让现有 HTTP 检查变成完整 HTTPS 审计。

本地服务列表只覆盖专用隔离环境内可发现的已发布服务，不代表自动发现整个局域网。授权到期或退出应用后失效，读取旧报告不会恢复权限。

九、自己的容器：选择真实目标，不手填编号

选择“我的容器”，从列表选一个实际容器，再核对目标和镜像。模型方式把明确容器编号交给对话；直接方式审计镜像快照。两种方式都不等于对运行网页执行漏洞利用。

列表为空时，先用内置靶场验证环境；需要时再展开维护区刷新。不要凭空填写容器编号，也不要因为列表为空就断言电脑没有服务。首次扫描器和数据库准备需要联网下载；正常复查不必每次手动点击更新。

对于代码项目，可把任务换成“审查这个已授权工作区的依赖与配置，先列证据，再提出最小修复建议；执行构建或测试前申请确认”。这一条不需要授权网络主机，但项目脚本可能访问目录外或软件仓库，仍要核对命令，不能把工作区选择器当作完整系统隔离。

十、报错怎么办：先找失败的环节，不重复乱点

真实原生测试最初也失败过：查询能力正常，执行确认却被错误序列化为对象，后端拒绝批准值，扫描没有运行。修复放在共用确认边界：等待异步原生确认，只接受严格布尔真值，未知值默认拒绝；不是给某个模型写一条特别提示词。

更早的连通性测试还发现过误报：目标停机，代理仍可接受连接，旧逻辑就把它判断为在线。修复后做了正常与停机对照：正常连续两轮通过，停机后连续两轮失败；失败状态必须保存，不能只留下“工具返回了文本”。

隔离反向验证检查授权目标可达、未授权端口拒绝、直接访问拒绝、公网访问拒绝与停止后清理等边界。通过这些验证，只证明所测边界按预期工作，不能承诺容器、虚拟机和代理永远没有漏洞。

十一、1.6.7 新增：从"检查"到"授权渗透"，模型能自己写 PoC 了

回到标题那个问题——它能接单做渗透测试吗？到 1.6.6，答案还只是"能做授权范围内的连接、响应头和组件匹配检查"。1.6.7 又往前走了一步：在同一套隔离之上，新增三类逐目标显式勾选的高影响范围，让这台 Mac 可以用来接授权渗透测试的单。

• 服务与版本识别：沙箱里跑 nmap -sV，认出授权端口上到底是什么服务、什么版本。
• SQL 注入探测：沙箱里跑 sqlmap，但只开检测技术，os-shell、文件读写、夺权这些利用开关在代码里被写死排除，模型拿不到。
• 自写 PoC 执行：模型（或你自己）写一段 Python 或 sh 脚本，交给隔离沙箱执行。

最后这条是关键，也是我最谨慎的地方：让模型自己写代码去打目标，听起来很危险。它能放开，不是因为我信任模型写的每一行，而是因为出口被网络锁死了。每个任务起一张没有默认路由的隔离网络，脚本唯一的出口是一个只往授权目标转发的代理；脚本只拿到代理地址和"本地端口→目标端口"的映射，连真实目标 IP 都不知道。所以哪怕脚本写成要连公网、要打别的机器，它也到不了——根本没有那条路。

我用一段真脚本在本机隔离环境里验过这件事，整轮约 59 秒：

破坏性类别——拒绝服务、删改数据、免杀反检测——按签名直接拒；声明会改变目标状态的 PoC，执行前还要再确认一次。模型这三个工具每一个都要你在原生弹窗里逐次批准，模型自己在参数里写"已批准"没有用。授权还是老规矩：单个 IP、最多 8 项、最长 60 分钟、退出应用即失效，且只能你在界面上勾选创建——模型不能给自己签发或扩大授权。升级到 1.6.7 后，每台机器都要重新通过本地靶场反向验证，这条线才会开。

所以"接单能不能用"的答案是：范围靠技术锁死，范围内把模型放到最自主——选工具、改配置、自己写 PoC 都行，破坏性动作加一道闸。能不能接，取决于你有没有那张授权书，而不是软件拦不拦得住越界——越界触犯刑法第 285、286 条和网络安全法。它是帮你取证、出报告的工具，不是绕开授权的手段。这条线目前只在 Mac 实测；Windows 和 Linux 构建了同样的功能，但隔离与反向验证还没在那两端真机跑过，执行同样"没过反向验证就不开"。

十二、下载哪版？哪些结论还没验收？

本轮正式版本为 1.6.7 全平台发行页，即第十一节那套授权渗透能力所在的版本。三平台安装包从发行页重新下载后，SHA-256 与构建值逐一致，更新签名验签通过；Mac 未苹果公证。更新清单与下载页同步到 1.6.7，旧发行已清理。本文的操作截图仍来自本机已安装的 1.6.6；1.6.7 在其上新增渗透能力，其结论来自隔离环境的端到端验证而非界面截图。

Windows和Linux从同一源码提交构建，安装包散列与更新签名已核对，但尚未做两平台真机使用验收。Linux仍按预览支持看待，不能运行MLX/Splash，受管llama.cpp与Prism下载尚未完整接入。本文的模型运行与原生窗口实测来自Mac，不扩展成全平台保证。

源码验收中，前端测试1423条通过、2条跳过；Rust测试305条通过、19条忽略（1.6.7 新增了渗透相关单元测试与一条真机围栏测试）；产品Python环境的测试文件此前已全量复测通过。我还对两道新闸做了变异验证：把"破坏性拒绝"和"PoC 拿不到真实目标 IP"的判断故意改坏，对应测试立刻变红，确认它们是真在拦、不是摆设。跳过和忽略项不算通过，测试数量也不能代替原生使用验收，更不能保证模型解释没有错误。

Mac 选择 Apple Silicon 包，安装到应用程序；Windows 选择 x64 安装程序；Linux 根据系统选择 AppImage 或 Debian 包。首次准备可能需要下载额外依赖，按软件提示确认；需要国际网络的下载应提前准备连接。具体依赖、散列和平台边界，以发行页为准。

最后：第一次拿到报告，第二次学会追问证据

这篇教程最值得照着做的是两次请求：第一次检查内置靶场，第二次明确说“不要重新扫描，读取刚才的报告”。前者验证执行链路，后者验证模型能不能使用已经获得的证据。

我不想用一个很大的漏洞数字证明软件厉害。更有用的是：少填无意义的表，目标和范围不含糊；模型有工具可用，程序守住权限；每个结论能回到报告，失败也留得下来。

先用练习靶场把这条流程走通，再检查自己的项目和服务。只能测试自己拥有或明确获得授权的目标；扫描可能造成资源占用或服务异常，风险提示不替代合法授权。

本文数据出处：1.6.7 渗透能力实现与隔离实测、安全功能设计与边界、模型调用与原生实测记录、1.6.4历史后端验收。完整原始回执与窗口截图保留在本地测试归档；示意图均为据此绘制，不是生成的假界面。