技术博客

前言 最近很多 AI 编程工具、个人 Agent、自动化框架都开始混在一起讨论：OpenClaw、Hermes、OpenCode、Claude Code、Codex。它们都能和大模型有关，也都可能帮你写代码、跑命令、接入工具，但它们并不是同一层级的东西。 如果只看宣传语，很容易得出一个错误判断：既然 Codex 和 Claude Code 已经能读代码、改文件、跑测试，为什么还要再装 Hermes？或者既然 OpenClaw 已经打通手机和电脑控制，Hermes 又有什么必要？ 我的结论比较直接： 如果主要需求是写代码、改项目、跑测试、修 bug，直接用 Codex 或 Claude Code 就够了。Hermes 的价值不在于“代码能力更强”，而在于把 AI 变成一个长期运行、能记忆、能积累技能、能跨入口接收任务的个人 Agent 层。 本文把这些工具拆开说明。 一、先按层级拆开 先不要把它们放在一个篮子里比。更合理的拆法是： 名称 本质 主要用途 是否替代 Claude/Codex Claude / Claude Code 模型 + 编码 Agent 读代码、改文件、跑命令、处理 Git 工作流 不替代，它本身就是核心编码工具 Codex OpenAI 编码 Agent 本地 CLI / IDE / 云端编码任务，读改跑代码 不替代，它本身也是核心编码工具 OpenCode 开源终端编码 Agent 一个可接多模型的 coding agent 壳子 可部分替代 Claude Code / Codex CLI OpenClaw 个人 AI 助手 / 控制平面 手机、电脑、聊天入口、系统任务自动化 不替代模型，更多是控制入口 Hermes Agent 长期运行、自我改进的 Agent 框架 记忆、技能沉淀、跨会话任务、长期自动化 不替代 Claude/Codex，更像上层编排 可以简单理解成： ...

前言 OpenClaw 最强大的地方在于它的技能（Skill）生态系统。Skill 是预定义的能力模块，让 AI Agent 能够执行特定任务——从发送邮件到操作浏览器，从查询股票到管理飞书文档。 本文将详细介绍我的 OpenClaw 实例中安装的所有 31 个 Skill，涵盖功能、工作原理、调用方式和实际使用场景。 Skill 系统原理 什么是 Skill？ Skill 本质上是一个包含 SKILL.md 指令文件的目录。当用户发送消息时，OpenClaw 的 Agent 会扫描消息内容，匹配到相关的 Skill 后加载其 SKILL.md 作为上下文，从而获得执行该任务所需的知识和能力。 ~/.openclaw/skills/ ├── my-skill/ │ ├── SKILL.md # 技能定义文件（核心） │ ├── _meta.json # 元数据 │ ├── scripts/ # 脚本文件 │ └── references/ # 参考资料 调用流程 用户消息 → Agent 语义匹配 → 加载对应 SKILL.md → Agent 根据指令执行 → 调用脚本/工具/API Agent 不需要显式调用 Skill，它会根据对话内容自动识别需要哪个 Skill。你也可以在消息中明确提到 Skill 名称来触发。 ...

前言 OpenClaw 是一个开源的 AI Agent 平台，可以连接各种 LLM（大语言模型）并提供丰富的技能生态系统。部署在 Ubuntu 服务器上后，你可以通过飞书、Discord、WhatsApp 等渠道与 AI 助手对话，还能安装 ClawHub 上的各种技能插件，让它帮你管理邮件、查询股票、操作浏览器等等。 本文记录了我在 Ubuntu 服务器上部署 OpenClaw 的完整过程，希望对你有帮助。 环境准备 服务器要求 操作系统：Ubuntu 22.04+（推荐 24.04 LTS） 内存：至少 1GB，推荐 2GB+ 存储：10GB+ 网络：能访问 GitHub 和飞书 API 基础依赖 # 更新系统 sudo apt update && sudo apt upgrade -y # 安装必要工具 sudo apt install -y git curl build-essential # 安装 Node.js（OpenClaw 需要 Node 22+） curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt install -y nodejs # 验证 node -v # v22.x+ npm -v 安装 OpenClaw OpenClaw 提供了一键安装脚本，非常方便： ...

本指南详细介绍如何使用 Docker 部署 Dify，并通过 Cloudflare Tunnel 实现安全的外网访问。 前置条件 macOS 系统 已安装 Docker 和 Docker Compose 拥有 Cloudflare 账户 拥有一个域名并托管在 Cloudflare 第一步：部署 Dify 1.1 克隆 Dify 仓库 cd /Users/heyaohua/Server git clone https://github.com/langgenius/dify.git cd dify/docker 1.2 配置环境变量 # 复制环境变量模板 cp .env.example .env # 编辑环境变量文件 vim .env 关键配置项： SECRET_KEY: 生成一个安全的密钥 DB_USERNAME, DB_PASSWORD: 数据库用户名和密码 REDIS_PASSWORD: Redis 密码 1.3 启动 Dify 服务 # 启动所有服务 docker-compose up -d # 检查服务状态 docker-compose ps 确保以下服务正常运行： docker-nginx-1: 端口 80, 443 docker-api-1: 端口 5001 docker-web-1: 端口 3000 docker-plugin_daemon-1: 端口 5003 第二步：安装 Cloudflare Tunnel 2.1 安装 cloudflared # 使用 Homebrew 安装 brew install cloudflared 2.2 登录 Cloudflare cloudflared tunnel login 这会打开浏览器，选择要使用的域名进行授权。 ...

目标：用 PostgreSQL 的 WAL + Streaming Replication 实现“写走主、读走从”，并提供生产可用的高可用与连接层方案，附配置模板与运维脚本示例。适配 PostgreSQL 16/17/18。 1. 架构总览 1.1 基础拓扑（最小可用） App(写) ─────────► Primary(主) ╲ ╲ WAL Stream ╲ App(读) ───────────► Standby1(从) ► Standby2(从) 写请求：直连主库。 读请求：直连从库（或通过中间层，见 §4）。 主从：物理复制（Streaming Replication），异步或半同步可选。 1.2 生产级拓扑（推荐） +-------------------+ | pgbouncer | 连接池（减少连接抖动） +-------------------+ │ +--------------+ | Pgpool-II | SQL解析级读写分离/健康检查/故障转移脚本 +--------------+ │ │ (Write) (Read) │ │ Primary ──┬── Standby1 └── Standby2 +-------------------+ | Patroni + etcd | 主从编排/自动故障切换/仲裁 +-------------------+ 可替换 Pgpool-II 为 HAProxy（协议层转发）+ 应用侧读写分离（双 DSN）。 可替换 Patroni 为 repmgr 或手工脚本（风险更高）。 2. 版本与参数基线 推荐版本：PostgreSQL 17（当前成熟稳定）或 18（新项目/前瞻特性）。 最小参数： wal_level = replica（或 logical 若需逻辑复制） max_wal_senders ≥ 从库数 + 维护冗余（例如 10） wal_keep_size：按网络/故障时间留足（例如 512MB~2GB） archive_mode = on + archive_command（若做增量备份/回放） 半同步：synchronous_commit = on + synchronous_standby_names = 'FIRST 1 (standby1, standby2)' 3. 数据层：主从复制配置模板（物理复制） 3.1 主库 postgresql.conf # 基础 listen_addresses = '*' port = 5432 # 复制/WAL wal_level = replica max_wal_senders = 10 max_wal_size = 4GB min_wal_size = 1GB wal_keep_size = 1024MB # 半同步（可选） # synchronous_commit = on # synchronous_standby_names = 'FIRST 1 (standby1, standby2)' # 性能观测（推荐开启） shared_preload_libraries = 'pg_stat_statements' pg_stat_statements.max = 10000 pg_stat_statements.track = all # 归档（如采用 pgBackRest 则由其接管） # archive_mode = on # archive_command = 'test ! -f /var/backup/%f && cp %p /var/backup/%f' 3.2 主库 pg_hba.conf # 允许业务访问 host all appuser 10.0.0.0/16 scram-sha-256 # 允许复制连接（repl 角色） host replication repl 10.0.0.0/16 scram-sha-256 3.3 创建复制用户 CREATE ROLE repl WITH REPLICATION LOGIN PASSWORD 'REPLACE_WITH_REPL_PASSWORD'; 3.4 从库基线拉起（pg_basebackup） 在 Standby 节点执行： ...

汇总在使用 Docker 部署 PostgreSQL（含 PostGIS、pgvector、TimescaleDB）过程中常见的问题及可操作的解决方案，涵盖构建、扩展、连接、权限、性能与数据等方面。 目录 构建问题 扩展问题 连接问题 权限问题 性能问题 数据问题 调试技巧 预防措施 获取帮助 构建问题 Q1: Docker 构建时出现 “lsb_release: command not found” 问题描述： /bin/sh: 1: lsb_release: command not found /bin/sh: 1: apt-key: command not found 原因分析： 在 Debian/Ubuntu 基础镜像中，lsb_release 和 apt-key 命令可能不存在或已被弃用。 解决方案：改用从源码编译的方式安装 TimescaleDB： # 不使用包管理器安装，改为源码编译 RUN cd /tmp && \ git clone https://github.com/timescale/timescaledb.git && \ cd timescaledb && \ git checkout 2.13.0 && \ ./bootstrap && \ cd build && \ make && \ make install Q2: 编译时出现 “gssapi/gssapi.h: No such file or directory” 问题描述： ...

本指南详细介绍如何使用 Docker 部署一个包含 PostGIS、pgvector 和 TimescaleDB 扩展的 PostgreSQL 15 数据库。该方案解决了扩展兼容性问题，特别是 pgvector 的段错误问题。 项目结构 PgSQL/ ├── .env # 环境变量配置 ├── Dockerfile # PostgreSQL 镜像构建文件 ├── docker-compose.yml # Docker Compose 配置 ├── README.md # 项目说明 ├── config/ # 配置文件目录 │ ├── pg_hba.conf # 客户端认证配置 │ └── postgresql.conf # PostgreSQL 主配置 ├── data/ # 数据持久化目录 │ └── pgdata/ # PostgreSQL 数据目录 ├── init-scripts/ # 初始化脚本 │ └── 01-install-extensions.sql # 扩展安装脚本 ├── logs/ # 日志目录 └── test-examples.sql # 测试示例 快速开始 1. 环境准备 确保系统已安装： ...

淘宝自动化框架选择方案 🎯 推荐方案：DrissionPage + 现有架构 为什么选择 DrissionPage？ 专为中国网站设计 针对淘宝、京东等电商网站优化 内置常见反爬虫机制绕过 国产框架，中文文档完善 与现有架构完美融合 可以直接使用现有的 requests session 支持与 mitmproxy 代理集成 兼容现有的数据处理管道 性能与易用性并存 基于 Chromium 内核，性能优秀 API 设计简洁直观 支持页面模式和 requests 模式切换 📊 框架对比分析 特性 DrissionPage Playwright Selenium Requests-HTML 性能 很快 最快 中等 快 反爬虫能力 优秀 优秀 一般 较弱 淘宝适配 优秀 好 一般 较弱 学习成本 低 中 中 低 中文文档 优秀 一般 好 一般 社区支持 活跃 活跃 最大 较小 🛠️ 技术实施路线 阶段一：环境准备 # 安装 DrissionPage pip install DrissionPage # 安装备选方案（可选） pip install playwright pip install selenium 阶段二：基础集成 创建 TaobaoAutomator 类 集成现有的代理服务器 实现基础的搜索和数据提取功能 阶段三：高级功能 反爬虫策略优化 数据清洗和存储 错误处理和重试机制 阶段四：性能优化 并发处理 资源管理 监控和日志 💡 备选方案 方案 A：纯 Playwright（如果团队技术能力强） 性能最佳 功能最全面 需要较多学习时间 方案 B：Selenium（如果需要最大兼容性） 社区资源最丰富 兼容性最好 性能相对较慢 方案 C：混合方案 DrissionPage 处理复杂交互 requests 处理简单API调用 mitmproxy 处理数据截取 🎪 具体实现示例 DrissionPage 基础用法 from DrissionPage import ChromiumPage # 创建页面对象 page = ChromiumPage() # 访问淘宝 page.get('https://www.taobao.com') # 搜索商品 search_box = page.ele('#q') search_box.input('手机') search_box.after().click() # 获取商品信息 products = page.eles('.item') for product in products: title = product.ele('.title').text price = product.ele('.price').text print(f"{title}: {price}") 与现有架构集成 from DrissionPage import ChromiumPage from crawler.gateway.proxy_server import ProxyServer class TaobaoAutomator: def __init__(self): # 启动代理服务器 self.proxy_server = ProxyServer() # 配置 DrissionPage 使用代理 self.page = ChromiumPage() self.page.set.proxy(f'127.0.0.1:{self.proxy_server.port}') def search_products(self, keyword): # 实现搜索逻辑 pass 🔧 技术要点 代理集成：确保自动化框架使用现有的代理服务器 数据同步：截取的API数据与页面数据关联 反爬虫：实现用户行为模拟和请求间隔控制 错误处理：网络异常、页面变化等情况的处理 📈 预期效果 开发效率提升 50%：相比从零开始 数据质量提升：结合API和页面数据 稳定性增强：多重反爬虫策略 维护成本降低：统一的架构设计

核心结论： 要有效避免 Impala 查询因资源被批处理（Hive/Tez）占满而导致 OOM，需在集群级和服务级两个维度协同调优，重点在于隔离资源、配置队列及精细化设置查询内存和并发。 一、集群级资源隔离 1. 使用 YARN 容器隔离 Hive（Tez）批处理与 Impala 将 Hive-on-Tez 运行在 YARN 上，通过配置不同的 YARN 队列（Queue）来隔离批处理作业与交互式查询。 示例配置（capacity-scheduler.xml）： <property> <name>yarn.scheduler.capacity.root.interactive.capacity</name> <value>30</value> </property> <property> <name>yarn.scheduler.capacity.root.batch.capacity</name> <value>70</value> </property> 如上，Batch 队列占 70%，Interactive（即 Hive LLAP/Impala）队列占 30%，确保 Impala 始终保留至少 30% 资源。 2. Cloudera Manager（或 Ambari）中的 cGroup 资源池 在 Cloudera Manager 上，启用 Impala 服务的 CPU & Memory cGroup 限制 设置 Impala 每台节点最大可用内存比率，以及各服务内不同工作负载（Workload）的最小/最大资源保证 配置步骤： 启用 cGroup 资源管理`bash 在每个节点上启用 cGroup sudo systemctl enable cgconfig sudo systemctl start cgconfig` ...

在本地化部署与离线使用场景中，Ollama、LM Studio 与 AnythingLLM 是三款主流平台，它们在模型支持范围、易用性、性能优化、社区生态以及商业许可等方面各有侧重。下表直观对比了三者的关键维度： 📊 平台对比总览 特性 Ollama LM Studio AnythingLLM 模型生态 支持 100+ 开源与闭源模型（如 GPT-OSS、Gemma 3、Llama3.1、DeepSeek 等），可通过 CLI 与 API 一键拉取与切换； 主要整合 Hugging Face 与 Mistral、Phi 3 系列，本地化界面化管理模型； 聚焦社区贡献模型与自定义微调，支持量化转换与多框架导入； 上下文窗口 最长 128K tokens，本地高效加载； 视模型而定，多数支持 8K–16K； 多数模型自带 4K–32K，可自定义扩展； 易用性 CLI + HTTP API，脚本化和集成友好； 可视化 GUI 管理，一键下载、运行与监控； 以 Python SDK 为核心，需编程对接； 性能优化 原生 MXFP4 与 QAT 量化，侧重 MoE 与长上下文优化； 内置 GPU/CPU 并行管理与自动批处理，支持 ONNX 与 TensorRT 导出； 支持 GGUF、GGML 与 ONNX，易于部署到边缘设备； 工具链集成 原生支持函数调用、Python 执行与 Web 搜索； 插件生态丰富，支持自定义后处理与监控脚本； 灵活集成 LangChain、LlamaIndex 等 RAG 工具； 社区与支持 官方文档齐全，活跃社区讨论与定期模型更新； 官方与第三方插件快速迭代，社区贡献模板； 社区驱动，依赖 GitHub 贡献与模板市场； 商业许可 多数模型 Apache-2.0／MIT，平台本身免费； 平台免费，模型受上游许可约束； 平台免费，部分模型 CC／专有许可； 部署环境 服务器或本地工作站； 桌面化应用（Windows/Mac/Linux）； 脚本化部署于任意支持 Python 的环境； 典型用户 开发者、数据科学家、企业后端集成； 无代码用户、快速原型与演示； 研究者、高度自定义场景； 🎯 详细平台分析 Ollama：开发者友好的命令行平台 核心优势 丰富的模型生态 支持100+开源和闭源模型 一键拉取和切换模型 定期更新模型库 支持自定义模型导入 ...