安装 Nginx sudo apt update sudo apt install nginx sudo systemctl enable --now nginx 反向代理配置示例 以代理本地 vLLM 服务（监听 127.0.0.1:8000）为例： # /etc/nginx/sites-available/api.example.com server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 流式响应（SSE）需要关闭缓冲 proxy_buffering off; proxy_read_timeout 300s; } } sudo ln -s /etc/nginx/sites-available/api.example.com /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx 使用 Let’s Encrypt 签发 HTTPS 证书 sudo apt install certbot python3-certbot-nginx sudo certbot --nginx -d api.example.com certbot 会自动修改配置文件，添加 443 端口监听与证书路径，并配置 HTTP 到 HTTPS 的重定向。证书默认 90 天有效期，certbot 会自动注册续期任务，可通过以下命令验证： ...

为什么容器化 AI 服务 环境隔离，避免 CUDA / Python 依赖版本冲突 便于在多台机器间快速复制部署 结合编排工具（Compose / K8s）实现弹性伸缩 前提：安装 NVIDIA Container Toolkit distribution=$(. /etc/os-release; echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list \ | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker 使用官方 vLLM 镜像启动服务 docker run -d \ --name vllm-server \ --gpus all \ -p 8000:8000 \ --ipc=host \ -v ~/.cache/huggingface:/root/.cache/huggingface \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct-AWQ \ --quantization awq 要点说明： ...

编写一个基础 unit 文件 # /etc/systemd/system/myapp.service [Unit] Description=My Application After=network.target [Service] Type=simple User=appuser Group=appuser WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/venv/bin/python app.py Restart=on-failure RestartSec=5 Environment=PYTHONUNBUFFERED=1 EnvironmentFile=-/opt/myapp/.env [Install] WantedBy=multi-user.target 关键字段说明： Type=simple：主进程即服务本身，适合大多数常驻程序 Restart=on-failure：进程异常退出时自动重启，避免服务假死 EnvironmentFile=-：前缀 - 表示文件不存在也不报错 常用管理命令 sudo systemctl daemon-reload # 修改 unit 文件后重新加载 sudo systemctl start myapp sudo systemctl enable myapp # 设置开机自启 sudo systemctl status myapp sudo systemctl restart myapp sudo systemctl stop myapp sudo systemctl disable myapp 查看日志 journalctl -u myapp -f # 实时跟踪日志 journalctl -u myapp --since today journalctl -u myapp -p err # 只看错误级别日志 资源限制 对 AI 推理等资源密集型服务，建议在 unit 中限制资源占用，避免单个服务拖垮整机： ...

ufw：面向新手的简化管理 ufw（Uncomplicated Firewall）是对 iptables/nftables 的简化封装，适合快速配置基础规则。 sudo apt install ufw # 默认策略：拒绝入站，允许出站 sudo ufw default deny incoming sudo ufw default allow outgoing # 放行必要端口 sudo ufw allow 22022/tcp # SSH（对应自定义端口） sudo ufw allow 80/tcp sudo ufw allow 443/tcp # 限制某端口的来源 IP 段 sudo ufw allow from 192.168.1.0/24 to any port 8000 sudo ufw enable sudo ufw status verbose nftables：更细粒度的现代方案 nftables 是 iptables 的继任者，语法更统一，规则集也更易维护。 sudo apt install nftables # /etc/nftables.conf table inet filter { chain input { type filter hook input priority 0; policy drop; ct state established,related accept iif lo accept tcp dport 22022 accept tcp dport { 80, 443 } accept # 限制单 IP 新建连接速率，缓解简单的连接洪泛 tcp dport 22022 ct state new limit rate 10/minute accept } chain forward { type filter hook forward priority 0; policy drop; } chain output { type filter hook output priority 0; policy accept; } } sudo nft -f /etc/nftables.conf sudo systemctl enable --now nftables 场景示例：仅内网可访问的 AI 推理服务 将 vLLM 等服务监听在内网接口，或通过防火墙限制外部访问： ...

使用密钥认证替代密码登录 # 本地生成密钥对（推荐 ed25519） ssh-keygen -t ed25519 -C "your_email@example.com" # 上传公钥到服务器 ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server /etc/ssh/sshd_config 关键配置 # 禁用密码登录，强制密钥认证 PasswordAuthentication no PermitEmptyPasswords no # 禁止 root 远程登录 PermitRootLogin no # 更改默认端口，降低自动化扫描命中率（非核心防护手段，只是降噪） Port 22022 # 限制协议版本与登录尝试 Protocol 2 MaxAuthTries 3 LoginGraceTime 30 # 仅允许特定用户/组登录 AllowUsers deploy admin 修改后重启服务： sudo systemctl restart sshd 注意：修改端口或禁用密码登录前，务必保留一个已登录的会话窗口，避免配置错误导致无法远程访问。 使用 fail2ban 防暴力破解 sudo apt install fail2ban # /etc/fail2ban/jail.local [sshd] enabled = true port = 22022 maxretry = 5 bantime = 3600 findtime = 600 sudo systemctl enable --now fail2ban sudo fail2ban-client status sshd 双因素认证（可选增强） 对高安全要求场景，可结合 libpam-google-authenticator 实现 SSH 二次验证，在密钥认证基础上再叠加一层动态口令。 ...

账户与权限 禁用 root 直接远程登录，改用普通账户 + sudo 为每个人员/服务分配独立账户，避免共享凭证 定期审查 sudo -l 权限范围，遵循最小权限原则 # 检查是否有异常的 sudo 权限 sudo -l -U username 更新与补丁 sudo apt update && sudo apt upgrade -y # 开启无人值守安全更新（Debian/Ubuntu） sudo apt install unattended-upgrades sudo dpkg-reconfigure --priority=low unattended-upgrades 文件与目录权限 # 查找全局可写的敏感文件 find / -xdev -type f -perm -0002 -not -path "/proc/*" 2>/dev/null # 查找 SUID/SGID 程序，核对是否为预期程序 find / -xdev \( -perm -4000 -o -perm -2000 \) -type f 2>/dev/null 关闭不必要的服务 systemctl list-unit-files --type=service --state=enabled sudo systemctl disable <不需要的服务> 内核参数加固（/etc/sysctl.conf） # 禁止 IP 转发（非路由器场景） net.ipv4.ip_forward = 0 # 防止 SYN Flood net.ipv4.tcp_syncookies = 1 # 忽略 ICMP 广播请求 net.ipv4.icmp_echo_ignore_broadcasts = 1 # 禁用来源路由 net.ipv4.conf.all.accept_source_route = 0 sudo sysctl -p 日志与审计 安装 auditd 记录关键系统调用与文件访问，配合 journalctl 定期审查异常登录尝试： ...

为什么需要框架 直接调用 LLM API 可以完成简单问答，但一旦涉及多轮工具调用、状态管理、多 Agent 协作，手写代码的复杂度会迅速上升。框架的价值在于提供标准化的抽象层。 主流框架简要对比 框架 定位 优势 局限 LangChain 通用 LLM 应用开发 生态最全，集成组件多 抽象层较重，调试复杂链路较麻烦 LlamaIndex 数据检索与 RAG 为核心 索引与检索能力强 Agent 能力相对偏弱 AutoGen 多 Agent 协作 天然支持多角色对话式协作 对单 Agent 简单任务偏重 原生 Function Calling 直接使用模型能力 轻量、可控性最高 需要自行实现状态管理 选型建议 简单问答 / 单轮工具调用：优先直接使用模型的 function calling 能力，避免引入不必要的框架开销 知识库问答类应用：LlamaIndex 在索引构建与检索优化上更专注 复杂多步骤任务编排：LangChain 的 LCEL（表达式语言）或 LangGraph 提供了较好的状态图抽象 需要多个专业角色协作（如“规划者 + 执行者 + 审核者”）：AutoGen 一类的多 Agent 框架更契合 一个最小 Agent 示例（伪代码） tools = [search_tool, calculator_tool] def run_agent(query): while True: response = llm.chat(messages, tools=tools) if response.tool_calls: for call in response.tool_calls: result = execute_tool(call) messages.append(tool_result(call, result)) else: return response.content 理解这个基本循环（LLM 决策 → 工具执行 → 结果回填 → 再决策）比死记框架 API 更重要，框架本质上都是在此基础上做工程化封装。 ...

结构化 Prompt 的基本框架 一个稳定可复用的 Prompt 通常包含以下几个部分： [角色设定] 你是一名资深的后端工程师 [任务描述] 请审查以下代码是否存在安全隐患 [输出约束] 以 JSON 格式输出，字段包括 issue、severity、suggestion [输入内容] {code} 将角色、任务、约束与输入明确分区，可以显著降低模型输出格式不稳定的概率。 强制结构化输出 对接下游程序时，建议明确要求 JSON 并给出 schema 示例： 请仅输出如下格式的 JSON，不要包含任何多余文字： { "summary": "string", "risk_level": "low | medium | high", "actions": ["string"] } 如果使用支持 function calling 或 structured output 的模型/框架，优先使用原生能力而非纯文本约束，稳定性更高。 思维链（CoT）引导 对于推理类任务，显式要求模型分步思考能提升准确率： 请先列出解决该问题需要的关键步骤，再逐步推导，最后给出结论。 需要注意的是，面向最终用户展示的产品通常应隐藏推理过程，只暴露结论，避免冗长输出影响体验。 Few-shot 示例的选择 示例数量并非越多越好，2~4 个高质量示例通常优于大量低质量示例 示例应覆盖边界情况（如空输入、异常格式），而不仅是“标准”场景 示例格式必须与期望输出格式完全一致，包括缩进和标点 常见反模式 在 Prompt 中堆砌矛盾指令（如同时要求“详细”又要求“简洁”） 过度依赖否定式指令（“不要做 X”），效果通常弱于正向描述期望行为 忽略模型的上下文长度限制，导致关键指令被截断 小结 Prompt 工程的本质是通过清晰的结构和约束，降低模型输出的不确定性，使其更适配工程化的下游调用。

RAG 的基本流程 一个典型 RAG 系统由四个阶段组成：文档切分 → 向量化 → 检索 → 生成。 原始文档 → Chunking → Embedding → 向量数据库 ↓ 用户问题 → Embedding → 向量检索 → Top-K 片段 → 拼接 Prompt → LLM 生成答案 文档切分策略 切分粒度直接影响检索质量： 固定长度切分：实现简单，但可能截断语义完整的段落 按语义切分：借助标题、段落结构切分，效果更好但实现复杂 滑动窗口重叠：相邻 chunk 间保留 10%~20% 重叠，缓解边界信息丢失 一般建议 chunk 大小控制在 300~800 token 之间，具体需结合模型上下文长度与检索精度需求测试确定。 向量数据库选型 方案 特点 适用场景 Milvus 分布式、功能全面 大规模生产环境 Qdrant 轻量、Rust 实现、性能好 中小规模自建 Chroma 极简易用 原型开发、本地实验 pgvector 复用现有 PostgreSQL 已有 PG 基础设施的团队 检索质量优化 混合检索：结合稀疏检索（BM25）与稠密向量检索，弥补语义检索对专有名词、编号类查询不敏感的问题 Rerank：检索出 Top-20 后，用专门的 rerank 模型重新排序取 Top-5，显著提升精度 查询改写：对用户原始问题做扩展或拆分，尤其适合处理多跳问题 常见陷阱 忽略 chunk 元数据（来源、章节）会导致答案缺乏可追溯性 检索结果未去重，可能造成同一内容多次占用上下文 未设置相似度阈值，低相关片段也被强行拼入 Prompt，反而干扰生成质量 小结 RAG 并非简单的“检索 + 拼接”，切分策略、检索方式与重排序环节的组合调优才是决定系统效果的关键。