端侧 AI Agent 不是自动攻击按钮：从 Nightcrawler 看手机本地推理、作用域代理与授权边界
把小型语言模型放到手机上，再让它调用安全工具，听起来很像“随身的自动渗透测试员”。Nightcrawler 的价值恰好不在于把这件事包装成炫技：它把本地模型、工具调用和网络访问限制拆成不同层，迫使使用者面对一个更现实的问题——当 Agent 已经能够提出并执行命令时，安全边界究竟应该放在哪里？
Nightcrawler 是 garagehq 发布的 Python 项目，README 将其定位为运行在 Android 手机 Kali NetHunter chroot 中的本地 AI 红队 Agent。项目文档给出的示例硬件是 OnePlus 8：手机本地通过 llama.cpp 运行 LFM2.5-1.2B-Instruct-Heretic，Agent 再经由 Kali MCP Server 使用工具。它的目标场景是已经获得书面授权、具有 Rules of Engagement 的安全测试；README 明确禁止将其用于未授权目标。
这也是阅读该项目的正确姿势：它可以作为端侧 AI 与授权安全自动化的架构案例，但不是面向任意网络的“扫描教程”，更不应被当成可绕过审批和责任归属的自动化武器。
一台手机里的执行链：模型不该直连工具
按照项目的架构文档，Nightcrawler 的核心链路不是“模型直接运行 shell”，而是多了一个中间控制面：
本地 llama.cpp（127.0.0.1:8080）
↓
Python Agent loop
↓
Scope Enforcement Proxy（8800）
↓
Kali MCP Server（5000）
↓
已授权的测试工具
模型负责理解任务、组织步骤和生成候选命令；MCP 服务负责把工具能力提供给 Agent；真正关键的是两者之间的 scope enforcement proxy。项目的 config.yaml 可以声明授权文件、允许测试的网络范围、排除主机与排除端口。代理会从命令中提取 IP 或 CIDR，检查其是否落入允许范围，并拒绝命中排除规则的目标。
这种结构回答了许多 Agent 系统经常忽略的问题：模型是否“知道”边界不重要，系统是否在执行点强制边界才重要。提示词里的“只能测试这个网段”只是软约束；将允许范围放进独立代理，并让工具调用必须穿过代理，才把策略变成可执行的控制。
不过也不能把它神化。Nightcrawler 的作用域校验和危险命令过滤都以规则、正则和已知参数形式为基础。文档源码显示，它会拦截若干高风险命令模式，也会检查常见端口参数；这能降低误操作面，却不等于对所有工具、所有参数写法和所有副作用都有完备证明。因此，授权文件、隔离实验环境和人工复核仍是不可替代的外层控制。
为什么端侧推理值得讨论
传统安全自动化通常把控制台、日志和模型推理都放到服务器或云端。Nightcrawler 选择在手机本地运行模型，并把数据存储、Web Dashboard 与推理服务放在设备附近。这种取舍至少带来三点启发。
第一，敏感上下文少出设备。测试范围、命令记录和环境观察不必天然发往第三方模型 API；这对内网实验、临时现场演练和网络条件不稳定的场景有实际意义。第二，移动端硬件成为约束的一部分。小模型能带来较低资源要求，但不会自动拥有大模型的可靠规划能力；复杂任务、长上下文和工具返回噪声都可能放大误判。第三，离线不等于无风险。模型在本地运行减少的是外传路径，不会降低某条错误命令对被测系统的影响。
README 还列出了本地 SQLite、仪表盘和 Tailscale 远程控制等组成。把这些能力连在一起时，应该额外区分“本地推理”“远程访问”和“远程执行”：前两者可以共存，但任何远程控制入口都需要独立认证、设备管理和审计，不能因为模型没有上云就默认整个系统安全。
一个安全的验证起点：先确认服务，不先执行任务
项目 README 提供了以下本地健康检查和 dry-run 入口。它们适合用来核验组件是否启动；真正的测试任务仍应只在明确授权的隔离范围内由具备资质的人员配置与复核。
curl -s http://127.0.0.1:8080/health NC_DRY_RUN=1 python3 main.py
这两行命令体现了一条可迁移的工程原则：先测控制面和依赖可用性，再谈业务动作。对于任何能调用文件系统、云 API、数据库或网络工具的 Agent，都可以用同样的顺序降低风险：先验证模型端点、策略代理、审计落点和模拟模式；确认拒绝规则有效后，才在最小授权范围内开放真实动作。
更进一步，不能只记录“任务完成”。至少应把任务的授权编号、允许目标、实际被拦截的请求、人工批准点与最终报告关联起来。这样，出了问题时能回答“谁批准了什么、系统为何放行或拒绝”，而不是只留下模型生成的一段解释。
三层边界比一个系统提示词可靠
从 Nightcrawler 的设计可以抽出一套适用于普通开发 Agent 的三层边界。
- 身份与授权层：先定义谁能发起任务、任务对应什么授权、授权何时失效。对安全测试而言是 Rules of Engagement；对内部运维 Agent 而言可以是工单、变更单或短期凭证。
- 执行策略层：在工具调用处校验允许资源、拒绝资源、可用动作与速率，而不是把这些要求只写在 system prompt。策略应能独立更新、被测试，并记录拒绝原因。
- 证据与复核层：保存输入、工具调用、策略判定和输出摘要。高影响操作应要求人工批准；自动生成的结论也要能回溯到具体证据，而非只保留自然语言结果。
这三层并不只适用于网络安全。一个会删库、部署生产环境或读取客户数据的编码 Agent，同样需要把“模型建议”与“系统执行”拆开。不同领域的规则不同，但执行前校验、最小范围、可回放审计这三个原则是相通的。
让策略可以被测试，而不是只在事故后解释
如果要把这种架构迁移到团队内部，最值得先建设的不是更多工具，而是一组可自动验证的策略测试。可以准备一份只包含保留网段、测试靶机和显式拒绝资源的测试配置，再用模拟工具调用覆盖几类情形：允许网段中的只读查询应放行；越出范围的地址应拒绝；命中排除主机或排除端口应拒绝；缺少任务授权标识的请求也应停在执行层之外。每次修改规则后，都让这些样例随 CI 一起运行。
这类测试的意义在于把“Agent 很谨慎”转化为可观察的系统性质。它还应配合默认拒绝：新工具、新目标、新网络段在没有明确规则时不执行；策略日志要区分模型的建议、代理的判定和最终工具结果。这样即使模型换代、提示词变更或 MCP 服务升级，团队仍可用同一套回归用例判断边界有没有被意外放宽。
对于高风险操作，策略代理之外还应设置人的确认点。最小授权范围、短时有效凭证、任务结束后的访问回收，以及对审计记录的定期复盘，都是把一次测试限制在应有边界内的必要补充。自动化越强，越不能把这些流程视为可选项。
采用前需要正视的限制
Nightcrawler 对设备与环境有较强前提：Android、Kali NetHunter、root 权限、足够内存，以及能运行本地模型的硬件条件。README 以特定手机为生产配置示例，不能据此推导为所有 Android 设备均受支持。模型本身也可能误解目标、遗漏上下文或生成不恰当的候选步骤，因此不能把“本地”误解成“可靠”。
许可证也是一个应在引入前补齐的治理项。README 写有 MIT 声明，但当前 GitHub 仓库 API 未返回可识别的许可证，仓库文件树中也未能核验到 LICENSE 文件。对个人实验而言，这可能只是项目早期整理问题；对团队引入、分发或二次开发而言，应在使用前向维护者确认正式许可证，而不是直接把它标作许可状态已确认的开源依赖。
因此，Nightcrawler 最有价值的地方不是“手机上也能做多少事”，而是提醒我们：端侧 AI Agent 的能力边界必须由架构、策略与审计共同定义。模型可以留在设备上，责任不能留在提示词里。