夜雨聆风Token是AI时代的“石油”，但你可以成为自己的“炼油厂”
“2小时消耗100美元。”
这不是什么大型企业的AI训练账单，而是一位普通OpenClaw用户的真实经历。他在社交平台晒出的账单截图，在开发者社区引发了广泛共鸣——评论区里，无数“养虾人”晒出了自己同样触目惊心的Token消耗记录。
与此同时，另一批用户却宣称自己“每月成本几乎为零”，甚至“用得越久，省得越多”。
同样是用OpenClaw，差距为何如此之大？
答案很简单：Token消耗不是玄学，而是可以被精确管理的科学。本文将基于真实用户的优化实录，为你拆解Token消耗的8个核心技巧，从清理文件到本地部署，从模型选型到缓存策略，帮你把每一分钱都花在刀刃上。
一、先诊断，再治疗：你的Token到底烧在了哪里？
在谈优化之前，先搞清楚一个问题：你的Token到底消耗在哪儿了？
一位阿里云开发者社区的用户分享了他的真实经历。他在OpenClaw中输入一句仅22个字符的简单指令，执行/status后得到的状态是：
输入：22 Token 输出：564 Token 上下文加载：44,000 Token 缓存命中率：0%
这意味着，一次简单的对话，AI却加载了4.4万Token的“背景信息”——其中绝大部分与当前问题毫无关系。用他的话来说：“绝大多数成本并非消耗在有效对话，而是被无效文件、重复配置、冗余备份等隐性上下文占用。”
他编写了一个审计脚本对~/.openclaw/目录进行扫描，结果令人震惊：
| 合计无效占用 | 36,238 | 78% |
结论：近八成的Token都烧在了与有效对话无关的地方。 这意味着，在不改变任何使用习惯的前提下，仅通过清理就能节省70-80%的成本。
二、8个降本技巧：从入门到精通
基于以上诊断逻辑，我整理了8个经过验证的Token优化技巧，按实施难度从低到高排列。
🔧 技巧一：清理无效文件（立竿见影，节省40-50%）
这是最直接、最有效的一步。OpenClaw启动时会自动扫描workspace/目录下的所有文件并全量注入上下文。如果这个目录里堆满了临时文件、草稿、备份，AI每次都要“阅读”一遍。
操作步骤：
进入你的OpenClaw工作目录（通常是 ~/.openclaw/或/opt/openclaw/data）识别并移除非必要文件：临时报告、链接清单、草稿、旧日志 将备份文件（.bak）统一归档到独立子目录（如 archive/bak/）检查多个Workspace是否有重复的AGENTS.md，如有则合并为一份
实测效果：一位用户执行上述清理后，启动Token从46,177降至25,515（降低约44%）。配合AGENTS.md去重后，最终降至12,000以内，**整体消耗降低74%**。
🔧 技巧二：善用斜杠命令（日常必备，即时生效）
OpenClaw内置了几个强大的斜杠命令，可以在不丢失重要信息的前提下“瘦身”当前会话。
/compact：压缩当前会话上下文。当你发现对话越来越长、响应越来越慢时，发送这个命令，AI会将历史对话总结成更短的“摘要记忆”，后续对话基于摘要进行，Token消耗大幅下降。建议每50-100轮对话使用一次。**
/reset**：重置当前话题的短期上下文，但保留长期记忆和个人偏好。当你要切换话题时使用，避免旧话题的“记忆残留”污染新对话。**
/new**：开启一个全新的会话，相当于“换个聊天窗口”。这是最彻底的清理方式，适合开启全新的任务。
一位用户分享了他的使用节奏：每个工作日早晨用/new开启新会话，中午休息前用/compact压缩，下午切换话题时用/reset。**月度Token费用降低了约30%**。
🔧 技巧三：多Agent分工（架构级优化，省30-50%）
很多用户喜欢“一个Agent包打天下”——代码、文档、运营、日程管理全交给同一个Agent。结果是：每次对话，Agent都要从混乱的记忆中“大海捞针”。
更好的做法：像组建团队一样，为不同任务配置专门的Agent：
代码Agent：只负责代码相关任务，工作目录只放代码文件 内容Agent：负责文档、周报、推文，工作目录只放素材 运营Agent：负责监控、提醒、调度，工作目录只放配置
效果：每个Agent的上下文更“干净”，模型不需要在无关信息中搜索。一位用户实践了这一方法后，**Token消耗降低了40%**，同时各任务的响应准确率也明显提升。
🔧 技巧四：配置心跳降频（细水长流，省20%）
OpenClaw默认每30分钟发送一次“心跳”信号，用于保持服务活跃和状态同步。但如果你不是7×24小时都在使用，这就是纯粹的浪费。
优化配置：
"heartbeat": {"intervalMinutes": 120, // 从30分钟改为2小时"activeHours": "08:00-24:00"// 只在活跃时段发送}效果：每日心跳次数从48次降至8次，减少了约83%的心跳Token消耗。虽然心跳本身占整体消耗比例不大，但积少成多。
🔧 技巧五：启用上下文裁剪（自动瘦身，省20-30%）
OpenClaw 2.6版本引入了contextPruning功能，可以自动裁剪过旧的上下文内容。
优化配置：
"contextPruning": {"mode": "cache-ttl","ttl": "5m"// 超过5分钟的tool输出自动裁剪}效果：每次对话只保留最近5分钟内的工具调用记录，避免历史输出堆积。一位用户反馈这项配置带来了20-30%的Token节省，且AI响应速度明显提升。
注意事项：这只影响发送给大模型的上下文，不会删除磁盘上的会话历史，不用担心数据丢失。
🔧 技巧六：子Agent模型降级（大智慧，省60%）
OpenClaw支持“子Agent”机制——当主Agent需要处理后台任务（如定时任务、监控、数据抓取）时，会派生子Agent执行。默认情况下，子Agent继承主Agent的模型配置，通常是最贵的旗舰模型（如Claude Opus）。
优化逻辑：子任务通常不需要最强模型。发个早报、跑个监控、抓个数据，中等模型完全够用。
优化配置：
"subagents": {"model": "minimax/MiniMax-M2.1", // 费用约为Opus的1/3"archiveAfterMinutes": 30}效果：子Agent的模型费用从Opus级别降至中端模型，**节省约60-70%**。同时设置archiveAfterMinutes从60降至30，子会话更快回收，减少内存占用。
🔧 技巧七：更换低成本模型（源头截流，省70-90%）
这是最直接的省钱方式——换一个更便宜的模型。
方案A：阿里云百炼Coding Plan
阿里云推出了“Coding Plan”服务，将从按Token计费升级为按次收费，大幅降低高频调用场景的成本。用户购买后，在控制台生成API Key，配置到OpenClaw即可使用。对于日常任务频繁的用户，这是性价比最高的选择之一。
方案B：七牛云等第三方通道
七牛云提供OpenAI/Anthropic兼容的API通道，支持一键创建密钥并激活最高600万的免费Token额度，对开发测试阶段的成本控制非常有帮助。
方案C：DeepSeek等国产模型
国产模型的价格优势非常明显：DeepSeek输入0.14元/万Token，输出0.28元/万Token；而Claude Opus输入15美元/百万Token（约1元/万Token）。国产模型的价格仅为Claude的1/7左右。
关键提醒：不同模型的能力差异客观存在。建议的策略是：简单任务用低成本模型，复杂推理用高端模型。通过OpenClaw的模型路由功能，可以在不同场景下自动切换。
🔧 技巧八：本地部署+本地模型（终极方案，近乎免费）
如果你追求极致的成本控制，且对数据隐私有较高要求，本地部署是终极答案。
方案A：使用免费云端算力
无问芯穹AICoder：提供免费的2核CPU、4GB内存开发实例，完全满足OpenClaw的运行需求 HyperAI：提供免费CPU配额，Basic用户单个任务最长可连续运行12小时
方案B：本地GPU推理
NVIDIA官方提供了在RTX GPU上本地运行OpenClaw的完整指南。根据GPU显存大小选择合适的模型：
使用LM Studio或Ollama作为后端，配置后即可在本地运行模型，Token成本为零，且数据完全不出本地。
但请注意：本地模型的能力与云端顶级模型（如Claude Opus）仍有差距。如果你的任务对推理质量要求极高，云端模型仍是必要投资。建议采用混合策略：日常任务用本地模型，复杂推理临时调用云端API。
三、进阶玩法：用Skill实现“自动驾驶”
除了手动配置，社区还开发了一些专门用于Token优化的Skill，可以实现“自动化省钱”。
QMD：让记忆检索从“全量加载”变为“精准召回”
QMD是Shopify创始人Tobi开发的开源工具，采用BM25全文搜索+向量语义搜索+Qwen3重排序的三层混合检索机制。
传统方式：每次对话加载全部记忆文件，哪怕只需要其中1%的信息。
QMD方式：只检索与当前问题最相关的2-3句话注入上下文。
实测效果：
每次查找Token消耗：15,000 → 1,500（**节省90%**） 长会话（100轮）消耗：500,000 → 60,000（**节省88%**）
安装配置：
# 安装QMDcurl -fsSL https://bun.sh/install | bashbun install -g qmd# 配置OpenClaw使用QMD# 在openclaw.json中添加："memory": {"backend": "qmd","qmd": {"enabled": true,"max_retrievals": 6 }}prompt-guard：分层加载防御规则
OpenClaw在处理用户输入时，会加载安全防御规则集。传统方式是每次请求都加载完整规则，其中70%的Token用于无意义的重复校验。
prompt-guard采用“分层加载”策略：只将当前请求相关的规则注入上下文，节省约70%的安全相关Token消耗。
四、效果汇总：不同策略的省钱效果
写在最后：Token优化是一场持久战
Token消耗从来不是“一劳永逸”的问题。随着使用习惯的改变、任务类型的变化，Token消耗曲线会持续波动。
三个建议供你参考：
建立监控习惯：每周执行一次
/status，关注上下文占用率和缓存命中率。当上下文占用超过40%时，及时执行/compact。定期“体检”：每个月花30分钟检查工作目录是否有新增的无关文件、是否有重复配置、是否有旧任务残留。
渐进式优化：不必一次性实施所有技巧。先从清理文件开始，感受变化后再逐步尝试模型降级、本地部署等高级方案。
正如一位经历了“4671次崩溃事故”的用户所言：“AI助手不是装完就能跑一辈子的。它就像一辆车——你得定期保养，检查机油、轮胎、刹车。不然哪天高速上抛锚，你才发现发动机早就拉缸了。”
Token是AI时代的“石油”，但你可以成为自己的“炼油厂”。从今天开始，花30分钟给你的OpenClaw做一次“体检”，让每一分Token都花在刀刃上。
本文数据来源：阿里云开发者社区用户优化实录、NVIDIA官方指南、腾讯云技术文档、无问芯穹AICoder教程、七牛云技术博客及公开社区分享。AI行业动态变化，最新定价请以各平台官方公告为准。
从“模型上下文协议”到“命令行才是未来”，一场关于AI如何连接世界的路线之争
你有没有想过一个问题：
当AI Agent要帮你查天气、订机票、操作电脑时，它到底是怎么“学会”这些能力的？
答案是：通过一个叫MCP的东西。
MCP，全称Model Context Protocol（模型上下文协议），由Anthropic在2024年推出，被业界寄予厚望——它被认为是AI Agent连接外部工具的“USB-C接口”，一个统一的、标准化的协议，让AI无需为每个工具单独写代码。
然而，OpenClaw创始人彼得·斯坦伯格（Peter Steinberger）最近在一期播客中，抛出了一个引爆行业争议的判断：
“MCP已死。”
这句话来自Lex Fridman Podcast第491期，彼得·斯坦伯格作为嘉宾，在长达三小时的深度对话中，详细阐述了他对MCP的批判，以及OpenClaw选择另一条路的原因。
他不是在博眼球。他用OpenClaw——这个GitHub史上增长最快的开源项目，33万+ Stars——的实际行动证明了自己的判断。
那么，MCP到底是什么？它真的“死”了吗？OpenClaw用什么替代了它？这场路线之争，又将如何影响AI Agent的未来？
一、MCP是什么？——AI的“万能插头”
在深入争论之前，我们先搞清楚MCP到底是什么。
MCP（模型上下文协议） 是Anthropic推出的一个开放标准，旨在解决AI Agent连接外部工具的“M×N问题”。
什么是“M×N问题”？
想象一下：你有M个AI模型（比如Claude、GPT、Gemini），你想让它们连接N个外部工具（比如数据库、API、文件系统）。如果没有统一标准，你需要为每一个“模型-工具”组合写一套集成代码——那就是M×N种适配。
MCP的解决方案是：定义一个标准协议，所有模型和工具只要遵守这个协议，就能“即插即用”。它的核心架构包含三个角色：
MCP Host：需要调用工具的AI应用（如Claude Desktop） MCP Client：与MCP Server通信的客户端 MCP Server：暴露工具能力的服务器程序
简单说，MCP想让AI Agent连接工具，变得像U盘插上电脑一样简单。
听起来很美，对吧？
但彼得·斯坦伯格说：这条路走不通。
二、为什么MCP“已死”？——彼得·斯坦伯格的三重批判
彼得·斯坦伯格对MCP的批判，可以从三个层面理解：
1. 根本缺陷：不可组合
这是最致命的问题。
他举了一个简单的例子：天气查询。
如果用MCP调用一个天气API，返回的是一大坨JSON数据——温度、降水、风速、湿度、气压……全塞进AI的上下文窗口。如果只想知道“今天带伞吗”，其他字段全是噪音，污染上下文，浪费Token。
但如果用命令行（CLI）呢？
weather-api 10001 | jq '.rain_probability'AI可以自己加一个jq命令，只过滤出需要的字段。甚至可以组合成更复杂的脚本：
weather-api 10001 | jq '{temp: .temp, rain: .rain_probability, wind: .wind_speed}'把三个API调用组合成一个精确的输出——这才是真正的可组合性。
彼得·斯坦伯格的原话是：
“MCP的致命问题在于不可组合。模型天生就擅长调用Unix命令，CLI就是另一条Unix命令而已，不需要学习特殊语法。”
2. 架构过重：标准化代价太大
MCP基于JSON-RPC 2.0协议，需要建立客户端-服务器连接，处理会话管理、工具发现、参数验证等一系列复杂的工程问题。
而CLI呢？就是一条命令。
智能体看到weather 10001，执行它，拿到输出——完事。没有连接建立，没有会话管理，没有协议解析。
彼得·斯坦伯格指出，MCP也有功劳——它推动了很多公司去构建API。但现在，OpenClaw可以直接把这些MCP“转译”成CLI来用。
3. 违背Unix哲学
Unix哲学的核心是：每个程序做好一件事，通过管道组合。
grep只做搜索，sort只做排序，uniq只做去重。但把它们用管道连起来，就能完成复杂的文本分析任务。
MCP违背了这一哲学。每个MCP Server都是“大包大揽”的——天气Server返回所有天气信息，用户无法只取需要的部分。
相比之下，CLI天然支持组合。彼得·斯坦伯格认为，这才是AI Agent连接工具的正确方式。
三、OpenClaw的答案：SKILL + CLI
如果不用MCP，OpenClaw用什么？
答案是：SKILL + CLI。
SKILL是OpenClaw的“技能模块”，本质上是一个结构化的文件夹，包含三部分：
SKILL.md：用自然语言写的“操作手册”，告诉AI这个技能是什么、什么时候用、怎么做 scripts：可执行的代码脚本 references：参考资料
大部分SKILL的底层，就是CLI工具加上一段自然语言说明书。
这个设计的精妙之处在于：
按需加载：AI启动时只加载SKILL的元数据（名称和简介），执行任务时才动态加载完整内容。这能有效节省上下文窗口和Token消耗。
自然语言友好：SKILL.md用自然语言编写，AI可以直接理解，不需要学习特殊协议语法。
Unix哲学：每个SKILL做好一件事，可以通过组合完成复杂任务。
彼得·斯坦伯格在播客中举了一个例子：他的智能体在摩洛哥旅行时，发了一条语音消息——他根本没有给智能体加语音功能。结果智能体自己检查了文件头，发现是opus格式，用ffmpeg转码，翻到了本地存储的OpenAI API Key，用curl把音频发给Whisper API做转写，然后回复了他。
这就是CLI哲学的力量。智能体不是在“执行预设功能”，而是在理解问题、搜索工具、评估方案、执行最优路径。这种能力可以迁移到任何领域。
四、MCP的“辩护者”：Claude Code Channels的尝试
当然，不是所有人都认同“MCP已死”的判断。
2026年3月19日，Anthropic发布了Claude Code Channels，允许开发者通过Telegram和Discord向Claude Code发送指令。这个产品的技术基础正是MCP。
在Channels架构中，每个通讯平台对应一个MCP插件，开发者启动会话时，系统同时启动一个基于Bun运行时的轮询服务，监听指定插件的消息。
这个设计有两个亮点：
1. 安全模型更成熟
每个Channel插件维护发送者白名单，只有经过配对验证的用户ID才能推送消息。Team和Enterprise计划还需要管理员显式启用channelsEnabled设置。
这种“默认关闭、逐层开放”的策略，和OpenClaw那种可以直接获取文件系统完整访问权限的做法形成了鲜明对比。
2. “专有引擎+开放连接层”策略
Anthropic的推理引擎是商业机密，但Telegram和Discord的插件代码托管在GitHub上，任何人都可以基于MCP协议为Slack、WhatsApp或其他平台构建自己的连接器。
这种策略让Anthropic能守住模型质量，同时把扩展生态的活儿分给社区。
但彼得·斯坦伯格的回应很简单：标准化代价是臃肿和不可组合，智能体本身就是最好的“协议适配层”——你给它一个CLI，它自己会搞清楚怎么用。
五、路线之争的本质：两种智能体哲学
MCP vs CLI的争论，表面上是技术选型，本质上是两种智能体哲学的差异。
MCP路线：标准化、结构化、可控
MCP试图为AI Agent的工具调用建立“工业标准”。这更符合企业级应用的需求——可审计、可治理、可追溯。对于金融、医疗等需要严格合规的场景，MCP的标准化和可管控性确实是优势。
CLI路线：轻量、灵活、可组合
CLI路线更符合开源社区的“小而美”哲学，也更能发挥大模型的通用问题解决能力。彼得·斯坦伯格在播客中说：
“编程作为一种手艺正在消亡，但构建作为一种能力正在爆发。那些试图把所有事情自动化的人，做出来的东西缺少风格、缺少爱、缺少人味。”
这句话揭示了他的核心信念：AI的价值不在于“自动化一切”，而在于“放大人类的能力”。
CLI路线的另一大优势是无需等待。大公司开发一个功能需要审批、协调、安全审查，一个功能从构想到上线可能几周甚至几个月。而彼得·斯坦伯格一个人，直接上线。
六、这意味着什么？——对三个群体的影响
这场路线之争，对不同群体意味着什么？
对AI Agent开发者
如果你正在开发AI Agent，不要盲目跟风MCP。先想清楚你的场景：
如果你的Agent需要与多个商业系统集成，且这些系统提供了MCP Server，MCP能节省大量工作 如果你的Agent主要在本地运行，操作文件、命令行、浏览器，CLI + SKILL可能更合适 如果两者都有，考虑混合策略——用CLI做主要工具调用，只在必要时用MCP
彼得·斯坦伯格本人的做法是：少数需要维持状态的场景（如Playwright控制浏览器）MCP仍然合理，但那是例外。
对企业决策者
如果你正在为企业评估AI Agent方案，不要只看功能列表。要关注：
安全架构：个人开源工具和企业级产品的本质区别，不在于功能多少，而在于安全是“可选配置”还是“内建基因” 可审计性：所有AI操作是否可追溯、可回放 权限模型：是否支持最小权限原则
明略科技副总裁李梦林指出，安全是“架构约束”而非“功能特性”——企业在评估AI Agent方案时，安全架构的成熟度应当是首要考量因素之一。
对普通用户
如果你只是想“养一只龙虾”替你干活，不必纠结技术路线。
OpenClaw目前更适合程序员、极客或网络熟手。对于普通人来说，可能需要等待国内大厂推出更多应用、交互性更好、安全性更高的变种“龙虾”。
目前OpenClaw的配置门槛仍然较高。有用户反映，很多人装上之后，依然只把它当作高级版闹钟或天气查询工具——真正价值在于“养成”，需要时间和耐心。
安全提醒：OpenClaw能访问文件、执行命令，建议用单独的试验设备，不要安装到主力机上。
写在最后：MCP死了吗？
回到最初的问题：MCP真的“死”了吗？
答案是：没有死，但也不再是唯一答案。
MCP在企业级集成、标准化治理等场景仍有价值。Anthropic推出Claude Code Channels，证明MCP在特定场景下可以工作得很好。
但OpenClaw用SKILL + CLI的实践证明：还有另一条路。这条路更轻量、更灵活、更符合Unix哲学，也更契合大模型的通用问题解决能力。
彼得·斯坦伯格在播客中说：
“每个MCP用CLI做都更好。这个判断在开发者社区仍有争议，但OpenClaw核心层根本没有MCP支持，也没人抱怨。”
这不是傲慢，而是基于实践的判断。他用OpenClaw的33万+ Stars证明了：用户不关心你用的是什么协议，他们只关心你能不能干活。
未来，更可能的局面是混合共存——MCP负责标准化集成，SKILL + CLI负责灵活组合。两者不是非此即彼，而是各有适用场景。
但无论如何，这场争论揭示了一个更根本的转变：AI Agent正在从“只会说”走向“真正做”。而怎么“做”，才刚刚开始被探索。
本文部分内容引用自Lex Fridman Podcast第491期、钛媒体、明略科技专家解读及公开行业报道。AI行业动态变化，最新信息请以各平台官方公告为准。
