AI

在 Ubuntu Server 上通过 Docker Compose 部署 OpenClaw，并接入反向代理

本文记录一次完整的 OpenClaw 部署过程：使用 Ubuntu Server 24.04，以 Docker Compose 管理 OpenClaw，将服务部署到一台内网主机，再通过另一台反向代理主机对外提供 HTTPS 访问。 文中的以下信息均已脱敏： 但是部署逻辑、命令顺序、踩坑过程都保留了，照着改成自己的值即可复现。 一、部署目标 目标架构如下： 二、环境信息 本文部署环境： 脱敏后的示例变量如下： INSTALL_DIR=/opt/docker/openclawCONFIG_DIR=/opt/docker/openclaw/data/configWORKSPACE_DIR=/opt/docker/openclaw/data/workspaceHOST_IP=192.168.100.10REVERSE_PROXY_IP=192.168.100.20HOST_PORT=10443PUBLIC_DOMAIN=openclaw.example.com 实际部署时，把这些替换成自己的值。 三、最终拓扑 最终结构如下： 浏览器 ↓ HTTPS / WSShttps://openclaw.example.com ↓反向代理主机（REVERSE_PROXY_IP） ↓ 反代到http://HOST_IP:HOST_PORT ↓OpenClaw Gateway（Docker 容器内固定监听 18789） 四、为什么选择 Docker Compose OpenClaw 官方本身就提供 Docker 方式，适合以下场景： 对我来说，Docker Compose 的优势主要在于： 五、准备工作 先安装基础组件： apt updateapt install …

AI

OpenClaw 及其替代方案梳理

一、问题背景 OpenClaw 属于一类“可执行任务的 AI Agent 框架”，核心能力是：通过大模型驱动，实现自动调用工具、执行命令、完成复杂任务流程。 但在实际使用过程中，这类系统暴露出明显问题： 因此，出现了大量替代方案，其核心方向不是“更强”，而是：在能力与安全之间重新平衡 二、同类替代方案（直接对标 OpenClaw） 1. 安全强化型 这一类是最接近 OpenClaw，但重点解决安全问题： 特点总结： 2. 云托管方案 这类方案放弃本地执行，转向云端： 特点： 但代价是： 三、工作流型替代（不同思路） 这类工具不强调“自主 Agent”，而是“可控流程”。 n8n + AI 优点： 缺点： 无代码工具 特点： 四、当前生态的真实情况 OpenClaw 的优势 但核心问题明显 因此行业趋势已经很清晰： 从“完全自动执行” → 转向“受控执行 + 沙箱隔离” 五、选择建议 如果以“长期稳定运行”为目标，可以按如下思路选择： 优先方案 可尝试方案 不建议 六、本质总结 这一类工具的核心不是“哪个更强”，而是： 如何让 AI 有执行能力，同时不失控 …

AI

NotebookLM 作为资料驱动型知识工作台的结构化分析

——功能机制、应用路径与局限性评估 摘要 在大语言模型逐渐成为通用工具的背景下，如何降低“幻觉风险”、提升可追溯性、并将人工智能嵌入日常知识工作流程，成为实践层面的核心问题。本文围绕 Google 推出的 NotebookLM 展开分析，从其技术理念、功能结构、工作机制与应用场景出发，探讨其在“资料驱动型知识处理”中的定位与边界。文章采用论文式结构进行论述，以明确逻辑框架与应用路径。 一、研究背景：从生成式对话到资料驱动型系统 传统大语言模型（LLM）在通用问答场景中表现优异，但存在两个结构性问题： 为解决上述问题，Google 推出 NotebookLM，其核心理念并非“更强的对话能力”，而是： 以用户导入资料为知识边界，围绕该边界进行总结与问答。 该理念改变了 AI 的使用范式：从“开放式知识生成”转向“封闭式资料重构”。 二、系统机制：Source-grounded 架构逻辑 NotebookLM 的运行逻辑可以概括为三层结构： 2.1 输入层：资料边界设定 用户导入资料（PDF、Google Docs、网页链接等）后，系统建立一个“语料域（Corpus Domain）”。该域构成模型回答问题的知识范围。 这一机制意味着： 2.2 处理层：语义压缩与重组 在处理层，系统完成三项核心任务： 这一流程类似于“增强型检索生成”（RAG）框架，但强调资料内闭环。 2.3 输出层：结构化呈现 输出通常表现为： 系统设计目标是：提高知识工作效率，而非提供开放式知识探索。 三、核心功能分析 3.1 资料问答功能 该功能允许用户围绕资料进行深度提问，例如： 与通用 AI 不同的是，回答具有“来源锚点”。这在法律、金融、技术文档分析等领域具有实际意义。 3.2 自动总结与结构化生成 NotebookLM 的优势不在于单句摘要，而在于“结构重构能力”： 该能力本质上属于认知负荷压缩工具。 3.3 Audio Overview：认知模式转换 NotebookLM …

AI

从二维到三维：SAM 3D 模型技术解析

在计算机视觉领域，图像分割已经发展多年。而随着三维重建与空间理解需求的增长，研究开始从“识别图像中的对象”走向“理解对象的三维结构”。Segment Anything Model（SAM） 的出现，本质上解决了“通用分割”问题。而在此基础上发展的 SAM 3D，则进一步尝试解决： 如何从二维图像推断三维结构。 本文将从原理、结构、能力与应用几个层面，对 SAM 3D 进行系统梳理。 一、技术背景：从 2D 分割到 3D 重建 传统的 3D 重建通常依赖： 而 SAM 3D 的核心思想是： 利用大规模预训练视觉模型的先验知识，从单张图像中推断三维结构。 这并不是“真实测量”，而是基于深度学习的结构推断与形状补全。 二、SAM 3D 的核心能力 1️⃣ 单图 3D 推断 输入： 输出： 这是 SAM 3D 的核心突破之一。 2️⃣ 基于分割的三维重建 SAM 3D 并不是独立模型，而是建立在 SAM 分割能力之上： 这种“先分割、再升维”的流程，使得模型具有更强的可控性。 三、模型结构概览 虽然具体实现会因版本不同而变化，但总体结构可以概括为： 图像编码器 (Vision …

AI

使用 Docker 部署 n8n 的完整实践记录（含反向代理与 LLM 接入）

一、目标架构 部署一个具备以下能力的自动化系统： 整体逻辑结构如下： 并额外接入： 二、数据库初始化陷阱 问题表现 原因 PostgreSQL 在首次启动时会根据环境变量初始化数据库。 之后即使修改密码，容器也不会重新初始化。 解决方式 删除数据库数据卷后重新启动。 关键原则： 数据库初始化仅进行一次。 三、数据库角色冲突问题 错误示例： 产生原因： 正确结构： 两者必须分离。 四、反向代理导致的两个典型问题 1️⃣ 邀请链接错误指向 localhost 现象： 新用户邀请链接使用 localhost 原因： 未正确设置外部访问环境变量。 必须显式配置： 否则系统默认生成本地地址。 2️⃣ X-Forwarded-For 报错 日志示例： 原因： 反向代理转发了客户端 IP但应用未信任代理 解决方式： 设置 trusted proxies。 是否可以忽略？ 五、浏览器安全提示差异 现象： 分析： 结论： 多半为浏览器本地安全数据库或版本问题。 更新浏览器即可解决。 六、容器间网络通信（LLM 接入） …

AI

自动化方案全景对比：从 AI 平台到工作流引擎的系统分析

随着自动化需求的增长，个人与组织可选择的技术方案越来越多。从 AI 应用平台到通用工作流编排引擎，再到企业级调度系统和传统脚本方式，不同工具在能力边界、扩展性、运维复杂度和适用场景上存在显著差异。 本文对主流自动化方案进行统一维度对比，涵盖： 一、AI 导向平台 1. Dify 定位AI 应用与大语言模型工作流平台。 核心能力 优势 局限 适用场景 2. Hugging Face Workflows 定位模型工作流组合平台。 核心能力 局限 适用场景 二、通用自动化工作流平台 3. n8n 定位开源自动化编排引擎。 核心能力 优势 局限 适用场景 4. Node-RED 定位可视化事件驱动自动化工具。 优势 局限 适用场景 5. Huginn 定位开源事件代理系统。 优势 局限 适用场景 三、SaaS 自动化平台 6. Zapier 定位云端自动化平台。 优势 局限 适用场景 …

AI

OpenWebUI 多模态与模型管理实践记录

背景 在 OpenWebUI 中同时接入本地模型（Ollama）与云端模型（OpenAI External）后，模型列表会显著膨胀，包含大量历史版本、兼容别名与专用用途模型。本文记录一种低心智负担、可长期使用的配置与使用方式，并解释多模态能力的实际用法。 一、为什么模型会“突然变多” 当 OpenWebUI 的 OpenAI 连接中 Model IDs 留空 时，系统会直接拉取 OpenAI /v1/models 的全量结果，其中包含： 这是 API 工程级清单，并非“用户选择列表”。数量增加并不代表配置错误。 二、真正需要关注的模型类别 1. 日常文本与思考 覆盖绝大多数文本任务。 2. 多模态（图文理解） 用法：在对话中拖入图片，配合文字提问即可完成“看图说话”。 3. 图像生成（文 → 图） 说明：该模型为单向生成模型，仅用于画图，不用于聊天或分析。 4. 可忽略的模型 这些模型不影响日常使用，可完全忽略。 三、两种可行的模型管理策略 策略 A：自动更新（省心） 适合：不想维护配置、只关心可用性。 策略 B：极简清单（推荐） 在 Settings → Connections → OpenAI → Model …

AI

OpenAI API Key 管理实践：为 OpenWebUI 与 Dify 分离创建 Key

一、背景说明 在本地或自托管环境中同时部署 OpenWebUI 与 Dify 时，二者都会涉及对 OpenAI API 的调用。如果使用同一个 API Key： 因此，更合理的做法是：为不同服务分别创建并使用独立的 API Key。 二、API Key 是否可以免费创建 OpenAI 平台允许用户： 但需要注意的是： 因此，创建多个 Key 并不会带来额外的免费调用额度。 三、是否可以创建多个 API Key 结论很明确： 这使得 API Key 可以作为逻辑隔离工具，而不是计费隔离工具。 四、推荐的 Key 划分方案 针对常见的自托管 AI 使用场景，推荐至少划分如下两类： 使用场景 API Key OpenWebUI（交互式对话） openwebui Dify（应用 / Workflow / Agent） dify 原则非常简单： 一服务一 …

AI

使用 ChatGPT API 构建自托管 AI 系统：与官方 ChatGPT 的全面对比

一、两个体系的本质区别 1. 官方 ChatGPT 官方 ChatGPT 是一个面向终端用户的一体化产品，核心特点是： 用户只需登录账号，即可直接使用文字、语音、图片、文件等能力，无需关心模型选择、上下文管理或计费细节。 2. ChatGPT API ChatGPT API 是一个面向开发者和系统构建者的能力接口，核心特点是： API 更像“发动机”，而不是“整车”。 二、账号与计费体系 账号关系 计费关系 两者可以同时使用，互不替代。 三、能力对比（模型层 vs 产品层） 模型能力 在模型层面： 差异主要来自产品层封装，而非模型本身。 四、多模态能力（图片 / 文档 / 截图） 官方 ChatGPT 的表现 这些能力对用户而言是“无感”的。 API 的实际情况 当前 OpenAI 的新一代 API 已原生支持多模态： 但需要注意： API 只提供能力，不提供完整交互体验 是否“好用”，高度依赖前端是否支持： 这也是为什么多数开源前端在体验上仍与官方存在差距。 五、语音能力 官方 ChatGPT …

AI

Dify 使用入门：从安装到真正可用的最小路径

一、结论先行：Dify 是什么？ 一句话概括： Dify 是一个“将大模型封装为应用”的平台。 它本身并不提供模型推理能力，也不是单纯的聊天界面，而是位于模型之上的应用与编排层，主要作用包括： 在常见的本地 LLM 架构中，其角色可以抽象为： 简化理解： 交互层解决“如何对话” Dify 解决“让 AI 持续按同一规则工作” 二、什么时候需要 Dify？ 不适合引入 Dify 的情况 当使用目标主要是： 此时，引入额外的应用层意义不大。 Dify 的适用场景 Dify 更适合以下需求： 其核心价值在于：长期一致性与可控性。 三、学习 Dify 的正确主线 应用 → 行为规则（Prompt） → 数据接入 学习顺序非常关键。 不建议一开始接触复杂功能，应先理解 Dify 的最小工作模型。 四、第一步：创建最小可用应用 目标不是“功能完整”，而是： 核心原则 当应用能够正常调用模型并完成基本对话，即达到该阶段目标。 五、第二步：通过系统指令固定行为 Dify 的关键能力在于系统级指令。 系统指令的作用不是提示，而是长期生效的行为约束。 其价值在于： 示例结构（抽象）： 只要系统指令保持不变，模型行为就具有可重复性。 …