ARTICLE · 1122503
自托管 AI 助手进内网前,先做完这 5 项检查
"我们打算在内网搭一个 AI 助手，大家都能用。有人推荐 Octop，说是自托管、数据不出门、还能多人共用。"
这类需求最近半年明显变多了。我顺着看了一圈，发现大部分讨论停在"怎么装起来"，很少有人讲装起来之后怎么办。
这篇以 Octop 为例，但不是只讲它——我要说的是**自托管 AI 助手进内网之前，有哪些检查不能省**。这些东西换成任何一个带终端和浏览器的 AI 工具都适用。
一、先说清楚：被攻破之后，丢的不是数据
这是自托管 AI 助手和普通内部系统最本质的区别。
普通 Web 系统被攻破，攻击者拿到的是**数据**。而一个带终端、浏览器、远程桌面的 AI 助手被攻破，攻击者拿到的是**执行权**：
· 宿主机的 shell（终端能力）
· 已登录的网页会话（浏览器能力，基于 CDP 直连）
· 键鼠操控（远程桌面）
· 所有已授权的外部服务 token（文档、IM、网盘…）
· 全部历史对话与长期记忆
最后一条容易被忽略：**记忆里往往沉淀着最多的内部信息**——项目背景、排障过程、内部术语。它不像数据库字段那样有明确的敏感标记，反而是最容易被整体拖走的东西。
所以这类系统的安全基线应该**高于**普通内部工具，不能按"反正内网用用"的标准来部署。
二、"开源"是分层的，别停在 L0
关于 Octop 有个常见的讨论：**它最核心的组件到底开没开源。** 这个话题值得跟一下，因为它演示了"开源"这件事的分层。
先给事实（2026-10-03 实查 GitHub API）：
· 主仓 TencentCloud/Octop：**6,406 star / 789 fork / 745 open issues**，MIT，Python，最后 push 10-02
· 9 月中旬时还是 2,860 star、211 open issues → **半个月里 star 涨了 124%，但 issue 涨了 253%**
· 最新版本已从 v1.0.0 走到 v1.0.2b5（9-29），13 天内发了 5 个 beta
然后是那个反转。四个核心组件在初期标注"筹备开源中"，官方在 issue 里的回复是"等热度继续提升后会陆续开源"。**结果 9 月 24 日真的开了**，只是改了名字：
· octop-harness（Agent 运行时）：32 star，MIT，9-24 创建
· octop-gateway（IM 通道桥接）：28 star，MIT
· octop-memory（分层记忆）：26 star，MIT
· octop-browser（CDP 浏览器自动化）：22 star，MIT
所以"能跑不能审计"这个判断，现在要打个折。但**开源只是第一层**：
L0 代码可得 —— 源码能下载到 ✅（已达成）
L1 构建可复现 —— 能自己从源码编出同样产物 ⚠️（取决于你怎么装）
L2 依赖可追溯 —— 知道运行时实际加载了哪些代码 ⚠️（要自己建 SBOM）
L3 社区已审计 —— 有人真看过并报过问题 ❌（四个组件加起来 star 不到 110）
四个组件 star 加起来不到主仓的 2%——这说明用户关心的是产品，不是代码。**"开源了"和"被审计过"之间还隔着两个数量级的注意力。** 下面第二节实践就是把 L1 和 L2 自己补上。
三、部署：最小暴露面
第一条原则：**不要直接把 8088 端口暴露出去。** 容器只监听本地回环，公网访问一律走反向代理，前面再加一层鉴权。
# 关键：-p 前面带上 127.0.0.1，只监听本机
docker run -d --name octop \
-p 127.0.0.1:8088:8088 \
-v octop-data:/data/.octop \
-e HOME=/data \
-e OCTOP_DEFAULT_PASSWORD="$(openssl rand -base64 24)" \
--restart unless-stopped \
octop:latest
这里有三处和常见教程不一样：
· -p 127.0.0.1:8088:8088：只绑回环地址，外面扫不到
· 密码**运行时生成**，不写进镜像也不写进 compose 文件
· 官方文档的默认管理员口令是公开的弱口令，**首次启动后必须立刻改**——这一条几乎所有自托管项目都中招，也是被扫得最多的一个点
需要外部访问时，反向代理加一层前置认证：
server {
listen 443 ssl;
server_name ai.internal.example.com;
ssl_certificate /etc/nginx/certs/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/key.pem;
# 只允许内网网段 + VPN 段
allow 10.0.0.0/8;
allow 172.16.0.0/12;
deny all;
location / {
# 前置一层基础认证，多一道门
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:8088;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# 远程桌面 / 终端走 WebSocket，这两行不能少
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;
}
}
WebSocket 那两行值得单独提醒：**远程桌面和终端能力依赖长连接**，反代没配 Upgrade 头会表现为"能登录但一开终端就断"，排查起来很费时间。
四、实践场景一：确认你装的依赖真的可审计
这是我最想写的一节，因为它把"可审计"从口号变成了可执行的动作。
原理不复杂：PyPI 上的包分两种分发形式——**wheel 是编译后产物，sdist 是源码包**。如果某个依赖只提供 wheel 没有 sdist，你就没办法从源码层面验证它到底做了什么。
先扫一遍环境里有哪些包是"只给 wheel"的：
#!/usr/bin/env bash
# 列出没有源码分发（sdist）的依赖 —— 这些无法从源码审计
set -u
OUT=$(mktemp -d)
trap 'rm -rf "$OUT"' EXIT
for pkg in $(pip freeze | cut -d= -f1 | cut -d'[' -f1); do
[ -z "$pkg" ] && continue
if ! pip download --no-binary :all: --no-deps -q -d "$OUT" "$pkg" >/dev/null 2>&1; then
echo "⚠️ 无源码分发: $pkg"
fi
done
扫出来的包不一定要换掉，但**要知道它们是哪些**，并且把这份清单归档。这就是 SBOM 的雏形。
然后验证关键包：把 sdist 拉下来，和 GitHub 上对应 tag 的源码比对。
VERSION=1.0.1
mkdir -p audit && cd audit
# 1) 拉源码包（不走 wheel）
pip download --no-binary :all: --no-deps octop==$VERSION -d .
tar -xzf octop-$VERSION.tar.gz
# 2) 拉官方仓库对应 tag
git clone --depth 1 --branch v$VERSION \
https://github.com/TencentCloud/Octop.git upstream
# 3) 比对
diff -rq octop-$VERSION upstream \
--exclude=.git --exclude=*.egg-info \
| head -50
这一步有个**必须提前说清楚的预期**：diff 几乎不可能完全干净。sdist 里通常包含构建生成的文件（如 PKG-INFO、*.egg-info、打包时生成的资源），这些在仓库里没有。
所以正确的做法是**关注关键目录是否一致**——认证、模型路由、工具执行、凭据处理这几处代码。如果这些目录有不明差异，那才是真问题。目标不是让 diff 归零，是让"敏感路径可核对"。
顺带一个判断信号：octop 在 PyPI 上的描述里写的还是旧组件名，而 GitHub README 已经改成新名了。**这类"文档没同步"的小细节，往往能反映发布流程的成熟度**——不是大问题，但值得记一笔。
五、实践场景二：能力开关与并发
第二节说过，远程桌面、浏览器、终端这三项是"重能力"。默认全部打开，意味着攻击面直接拉满。我们的做法是**默认关闭，用时再开，用完即关**。
具体到 Octop，这几项在控制台左侧栏都能看到（Remote Desktop / Browser AI+ / Terminal AI+）。原则比配置更重要：
· **远程桌面**：只在需要跨机排障时临时开，不要常驻
· **浏览器能力**：它基于 CDP 直连浏览器，意味着能触达已登录的会话。给专人开，不全员开
· **终端能力**：建议给 AI 用的账号单独建一个低权限系统用户，不要用 root 或你的常用账号
数据库这边，默认是 SQLite（WAL 模式）。几个人的量完全够用，但**给几十人的团队用就得换 PostgreSQL**——SQLite 的写锁是整库级的，并发一上来就卡。切换时数据库用容器起即可，Octop 侧的连接配置以官方文档为准：
services:
db:
image: postgres:16-alpine
environment:
POSTGRES_DB: octop
POSTGRES_USER: octop
POSTGRES_PASSWORD_FILE: /run/secrets/pg_pass
volumes:
- pgdata:/var/lib/postgresql/data
secrets:
- pg_pass
healthcheck:
test: ["CMD-SHELL", "pg_isready -U octop"]
interval: 10s
retries: 5
# 同样只暴露给同网络的 octop 服务，不映射到宿主机
expose:
- "5432"
octop:
image: octop:latest
depends_on:
db:
condition: service_healthy
ports:
- "127.0.0.1:8088:8088"
volumes:
- octop-data:/data/.octop
environment:
HOME: /data
OCTOP_DEFAULT_PASSWORD_FILE: /run/secrets/octop_pass
secrets:
- octop_pass
volumes:
pgdata:
octop-data:
secrets:
pg_pass:
file: ./secrets/pg_pass.txt
octop_pass:
file: ./secrets/octop_pass.txt
密码走 secrets 而不是 environment 明文，是为了避免出现在 docker inspect 和进程环境里。这属于顺手就能做对的事。
六、对比与注意事项
自托管 AI 助手的三条路线（⭐ 为主观评分，满分 5 星）：
自托管开源产品（如 Octop）
· 上手速度：⭐⭐⭐⭐⭐（一条命令）
· 数据可控：⭐⭐⭐⭐（在自己机器上）
· 可审计性：⭐⭐⭐（L0 达成，L3 几乎为零）
· 运维责任：⭐⭐（全在自己身上）
· 适用：想快速验证、团队规模不大
开源框架自建（LangChain / 各类 Agent 框架拼装）
· 上手速度：⭐⭐
· 数据可控：⭐⭐⭐⭐⭐
· 可审计性：⭐⭐⭐⭐⭐（每一行都是自己的）
· 运维责任：⭐（最重）
· 适用：有明确定制需求、有工程人力
商业 SaaS
· 上手速度：⭐⭐⭐⭐⭐
· 数据可控：⭐（要出门）
· 可审计性：⭐（只能看对方的合规文档）
· 运维责任：⭐⭐⭐⭐⭐
· 适用：数据敏感度低、不想养运维
几条注意事项：
· **看 issue/star 比的变化，不要看绝对值。** Octop 半个月里 star +124%、issue +253%，后者增速是前者两倍——这是"产品形态跑在工程成熟度前面"的典型信号
· **beta 后缀 + 高频发版要放进预期。** 从 v1.0.0 到 v1.0.2b5 只用了 13 天，说明 1.0 的"完整"是相对的，生产环境要锁版本
· **一键安装脚本是"先执行后审计"。** macOS/Linux 的 install.sh、Windows 的 install.ps1 都是下载即执行，真要跑就先单独下下来看一遍，或者直接用 Docker
· **备份的是整个数据目录**，配置和凭据都在里面，漏了凭据等于重装
· **审计日志比 Web 应用更重要。** 要能回答"谁在什么时候让 AI 执行了什么"
七、总结
这套检查适合：
· 准备把 AI 助手接入内网、多人共用
· 助手带有终端、浏览器、远程桌面等重能力
· 数据敏感度要求"不出门"
· 团队规模在几十人以内
需要另外考虑的情况：
· 上百人共用且要做细粒度权限 → 需要更强的身份体系，不是加个反代能解决的
· 有等保或合规审计要求 → 可审计性要按 L2/L3 补齐，可能得走自建
· 只是自己一个人用 → 大部分检查可以简化，重点放在备份和默认口令上
· 完全没有运维人力 → 自托管的隐性成本会超过 SaaS
写这篇最想留下的一句话是：**把 AI 助手接进内网，等于把一部分执行权交给了它。** 这不是保守，是这类系统和普通内部工具的本质差别——数据泄露是损失，执行权丢失是事故。默认口令改掉、暴露面收窄、重能力按需开关、依赖能追溯，这四件事做完之前，它不该出现在生产网络的拓扑图里。
你们公司有没有在内网跑 AI 助手？权限和审计这块是怎么做的？评论区聊聊。
注：本文涉及 Octop 的数据均为 2026-10-03 通过 GitHub API 与 PyPI 实查（star 6406 / open issues 745 / 最新 v1.0.2b5；octop-harness、octop-gateway、octop-memory、octop-browser 于 2026-09-24 开源，均为 MIT）。项目处于快速迭代期，Nginx 与 compose 配置需按自身环境调整，具体配置项以官方文档为准。
本文来源于互联网，如有侵权，请联系作者删除
谢谢关注！