我让 OpenClaw 🦞 帮我部署模型

2026-03-13

LLM

在我让 OpenClaw 🦞 为我当 OP 这篇文章中，我介绍了我是如何让 OpenClaw 帮我管理服务器集群的。

过了几天，我就开始想搞一点更复杂的事情。既然 OpenClaw 都可以帮我管理服务器集群了，那为什么不能让它帮我部署模型呢？反正我每次部署模型不也是先登录 GPU 服务器，然后在上面执行各种 CLI 操作（下载模型、配置虚拟环境、下载依赖……）？并且每次遇到部署问题时，我也是截个图直接丢给大模型……

2026-03-13

Model Deploy

在 GPU 服务器上使用 vLLM 部署大语言模型。目前仅支持在 vLLM 推理引擎上部署大模型。

快速开始

在 ModelScope 平台，模型一般采用 <MODEL_ORG>/<MODEL_NAME> 来唯一识别，例如 Qwen/Qwen3.5-0.8B 而言，MODEL_ORG 为 Qwen，MODEL_NAME 为 Qwen3.5-0.8B。

Qwen 系列模型部署

对于 Qwen 系的模型部署，请使用 scripts/deploy.sh 部署脚本，该脚本的使用方式如下：

用法: [环境变量] deploy.sh <model_name>

示例:
  PORT=8001 \
  GPU_COUNT=4 \
  ./deploy.sh Qwen3.5-0.8B

环境变量:
  ENV_NAME        conda 环境名称 (默认: vllm)
  PORT            服务端口 (默认: 8000)
  GPU_COUNT       GPU 并行数 (默认: 1)
  PROXY           代理地址 (默认: http://{proxyaddress}:{port})
  MODEL_BASE_PATH 模型存储路径 (默认: /home/work/models)

变量	说明	默认值
MODEL_ORG	模型组织	Qwen
MODEL_NAME	模型名称	Qwen3.5-0.8B
ENV_NAME	conda 环境	vllm
PORT	模型服务端口	8000
GPU_COUNT	GPU 并行数	1
PROXY	代理地址	http://{proxyaddress}:{port}
MODEL_BASE_PATH	模型本地存储路径	/home/work/models

部署步骤

从用户请求中提取需要部署的：模型名称（MODEL_NAME），模型组织（MODEL_ORG），需要部署的服务器地址（TARGET_HOST），部署账号（TARGET_USER）等所需要的信息。
把 ./skills/model-deploy/scripts/deploy.sh 复制到目标服务器的指定路径下，例如 $HOME/wangwei17。
在目标服务器上给部署脚本增加可执行权限。
在目标服务器上执行部署脚本。必须采用如下的方式来部署：

1	ssh ${TARGET_USER}@${TARGET_HOST} "cd $HOME/17 && PORT=8001 && ./deploy.sh Qwen3.5-0.8B"

部署完成后，在目标服务器上执行 curl http://127.0.0.1:8001/v1/chat/completions 测试模型服务是否启动成功。

curl -X POST http://127.0.0.1:8001/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
      "messages": [{"role": "user", "content": "你好"}],
      "max_tokens": 512
  }'

约束说明

在目标服务器上执行命令必须采用如下的方式：ssh ${TARGET_USER}@${TARGET_HOST} "${CMD}"。

常见问题

端口占用: 检查 netstat -tlnp | grep <port>
版本问题: 运行 pip install vllm --upgrade
网络问题: 配置代理 export https_proxy="http://{proxyaddress}:{port}"
GPU memory 不足: 运行 nvidia-smi 查看显存使用情况，找到满足显存需求的的 GPU 卡编号 GPU_FAN，然后运行 export CUDA_VISIBLE_DEVICES=$GPU_FAN 来指定部署使用的 GPU 卡，然后重新执行部署脚本。

我让 OpenClaw 🦞 为我当 OP

2026-03-08

LLM

正如我在为 OpneClaw 增加 Browser 工具中提到的那样：

在整个的部署过程中，遇到了太多的坑，每遇到一个坑，我就让 Gemini 帮我解决。

突然，我意识到：目前 LLMs 对于 Linux 系统的理解应该比人类要强得多，对 Linux 系统的各种命令操作也应该比人类要强得多。

既然如此，为什么不让 OpenClaw 帮我解决 Linux 系统的运维呢？恰好，我有一个 3 台机器的小集群，每天都要登录上去做一些手工操作，我不想再这样继续下去了。我想做出一些改变，于是，我决定让 OpenClaw 来当 OP，帮我管理集群。我要做的就是：通过 IM 下发指令。

为 OpneClaw 增加 Browser 工具

作者：王伟 , Gemini

2026-03-04

LLM

在 OpenClaw 初体验中，我在阿里云的 ECS 主机上部署了 OpenClaw，并用它做了些初步的尝试。有时候，可能想浏览某些网页，但是这些网页在手机上的浏览体验又不好，所以此时就可以通过 IM 软件让 OpenClaw 调用 Chrome 浏览器来帮我们打开页面并截图。

我想每天上班的时候扫一眼 Github Trending 的内容（我在手机上没法直接访问这个页面，当然也有方法，但是我嫌麻烦），这个时候就可以通过 OpenClaw 调用 Chrome 浏览器来打开这个页面并截图发给我了。

2026 年初，除了基础大模型争相斗艳之外，在技术圈，一个名叫 OpenClaw 的个人 AI 助手火出了天际，引爆了新一轮的 Agent 热潮。OpenClaw 的核心理念是让 AI 直接接管系统的读写与执行权限，并通过 Telegram、Discord 或 WhatsApp 等 IM 软件接收自然语言指令，然后再服务器上自动执行代码编写、文件管理、收发邮件等任务。通过 IM 软件下达任务，OpenClaw 会自己分析任务，然后自动执行任务，并返回执行结果。这才是我们一直在苦苦追求的 AI 个人助理。

如何提升大模型评测数据集的质量？

2026-02-06

LLM

在大模型评测 7 条原则中，我们把大模型评测过程中遇到的影响结果置信度的问题进行了总结。在 2025 年，这些实践总结也确实帮助我们提升了评测的质量。但是，在 2025 年末的时候，随着模型 SOTA 的不断突破（例如： Nano Banana Pro、Seedream-4.5、……），我们慢慢发现：我们的评测区分度存在不断下降的趋势，这导致我们很难通过评测来区分不同模型之间的性能差异。

然而，实际的情况并非我们的结果所呈现的那样，尤其在图片生成、视频生成等场景，不同的模型之间还是存在区分度的。在 Arena 平台的图生图对抗榜单显示：模型之间确实存在比较明显的差异。

深入研究 Anthropic 的 Agent 评估实践

2026-01-25

LLM

2026 年 1 月 9 日，Anthropic 发布了一篇题为 Demystifying evals for AI agents ^[1]的博文，详细介绍了他们在评估 Agent 方面的思考、实践和方法。恰巧，我们在 LLM 评估领域也做了一些工作，并且也遇到了很多亟待解决的问题，因此对这篇博文产生了浓厚的兴趣。于是，花了几天时间，认真研习了这篇博文，并对其中的内容进行了整理和总结。

对 Agent Skills 的认知与思考

2025-12-24

LLM

自从 12 月 9 日，Anthropic 的 Barry Zhang 和 Mahesh Murag 在内部做了一个名为 Stop Building Agents, Build Skills Instead^[1] 的分享之后，Skills 突然就火了起来。微信公众号、小红书等平台上涌现出了大量的介绍 Skills 的文章。一开始对这个概念也是迷迷糊糊的，于是就花了点时间阅读了 Claude 官方对 Skills 的所有博客与文档，自己也写了一个简单的 Skills 体验了一把这个火得不能再火的技术。

Skills 的本质

Agent Skills 通过工程层面的优化，改变了 如何管理、如何交付、如何使用 大模型能力的方式，让 Agent 的构建更加简便、可控。
从技术层面看，Agent Skills 并没有改变 LLM 的底层原理，Transformer 架构没变、权重没变、预测下一个 token 的逻辑也没变……

Context Engineering for AI Agents

2025-11-29

LLM

2025 年 6 月 25 日，在 Andrej Karpathy 推文的推动下，上下文工程（Context Engineering）一词迅速在 AI 开发者社区中爆火。

+1 for “context engineering” over “prompt engineering”.

但是当时主要精力放在了大模型评估的工作上，因此一直没有时间来深入研究 上下文工程（Context Engineering）。直到最近，在我们构建端到端的 TestingAgent 时，我们遇到了因上下文窗口限制，多轮交互后初始重要字段丢失，导致 TestingAgent 执行失败的问题。我想，是时候来深入研究一下 上下文工程（Context Engineering）了。

如何根据历史胜负数据估计 Elo 打分？

2025-11-15

LLM

最近，Grok4.1 和 Gemini3 模型的发布都提到了人类偏好打分平台——LMArena 大模型竞技场：

在 LMArena 的 Text Arena 排行榜上，Grok 4.1 的推理模式（代号：quasarflux）以 1483 的 Elo 分数位居总榜首位，领先最高的非 xAI 模型整整 31 分^[1]。
刚一发布，Gemini 3就几乎屠榜所有评测集，以1501 Elo得分位列LMArena大模型竞技场第一^[2]。

通过对 LMArena 的榜单进行仔细分析，我们发现，不同于我们在有趣的 Elo 积分系统中介绍的实时更新的 Elo 分数，LMArena 的 Elo 分数还提供了 95% 置信区间的估计，同时还提供了模型上下限能力的排序。

这种新颖的打分、排序方式引起了我们的兴趣，于是我们决定深入研究 LMArena 的 Elo 评分系统，了解其背后的原理和方法，从而可以对 LMArena 的榜单有更深入的理解。