技术博客

背景 前两篇文章分别介绍了 OpenGame 的技术原理，以及我做的 opengame-web-console 控制中心。那两篇更偏“从 0 到 1”：用户输入一个游戏想法，系统通过 GDD 规划、M1 可玩核心、M2 完整闭环、M3 美术音效、M4 打磨优化和最终验收，把提示词变成一个可试玩的 HTML5 小游戏。 但真正要把它拿去做项目、路演、客户演示或活动投放，只做到“能生成一个游戏”还不够。商业化更关心的是另一件事： 第一版已经能跑起来之后，怎么持续迭代成一个更像商品、更能演示、更容易换皮、更方便发布的 H5 游戏资产。 这篇文章就专门讲 OpenGame Web Console 的迭代升级思路：怎么商业化表达，哪些细节最容易影响交付，亮点在哪里，以及每个环节可以怎么写提示词。 结论 OpenGame Web Console 的商业价值可以概括成一句话： 它把“小游戏外包的一次性项目”变成“可被 AI 持续生产、质检、换皮、发布和版本管理的游戏内容流水线”。 客户真正需要的不是“AI 会写代码”这个卖点，而是更稳定的交付链路： 需求先沉淀成 GDD，不是直接开始乱写代码。 每个阶段都有明确产物和验收标准。 失败后能基于质量报告自动修复。 美术资产有 skin-manifest.json 管理，方便换皮和复用。 成功版本可以发布到 OSS，并提升为当前版本。 新需求可以基于上一版继续迭代，保留已有可玩行为。 所以商业化话术里要少说“模型很强”，多说“交付链路可控”。客户担心的是时间、成本、质量、版权、安全和可维护性。 从一次生成到版本链运营 普通 AI 生成游戏常见的问题是：每次都是重新生成一个目录。这样虽然能看效果，但很难做持续交付。一次生成失败了不知道从哪里继续，一次生成成功了也不知道下一版怎么在原基础上升级。 我的控制中心里做了版本链设计：任务成功后会成为某个 game 的一个版本，用户可以基于历史 task 继续迭代。服务端会克隆上一版 workspace，再把变更说明包装成新的 iteration prompt。新任务会保留业务目标、游戏类型、美术风格、目标设备等元数据，并记录 parentTaskId、versionNumber 和 changeNote。 对外可以把每个游戏包装成一个持续进化的产品： 版本 目标 V1 验证核心玩法，证明游戏能玩起来 V2 补菜单、关卡、结算和重玩路径 V3 升级主题美术、角色动画、按钮、背景和音效 V4 适配移动端、优化加载、提升首屏商业观感 V5 为品牌、活动、节日、渠道做换皮版本 这里的关键不是版本号，而是每一版都要有可解释的商业目标。不要写“优化一下”，而要写“让首次打开 3 秒内能看懂玩法，并让截图适合投放活动页”。 ...

背景 最近 AI Agent 工具越来越多，名字也越来越容易混在一起：OpenClaw、Hermes、OpenCode、Claude Code、Codex，看起来都像能“帮你干活”，但它们解决的问题其实不一样。 如果只看宣传词，很容易得出一个错误结论：哪个更像 Agent、哪个功能更多、哪个更会自动化，就应该装哪个。实际使用时不是这样。工具选型首先要看任务类型，而不是看它是不是更“智能”。 这篇文章整理一个实用判断框架：如果目标是写代码，优先看 Codex 和 Claude Code；如果想要开源、可换模型的编码 Agent，看 OpenCode；如果想让 AI 接管手机、电脑或聊天入口，看 OpenClaw；如果想做长期记忆、技能沉淀、自我改进和长期自动化，再考虑 Hermes。 结论 先给结论： 工具 最适合做什么 不适合做什么 Codex 在真实代码仓库里读代码、改代码、跑命令、修 bug、写文章或工程文档 直接当手机助手或长期自治系统 Claude Code 高质量代码理解、重构、解释复杂工程、命令行协作 跨设备入口控制 OpenCode 开源编码 Agent，可换模型，可自托管，可按团队需求改造 追求最强闭源模型体验时未必省心 OpenClaw 手机、电脑、聊天入口控制，多端操作和技能触发 作为主要编码 Agent 未必最优 Hermes 长期记忆、技能沉淀、自我改进、长期自动化任务 单纯写代码时通常过重 最重要的一句话是： 不要为了“看起来更 Agent”而盲目装 Hermes。先问自己：我到底是在写代码、换模型、控设备，还是做长期自动化？ 五类工具的定位 Codex：面向真实工程的编码协作 Codex 更适合放在真实代码仓库里工作。它的优势不是“聊天”，而是能围绕一个项目持续做工程动作： 阅读代码结构。 修改文件。 运行构建、测试、检查脚本。 根据失败输出继续修。 写技术文档、博客文章、迁移说明。 在一个 workspace 里把任务推进到可验证状态。 如果你的主要任务是： 修 bug 改前端页面 写后端接口 补测试 重构模块 写项目文档 发布 Hugo 博客 那么 Codex 这类代码工作区 Agent 是更自然的选择。它贴近开发者日常：读文件、改文件、跑命令、看输出、再改。 ...

背景 上一篇文章整理了 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. 环境准备 确保系统已安装： ...