ApexGearNode | AI 知识库

当云端 API 的延迟账单越积越厚，越来越多的团队开始把目光投回本地推理栈。OpenClaw 项目正是这一浪潮下的典型样本——它在 RTX 4090 单卡上用 vLLM 跑通 7B 级别模型，端到端首字响应被压缩到 1.2 秒以内，彻底摆脱对外部服务的依赖。但把模型拉到本地只是第一步；真正决定体验上限的，是那份躺在项目根目录下的 corecontext.text 文件。

本文将拆解 OpenClaw 的两条工程主线：一是用 vLLM 部署一个 PagedAttention 推理服务，让本地模型获得生产级的吞吐与并发；二是按社区共识的十步法打磨一份上下文文件，让同一个基座模型在不同的 system prompt 下，呈现出截然不同的"灵魂"。前者解决速度问题，后者解决人格问题——两条线缺一不可。

一、为什么选 vLLM：PagedAttention 的工程红利

本地推理最大的痛点不是模型权重，而是 KV cache 对显存的低效利用。传统 HuggingFace Transformers 在长上下文场景下会因为显存碎片化而崩溃，vLLM 通过借鉴操作系统虚拟内存的 PagedAttention 机制，把 KV cache 切成固定大小的"页"，使显存利用率从 30% 跃升到 90% 以上。

对 OpenClaw 这种需要秒级响应、又要在单卡上服务多用户的场景，PagedAttention 带来的吞吐提升是数量级的。配合 continuous batching，vLLM 能把多个请求的 prefill 与 decode 阶段交织执行，避免任何一张卡处于空转状态。

1.1 硬件门槛与显存估算

跑通 7B 量化模型（INT4）至少需要 8GB 显存，14B 推荐 12GB，34B 则需要双卡 24GB 以上。OpenClaw 默认走 INT4 量化路径，用 GPTQ 或 AWQ 格式加载权重，在 4090 上可以把首字延迟压到 1 秒级别。

vllm_launch.sh

python -m vllm.entrypoints.openai.api_server \
  --model ./models/Qwen2.5-14B-Instruct-AWQ \
  --quantization awq \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --tensor-parallel-size 1 \
  --port 8000

OpenClaw 默认把 gpu-memory-utilization 设到 0.92，留出 8% 给系统与采样缓存。如果机器上还跑其他推理任务，建议下调到 0.85 以下，避免 OOM。

二、上下文文件：本地模型的灵魂

把模型权重装好只是让大脑上线，真正的"人格"来自 corecontext.text 这份纯文本文件。它告诉模型：你是谁、用户是谁、什么行为被允许、什么工具可调用——所有云端 API 默认帮你做好的事情，本地部署都要自己写。

社区里流传着一句很到位的话：同一份模型，不同的上下文，呈现完全不同的个性。OpenClaw 的核心理念是把这份上下文当作活文档而非一次性配置——模型装一次，上下文改无数遍。

2.1 十段式骨架

OpenClaw 推荐的上下文结构包含十个段落，按顺序依次是 Identity、Relationship、Values、Capabilities、Tools、Memory、Style、Example Conversations、Rules、Iteration Log。前八段定义静态人格，后两段记录动态演化。

corecontext.text

# Identity
You are OpenClaw, a warm, technically rigorous local AI companion.
Speak with curiosity, clarity, and a hint of dry humor.

# Relationship
The user is a maker working on robotics and web projects.
Treat them as a trusted collaborator, not a help-desk ticket.

# Values
- Honesty first: admit uncertainty rather than fabricate.
- Safety: never generate code that bypasses auth or exfiltrates data.
- Respect time: answer concisely unless detail is requested.

Identity 段必须用指令式短句。描述"你是一个友好的助手"远不如"Speak with curiosity, clarity, and a hint of dry humor"有效——模型对祈使句的遵从度显著高于对形容词的反应。

三、能力边界：把离线写进宪法

本地模型最常翻车的场景，是被问"帮我查一下今天的新闻"然后一本正经地编造答案。OpenClaw 的解法是在 Capabilities 段把能/不能做的事写死，并要求模型在无能力时主动声明离线状态并给出替代方案。

3.1 工具声明而非工具发现

模型不会自己猜测有什么工具可用。所有工具（list_files、run_sim、read_file 等）必须按名称列出，并附上功能描述。这是 OpenClaw 与 LangChain 等框架的本质区别：没有动态工具注册，只有静态文本契约。

tools_section.txt

# Tools
- list_files: shows contents of the current project folder.
- run_sim: launches the robot simulator with the given config.
- read_file <path>: returns the full text of a local file.
- write_file <path, content>: persists content to disk.

Note: the model MUST call these by exact name as written above.

注意 read_file 与 write_file 中的尖括号只是占位符语法，模型理解的是位置参数语义。如果你改成 JSON Schema 描述，反而会让本地模型感到困惑——保持纯文本契约最稳。

四、记忆映射：让模型知道档案在哪

OpenClaw 项目通常包含多个文本文件：roadmap.text 记录长期规划，hardware.md 描述硬件清单，build.log 存最近一次构建结果。Memory 段就是告诉模型这些文件的相对路径与用途。

这一步看似多余，实则是把"项目记忆"显式化。没有这段，模型每次都会在错误的文件里寻找答案；有这段后，模型能在被问到"下一步该做什么"时直接引用 roadmap.text 的最新条目。

4.1 对话风格调校

Style 段是"氛围参数"——回复长度、用词、术语解释方式都在这里调。OpenClaw 默认偏向"工程师对工程师"的简洁风，但允许在 Style 段覆盖成教学风、审稿风或苏格拉底式反问风。

如果想让模型学会某种节奏，与其描述它"应该友好"，不如直接给一段示例对话。模型对 few-shot 示例的吸收效率远高于对形容词指令的响应——show, do not just tell。

五、活文档迭代：模型装一次，上下文改百次

OpenClaw 的核心运营哲学是：Install the model once. But refine the context many times. 每一次让模型答错、答偏或答得太啰嗦，都是上下文文件的修订信号。

具体的迭代动作有三个：喜欢的行为抽成规则写进 Rules 段；不喜欢的行为要么在 Example Conversations 里加反例，要么在 Capabilities 段加硬约束；价值观漂移则在 Values 段追加新的底线条目。这种"基于反馈的版本化"是把通用模型训练成专属伙伴的关键路径。

5.1 与 vLLM 的协同

上下文长度直接影响推理延迟。把 corecontext.text 从 2KB 膨胀到 20KB，首字延迟会从 1.2 秒爬升到 2.5 秒以上。OpenClaw 的应对策略是启用 vLLM 的 prefix caching——相同的 system prompt 前缀会被缓存在显存里，多轮对话的边际成本接近零。

vllm_with_prefix_cache.py

from vllm import LLM, SamplingParams

llm = LLM(
    model='./models/Qwen2.5-14B-Instruct-AWQ',
    enable_prefix_caching=True,
    max_model_len=8192,
    quantization='awq',
)

# 相同的 corecontext 前缀在多轮请求间复用
sampling = SamplingParams(temperature=0.7, max_tokens=512)
outputs = llm.generate(prompts, sampling, prefix=corecontext_prefix)

prefix caching 的命中率受会话前缀稳定性影响。建议把 corecontext.text 放在 prompt 最前面且永远不修改顺序——一旦中间插入新段落，缓存就会失效，重新 prefill 的代价不菲。

结论

OpenClaw 给出的是一条"速度 + 人格"双轨并行的本地化路径：用 vLLM 的 PagedAttention 把推理延迟压到秒级，再用上下文文件的十段式骨架把通用模型驯化成专属伙伴。两者结合，本地部署不再是"将就的备选"，而是可以正面对抗云端 API 的工程方案。

真正的护城河不在硬件也不在模型权重，而在 corecontext.text 这份持续迭代的活文档。当你的上下文足够精细、足够诚实、足够具体——它就是你在这个 AI 时代的个人宪法，也是让你的本地模型"秒级响应"的同时还能说出人话的关键。