搬瓦工 VPS 上构建私有化 AI Agent 智能体应用入门指南和配置方案推荐

在大模型重构互联网的今天，手中的 VPS 是否只能沦为探针宿主或吃灰的摆设？面对 Dify 和 n8n 等 AI 应用对硬件的吞噬，传统的站长思维已不足以应对。本文将打破“AI 必须高配”的迷思，以资深 VPS 玩家的视角，探讨如何通过存算分离的架构创新与 Docker 调优，在仅有 1-2GB 内存的搬瓦工 VPS 主机环境中，稳定托管庞大的现代化 AI 智能体平台。这不是一篇简单的安装教程，而是一场关于如何榨干硬件性能、实现从 Web Server 向 Reasoning Server 华丽转身的技术突围战。

• 核心应用： Dify / n8n / FastGPT
• 关键架构： Docker Compose + 存算分离 (Supabase)
• 硬件环境： BandwagonHost (1C/2G/CN2 GIA)

一、序言：从 Webmaster 到 AIMaster 的身份跃迁

在过去二十年的互联网发展史中，”站长”这个称谓承载了无数技术爱好者的光荣与梦想。从早期的 Discuz! 论坛时代，到 WordPress 博客盛世，再到后来的静态网站与 Jamstack 浪潮，我们手中的 VPS 始终扮演着”内容宿主”的角色。我们精心优化 Nginx 配置，为了几十毫秒的 TTFB（Time To First Byte）调整 TCP 拥塞控制算法，为了节省几兆内存而精简 PHP 扩展。那是一个以”展示”为核心的时代，VPS 的使命是将静态或动态的内容尽可能快地分发给访客。

然而，2023 年以来的 AI 浪潮彻底重构了这一逻辑。随着大语言模型 (LLM) 的 API 化以及 Agent（智能体）概念的兴起，VPS 的角色正在经历一场从 Web Server 到 Reasoning Server（推理服务节点）的深刻跃迁。今天的站长，不再仅仅满足于搭建一个用于阅读的博客，而是渴望拥有一套属于自己的、能够处理复杂逻辑、自动化执行任务、甚至具备一定思考能力的数字员工体系。

如果你和我一样，手中握有一台或多台搬瓦工的传家宝机器——也许是当年 49.99 刀的 CN2 GIA 限量版，或者是后来补货的 The Plan——你可能会面临一个幸福的烦恼：这些线路极佳但硬件资源（特别是内存）相对捉襟见肘的机器，如何在 AI 时代焕发第二春？

本文以一位资深 VPS 玩家的视角，剥离掉市面上那些虚无缥缈的 AI 概念与资本泡沫，专注于实操与架构。我们将深入探讨如何在资源受限的环境中，通过精细化的架构设计与极限压榨的运维技巧，自行托管 n8n、Dify、FastGPT 等顶级 AI Agent 平台。这不仅仅是一篇安装教程，更是一份关于如何在云端构建属于你自己的”数字员工”体系的架构白皮书。我们将直面核心痛点：如何在 1GB 至 2GB 内存的紧约束下，让庞大的现代化 AI 应用跑得稳定、跑得流畅。

二、选型篇：自托管 AI 应用的生态图谱

在 SSH 连上服务器敲下第一行 Docker 命令之前，我们必须先解决”装什么”的问题。GitHub 上标榜自己是 “Next Gen AI Platform” 的项目多如过江之鲫，但真正具备生产力属性、社区活跃且适合个人站长维护的，其实屈指可数。

不同的 AI Agent 平台有着截然不同的基因。有的源于工作流自动化工具的进化，有的则是为了解决 RAG（检索增强生成）难题而生。为了避免在错误的工具上浪费时间，我们需要对它们进行庖丁解牛般的深度剖析。

2.1 核心选手深度解析：场景、架构与资源消耗

1. Dify.AI —— AI 原生应用的中枢神经

Dify 无疑是目前开源界最耀眼的明星之一。它的核心价值在于提供了一套完整的 LLM Ops（大模型运营） 栈。对于站长而言，Dify 不仅仅是一个聊天机器人，它是一个能够让你把 Prompt（提示词）、Context（上下文）、Plugins（插件）和 Model（模型）像乐高积木一样拼装起来的”军火库”。

• 核心场景与用途：
  • 深度 RAG 应用：如果你需要建立一个基于私有文档（PDF、Markdown、Notion）的问答系统，Dify 内置的知识库切片、清洗、向量化流程是目前开源界体验最好的。它屏蔽了底层 LangChain 的复杂性，让你专注于数据本身。
  • Agent 编排：Dify 的 Agent 模式支持工具调用（Function Calling）。你可以让它查天气、搜索 Google、读取网页，甚至调用你自己写的 API。
  • BaaS (Backend as a Service)：站长可以直接利用 Dify 生成的 API 接口，为自己的前端应用（如小程序、Web 站）提供 AI 能力，而无需自己写后端 Python 代码。
• 架构与资源隐患：Dify 的强大是有代价的。它的架构非常”重”，默认部署包含以下容器：
  • api: 后端核心，Python 编写，内存大户。
  • worker: 异步任务队列，处理文档解析和长任务，也是内存大户。
  • web: 前端 Next.js 服务。
  • db: PostgreSQL 数据库。
  • redis: 缓存与队列。
  • weaviate/qdrant/milvus: 向量数据库（这是资源消耗的无底洞）。
  • sandbox: 代码执行沙箱。
  • 站长建议：官方推荐 4GB 内存起步。在搬瓦工 2GB 机器上硬跑全套架构几乎 100% 会导致死机，必须采用”存算分离”策略（后文详述）。当然也可以直接购买 4GB 起步的配置。

2. n8n —— 自动化流程的”万能胶水”

n8n 本质上是一个工作流自动化工具（Workflow Automation Tool），对标的是 Zapier 或 Make。但自 2023 年引入 LangChain 节点以来，它迅速成为了构建 Task-Oriented Agent（任务导向型智能体） 的神器。

• 核心场景与用途：
  • 流程串联：“当 RSS 更新时 -> 读取文章内容 -> 用 GPT-4 总结 -> 发送到邮箱”。这种线性的、涉及多个外部系统交互的任务，n8n 是无敌的。
  • 数据清洗与ETL：在把数据喂给 AI 之前，往往需要复杂的格式化、过滤、API 请求，n8n 提供了 400+ 官方集成节点，是连接旧世界（MySQL、WordPress、Email）与新世界（LLM）的桥梁。
  • 轻量级 Agent：n8n 新增的 AI Agent 节点支持 Memory（记忆）、Tools（工具），可以构建具备一定自主决策能力的 Bot。
• 架构与资源优势：n8n 是基于 Node.js 构建的，架构相对单体且紧凑。
  • 资源消耗：相对亲民。在无大量并发任务时，纯净的 n8n 容器在 1GB 内存下配合 Swap 可以勉强运行，2GB 则非常舒适。它是目前”性价比”最高的 AI 编排工具。

3. FastGPT —— 垂直领域的知识库专家

相比 Dify 的大而全，FastGPT 走的是”小而美”的路线（虽然其底层依赖并不小）。它专注于知识库问答这一垂直场景，且在中文处理优化上做得非常出色。

• 核心场景与用途：
  • 企业/个人知识库：它的知识库导入流程非常直观，且支持混合检索（关键词+向量）和重排（Rerank），往往能获得比默认设置的 Dify 更好的回答准确率。
  • 客服机器人：界面极其清爽，适合直接丢给非技术人员使用。
• 架构与资源隐患：FastGPT 的技术栈略显独特，它重度依赖 MongoDB 来存储对话记录和知识库元数据。MongoDB 也是著名的”内存吞噬者”。同时它也需要 Postgres (pgvector) 做向量存储。这意味着你在 VPS 上不仅要跑 Postgres，还要跑 Mongo，双重数据库的压力对内存是极大的考验。

4. Flowise / LangFlow —— 极客的代码可视化实验台

这两款工具更像是 LangChain 库的 GUI 外壳。它们将代码逻辑抽象为图形化的节点，每一个节点直接对应 LangChain 的一个 Class 或 Function。

• 核心场景与用途：
  • 原型验证与学习：如果你想搞清楚什么是 “RecursiveCharacterTextSplitter” 或者 “ConversationBufferMemory”，用 Flowise 拖拽一下非常直观。
  • 极度定制化：由于贴近代码层，它能实现一些非常底层的逻辑控制。
• 架构与资源优势：通常是单体 Node.js 应用，架构简单，资源占用较低（Flowise 甚至支持 SQLite，无需重型数据库）7。但稳定性与易用性不如 Dify 和 n8n，更适合作为”玩具”或”实验台”。

2.2 全维度选型对比矩阵

为了让决策更加量化，基于大量的实测数据与社区反馈，我整理了以下对比矩阵。请注意”资源亲和度”这一指标，它直接关系到在搬瓦工 VPS 上的生存率。

AI 智能体平台格局：资源占用 vs 功能定位

三、硬件篇：搬瓦工 VPS 的配置与线路推荐

搬瓦工在 VPS 圈子里是一个特殊的存在。如果你习惯了 Hetzner、RackNerd 甚至 Contabo 那种”量大管饱”（几十欧元能买到 32GB 内存）的配置，你会觉得搬瓦工的定价简直是”抢钱”。但在 AI Agent 部署的语境下，我们必须重新审视”性价比”的定义。

3.1 为什么选择搬瓦工 CN2 GIA？

在 AI 应用的架构中，VPS 实际上充当了一个 “Coordinator”（协调者） 的角色。它向 OpenAI/Anthropic 发送请求，向你的邮箱推送消息，向你的 Notion 写入数据。

1. 管理面板的交互体验（Latancy Matters）：Dify 和 n8n 都是重前端的单页应用。尤其是 Dify 的编排界面，包含大量的 Canvas 绘图和实时状态更新。如果你的 VPS 丢包率高，或者 RTT（往返时延）波动大，每一次点击保存、每一次拖拽节点都会伴随着令人抓狂的 Loading 转圈。CN2 GIA 作为中国电信最高等级的国际出口线路，能保证在晚高峰时期，国内直连管理的体验如丝般顺滑。这一点对于需要频繁调试 Workflow 的站长至关重要。
2. API 连通性与Webhook 回调：虽然 AI 模型API通常在海外，但 Agent 的价值在于连接。如果你的 Agent 需要回调国内的服务（例如：推送到飞书、企业微信、钉钉机器人，或者连接国内的私有数据库），一条优质的回程路由是消息不丢失、低延迟的保障。搬瓦工的 DC6/DC9 机房在回程路由上有着极高的稳定性。

参考文章：《2025 搬瓦工 CN2 GIA 机房有哪些？搬瓦工 CN2 GIA/CN2 GIA-E/CTGNet 线路和套餐整理》。

3.2 套餐推荐策略：你是”土豪”还是”极客”？

搬瓦工的产品线错综复杂，且经常会有”限量版”（Limited Edition）混淆视听。根据 2025/2026 年的市场情况与库存常态，我将推荐方案分为三个梯队，分别对应不同的折腾能力与预算。

方案 A：性价比机型（可遇不可求）

• 套餐名：The Plan v2 或 The Plan 2025 Limited Edition
• 典型配置：2核 CPU / 2GB 内存 / 40GB SSD / 1000GB 流量
• 参考价格：约 $99 / 年
• 站长点评：这是目前运行 Docker 化 AI 应用的黄金标准。
  • 理由：2GB 内存是运行现代 Docker 应用的舒适区。配合合理的 Swap 设置，你可以同时跑起精简版的 Dify 和 n8n，甚至还能再挂一个极简的 Uptime Kuma 监控。
  • 购买策略：这类套餐通常是不定期的 Flash Sale。如果你看到补货，且预算允许，闭眼入。

参考文章：

1. 《2026 最新搬瓦工限量版套餐预测：MiniChicken/MiniBox/MegaBox/The Plan 等限量版套餐是否补货？》
2. 《搬瓦工 THE PLAN 限量版套餐和 CN2 GIA-E 套餐的区别/对比/可选机房差异》
3. 《搬瓦工 THE PLAN 2024 限量版套餐重磅回归！$99/年，2核/2GB/40GB SSD/1000GB，18 机房可选 限时限量回归》

方案 B：极限挑战型（技术流与备用机）

• 套餐名： DC6/DC9 CN2 GIA Limited Edition
• 典型配置： 1核 CPU / 512MB – 1GB 内存 / 20GB SSD
• 参考价格： 约 $49 – $79 / 年
• 站长点评： 1GB 甚至 512MB 能跑 AI Agent 吗？能，但极难。
  • 理由： 这种配置下，你必须具备极强的 Linux 运维能力。你必须剥离所有数据库（Postgres, Redis, VectorDB）到外部云服务，仅在 VPS 上运行无状态（Stateless）的业务容器。每一个 MB 的内存都必须精打细算。
  • 警告： 如果你是 Docker 新手，或者不懂 OOM 调优，请远离此方案。频繁的内存溢出崩溃会让你怀疑人生。

参考文章：

1. 《2026 最新搬瓦工限量版套餐预测：MiniChicken/MiniBox/MegaBox/The Plan 等限量版套餐是否补货？》
2. 《搬瓦工 Box 系列限量版套餐整理和对比：MiniBox / BiggerBox / PowerBox / SakuraBox / BiggerBox Pro / MegaBox Pro》
3. 《2024 搬瓦工所有限量版套餐整理/对比/选择推荐/购买指南：CN2 GIA-E/DC9/THE PLAN 限量版等》

方案 C：高配置大流量应用型（一步到位推荐）

• 套餐名： CN2 GIA-E，或者 CN2 GIA SLA 套餐
• 典型配置： 2.5Gbps – 10Gbps 超大带宽
• 站长点评： 如果你要做视频流生成的 AI 应用（如 Sora 类服务的中间件），或者你的网站有海量的图片/视频分发需求，或者想要一步到位，虽然 AI Agent 主要是文本交互（JSON 数据），对带宽并不敏感。但是仍然建议一步到位购买 CN2 GIA-E 系列套餐。如果对稳定性或者 SLA 有进一步要求，建议购买 SLA 套餐。

参考文章：

1. 《2025 搬瓦工 CN2 GIA 机房有哪些？搬瓦工 CN2 GIA/CN2 GIA-E/CTGNet 线路和套餐整理》
2. 《搬瓦工 DC6 CN2 GIA ECOMMERCE（CN2 GIA-E）》
3. 《搬瓦工推出全新 SLA PLAN：$65.89/季度起，全新 DC5 SLA 机房，99.99% SLA 保证，每两周可免费换 IP 地址》

CN2 GIA-E 套餐：

CN2 GIA-E SLA 套餐：

四、架构篇：如何在 2GB 内存上跳舞？——存算分离的艺术

这是本报告最核心、也最具技术含量的部分。官方文档通常建议 Dify 需要 4GB+ 内存，但在寸土寸金的 CN2 GIA VPS 上，我们必须打破常规，采用存算分离（Storage-Compute Separation）的微服务架构策略。

我们的核心思路是：将吃内存的组件（数据库、向量库）剥离出 VPS，利用互联网上免费的 Serverless 资源，只在 VPS 上运行核心业务逻辑。

4.1 传统单体架构 vs. 站长优化架构

• 官方全家桶（All-in-One Docker）：
  • VPS 内部运行：Nginx + Dify API + Dify Worker + Dify Web + Postgres + Redis + Weaviate (向量库) + Sandbox。
  • 结果：这一套下来，空载内存占用就在 3.5GB 左右。在 2GB 的 VPS 上，一旦发起请求，大量的 Swap 换入换出（Thrashing）会导致系统假死，IOwait 飙升，SSH 都连不上。
• 站长优化版（Hybrid Cloud）：
  • VPS 内部（计算层）： 只运行无状态容器——Nginx + Dify API + Dify Worker + Dify Web + Redis (可选).
  • 外部托管（存储层 – Free Tier 白嫖）：
    • Postgres + Vector DB： 使用 Supabase。
    • Redis：可使用 Upstash（Serverless Redis）或者在 VPS 上跑一个极简配置的 Redis（内存限制在 128MB）。

通过这种拆分，VPS 上的常驻内存占用可以被压缩到 1GB 左右，留出 1GB 给突发任务和系统缓存，极其稳定。

4.2 为什么选择 Supabase 作为外挂心脏？

在 Dify 和 FastGPT 的架构中，向量数据库（Vector Database）是最大的资源黑洞。本地运行 Weaviate 或 Milvus，通常需要 Java 虚拟机或者复杂的内存索引结构，这对于小内存 VPS 是不可接受的。

Supabase 的出现完美解决了这个问题：

1. Postgres 原生支持： Supabase 实际上是一个加强版的 Postgres 数据库。Dify 原生支持通过 Postgres 的 pgvector 插件进行向量检索，这意味着我们不需要额外部署 Weaviate 或 Qdrant。
2. 免费层极其良心： Supabase 的 Free Tier 提供 500MB 的数据库存储空间。对于个人站长的知识库来说（通常是几百篇文档，切片后几万个 Chunk），500MB 是海量的。相比之下，自己跑一个 Postgres 容器起步就要占用 200MB+ 内存。
3. 网络延迟可控： Supabase 的 AWS 节点（通常在美国东部或西部）与搬瓦工的洛杉矶节点（DC6/DC9）之间的延迟通常在 10-30ms 左右，对于数据库查询来说完全在可接受范围内。

4.3 架构图示：混合云部署模型

为了让你更直观地理解这种”乾坤大挪移”，请看下面的架构设计图：

[架构核心逻辑]：通过将最消耗内存的”存储层”（Postgres + pgvector）剥离到 Supabase，VPS 仅承担”计算层”（Docker 容器运行 Python/Node.js 代码）。

• 中心节点（搬瓦工 VPS）：
  • Nginx：服务器，处理 SSL 和请求缓冲。
  • Docker Engine：
    • dify-api / dify-worker：业务逻辑核心。
    • n8n：流程编排核心。
    • redis (本地)：仅作极短期缓存和队列，配置 maxmemory 限制。
• 左侧云端（Supabase）：
  • PostgreSQL：存储 Dify 的用户表、应用配置表。
  • pgvector：存储知识库的向量数据（Embeddings）。
  • 优势：0 内存占用（对 VPS 而言），500MB 免费存储。
• 右侧云端（LLM Providers）：
  • OpenAI / Anthropic / DeepSeek：提供推理能力。
  • 通过 API Key 连接。

这种架构不仅节省了 VPS 资源，还变相实现了数据备份——即使你的 VPS 被误删，只要 Supabase 的数据还在，换一台机器拉起 Docker 镜像，你的数据瞬间复活。

五、实战篇：基于 aaPanel (宝塔) + Docker 的部署指南

即使你是 Linux 老手，我也强烈建议使用面板来管理这些复杂的 Docker 容器。我们将以 aaPanel (宝塔国际版) 为例，为大家阐述一下快速部署指南。

参考文章：《搬瓦工建站教程：如何在 Ubuntu 20.04 安装 aaPanel 面板（宝塔国际版）》。

5.1 环境准备与系统级调优

在开始安装应用前，必须把这台 VPS 的底子打好。

1. 安装 aaPanel：SSH 登录搬瓦工 VPS，建议使用 Ubuntu 22.04 LTS 系统。运行官方安装脚本：

   wget -O install.sh http://www.aapanel.com/script/install-ubuntu_6.0_en.sh && sudo bash install.sh aapanel
   

2. 环境初始化：

   • 登录面板后，选择安装 Nginx (推荐 1.22+)。
   • 坚决不要安装 MySQL、PHP、FTP！除非你这台机器还要跑 WordPress。我们的目标是保持系统纯净，把每一 MB 内存都留给 AI。
   • 在面板 App Store 中安装 Docker 和 Docker Compose 插件。
3. 救命稻草：配置 Swap (虚拟内存)与内核参数对于 2GB 内存的机器，Swap 是防止 OOM 的最后一道防线。
   • Swap 设置： 在 aaPanel 首页 -> Linux Tools (或者手动终端) -> Swap/Virtual Memory。强烈建议设置为 4096MB（即内存的 2 倍）。虽然 SSD Swap 速度慢，但总比进程直接被杀掉好。
   • 内核参数调优： 修改 /etc/sysctl.conf，增加 vm.swappiness=20。默认值通常是 60，意味着系统很积极地使用 Swap。改为 20 可以让系统尽量优先使用物理内存，只有在真正紧缺时才动用 Swap，避免不必要的 IO 卡顿。

5.2 部署 Dify (极简存算分离版)

我们将修改官方的 docker-compose.yml 来适配 Supabase。

第一步：获取 Supabase 连接信息

1. 注册 Supabase 账号并创建一个新项目。
2. 进入项目 Settings -> Database -> Connection string (URI)。
3. 复制连接字符串，它看起来像这样：postgresql://postgres:@db..supabase.co:5432/postgres。
4. 关键步骤： 在 Supabase 的 SQL Editor 中执行以下命令，开启向量插件：

   create extension if not exists vector;
   

第二步：获取 Dify 代码

在 SSH 中（或通过 aaPanel 的文件管理器）：

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp.env.example.env

第三步：魔改 docker-compose.yaml

编辑 docker-compose.yaml 文件，注释掉或删除以下服务（Service）块：

• db (Postgres)
• weaviate (向量库)
• sandbox (如果你不需要跑复杂的 Python 代码沙箱，个人用可以先关掉省内存)

第四步：配置外部数据库连接 (.env)

编辑 .env 文件，填入你的 Supabase 连接信息：

# 数据库配置 (改为 Supabase 提供的参数)
DB_USERNAME=postgres
DB_PASSWORD=你的Supabase强密码
DB_HOST=db.你的项目ID.supabase.co
DB_PORT=5432
DB_DATABASE=postgres

# 向量库配置 (告诉 Dify 使用 pgvector 而不是 weaviate)
VECTOR_STORE=pgvector
# 注意：Dify 连接 Supabase 的 pgvector 复用上面的 DB 连接，无需额外配置 Weaviate 地址

第五步：启动与验证

docker compose up -d

启动后，使用 docker stats 查看。你会发现，原本需要 3-4GB 的 Dify，现在只需要 api (~300MB) + worker (~200MB) + web (~50MB) + redis (~20MB)，总占用被压到了 600MB-800MB 之间。这在 2GB 的 VPS 上简直是宽敞的。

5.3 部署 n8n (生产级 Docker 版)

n8n 的部署相对简单，但同样有内存陷阱。

1. 创建目录： mkdir -p /root/n8n/data
2. 创建 Compose 文件： 在 /root/n8n/ 下创建 docker-compose.yml：

version: '3.8'
services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=你的强密码
      - N8N_HOST=你的域名
      - WEBHOOK_URL=https://你的域名/
      - GENERIC_TIMEZONE=Asia/Shanghai
      # 核心优化：限制 Node.js 堆内存，防止垃圾回收不及时撑爆 VPS
      - NODE_OPTIONS=--max-old-space-size=1024
    volumes:
      -./data:/home/node/.n8n

• 站长经验： NODE_OPTIONS=--max-old-space-size=1024 这行代码价值千金。Node.js 默认的内存上限较高，在低配机器上容易因为 GC（垃圾回收）不及时而导致进程不断膨胀。强制限制在 1GB 可以让 V8 引擎更积极地回收内存。

六、进阶篇：站长必须知道的 Nginx 与网络微调

很多站长在部署完 AI 应用后，会遇到一个典型问题：“打字机效果”（Streaming）出不来。对话是一卡一卡，然后整段显示的。这对于 AI 体验是毁灭性的打击。这通常不是 VPS 慢，而是 Nginx 配置的问题。

6.1 解决 SSE (流式输出) 卡顿

AI 的流式输出依赖 Server-Sent Events (SSE) 技术。默认的 Nginx 配置为了优化传输效率，会开启 proxy_buffering（缓冲），也就是把后端（Dify）吐出来的字符先攒在内存里，攒够了一定大小（比如 4k）再发给浏览器。这直接导致了流式输出失效。

解决方案：

在 aaPanel 的网站设置 -> 配置文件 (Nginx Config) 中，找到 location / 块，添加以下核心指令 27：

location ^~ / {
    proxy_pass http://127.0.0.1:5678; # 指向你的 Docker 端口
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    
    # [核心优化 1] 关闭缓冲，让 AI 的每一个 Token 直接吐出来
    proxy_buffering off;
    proxy_cache off;
    
    # [核心优化 2] 支持 SSE 和 WebSocket 长连接
    proxy_set_header Connection '';
    proxy_http_version 1.1;
    chunked_transfer_encoding off;
    
    # [核心优化 3] 防止长对话超时 (设为 10 分钟以上)
    # 复杂的 RAG 检索或 GPT-4 分析可能需要几十秒，默认 60s 容易断开
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
}

为了让你更直观地理解这个机制，请参考下图：

6.2 安全加固：把你的 Agent 关进笼子

既然是个人自用，千万不要让你的 Dify/n8n 后台裸奔在公网上。Dify 的开源版本并没有极其严苛的企业级 WAF 防护。

1. Nginx Basic Auth（门神锁）：虽然 Dify 本身有账号密码，但我强烈建议在 Nginx 层再加一把锁。这样扫描器连登录页面的 HTML 都加载不出来。
   • 操作： 在 aaPanel 网站设置 -> “Site Directory” -> “Password Access”，设置用户名密码。
   • 注意： 对于 /v1/chat-messages 这类 API 路由，你需要额外写一个 location 块并设置 auth_basic off;，否则你的手机客户端或第三方应用调用 API 时会报错。
2. 防火墙策略（Firewall Discipline）：利用 aaPanel 的 Security 模块，仅开放 80, 443 和 SSH 端口。
   • 切记： Docker 映射出来的 5678 (n8n) 或 8080 (Dify) 端口，不要在防火墙放行。所有的访问必须强制经过 Nginx（Https），这样才能享受 SSL 加密和刚才配置的 Basic Auth 保护。不要图省事直接用 IP:5678 访问，那是裸奔。

七、总结与展望

作为站长，我们在 AI 时代并没有被淘汰，而是迎来了新的战场。我们从配置 PHP.ini 的参数，变成了配置 Docker 的内存限制；从优化图片的加载速度，变成了优化 Token 的输出流速。

通过搬瓦工 CN2 GIA VPS 提供稳定的网络基座，配合 aaPanel + Docker 的标准化部署，再利用 Supabase 进行极其关键的”存算分离”，我们完全可以在 $99/年 级别的硬件上，运行一套企业级的 AI Agent 系统。这套系统不仅能作为你的私人助理（整理邮件、RSS、自动回复），更能成为你未来开发 AI 应用、探索商业变现的基石。

最后给站长的三个建议：

1. 数据无价： Docker 容器是临时的，数据卷（Volume）和 .env 才是永恒的。利用 aaPanel 的计划任务，每天把重要数据备份到腾讯云或者 FTP 等地。
2. 监控常驻： 2GB 内存是走钢丝。在面板里装个监控插件，如果内存长期高于 90%，请认真考虑是该升级套餐，还是该优化你的 Workflow 逻辑。
3. 拥抱变化： Dify 和 n8n 的迭代速度极快（通常是周更）。保持 docker compose pull 的习惯，但升级前务必看 GitHub Release Notes，防止破坏性更新（Breaking Changes）。

祝各位站长在 AI 的星辰大海中，折腾愉快！

搬瓦工实时库存：https://stock.bwg.net

选择建议：

• 入门：KVM 套餐，目前最便宜，可选 CN2 GT 机房，入门之选。
• 推荐：CN2 GIA-E 套餐，速度超快，可选机房多（DC6、DC9、日本软银、荷兰联通等），性价比最高。
• 高端：香港 CN2 GIA 套餐，价格较高，但是无可挑剔。大阪 CN2 GIA 套餐也是非常不错的高端选择。

搬瓦工新手教程

1. 搬瓦工新手入门：《搬瓦工新手入门完全指南：方案推荐、机房选择、优惠码和购买教程》（推荐阅读）
2. 搬瓦工购买教程：《2026 年最新搬瓦工购买教程和支付宝支付教程》
3. 搬瓦工补货通知：《欢迎订阅搬瓦工补货通知（补货提醒）/ 加入搬瓦工交流群》
4. 搬瓦工方案推荐：《搬瓦工高性价比 VPS 推荐：目前哪款方案最值得买？》

未经允许不得转载：Bandwagonhost中文网 » 搬瓦工 VPS 上构建私有化 AI Agent 智能体应用入门指南和配置方案推荐