从旧金山到澳门：OpenClaw Maintainers 眼中的 Agentic Coding

2026 年 5 月 30 日，ClawCon Macao 将在 BEYOND Expo 2026 期间于澳门威尼斯人金光会展举行。

图：ClawCon Macao @ BEYOND Expo 2026 官方活动视觉

这是 ClawCon 全球社区系列活动的一站，也是继 ClawCon Shanghai 之后，ClawCon 在中国的第二场活动。

更特别的是，这次 keynote 有四位华人 OpenClaw maintainer 同台分享

其中三位来自腾讯云

他们讨论的主题是：

Harness Engineering and Agentic Coding：OpenClaw Maintainers' Perspective

这不是一场传统意义上的产品发布，也不是一场只谈概念的 AI 圆桌。

ClawCon 一直强调开放协作、真实 Demo、AI 工作流实践与 Builder 交流。相比传统行业大会，它更关注真实项目、现场演示，以及开发者之间的深度连接。

在这场 35 分钟的 keynote 里，四位 Maintainer 从不同角度讲了同一件事：当 AI coding agent 从个人工具走向真实项目、真实社区、真实部署环境，难点已经不只是“让 AI 写代码”。

更大的问题是：如何让人的判断、社区协作、工具生态和部署场景，变成可运行、可验证、可持续演进的工程系统。

这场分享由 Frank、Mason、Maurice、Sliver 四位 maintainer 共同完成。主线很清晰：

• Frank 讲 maintainer 的真实日常：在陌生领域快速定位问题。

• Mason 讲大型开源项目治理：如何用 ClawSweeper 把重复判断系统化。

• Maurice 讲 ClawHub：为 agent 时代设计的 Skill / Plugin / Soul registry。

• Sliver 讲 OpenClaw 上云实践和中国区优化：让工具真正跑进用户的生产环境。

ClawCon 的起点很有社区气质。

2026 年初，Michael Galpert 原本在旧金山组织 Claude Code 相关的 show-and-tell 小聚会。后来，因为自己越来越多地使用 OpenClaw，他转向 OpenClaw 社区 Discord，想看看是否有人愿意一起办一场线下 meetup。

最初只是约 30 人 RSVP 的小活动，主办方按 80 人规模找场地。但随着消息扩散，报名人数一路增长：80、200、700、900，最终旧金山首场 ClawCon 变成了一场超过千人报名的社区活动。那场活动之后，ClawCon 开始从旧金山走向纽约、东京、伦敦、上海、澳门等更多城市。

图：OpenClaw 创始人 Peter Steinberger 与 ClawCon 共同组织者 Tomas Taylor 在首届 ClawCon 旧金山活动现场

ClawCon 官方网站把它定义为 personal AI 的 festival：免费、开放、社交优先，有 demo、有 Q&A，也有大量非结构化的交流时间。它不是需要门槛筛选的开发者大会，也不是传统公司展会，而是让正在构建 personal AI 工具和工作流的人聚在一起。

上海站是 ClawCon 在中国的第一场。2026 年 5 月 11 日，ClawCon Shanghai 在 muShanghai 举办，现场包含主舞台、开放麦、Skill Lab、龙虾市集、OpenClaw Demo Show 等环节，Luma 页面显示有 1,221 人参加。

澳门站则把这条社区线带到了 BEYOND Expo 2026 的现场。

BEYOND Expo 2026 于 2026 年 5 月 27 日至 30 日在澳门威尼斯人金光会展举行。

公开日程信息显示，BEYOND Expo 今年设置 7 大舞台、200+ 场圆桌论坛及主题演讲、400+ 位全球嘉宾、1200+ 全球科技企业，并围绕具身智能、AI 智能体、AI 向善、科技出海等方向展开。

ClawCon Macao 是 BEYOND Expo 期间的官方社区活动之一，由 OpenClaw Asia 发起并组织。

它聚焦 OpenClaw、personal AI、AI Agent workflows、live demos 和 builder networking，面向 OpenClaw 开发者、AI Agent builder、开源社区 maintainer、模型厂商、AI startup 和投资人。

Frank 的开场很直接：OpenClaw maintainer 每天面对的，从来不是一个干净、固定、边界清晰的技术栈，而是一个同时在动、哪里都可能坏的真实系统。

聊天平台、模型供应商、记忆体系统、Gateway、agent runtime、macOS 原生能力、沙箱权限、安全、CLI、构建和测试，任何一处出了问题，maintainer 都必须快速进入现场。

一个典型场景是：上午还在修 WhatsApp 图片上传，下午就要追某个模型的 reasoning leak。两个问题完全不在同一个领域，却可能落到同一个 maintainer 身上。

真正的挑战不只是“会不会”，而是“能不能快速切换”：

• 这个问题属于哪个领域？

• 应该调用哪一块基础知识？

• 哪些证据能证明判断方向是对的？

• 什么时候该收敛，不再继续发散？

Frank 举了一个具体案例：PR #81802 里，memory watcher 把文件描述符用爆，触发 EMFILE。解决这个问题并不要求 maintainer 成为 Linux kernel 专家，但必须能快速把 soft limit / hard limit、fork / exec 后的 fd 继承、EBADF 等旧知识重新接上线，并把它们套回 OpenClaw 的真实路径里。

这也是他对“通才”的定义：不是“什么都会”，而是在系统坏掉时，能够快速把正确的知识、证据和上下文接回来。

AI 在这里最重要的价值，不是替代判断，而是加速这个过程。过去需要几个小时才能翻出来、补齐、确认的知识，现在可能几分钟就能重新接上线。对 Maintainer 来说，这是一种非常实际的 leverage。

个人判断力再强，也有上限。当一个 AI coding agent 项目长到 OpenClaw 这样的规模，问题会换一种形态出现：issue、PR、用户反馈、验证证据、风险判断同时涌入，Maintainer 的时间却不会线性增长。

Mason 在分享中把这个问题概括为一句话：AI Native 项目的瓶颈，不一定在写代码，而在治理吞吐。

Maintainer 每天要处理的判断非常具体：

这些判断单看都不大，但叠起来就是瓶颈。更重要的是，其中有相当一部分是重复的、确定性的。如果每次都靠 maintainer 手工重新跑一遍，团队会被流程本身消耗掉。

ClawSweeper 要解决的正是这个问题：把 Maintainer 脑子里的判断标准，变成可重复执行的系统。

ClawSweeper 不是替 Maintainer 做最终决定，而是把前置判断系统化。什么是重复 issue，什么是垃圾信息，什么叫验证证据不足，一个 PR 合并前最需要注意什么业务风险，贡献者下一步应该补什么，这些过去高度依赖个人经验的环节，现在可以先由系统整理出来。

这背后有两层治理。

第一层是 issue / PR 分诊和清理。

Backlog 是项目治理入口，如果入口不干净，后面的 review、release、社区沟通都会变慢。ClawSweeper 会帮助识别重复 issue、清理无效内容、关闭已修复但未关闭的问题、筛出值得推进的 PR。

第二层是辅助 Maintainer 决策。

传统 review 中Maintainer 要从 diff 里自己捞风险：这个改动会不会改变用户行为？会不会影响已有部署？测试是否覆盖了关键路径？ClawSweeper 会先把这些问题结构化地摆出来，让人更快进入真正需要判断的上下文。

ClawSweeper 还会给 PR 一个质量评级，并提供 rank-up 建议，例如补充复现步骤、测试输出、截图或日志，修复影响正确性和可维护性的 review findings，或者移除无关重构、收敛 patch 范围。

评级本身不是核心机制，但它能让 contributor 和 Maintainer 快速形成共同语境：这个 PR 现在大概在哪个质量层级，下一步怎么提升。

治理让 core 主线能稳定跑下去，但生态扩展需要另一套基础设施。Maurice 的部分聚焦 ClawHub。

一句话概括：npm 之于 Node，ClawHub 之于 OpenClaw。

但 ClawHub 从第一天起就是为 Agent 设计的，这一点和传统 registry 有本质区别。

Skill 是 SKILL.md加资源文件和 frontmatter 的文本包。新的原语，需要新的分发平台。这也符合 OpenClaw 的设计哲学：core 保持精简，可选能力尽量以 plugin 形式发布。新能力默认进入 ClawHub，而不是全部塞进 core。

ClawHub 当前托管四类内容：

围绕 agent 的使用方式，ClawHub 做了几个关键设计。

第一，Skill 是文本加 frontmatter。SKILL.md 顶部直接声明自己是谁、需要什么权限、怎么安装。这样 agent 读得懂，自动审核也能做“声明 vs 实际”的一致性检查。

第二，版本不可变，tag 可移动。每次 publish 冻结一个版本，latest 是可以移动的 tag。回滚就是把 tag 移回旧版本。对 agent 来说，一行 prompt 的变化也可能导致行为变化，所以复现性比传统 package 时代更加重要。

第三，官方身份不能自我声明。Official 徽章由系统根据 GitHub 组织成员关系判断，避免冒名抢注。

第四，链接不能被轻易破坏。rename 会自动 redirect，merge 会隐藏源 listing 并重定向到 canonical，owner migration 会保留版本、star、comment、audit 等历史。Registry 最贵的资产之一是 URL。

第五，pin 是 agent 时代的 lockfile。clawhub pin <slug> 可以冻结本地副本，对抗 update --all 和 force reinstall。

第六，搜索不能只靠关键词。用户搜“help me clean up my inbox”时，句子里不一定出现 “cleanup” 这个 token。ClawHub 使用 embedding 和向量搜索提升召回率。

Maurice 特别强调了安全，因为 Agent registry 的威胁模型与传统 library registry 不一样。

一个 library 最多让程序崩溃；一个恶意 skill 可能让 agent 替用户发邮件、删文件、调用账号权限、暴露凭据。Agent 的能力边界更接近“可行动的代理”，不是单纯被调用的代码。

ClawHub 因此设计了三层审核：

ClawScan 问的核心问题不是简单的“危险吗”，而是“是否一致”：

名称、摘要、metadata、请求权限、实际内容，这些东西是否彼此对得上？是否符合一个合理用户对这个 skill 的预期？

常见风险包括：

• Prompt injection：数据里藏指令，诱导 AI 执行。

• Tool misuse：拿合法工具做越界操作。

• Credential exposure：暴露 token 和密钥。

• Unsafe execution：执行不必要的危险操作。

• Context poisoning：往 agent 的上下文或记忆里塞入误导性信息。

• Excessive agency：请求的权力远超实际用途。

这里还有一个重要区分：权力大，不等于恶意。

一个发布类 skill 可能被标记为 Review / Medium risk，并不意味着它是恶意的，而是说明它目的看起来对齐，但握有有意义的账号权限。审核要判断的是：这份权力有没有被声明、被披露，并且匹配用途。

社区审核也被纳入信任体系。登录用户可以 report；超过一定数量的独立 report 会自动隐藏等待 moderator 审核；评论有 GitHub 账号年龄要求；角色变更和删除进入 audit log；被 hold 或 hidden 的 listing，owner 仍然可以看到诊断信息，知道下一步该修什么。

ClawHub 不把审核当成简单 gate，而是当成可解释的信任系统：open by default，audited by design。生态可以在 core 外面成长，但每一次发布都必须可读、可审、可回滚、可追责。

Sliver 的部分把视角拉回真实使用场景。

根据分享中的统计，OpenClaw 用户中约 53% 在本地运行，47% 在云上运行。本地用户里，Mac 约 41%，Windows 约 8%，Linux 约 4%。也就是说，云端运行已经接近一半。

云上的好处很直观：更安全，环境坏了可以重建；更方便，随时可用；不占用本地资源；多设备之间也能共享同一个运行环境。

但云上也有现实门槛：需要一点专业知识，需要一点成本，部分操作也会受限，比如浏览器体验和苹果生态相关能力。

OpenClaw 围绕这些问题做了几类优化。

性能上，目标很明确：2C2G 能用，2C4G 流畅。超过 200 个 PR 专门用于修复低配机器上的稳定性问题。根据腾讯云不完全统计，超过 40% 的实例是 2C2G 配置，并且能够稳定运行。

工具体验上，浏览器操作支持 12 个搜索后端：Brave、DuckDuckGo、Exa、Firecrawl、Gemini、Grok、Kimi、MiniMax、Ollama、Perplexity、SearXNG、Tavily。

云厂商和生态合作也在持续展开。托管形态包括腾讯云 Lighthouse、阿里云 ECS、华为云、火山引擎；SaaS 形态出现了 ArkClaw、WorkBuddy、MaxClaw、KimiClaw、CoPaw 云端、Tbox；本地 / 自部署形态则包括 QClaw、OpenClaw 原版、AutoClaw、CoPaw 本地、EasyClaw 等。

OpenClaw 刚在中国火起来时，一个常用的中国 IM 都没有。社区里最热门的教程之一，是教大家如何接入 Telegram。

但中国用户面对的是一组很具体的问题：海外模型访问慢，付费不方便，文档缺少本土化，数据合规要求不同，IM 和云服务也有明显地域差异。

所以本土化不是简单翻译界面，而是让用户能接入自己真实可用的模型、通信工具和基础设施。

在模型 endpoint 上，OpenClaw 已经接入 11 个明确属于中国企业或中国模型方的 endpoint：

BytePlus、DeepSeek、MiniMax、Moonshot AI / Kimi、千帆、Qwen Cloud、StepFun、腾讯云、火山引擎、小米、智谱。

在 IM 工具上，Telegram / Discord 在国内不可用，各厂商先推自家插件，OpenClaw 后续陆续收录大量国内 IM 插件。当前 onboard 界面已经可见 QQ、WeCom、飞书、元宝等入口。

社区层面，虽然 GitHub 默认英文，但中文交流并不少。分享中提到，已经有接近 2K 个 issue 直接使用中文讨论，中文 PR 描述和中文 discussion 也很常见。

访问体验层面，ClawHub 国内访问和限频问题催生了 SkillHub，目标是解决中国用户访问、发现、安装 skill 的链路问题。

中国区优化不是一个单点功能，而是一组围绕模型、云、IM、社区和访问体验的持续适配。

这场 keynote 的四个部分，其实串成了一条完整链路。

Frank 讲的是地面：maintainer 在陌生领域里快速定位问题，在频繁切换中保持判断力。AI 加速的，是把正确的基础知识重新接上线。

Mason 把问题拉到系统层：当输入量超过个人处理能力，ClawSweeper 把重复治理判断做成可运行的系统，让 Maintainer 把注意力留给方向、风险和社区信任。

Maurice 往外看生态：ClawHub 不是传统 package registry 的简单复刻，而是从第一天起为 agent 设计，让 Skill、Plugin、Soul 的发布可读、可审、可回滚、可追责。

Sliver 回到部署现场：云端部署、中国区模型和 IM 适配、社区和访问体验优化，让 OpenClaw 真正进入用户每天使用的环境。

OpenClaw 的核心经验可以浓缩成一句话：

AI native 不是让 AI 放飞，而是把人的判断、社区协作、工具生态和真实部署场景，做成可运行的工程系统。