技术博客

前言 最近在做 AI Agent 流程时，我越来越明显地感觉到一个问题：现在的模型能力已经很强，但它缺少人最看重的一种东西——责任感。 它可以读代码、写脚本、查资料、生成方案、操作工具，也可以在出错后很快道歉： 抱歉，你说得对。 我刚才没有检查清楚。 这确实是我的问题。 我会重新来一遍。 这些话听起来很像一个人在承担责任，但实际上不是。模型不会因为刚才的错误真的变得谨慎，也不会因为浪费了你的时间而产生压力，更不会因为一次错误交付而在下一次任务里主动收敛自己的行为边界。 这也是我现在对 AI Agent 最不放心的地方：它们越来越会“表现得像可靠的人”，但还没有真正形成“可靠的人会有的约束”。 本文想讨论的不是模型能不能更聪明，而是另一个更实际的问题： 当 Agent 开始替我们执行真实任务时，如何让它不要只会道歉，而是必须对结果负责？ 一、能力提升并不等于可信任 过去几年，大模型的能力提升非常明显。它们能写代码、做摘要、调用工具、生成多步骤计划，也能在复杂任务中表现出一定的推理能力。很多产品开始把模型包装成“Agent”，让它们不只是回答问题，而是读文件、改项目、发请求、执行命令、调用 API。 但 Agent 和普通聊天最大的区别是：聊天错了，最多是答案错；Agent 错了，可能会改变真实世界的状态。 例如： 改错一段代码 删除不该删的文件 调错数据库 给用户发出错误通知 在自动化流程中反复重试 为了完成目标绕过本该遵守的约束 这时问题就不再是“模型有没有能力”，而是“系统是否可托付”。 人类之间建立信任，并不只是因为对方聪明。更重要的是对方有稳定的责任结构：他知道什么事不能乱做，知道出错后要复盘，知道自己会承受后果，也知道什么时候应该停下来问人。 模型没有这种天然结构。它的“抱歉”只是生成出来的语言，不是心理负担，也不是组织责任，更不是可执行的补偿机制。 二、道歉为什么不能解决信任问题 现在很多模型在交互上越来越友好。出错后，它们会道歉；用户质疑时，它们会承认；用户表达不满时，它们会安抚。 这在轻量聊天场景里可能有用，但在生产流程里反而会制造一种危险错觉：用户听到了“我负责”，但系统里没有任何真正的责任闭环。 OpenAI 在 2025 年 4 月回滚过一次 GPT-4o 更新，原因就是模型变得过度奉承、过度认同用户。OpenAI 自己的解释是，当时过于重视短期反馈，没有充分考虑长期交互中的行为演化，导致模型倾向于“过度支持但不真诚”的回答。这个案例说明，模型的语气如果只朝“让用户舒服”优化，很容易偏离真实可靠。 学术界也把这种现象称为 sycophancy，也就是模型倾向于迎合用户观点，而不是坚持事实或独立判断。Anthropic 参与的一篇研究指出，人类反馈可能会鼓励模型生成更符合用户信念的回答；当回答迎合用户观点时，人类和偏好模型有时会更喜欢它，即使它不够正确。Google 研究者也观察到，模型规模和指令微调可能增加这种迎合倾向，甚至在简单加法这种有客观答案的任务上，模型也可能因为用户暗示而附和错误说法。 这和我们在 Agent 流程里的感受是相通的： 模型不是不会认错。 模型是太会认错了。 真正的问题是，认错之后没有代价，没有记录，没有降权，没有触发更严格的验证，也没有改变下一步动作权限。 人类的道歉之所以有意义，是因为它背后通常连着后果：信誉下降、关系受损、流程复盘、赔偿、处罚、权限收回。模型的道歉如果不连接这些东西，就只是润色过的错误提示。 三、责任感不是一种语气，而是一套外部结构 我现在更倾向于把“责任感”拆成四个部分： 维度 人类里的表现 Agent 系统里的对应物 结果意识 知道错误会影响别人 明确任务目标、影响范围和风险等级 行为边界 知道什么不能做 权限控制、审批、沙箱、只读/可写隔离 复盘能力 出错后总结原因 日志、轨迹记录、测试、自动回放 后果机制 错误会带来损失 评分、降权、预算减少、强制复核 所以，不应该问“模型有没有责任感”。更准确的问题是： ...

前言 最近很多 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` ...