n8n 自部署指南：开源工作流自动化平台 什么是 n8n n8n（发音为 “n-eight-n”）是一个开源的工作流自动化平台，被称为"自托管的 Zapier 替代品"。它允许用户通过可视化的节点编辑器创建自动化工作流，连接不同的应用程序和服务，实现业务流程的自动化。 n8n 的核心特点： 开源免费：MIT 许可证，可自托管 可视化编辑器：无需编码，通过拖拽创建工作流 丰富集成：支持 400+ 应用集成 灵活部署：支持 Docker、Kubernetes、本地部署 定时执行：支持手动、定时、事件触发 截至目前，n8n 在 GitHub 上已获得超过 37000 个 Star，是最受欢迎的自动化工作流工具之一。 部署方式选择 n8n 支持多种部署方式： 部署方式 适用场景 难度 Docker Compose（SQLite） 个人使用、小团队 简单 Docker Compose（PostgreSQL） 生产环境、多用户 中等 Node.js (npm) 本地开发测试 简单 Kubernetes 大规模生产部署 复杂 Docker Compose 部署（推荐） 环境要求 服务器：Ubuntu 22.04+ 或其他 Linux 发行版 资源：建议 2GB+ 内存，20GB+ 存储 Docker 和 Docker Compose 已安装 简单版（SQLite） 创建项目目录和配置文件： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 mkdir -p ~/n8n && cd ~/n8n cat > docker-compose.

小内存腾讯云服务器优化：关闭安全加固、云监控与自动化助手 背景简介 腾讯云服务器默认会安装多种监控和安全组件，包括云监控（Cloud Monitor）、云镜（Security Agent）、安全加固和自动化助手（TAT）等。这些组件在后台持续运行，会占用一定的系统资源（CPU、内存）。 对于小内存服务器（如 1GB 或 2GB 内存）来说，这些后台服务可能会影响业务程序的可用内存，甚至导致 OOM（内存耗尽）问题。 优化目标： 释放内存资源 减少后台进程占用 提升服务器响应速度 降低资源消耗 需要关闭的组件 组件名称 功能 占用资源 云监控（YunAgent） 监控服务器性能指标 约 50-100MB 内存 云镜（Security Agent） 安全防护和病毒扫描 约 30-80MB 内存 安全加固（Security hardening） 系统安全加固 约 20-50MB 内存 自动化助手（TAT） 远程运维自动化 约 10-30MB 内存 思维导图：操作流程总览 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 graph TD A[开始优化] --> B{确认权限} B -->|需要sudo| C[获取root权限] B -->|已是root| D[开始操作] C --> D D --> E[1.

Linux Swap 分区大小修改指南 什么是 Swap Swap（交换空间）是 Linux 系统的一种虚拟内存技术。当物理内存不足时，系统会将不活跃的内存页面移动到 Swap 空间中，从而释放物理内存供活跃进程使用。 Swap 的作用： 扩展可用内存容量 防止内存耗尽导致系统崩溃 支持内存休眠（suspend to disk） 在内存压力时提供缓冲 修改 Swap 大小的三种方法 方法一：使用 swapfile（推荐） 这种方法最灵活，不需要重新分区。 步骤 1：查看当前 Swap 状态 1 2 3 4 5 6 7 8 # 查看当前 Swap 使用情况 free -h # 查看 Swap 文件位置 swapon --show # 查看磁盘空间 df -h 步骤 2：禁用现有 Swap 1 2 3 4 5 # 关闭 Swap sudo swapoff -a # 如果有多个 Swap，指定关闭特定文件 sudo swapoff /swapfile 注意： 关闭 Swap 前确保有足够的物理内存，否则可能导致程序崩溃。最好在系统负载低时操作。

OpenSpec：让 AI 编程助手遵循规范而非猜测 背景简介 AI 编程助手最常见的问题不是它们不会写代码，而是它们写出的代码与你的预期不符。你说"添加深色模式"，它却重写了 CSS 变量、添加了切换按钮、还重构了布局——而你只是想改变颜色变量。下一次对话时，上下文丢失了，AI 又从零开始猜测你的意图。 OpenSpec 解决了这个问题：在 AI 开始写代码之前先生成规范文档。双方先对齐"要做什么"和"怎么做"，然后再按照规范实现。 截至目前，OpenSpec 在 GitHub 上已获得超过 36000 个 Star，成为 AI 驱动开发领域的标杆框架。 核心架构 OpenSpec 将项目知识分为两个部分： 1 2 3 4 5 6 7 8 9 openspec/ ├── specs/ ← 真实来源（当前行为） │ ├── auth/ │ │ └── spec.md │ └── payments/ │ └── spec.md └── changes/ ← 进行中的修改（每个变更一个文件夹） ├── add-dark-mode/ └── archive/ ← 已完成的变更归档 Specs 描述系统的当前行为，Changes 是提出的修改。分开管理，多个变更可以并行进行而不会冲突。 思维导图：OpenSpec 整体架构 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ┌─────────────────────────────────────────┐ │ OpenSpec 框架 │ │ 规范驱动开发 (Spec-Driven Dev) │ └─────────────────────────────────────────┘ │ ┌─────────────────────────────────┼─────────────────────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │ 真实来源 │ │ 变更管理 │ │ 工作流程 │ │ (Specs) │ │ (Changes) │ │ (Workflow) │ └─────────────────────┘ └─────────────────────┘ └─────────────────────┘ │ │ │ ├─系统当前行为 ├─proposal（提议） ├─propose ├─增量更新 ├─specs（增量规范） ├─apply └─版本历史 ├─design（设计） ├─archive └─tasks（任务清单） └─explore │ ├─ADDED（新增） ├─MODIFIED（修改） └─REMOVED（删除） ▼ ┌─────────────────────────────────┐ │ 四类产出物 │ ├─────────────────────────────────┤ │ • proposal.

OpenCode Skill Creator 使用指南 什么是 Skill Creator Skill Creator 是 Anthropic 官方提供的 Skill 开发助手，帮助开发者创建、优化和打包技能。它是 Claude Code 生态中用于扩展 Agent 能力的重要机制。 在 Claude Code / OpenCode 中，Skill（技能） 是一种可复用的能力扩展包，本质上是一个模块化知识包，可以给 AI 添加： 专业领域知识 固定工作流程 API / 工具使用方式 模板和脚本 简单理解：Skill = 给 AI 写的一份操作说明书 核心价值： 将工作流程固化为可复用的技能 让 AI 助手具备领域专业知识 提高团队协作效率 标准化工作流程 思维导图：Skill Creator 整体架构 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 ┌─────────────────────────────────────────┐ │ Skill Creator 框架 │ │ AI 技能开发与评估工具链 │ └─────────────────────────────────────────┘ │ ┌─────────────────────────────────┼─────────────────────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │ 技能结构 │ │ 工作流程 │ │ 核心工具 │ │ (File Structure) │ │ (Workflow) │ │ (Tools) │ └─────────────────────┘ └─────────────────────┘ └─────────────────────┘ │ │ │ ├─SKILL.

RAG检索增强生成分类详解 背景 随着大语言模型（LLM）的快速发展，如何让AI在生成内容时准确引用最新、最相关的信息成为一个核心挑战。检索增强生成（Retrieval-Augmented Generation，简称RAG）技术应运而生，它通过结合检索系统和生成模型的优势，显著提升了AI输出的准确性和可信度。本文将详细介绍RAG的分类体系，帮助读者根据不同场景选择合适的RAG方案。 RAG基本工作原理 RAG的核心思想是将用户查询与外部知识库相结合，其工作流程主要包括以下几个环节： 文档处理：将原始文档切分为Chunks（文本块），每个chunk经过Embedding模型转换为向量 向量存储：将向量存入向量数据库（如Milvus、Pinecone、Chroma等） 语义检索：用户查询同样被转换为向量，在向量数据库中检索最相关的Top-K个chunks 增强生成：将检索到的相关文档作为上下文，连同用户问题一起发送给LLM生成回答 1 用户问题 → 向量化 → 向量数据库检索 → 上下文组装 → LLM生成 → 回答输出 RAG分类体系 根据技术复杂度和应用场景，RAG可以分为以下几类： 1. 简单RAG（Naive RAG） 简单RAG是最基础的实现方式，采用"检索-拼接-生成"的直线路径。 工作流程： 用户输入查询 一次性从向量数据库检索Top-K相关文档 将检索结果与查询拼接后发送给LLM 优点：架构简单、实现成本低、延迟低 缺点：当检索结果不准确或包含噪声时，生成质量会明显下降；无法处理复杂的多跳推理问题 适用场景：文档问答、知识库查询、结构简单的FAQ系统 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 # 简单RAG实现示例 from langchain_ollama import OllamaLLM from langchain_chroma import Chroma from langchain_ollama import OllamaEmbeddings # 初始化组件 llm = OllamaLLM(model="qwen2.