企业官网建设流程全解析

1. 为什么我会把自媒体编辑和发布交给openclaw来跑

做自媒体的人应该都有这种感受：内容创作本身已经够累了，更折磨人的是那些重复性的琐碎操作——把一篇稿子从笔记里翻出来，手动复制到编辑后台，调整格式，配图，选定时发布，再到另一个平台重复一遍。如果同时管着公众号、知乎、小红书三个平台，光是“发布”这一步就能吃掉你每天半小时。

我选择openclaw来做自媒体编辑和发布，目标很明确：把“选题-初稿-润色-排版-发布-数据回收”这条链路里能自动化的部分全部自动化，让我把精力集中在真正需要人的事情上，比如观点、判断和跟读者的互动。

先解释一下openclaw是什么。它本质上是一个开源的AI智能体（Agent）框架，不绑定任何一家大模型厂商，可以接本地模型也可以接云端API，核心能力是让你把“调用模型、读写文件、执行命令、访问网络接口”这些动作编排成一条完整的工作流。和市面上一些一键生成文章的套壳工具不同，openclaw更像一个流水线底座：你想让它干什么、按什么顺序干、干到什么程度可以停下来问你，都由你自己定义。

这套东西很适合自媒体场景，原因有三：第一，自媒体内容生产本身就是流程化动作，适合拆解成Agent任务；第二，我的账号密码、API Key、素材库都在自己手里，用开源框架部署在本地或自己的云服务器上，不用把内容平台账号托管给第三方；第三，我现在主力机是Windows，日常用Obsidian管理素材和灵感，openclaw可以通过Companion组件跟本地文件系统打通，正好契合我的工作习惯。

当然，截至目前这类AI智能体工具林林总总，像workbuddy也做类似的事情，但我选择openclaw的核心理由是它的开源属性和可定制性。别人封装好的产品可能开箱即用，但到了真正跑自媒体工作流的时候，你就会发现每个平台的发布接口、每个模型的输出习惯、甚至每篇稿子的“个人风格”都不一样，没有一个固定模板能覆盖所有需求。自己手里有源码，改起来才踏实。

这篇文章我会把从零搭建到实际运行的完整过程写清楚，包括Windows下WSL2环境怎么配、本地模型怎么接、工作流怎么设计、云服务器部署要注意什么，以及我在实测中踩过的各种坑。如果你也是那种喜欢自己掌控流程的技术型创作者，这篇应该能帮你省掉不少摸索时间。

2. Windows下部署openclaw：WSL2、Node.js和Companion的组合拳

2.1 为什么我不直接在Windows里跑，而是绕道WSL2

很多人在Windows上装这类工具时习惯直接找Windows安装包，但openclaw的项目依赖大多是为类Unix环境设计的，直接跑在Windows原生的CMD或PowerShell里会遇到一堆路径问题和权限问题。我的做法是绕道WSL2：在Windows上装一个Ubuntu子系统，所有openclaw相关服务都跑在Ubuntu里，Windows这边只负责装Companion作为桥接。

这么做还有一个好处：后续如果我想把openclaw迁移到云服务器，云上也是Ubuntu环境，本地和云端的部署逻辑就是一致的了，不用维护两套不同的配置。对自媒体这种需要长期迭代的工作流来说，环境一致性比什么都重要。

WSL2的部署本身不复杂，但我在第一步就被“无法安全验证WSL环境”这个报错卡了一下。事情是这样的：按照教程执行wsl --install之后，系统提示我重启，重启完一运行wsl --status就报错，说无法安全验证。排查了一圈才发现问题是WSL内核版本太旧，和当前Windows版本的Hyper-V组件对不上。解决办法比较直接，在PowerShell管理员模式下执行wsl --update把内核更新到最新，再执行wsl --status就能看到默认版本、内核版本和正在运行的发行版列表了。如果你也遇到这个报错，先别急着重装系统，按这个顺序排查准没错。

2.2 在Ubuntu里安装openclaw的基本步骤

进到WSL2的Ubuntu环境后，安装openclaw大体上就是三件事：装Node.js、拉项目代码、装依赖。

先说Node.js。openclaw对Node版本有最低要求，建议装20以上的LTS版本。我在WSL里用nvm管理Node版本，这样以后升级和切换都方便：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 node -v

Node装好之后，把openclaw的代码仓库clone到本地，进入目录执行npm install。这一步时间比较长，依赖包很多，耐心等就好。如果中间有网络波动导致失败，不用慌，删掉node_modules重新install即可。

安装完之后，openclaw会在用户目录下生成一个配置文件夹，里面包含主配置文件、Agent定义目录和日志目录。我第一次启动时没有改任何配置，直接跑了一遍测试任务，确认框架本身能转起来，再开始做定制。这一步很重要，先把系统跑通，再谈自媒体工作流，否则一上来就扎进配置细节里，出了问题根本分不清是框架问题还是自己的配置问题。

2.3 Companion配置的正确打开方式

Companion是openclaw在Windows下的一个桥接组件，作用是把宿主机（Windows）这边的文件系统、剪贴板、浏览器会话等资源暴露给WSL2里跑的agent使用。简单说，没有Companion，agent就只能在WSL的隔离环境里活动，没法帮你读写桌面上的Obsidian笔记库。

配置Companion时有几个点特别容易踩坑：

第一，Companion服务默认监听某个本地端口，但WSL2的网络是NAT模式，Windows访问WSL2里的服务不能用localhost直连。你需要确认WSL2实例的内部IP，然后在Companion配置里把要暴露的目录路径和服务地址填写正确。第二，openclaw连接Companion时需要在配置里设置与你实际启动的端口一致，别照着网上的教程端口照抄。第三，如果你在Windows防火墙里开了拦截，记得放行Companion所在端口的入站连接，否则连上了也会超时。

我踩过一次印象很深的坑：Companion明明显示服务已启动，openclaw却一直报“无法连接到Companion”。最后查出来是我在WSL2里用了wsl hostname -I拿到的IP，跟Windows侧实际访问的IP不是同一个。WSL2重启之后IP会变化，所以不要在配置文件里写死IP，直接用localhost加端口转发规则，或者给WSL2设置镜像网络模式，让localhost直接互通，这样配置最省事。

3. 把qwen2.5-3B接入openclaw：本地模型还是API模型

3.1 我为什么选qwen2.5-3B当主力模型

自媒体内容以中文为主，所以模型的中文能力和性价比对我来说是第一位的。我最终选了qwen2.5-3B这个参数规模的模型，原因有三个：

第一，中文语境理解够用。3B模型不算大，但在编辑润色、改写段落、提炼摘要这种指令性任务上表现足够好，不会像更小的模型那样频繁出现词不达意。第二，资源门槛低。量化之后跑起来大概需要2-3GB内存，我本地机器16GB内存完全没压力。如果你有4GB显存的显卡，用Ollama加载GPU版本会更流畅。第三，不花钱。本地跑模型不产生API费用，对于我这种日更三个平台的场景，一个月下来能省不少。

当然，本地模型也有短板。qwen2.5-3B生成的长文容易出现前后逻辑松散、重复啰嗦的问题，所以我在工作流里设计了一个“分段生成再合并润色”的环节，后面详细说。如果你预算充足，也可以把qwen2.5-72B通过云端API接进来，质量会提升不少，但成本也上来了，看个人取舍。

3.2 Ollama的安装与模型拉取

本地跑模型我用的Ollama，它跟openclaw配合非常顺。安装就一条命令：

curl -fsSL https://ollama.com/install.sh | sh

装完启动服务，然后拉取模型：

ollama pull qwen2.5:3b

拉取时间取决于网速。拉完可以先单独测试一下模型能不能正常对话，确认没问题再去配openclaw，这样问题定位更清晰。

3.3 在openclaw里定义模型Provider

openclaw的模型配置是Provider模型，一块区域定义模型服务商，另一块定义具体Agent默认用哪个模型。我这里给出一个简化的配置片段，使用Ollama的OpenAI兼容接口：

providers: ollama: type: openai base_url: http://localhost:11434/v1 api_key: ollama models: - qwen2.5:3b agents: editor: provider: ollama model: qwen2.5:3b max_tokens: 8192 temperature: 0.7

这里有个细节：Ollama的兼容接口其实不校验API Key，随便填什么都行，但字段不能为空。max_tokens我建议设大一点，因为自媒体文章的稿子动辄上千字，如果默认的2048很容易在生成中途截断，导致半拉子文章。另外temperature控制随机性，初稿阶段可以设0.8以上，让文案更有发挥；到了润色和格式整理阶段我会降到0.3，求稳定。

如果你用的是阿里云的模型API，配置逻辑也一样，只是base_url换成对应服务的地址，api_key填你自己的Key。注意不要在公开仓库里泄露Key，环境变量或者本地配置文件单独管理。

4. 自媒体内容工作流：从Obsidian素材库到多平台定时发布

4.1 素材库整理：让openclaw能读懂你的笔记

我平时所有选题、想法、资料都沉淀在Obsidian里。要让openclaw自动从笔记库里提取素材，前提是笔记结构足够规范。我的做法是给每篇笔记加上YAML frontmatter元数据，这样agent可以精确过滤和读取：

--- tags: [自媒体, AI工具] type: idea target: [公众号, 知乎] keywords: [openclaw, 自媒体自动发布] status: draft created: 2025-02-01 ---

这里的关键是type和target字段。type标记笔记类型，是灵感、素材、还是已成稿；target标记这篇内容计划发到哪个平台。openclaw读取笔记库时，会先扫描frontmatter，把所有status: draft且type: idea的文件当作待处理素材，然后再进入工作流。这样一来，我平时在Obsidian里随手记的碎片想法，只要打上标签，就会被自动抓取形成选题候选，非常省心。

4.2 工作流怎么设计：四个Agent协作

我设计的自媒体工作流一共四个环节，对应openclaw里的四个Agent角色：

选题Agent：从Obsidian素材库扫描所有打标笔记，按照关键词相关度和时效性，筛选出当前值得写的3-5个选题，生成一版选题列表，附上每个选题的切入角度和参考资料路径。

写作Agent：针对选定的选题，读取相关素材笔记，调用qwen2.5-3B生成初稿。生成的规则是分段落写，每次只写一个章节，写完一段保存一段，避免长文生成中途截断导致全部丢失。

编辑Agent：对初稿进行润色和格式化。这里会检查错别字、拆分过长句子、补充小标题、转化口语化表达，还要按不同平台的语气微调：公众号偏深度，知乎偏理性结构，小红书偏轻松种草。

发布Agent：触发各平台的发布接口或保存草稿。正规路径是我整理好的发布脚本，通过平台开放API推送；如果该平台没有开放接口，就生成一个带完整标题、正文、标签的Markdown文件，放到“待人工发布”目录，我手动粘贴。

整个链条在openclaw里就是一组串行任务。这个工作流我用一个简单的cron表达式定时触发，每天早上跑一次选题和初稿生成，下午跑编辑和发布准备，这样我不会被任务“卡”在电脑前，什么时段出什么成果是固定的。

4.3 人工介入点：别把发布按钮完全交给Agent

从我实际使用经验来看，你可以让openclaw自动完成度达到90%，但最后那10%的人工确认必须保留。尤其是涉及事实陈述、观点判断、价值导向的内容，AI生成的稿子再流畅也不能直接替你做决定。所以我的流程里发布Agent默认只会生成草稿，不会真正点发布按钮。只有我手动检查定稿后，才允许执行发送动作。

这一点不只是为了内容质量，也是为了合规安全。自媒体内容一旦发出去就覆水难收，审核这一个动作无论如何都不能省略。所以openclaw的价值是帮你把发布前的所有准备工作压缩到最短，而不是替代你做最终判断。

5. 云服务器部署：把openclaw从“开机才能跑”变成7x24小时服务

5.1 为什么我最终决定上云

本地WSL2方案最大的问题是：定时任务必须依赖电脑开机。我的台式机不可能7x24小时挂着，而且WSL2默认网络模式重启后IP会变，Companion连接也要跟着调整。一旦出门或断电，整个自媒体流水线就停了。

所以我后来把openclaw的核心服务搬到了云服务器上。正好现在云厂商都有免费试用额度，我当时用阿里云的新用户免费试用名额开了一台2核4G的Ubuntu实例，把这些年一直想试的云端部署彻底跑了一遍。

5.2 云服务器上的安装与systemd守护

云端安装流程和本地WSL2基本一致，但也有些差别。云服务器是纯净Ubuntu环境，不需要WSL这层，直接装Node.js 20、clone仓库、npm install，就可以了。装完同样配置Ollama和模型，然后把工作流目录和素材同步机制准备好。

为了让openclaw在退出生效后也能稳定运行，我用systemd做了服务守护。一个简单的unit文件长这样：

[Unit] Description=openclaw self-media agent After=network.target ollama.service [Service] User=ubuntu WorkingDirectory=/opt/openclaw ExecStart=/usr/bin/node /opt/openclaw/src/index.js Restart=always RestartSec=10 Environment=NODE_ENV=production [Install] WantedBy=multi-user.target

这个配置的效果是：服务器一开机，openclaw自动跟着启动；进程意外退出后，systemd会在10秒内自动拉起；如果Ollama服务还没起来，它会等待依赖服务就绪后再启动。这一步做完了才算真正达到“无人值守”的状态。

5.3 本地Obsidian和云端openclaw之间的素材同步

服务上了云，素材库还在本地怎么办？我的方案是用Git做同步：本地Obsidian笔记库是一个Git仓库，每次编辑完推送到远端；云端clone一份同样内容，openclaw的选题Agent扫描云端工作目录。这样做的好处是一份素材两处用，本地负责写作和灵感整理，云端负责执行和输出，互不干扰。

同步频率我设置了30分钟一次，对自媒体场景完全够用。如果你希望更快，也可以用webdav或对象存储，但Git对我来说最直观，而且自带版本历史，改坏了还能回滚。

5.4 云端部署的安全注意项

这里必须多说几句。把openclaw部署到公网服务器后，暴露面比本地大得多。我的建议是：

• openclaw的管理端口不要直接绑定公网IP，只监听127.0.0.1，通过Nginx反向代理加访问认证，或者干脆只用SSH隧道访问。
• API Key和Companion密钥永远不要写进Git仓库或公开配置文件，用环境变量或独立的secrets文件加载。
• 素材库里如果有未发布稿或其他隐私内容，要确保目录权限只有运行用户能读。

我见过不少人在云服务器上把Dashboard端口直接暴露出去，没过两天就收到陌生IP的扫描和爆破日志。这不是危言耸听，安全意识在自动化内容生产场景里同样重要。

6. 实测中遇到的坑与排错记录

6.1 “无法安全验证WSL环境”的完整排查过程

这个报错我之前提了一嘴，这里展开说说完整的排查链路，方便遇到同样问题的读者参考。

我的排查顺序是这样的：先运行wsl --status看系统报什么错，确认是内核验证失败；然后wsl --update更新内核，重启WSL再试；如果仍然失败，检查Windows的虚拟化功能是否开启，在PowerShell里运行systeminfo查看Hyper-V要求那一栏；确认没问题后，再检查应用商店里的WSL服务是否处于启用状态。

最保险的兜底方案是：控制面板里关闭“适用于Linux的Windows子系统”和“虚拟机平台”两个功能，重启，再重新勾选，重启。这个操作能让系统彻底重装WSL组件，适用范围最广。做完这套，我的WSL环境才恢复正常。整个过程跟openclaw本身没有关系，但它属于用openclaw做自媒体前必须趟过的基础设施坑。

6.2 localhost连不上：WSL2网络模式引起的幻觉

另一个高频问题：openclaw在WSL2里启动，Windows上的Companion却连不上。不是端口没开，而是WSL2默认NAT模式下，Windows侧访问WSL2里的服务不能用localhost。很多旧教程会让你查wsl hostname -I拿一个动态IP填进去，但WSL2每次重启IP都会变，填了等于没填。

我的解决方案是给WSL2配置镜像网络模式。在用户目录下的.wslconfig文件里写：

[wsl2] networkingMode=mirrored

保存后执行wsl --shutdown重启WSL，网络模式就生效了。之后再访问WSL2里的服务，直接用localhost就能通，不需要管IP地址。这个改动对我的部署效率提升是肉眼可见的，强烈建议Windows 11用户在跑openclaw时优先配置。

6.3 内存不够：3B模型也能把机器搞崩

主机的内存虽然不算小，但我同时跑Obsidian、浏览器、微信等一堆应用，再叠加WSL2里Ollama加载模型和Node进程，内存压力还是很明显。我遇到过几次系统卡死，查了一下是WSL2吃掉了所有内存。

解决办法是在.wslconfig里限制WSL2的内存上限，给Ollama设置并发限制，同时在Ubuntu里配置swap。我把内存上限设为主机物理内存的一半，预留一些给Windows本身和Obsidian。Ollama那边通过环境变量OLLAMA_MAX_LOADED_MODELS=1控制同时加载的模型数量，避免多个模型抢占资源。配置swap时我给了8G的swap文件，虽然慢，但至少不会频繁被杀进程。

如果你也打算在本地跑openclaw+qwen2.5-3B，我建议至少16G内存起步。低于这个配置，还是老实走云端API方案更省心。

6.4 生成稿总在中间断掉：长文截断与重试工作流

qwen2.5-3B在生成长文时，经常出现生成到一半就停住，或者开始重复之前段落的问题。这不是openclaw的问题，而是小型模型的上下文连贯性不足。我的应对措施是分段生成，一段控制在300到500字以内，每段都要求模型“只围绕当前小标题展开”，生成完由脚本拼接。拼接后再交给编辑Agent做一次通读和润色，把重复段落和语气断层修掉。

另外，openclaw的任务系统里有重试机制。我给每个生成任务配置了最多三次重试，如果某次生成结果超时或为空，自动换一个提示词变体重试。这招很管用，多试几次总比卡在流程里强。

7. 跑通全流程后的真实体会：哪些事可以放心交给openclaw，哪些必须留给自己

现在我的自媒体流水线已经稳定跑了将近一个月，每天早晨自动产出选题和初稿，下午自动生成平台适配版本，晚上我花二十分钟确认存档和内容质量，然后手动推送。这个工作流实实在在帮我省掉了每天至少两小时的机械劳动时间。

哪些事可以放心交给openclaw？重复性内容加工，比如格式转换、多平台适配、错别字修正、素材检索，这些它做得又快又稳。还有定时任务触发，比如每天固定时间启动选题扫描，这种事情交给机器近乎零失误。

哪些事必须留给自己？所有涉及事实判断、观点表达和情绪立场的内容。AI可以帮你写出通顺漂亮的文字，但写出来的内容是否真实、是否公允、是否符合自己的价值观，这些需要你亲自把关。这不是能力限制，这是责任边界。自媒体发出每一个字都会有人看到，都应该对读者负责。

另外分享一个小技巧：我让编辑Agent每次改稿后输出一份“修改说明”，列出它改动的地方和理由。一开始没什么用，但跑了两周之后，我发现它越来越贴合我的行文习惯，因为修改说明本身就是一种基于反馈的提示词学习，每次我手动改回来或确认的地方，也会被记录成规则沉淀下来。这种“越用越顺”的感觉，是本地部署开源Agent带给我最大的惊喜。

如果你正在考虑用openclaw做自媒体编辑和发布，我的建议是先跑通最小的闭环：一个模型、一个工作流、一个平台。先让它帮你生成一篇草稿，你手工发布一次，感受一下整个流程的顺畅度和输出质量。之后再去叠加Obsidian素材库、多平台发布、云服务器常驻这些高级功能。自动化这件事，步子迈太大容易翻车，从最小的闭环开始慢慢打磨，反而最快。