技术博客

背景 上一篇文章整理了 OpenGame 的基本概念：它可以把自然语言提示词转成一个可运行的 Web 游戏工程。但如果只在命令行里执行 opengame -p "..." --yolo，很快会遇到几个工程问题： 生成任务耗时长，需要队列和状态追踪。 Agent 输出很多日志，需要实时可视化。 游戏不是“一次生成就结束”，需要 GDD 审核、分阶段实现、失败修复、版本迭代。 生成结果需要可预览、可试玩、可换皮，而不是只留在本地目录。 失败原因需要结构化，否则很难知道是 API 中断、构建失败、资源缺失，还是画面质量不过关。 所以我设计了一个 opengame-web-console：它不是简单包一层按钮，而是把 OpenGame SDK 放进一个任务化、可观察、可修复、可迭代的控制中心。 结论 这个控制中心的核心设计可以概括为一句话： 前端只负责提交需求和观察状态，后端把每一次游戏生成封装成任务，任务运行时负责规划、调用 SDK、执行门禁、自动修复、沉淀版本。 整体链路如下： 用户提示词 ↓ Web Console ↓ POST /api/tasks ↓ TaskService 创建任务记录与 workspace ↓ TaskQueue 串行调度 ↓ TaskRunner 调用 @opengame/sdk ↓ OpenGame Agent 在 workspace 中生成游戏 ↓ Playable / Visual Gate ↓ 成功：保存 previewEntry，可预览、试玩、迭代、换皮 失败：记录 failureReason，生成修复 prompt，可重试 为什么不是直接调用 CLI 直接调用 CLI 适合本地实验，但不适合做“控制中心”。控制中心需要解决的是长期运行问题： ...

背景 OpenGame 是 CUHK MMLab 在 2026 年 4 月发布的开源智能体框架，目标是让用户用一段自然语言描述生成一个可运行、可交互的 Web 游戏。项目论文为 OpenGame: Open Agentic Coding for Games，官方代码仓库在 leigest519/OpenGame。 它解决的问题不是“让大模型写一段游戏代码”，而是让 Agent 完成一整个游戏工程：选择技术模板、生成多个文件、维护游戏状态、处理资源、启动构建、检查运行错误，并反复修复到可玩状态。这个目标比普通代码生成更难，因为游戏开发同时依赖实时循环、输入系统、碰撞逻辑、场景连接、资源加载和 UI 状态。 截至 2026-05-06，OpenGame 已经公开框架代码和演示项目，npm release 仍在准备中，官方推荐从源码安装。 结论 OpenGame 的核心价值可以概括为三点： 它把“游戏生成”从单次代码补全变成了端到端 Agent 流程。 它用 Game Skill 管理模板选择和调试经验，降低跨文件工程崩坏的概率。 它用 OpenGame-Bench 的思路把可玩性纳入评估，而不是只看代码能否编译。 如果你想快速生成 Web 小游戏原型、验证玩法、做 AI 生成式游戏开发实验，OpenGame 值得关注。如果你要生产级商业游戏，它更适合作为原型工具和研究框架，而不是直接替代完整游戏团队。 系统架构 OpenGame 可以拆成四层来看： 用户提示词 ↓ OpenGame CLI / Agent Runtime ↓ Game Skill ├── Template Skill：选择 Canvas、Phaser、Three.js 等项目模板 └── Debug Skill：运行、检测、定位、修复构建和交互问题 ↓ Web Game Project ├── 源码 ├── 资源 ├── 配置 └── 可运行页面 CLI 与 Agent Runtime OpenGame 当前主要通过命令行运行。用户传入一个 prompt，Agent 在目标目录中生成游戏项目，并在必要时修改文件、修复错误、输出运行方式。 ...

前言 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` ...