【导读】OpenClaw近期在AI Agent圈层热度攀升：它允许把“可执行”的智能体部署到自己的服务器上，通过Telegram、飞书等Channel进行对话，并进一步调用Skills执行定时任务、联网检索、操控浏览器、编写与部署代码等操作。本文以一台2核4G的Ubuntu云服务器为例，复盘从Node环境、安装引导到Skills选择、embedding长期记忆、SearXNG+Crawl4AI联网查询，以及Dashboard外网访问（Cloudflare Zero Trust Tunnel）的完整打通路径。
一、从干净系统开始：安装OpenClaw与Onboarding关键选择
OpenClaw的定位更像“可托管的AI Agent运行时”：你不仅能对话，还能让Agent在服务器里执行任务与自动化流程。也正因其具备系统操作能力，部署时最重要的前置条件之一是——尽量在“干净的系统”上安装，避免对重要文件造成误删或误改带来的风险。
硬件与系统选择方面，2核4G的Linux云服务器在多数个人与企业PoC场景足够使用；如果有Mac mini等设备，macOS生态在某些功能支持上更丰富，但对通用部署而言Ubuntu更具可复制性。
1）Node环境：用版本管理器锁定Node 22
在环境准备阶段，一个常见策略是使用Node版本管理工具，避免系统自带Node版本不一致引发的依赖问题。示例流程如下（保留原始命令形态，便于照做）：
curl -fsSL https://fnm.vercel.app/install | bash source ~/.bashrc fnm install 22
2）安装OpenClaw：一条脚本命令 + 可重复的Onboarding
OpenClaw的安装可通过脚本快速完成：
curl -fsSL https://openclaw.ai/install.sh | bash
安装后会进入新手指引。如果当时误操作跳过，可以用下面的命令重新触发引导（包含daemon安装）：
openclaw onboard --install-daemon
在Onboarding阶段，一般会遇到几个决定后续体验的选择：
- QuickStart：偏向快速跑通主链路，适合首次安装。
- 模型供应商配置：会要求填写API Key / Base URL等。需要注意部分供应商的海外版Base URL差异：例如Moonshot AI、Z.AI如果使用国内API Key但Base URL不匹配，可能无法直接工作。
- Codex OAuth：在支持的情况下，OAuth方式的接入会更顺滑，减少Key管理成本。
- Channel（对话渠道）：决定你从哪里“跟Agent说话”。
3）Channel配置：Telegram/Discord/飞书的取舍
OpenClaw支持多个渠道。若追求生态成熟与Bot能力，Telegram、Discord通常更方便；若更贴近国内企业协作场景，飞书是更现实的入口。
以Telegram为例，需要先在Telegram里找到 @BotFather，创建自己的bot，获取 TELEGRAM_BOT_TOKEN，再回填到OpenClaw的配置流程中即可完成绑定。
4）基础组件建议：skills、homebrew、pnpm等
Onboarding过程中会出现一系列安装选择。常见的组合是：
- skills：开启
- homebrew：开启（取决于环境）
- node manager：pnpm（偏向工程化与依赖管理效率）
这些选项的共同目标是：让Agent后续“自我扩展”的链路更顺畅——也就是能装、能跑、能更新。
二、技能与能力扩展：从Skills生态到长期记忆与联网搜索
跑通安装只是起点，OpenClaw真正的“可用性”来自三类能力：Skills生态、长期记忆（embedding）、联网检索（自建或接入）。它们决定了Agent能否从聊天助手走向“可交付任务的搭档”。
1）Skills：把能力变成可安装模块
在Skills选择上，有几类模块会显著提升使用上限，尤其适合把Agent作为长期在线的执行体：
- clawhub：更像公共Skills注册中心，便于发现与安装更多Skills。
- MCPorter：用于对接MCP相关能力（面向工具化与多能力组合）。
- model-usage：帮助追踪模型调用与消耗（对成本与配额管理有价值）。
- summarize：总结能力的“产品化”入口，适合沉淀为可复用工作流。
当你把“某次对话里做成的能力”封装为skill后，后续就不再依赖临时prompt复现，而是形成稳定的调用入口。
2）安装浏览器：让Agent能“操作网页”
OpenClaw支持由Agent控制的专用浏览器（基于其运行时与配置隔离机制）。通常你只需要向Bot下达安装浏览器的指令，例如安装Chrome，即可完成依赖准备。这类能力对于抓取数据、表单操作、后台配置、低代码式流程自动化非常关键。
3）接入embedding模型：为“长期记忆”铺底
如果希望Agent具备更稳定的长期记忆与检索能力，embedding模型是基础组件之一。实践中可以接入一些可用的填写服务，例如 Qwen3-Embedding-8B 等，并将供应商端点与模型id交由ClawBot完成配置。
embedding的价值在于：它让Agent具备“可检索的历史经验库”，不仅记住聊天上下文，更能在任务中单用过去的决策与资料。
`4）搭建联网查询：用SearXNG + Crawl4AI复刻Tavily式能力
默认配置中常见的联网检索会让你配置Brave等服务，免费额度（例如每月1000次）对轻量场景够用；但如果你想更可控、更可扩展，可以自建检索与抓取链路。
一种可行组合是：
- SearXNG + Crawl4AI：实现“搜索 + 内容抓取/清洗”的闭环
- 输出格式：json、markdown（便于后续skill或RAG链路调用）
- 搜索策略：SearXNG优先使用 brave+mwmbl，以 duckduckgo 作为备用
- 部署形态：docker运行
- 再编写skill：把该服务封装成类似Tavily的调用接口供Agent使用
这条路径的关键 在于“
代某个商业API”，而在于把联网检索变成你可控的基础设施：可观测、可扩容、可定制过滤规则与输出结构。
5）自检查与健康诊断：doctor与文档对齐
当能力逐渐叠加后，建议让ClawBot访问OpenClaw文档进行自查，或直接执行健康检查命令：
openclaw doctor
这样能更快暴露权限、依赖、daemon状态、渠道连接等问题，减少“看似能聊、但跑不动任务”的隐性故障。
三、Dashboard外网访问：Cloudflare Tunnel与token/pairing双重校验
OpenClaw提供图形化Dashboard便于配置与监控。若希望外网访问，常见做法是通过Cloudflare Zero Trust做内网穿透（Tunnel），把本地服务安全暴露到域名上。
1）Dashboard的访问机制：token -> pairing
Dashboard并非“有域名就能进”，其访问链路通常包含两层校验：
- URL携带 token：形如 http://127.0.0.1:18789/?token=xxx
- 首次访问设备需要 pairing 配对审批
因此当你通过Tunnel访问时，如果出现类似错误提示（如unauthorized/token missing），大概率是缺少token或未完成pairing。
2）Cloudflare Zero Trust Tunnel：把18789映射到域名
在Cloudflare Zero Trust中创建Tunnel并部署Connector后，需要配置一个公开域名与服务地址的映射关系，例如：
- Public hostname：clawbot.example.com
- Service：http://127.0.0.1:18789
保存后，外网即可通过域名访问到Dashboard入口。
3）获取tokenized URL：openclaw dashboard --no-open
如果外网访问提示缺少token，可以在服务器端执行以下命令拿到tokenized URL：
openclaw dashboard --no-open
输出会包含类似：
- Dashboard URL: http://127.0.0.1:18789/?token=xxx
此时把 ?token=xxx 拼到你的外网域名后，例如：
clawbot.example.com?token=xxx
即可满足token校验要求。
4）处理pairing required：批准新设备
当出现 disconnected (1008): pairing required，通常意味着新设备尚未被批准。可以在服务器执行：
openclaw devices list
找到待批准设备并通过，即可完成pairing，恢复连接。
5）渠道绑定变更：新增Agent可能“接管”同一Channel
一个容易踩的坑是：新增Agent时如果选择复用main agent的channel，可能会导致channel绑定被切换，你从该渠道发消息时命中的Agent发生变化。解决方式一般是让agent执行“更换绑定渠道”的配置操作，或重新规划不同Agent对应不同channel。
结语：技术背后的管理思考
OpenClaw这类可自托管AI Agent之所以被关注，本质上是它把“对话式AI”推进到“可执行的工作单元”：既能通过Telegram/飞书等Channel进入日常协作，又能依赖Skills、定时任务、浏览器控制、联网检索与embedding长期记忆，形成可持续迭代的个人/团队工作流。对企业管理者与HR而言，这意味着数字化不再只是“上系统”，而是开始出现可拆分、可授权、可审计的“数字员工”雏形：哪些任务能交给Agent自动完成，哪些需要人类审批；如何通过model-usage等机制做成本与权限治理；又该如何定义岗位能力，把“会用Agent编排流程、会写skill、懂MCP/RAG基础”的复合技能纳入人才画像与培训体系。正如红海云在探索新一代人力资源管理解决方案时所强调的，技术的终极价值在于赋能组织：当AI Agent逐步进入业务流，企业更需要用制度、权限、流程与绩效口径，把效率红利转化为可规模化的组织能力。
