企业官网建设流程全解析

上个月我把OpenClaw跑在了一台落灰的安卓旧手机上，又在一台Windows老笔记本上装了Companion做联动实验。折腾完那几天我最大的感受是：这个项目真正难理解的地方，不在模型本身，而在于它把“模型怎么跟真实系统交互”这件事做成了一套完整的运行时体系。官方文档里管这一层叫Agent runtimes，社区里更多人直接叫它Harness。不管叫法怎么变，你只要搞懂了这一层，后面看Skill、看策略、看各种部署方案都会顺很多。

这篇是“理解Harness系列”的中间篇。上篇我们聊了OpenClaw是什么、Harness这个概念为什么会出现；这篇我打算把runtimes的核心机制彻底拆开：主循环怎么转、上下文怎么管、平台适配层做了什么、安全模型怎么兜底，再附上Windows、安卓Termux、内网服务器三种环境的完整部署记录。下篇再讲Skill开发和Harness工程化的进阶玩法。

先说明一点，我用的OpenClaw是基于Rust的版本，部署时间在近期的主线版本上，文中涉及的配置项和命令都以我当时操作的版本为准。这类项目迭代非常快，如果你看到的结构和我写的有出入，多半是版本差异，按实际版本调整即可。

1. 系列定位：为什么先啃run-times这一层

1.1 OpenClaw到底是个什么东西

简单说，OpenClaw是一个把大语言模型接进真实操作环境的AI Agent框架。它跟那些只能聊天的套壳应用不一样，它能让Agent直接调用你系统里的命令、读写文件、操作浏览器、控制手机上的App，甚至通过Companion组件操控多台设备。

我第一次看到它的宣传语“Agent anywhere”的时候，还以为是夸张营销，直到我真正在Termux里把它跑起来，看着它自己执行shell命令去装软件包，才意识到这个项目的野心确实大。它不是给你一个测试用的Playground，而是真的想把“AI操作计算机”这件事做成一个可落地的工程方案。

这个框架最特别的地方在于，它的核心是用Rust写的。选Rust不是炫技，是有实际考量的：Agent要操作真实系统，就必须处理大量系统级调用、并发任务、网络通信、进程管理，这些场景对内存安全和性能的要求都很高。Rust在保证安全性的同时，又能提供接近C语言的执行效率，恰好匹配这个需求。你用Python写一个玩具Agent不难，但想把它变成常驻后台、监听事件、随时响应指令的系统服务，Python那套GIL、内存占用、部署依赖会让你非常痛苦。

1.2 Harness不是模型，也不是API封装

很多第一次接触OpenClaw的人都有一个误区，觉得Harness就是把大模型的API封装了一下，加个聊天窗口。这个理解差得比较远。

我给Harness一个更直观的类比：如果说大模型是驾驶员的大脑，那Harness就是整辆车的驾驶舱。它负责把驾驶员的意图转化成方向盘、油门、刹车的实际操作，还要时刻盯着仪表盘上的各种状态，保证车辆在安全范围内行驶。没有驾驶舱，大脑再聪明也只是悬空的思想。

具体到OpenClaw的架构里，Harness承担了这些事：

• 运行循环的驱动：模型不是自己主动干活的，是Harness在循环里不断把环境状态喂给模型，拿到决策后再去执行。
• 上下文的组织与管理：模型有上下文窗口限制，Harness负责决定哪些历史信息保留、哪些压缩、哪些丢弃。
• 工具调用的中转：模型输出一个“调用某命令”的意图，Harness负责把它翻译成真实的系统调用并处理返回值。
• 安全策略的强制：模型说“帮我删掉这个文件”，Harness不会傻乎乎直接执行，它会先检查策略、请求用户批准。
• 多平台适配：Windows、Linux、Android的底层调用完全不同，Harness把这层差异全部抹平，让模型面对一个统一的“设备抽象层”。

所以你看，Harness的本质是“连接模型与物理世界的工程脚手架”。这也是为什么社区里越来越多人在讨论“harness engineering”——大家逐渐意识到，Agent项目能不能真正好用、可控、稳定，核心功夫全在这个脚手架里，模型本身反而越来越同质化。

2. OpenClaw runtime的核心机制拆解

2.1 运行时主循环：Agent到底是怎么“自动干活”的

理解OpenClaw的runtime，第一件事是理解它的主循环。我跟不少朋友聊过，大家习惯用“Agent会自己思考然后行动”这种拟人化描述，但这其实掩盖了底层的机械过程。真实情况是，Harness在一遍一遍地执行一个固定循环，每一步都极其机械：

1. 采集当前环境状态（有哪些新消息、哪些任务在队列、上一轮的执行结果是什么）。
2. 把这些状态整理成Prompt，连同历史上下文一起发给大模型。
3. 模型返回一个结构化响应，可能是自然语言回复、工具调用指令，或者一个状态更新请求。
4. Harness解析这个响应，校验安全性,执行对应操作。
5. 把执行结果和新的状态追加进上下文。
6. 回到第1步，继续循环，直到任务完成或达到终止条件。

这个循环里的关键点在于：模型是不持有任何状态的。它每次都是“失忆”的，它记得什么、不记得什么，完全由Harness决定。所以上下文管理其实是整个runtime里最容易出问题、也最值得花心思的地方。

我在实际使用中观察到，OpenClaw的上下文管理不是简单地“把所有对话历史都塞进去”。它有一套自己的优先级逻辑：系统指令和Skill定义永远在最核心的位置，然后是用户明确的意图和当前任务状态，再是老旧的对话记录。当上下文接近窗口上限时，它会主动摘要压缩早期的内容，而不是粗暴截断。这个做得比很多我见过的框架都细。

至于“Agent会不会跑飞”这个问题，其实也靠主循环控制。Harness里有一个“最大循环次数”的兜底参数，如果你不设，一个卡在死循环里的Agent可能会无限调用同一个命令。我自己的习惯是，凡涉及文件批量操作或多步骤任务，一定设置上限，宁可任务完不成中断掉，也不能让它无限占着资源。

2.2 多平台runtimes：Windows、Linux、Android在跑同一个Agent

标题里写了“runtimes”复数，这不是笔误。OpenClaw的Runtime不是一个单一的可执行文件，而是一组适配不同平台的运行时组件的统称。这是它最有工程味道的一个设计。

你在Windows上装的OpenClaw，跟你在Linux服务器上装的，跟你在安卓Termux里装的，核心逻辑完全一样，但底层交互层不同。Windows下有Companion组件专门负责桌面级的窗体操作和系统集成，Linux下会直接走Shell和系统调用，Android端则运行在一个受限的用户空间里，通过Termux提供POSIX环境。

这套“一个核心、多端适配”的架构，用一句话概括就是：模型看不懂操作系统，Harness负责翻译；而不同的操作系统有不同的方言，Runtime就是那个懂各方言的翻译官。

举个具体场景：我在Windows上让Agent打开一个应用的窗口，它调用的是Windows API级别的操作；同一段指令放到安卓手机上，它走的是Android的Activity调用；放到Linux服务器上，可能只是启动一个进程并检查输出。模型不需要知道自己在哪个系统上，它只需要告诉Harness“我想干什么”，剩下的事是Runtime层解决的。

这个设计的好处非常明显：你写的Skill和策略可以跨平台复用，不用为每个平台单独设计一套Agent逻辑。但也有代价，就是不同平台的能力边界不一样。比如Windows上能做的GUI自动化，在纯Linux服务器上就做不到，因为根本没有桌面环境。你在写Skill的时候要知道目标平台的能力边界，否则就会出现“在Windows上跑得好好的，部署到服务器上直接报错”的情况。

2.3 上下文、Token与模型的对话接口

讨论runtime，绕不开Token这个问题。很多刚上手的朋友会疑惑：“AI Agent的token到底是什么意思？”简单说，Token是大模型处理文本的最小单位，一个汉字大概相当于1到2个Token，一段英文可能一个词就是一个Token。你在配置里看到的context window、max tokens、temperature这些参数，全都在围绕Token做文章。

在OpenClaw里，你不需要自己精细计算每次请求用了多少Token，因为Harness会帮你统计和管理。但你仍然需要理解几个影响Token消耗的因素：

第一个是系统提示词。OpenClaw默认会注入一份不小的系统指令，里面包含了Agent的行为规范、可用工具清单、Skill说明。这部分每轮对话都会占Token，而且属于“不可压缩”的部分。

第二个是工具返回的结果。Agent执行完一个命令，命令的输出会作为上下文的一部分返回给模型。如果你让Agent去cat一个几万行的日志文件，这些内容全都会被塞进上下文，Token瞬间就爆了。所以好的Skill设计，一定是精准控制输出量的。我自己写Skill的时候，凡涉及文件读取，都会在指令里明确“只读取前N行”或者“只返回匹配关键字的行”。

第三个是历史累积。多轮交互下来，历史消息会越攒越多，Harness虽然会做摘要压缩，但摘要本身也占空间。遇到长会话，最好的办法是主动开新会话或执行清理指令，别指望一个会话能无限用下去。

在模型接入上，OpenClaw走的是兼容OpenAI接口的路线，所以你可以接各种兼容API的服务。社区里讨论度比较高的组合是DeepSeek加OpenClaw，这条路线的优势是便宜、速度快、中文理解好。也有人把Ollama本地模型接进来，好处是数据不出本机，缺点是推理速度受限于显卡，跑小模型还行，跑大模型就很吃力，而且本地模型在指令遵循能力上普遍比云端商用模型弱一截。以我做Agent开发的经验，指令遵循能力比“聪明”重要得多，因为Agent需要严格按照结构化指令去调工具、走流程，模型再聪明，不听话就全白搭。

3. 三种典型环境下的完整部署实操

3.1 Windows端搭建：Companion配置与CLI安装

先把Windows端的部署流程完整走一遍。我的主力机是一台Windows 10的ThinkPad，配置不算高，跑起来没什么压力。OpenClaw在Windows上的安装主要是两条路：直接装CLI，或者CLI加Companion组合使用。

CLI是最小化的运行方式，适合做命令行交互和脚本调用。安装之前确保机器上有Rust工具链，因为部分组件需要从源码编译。这里我直接用脚本安装，它会自动拉取预编译的二进制：

curl -fsSL https://openclaw.example.com/install.sh | bash

安装完成后，验证一下版本，确定装的是当前主线：

openclaw --version

然后初始化配置目录。初始化过程会生成一个默认配置文件，里面包含模型接入参数、运行模式、安全策略等核心设置：

openclaw init

这里插一句，如果你是直接拉源码编译，依赖的包比较多，编译时间会比较长，中间还可能因为网络原因拉取失败。遇到这种情况别慌，多试几次或者手动把依赖包下到本地再编，基本都是能解决的。我用预编译脚本装，全程大概五分钟搞定。

然后说Companion。Companion是OpenClaw在桌面端的“外挂神经系统”，它负责接管那些CLI做不到的桌面级操作——比如控制窗口焦点、模拟键鼠、读取剪贴板、跟其他桌面应用联动。你在Windows上装Companion，本质上是给Agent开了一扇操作你桌面的门，所以它的配置里安全选项比CLI严格得多。

Companion的配置文件里有一个比较关键的连接参数，叫companion_port，默认是某个固定端口。安装完成之后，Companion会启动一个本地服务，CLI通过这个端口跟它通信。我第一次配的时候没注意IP绑定选项，结果它绑定到了所有网络接口上，虽然实际没出事，但心里不踏实。后来我改成仅绑定本机回环地址，这样外部设备就完全访问不到这个端口了。我强烈建议你也这么做，尤其当你的电脑在局域网里的时候，别把Agent的控制端口暴露给整个网络。

3.2 安卓端部署：Termux里跑OpenClaw的完整步骤

手机上跑Agent是我觉得这个项目最酷的场景。一台几百块的旧手机，装个Termux，就能变成7乘24小时在线的个人Agent节点，功耗还低得可以忽略。这个折腾过程的每一步我都有记录，分享出来给你参考。

第一步，在手机上装Termux。推荐去F-Droid或者GitHub的Release页面拿最新版，不要用某些应用商店里的老版本，老版本很容易在后续安装依赖时报错。

装好Termux后，先换国内可用的软件源，不然装依赖的时候网络会非常慢。这里有个小坑：Termux的源配置文件路径在不同版本里有点变化，如果你按老教程找pkg源文件找不到，就看看是否存在$PREFIX/etc/apt/sources.list.d目录，新版一般把源拆成独立文件放在这里。

接着更新软件包、装基础依赖：

pkg update && pkg upgrade -y pkg install rust git clang make pkg-config openssl

在手机上编译Rust项目的感受是：能跑，但慢。我当时编完核心组件花了将近二十分钟，手机还微微发烫。如果你不想在手机本地上编，可以考虑在电脑上交叉编译好二进制再拷过来，但交叉编译的配置门槛更高，手机直接编其实是更省心的路径。

编完之后，初始化配置、设置模型接入信息，这一步跟在电脑上是一样的。注意安卓端因为没有桌面环境，Companion是用不了的，你只能走纯CLI模式。但纯CLI也够用了——我实测下来，文件管理、下载任务、定时脚本、联网请求这些最常见的自动化场景，在Termux里都能跑得很好。

这里我要特别提一个权限问题：Termux默认运行在一个隔离环境里，它访问手机存储的能力是受限的。如果你想让它操作手机主存储的文件，得用termux-setup-storage命令授权，它会创建一个名为storage的软链接目录，指向手机的真实存储路径。不加这个授权，Agent在Termux里只能碰自己的数据目录，很多事情都干不了。这个步骤网上很多教程都一笔带过，但实际使用中卡住的大多就是这里。

3.3 内网服务器部署：用Docker还是裸二进制

把OpenClaw部署到内网服务器，是很多团队落地Agent项目的常规需求。我自己在部署测试服务器时，两种方式都试过，说下选择逻辑。

如果你的服务器上已经有一套Docker基础设施，那直接用镜像是最省事的。Docker的优点不用多说，环境隔离、依赖干净、迁移方便。但有一个点你要想清楚：OpenClaw是那种需要跟宿主机深度交互的Agent框架，你在容器里跑它，它默认看不到宿主机的文件系统和进程。你要真想让它管理宿主机上的服务，就得挂载目录、开放进程通信，等于把一部分隔离性亲手放弃掉。愿意接收这个折中，那Docker很舒服；不愿意，就考虑裸二进制。

裸二进制部署其实也没有多复杂。我当时的步骤是这样的：先在服务器上装好Rust工具链，然后克隆源码编译，或者直接拉一份预编译二进制放进去。编译完成后设置配置文件里的模式为server，指定监听端口和绑定地址，再用systemd注册成守护进程，保证开机自启、崩溃自动拉起：

[Unit] Description=OpenClaw Agent Service After=network.target [Service] ExecStart=/opt/openclaw/bin/openclaw serve --config /etc/openclaw/config.toml Restart=always User=openclaw Group=openclaw [Install] WantedBy=multi-user.target

这里有一个非常重要的经验：务必创建一个低权限的专用系统账户来跑Agent，不要直接用root。Agent是有能力执行任意命令的，它工作得再好，本质上也是一个“能被远程指令驱动的Shell”。用低权限账户运行，就算出问题，损失面也小得多。我见过有人直接root跑Agent，还开放了远程调试端口，看得我冷汗直冒。

关于绑定地址，内网部署时默认建议只监听内网网卡的IP，不要图省事绑0.0.0.0。这个建议的原因很简单，0.0.0.0意味着同一网络内任何设备都能访问你的Agent端口，一旦有人发一个恶意指令，Agent可能就被当成远程控制木马使了。除非你有成熟的认证和加密方案，否则别这么干。

3.4 配置模型接入：DeepSeek、Ollama与OpenAI兼容接口

部署完Runtime，下一步就是把大模型接进来。OpenClaw的配置文件中模型接入部分，核心就几项：API地址、API Key、模型名、上下文长度、温度参数。我分别说下接云端API和接本地模型的配置要点。

接云端API，这里以DeepSeek为例，因为它在中文场景下的表现确实不错，价格也亲民。配置文件里的格式大约长这样：

[model] provider = "openai_compatible" base_url = "https://api.deepseek.com/v1" api_key = "sk-xxxxxx" model = "deepseek-chat" context_window = 65536 max_tokens = 8192 temperature = 0.3

这个配置的本质是告诉Harness：你对着这个OpenAI兼容地址发请求，用这个模型名，别超过这个上下文窗口，每次回复最多生成这么多Token，回复风格按这个温度来。

这里有几个参数我要单独讲一下。temperature控制的是输出的随机性，0.3是我做Agent任务比较偏好的值，稳定、少发散；你要是想让Agent更灵活一点可以调到0.7，但代价是它偶尔会做出意料之外的决策。context_window这个值一定要跟模型实际支持的窗口对齐，设太大，Harness会在请求时超出模型上限直接被拒；设太小，长对话进行到一半上下文就被强制截断，Agent会“失忆”。

接Ollama本地模型时，base_url要指向本机的Ollama服务地址，例如http://127.0.0.1:11434/v1，这是Ollama自带的OpenAI兼容端点。模型名用你Ollama里拉取的标签名，比如llama3.1:8b、qwen2.5:7b这类。

本地模型的感受我多说两句：可以玩，而且隐私性极好，但要管理好预期。我的测试机上有一块老显卡，跑7B左右的模型能接受，再大就卡得难受了。指令遵循方面，本地小模型跟DeepSeek这种商用模型相比差距明显，复杂Skill经常执行到一半跑偏。如果只是做简单的工具调度和文件管理，本地模型够用；要做复杂的多步骤自动化，我建议还是接云端API，省心得多。

4. 安全模型与权限控制，这一层绝对不能省

4.1 危险指令的类型、防护与用户批准机制

聊Agent开发，绕不开一个灵魂问题：你敢不敢让一个AI在你电脑上随便执行命令？说实话，刚上手的时候我也不敢。但我用OpenClaw最满意的一点，就是它在架构层面认真回答了这个问题，而不是用“我信任大模型”这种不负责任的态度糊弄过去。

OpenClaw对命令有一套分类和管控机制。它不搞“一刀切禁止”，因为一刀切意味着Agent什么都干不了；它也不搞“全开放”，因为全开放就是在给自己埋雷。它的做法是分级管控：

• 文件读取类：比如查看文件内容、列出目录，这类操作风险低，可以放行。
• 状态查询类：系统信息、进程列表、网络状态，风险低但涉及一定隐私，视策略决定。
• 文件修改类：写入、移动、重命名，风险中等，默认需要用户确认。
• 删除和覆盖类：这个不用说你也能理解，默认必须用户手动批准。
• 配置修改和系统级变更：这类操作几乎每次都要过用户确认。

用户批准机制在CLI里是交互式弹窗，界面会清楚地显示“Agent想执行这个命令，你批准吗”，你按Y它就继续，按N它就中止。这个机制看着简单，实际使用中非常关键。我见过一些Agent项目，压根不给你说“不”的机会，Agent要干啥就干啥，那种项目我只能说，勇气可嘉，但我不敢用。

这里我补充一个实操心得：批准弹窗出现时，不要想都不想就按Y。我一开始为了效率几乎全按Y，结果有一次Agent自己提了一个递归删除临时文件的命令，命令本身看着没什么问题，但结合它当时的执行上下文，我意识到它其实是想清理掉另一个目录下的缓存文件，跟它原本的任务目标已经偏了。从那以后我养成习惯，每次批准前花两秒钟看一眼命令是什么，想想跟当前任务有没有关联。这也就是两三秒的事，但可以避免绝大多数“失手”。

4.2 策略配置：让Agent“只能做允许的事”

如果说用户批准机制是运行时的人工刹车，那策略配置就是事前写好的交通规则。OpenClaw的配置文件里可以定义一系列策略规则，告诉Harness哪些能做、哪些坚决不能做，这些规则不依赖用户的现场判断，是系统层面的强约束。

我跟别人讲这个概念的时候喜欢用一个例子：你可以直接把“禁止对/home目录之外的文件做写操作”写进策略里。这样就算模型在某个上下文里被带偏了，真的产生了删除其他目录文件的意图，Harness在执行前检查策略时就会直接拦下来，模型根本碰不到真实系统。这就是“纵深防御”的思路——模型不可信，所以防线在模型之外。

配置策略时，有几个原则值得参考：

第一，遵守最小权限原则。给Agent的权限，只覆盖它要做的任务的必要范围。让Agent去下载文件，就把它的写权限限在下载目录下；让Agent管理日志，就限在日志目录下。别把整个磁盘的写权限交出去。

第二，网络访问也要管。如果需要Agent访问外网，可以在策略里限制只允许特定域名或特定端口。别让它拥有完全自由的网络访问权，否则它可能被诱导去访问内网的其他服务，那就坏了。

第三，敏感区域单独设防。如果机器上有机密资料、生产环境配置、数据库凭据这类重要文件，直接在策略里把相关路径拉进黑名单，不让Agent读取。这东西你主动设一下，比事后担惊受怕强得多。

我看社区里关于“Agent安全”的讨论越来越多，这不是坏事。AI Agent的能力边界在扩大，如果安全机制跟不上，早晚会出大事。我的态度是：能力越强的工具，越需要规章制度。给Agent设策略跟给家里宠物划禁区是一个道理——它可能确实很聪明，但你不能指望它每次都能忍住不去碰危险区域。

5. 常见问题与排查技巧实录

5.1 安装、连接与模型报错的集中整理

这几天折腾下来，我攒了一批很有代表性的报错场景，整理成表格给你。都是实操中比较高频的问题，每条后面附了排查思路和解决方案。

5.2 容易被忽略的细节和经验之谈

表格之外，再说几个我从实操里总结出来的细节。这些东西文档里不会专门写，但遇到了能省你半天时间。

第一个是对着“报错日志”查问题。OpenClaw的日志系统比很多同类项目做得清楚，很多问题的真实原因在日志里写得明明白白。我遇到过一个人抱怨“退出码非零”，但打开日志一看，是配置文件里某个字段写错了。凡是遇到“看不懂的错误”，第一步永远是翻日志，而不是在社区里重新提问。

第二个是版本对齐的问题。OpenClaw、Companion、Skill之间是有版本依赖关系的，老版本的CLI去连新版本的Companion，很可能握手失败。升级任何一端之后，如果出现原来正常的功能突然异常，先检查一下各组件版本是否兼容。这个问题我在Windows上遇到过，Companion更新后CLI连不上，回退版本就恢复了。

第三个是配置修改后不要忘了重启服务。OpenClaw的很多配置是启动时一次性加载的，你改了配置文件不重启，改动不生效，然后你对着屏幕怀疑人生。我就是这么上当过的，浪费了将近十分钟。改完配置，停掉进程重新拉起来，这个动作要成为肌肉记忆。

第四个是关于日志里的“正常噪音”。Agent在运行过程中会输出大量看似“报错”但其实是正常流程的信息，比如某些请求被拒绝重试、某些非关键命令失败后走备用方案。新手容易看到日志里有一点红就紧张，其实要用入口去判断——任务最终的结果是不是符合预期？如果符合，那些中间噪音不用管；如果不符合，就从最后失败的地方往前倒推。抓主要矛盾，别被日志海洋淹没。

6. 写在最后：几个实操后的个人体会

折腾OpenClaw这段时间，我对Agent工程最大的感受是：模型能力固然重要，但真正决定一个Agent项目能不能用的，是工程细节的完成度。上下文怎么管理、工具怎么调度、权限怎么控制、错误怎么恢复，这些看起来不性感的工作，恰恰是Agent从“玩具”走向“工具”的分水岭。OpenClaw让我比较惊喜的地方，就是它在这些细节上的完成度确实高，不是那种演示完就散架的Demo。

如果你刚接触这个项目，我建议的路线是：先在Windows或Linux上装一个CLI跑通基础对话，然后尝试让它做一两件最简单的真实任务，比如整理目录、批量改文件名；跑通之后再上安卓或服务器部署，最后再深入研究和实践Skill开发。每一步都把前一步的基础打牢，后面就不会踩太多坑。

最后分享一个小技巧：尽可能保持配置文件的注释习惯。OpenClaw的配置项很多，每个参数的含义和边界条件，第一次配的时候可能觉得理所当然，过两个星期再看，可能已经忘了当时为什么这么设。我自己的做法是，凡是改了默认值的参数，都在配置文件旁边写一行注释，记下调整原因。这个习惯帮我省了无数回头查阅文档的时间，也让我在回滚配置时能快速判断哪些是“有意改动”，哪些是“随手的测试值”。

下篇我会重点讲怎么编写自己的Skill，以及怎么把OpenClaw嵌入到更大的自动化流程里。如果你正在搭建自己的Agent，建议先把这篇里的部署和处理机制动手跑一遍，有了实际操作的经验打底，后面看进阶内容会轻松很多。