修复 mcporter 与 n9e-mcp-server SSE 连接挂起问题一、事件概述1. 事件背景用户在使用 mcporter 调用 Nightingale MCP 工具时，程序出现挂起现象。mcporter list 显示 nightingale 服务为 offline 状态，执行 mcporter call nightingale.list_active_alerts 命令时程序无响应。2. 影响范围A. 影响功能Nightingale MCP 工具调用全部失败无法通过 MCP 协议访问 Nightingale 监控数据影响 list_active_alerts、list_history_alerts 等所有监控工具B. 影响时长调试过程持续约 2 小时，涉及多次代码修改和验证3. 严重程度P2 级问题，影响特定 MCP 服务器的可用性二、事件时间线1. 问题发现（初始阶段）A. 现象描述执行 mcporter list 时，nightingale 显示为 "offline — unable to reach server"B. 初步判断根据计划文件，问题根源是配置不匹配：mcporter 配置使用 stdio 模式，但 n9e-mcp-server 已切换到 HTTP SSE 模式运行。2. 配置调整（第一阶段）A. 处理措施修改 /home/jacky/.claude/config/mcporter.json，将 nightingale 从 stdio 模式改为 HTTP SSE 模式B. 效果评估问题未解决，mcporter list 仍显示 nightingale 为 offline3. 用户关键反馈（第二阶段）A. 发现途径用户注意到服务器日志中 session_id 为空字符串：session_id=""B. 用户提问"from the log i see session_id is null, shall this is the problem?"4. SessionID 调查（第三阶段）A. 调研方法通过 zread 工具检查 go-sdk 源代码 mcp/sse.goB. 关键发现在 sseServerConn 和 sseClientConn 的 SessionID 方法中发现以下注释：// TODO(jba): get the session ID. (Not urgent because SSE transports have been removed from the spec.) func (s *sseServerConn) SessionID() string { return "" }C. 结论空的 session_id 是预期行为，SSE 传输已从 MCP 规范中移除，不是问题根源5. 真实问题定位（第四阶段）A. 处理措施使用 curl 直接测试 SSE 端点，验证服务器是否正常响应B. 关键发现curl 测试成功，SSE 流程正常工作。问题在于 mcporter 的传输模式回退逻辑：尝试 Streamable HTTP 模式：失败，提示 "sessionid must be provided"回退到 SSE 模式：挂起6. 配置文件定位（第五阶段）A. 处理措施搜索并确认 mcporter 的实际配置文件位置B. 关键发现mcporter 使用 /home/jacky/.mcporter/mcporter.json，而非 /home/jacky/.claude/config/mcporter.jsonC. 修复措施更新正确的配置文件，将 URL 从远程地址改为本地地址7. Token 认证逻辑修复（第六阶段）A. 问题分析检查 n9e-mcp-server 的 HTTP 处理代码，发现所有请求（包括 POST 到 session endpoint）都强制要求 token 认证B. 问题根因POST 请求到 /mcp?sessionid=XXX 时，这些请求应仅使用 sessionid 认证，不应再次验证 tokenC. 修复措施修改 /mydata/code/mcp/n9e-mcp-server/internal/http_server.go，添加条件判断：mainHandler.HandleFunc("/mcp", func(w http.ResponseWriter, r *http.Request) { // POST 请求带 sessionid 直接转发到 SSE handler if r.Method == http.MethodPost && r.URL.Query().Get("sessionid") != "" { sseHandler.ServeHTTP(w, r) return } // 其他请求需要 token 认证 token := r.URL.Query().Get("token") if token == "" { http.Error(w, "token parameter required", http.StatusUnauthorized) return } sseHandler.ServeHTTP(w, r) })D. 效果评估mcporter list 成功显示 "nightingale (27 tools, 0.1s)"，SSE 连接正常建立8. Nightingale API 401 问题（第七阶段）A. 现象描述SSE 连接正常后，工具调用返回 "client error: 401 unauthorized"B. 处理措施检查容器网络配置，发现容器 IP 为 172.30.0.2（Docker bridge 网络），而 Nightingale 服务器在 192.168.124.79C. 修复措施修改 docker-compose.yml，将 network_mode 改为 host 模式D. 当前状态仍返回 401 错误，问题根源是 Nightingale 服务器端的配置，需要在 config.toml 中启用 HTTP.TokenAuth.Enable = truesequenceDiagram participant M as mcporter participant C as 配置文件 participant S as n9e-mcp-server participant N as Nightingale API M->>C: 读取配置（错误位置） M->>S: 尝试 stdio 连接 S-->>M: 连接失败 M->>C: 读取配置（正确位置） M->>S: GET /mcp?token=xxx S->>S: 验证 token S-->>M: endpoint 事件 M->>S: POST /mcp?sessionid=XXX Note over S: token 验证拦截（问题） S-->>M: 401 unauthorized Note over S: 修复后：跳过 token 验证 M->>S: POST /mcp?sessionid=XXX S-->>M: SSE 消息 M->>N: 调用 API N-->>M: 401 unauthorized（服务器配置问题）三、问题分析1. 直接原因n9e-mcp-server 的 HTTP 处理器对所有请求强制执行 token 认证，包括已建立 SSE 会话的 POST 请求2. 根本原因（5 Whys 分析）A. 为什么出现这个问题？代码未区分初始连接请求和会话请求，统一要求 token 认证B. 为什么没有及时发现？初始测试使用 GET 请求建立 SSE 连接，这种场景下 token 验证是正确的，问题仅在后续 POST 请求时暴露C. 为什么 SSE 会话请求不需要 token？SSE 协议流程规定：初始 GET 请求使用 token 建立连接服务器返回 endpoint 事件，包含 sessionid后续 POST 请求仅使用 sessionid 作为认证依据D. 为什么容器网络问题会影响 API 调用？Nightingale 服务器配置了 IP 白名单，容器 IP 不在白名单内E. 为什么 401 问题仍未完全解决？这是 Nightingale 服务器端的配置问题，不在 n9e-mcp-server 代码范围内3. 深层反思mcporter 的配置文件位置不符合预期（~/.mcporter/ 而非 ~/.claude/config/）go-sdk 中 SessionID 返回空字符串的注释容易引发误解HTTP 服务器的认证逻辑需要区分不同类型的请求四、解决方案1. 临时方案A. 实施措施无临时方案，问题根因明确，直接进行代码修复2. 永久方案A. 代码层面改进修改 http_server.go，对 POST 请求添加 sessionid 检查，跳过 token 认证B. 配置层面改进更新 mcporter 配置为正确的 HTTP SSE 模式，使用正确的配置文件路径C. 网络层面改进Docker 容器使用 host 网络模式，避免 IP 限制问题3. 预防措施A. 代码审查在代码 Review 时关注认证逻辑的边界条件B. 文档完善明确说明 mcporter 的配置文件位置C. 测试覆盖增加 SSE 会话请求的测试用例五、经验总结1. 做得好的地方通过 curl 测试隔离了问题范围检查 go-sdk 源码确认了 session_id 行为的预期性系统化排查流程，从配置到代码到网络2. 需要改进的地方未尽早确认 mcporter 的配置文件位置对 SSE 协议的认证流程理解不够深入3. 流程优化建议建立 MCP 服务器调试 checklist明确各工具的配置文件位置规范记录常见协议流程（SSE、stdio）的差异点六、参考资料MCP 规范文档go-sdk 源代码Nightingale API 文档
OpenClaw Studio 入门指南一、概述1. 简介A. 是什么OpenClaw Studio 是一个简洁的 Web 仪表板，用于管理和控制 OpenClaw Gateway。它提供统一的界面来连接 Gateway、查看和创建 agents、进行对话、管理审批任务以及配置定时作业。B. 为什么学提供可视化界面，简化 OpenClaw 的操作流程支持多种部署场景，满足本地和云端需求集中管理 agents、聊天、审批和作业配置C. 学完能做什么在本地或云端部署 OpenClaw Studio配置 Studio 与 Gateway 的连接使用 Studio 界面管理 agents 和执行任务二、环境准备1. 系统要求Node.js 18+（推荐使用 LTS 版本）OpenClaw Gateway URL 和访问 tokenTailscale（可选，推荐用于远程访问）2. 安装步骤推荐安装方式（npx）npx -y openclaw-studio@latest从源码安装（高级用户）git clone https://github.com/grp06/openclaw-studio.git cd openclaw-studio npm install npm run dev3. 验证安装安装完成后，在浏览器中打开 http://localhost:3000，确认 Studio 界面正常加载。三、核心概念1. 基本术语Gateway：OpenClaw 的核心服务，负责 agents 的执行和管理Studio：Web 仪表板，提供图形化界面与 Gateway 交互Upstream：Studio 连接到 Gateway 的上游服务Agent：可执行特定任务的智能代理Tailscale：虚拟网络服务，用于安全的远程访问2. 工作原理OpenClaw Studio 采用双路径网络架构，Studio 作为中间层连接浏览器和 Gateway。graph LR subgraph 用户终端 Browser[浏览器] end subgraph Studio主机 Studio[OpenClaw Studio Web服务] WS1[WebSocket 3000端口] end subgraph Gateway主机 Gateway[OpenClaw Gateway] WS2[WebSocket 18789端口] end Browser -->|HTTP/UI| Studio Browser <-->|WebSocket 实时更新| WS1 WS1 -->|WebSocket| WS2 WS2 <--> Gateway网络连接说明：浏览器到 Studio：HTTP 用于 UI 界面，WebSocket 用于实时更新Studio 到 Gateway：Studio 服务器通过 WebSocket 连接配置的上游 URL3. 部署模式Studio 支持三种常见的部署场景，根据 Gateway 和 Studio 的运行位置选择合适的方式。四、快速上手1. 场景选择根据你的网络环境选择部署场景：场景 A：Gateway 本地运行，Studio 本地运行（同一台计算机）场景 B：Gateway 云端运行，Studio 本地运行（你的笔记本电脑）场景 C：Studio 云端运行，Gateway 云端运行（始终在线）2. 场景 A：Gateway 本地，Studio 本地适用于开发和测试环境，两者在同一台计算机上运行。安装和启动npx -y openclaw-studio@latest cd openclaw-studio npm run dev配置连接打开 http://localhost:3000，在 Studio 中设置：Upstream URL: ws://localhost:18789Upstream Token: 你的 Gateway token（可通过 openclaw config get gateway.auth.token 获取）3. 场景 B：Gateway 云端，Studio 本地适用于 Gateway 部署在云服务器，而在本地进行管理的场景。运行 Studionpx -y openclaw-studio@latest cd openclaw-studio npm run dev配置网络连接方案一：Tailscale Serve（推荐）在 Gateway 主机上：tailscale serve --yes --bg --https 443 http://127.0.0.1:18789在 Studio（你的笔记本）中：Upstream URL: wss://.ts.netUpstream Token: 你的 Gateway token方案二：SSH 隧道从你的笔记本执行：ssh -L 18789:127.0.0.1:18789 user@<gateway-host>在 Studio 中：Upstream URL: ws://localhost:187894. 场景 C：Studio 云端，Gateway 云端适用于始终在线的生产环境，推荐使用 Tailscale 实现安全访问。在 VPS 上运行 Studionpx -y openclaw-studio@latest cd openclaw-studio npm run dev暴露 Studio 到 Tailnettailscale serve --yes --bg --https 443 http://127.0.0.1:3000访问和配置从你的笔记本或手机打开：https://.ts.net在 Studio 中设置：Upstream URL: wss://.ts.net或者其他 Studio 主机可以访问的 Gateway 地址Upstream Token: 你的 Gateway token五、配置说明1. 配置文件路径OpenClaw 配置：~/.openclaw/openclaw.json可通过环境变量 OPENCLAW_CONFIG_PATH 或 OPENCLAW_STATE_DIR 覆盖Studio 设置：~/.openclaw/openclaw-studio/settings.json2. 环境变量变量名说明默认值是否必填NEXT_PUBLIC_GATEWAY_URL默认 Gateway URLws://localhost:18789否STUDIO_ACCESS_TOKENStudio 访问令牌无有条件必填HOST绑定主机地址127.0.0.1否STUDIO_ACCESS_TOKEN 使用规则：绑定到公网主机时必填（HOST=0.0.0.0、HOST=:: 或非回环地址）仅绑定到回环地址时可省略（127.0.0.1、::1、localhost）3. 网络配置注意事项避免将 Studio 部署在 /studio 路径下，除非配置 basePath 并重新构建如果 Studio 可从非回环地址访问，必须设置 STUDIO_ACCESS_TOKEN使用 /?access_token=... 一次性设置访问令牌的 cookie六、故障排查1. 连接失败如果 UI 加载正常但连接失败，通常是 Studio 到 Gateway 的连接问题：检查上游 URL 和 token 是否正确配置存储位置：/openclaw-studio/settings.json2. 常见错误码错误原因解决方案EPROTO 或 wrong version number使用 wss:// 连接非 TLS 端点改用 ws://，或将 Gateway 置于 HTTPS 后Assets 404 under /studioStudio 部署在 /studio 路径在根路径 / 部署，或配置 basePathStudio access token required未提供 STUDIO_ACCESS_TOKEN设置环境变量或通过 /?access_token=... 设置studio.gateway_url_missingGateway URL 未配置在 Studio 设置中配置 Upstream URLstudio.gateway_token_missingGateway token 未配置在 Studio 设置中配置 Upstream Tokenstudio.upstream_error上游连接错误检查 Gateway 是否运行且可访问studio.upstream_closed上游连接关闭检查网络连接和 Gateway 状态七、进阶功能1. UI 工作流详见 docs/ui-guide.md，了解以下功能的操作流程：Agent 创建Cron 定时任务配置执行审批管理2. PI 和聊天流式传输详见 docs/pi-chat-streaming.md，了解：Studio 如何将浏览器 WebSocket 流量桥接到上游 Gateway运行时流式事件（聊天/agent 事件）如何到达聊天 UI 如何渲染工具调用、思考追踪和最终对话行3. 权限和沙箱详见 docs/permissions-sandboxing.md，了解：Agent 创建选项（工具策略、沙箱配置、执行审批）这些设置如何从 Studio 流向 OpenClaw Gateway上游 OpenClaw 在运行时如何强制执行这些设置4. 颜色系统详见 docs/color-system.md，了解：语义化颜色契约状态映射规则确保 action/status/danger 在 UI 中一致使用的防护措施5. 架构详情详见 ARCHITECTURE.md，了解：模块组织结构数据流设计系统组件交互参考资料OpenClaw Studio GitHub 仓库OpenClaw 官方文档
OpenClaw 安装配置指南一、概述1. 简介A. 是什么OpenClaw 是一个开源的个人 AI 助手平台，支持多平台集成（WhatsApp、Telegram、Discord 等）和任务自动化。B. 为什么使用支持多聊天平台统一管理提供 WebSocket Gateway 实现实时通信支持代理管理和会话持久化开源免费，可自主部署C. 学完能做什么在 Linux 环境中安装 OpenClaw配置和管理聊天频道运行和监控 Gateway 服务使用控制面板管理 AI 代理2. 前置知识A. 必备技能基本 Linux 命令操作了解 Node.js 和 npm 基本概念B. 推荐知识了解 WebSocket 基本原理熟悉 JSON 配置文件二、环境准备1. 系统要求操作系统：Linux（Kali、Ubuntu、Debian 等）Node.js：v22.12.0 或更高版本构建工具：gcc、make、g++、python3内存：至少 2GB 可用磁盘：至少 500MB 可用空间2. 安装步骤检查 Node.js 版本node --version检查构建工具make --version gcc --version检查 npm（通过 corepack）node /usr/share/nodejs/corepack/dist/npm.js --version3. 验证安装确保所有前置条件满足后再继续。三、核心概念1. 基本术语Gateway（网关）：WebSocket 服务器，处理通道和代理之间的通信Agent（代理）：AI 智能体，处理用户消息和任务Channel（通道）：连接的聊天平台（Telegram、Discord 等）Session（会话）：用户与代理之间的对话历史Credentials（凭证）：第三方服务的认证信息2. 工作原理graph TB Client[用户客户端 Telegram/Discord] --> Channel[通道模块] Channel --> Gateway[WebSocket 网关] Gateway --> Agent[AI 代理] Agent --> Gateway Gateway --> Channel Channel --> Client Gateway --> Control[控制面板 http://127.0.0.1:18789] Agent --> Session[(会话存储)] Channel --> Cred[(凭证存储)]四、快速上手1. 安装 OpenClaw官方安装脚本（推荐）curl -fsSL --proto '=https' --tlsv1.2 https://openclaw.ai/install.sh | bash替代方案：用户级安装当 npm 通过 corepack 提供且没有系统级权限时使用：# 创建用户级 npm 目录 mkdir -p ~/.npm-global # 设置环境变量 export npm_config_prefix="$HOME/.npm-global" export PATH="$npm_config_prefix/bin:$PATH" # 使用 corepack npm 安装 npm_config_prefix="$HOME/.npm-global" PATH="$npm_config_prefix/bin:$PATH" \ node /usr/share/nodejs/corepack/dist/npm.js install -g openclaw@latest2. 验证安装# 检查可执行文件 ls -la ~/.npm-global/bin/openclaw # 查看版本 ~/.npm-global/bin/openclaw --version # 检查已安装包 ~/.npm-global/bin/node /usr/share/nodejs/corepack/dist/npm.js list -g openclaw预期输出：可执行文件：~/.npm-global/bin/openclaw版本：2026.2.26（或更新版本）3. 初始化配置首次使用前需要运行配置向导：~/.npm-global/bin/openclaw onboard或使用交互式设置向导：~/.npm-global/bin/openclaw configure配置完成后，配置文件位于：主配置：~/.openclaw/openclaw.json工作空间：~/.openclaw/workspace凭证：~/.openclaw/credentials日志：~/.openclaw/logs/五、启动服务1. 启动 Gateway~/.npm-global/bin/openclaw gateway默认配置：WebSocket 地址：ws://127.0.0.1:18789控制面板：http://127.0.0.1:18789/2. 检查服务状态# 健康检查 ~/.npm-global/bin/openclaw health # 查看详细状态 ~/.npm-global/bin/openclaw status正常输出示例：Gateway: local · ws://127.0.0.1:18789 · reachable 62ms Telegram: ok (@your_bot_name)3. 访问控制面板浏览器访问：http://127.0.0.1:18789/六、常用命令1. 核心命令命令说明openclaw gateway启动 WebSocket 网关openclaw status查看系统状态openclaw health健康检查openclaw configure交互式配置向导openclaw onboard初始化配置向导openclaw channels管理聊天通道openclaw agents管理代理openclaw message发送消息2. 通道管理# 登录 Telegram 通道 ~/.npm-global/bin/openclaw channels login --channel telegram # 查看通道状态 ~/.npm-global/bin/openclaw channels list # 登录 Discord ~/.npm-global/bin/openclaw channels login --channel discord3. 日志查看# 实时查看网关日志 ~/.npm-global/bin/openclaw logs --follow # 查看指定行数的日志 ~/.npm-global/bin/openclaw logs --lines 100七、常见问题1. 安装问题npm command not found问题：官方脚本无法找到 npm 命令解决方案：使用用户级安装方案mkdir -p ~/.npm-global export npm_config_prefix="$HOME/.npm-global" export PATH="$npm_config_prefix/bin:$PATH"原生模块编译失败问题：sharp、canvas 等原生模块编译失败解决方案：安装构建依赖sudo apt-get update sudo apt-get install -y build-essential python3 python3-dev2. 运行问题Gateway 无法连接问题：ECONNREFUSED 127.0.0.1:18789解决方案：检查 Gateway 是否运行~/.npm-global/bin/openclaw gateway凭证目录权限警告问题：credentials 目录权限过于宽松解决方案：收紧权限chmod 700 ~/.openclaw/credentials3. 配置问题如何设置自定义端口编辑 ~/.openclaw/openclaw.json，修改 gateway.port 字段如何启用 dev 模式~/.npm-global/bin/openclaw --dev gatewaydev 模式使用独立的配置和状态目录（~/.openclaw-dev/）八、安全建议1. 基本安全措施使用强密码保护控制面板不要在公共网络暴露 Gateway 端口定期备份配置和会话数据设置凭证目录权限为 7002. 网络安全使用反向代理时配置 trustedProxies启用 HTTPS 访问控制面板限制聊天机器人的访问权限3. 运行安全检查# 运行安全审计 ~/.npm-global/bin/openclaw security audit # 运行系统健康检查 ~/.npm-global/bin/openclaw doctor参考资料OpenClaw 官方文档OpenClaw GitHub 仓库OpenClaw 安装指南
Netventory 网络扫描工具技术分析一、新闻概述1. 标题Netventory：快速单二进制网络扫描工具，支持 TUI 和 WebUI 双界面2. 发布时间2025 年 1 月（当前版本 v0.3.0n）3. 来源GitHub 开源项目4. 作者RamboRogers二、核心内容1. 事件摘要A. 主要内容Netventory 是一个用 Go 语言编写的快速网络发现工具，提供终端 TUI 和 Web 两种用户界面，无需 root 权限即可运行。B. 核心亮点单二进制可执行文件，无需额外依赖跨平台支持 Linux、macOS 和 Windows双界面设计：终端 TUI 和 WebUI高并发扫描架构，性能优异多协议主机名解析MAC 地址厂商识别2. 关键信息A. 版本号当前版本：v0.3.0nB. 技术栈语言：Go 1.21+（GPLv3 开源许可）架构：并发扫描 + Worker PoolC. 涉及技术网络扫描、端口检测NetBIOS、SMB、RDP、mDNS 协议解析WebSocket 实时通信Token 认证机制3. 背景介绍A. 项目定位网络发现和网络审计工具，替代传统的 nmap 等复杂工具，提供更友好的用户界面。B. 相关上下文网络扫描工具通常分为命令行工具（如 nmap）和图形化工具（如 Angry IP Scanner），Netventory 结合了两者的优势。三、详细报道1. 主要功能A. 网络发现快速网络扫描，可配置 Worker 数量自动检测网络接口和计算 CIDR 范围MAC 地址解析和厂商查找端口扫描（22、80、443、445、139、135、8080、3389、5900、8006）无需 root 权限B. 高级主机名解析Netventory v0.3.0n 引入了多层主机名解析策略：graph TD A[目标设备] --> B{DNS 解析} B -->|成功| F[主机名] B -->|失败| C{NetBIOS} C -->|成功| F C -->|失败| D{SMB 主机名} D -->|成功| F D -->|失败| E{RDP 证书} E -->|成功| F E -->|失败| G{mDNS/Bonjour} G -->|成功| F G -->|失败| H[使用 IP 地址]C. 设备类型检测Apple 设备：通过厂商 OUI、端口开放情况和 mDNS 发现Windows 设备：通过 SMB 和 NetBIOS 检测Proxmox 虚拟化平台：检测 8006 端口D. 协议增强SMB：支持来宾账户、匿名访问回退、共享枚举RDP：TLS 证书解析，提取 CN 和 SANmDNS：服务类型发现、Apple 专用服务检测2. 技术架构A. 系统组成graph TB subgraph 用户界面层 TUI[终端 TUI] WEB[Web UI] end subgraph 业务逻辑层 SCAN[扫描引擎] RESOLVE[主机名解析器] DETECT[设备检测器] end subgraph 协议层 DNS[DNS 客户端] NETBIOS[NetBIOS] SMB[SMB 客户端] RDP[RDP 证书解析] MDNS[mDNS 客户端] end subgraph 网络层 WORKER[Worker Pool] ICMP[ICMP Ping] TCP[TCP 端口扫描] end TUI --> SCAN WEB -->|WebSocket| SCAN SCAN --> WORKER WORKER --> ICMP WORKER --> TCP RESOLVE --> DNS RESOLVE --> NETBIOS RESOLVE --> SMB RESOLVE --> RDP RESOLVE --> MDNS SCAN --> RESOLVE SCAN --> DETECT DETECT --> SMB DETECT --> MDNSB. 并发扫描模型sequenceDiagram participant M as 主控制器 participant W as Worker Pool participant T as 目标设备 M->>W: 分配 IP 段 par 并发扫描 W->>T: ICMP Ping W->>T: TCP 端口检测 end T-->>W: 返回在线状态 W->>W: 端口扫描 W->>W: MAC 地址解析 W-->>M: 设备信息 M->>M: 主机名解析 M->>M: 设备类型判断C. Web 架构graph LR C[客户端浏览器] -->|HTTP + WebSocket| S[Web 服务器] S -->|Token 验证| A[认证中间件] A -->|通过| S S -->|扫描请求| E[扫描引擎] E -->|实时更新| S S -->|WebSocket 推送| C3. 技术细节A. 性能指标默认 Worker 数量：50可配置 Worker 范围：用户自定义扫描速度：高并发非阻塞设计内存占用：优化的设备追踪B. 安全设计Token 认证：WebUI 访问需要唯一 Token不收集敏感数据隐私优先设计无需 root 权限C. 兼容性LinuxmacOSWindows（PowerShell 安装脚本）四、影响分析1. 行业影响A. 竞争格局与 nmap 相比：更友好的界面，更简单的使用与 Angry IP Scanner 相比：跨平台、命令行和 Web 双界面与 masscan 相比：更侧重设备发现而非速度B. 技术趋势单二进制部署趋势TUI 和 WebUI 融合零依赖部署模式2. 用户影响A. 目标用户网络管理员安全研究人员IT 运维人员网络爱好者B. 应用场景网络审计：快速发现网络设备安全评估：端口和服务枚举网络管理：设备清单和追踪故障排查：网络连接验证3. 技术优势A. 相比传统工具无需复杂参数配置实时可视化反馈跨平台一致性体验丰富的设备信息B. 创新点多协议主机名解析回退机制设备类型智能识别WebSocket 实时更新单二进制零依赖五、各方反应1. 项目特点GitHub Stars：持续增长中开源许可：GPLv3社区活跃：持续迭代更新2. 技术评价A. 优点界面美观，交互友好性能优秀，扫描快速功能全面，协议丰富部署简单，单文件运行B. 限制相比 nmap 功能较简单不支持自定义脚本高级扫描选项较少六、使用指南1. 安装方式Mac 和 Linuxcurl -L https://raw.githubusercontent.com/RamboRogers/netventory/refs/heads/master/install.sh | sh或使用 Homebrew（Mac）：brew tap ramborogers/netventory brew install netventoryWindows PowerShelliwr -useb https://raw.githubusercontent.com/RamboRogers/netventory/refs/heads/master/install.ps1 | iex2. 命令行选项# 终端模式 netventory # 启动终端界面 netventory -d # 启用调试模式 # Web 模式 netventory -w # 启动 Web 界面 netventory -p 8080 # 指定 Web 端口 # 性能调优 netventory --workers 100 # 设置 Worker 数量 # 信息查询 netventory -v # 显示版本信息 netventory -h # 显示帮助3. Web 访问启动 Web 模式后，使用生成的 Token 访问：http://localhost:7331?auth=<token>七、版本演进v0.3.0n（当前版本）增强设备发现功能多协议主机名解析Proxmox 端口检测v0.2.0n完整的 Web 界面WebSocket 实时更新Token 认证机制早期版本终端 TUI 界面基础网络扫描功能MAC 地址解析参考资料Netventory GitHub 仓库
Clawdbot 个人 AI 助手 Gateway 架构技术分析一、概述1. 项目简介Clawdbot 是一个开源的个人 AI 助手平台，采用本地优先的架构设计，允许用户在自己的设备上运行完全可控的 AI 助手。项目由 Peter Steinberger 发起，采用 MIT 许可证发布。2. 核心特性本地优先的 Gateway 控制平面多通道消息支持（WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Microsoft Teams、Matrix、Zalo、WebChat 等）多 Agent 路由与会话隔离语音唤醒和对话模式（支持 macOS/iOS/Android）实时 Canvas 可视化工作区浏览器自动化控制Docker 沙箱安全隔离跨平台支持（macOS、Linux、Windows WSL2、iOS、Android）二、系统架构1. 整体设计Clawdbot 采用中心化的 Gateway 控制平面架构，所有组件通过 WebSocket 连接到 Gateway 进行通信。graph TB subgraph 通信层 WA[WhatsApp] TG[Telegram] SL[Slack] DS[Discord] SI[Signal] IM[iMessage] MT[Teams] MX[Matrix] WC[WebChat] end subgraph 控制平面 GW[Gateway WebSocket ws://127.0.0.1:18789] end subgraph 执行层 AG[Pi Agent Runtime] CLI[CLI Interface] UI[WebChat UI] end subgraph 设备节点 MAC[macOS App] IOS[iOS Node] AND[Android Node] end subgraph 工具层 BR[Browser Control] CV[Canvas] CR[Cron] WH[Webhooks] end WA --> GW TG --> GW SL --> GW DS --> GW SI --> GW IM --> GW MT --> GW MX --> GW WC --> GW GW --> AG GW --> CLI GW --> UI GW --> MAC GW --> IOS GW --> AND AG --> BR AG --> CV AG --> CR GW --> WH2. 核心组件A. Gateway（控制平面）Gateway 是 Clawdbot 的核心组件，提供统一的 WebSocket 控制平面，负责：会话管理（sessions）通道路由（channel routing）工具调度（tool orchestration）事件分发（event dispatch）配置管理（configuration）定时任务（cron scheduling）Webhook 处理B. Pi Agent Runtime采用 RPC 模式运行的 AI Agent 运行时，支持：工具流式传输（tool streaming）块流式传输（block streaming）会话隔离（session isolation）思考级别控制（thinking levels）C. 通道适配器支持多种消息平台的适配器，每个适配器负责：平台特定的消息协议处理媒体文件处理（图片、音频、视频）群组路由规则私聊策略（pairing/open）三、会话模型1. 会话类型Clawdbot 采用灵活的会话模型：main 会话：直接对话，拥有完整工具访问权限群组会话：隔离的会话环境，可配置沙箱模式工作区会话：支持多 Agent 并行工作2. 激活模式stateDiagram-v2 [*] --> Inactive Inactive --> Mention: 群组中被提及 Inactive --> Always: 始终激活模式 Mention --> Processing: 处理消息 Always --> Processing: 接收消息 Processing --> Idle: 处理完成 Idle --> Inactive: 超时 Idle --> Processing: 新消息3. Agent-to-Agent 协调Clawdbot 提供独特的会话间通信机制：sessions_list：发现活跃的 Agent 会话sessions_history：获取会话历史记录sessions_send：向其他会话发送消息这种设计允许多个 Agent 协同工作，无需在聊天界面之间切换。四、安全模型1. 默认安全策略Clawdbot 对入站 DM 采用默认拒绝策略：dmPolicy=pairing：未知发送者需要配对码配对后添加到本地白名单公开入站需要显式 opt-in2. 沙箱隔离对于非 main 会话（群组/公开通道），支持 Docker 沙箱：per-session Docker 容器allowlist：bash、process、read、write、edit、sessions_* 工具denylist：browser、canvas、nodes、cron、discord、gateway3. 权限管理macOS 应用通过 Gateway 协议暴露 TCC 权限：system.run：需要屏幕录制权限system.notify：需要通知权限camera.*、screen.record：遵循 TCC 权限状态五、部署架构1. 本地部署推荐配置：Gateway 运行在用户设备上运行时要求：Node.js >= 22安装方式：npm install -g clawdbot@latest后台服务：launchd（macOS）/systemd（Linux）2. 远程部署Gateway 可以运行在小型 Linux 实例上：客户端通过 Tailscale Serve/Funnel 连接或通过 SSH 隧道访问设备节点（macOS/iOS/Android）仍可执行本地操作graph LR subgraph 远程服务器 RG[Remote Gateway] end subgraph 本地设备 MAC[macOS Client] IOS[iOS Node] AND[Android Node] end subgraph 网络层 TS[Tailscale VPN] SSH[SSH Tunnel] end MAC -->|WebSocket| TS IOS -->|Pairing| TS AND -->|Pairing| TS TS --> RG SSH --> RG3. Tailscale 集成Clawdbot 原生支持 Tailscale 网络暴露：Serve 模式：tailnet-only HTTPSFunnel 模式：公共 HTTPS（需要密码认证）Gateway 绑定 loopback，通过 Tailscale 代理六、工具系统1. 内置工具Clawdbot 提供丰富的内置工具：工具类别工具名称功能描述浏览器browserChrome/Chromium CDP 控制可视化canvasA2UI 推送/重置/评估节点nodes.*相机、屏幕、位置、通知会话sessions_*Agent 间通信协调系统system.run命令执行（需权限）调度cron定时任务和唤醒Webhookwebhooks外部触发集成2. 技能平台支持三类技能：Bundled Skills：内置技能Managed Skills：托管技能Workspace Skills：用户自定义技能（~/clawd/skills/）七、技术栈1. 后端技术运行时：Node.js >= 22包管理：npm/pnpm/bun语言：TypeScriptWebSocket：自定义协议浏览器控制：Chrome DevTools Protocol2. 平台适配平台技术栈macOSElectron（菜单栏应用）iOSSwift原生AndroidKotlin/JavaLinuxNode.js 服务WindowsWSL23. 通道实现通道技术选型WhatsAppBaileysTelegramgrammYSlackBoltDiscorddiscord.jsSignalsignal-cliiMessageAppleScript（macOS）八、配置管理1. 最小配置{ "agent": { "model": "anthropic/claude-opus-4-5" } }2. 通道配置示例Telegram 配置{ "channels": { "telegram": { "botToken": "123456:ABCDEF", "groups": { "*": { "requireMention": true } } } } }浏览器配置{ "browser": { "enabled": true, "controlUrl": "http://127.0.0.1:18791", "color": "#FF4500" } }九、开发工作流1. 从源码构建git clone https://github.com/clawdbot/clawdbot.git cd clawdbot pnpm install pnpm ui:build pnpm build pnpm clawdbot onboard --install-daemon2. 开发循环pnpm gateway:watch # 自动重载3. 子模块初始化（如需构建应用）git submodule update --init --recursive ./scripts/restart-mac.sh十、特色功能1. Voice Wake + Talk Mode支持 macOS/iOS/Android 的语音唤醒和持续对话：Always-on speech（通过 ElevenLabs）Push-to-Talk overlay唤醒词触发转发2. Live CanvasAgent 驱动的可视化工作区：A2UI（Agent-to-User Interface）实时 Canvas 渲染快照和评估功能3. Companion AppsmacOS 菜单栏应用：Gateway 控制、Voice Wake、WebChatiOS 节点：Canvas、Voice Wake、相机、屏幕录制Android 节点：Canvas、Talk Mode、相机、屏幕捕获十一、运维与监控1. 健康检查clawdbot doctor2. 日志管理支持结构化日志和调试输出。3. Gateway Lock防止多实例冲突的锁机制。十二、生态与社区1. 技能注册中心ClawdHub 提供技能发现和自动安装功能。2. 贡献者项目拥有超过 200 名贡献者，采用 AI/vibe-coding 友好的贡献政策。3. 文档资源架构概览配置参考安全指南故障排除平台特定指南十三、适用场景1. 个人生产力多平台消息统一入口自动化任务执行信息检索和整理2. 开发者工具代码审查辅助自动化测试文档生成3. 隐私优先场景本地运行，数据不出设备完全可控的 AI 助手支持离线操作（部分功能）十四、技术亮点1. 统一控制平面通过单一 WebSocket 接口管理所有组件，简化了架构复杂度。2. 会话隔离群组会话与主会话隔离，支持细粒度的权限控制。3. Agent 协同sessions_* 工具支持 Agent 间直接通信，实现多 Agent 协作。4. 跨平台节点设备节点可以配对到远程 Gateway，实现分布式执行。5. 安全第一默认 DM 配对策略、Docker 沙箱、TCC 权限管理等多层安全机制。参考资料Clawdbot GitHub 仓库Clawdbot 官方文档
Happy Server 零知识同步后端技术分析一、技术概述1. 项目简介Happy Server 是一个专为开源 Claude Code 客户端设计的最小化后端服务，提供端到端加密的对话同步功能。A. 核心定位Happy Server 作为安全同步的骨干网络，使多设备能够共享加密对话，同时保持完全隐私。服务器存储加密数据但无法解密，仅作为加密数据的中继存储点。B. 设计哲学零知识架构：服务器无能力查看用户消息内容最小化攻击面：仅包含安全同步必需的功能隐私优先：无分析、无追踪、无数据挖掘2. 核心特性A. 安全特性零知识证明：服务器存储加密数据但无法解密密码学认证：不存储密码，仅使用公钥签名端到端加密：消息在离开发备前已加密B. 功能特性实时同步：基于 WebSocket 的跨设备实时同步多设备支持：手机、平板、电脑无缝会话管理推送通知：任务完成或需要权限时加密推送通知分布式就绪：设计支持水平扩展C. 开源特性完全开源：透明的实现可审计和自托管MIT 许可：自由使用、修改、部署二、技术架构1. 架构设计graph TB subgraph 客户端设备 C1[设备 A 手机] C2[设备 B 电脑] C3[设备 C 平板] end subgraph 本地加密层 E1[密钥生成] E2[端到端加密] E3[签名验证] end subgraph Happy Server S1[WebSocket 同步] S2[加密数据存储] S3[推送通知服务] end C1 -->|本地加密| E1 C2 -->|本地加密| E1 C3 -->|本地加密| E1 E1 --> E2 E2 -->|加密数据流| S1 S1 --> S2 S2 -->|同步| S1 S1 -->|加密推送| S3 S3 -->|加密通知| C1 S3 -->|加密通知| C2 S3 -->|加密通知| C32. 工作流程A. 消息同步流程sequenceDiagram participant D1 as 设备 A participant E as 本地加密层 participant H as Happy Server participant D2 as 设备 B D1->>E: 1. 生成密钥对 D1->>E: 2. 加密消息 D1->>E: 3. 签名验证 E->>H: 4. 上传加密数据 H-->>D1: 5. 确认存储 H->>D2: 6. WebSocket 推送 D2->>E: 7. 下载加密数据 D2->>E: 8. 本地解密 E-->>D2: 9. 显示消息B. 安全模型分析层级安全措施说明客户端本地密钥生成密钥永不离开设备传输层端到端加密服务器仅中继加密数据存储层加密数据存储服务器存储无法解密的数据认证层公钥签名无密码存储风险3. 技术栈分析根据 GitHub 仓库信息：主语言：TypeScript（99.4%）部署方式：Docker 容器化数据库：Prisma ORM实时通信：WebSocket 协议三、安全分析1. 零知识架构A. 核心原理服务器仅存储加密数据块（encrypted blobs），完全没有解密能力。加密在客户端本地完成，只有用户持有密钥。B. 安全优势服务器被入侵无风险：攻击者仅能获取无法解密的加密数据无需信任服务器提供商：即使云服务商也无法访问消息内容符合隐私法规：数据始终处于加密状态C. 密码学认证不存储用户密码使用公钥签名进行身份验证防止密码泄露风险2. 隐私保护A. 无数据收集无分析追踪无行为记录无数据挖掘B. 推送通知加密通知内容同样经过加密，服务器仅能转发但无法查看通知内容。四、部署方案1. 云服务托管A. 官方云服务地址：happy-api.slopus.comB. 安全性说明由于采用端到端加密，使用官方云服务的安全性与自托管完全相同。所有数据在离开发备前已加密，服务器即使想查看也做不到。C. 优势无需维护基础设施自动更新和扩展与自托管相同的安全模型2. 自托管部署A. 开源特性MIT 许可，可自由修改和部署完全透明的实现可审计的代码B. 部署建议使用 Docker 容器化部署配置反向代理（Nginx）启用 HTTPS 加密传输配置防火墙规则五、应用场景1. Claude Code 客户端Happy Server 专为开源 Claude Code 客户端设计，实现：多设备对话同步任务状态共享加密推送通知2. 扩展应用场景基于其架构设计，Happy Server 可应用于：需要高隐私保护的即时通讯多设备协作工具加密笔记同步六、技术影响1. 隐私保护范式Happy Server 展示了一种新的隐私保护范式：通过端到端加密实现零信任架构服务器提供商无法访问用户数据开源透明增加可信度2. 同步架构设计最小化服务器功能客户端承担加密解密逻辑服务器仅作为加密数据的中继和存储3. 开源生态MIT 许可促进广泛采用可审计性增强安全信任自托管选项满足合规需求七、总结Happy Server 代表了隐私优先的服务架构设计理念。通过零知识架构和端到端加密，它实现了用户数据完全隐私保护，同时保持了多设备同步的便利性。其开源特性和自托管选项为用户提供了完全的数据控制权。该项目的技术架构为其他隐私敏感应用提供了有价值的参考，证明了在功能性和隐私性之间可以取得良好平衡。参考资料Happy Server GitHub 仓库Happy Server 官方云服务
Rustpad 开源协作代码编辑器技术分析一、项目概述1. 项目背景Rustpad 是一个高效且极简的开源协作文本编辑器，基于 Operational Transformation（OT）算法实现。该项目由 ekzhang 开发，采用 Rust + React 技术栈，提供实时协作代码编辑功能。2. 核心特性A. 技术亮点无需数据库：使用内存存储，支持可选的 SQLite 持久化极小体积：Docker 镜像仅 6 MB自托管：完全独立部署，不依赖外部服务WebAssembly：OT 逻辑编译为 WASM 在浏览器中运行B. 应用场景团队协作代码编辑实时文档协作技术面试编程环境临时代码分享和协作3. 项目状态开源协议：MIT LicenseDocker 拉取量：活跃使用中GitHub 状态：CI workflow 通过公网实例：rustpad.io二、系统架构1. 整体架构Rustpad 采用典型的三层架构：graph TB subgraph 客户端 A[Monaco Editor] --> B[React UI] B --> C[WASM OT 模块] end subgraph 传输层 C --> D[WebSocket] D --> E[Warp HTTP 服务器] end subgraph 服务端 E --> F[OT 算法库] F --> G[内存数据结构] G --> H[可选 SQLite 持久化] end2. 组件说明A. 前端组件Monaco Editor：VS Code 同款编辑器，提供代码编辑功能React UI：用户界面框架WASM OT 模块：WebAssembly 编译的操作转换逻辑B. 后端组件Warp：高性能 Rust Web 框架operational-transform：OT 算法实现库内存存储：文档内容的内存数据结构C. 通信层WebSocket：客户端与服务器的实时双向通信三、核心技术1. Operational Transformation 算法OT 算法是实现实时协作编辑的关键技术。其核心思想是将用户的编辑操作转换为可交换、可合并的变换操作。A. 基本原理graph LR A[用户 A 操作] --> C[OT 引擎] B[用户 B 操作] --> C C --> D[操作转换] D --> E[合并后的文档状态] E --> F[同步到所有客户端]B. WebAssembly 优化Rustpad 使用 wasm-bindgen 将 Rust 编写的 OT 逻辑编译为 WebAssembly，实现浏览器端的高性能执行。优势：接近原生的执行速度减少服务器负载更快的响应时间2. 数据存储策略A. 内存优先模式默认情况下，Rustpad 将文档存储在内存中：优点：极快的读写速度无需数据库配置简化部署缺点：文档在服务器重启后丢失24 小时无活动后自动清除B. SQLite 持久化模式通过设置 SQLITE_URI 环境变量启用持久化：SQLITE_URI=/data/rustpad.db优点：文档在重启后保留支持长期存储注意事项：需要挂载 Docker 卷性能略有下降四、技术栈详解1. 后端技术栈A. Rust + Warp选择理由：Warp 基于 Tokio 异步运行时，性能优异类型安全的路由系统内置 WebSocket 支持零成本抽象代码示例（路由定义）：let routes = warp::path("editor") .and(warp::ws()) .map(|ws: warp::ws::Ws| { ws.on_upgrade(|socket| handle_connection(socket)) });B. operational-transform 库功能：实现文本操作的转换和合并处理并发编辑冲突保持文档一致性2. 前端技术栈A. React + TypeScript选择理由：组件化开发强类型检查丰富的生态系统B. Monaco Editor特性：VS Code 同款编辑器支持多种编程语言语法高亮代码补全和智能提示主题和快捷键自定义3. 构建工具链A. wasm-pack用于构建和打包 WebAssembly 模块：wasm-pack build rustpad-wasmB. Vite前端开发和构建工具，提供热重载功能。五、部署方案1. Docker 部署A. 快速启动docker pull ekzhang/rustpad docker run --rm -dp 3030:3030 ekzhang/rustpadB. 持久化部署docker run -d \ -p 3030:3030 \ -v /path/to/data:/data \ -e SQLITE_URI=/data/rustpad.db \ -e EXPIRY_DAYS=7 \ ekzhang/rustpadC. 多架构支持Docker 镜像支持：linux/amd64linux/arm642. 云平台部署A. Fly.io 部署官方使用 Fly.io 托管公网实例 rustpad.io。优点：全球边缘节点自动 HTTPS简单的部署流程3. 配置选项环境变量变量名说明默认值PORTHTTP 监听端口3030EXPIRY_DAYS文档过期天数1SQLITE_URISQLite 数据库路径无（内存模式）RUST_LOG日志级别info六、开发指南1. 环境准备A. 依赖工具Rust 工具链wasm-packNode.js 16+npm 或 yarnB. 构建步骤构建 WebAssembly 模块：wasm-pack build rustpad-wasm安装前端依赖：cd rustpad-frontend && npm install启动后端服务器：cd rustpad-server && cargo run启动前端开发服务器：cd rustpad-frontend && npm run dev2. 测试A. 后端测试cargo testB. WebAssembly 测试wasm-pack test --chrome --headless rustpad-wasm七、优势与局限1. 技术优势A. 性能优势Rust 后端提供高并发处理能力WebAssembly 前端计算加速内存存储减少 I/O 开销B. 部署优势单一 6 MB Docker 镜像无需额外数据库配置支持多 CPU 架构C. 开发体验TypeScript 提供类型安全React 生态丰富热重载开发体验2. 技术局限A. 功能限制不支持用户认证缺少权限管理无版本历史记录B. 存储限制默认内存模式数据易失SQLite 不适合高并发写入无分布式存储支持C. 扩展性限制单服务器架构无水平扩展能力内存容量限制八、适用场景分析1. 推荐场景A. 小团队协作临时代码审查技术讨论配对编程B. 教育场景编程教学算法演示代码面试C. 快速原型概念验证内部工具MVP 开发2. 不推荐场景A. 大规模生产环境需要用户认证的场景需要权限控制的场景需要高可用的场景B. 企业级应用需要审计日志需要版本控制需要细粒度权限九、同类项目对比1. 功能对比项目语言算法数据库认证RustpadRust + TSOT可选无EtherpadNode.jsOT有有HackMDNode.jsOT有有Google Docs闭源OT有有2. 定位分析Rustpad 的定位是：极简：最小化功能集高效：性能优先自托管：易于部署开源：完全透明十、总结与展望1. 项目总结Rustpad 是一个设计精良的协作编辑器，通过合理的技术选型实现了：极小的部署体积（6 MB）高性能的协作体验简单的自托管流程适合作为学习实时协作技术的参考项目，也适合作为小团队的临时协作工具。2. 技术启发A. WebAssembly 应用Rustpad 展示了 WebAssembly 在实际项目中的应用价值，为类似项目提供了参考。B. 无数据库架构证明了在特定场景下，内存优先架构可以大幅简化系统设计。C. Rust + React 组合展示了 Rust 后端与 React 前端的良好协作模式。3. 改进方向若要用于生产环境，建议增加：用户认证和授权文档版本历史分布式存储支持监控和日志系统API 限流保护参考资料Rustpad GitHub 仓库Rustpad 公网实例Operational Transformation 算法详解Warp 官方文档wasm-bindgen 文档
PushMe 消息通知平台技术分析项目概述PushMe 是一个开源的轻量级消息通知解决方案，由 Android 客户端、自建服务器端和多种接收端组成。该项目旨在为个人开发者和小型团队提供简单、可靠的消息推送能力，无需复杂的注册登录流程，通过 push_key 即可实现消息推送。核心特点：简单：无需登录注册，安装后获取 push_key 即可使用轻量：Android 原生开发，安装包不到 3M可靠：支持离线消息存储与转发兼容：接口兼容企业微信/钉钉/飞书群机器人可扩展：支持插件开发和消息转发系统架构graph TD subgraph "发送端" A1[API调用] A2[curl命令] A3[第三方服务] A4[群机器人兼容] end subgraph "PushMe服务器" B1[HTTP API 端口3010] B2[WebSocket服务] B3[消息队列] B4[push_key管理] end subgraph "接收端" C1[Android客户端] C2[Windows客户端] C3[Telegram机器人] end A1 -->|HTTP POST| B1 A2 -->|HTTP POST| B1 A3 -->|HTTP POST| B1 A4 -->|HTTP POST| B1 B1 --> B3 B3 --> B2 B2 -->|WebSocket| C2 B2 -->|原生推送| C1 B2 -->|Bot API| C3 C1 -->|确认回执| B4 C2 -->|确认回执| B4架构说明：发送端：支持多种消息来源API 调用：任何支持 HTTP 的编程语言curl 命令：命令行直接发送第三方服务： webhook 集成群机器人兼容：可直接替换企业微信/钉钉/飞书群机器人地址PushMe服务器：核心消息中继HTTP API（端口3010）：接收消息推送请求WebSocket服务：实时推送给桌面客户端消息队列：处理离线消息push_key管理：用户身份验证接收端：多终端消息同步Android客户端：原生推送接收Windows客户端：WebSocket 实时接收Telegram机器人：跨平台消息转发技术栈分析服务器端（PushMeServer）组件技术选型运行时Node.js >= 16进程管理PM2部署方式Docker / 源码安装通信协议HTTP + WebSocket消息格式JSON端口分配：3010：Web管理界面、消息发送 API、WebSocket 服务（管理员和 Windows 客户端）3100：消息服务端口（Android 客户端连接）Android 客户端特性说明系统要求Android 7+开发方式原生 Android 开发安装包大小< 3M后台保活支持多种 ROM 的后台保活设置后台保活策略：权限管理：允许自启动、后台运行电池管理：允许后台高耗电（实测耗电低）通知管理：允许消息通知Android 12+：需开启 alarm 闹钟权限部分手机：关闭后台网络优化消息类型支持type 参数类型说明text通知消息普通文本消息markdown通知消息Markdown 格式文本消息html通知消息HTML 格式消息data数据消息数据可视化（支持 data/markdata/chart/echarts 格式）核心功能分析1. push_key 认证机制push_key 是 PushMe 的核心认证机制，用户在 Android 客户端生成后，即可用于 API 调用。这种设计避免了传统账号体系的复杂性：获取流程：安装APP → 生成push_key → 复制使用 → 发送消息优势：无需注册登录密钥即身份支持多设备独立密钥2. 消息通道机制PushMe 支持自定义消息通道，用户可以为不同来源的消息设置：不同的通知声音不同的震动模式不同的通知样式应用场景：监控告警：使用紧急提醒消息通知：使用普通提示定时任务：使用静默通知3. 插件系统PushMe 支持插件开发，允许用户对收到的消息进行加工处理：// 插件开发示例（概念） function processMessage(message) { // 自定义处理逻辑 return modifiedMessage; }4. 消息转发支持将手机端收到的消息转发到电脑端：Android 客户端接收消息通过 WebSocket 转发到 Windows 客户端实现跨设备消息同步API 接口发送消息接口请求地址：POST https://push.i-i.me/请求参数：参数描述必填push_key接口密钥是title消息标题与 content 至少填一项content消息内容与 title 至少填一项type消息类型（text/markdown/html/data）否topic消息主题（info/success/warning/error）否示例请求：# 发送文本消息 curl -X POST "https://push.i-i.me/" \ -d "push_key=YOUR_PUSH_KEY" \ -d "title=测试标题" \ -d "content=测试内容" # 发送 Markdown 消息 curl -X POST "https://push.i-i.me/" \ -d "push_key=YOUR_PUSH_KEY" \ -d "title=Markdown测试" \ -d "content=# 标题\n**加粗**内容" \ -d "type=markdown"兼容性接口PushMe 接口兼容企业微信/钉钉/飞书群机器人，可直接替换 webhook 地址：# 原企业微信机器人 webhook = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=XXX" # 替换为 PushMe webhook = "https://push.i-i.me/?push_key=YOUR_PUSH_KEY"部署方案Docker 部署docker run -dit \ -p 3010:3010 \ -p 3100:3100 \ -v $PWD/pushme-server/config:/pushme-server/config \ --name pushme-server \ --restart unless-stopped \ node:16.20.2-alpine3.17源码部署# 环境要求：nodejs >= 16 npm i --registry=https://registry.npmmirror.com npm i pm2 -g --registry=https://registry.npmmirror.com pm2 start server.js --name pushme-server pm2 save pm2 startup应用场景1. 服务监控告警# 服务器监控脚本 curl -X POST "https://push.i-i.me/" \ -d "push_key=YOUR_KEY" \ -d "title=服务器告警" \ -d "content=CPU使用率超过90%" \ -d "topic=error"2. 自动化脚本通知# Python 脚本集成 import requests def send_notification(title, content): requests.post("https://push.i-i.me/", data={ "push_key": "YOUR_KEY", "title": title, "content": content })3. CI/CD 流程通知# Jenkins Pipeline stage('Notification') { steps { sh """ curl -X POST "https://push.i-i.me/" \ -d "push_key=\${PUSH_KEY}" \ -d "title=构建通知" \ -d "content=项目 \${JOB_NAME} 构建完成" """ } }技术优势与局限优势零门槛使用：无需注册登录，获取 push_key 即可轻量高效：安装包小，资源占用低自建可控：支持私有部署，数据安全可控多端同步：Android + Windows + Telegram 全覆盖扩展性强：支持插件和自定义通道局限后台保活依赖 ROM：部分国产 ROM 后台管理严格无官方 iOS 客户端：仅支持 Android消息历史有限：离线消息存储容量有限自建需技术能力：私有部署需要 Node.js 环境与同类方案对比方案部署复杂度终端支持消息可靠性自定义能力PushMe低Android/Windows中高Server酱低微信中低Bark低iOS高中Gotify中全平台高高企业微信机器人低全平台高中总结PushMe 是一个设计精良的个人消息推送解决方案，通过简单的 push_key 机制实现了零门槛的消息推送能力。其模块化的架构设计（Android 客户端 + Node.js 服务器 + Windows 客户端）使得用户可以根据需求灵活选择部署方式。对于个人开发者和小型团队而言，PushMe 提供了一个开箱即用的消息通知平台，特别适合：服务器监控告警自动化脚本通知CI/CD 流程集成个人消息聚合项目的开源特性（MIT 许可）和完善的文档支持使其成为一个值得推荐的技术选择。参考资源GitHub 项目: yafoo/pushme服务器端: yafoo/pushme-server官方网站: push.i-i.me接口文档: push.i-i.me/docs/index
nasa42/Webterm 终端穿透访问技术分析项目概述Webterm 是一个用 Rust 编写的轻量级工具，旨在提供安全的、基于浏览器的远程终端访问能力。该项目主要解决防火墙后、私有网络或动态 IP 环境下的服务器访问问题。项目地址：https://github.com/nasa42/webterm官方状态：早期开发阶段，不建议生产环境使用。核心问题分析问题定义传统 SSH 访问在以下场景存在限制：防火墙限制：入站连接被阻止私有网络：设备仅拥有私有 IP（如负载均衡器或 NAT 后）端口限制：无法开放或转发额外端口动态 IP：家庭服务器 IP 频繁变化客户端限制：受限环境无 SSH 客户端解决方案核心Webterm 通过三层架构解决上述问题：Agent：运行在目标设备上的轻量级二进制程序Relay：无状态中继服务器，仅转发加密数据Frontend：静态前端网站，通过浏览器访问系统架构架构图组件说明组件技术实现作用AgentRust 二进制在设备上运行，保持与 Relay 的持久 WebSocket 连接Relay无状态服务器路由 Agent 与 Frontend 之间的通信Frontend静态网站浏览器端终端界面数据流向用户浏览器 --[WebSocket]--> Relay --[WebSocket]--> Agent --> PTY 会话认证与加密机制认证流程零知识证明认证Agent 使用 Device Name 和 Secret Key 向 Relay 注册Frontend 请求连接时，Relay 向 Agent 转发请求Agent 使用零知识证明验证 Frontend 身份密钥不传输：原始 Secret Key 永不通过网络传输加密方案机制实现方式密钥派生PBKDF2传输加密AES256-GCM中继安全零信任（仅转发加密数据）技术特性性能特点内存占用：空闲时低于 10 MB通信协议：FlatBuffers 高效序列化持久会话：支持数天/数周后重连安全特性端到端加密：所有通信使用 AES256-GCM零信任中继：Relay 无法读取消息内容静态前端：未压缩代码便于审计自托管支持：可自行部署 Relay 和 Frontend功能特性多终端支持：单设备多会话设备子名称：多设备共享同一 Device NameIP 变更容忍：设备 IP 变化不影响连接部署与使用快速安装# 安装 Agent curl -sSfL https://webterm.run/install.sh | bash # 启动 Agent webterm-agent --device-name <DEVICE_NAME> --secret-key <SECRET_KEY>访问终端访问 https://webterm.run 并使用相同凭据连接。与 SSH 对比维度SSHWebterm网络要求需开放端口仅需出站连接客户端SSH 客户端浏览器会话持久否是动态 IP不友好支持审计能力依赖日志流计划支持应用场景远程访问：浏览器安全连接服务器容器管理：无需开放网络端口管理 Docker嵌入式/IoT：树莓派等低功耗 Linux 系统个人设备：家庭服务器或笔记本远程访问发展路线[ ] SSO 单点登录集成[ ] 文件浏览器功能[ ] 审计日志记录[ ] 实时服务器指标[ ] 自定义插件支持[ ] Relay 故障转移与负载均衡技术分析总结优势网络穿透能力强：解决传统 NAT 穿透问题安全性设计完善：零知识证明 + 端到端加密资源占用极低：适合资源受限环境跨平台访问：仅需现代浏览器风险与限制项目早期阶段：功能不完整，API 可能变化依赖中继服务：默认使用 webterm.run 公共中继仅支持 Linux：当前仅支持基于 Linux 的系统架构启示Webterm 的三层架构设计体现了现代 Web 应用在受限网络环境下的创新解决方案：反向连接模式：Agent 主动连接 Relay，避免入站端口需求加密数据平面：中继仅转发，无法窃听状态最小化：Relay 无状态设计便于横向扩展参考资料项目仓库：https://github.com/nasa42/webterm官方网站：https://webterm.run
VibeTunnel 技术分析：浏览器终端代理平台一、核心问题定义在现代 AI 开发工作流中，开发者面临三个关键痛点：远程监控需求：AI agent 执行长时间任务时，开发者需要离开开发环境但仍需监控进度跨设备访问障碍：从移动设备或不同终端访问本地开发环境需要复杂的 SSH 配置Agent 协作复杂性：多个 AI agent 同时工作时，缺乏统一的会话管理和监控界面VibeTunnel 通过"将浏览器转换为终端"的核心理念，为这些问题提供了零配置的解决方案。二、系统架构分析2.1 三层架构设计graph TD subgraph 客户端层 A[浏览器 Web UI] B[iOS App] C[移动浏览器] end subgraph 传输层 D[WebSocket 连接] E[Tailscale VPN] F[ngrok 隧道] end subgraph 服务端层 G[Node.js 服务器] H[PTY 分配器] I[会话管理器] end subgraph 系统集成层 J[macOS 菜单栏 App] K[Git Hooks] L[终端会话] end A --> D B --> D C --> D D --> E D --> F E --> G F --> G G --> H G --> I I --> K H --> L J --> G2.2 核心组件分解组件技术栈职责macOS AppSwift服务器生命周期管理、菜单栏集成Web ServerTypeScript/Node.js终端会话处理、WebSocket 通信Web FrontendLit + ghostty-web终端渲染、会话 UIPTY Controllernode-pty伪终端分配、I/O 转发2.3 vt 命令转发机制sequenceDiagram participant User as 用户终端 participant VT as vt wrapper participant Server as VibeTunnel Server participant Browser as 浏览器界面 User->>VT: vt npm run dev VT->>VT: 解析别名/函数 VT->>Server: 创建会话请求 Server->>Server: 分配 PTY Server-->>Browser: WebSocket 推送 Browser->>Browser: 渲染终端输出 User->>VT: 输入命令 VT->>Server: 转发输入 Server-->>Browser: 实时更新vt 命令的智能特性：别名解析：自动展开 shell 别名（如 vt gs → git status）Shell 检测：智能路由到最佳实现（Mac App 优先于 npm 版本）标题管理：三种模式（static/filter/none）控制终端标题行为三、关键功能实现3.1 Git Follow Mode这是 VibeTunnel 最具创新性的功能，解决了 AI agent 使用 Git worktree 时的同步问题。工作原理：在 worktree 中执行 vt follow 安装 Git hooks（post-commit、post-checkout）主仓库通过 Git config 存储被跟踪的 worktree 路径当 worktree 切换分支时，hooks 触发主仓库自动 checkout实际价值：传统工作流： Agent 在 worktree 工作 → 切换分支 → 主仓库 IDE 失效 → 需要重启服务器 VibeTunnel 工作流： Agent 在 worktree 工作 → 切换分支 → 主仓库自动跟随 → IDE 继续运行3.2 多重远程访问方案方案安全性配置复杂度适用场景Tailscale Private最高（端到端加密）低个人设备间访问Tailscale Public高（HTTPS）中临时分享会话ngrok高（HTTPS）低快速公网暴露Cloudflare Tunnel高中企业级部署3.3 认证系统架构graph LR A[客户端请求] --> B{认证模式检查} B --> C[系统认证] B --> D[环境变量] B --> E[SSH 密钥] B --> F[无认证] B --> G[本地绕过] C --> H[PAM/macOS 本地用户] D --> I[VIBETUNNEL_USERNAME/PASSWORD] E --> J[~/.ssh/authorized_keys] F --> K[仅受信任网络] G --> L[localhost + token 可选] H --> M[会话创建] I --> M J --> M K --> M L --> M四、技术实现细节4.1 会话管理每个终端会话的核心状态结构：interface Session { id: string; // 唯一会话标识 pty: IPty; // node-pty 实例 title: string; // 会话标题 titleMode: 'none' | 'filter' | 'static'; isActive: boolean; // 基于 I/O 活动的状态 lastActivity: Date; // 用于 idle 检测 recordingPath: string; // asciinema 录制文件路径 }4.2 WebSocket 通信协议消息类型：stdin: 浏览器输入转发到 PTYstdout: PTY 输出推送到浏览器resize: 终端尺寸变更title: 终端标题更新activity: 活动状态变化4.3 macOS 权限处理系统使用分离的 Bundle ID 处理 Debug/Release 版本权限：Production: sh.vibetunnel.vibetunnelDebug: sh.vibetunnel.vibetunnel.debug这允许同时安装两个版本而互不干扰权限状态。五、部署与使用场景5.1 典型使用场景AI Agent 监控：从手机监控 Claude Code、Cursor 等 AI agent 的执行进度远程构建监控：在移动时查看长时间运行的编译/测试任务协作调试：与同事共享终端会话进行实时协作CI/CD 集成：通过 npm 包在容器或 CI 环境中暴露终端5.2 安装选项对比方式系统要求优势限制macOS AppApple Silicon M1+菜单栏集成、自动更新不支持 Intel Macnpm PackageNode.js 22.12+Linux 支持、Docker 友好无菜单栏集成源码构建Xcode 16+完全定制化配置复杂六、安全考量6.1 安全最佳实践生产环境必须使用认证# 推荐：SSH 密钥认证 vibetunnel --enable-ssh-keys --disallow-user-password # 或：环境变量 + HTTPS VIBETUNNEL_USERNAME=admin VIBETUNNEL_PASSWORD=$(openssl rand -base64 32)避免本地绕过模式：--allow-local-bypass 仅用于开发HTTPS 强制：生产环境通过 nginx/Caddy 提供 HTTPS日志监控：定期检查 ~/.vibetunnel/log.txt 中的异常认证模式6.2 Tailscale 集成安全模型graph TD A[用户设备] -->|WireGuard 加密| B[Tailscale 中继] B -->|端到端加密| C[Mac 上 VibeTunnel] C --> D[本地 PTY 会话] style A fill:#e1f5e1 style B fill:#ffe1e1 style C fill:#e1e1ff style D fill:#fff4e1安全优势：流量不经过公网（Private 模式）自动证书管理零配置 NAT 穿透七、性能与可扩展性7.1 性能优化策略嵌入式 Node.js：将服务器打包为单文件可执行程序自定义 Node 构建：可选的 46% 体积缩减（61MB vs 107MB）esbuild 打包：毫秒级热重载（开发模式）活动检测优化：基于 I/O 时间戳的高效状态判断7.2 资源占用组件典型内存占用CPU 使用率空闲服务器~30-50MB<0.1%单个活跃会话+5-10MB0.5-2%Web UI~20MB浏览器进程八、生态集成8.1 Poltergeist 自动构建VibeTunnel 可与 Poltergeist 集成实现自动重建：poltergeist # 监控 Swift/Xcode 文件变化并自动重建8.2 开发者工具链# 代码覆盖率测试 ./scripts/test-all-coverage.sh # 开发服务器（外网设备测试） cd web && pnpm run dev --port 4021 --bind 0.0.0.0 # DerivedData 构建优先级 export VIBETUNNEL_PREFER_DERIVED_DATA=1 vt your-command九、技术债务与未来方向9.1 当前限制Windows 不支持：计划支持（issue #252）iOS App 仍在开发：不建议生产使用热模块替换缺失：需要手动刷新浏览器9.2 未来改进方向Vite 迁移：实现真正的 HMR多会话标签页：改进并行任务管理会话录制回放：增强 asciinema 集成WebRTC 支持：更低延迟的终端传输十、总结VibeTunnel 代表了终端工具的演进方向：从"本地命令行"到"云端可访问的工作空间"。其核心创新在于：零配置哲学：通过 Tailscale/ngrok 等现代网络工具消除复杂的端口转发配置Agent 友好设计：Git Follow Mode 等 AI 原生功能多平台一致性：macOS App、npm 包、源码构建多种部署方式随着 AI agent 在开发流程中的普及，VibeTunnel 这样的工具将成为基础设施，弥合本地开发环境与远程访问需求之间的鸿沟。参考资料项目仓库：https://github.com/amantus-ai/vibetunnel官方文档：https://vt.shTailscale 文档：https://tailscale.com/kb/1112/funnel/asciinema 格式规范：https://asciinema.org/docs/advanced