我最近开始用智谱的 GLM 5.2之后，就把 Cloud Code 升级到了最新版。

升级到最新版以后，我发现如果用 GLM，实际上它还是不会触发自动压缩上下文的功能。

因为我最近也在并行使用 Claude Sonnet，在 Claude 里同时用这两个模型时，对比非常明显：
1. Claude Sonnet：右下角会有一个“Auto Compact”的提示，显示还有多少额度会自动压缩。
2. 其他模型（比如 GLM）：右下角只会直接提示“... Left”，显示剩余的 Context 额度和百分比，这种情况下就只能自己手动去触发压缩。

之前我也琢磨过，这种感觉就跟手动挡和自动挡的车似的。用手动挡（手动压缩）时，你得稍微留心一下，去考虑在工作任务和对话轮次的哪个节点开始压缩，才能让模型处于最佳状态。

这其实是个取舍问题。你可能会问，为啥不直接一直用 Claude 模型，不就万事大吉了吗？

我大概出于两个考虑：
1. 公司的 Token 虽然是免费给员工用，而且现在基本上不限量，但我担心的是，如果我只习惯在这些国际大模型上把事情搞定，那未来万一公司不提供 Token 了，或者我不在公司了，我自己用 AI 做事情的时候该怎么办？我必须得有一个在国内可以稳妥使用的模型作为后备。
2. 确实如我之前所说，GLM 已经比较符合我的工作流习惯，和我的工作流契合得挺好了，所以我才一直在坚持使用。

最近零散的想法挺多的，想到哪儿就记到哪儿吧。

今天在 Claude Code 里使用 plan mode，比之前用 plan mode 的产出好多了。以前是用不用 plan mode 结果都差不多，现在是它先用子 agent 去知识库先收集信息，再做计划，少量对我提问后，开始产出结果。最终调个一两版就完成了。
思考了一下原因应该是自己沉淀了足够多的知识库内容，以及不断精炼的 AI rules，每次出现问题增加的 hooks，迭代了十几版的 skill。

因为用的是 token plan 或者是公司的 token，对 token 的 ROI （投资回报率）毫不敏感。

这个毛病必须改掉。

要不以后花自己的 token 的时候，要么做不出来任何东西（token plan 被卡 5 小时用量），要么做出来东西亏钱（生成的内容比 token 还要贵，或是别人用起来成本高，时长上无竞争力）。

起因是自己正在看《Claude Code 实战》，读到其中 skill 的 description 预算机制时被点醒了。

我自己的 skill 都是 Claude Code 自己写的，实际上我不太关心它写的怎么样，我更在乎结果。

但是实际上每个 skill 中有多少无效的字符，我其实没有看过。

这么看下来，实际上有两个方向上现在做的不够好。
一个是不做约束，不断地在创作的过程中，或者是使用的过程中，额外消耗 token。
另外一种就约束过死，明确的告诉他要做什么，纯粹从一个创造工具沦陷为一个执行工具。

我现在有点理解为什么每一个高频的细分场景最好都有一个 Agent 了。

因为这种 Agent 可以用 Hooks（钩子）去做更强的校验。但如果不分场景只用一个 Agent 的话，逻辑就没法写进钩子里，只能存到 Memory（记忆）里。

而 Memory 实际上又不是每次都能强行召回的，就有可能会出现一些偏差。

自从换了 GLM-5.2 之后，重新把 Claude Code 更新到最新版本。

之前的问题是，使用 5.1 的时候，始终无法启动自动压缩，直到 API 报错，说 context 超过模型限制。

我以为我换了 5.2 以后，这个问题就会解决，不知道哪里来的自信升到了 2.1.19x。
用着用着发现，context 到了 100%之后还是不会自动压缩，但是也没有出现 API 因 context 爆了返回错误的情况。

我战战兢兢提问：
为什么没有自动压缩？

这个是 Claude Code 的 harness 决定的。

那我要不要压缩？
建议你一会儿压缩，否则我们本轮对话会丢失很多东西。

我觉得有道理，以前经常它跑着跑着就自动压缩了，虽然说不上结果偏差，但也觉得节奏不好。

我觉得我应该好好看看 Claude Code 的文档，看看后续版本的 harness 到底是怎么设计的。

不行，已经把新做的 3 个 汉堡包 skills 全删掉了。在实际使用的过程中，发现不但时间没有省下来，结果还经常出错。

用 Codex 分析了用这个方法做的几个项目，它指出因为我要为了效果不断的调整和修改，这种情况下，“施工单”里并不一定会描述很多的细节，而不同模型的推断能力不同，弱模型这些细节是推断不出来的。因此结果才总是不理想。

那么这个应该怎么办呢？反思了一下，至少应该还是从常用模型出发（贵的模型太贵了），通过不断的纠错（加入 memroy 反馈）和沉淀规则（建立 skills）来让它逐渐掌握我的标准。
如果是我本身没想清楚，只是看下效果的话，其实任何模型都没啥用，使用施工单反而增加了更多的成本。

总之，这个想法失败了

如果你用 Claude Code 做工具，但是用的是国产模型的话，千万不要把版本号升到 2.1.144 以上。

我发现升级超过这个版本号以后，模型自动压缩会出现问题。我想了好多种办法，可能都不太好解决，或者说用起来不顺。

我现在已经把 Claude Code 的版本号降回来了。

最近一直在琢磨怎么把手里的工具变成 AI 员工，最近终于发现这个事情的瓶颈在哪里。

我希望的是，AI 在吸收了我所有的知识以后，能够自主地直接交付结果，而不用中途打断我，问任何东西。

但在做这种尝试时，我发现自己会受到模型的限制。比如我在用国产模型（比如 GML 5.1）的时候——这属于上一批国产模型，最新的一批我还没用——在这一批里，我觉得它已经比较能理解我的业务场景，交付的结果也相对满意。

直到昨天我发现，当它在对一件事做微调时，由于调整过度，把之前正确的东西全调没了。我觉得这不单纯是规则的问题，而是它的逻辑理解有瓶颈或者说上限。

针对这个问题，我想了个解法。其实最简单的办法就是换国外那些昂贵的高级模型，但像我们这种体量的公司，对成本还是比较敏感的。

所以我折中想了一个“汉堡包”式的做法：
1. 底层规划：在开始阶段，先用高级模型做规划。我在这里引入了一个“施工单”的概念，让高级模型先创建一个标准施工单。
2. 中层执行：在执行阶段，换成国产模型或者一些响应更快的模型，去执行这个施工单。
3. 顶层验收：在最后验收结果时，再调用高级模型进行把关。

目前想到了这么一个折中的法子，但不知道实际效果如何。我这两天会测试一下，过两天无论有没有效果，我都发出来分享给大家。

同时也想问问大家，在考虑费用限制的前提下，有没有什么更好的办法来解决这种逻辑瓶颈的问题？

mark