后端前端AI 技能AI 插件搜索引擎【免费下载链接】clawhubSkill Plugin Registry for OpenClaw项目地址https://gitcode.com/gh_mirrors/mo/clawhub点击查看免费下载本篇技术指南围绕 ClawHub 仓库内置的 Agent 技能.agents/skills/convex-acquire-domain/SKILL.md展开讲解如何通过 Convex 的 labs 能力为当前 Convex 应用完成「域名头脑风暴 → 实时询价 → 注册 → DNS 指向 → 绑定自定义域名 → 重绑 Auth Origin → 重新发布」的完整闭环。读完本文你将掌握该技能的四步工作流、三条硬性安全规则以及 ClawHub 源码中与自定义域名、Auth Origin 相关的底层实现原理可直接复用到任何 Convex 应用的域名上线流程中。技能定位这不是买域名而是给部署换门牌convex-acquire-domain是 ClawHub 仓库中定义的一个 Agent 能力文件SKILL.md它的描述是Find and buy a domain for the current Convex app through Convex, then bind it (labs; spend action).翻译过来即通过 Convex 平台为当前 Convex 应用寻找并购买域名然后把该域名绑定到部署上。它有两个关键定语labs这是 Convex 平台处于实验阶段的能力使用时需要有对应的平台开关支持spend action注册域名会产生真实费用因此该操作被归类为花费类动作且是Tier-2 等级——意味着它比普通写操作更敏感执行前需要更严格的确认门槛。理解这一点很重要Agent 自身并不持有注册商账号或 API 凭据真正的注册动作由Convex 控制平面control plane代劳底层经由 DNSimple 注册商完成Agent 在整个流程中只负责提建议、问价格、等确认、做绑定。这从根上规避了把注册商密钥暴露给 Agent 的安全风险。这个技能文件位于仓库的.agents/skills/目录属于 ClawHub 为 OpenClaw Agent 生态预置的自动化能力之一。ClawHub 本身就是一个部署在 Convex 之上的 Skill Plugin Registry参见 convex.json 中functions: convex的配置因此为一个 Convex 应用买域名并绑到部署正是这个仓库日常运维会真实遇到的场景。四步工作流从头脑风暴到域名上线技能文件把整个流程压缩为清晰的 4 个步骤任何一个环节都不能省略第 1 步头脑风暴候选域名实时检查可用性与年价格针对当前应用的产品定位先构思 35 个贴题on-theme的候选域名然后逐个查询实时可用性live availability域名是否尚未被注册年费价格annual price每个候选域名的一整年注册费用。注意这里的实时——价格和可用性都是动态数据必须当场从 Convex 的查询接口获取而不是使用 Agent 记忆中的历史缓存。第 2 步展示带价格的最优选项等待用户明确选择把查询结果整理成域名 年费的候选清单呈现给用户。此时 Agent 不能有任何动作必须等待用户对某个具体域名给出明确同意explicit yes / explicit pick。这是技能规则中的第一条红线。第 3 步通过 ConvexDNSimple注册域名在用户明确选定域名后触发 Tier-2 花费操作注册动作由Convex 控制平面执行经由 DNSimple 注册商完成注册Agent 全程不接触注册商凭据registrar credential既无法看到也无法使用 API 密钥注册完成后域名的 DNS 记录已处于 Convex 可管理状态。第 4 步DNS 指向部署绑定为自定义域名重绑 Auth Origin 并重新发布注册成功后的落地动作分三步把 DNS 指向当前部署将域名的 DNS 记录解析到该 Convex deployment 对应的站点地址附加为 Convex 自定义域名在 Convex 平台上把该域名挂到当前 deployment 上使其成为对外可访问的自定义主机名重绑 Auth OriginRP_ID / ORIGIN并重新发布域名变更会改变认证来源必须同步更新认证配置并重新部署即re-publish否则认证回调会指向旧的来源导致登录链路失效。第 4 步是全流程中最容易踩坑的一环下一节会结合 ClawHub 源码说明它为什么必然发生。三条硬性规则技能的安全边界技能文件在 Workflow 之外专门列出了三条不可逾越的规则它们共同构成了该技能的安全模型规则含义设计动机Never register without an explicit yes on a specific domain必须针对某一个具体域名得到明确同意后才能注册防止 Agent 在对话中顺手买下未获授权的域名产生真实账单Show the price before registering注册前必须展示价格花费动作前用户有权知情避免隐性扣费If the user already owns a domain, hand off to thedomainscapability用户已有域名时转交给domains能力而不是新买一个已有域名走绑定流程即可重复购买是浪费该技能只负责购买新域名的场景Rebinding the domain changes the auth origin — re-publish after重绑域名会改变认证来源操作后必须重新发布保证认证配置与线上部署始终一致第 3 条尤其体现了能力划分的工程思维买域名和管已有域名是两个不同的能力域Agent 应该把工作交给最合适的工具而不是自己硬扛。源码佐证为什么绑定域名必然要重绑 Auth Origin技能文件要求rebind the auth origin (RP_ID/ORIGIN)这在 ClawHub 的认证配置中有着直接对应的实现证据。Auth Origin 的配置入口ClawHub 的 Convex 认证配置位于 convex/auth.config.ts其中关键的一段export default { providers: [ { domain: process.env.CONVEX_SITE_URL, applicationID: convex, }, ], };providers[0].domain取自环境变量CONVEX_SITE_URL——这正是认证回调所声明的来源域名。当你把自定义域名绑定到部署后这个来源域名就变了对应 WebAuthn 语义中的RP_IDRelying Party ID与 OAuth 语义中的ORIGIN都要随之更新。如果只绑定域名而不重绑 Auth Origin浏览器会因认证请求来源与已注册的 RP_ID 不匹配而拒绝继续登录。自定义域名在站点 URL 解析中的优先级ClawHub 在 src/lib/convexDeploymentUrl.ts 中实现了一个关键的解析函数resolveConvexSiteUrl它的决策顺序恰好印证了自定义域名优先的语义如果显式提供了VITE_CONVEX_SITE_URL自定义域名的入口直接使用它的 origin否则从VITE_CONVEX_URL形如https://deployment.convex.cloud派生对应的https://deployment.convex.site本地开发时localhost/127.0.0.1/[::1]原样返回。配套的单元测试 src/lib/convexDeploymentUrl.test.ts 明确验证了这条路径it(prefers an explicit site URL for custom domains, () { expect( resolveConvexSiteUrl({ VITE_CONVEX_SITE_URL: https://api.preview.example/, VITE_CONVEX_URL: https://preview-branch-123.convex.cloud, }), ).toBe(https://api.preview.example); });也就是说只要设了自定义域名的 site URL整个应用对外暴露的来源就会切到新域名。这从源码层面解释了为什么附加为自定义域名与重绑 Auth Origin必须成对出现——它们共享同一个配置入口CONVEX_SITE_URL/VITE_CONVEX_SITE_URL。为什么要re-publish构建期编译而非运行期读取ClawHub 的部署规范 specs/deploy.md 明确指出Nitro 服务端处理/api/**与/v1/feeds/**时目标地址来自构建期的VITE_CONVEX_SITE_URL或由VITE_CONVEX_URL派生Those build-time values are compiled into the Nitro server output so stale Vercel runtime variables cannot redirect a Preview deployment to production.也就是说这些站点 URL 是在构建/发布时编译进产物的而不是运行时动态读取的。因此更换域名后若不重新发布线上产物里编译进去的还是旧域名——这正是技能规则要求re-publish after的底层原因。重新发布让新的自定义域名连同新的 Auth Origin真正进入服务端产物与认证配置才能保证端到端一致。仓库内的一致实践registry.openclaw.ai 的域名绑定要求ClawHub 自身就在生产环境使用自定义域名这一实践可以佐证技能第 4 步的必要性。在托管目录源规范 specs/hosted-catalog-feed.md 中写明Theregistry.openclaw.aicustom domain must point at the same Vercel project before the public RFC URLs are enabled.即生产环境的自定义域名registry.openclaw.ai必须与部署位于同一个 Vercel 项目才会启用公开的 RFC URL。这与技能的把 DNS 指向部署 附加为自定义域名是同构的落地要求——自定义域名不只是 DNS 记录它必须与承载部署的项目/环境严格对齐否则流量会打到错误的后端。对技能第 4 步中Point DNS at the deployment而言可以从源码推断具体指向什么convexDeploymentNamesrc/lib/convexDeploymentUrl.ts从https://name.convex.site形式的 URL 中提取部署名也就是说自定义域名最终需要解析到该部署的name.convex.site站点地址通常是 CNAME / ALIAS 记录再由 Convex 平台在自定义域名与部署之间完成关联。实战操作清单把技能内容落成一份可照做的清单确认前提当前 Convex 应用已存在且可访问且你已启用 Convex 的 labs 域名能力。产出候选让 Agent 给出 35 个与产品主题相关的候选域名逐个查询实时可用性与年费。人工确认检查域名 年费清单只对最终选定的那一个域名说是。触发注册由 Convex 控制平面DNSimple完成注册Agent 不接触任何注册商凭据。指向部署把新域名 DNS 解析到部署的站点地址如name.convex.site并附加为 Convex 自定义域名。重绑 Auth Origin更新CONVEX_SITE_URL/VITE_CONVEX_SITE_URL环境变量对应 convex/auth.config.ts 的providers[0].domain与 convexDeploymentUrl.ts 的解析逻辑。重新发布重新构建并部署使编译产物携带新域名与新认证来源。回归验证访问新域名确认首页、/api/*路由与认证登录全部工作正常如用户本已持有域名直接改走domains能力做绑定跳过购买环节。需要强调的最后一点该技能文件本身标注为labs功能且属于花费动作生产环境启用前请确认所在 Convex 项目已开通对应能力并确保本地开发VITE_CONVEX_URLhttp://127.0.0.1:3210等回环地址与生产配置互不混淆——ClawHub 的 CONTRIBUTING.md 中关于端口与站点 URL 对齐的提醒同样适用于接入了该技能的任意 Convex 应用。赞分享后端前端AI 技能AI 插件搜索引擎【免费下载链接】clawhubSkill Plugin Registry for OpenClaw项目地址https://gitcode.com/gh_mirrors/mo/clawhub点击查看免费下载相关推荐非自回归机器翻译模型训练脚本全解析NAT / NAT-CRF / iNAT / InsT / CMLM / LevT 实战指南非自回归机器翻译模型训练脚本全解析NAT / NAT CRF / iNAT / InsT / CMLM / LevT 实战指南 导读 本指南围绕 kosmos后端前端AI 技能AI 插件搜索引擎ClawHub 实战为 Convex 应用接入 convex-dev/auth 认证Passkey / OAuth 完整接线指南ClawHub 实战为 Convex 应用接入 convex dev/auth 认证Passkey / OAuth 完整接线指南 本文是一份面向 Con后端前端AI 技能AI 插件搜索引擎使用 AWS CLI 解绑 App Runner 自定义域名disassociate-custom-domain 实战指南使用 AWS CLI 解绑 App Runner 自定义域名disassociate custom domain 实战指南 导读 本文聚焦 AWS CLI 中开发工具云原生运维上一篇Voyager 1.6 入门指南Laravel 管理后台的安装、配置与 Admin 用户创建下一篇探索现代桌面美学Paper图标主题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考