企业官网建设流程全解析

简介：这份PDF是厦门大学大数据教学团队2026年3月推出的科普讲座课件，共94页，面向希望系统了解大模型与AI智能体的高校师生、科研人员及技术爱好者。内容从图灵测试与达特茅斯会议讲起，梳理人工智能六阶段发展史与未来五个阶段，并重点剖析OpenClaw（小龙虾）这一开源AI智能体执行网关：涵盖其更名历程、跨IM交互、持久记忆、本地执行与多智能体协同等核心能力，以及云端部署、应用实践和辅助科研的具体路径。课件还给出AI能力四层金字塔、大模型能力边界对照表与未来3—5年趋势判断，帮助读者建立“了解、区分、协作”的人工智能思维。资源包为1个PDF文件，约21.83MB，已有207人学习，适合作为讲座配套资料或自学参考。

1. 从一份 94 页 PDF 说起：OpenClaw 智能体到底解决什么问题

2026 年厦大团队那份 94 页的 OpenClaw 应用实践文档，我是在一个做自动化运维的朋友群里看到的。群里讨论最热的不是文档本身，而是「openclaw 部署」「openclaw 安装教程」「openclaw 无法安全验证」这几个词——说明大量人卡在了第一步。OpenClaw 这个被戏称为「小龙虾」的智能体框架，核心定位是让大模型不只是聊天，而是能真正操作本地环境：读写文件、执行命令、调用浏览器、串联多步任务。它和 Coze、Dify 那类平台化智能体最大的区别在于，OpenClaw 跑在你自己的机器上，算力可以接 API，也可以挂本地 Ollama，数据不出本机。这份文档适合两类人：一是想把智能体从「演示」推进到「每天真用」的开发者，二是被平台智能体限制住、需要本地执行能力的人。接下来我按部署、配置、Skill 开发、避坑的顺序，把这条链路讲透。

2. OpenClaw 部署：从 Windows 到 Ubuntu 的最小可跑路径

2.1 先搞清楚 OpenClaw 的运行依赖链

OpenClaw 本身是一个 Node.js 应用，它的执行能力依赖三层：最底层是操作系统（Windows 走 WSL2，Linux 原生），中间层是 Node.js 运行时和系统工具（shell、文件系统、浏览器），最上层才是模型接入。很多人一上来就装 OpenClaw，结果报「无法安全验证」或者 sl2 环境错误，本质是跳过了底层检查。

Windows 上最常见的报错是提示你在 PowerShell 里运行wsl --status，这说明 OpenClaw 检测到 WSL 未安装或版本不对。WSL2 是必须的，因为 OpenClaw 的很多 Skill 依赖 Linux 命令语义，Windows 原生 cmd 和 PowerShell 的管道行为跟 bash 不一致，直接跑会出各种玄学问题。

Ubuntu 上相对省心，但要注意 Node.js 版本。OpenClaw 对 Node 版本有下限要求，低于这个版本会在启动时直接崩，而且报错信息不一定指向 Node。我一般建议用 nvm 管理版本，而不是系统包管理器装的 Node。

提示：部署前先确认三件事——WSL2 是否可用、Node 版本是否达标、磁盘剩余空间是否够模型缓存。这三项任何一项不满足，后面都会以奇怪的方式失败。

2.2 Windows 下的完整部署命令

先处理 WSL。以管理员身份打开 PowerShell：

# 查看 WSL 状态，确认是否已安装及版本 wsl --status # 如果未安装或版本为 1，执行安装并设为默认 wsl --install wsl --set-default-version 2 # 安装完成后重启，再进入 Ubuntu 子系统 wsl

进入 WSL 的 Ubuntu 环境后，装 Node.js。这里用 nvm 而不是 apt：

# 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 重新加载 shell 配置 source ~/.bashrc # 安装 Node.js LTS 版本（OpenClaw 需要较新的 LTS） nvm install --lts nvm use --lts # 验证版本 node -v npm -v

接着安装 OpenClaw 本体。常见做法是全局安装：

# 全局安装 OpenClaw CLI npm install -g openclaw # 验证安装 openclaw --version # 初始化配置目录 openclaw init

openclaw init会在用户目录下生成配置文件夹，里面包含模型配置、Skill 目录和日志路径。这一步如果卡住，多半是网络问题或 npm 源问题，可以换源重试。

参数说明：nvm install --lts装的是当前 LTS 线，不是最新版；OpenClaw 对 Node 主版本有要求，装完用node -v确认。openclaw init生成的目录结构不要手动改，后续 Skill 安装会依赖这个结构。

2.3 Ubuntu 原生部署与 Ollama 本地模型接入

Ubuntu 上跳过 WSL 步骤，直接装 Node 和 OpenClaw。如果你不想用 API 算力，可以挂本地 Ollama：

# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取一个适合智能体的小模型 ollama pull qwen2.5:3b # 确认 Ollama 服务在跑 ollama list

然后在 OpenClaw 配置里指向本地 Ollama 端点。配置文件通常是~/.openclaw/config.json或类似路径，具体以openclaw init生成的为准：

{ "model": { "provider": "ollama", "baseUrl": "http://localhost:11434", "model": "qwen2.5:3b" } }

逻辑说明：OpenClaw 把模型调用抽象成 provider，ollama 只是其中一种。baseUrl 指向本地 11434 端口，model 字段要和ollama list里的名字完全一致，大小写和冒号都不能错。3B 级别的模型跑简单任务够用，但多步推理和工具调用容易翻车，生产环境建议至少 7B 以上或直接接 API。

注意：本地模型和 API 模型在 OpenClaw 里的行为不完全一致。本地模型对 function calling 的支持参差不齐，如果 Skill 调用总是失败，先换成 API 模型验证是不是模型能力问题。

3. OpenClaw 配置与 Skill 开发：让智能体真正干活

3.1 模型接入的三种方式和选型建议

OpenClaw 支持三类算力接入：云端 API、本地 Ollama、以及兼容 OpenAI 接口的自建服务。选型上我的经验是：日常高频任务用 API，因为延迟低、工具调用稳定；隐私敏感或离线场景用 Ollama；自建服务适合团队内部统一管理密钥和配额。

配置 API 模型时，关键参数是 baseUrl、apiKey 和 model。baseUrl 要写完整的兼容端点，不要只写域名。apiKey 建议放环境变量而不是明文写配置文件：

# 在 shell 配置里导出密钥 export OPENCLAW_API_KEY="your-key-here" # 配置文件中引用环境变量

{ "model": { "provider": "openai-compatible", "baseUrl": "https://your-endpoint/v1", "apiKeyEnv": "OPENCLAW_API_KEY", "model": "your-model-name" } }

参数说明：apiKeyEnv是告诉 OpenClaw 从哪个环境变量读密钥，这样配置文件可以进版本控制而不泄露。baseUrl末尾的/v1不能省，很多兼容服务靠这个路径区分。

3.2 写一个能跑的最小 Skill

Skill 是 OpenClaw 的执行单元，本质是一个带元数据的函数。最小 Skill 包含三部分：声明（名称、描述、参数 schema）、执行逻辑、返回值。下面是一个读文件并统计行数的 Skill：

// skills/count-lines/index.js module.exports = { name: 'count-lines', description: '统计指定文件的行数', parameters: { type: 'object', properties: { filePath: { type: 'string', description: '要统计的文件绝对路径' } }, required: ['filePath'] }, async execute({ filePath }) { const fs = require('fs').promises; try { const content = await fs.readFile(filePath, 'utf-8'); const lines = content.split('\n').length; return { success: true, lines }; } catch (err) { return { success: false, error: err.message }; } } };

逻辑说明：parameters用的是 JSON Schema，OpenClaw 会把它转成模型能理解的工具描述。execute接收解构后的参数，返回一个对象。关键点是错误不要抛出去，而是包在返回值里，否则整个智能体流程会中断。参数说明：filePath要求绝对路径，是因为智能体的工作目录不确定，相对路径容易踩坑。

写完 Skill 后需要在配置里注册，或者放到约定的 skills 目录让 OpenClaw 自动扫描。注册后可以用openclaw skill list确认是否被识别。

3.3 多步任务的编排与上下文控制

OpenClaw 的强项是把多个 Skill 串成工作流。比如「找到日志目录里最大的文件，统计它的错误行数，把结果写到报告文件」——这涉及列目录、排序、读文件、过滤、写文件五个动作。编排时最容易翻车的是上下文膨胀：每一步的原始输出都塞回模型，几轮之后 token 就爆了。

我的做法是在 Skill 里做聚合，只返回模型决策需要的最小信息。比如列目录的 Skill 不要返回完整文件列表，而是返回「最大文件名 + 大小」。这样模型拿到的是结论而不是原始数据，后续步骤的 prompt 长度可控。

另一个技巧是给每个 Skill 的 description 写清楚「什么时候用」和「不要什么时候用」。模型选错工具，十有八九是 description 太模糊。比如「读文件」要写明「用于读取文本文件内容，不用于列目录」。

4. OpenClaw 避坑与排查：那些文档不会写的翻车现场

4.1 报「无法安全验证」或 sl2 环境错误

现象：启动 OpenClaw 时提示无法安全验证，或让你在 PowerShell 运行wsl --status。

原因：WSL 未安装、版本为 1、或 WSL 子系统内的 Node 环境不完整。OpenClaw 的部分安全检查依赖 Linux 环境，Windows 原生跑会直接失败。

解决：按 2.2 的步骤确认wsl --status输出正常，wsl --set-default-version 2设为默认，然后在 WSL 内重新装 Node 和 OpenClaw。不要在 Windows 侧和 WSL 侧混装，两边环境是隔离的。

4.2 Skill 被识别但模型从不调用

现象：openclaw skill list能看到 Skill，但对话时模型总是用别的方式回答，不触发 Skill。

原因：Skill 的 description 太笼统，或者 parameters 的 description 缺失，模型无法判断何时该用。

解决：把 description 写成「动作 + 对象 + 场景」，parameters 里每个字段都加 description。改完重启 OpenClaw 让配置生效。如果还不触发，临时把模型换成工具调用能力更强的 API 模型对比。

4.3 本地 Ollama 模型工具调用失败

现象：接 Ollama 后，简单问答正常，但一到 Skill 调用就报解析错误或直接忽略。

原因：小参数模型对 function calling 的支持不完整，返回的 JSON 格式不符合 OpenClaw 预期。

解决：先换 API 模型确认是模型问题而非配置问题。如果必须用本地模型，选工具调用支持较好的型号，并在 OpenClaw 里开启更宽松的解析模式（如果有）。3B 级别模型做多步任务基本不可靠，这是血泪经验。

4.4 多步任务中途卡死或循环

现象：智能体执行到某一步后反复调用同一个 Skill，或者停在那里不动。

原因：Skill 返回的错误信息不明确，模型不知道失败原因，只能重试；或者 Skill 返回值太大，模型解析超时。

解决：Skill 的错误返回要具体，比如「文件不存在：/path/to/file」而不是「读取失败」。返回值做裁剪，只给模型必要字段。另外给任务设最大步数上限，防止无限循环。

4.5 配置文件改了不生效

现象：修改 config.json 后行为没变化。

原因：OpenClaw 可能缓存了配置，或者你改的不是实际加载的那份（比如 WSL 内外各有一份）。

解决：改完配置后完全退出再启动，不要只重启对话。用openclaw config path确认当前加载的配置文件路径，确保改对了文件。

5. 进阶：用行为审计和 Skill 组合把 OpenClaw 用成生产力

5.1 给智能体加一层行为审计

智能体行为审计这个词最近被提得很多，落到 OpenClaw 上，就是记录每一次 Skill 调用的输入、输出、耗时和结果状态。这不是为了合规，而是为了排错。我一般会在 Skill 的 execute 外层包一个日志装饰器：

// utils/audit.js function withAudit(skill) { const originalExecute = skill.execute; skill.execute = async function (params) { const start = Date.now(); const result = await originalExecute.call(this, params); const entry = { skill: skill.name, params, result, duration: Date.now() - start, timestamp: new Date().toISOString() }; // 追加写入审计日志 require('fs').appendFileSync( process.env.HOME + '/.openclaw/audit.log', JSON.stringify(entry) + '\n' ); return result; }; return skill; }

逻辑说明：装饰器模式不改动 Skill 本身逻辑，只在调用前后加记录。参数说明：日志写到~/.openclaw/audit.log，每行一条 JSON，方便后续用 jq 或脚本分析。有了这份日志，智能体哪一步慢、哪一步错、模型传了什么参数，一目了然，比猜快得多。

5.2 Skill 组合的两种模式

单个 Skill 能力有限，真正好用是把它们组合起来。两种模式我常用：串行链和条件分支。串行链适合固定流程，比如「拉取数据 → 清洗 → 写库」；条件分支适合需要判断的场景，比如「如果文件存在就读，否则先创建」。

组合的关键是让每个 Skill 的返回值结构化，模型才能根据返回值决定下一步。如果 Skill 返回一段自然语言，模型就得猜，稳定性直线下降。我习惯让所有 Skill 返回{ success, data, error }三字段结构，模型看到 success 为 false 就知道要处理错误。

5.3 验证智能体是否真的可靠

上线前我会做一轮回归测试：准备 10 到 20 个典型任务，每个任务跑三遍，看成功率。重点看两类失败：一是模型选错 Skill，二是 Skill 执行报错。前者改 description，后者改 Skill 实现。跑三遍是因为模型有随机性，一遍通过不代表稳定。

还有一个土办法：把审计日志按任务 ID 聚合，看平均步数和平均耗时。如果某个任务步数明显偏多，说明 Skill 拆分粒度有问题，或者模型在某个环节反复试错。

5.4 我踩过的最大的坑

最后说一个我自己的教训。早期我把所有 Skill 都写成「万能工具」，一个 Skill 能干好几件事，参数一大堆。结果模型根本不知道该传什么，调用成功率极低。后来改成每个 Skill 只做一件事，参数不超过三个，成功率立刻上来了。智能体的能力边界不是靠 Skill 多，而是靠 Skill 清晰。这个习惯我一直保持到现在：写 Skill 之前先问自己，这个 Skill 能不能用一句话说清楚它干什么，说不清楚就拆。

希望帮到你。

本文还有配套的精品资源，点击获取