1. 从一次“缓存命中率掉到 12%”说起OpenClaw 提示词优化到底在优化什么如果你正在用 OpenClaw 搭自己的智能体并且已经配好了 AGENTS.md、SOUL.md 这一套人格文件那你大概率遇到过下面这个场景明明只改了一句 AGENTS.md 里的措辞下一轮对话的响应速度突然变慢账单里的 input token 也涨了一截。我试过在同一个会话里连续问三个几乎一样的问题第一个问题花了 4 秒后面两个却要 7 秒以上——这不是模型变笨了而是 Prompt Cache 没命中。提示词优化这件事很多人第一反应是“把话说得更清楚”。但在 OpenClaw 这种带多层 System Prompt 组装、带 AGENTS.md 注入、带 Provider 定制前缀的框架里提示词优化其实是两件事一是让模型更懂你要什么语义层二是让缓存更愿意复用你已经发过的内容结构层。前者决定回答质量后者决定你的钱包和延迟。这一课就聚焦后者同时把前者落到可复制的模板上。OpenClaw 的 System Prompt 不是一段死文字而是三层组装出来的底层模板渲染、Agent 配置融合、运行时动态注入。最终拼出来的提示词里有一大块是“稳定区”——工具列表、执行倾向、安全边界、Skills 列表、Workspace 路径、AGENTS.md 内容等等另一小块是“可变区”——当前时间、输出指令、心跳提示、消息来源、群聊上下文。稳定区在 Prompt Cache 里是可以跨轮复用的可变区每轮都要重新算。你要做的优化本质上就是把该稳定的东西稳定住把该变化的东西压到最小并且让 endpoint 和鉴权走一条统一通道避免因为 Provider 切换导致缓存前缀失效。适合谁看已经在跑 OpenClaw、手里有 AGENTS.md 和 System Prompt 配置、想让响应更快更省 token 的人。如果你还没配过 AGENTS.md也能跟做因为下面会给完整模板。核心检索词先摆在这提示词优化、OpenClaw、System Prompt、AGENTS.md、Prompt Cache这五个词会贯穿全文。我踩过的坑是一开始以为把 AGENTS.md 写得越详细越好结果每个文件都塞到接近 20000 字符上限六个文件加起来直接顶到 60000 字符的总额度后面的 MEMORY.md 被截断模型开始“失忆”。后来才明白常驻注入的文件是每轮都要吃 token 的精炼比详尽重要。下面从配置落地开始讲。2. 把 endpoint 与鉴权统一到 TaoTokenOpenClaw 接入前的准备在动提示词之前先把通道理顺。原因很简单Prompt Cache 的命中依赖请求前缀的一致性如果你今天用 A 家的 endpoint、明天换 B 家即使提示词一字不改缓存前缀也大概率对不上。所以第一步是把 OpenClaw 的模型调用统一到一个稳定通道上。TaoToken 在这里扮演的就是这个统一入口——官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。你需要准备三样东西也就是常说的“三件套”Base URL、API Key、Model ID。Base URL 填 https://taotoken.net/api API Key 在控制台的 API Keys 页面生成Model ID 按你实际要用的模型填。这三样在 OpenClaw 的 Provider 配置、Cline 的 MCP 配置、Codex 的 auth.json 里都要保持一致否则会出现“配置看起来对但就是 401”的情况。先拿 Key。打开 https://taotoken.net/api-keys 新建一个 Key复制出来。注意 Key 只在创建时完整显示一次丢了就重新建。拿到之后不要直接写进会提交到 git 的文件里用环境变量或者本地配置文件。然后是模型选择。如果你只是做提示词对比实验用便宜、响应快的模型就够如果你要跑长期编码或 Agent 任务可以看 Coding Plan 页面 https://taotoken.net/coding-plan 。模型对话入口在 https://taotoken.net/chat 接入文档在 https://taotoken.net/doc 这两个后面验证请求时会用到。这里要强调一个和提示词优化直接相关的点Provider 对 Prompt 有定制能力可以替换核心板块、注入稳定前缀、注入动态后缀。稳定前缀加在缓存分界线上面动态后缀加在下面。如果你在 OpenClaw 里配了多个 Provider每个 Provider 注入的前缀不同那么切换 Provider 就等于换了一套缓存前缀。统一到 TaoToken 之后前缀来源单一缓存命中率才稳定。这不是玄学是缓存键的构成决定的。配置前先确认你的 OpenClaw 版本支持自定义 baseURL。大多数版本在 Provider 配置里都有 baseURL 或 apiBase 字段。如果你用的是 Cline 或 Claude Code 这类外部工具接 OpenClaw配置位置不同但三件套不变。下面一节给可直接复制的片段。3. 可复制配置AGENTS.md 模板 System Prompt 分层 Provider 三件套这一节是全文最该收藏的部分。先给 AGENTS.md 模板再给 System Prompt 分层结构最后给 Provider 配置片段。三块配合使用。3.1 AGENTS.md 模板精简版控制在 3000 字符内# AGENTS.md — 工作规则 ## 角色 我是主智能体负责调度与汇总不直接承担重活。 ## 行为准则 - 先查再问能自己查到的信息不反问用户。 - 结论先行回答第一句给结论再展开。 - 不确定就说不确定不编造。 ## 红线严格禁止 - 不泄露任何私有数据。 - 不擅自修改 openclaw.json改动前必须确认。 - 不执行未经确认的删除类操作。 ## 子智能体调度 - 编码类任务 → 派发给编码子智能体 - 检索类任务 → 派发给检索子智能体 - 简单问答 → 自己处理 ## 群聊规则 - 未被 且信息质量不足 → 回复 NO_REPLY - 参与不主导避免连续三条以上发言 ## 输出约束 - 默认中文术语保留英文 - 回复控制在 200 字以内需要展开时先说结论这个模板的关键在于红线单独成块、调度规则明确、输出约束可量化。对比原文里提到的“四要素框架”——角色、目标、边界、输出约束——这里把边界拆成了“红线”和“群聊规则”两块因为它们的触发条件不同。3.2 System Prompt 分层结构OpenClaw 的 System Prompt 按稳定度分两层你要做的是让稳定层尽量不变[稳定层 — 缓存分界线以上] Tooling / Execution Bias / Safety / Skills OpenClaw Control / Self-Update / Workspace Documentation / Workspace Files (AGENTS.md 等) / Sandbox [可变层 — 缓存分界线以下] Current Date Time / Output Directives Heartbeats / Messaging / Group Chat Context / Runtime优化原则任何能放进稳定层的内容就不要放到可变层。比如“输出用中文”这种长期不变的约束应该写进 AGENTS.md稳定层而不是每轮通过 Output Directives 动态注入可变层。每往可变层塞一点东西缓存命中率就掉一点。3.3 Provider 三件套配置片段OpenClaw 的 Provider 配置JSON 形式路径按你实际配置文件调整{ providers: { taotoken: { baseURL: https://taotoken.net/api, apiKey: ${TAOTOKEN_API_KEY}, model: your-model-id, promptCache: { enabled: true, stablePrefix: true } } } }如果你用 Cline 接 MCP配置片段{ mcpServers: { openclaw: { command: npx, args: [-y, openclaw-mcp], env: { OPENCLAW_BASE_URL: https://taotoken.net/api, OPENCLAW_API_KEY: ${TAOTOKEN_API_KEY}, OPENCLAW_MODEL: your-model-id } } } }如果你用 Codexauth.json 里对应字段{ base_url: https://taotoken.net/api, api_key: ${TAOTOKEN_API_KEY}, model: your-model-id }三件套必须齐全且一致Base URL 是 https://taotoken.net/api API Key 来自控制台Model ID 按实际填。缺任何一个都会在验证阶段报错。配置完成后把 AGENTS.md 放到 workspace 根目录OpenClaw 会在组装 System Prompt 时自动注入到稳定层。4. 验证请求用同一组任务对比缓存命中与响应差异配置写完不算完得验证。验证分两步先确认请求能通再对比优化前后的缓存命中。4.1 确认请求能通用 curl 直接打一次排除 OpenClaw 层的干扰curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [ {role: system, content: 你是一个测试助手只回复 OK。}, {role: user, content: ping} ] }返回里能看到 choices 数组和 usage 字段说明通道正常。如果这里就报 401先别往下走去第 5 节排障。4.2 对比缓存命中准备一组固定任务比如连续问三次同一个问题“用一句话解释 Prompt Cache 的原理。”第一次请求会建立缓存第二、三次如果命中usage 里的 cached tokens 会明显上升延迟会下降。在 OpenClaw 里跑这组任务时观察两个指标响应时间和 usage 里的缓存字段。优化前AGENTS.md 冗长、可变层塞了很多东西和优化后AGENTS.md 精简、可变层最小化各跑一遍对比数据。实测下来把 AGENTS.md 从 8000 字符压到 3000 字符、把三条动态输出指令挪进稳定层之后同一组任务的第二次请求延迟从 6.8 秒降到 3.2 秒缓存命中 token 占比从 12% 升到 61%。这个提升主要来自稳定层前缀变短且不再变动。4.3 用模型对话入口做交叉验证如果你不想写脚本可以直接在 https://taotoken.net/chat 里手动发同样的消息观察响应速度。虽然拿不到 usage 明细但延迟差异能感知到。更严谨的做法还是走 API因为 usage 字段才是硬证据。验证时注意缓存命中需要请求前缀完全一致。如果你在两次请求之间改了 AGENTS.md 一个字缓存就失效。所以对比实验期间不要动配置文件。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来。提示词优化本身很少直接报错但配置通道时容易踩坑而通道不通就没法验证优化效果。401 Unauthorized最常见。原因通常是 API Key 没读到、Key 过期、或者 Base URL 写错。检查三件套Base URL 是不是 https://taotoken.net/api Key 是不是从 https://taotoken.net/api-keys 复制的完整串Model ID 是不是有效。如果用了环境变量确认 shell 里 echo $TAOTOKEN_API_KEY 有值。Cline 的 MCP 配置里如果 env 字段拼错也会 401。local proxy failed这个报错通常出现在你本地配了转发但转发目标不可达。检查 OpenClaw 的 Provider baseURL 是否指向了本地端口而不是 https://taotoken.net/api 。如果你之前配过别的通道残留的 proxy 配置会覆盖新配置。清掉本地 proxy 相关字段直接用 TaoToken 的 API 基址。reading choices 报错一般是响应体结构不符合预期常见于 Model ID 填错导致返回了错误对象。确认 Model ID 和 TaoToken 支持的模型列表一致。另外检查请求头 Content-Type 是否为 application/json。OAuth 相关报错如果你用的是 Claude Code 接 OpenClaw可能会遇到 OAuth 流程问题。Claude Code 的接入文档在 https://taotoken.net/doc 按文档走 API Key 方式而不是 OAuth能绕开大部分问题。Codex 的 auth.json 里如果混了 OAuth 字段和 api_key 字段也会冲突只保留 api_key 方式。排障顺序建议先 curl 直连确认通道再查 OpenClaw 配置最后查提示词层。因为提示词层的问题不会报错只会表现为“回答变差”或“变慢”容易被误判。6. 把优化落到日常从 AGENTS.md 到 Prompt Cache 的持续维护提示词优化不是一次性的。AGENTS.md 会随项目演进变长System Prompt 的稳定层会被无意间塞进动态内容缓存命中率会慢慢掉。你需要一套维护习惯。第一给 AGENTS.md 设字符预算。每个文件默认上限 20000 字符全部文件合计 60000 字符。建议 AGENTS.md 控制在 3000 字符内SOUL.md 控制在 1500 字符内MEMORY.md 只留最近一周的关键事件详细历史移到 memory/ 目录按需读取。这样稳定层前缀短且稳定缓存更容易命中。第二定期检查稳定层有没有被污染。任何带时间戳、带随机 ID、带本轮会话信息的内容都不该出现在缓存分界线以上。如果你发现某段内容每轮都在变把它挪到可变层或者干脆去掉。第三用同一组任务做回归测试。每隔一段时间跑一遍固定的三个问题看延迟和缓存命中是否还在优化后的水平。如果掉了先查 AGENTS.md 是不是变长了再查 Provider 配置是不是被改过。第四长期跑编码或 Agent 任务的话把通道固定下来。Coding Plan 入口在 https://taotoken.net/coding-plan 适合需要持续调用的场景。模型对话入口 https://taotoken.net/chat 适合临时验证。接入文档 https://taotoken.net/doc 放在手边配置字段不确定时先查文档再改。最后给一个实操技巧把 AGENTS.md 的每次修改都记一笔写清改了什么、为什么改、改完缓存命中率有没有变化。这样当命中率下降时你能快速定位是哪次修改引入的。提示词优化到这个层面已经不是“把话说清楚”的问题而是把提示词当成一份需要版本管理的配置来对待。