OpenClaw 遭 Anthropic “断供” 背后:失控的成本管理最近圈子里都在讨论 Anthropic 限制 OpenClaw 使用 Claude 包月订阅额度的事。很多人抱怨这是大厂打压开源生态，但如果你亲自去 LLM API 官网看过 OpenClaw 框架的 token 消耗额度，就会知道这种“断供”早有征兆。这根本不是简单的商业竞争，本质是失控的上下文造成的资源量费。Claude：精打细算
去看看 Anthropic 自家是怎么做 Claude Code 的，他们在底层对资源的调度极其克制。不管是之前的 Skills 机制，还是现在的工具调用（Tool Use），Claude 采用的都是典型的“渐进式披露（Progressive Disclosure）”策略。大模型绝不会在一次请求里把所有工具的 Schema 和历史对话全盘接收，而是按需、按片动态加载。他们极其清楚自己的算力池有硬性瓶颈，靠死磕长文本堆出来的智能，在商业上是一笔算不过来的烂账。
具体来说，这种克制体现在以下两个方面：
成本太高：Token 消耗倍增
在粗放的开源框架里，开发者习惯于把系统能做的所有事情全写进 System Prompt。假设你有一个包含 50 个工具（比如查订单、退款、改密等）的复杂业务线。每个工具的 JSON Schema 定义加上描述，平均需要 150 个 Token。如果全量注入，光是 System Prompt 就占了 7500 个 Token。 在 Agent 循环中，大模型每思考（Thought）并执行（Action）一步，历史上下文就会增加。假设一个任务需要循环 5 次，这 7500 个基础 Token 会被重复计费 5 次。这只是底座成本，还没算上动态生成的日志。 Claude 的做法是渐进式披露。模型首先只加载一个极简的“意图识别”Prompt，判断当前只需用到“查订单”工具，然后才通过动态拉取这一个工具的 Skill 注入到下一轮请求中。每次请求，每个用户的请求，基础开销瞬间从 7500 降到 150，这在 C 端可能是几分钱的差别，但在高并发的生产环境里，直接决定了项目是盈利能力。理解太差：幻觉加剧，上下文丢失
大模型的上下文窗口虽然已经卷到了 200K 甚至 1M，但“能吃下”和“能消化”是两码事。学术界和工程界的共识是，注入的无关 Schema 和冗余历史记录越多，大模型在关键步骤上产生“幻觉”或掉链子的概率就呈指数级上升。 Claude 它不把大模型当成一个全知全能的超级大脑，而是当成一个流水线上的专注工人。每次只给当前步骤绝对必要的信息片段。这种克制不仅省了钱，更大幅提高了复杂函数调用（Function Calling）的准确率，避免了模型在海量的工具库里发生“路由穿透”跑偏。在 Agent 高速迭代的今天，不要去迷信那些动辄占用几十万 Token 来完成一个简单任务的“暴力跑分”演示。真正能在企业里活下来的架构，必定是像 Claude Code 这样，懂得死扣每一个 Token 投入产出比的“抠门”系统。OpenClaw：资源挥霍
接着刚才的逻辑，我们来看看硬币的反面。为什么说 OpenClaw 这种在开源圈火爆的框架，一旦接入真实的业务场景就是一颗“定时炸弹”？看他们的 Demo 演示确实极其惊艳，你给一个宏大目标，它能在终端里自动写代码、跑测试、修 Bug。但如果你在后台抓包看过它的通信 Payload，就会发现这种所谓的“全自动”，本质上建立在一种毫无节制的“算力暴力美学”之上。它完全放弃了传统的软件工程设计，把所有的控制流、异常处理和上下文状态，一股脑全扔给了大模型去生扛。我们可以从以下三个技术维度，看看这种架构是如何变成“算力黑洞”的：上下文不做精细化管理
OpenClaw 强依赖于 ReAct（思考-行动-观察）循环。在大模型的每次迭代中，它都会把上一步的输出、调用的系统命令、甚至终端里原封不动的长篇报错日志（比如几百行的 npm 安装警告或编译错误），全量拼接到下一次的 Prompt 里传回去。这意味着什么？在传统的后端开发中，一个循环写崩了顶多吃满单台服务器的 CPU ；但在这种 Agent Loop 里，循环失控燃烧的是真实的金钱。它没有对中间态信息做任何摘要、剪枝或向量化降维，只要任务没结束，上下文就像滚雪球一样越来越大。这种把大模型当“垃圾桶”的粗放用法，直接导致了资源占用的数量级飙升。每次请求都重复计费
很多 C 端用户甚至部分开发人员，对大模型的计费逻辑存在盲区，以为只为新生成的内容买单。但现实是，API 是按每次请求的总体 Token 量（输入+输出）计费的。假设 OpenClaw 初始携带了 5K Token 的系统指令和环境背景，在第 10 次 Loop 时，哪怕它只输出了一句长度为 10 的简单命令，你依然要为之前堆叠到 20K 的上下文历史重新付一次钱。这种级别的成本膨胀曲线，正是大家在使用这类框架时感觉“这玩意儿怎么这么贵”的根本原因。框架本身既没有在代码层面为 C 端用户提供成本熔断机制，也没有在交互上教育用户如何去优化上下文。用“概率”替代“工程”，缺乏业务兜底
在真正的 B 端企业级架构里（比如用 Golang 写的服务端），业务流程的流转、权限的校验、错误的重试，都必须是强类型的、确定性的。而 OpenClaw 恨不得连基础的 API 路由分发都让大模型去猜。一旦遇到模型幻觉，Agent 就会在一个错误的逻辑死胡同里疯狂原地打转，直到把用户的 API 额度耗尽。对于企业来说，这种不可控的架构是无法上生产线的——你不能因为一个 AI 的推理死循环，导致整个业务线资源耗尽。OpenClaw 证明了 LLM 具备接管操作系统的潜力，但它目前的实现方式过于“原始”。它就像一台没有安装油表、排量惊人的 V8 发动机，油门旱地拔葱，跑得确实猛，但绝不是我们现阶段构建企业级智能客服或业务 Agent 的常规武器。我们需要的是精准可控的“混动系统”，而不是这种盲目挥霍算力的性能怪兽。“来财”智能客服踩过的真实血坑
这种开源框架的粗放模式，放在个人开发者电脑上跑跑 Demo 没问题，但一旦放到真实的 B 端生产环境里，简直就是一场灾难。我们在推“来财”智能客服项目时，Token 几乎成了决定项目生死的核心命题。企业级服务不是做慈善，如果一个智能客服每回答一个问题的成本比请个真人还贵，那这个产品在商业逻辑上就是死路一条。在“来财”早期的架构迭代中，我们也曾盲目迷信大力出奇迹，结果踩进了一堆至今想起来都后怕的深坑：无节制上下文堆叠：不仅贵，还变笨了
早期我们没有做严格的上下文路由，试图让 AI 记住用户所有的历史咨询记录。结果发现，当上下文被塞满到几万个 Token 时，生成的质量反而断崖式下跌。大模型在处理这种“超载”信息时，注意力会严重分散，经常在回答“来财”核心业务逻辑时产生严重的幻觉。我们花了最高的单次请求费用，却换回了一个答非所问、甚至胡言乱语的回复。这证明了：在 Agent 开发中，多即是少，臃肿的上下文是精准输出的天敌。
简单工作使用高级模型：一夜干到欠费的惨剧
最离谱的一次教训，出在我们早期的模型选型和流量路由策略上。当时为了图省事，在尝试让 Agent 执行几个非常简单的基础工具调用（比如重启设备等操作）时，我们直接把请求丢给了价格高昂的 Claude 来驱动。 其实在真实的工程落地中，这类简单的意图识别和结构化工具调用，用 DeepSeek 这个级别的模型就完全胜任了，不仅响应极快，而且成本可以说是白菜价。但在当时那种粗放的调用逻辑下，所有流量无脑走 Claude，导致原本微不足道的简单操作，成本直接飙升了 10 倍以上。那个晚上，就因为一个原本 DeepSeek 就能搞定的简单逻辑，Claude 高昂的 Token 单价让 API 账户里的余额直接上演“高台跳水”，一夜之间干到欠费停机。对于 B 端业务来说，这种不分青红皂白“全量上贵族大模型”的做法，带来的财务风险是绝对无法接受的。 上下文不裁剪：响应金钱双重灾难
B 端用户对响应速度（Latency）极其敏感。因为没有做上下文裁剪，随着对话轮次的增加，请求的 Token 量越来越大，大模型的首字响应时间（TTFT）从秒级退化到了几十秒甚至更久。 想象一下，一个急需解决问题的企业客户，面对一个转了半天圈才弹出的回复，用户体验会有多糟糕？而且因为请求体过大，网络传输的稳定性也成了问题，超时报错频发。这种“高费用、低速度”的负反馈循环，直接倒逼我们彻底重构了“来财”的后端架构。企业级 Agent 的出路不在于如何“堆料”，而在于如何“克制”。如果一个架构师不懂得如何裁剪上下文、不懂得如何优化调用路径，那么他构建出的系统，终将会被昂贵的账单和低效的响应速度给拖垮。从堆砌走向精修的 Agent 工程师时代
对于普通 C 端用户来说，搞懂“Token 经济学”的门槛太高了，短期内很难适应这种动辄大几十刀的刺客账单。但对于 B 端来说，未来的出路非常清晰：走向深度定制化的轻量 Agent。这就像当年关系型数据库普及的过程一样——你不能指望随便塞句 SQL 进去系统就能高性能运转，你需要经验老道的 DBA 去建索引、做分表、控制连接池。 未来的 Agent 开发也是如此。市场会急需一批真正懂底层机制的架构师，去优化调用频次、设计多级缓存，甚至去逆向模仿 Claude Code 的通信架构，来构建低成本的后台服务。此外，抛开当前市场的浮躁炒作，AI 的算力成本依然高得令人发指。复杂的推理请求做不到毫秒级响应，单次交互的高昂费用，依然制约整个行业落地。目前框架的迭代速度远超想象，Agent 赛道只会滚滚向前，那些无视成本的项目注定会是一个中间状态。在这个节点，懂成本控制的底层研发，才是接住这波井喷红利的关键。
夜雨聆风
