文章
别被层出不穷的 AI 工具困住：看懂以后，其实都差不多
之前我看到量子位智库发了一张榜单，统计的是 8 月国内“龙虾类”桌面智能体的月访问量，WorkBuddy 排在第一。
我顺手把图发给弟弟，说：“有时间可以研究一下腾讯的 WorkBuddy，现在它在 AI 办公领域挺值得关注。”
他回了个 👌。
本来聊到这里也就结束了，但我又补了一句：“它也是一种智能体，跟 Claude Code、Codex 这些有点像。”说完以后，我自己又觉得不够准确，于是又补了一句：
“更准确一点，应该聊聊 Harness。”
然后我给弟弟出了一个题：
Agent = ？ + ？
我让他先去看我之前写的一篇文章，再回来回答。
过了一会儿，他发来一句：
Agent = Model（大模型）+ Harness（相当于遥控器）。
大方向没错，但看到“遥控器”三个字，我又觉得，这个比喻有一点感觉，却不够准确。
于是，我们就从 WorkBuddy，一路聊到了 Model、Harness、Claude Code、GLM、CC Switch。
聊到后面，我突然意识到，这次聊天真正值得记录的，其实不是“这几个工具怎么搭”，而是：
为什么它们可以这样搭。
先搞清楚：你每天到底在用什么
现在 AI 工具越来越多。
Claude Code、Codex、GLM、DeepSeek、WorkBuddy、MiniMax Code、CC Switch……
名字越来越多，更新也越来越快。很多人的使用方式其实很直接：别人说这个好，就装这个；看到一个性价比方案，就照着配；找到教程以后，复制命令、填 API Key，跑起来就算完成。
这当然没有问题。工具本来就是拿来用的。
但我越来越觉得，如果一直停留在“别人怎么配，我就怎么配”这一层，会有一个很明显的问题：你会用，却不知道自己为什么这样用。
一旦模型换了、工具变了、原来的方案失效了，你还是只能重新去找下一篇教程。
所以这次我没有直接告诉弟弟“你就这样配”，而是一直问他：
哪些是 Model？哪些是 Harness？
你现在用的 Model 和 Harness 分别是什么？
GLM、Claude Code、CC Switch 又分别处在哪一层？
我想让他先把这些看起来混在一起的名字拆开。
Model 和 Harness，到底是什么关系
Model 比较容易理解。
像 GPT、Claude、DeepSeek、GLM，本质上都是大模型。你可以把 Model 理解成“脑力”，它负责理解、推理和生成。
但只有模型本身还不够。
比如在一个代码项目里，模型并不会天然知道代码仓库在哪里、应该先读哪个文件、能不能执行 Shell、什么时候需要跑测试、哪些文件可以改、失败以后要不要继续重试。
这些事情，需要另外一层系统来组织。
这就是 Harness。
如果一定要用一个容易理解的说法，我更愿意把它理解成：
Model 像大脑，Harness 则是一整套让这个大脑能够进入真实工作环境的执行系统。
弟弟一开始把 Harness 比喻成“遥控器”。我说，这个比喻不算错，但不完整。
遥控器更像是“给指令”，而 Harness 做的事情更多。它不仅要让模型知道“接下来干什么”，还要规定模型可以调用哪些工具、能访问什么、怎么执行、什么时候停止。
换句话说，它既在释放模型能力，也在约束模型能力。
这也是为什么一个 Agent 并不是“给大模型更多自由”这么简单。真正可靠的 Agent，反而需要很多流程、工具和权限边界。
Claude Code 不是 Claude
这也是最容易混淆的一点。
Claude 是模型，但 Claude Code 不是模型。
Claude Code 更接近一套 Coding Harness。它可以让模型进入真实代码环境里，读取项目、修改文件、执行命令、跑测试，再根据结果继续推进任务。
所以更准确的理解应该是：
Claude 是 Model，Claude Code 是承载和调度模型工作的 Harness。
把这两层拆开以后，很多事情就一下子容易理解了。
比如，为什么 Claude Code 可以接 GLM？
因为 Harness 和 Model 本来就不是同一层。
只要接口兼容，理论上就可以保留 Claude Code 这套成熟的 Coding 工作流，同时把底层模型换成 GLM。
也就是说，你保留的是“怎么工作”，替换的是“谁来思考”。
这时候我问弟弟：
“那你现在主要用的 Model 和 Harness 是什么？”
他说：
“Zhipu GLM。”
“CC Switch。”
我回他：
“你答对了一半。”
后来他自己重新查了一遍，才把关系理顺：
GLM 是 Model。 >Claude Code 才是 Harness。
于是下一个问题自然就来了：
那 CC Switch 又是什么？
CC Switch 为什么会出现
如果只从表面看，CC Switch 很简单：切模型、换 Provider、管理配置，不用自己每次去改一堆环境变量和 API Key。
但如果已经理解了 Model 和 Harness，再看 CC Switch，它的价值就更清楚了。
我当时跟弟弟说，可以先把它近似理解成 Harness 和不同模型服务之间的配置、切换和路由层。
这个说法不是严格定义，因为现在的 CC Switch 已经不只是一个“模型切换器”，还涉及 Provider、MCP、Skills、Prompt、会话和用量等管理。
但对于理解它为什么存在，这个模型已经够用了。
现实中，我们经常会遇到这样的需求：喜欢 Claude Code 这套工作方式，但并不希望所有任务永远只用一个模型。有时候看重能力，有时候看重成本，有时候看重速度，还有时候只是某个服务暂时不稳定。
如果每次切换都靠手动改配置，很快就会变得很麻烦。
所以 CC Switch 的价值，本质上是在降低不同组合之间的切换成本。
到这里，Claude Code、GLM、CC Switch 三者之间的关系就比较清楚了：
Claude Code 负责工作流，GLM 提供模型能力，CC Switch 负责更方便地管理不同模型和服务的接入。
为什么 Claude Code + CC Switch + GLM 会成为一种平衡方案
这也是我和弟弟聊到后面真正想明白的一件事。
很多人看到这个组合，得到的结论可能只是：
“这套方案挺好用，性价比也不错。”
但如果继续问一句“为什么”，就会发现它其实是在几个因素之间做平衡。
Claude Code 提供的是成熟的 Coding Harness；GLM 提供国产模型能力，以及对国内用户更友好的服务可用性和成本；CC Switch 则降低了模型和 Provider 切换的配置成本。
所以它不是三个工具随便堆在一起，而是在工作流成熟度、模型能力、成本、可访问性、可替换性和配置便利性之间找了一个平衡。
真正重要的是，当你理解了这套结构以后，就不会再把“Claude Code + CC Switch + GLM”当成一个必须照抄的固定配方。
今天可以这样组合，明天完全可能换。
新的 Harness 出来了，可以换。
新的国产模型能力更强了，也可以换。
中间的配置方式变了，同样可以调整。
因为你已经知道，每一层分别是在解决什么问题。
这也是为什么我让弟弟去看 WorkBuddy
最开始，其实只是因为那张 WorkBuddy 的榜单。
WorkBuddy 和 Claude Code 不是完全同一种产品。Claude Code 更偏 Coding 场景，而 WorkBuddy 更像一个已经帮用户封装好的桌面 Agent 工作台。
你不需要一开始就理解 Provider、Harness、MCP、Skills，也不用自己去配置很多东西，只需要告诉它你想做什么，比如分析文件、整理资料、做 PPT，它会尽量自己规划和执行。
这条路线的优势很直接：
把复杂度藏起来，让用户开箱即用。
Claude Code + GLM + CC Switch 这条路线则相反一点，它把一部分复杂度暴露出来。你愿意多理解一点，也多配置一点，换来更高的自由度和可控性。
我并不觉得哪一种方式更高级。
对于大多数普通任务，开箱即用往往反而是最好的选择。工具本来就是为了提高效率，不是为了证明自己会折腾。
但如果你想在 AI 上走得更深一点，那么理解后一种方式背后的结构，会带来一个额外价值：
你开始看到的不再只是“产品”，而是“零件”和“层次”。
我真正想告诉弟弟的，不是怎么配置
其实这套东西，如果只是想跑起来，并不难。
找个教程，复制几条命令，填一下 Key，装好 CC Switch，很快就能用。
以后 AI 再发展一段时间，甚至可能连这些配置都不需要自己做。你直接告诉 AI：
“帮我把 Claude Code 配好，接上 GLM，再把 Provider 管理好。”
它自己可能就做完了。
所以，当“会配置”越来越容易以后，真正值钱的是什么？
我觉得不是背更多工具名，而是理解这些工具为什么会这样组合。
为什么 GLM 是 Model？
为什么 Claude Code 是 Harness？
为什么 Model 和 Harness 可以解耦？
为什么中间还需要 CC Switch？
为什么 WorkBuddy 又选择把这些东西尽量封装起来？
这些问题看起来没有教程那么直接，但它们决定了你以后遇到新工具时，是继续等别人告诉你怎么配，还是能够自己判断。
知其然，更要知其所以然
我最后跟弟弟说，大意是：
Claude Code + CC Switch + GLM，是一个在多个因素之间取平衡的综合方案。你知道怎么装、怎么用，这是“知其然”。
但还应该多问一句：
为什么要这么组合？
当你理解了为什么，就不会永远依赖别人给你的“最佳方案”。
下一次新的模型出来，新的 Harness 出来，新的工具出来，你可以自己判断它应该放在哪一层，解决什么问题，值不值得替换。
甚至，你可能会组合出一个更适合自己的方案。
我觉得创新很多时候并不是“从零发明一个东西”，而是先把已有的东西拆开看懂，再重新组合。
别人看到的是 Claude Code，你看到的是 Harness。
别人看到的是 GLM，你看到的是 Model。
别人看到的是 CC Switch，你看到的是配置和路由层。
当你开始这样看问题以后，自然就会继续想：
能不能根据任务自动选择不同模型？
简单任务能不能用便宜模型，复杂任务再切强模型？
自己的业务接口能不能接进 Agent？
重复工作能不能沉淀成 Skill？
不同 Agent 能不能分工？
很多新想法，其实都是从“先拆开看懂”开始的。
所以回头再看那天聊到的 WorkBuddy、Claude Code、GLM、CC Switch，具体是哪几个工具，反而没有那么重要。
半年以后，工具可能又换了一轮。
但有一句话，我希望弟弟能记住：
知其然，也要知其所以然。
以前我总觉得，这句话有点像老师教育学生。
现在反而越来越觉得，它很适合 AI 时代。
因为当答案越来越容易获得，代码越来越容易生成，工具越来越容易使用以后，真正能拉开差距的，可能不是谁装了更多工具，而是谁愿意再多问一句：
为什么？
而很多真正有意思的创新，往往就是从这个“为什么”开始的。