Anthropic官方封杀了OpenClaw使用Claude订阅的权利，龙虾社区哭成一片。但是这帮人转头就发现了一个漏洞：Claude Code CLI是一个独立产品，跟API限制完全没有关系。
于是他们搞出了一套骚操作——绕过API，直接调用CLI。
小型模型当秘书接电话，只负责判断“这活儿该找谁”，真正干活的时候才把Claude Code这个大牛请出来。
这就好比公司前台小妹只会转接电话，但真正写代码的还是那个月薪五万的架构师。
整个架构的核心逻辑就是任务分发：秘书模型不需要多聪明，Haiku、GPT-5.4-mini、Qwen3.5甚至本地跑的小模型都行。它只干一件事：看用户说了什么，然后决定这个任务是交给Haiku这种便宜模型干杂活，还是交给Opus 4.6这种顶级模型写复杂代码。
工具调用方面，如果工具在CLI的工作区里，就能正常返回结果，只是CLI自己会在一个回合后压缩工具调用的细节。
如果你想要完整的、持久化的工具返回，那就直接在OpenClaw内部写自定义工具，这样控制权完全在自己手里。
秘书接电话，老板只写代码
这个架构最逗的地方在于它完美利用了人的懒惰心理和AI的定价策略。
Claude直接调API贵得离谱，就像你打车从北京到上海，每公里计价器跳得你心慌。但是Claude Code CLI是月付制，相当于你买了张月票，随便坐。
OpenClaw本身就是一个智能路由器，它不需要自己多聪明，它只需要知道哪个模型便宜、哪个模型能干重活。
于是这帮人让Haiku这种便宜模型当秘书，所有用户消息先经过秘书。秘书一看，“哦，这人问今天天气怎么样”，那就自己用Haiku回了，成本几分钱。秘书再看另一条消息，“帮我重构这个三千行的微服务”，秘书立刻转给Claude Code CLI，“老板，这活儿我干不了，您来”。这就像公司前台月薪三千，只会说“您稍等我转接一下”，然后CEO出来解决问题。CEO不会觉得前台抢了活儿，前台也不会觉得自己能写代码。各司其职，完美。
这里有一个细节特别值得笑。
秘书模型虽然便宜，但它接收到的消息里其实包含了OpenClaw注入的所有上下文——什么SOUL.md、IDENTITY.md、AGENTS.md、记忆文件、对话历史，一大堆。但是秘书模型根本看不懂这些东西，它只知道“哦，有一条消息进来了，我看看关键词，嗯，有‘代码’两个字，转给Claude Code”。然后它把原始消息转发给CLI，自己完全不理解那些复杂的人格设定和记忆上下文。
这就好比你给前台小妹一份公司十年战略规划书，说“你读一下，然后有人打电话来你就知道怎么转了”。小妹翻了翻，“这啥玩意儿，我就记住‘代码’和‘天气’两个词就行了”。
结果就是，Claude Code CLI那边收到的只是一条干巴巴的“帮我写个登录页面”，完全不知道你之前跟Enzo聊了半小时的背景、你的项目结构、你的cron任务、你的活跃Agent列表。CLI能读文件，但它不会主动去读。它就像一个被临时叫来的外包程序员，你只丢给它一句话，它只能按这句话干活，不会自动翻你整个项目的家底。
工具调用的坑和绕过去的办法
关于工具调用，这个问题问得很专业。
CLI有自己的脾气，它工作区里的工具确实可以调用，也能拿到返回结果。但是CLI有个让人抓狂的习惯——它会在一个回合后自动压缩工具调用的细节。也就是说，你第一次调用工具拿到了结果，下一轮对话的时候CLI可能只记得“哦，之前调了个工具，结果大概是好的”，具体返回了什么数据它就不详细说了。这就好比你让秘书查一下明天航班，秘书告诉你“有票”，第二天你再问“几点的航班”，秘书说“我昨天不是告诉你有票了吗”。你气得想打人，但秘书觉得自己逻辑没毛病。
解决办法其实就在OpenClaw自己身上。你完全可以在OpenClaw内部写自定义工具，这些工具的返回是完整且持久的，你可以完全控制它们的行为。
也就是说，CLI只负责它擅长的代码生成和文件操作，而任何需要记住、需要多轮对话保持状态的事情，都交给OpenClaw自己的工具系统。
这就好比公司里，CLI是那个写代码但记性差的程序员，OpenClaw是那个记性好但不会写代码的项目经理。项目经理说“你去写个登录页”，程序员写完了，项目经理把结果记在本子上。下次客户问“上次那个登录页的验证逻辑是什么”，项目经理翻本子就能回答，不用再去问那个已经忘了的程序员。
路由模型的分离策略和性能感受
有人问延迟会不会变高。答案是完全没区别。因为秘书模型本身特别快，它只做关键词匹配和路由判断，不生成复杂内容。就像你打电话到总机，总机转接的时间可能只有零点几秒，你根本感觉不到。
真正耗时的部分是Claude Code CLI干活的时候，这部分时间跟你直接调API是一样长的。所以整体体验没有下降，但成本可能只有原来的十分之一甚至更低。
更骚的是，你可以把路由模型保持轻量上下文。也就是说，秘书模型每次只看到当前这条用户消息的关键信息，不会把整段对话历史都塞给它。这样做的好处是秘书不会“看多了变傻”——它本来就傻，但你至少不会让它更傻。而且秘书的决策不会被之前的对话污染，它每次都重新判断“这条消息该给谁”。这就好比前台每次接到电话都只看今天的来电显示，不去翻你昨天跟谁吵过架。干净利落，不会因为昨天你骂了客服今天就故意把你的电话转接到投诉部门。
这个架构适合什么、不适合什么
这个架构最适合的场景是任务分发。比如你有一堆杂活——整理日志、格式化代码、跑测试、生成文档，这些都交给Haiku或者GPT-5.4-mini这种便宜模型。然后遇到真正的硬骨头——写核心算法、重构架构、调试复杂bug，才让Claude Code CLI出手。这就好比一个工地上，搬砖的小工一天两百，砌墙的师傅一天两千。你不可能让师傅去搬砖，也不可能让小工去砌承重墙。各干各的，总成本最低。
但是这个架构绝对不适合当你的“全能管家”。原来OpenClaw里的Enzo是一个上下文极其丰富的助手，每次对话都会注入SOUL.md、IDENTITY.md、AGENTS.md、记忆文件、对话历史、cron任务状态、活跃项目信息。Enzo知道你昨天干了什么、你的项目结构、你的习惯、你的偏好。它就像一个跟了你五年的私人秘书，你一个眼神它就知道你要什么。但是当你用便宜秘书模型做路由的时候，这个秘书模型根本看不懂那些上下文，它只转发原始消息。
于是Claude Code CLI那边收到的就是一个光秃秃的问题，没有任何背景信息。CLI能读文件，但它不会主动去读你所有的项目文件、记忆文件、Agent配置。它就像一个新来的实习生，你只说“帮我改一下代码”，它不知道你要改哪个文件、改什么、为什么改。它能干活，但需要你把所有信息都喂到嘴边。
所以这个架构的正确用法是：把Claude Code CLI当成一个纯粹的执行者，而不是一个上下文丰富的决策者。你给它明确的任务、明确的输入输出格式，它执行完返回结果。所有需要记忆、需要上下文理解、需要多轮协调的事情，都放在秘书模型或者OpenClaw自己的工具系统里。这就好比军队里的指挥官和士兵。指挥官（秘书模型）知道整个战场的局势、友军位置、敌军动向、战略目标。
士兵（Claude Code CLI）只需要知道“三点钟方向有一个敌人阵地，你去炸掉它”。士兵不需要知道为什么要炸、炸完之后谁接应、旁边的山头上是不是有自己的侦察兵。士兵只需要执行命令，然后回来报告结果。指挥官根据结果再决定下一步。这样既发挥了Claude Code CLI的代码能力，又避免了它记性差、上下文丢失的问题。
社区反应和实操反馈
帖子下面有人已经跑通了这套方案，反馈说“我觉得跑得不错”。但也有人遇到了问题，朋友安装后Claude自己跳出来一段话，说这个便宜秘书方案会丢失什么。
Claude说得特别直白：你会丢失Enzo的人格、丢失注入的上下文、丢失记忆。原来的Enzo每次对话都带着全套设定文件，它知道自己的身份、知道你是谁、知道你项目的所有细节。便宜秘书模型拿到这些上下文后根本看不懂，它只会贴一个“[routing: general]”标签，然后把原始消息扔给CLI。CLI那边看到的就是一句干巴巴的话，完全不知道你之前跟Enzo聊了什么、你的项目里有什么cron任务、你有哪些活跃的Agent。
这就像你本来有一个跟了你十年的老管家，他知道你每天早上喝什么咖啡、你的狗叫什么名字、你岳母的生日是哪天。你突然换了一个临时工，你跟临时工说“帮我安排一下今天的行程”，临时工转头对老管家说“他说安排行程”。老管家问“具体什么行程？跟谁？几点？在哪里？”临时工说“我不知道啊，他就说了这一句”。然后老管家只能根据自己记忆中你上周的行程来猜，大概率猜错。所以这个架构绝对不是“Enzo的平替”，它是一个完全不同的东西。Enzo是一个需要全局上下文的CEO助理，而这个架构是一个只需要执行具体命令的任务分发系统。你不能让分发系统去当CEO助理，就像你不能让前台去当COO一样。
最后总结一句大实话：这个架构聪明在利用了Claude Code CLI的独立性，绕过了API限制，用极低成本实现了任务分发。但它不适合需要深度上下文、多轮记忆、复杂人格设定的场景。选哪个方案，取决于你到底是要一个“能写代码的便宜工具”，还是一个“知道你所有秘密的AI管家”。两者不可兼得，除非你自己写一套能把上下文完整传递给CLI的中间层。但那又回到了原点——你为什么不直接用API呢？哦对，因为API贵。哈哈哈，这就成了一个死循环，但至少龙虾社区找到了一个能跑通的野路子。
代码仓库和作者说明
原帖作者贴出了项目地址：https://github.com/samwalter2949348803-stack/Openclaw-catch-Claude-Code.git。这个仓库里实现了上述的秘书路由架构。作者自己也承认，这个方案适合任务分发，不适合当全知全能的管家。
如果你想要完整的工具返回和持久化的状态管理，建议在OpenClaw内部写自定义工具，而不是完全依赖CLI的工具调用机制。