一次 Claude Coworker 灾难体验：13GB 磁盘、两轮配额、零产出
一次 Claude Coworker 灾难体验：13GB 磁盘、两轮配额、零产出
wwxdsg
我从没想过，一个 Agent 可以同时做到三件事：什么都没产出，占满我的硬盘，还烧完了我的配额
五天前我看到 Claude Desktop 上多了一个叫 Coworker 的功能，很兴奋。它在实验室（Labs）标签下，意味着是”研究预览”。作为一个做 Agent 开发的人，我对各种 agent 形态天然好奇，第一时间就试了。
两天后，C 盘红了。
我以为是我装了什么东西——最近没装过。然后我发现多了整整 13GB 的 Claude 应用数据。同一天，我发现我的 Claude Pro 日配额被全部烧光，什么都没产出来。
我当时真的是一脸问号。我知道 agent 会吃 token，但我没想到一个课程报告任务能在背后吃掉这么多资源。
我看到了什么
先说我当时在做什么。我让 Coworker 帮我写一份大数据系统课程设计的报告，上传了项目结构文件和 README，选了一个工作文件夹。很简单的任务。
过了一段时间，我发现 C 盘剩余空间从正常水平掉到了不到 2GB。我质问 Coworker「你做项目怎么吃了 C 盘那么大的空间」，然后它继续自顾自折腾，最后报了一个错：
You’ve hit your session limit · resets 6:50am
我打开 C:\Users\...\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ 一看：
vm_bundles/claudevm.bundle— 12GBCache/+Code Cache/+GPUCache/— 几百 MBclaude-code-vm/+claude-code/— 几百 MBlocal-agent-mode-sessions/— 会话残留
加起来 13GB。一个课程报告，13GB。
然后我去翻会话日志。它用了 claude-opus-4-6——最贵的模型。一共 156 轮 assistant 回复。
156 轮。为一个课程报告。
到底发生了什么
我从会话目录里挖出了 audit.jsonl 和 local_*.json，完整还原了时间线。
它一启动就做了几件事：创建了 5 个 Task，读了项目文件，然后——开始不停地重试一个叫 bash 的工具调用。
“Workspace still starting. The isolated Linux environment is booting in the background (usually 10-30 seconds). Try again shortly.”
这条错误在日志里出现了 82 次。
82 次。每次重试，Coworker 都把整个对话上下文重新发给 Claude Opus 4.6。而那个 system prompt 有多长？我把原始内容提出来了，包含了 Anthropic 全部产品线介绍、行为规范、tone 指引、artifacts 渲染规则、文件处理规则、65 个 skill 定义——以及一种令人窒息的”系统提示词膨胀”。
每一次重试的成本 = 巨型 system prompt + 所有历史消息 + 工具调用结果 + 模型推理输出。乘以 82。
更离谱的是，它在 17:07 就打满了第一轮 5 小时配额——从会话开始算，只过了 15 分钟。等到 17:51 重置后，它继续工作，然后在 18:25 第二次烧光。
一个会话，两轮配额。为零产出付费。
作为一个做 Agent 的人，我看到的是什么
这不是模型的问题。Opus 4.6 只是做了一个 agent loop 让它做的事——收到错误，重试。重试。重试。被拒了还要重试。
问题是整个 agent 系统设计上的缺陷，而且这些缺陷对我来说太眼熟了：
1. 没有熔断
这是最致命的问题。同一个工具调用，同一个错误，重试 82 次。任何一个生产级系统都会在连续 N 次失败后停止并向上汇报，但 Coworker 没有。它不是缺少推理能力，而是缺少一个对失败模式的基础检测。
作为对比，如果我在自己写的 agent loop 里发现同类型错误连续出现 5 次，我会立刻打断循环、记录异常、提示用户。这不是因为我的模型更聪明，而是因为我给 loop 加了护栏。
2. 用最贵的模型做最机械的决策
判断「上次 bash 调用失败了，我应该再试一次」这件事——不需要 Opus。一个 if-else 就够了。如果用 Haiku、甚至一个简单的状态机来处理重试逻辑，token 消耗能差出几个数量级。但 Coworker 把所有决策都交给 Opus，包括那些根本不需要「推理」的步骤。
3. 上下文膨胀失控
那个 65 个 skill 全部预加载到 system prompt 里。用户要写一个课程报告，不需要知道怎么发营销邮件、做 SEO 审计、设计品牌评审。把和任务无关的 skill 定义按需加载而不是预加载，是最基本的优化。但设计上选择了「全部塞进去」。
这不是 prompt engineering 的问题，是架构选择的问题。
4. Loop 模式缺乏目标锚定
Loop 模式的设计意图是让 agent 能「自主推进工作」——做完一步，检查结果，决定下一步。但实际执行中，它没有一个有效机制来判断「我是不是还在朝目标前进」。
它创建了 5 个 Task，然后因为沙箱起不来，全部卡住。但它没有把「沙箱不可用」这个信息用来重新规划方案（比如不用沙箱，用本地文件工具），而是原地重试。目标锚定不够强。
5. 资源泄漏
那个 12GB 的 claudevm.bundle 是一个 VM 镜像。它被下载下来之后，即便 VM 启动失败了，也没有被清理。用户永远不知道这个文件存在，系统也不会自动回收。
这是一个很经典的 agent 后处理缺失：创建了资源，却没有生命周期管理，没有清理策略，也没有失败回滚。
这不是”技术预览”的借口
我理解 Coworker 是 Labs 下的「研究预览」。我也做实验性功能，我知道 preview 意味着不完美。
但这里有些问题不是功能不完善导致的，而是架构上缺少对 agent 常见失败模式的防御：
- 把重试逻辑交给模型而不是框架——这不是 feature，是 bug
- 不检查操作是否有效就反复执行——这也不是 preview 能解释的
- 无上限消耗用户配额——这更不能接受
我的观点是：agent 系统的基础护栏不应该比功能本身更晚交付。 没护栏就上线，等于把一艘没有水密舱的船开进了 open sea。你觉得水会从哪里进来？当然是所有地方。
总结
这次经历的荒诞之处在于，它用一种极端高效的方式同时失败：
- 磁盘占用？13GB 全在
- Token 配额？两轮烧光
- 实际产出？几个用不上的 SVG 和一段没跑通的 Python
1.5 小时内，我什么都没得到，但失去了一切：空间和额度。
作为一个做 agent 的人，我其实不生气于这个功能做得不好——我生气的是，我看到的问题全是我每天在防范的东西。熔断、模型分层、上下文精简、资源回收、目标检查——这些不是 rocket science，这些就是 agent engineering 的基本功。
如果一个 agent 产品在最贵的模型上、在用户的生产环境里、没有任何护栏地运行，那这不仅仅是一个 bad experience。这是一个 design failure。
后记：我把 13GB 数据清掉了。Coworker 功能我短期内不会再碰。但我感谢这次经历——它让我更确信，agent 工程真正的难点不是让模型变聪明，而是在模型变蠢的时候，你还有一道防线。
