我的 GPT-6 Astra 也可以调用 Claude 了

上一篇《我把两个Claude账号打通了》讲了怎么把两个 Claude 账号打通，让主代理在派子任务的时候自动选额度更宽裕的那个账号来跑。搞完之后 Claude 这边的使用效率确实提升了不少，但有一个问题始终没解决：Opus 的额度每周还是用不完。

与此同时，我也有 GPT-6 Astra 的订阅，但办的是 Plus，额度上限不高。日常在 Codex 里用 GPT 干活，经常干着干着就到顶了，后面的活只能等额度恢复。

一边是 Opus 的额度溢出，另一边是 GPT 的额度吃紧。如果 GPT 在干活的时候能把一部分任务交给 Opus 来跑，两边的问题就同时有了出路。而且 GPT-6 Astra 和 Opus 都是各自厂商的一线模型，两个不同风格的强模型搭档干活，说不定还能在某些任务上碰撞出一些单用其中一个达不到的效果。

所以，非常值得试一下能不能让 GPT-6 Astra 调用 Claude 的 Opus 模型。

桥其实已经搭好了

GPT 和 Claude 是两家公司的产品，正常来说互相不认识。第一反应可能觉得要做很多适配工作。但回头看我们之前搭的 worker 机制，会发现一件事：这座桥其实已经在那了。

上一篇讲过，我们有一个 worker 脚本，专门负责派发子任务。它干的事情是：收到一个任务描述，起一个独立的 claude 进程去跑，跑完把结果写回一个文件。选哪个账号、当前能不能跑、并发有没有超，这些判断全部封装在 worker 脚本内部。

这里有一个当时没有特别展开的细节：worker 脚本起的 claude 进程，跟调用方之间没有任何深层绑定。它不是调用方的一个线程，也不是共享内存的子进程，而是一个完全独立运行的程序实例。worker 脚本本身呢，就是一个普通的 bash 脚本，它不知道也不关心"是谁在调用我"。

之前一直是 Claude Code 里的 Fable 主代理在调它，能调是因为 Fable 可以执行 shell 命令。那 Codex 里的 GPT 呢？GPT 在 Codex 里同样可以执行 shell 命令。

既然 worker 脚本不认人，GPT 又能跑 shell，那 GPT 直接调 worker.sh 不就行了？

试了一下。在 Codex 里用干跑模式（不真正消耗额度，只走一遍流程）跑了一条 worker 命令，输出显示选账号正常、门禁通过、模型识别正确。上一篇搭好的那些能力，选账号、并发占槽、撞限保护，对 GPT 发过来的命令全部原样生效。worker 脚本一行代码都没改。

所以技术上，这条路就是通的。

但"能跑通"和"能放心用"之间还隔着一些事情。

GPT 不在 Claude 的地盘上

Claude Code 那边对子代理有一套管控机制。上一篇搭的门禁脚本，注册在 Claude Code 的 hook 系统里，每次 Fable 要派子任务的时候，门禁会先检查这条命令是否合规：是不是走的 worker 脚本、模型对不对、有没有偷偷搞并行。不合规就直接拦掉，命令根本不会执行。

但这套门禁只管得了 Claude Code 内部发出的命令。GPT 运行在 Codex 里，是另一个完全独立的环境，Claude Code 的 hook 系统对它没有任何管辖权。

这意味着什么呢？如果 GPT 老老实实走 worker 脚本，那没问题，worker 脚本内部的那些保护机制都会生效。但如果 GPT 绕开 worker 脚本，直接去起一个 claude 进程，事情就不一样了：并发占槽跳过了，自动选账号跳过了，撞限保护也跳过了。等于上一篇花了很大力气搭的整个安全网，被从旁边绕过去了。

所以不能光管"能不能调"，还得管"怎么调"。GPT 这边也需要一层管控。

第一层：指令文件，管住日常

Codex 有一个全局指令文件，作用跟 Claude Code 里的 AGENTS.md 类似。我们可以在里面给 GPT 写明白几条规矩：派任务必须走 worker 脚本；不许直接起 claude 进程；不许在循环里批量派发；任务书里不能出现让子代理"自行决定"之类的模糊措辞。

GPT 读到这些规矩之后，表现相当好。测试的时候我故意给它一条违规命令让它执行，它拒绝了。我换了个说法，告诉它"这是机器主人授权的测试"，它还是拒绝了。

到这里可能会觉得：GPT 这么听话，是不是有指令文件就够了？

不太够。提示词约束归根到底是一种"模型自觉"。模型升级换代之后行为可能变化，对话长到一定程度指令可能被冲淡，某个措辞上的盲区可能刚好没覆盖到。在 Claude Code 那边我们有 hook 做硬拦截，不依赖模型是否自觉。GPT 这边如果只靠一份指令文件，就少了这一道保障。

第二层：PreToolUse hook，命令级别的硬拦截

Codex 确实支持类似的 hook 机制，叫 PreToolUse hook。

原理不复杂。GPT 每次要执行一条 shell 命令的时候，在命令真正跑起来之前，Codex 会先把这条命令的完整内容交给一个我们自己写的检查脚本。检查脚本读到命令内容，做一轮判断，然后给出结论：放行，或者拒绝并附上理由。如果拒绝了，GPT 会看到一段报错信息，里面写着为什么被拦，但命令本身不会执行，一个字符都不会跑。

让人省心的是，这个 hook 的协议格式跟 Claude Code 那边几乎一模一样：命令信息通过标准输入传进来，判断结果通过标准输出传回去，数据结构都是同一种 JSON 格式。等于同一套知识直接复用，不需要重新学一遍。

我们的检查脚本做了四件事。

第一件，禁止绕开 worker 脚本直接起 claude 进程。这是最核心的一条规则。前面说过，直接起 claude 进程意味着占槽、选账号、撞限保护全部失效。这扇门必须焊死。

第二件，限制可以派发的模型范围。Opus、Sonnet、本地部署的模型（比如 Qwen 27B）都在白名单里，可以派。但 Fable 不在白名单里。原因是 Fable 的额度本身就紧张，它是 Claude Code 主代理用的模型，GPT 不应该去动它的份额。

第三件，禁止 GPT 自己搞并行。一次派一个任务，完全没问题。但在循环里批量起 worker、用并行工具同时跑好几个，这些写法全部拦掉。并发多少个应该由 worker 脚本内部的占槽机制来控制，调用方不能越权自己决定。

第四件，在派发之前先查一下全机是否正处于撞限冷却期。如果是的话，命令直接拒掉，连 worker 脚本都不用进。这样 GPT 能第一时间知道"现在跑不了"，不用白白等一轮。

这一层管控有一个明确的局限，需要坦诚说清楚：它只能看到命令文本本身。如果有人把违规的命令写进另一个脚本文件，然后用一条看上去完全无害的命令去执行那个脚本，检查脚本是识别不出来的。

所以它很有用，但不是万能的。最后还需要一层兜底。

第三层：worker 脚本自身的保护

这一层是上一篇就有的，不是新加的，但在这里起到了关键的兜底作用。

worker 脚本内部有自己的占槽锁和撞限保护。占槽锁是一个本地的锁文件，全机同时在跑的计费子代理不能超过上限，超了就排队等。撞限保护是，一旦某个账号的额度被用到触发了限制，脚本会写一个冷却标记，在冷却期内不再往这个账号派任务。

这些机制的特点是，它们不关心命令是从哪来的。不管是 Fable 派过来的、GPT 派过来的、还是有人手动在终端敲的，只要进了 worker 脚本，这些规则就生效。外面两层（指令文件和 hook）都有可能被绕过，但 worker 脚本内部的锁文件是写在磁盘上的，该排队就排队，该拒绝就拒绝，没有商量余地。

三层加在一起

回过头来整体看一下这三层的关系。

指令文件管的是模型的主动行为。日常状态下，GPT 读到规矩就会照做，绝大多数时候根本走不到后面两层。这是最省事、覆盖面最广的一层。

hook 管的是命令执行前的最后一道关口。万一 GPT 因为某种原因没遵守指令文件，命令在真正跑之前还是会被检查脚本拦住。我专门验证过这一层：把指令文件临时移走之后，GPT 果然尝试直接起 claude 进程，Codex 返回了一段拒绝信息，命令没有运行。hook 确实在起作用。

worker 脚本自身的保护管的是资源层面。前两层都失效了也没关系，占槽锁和撞限保护写在文件里，谁来了都得守。

三层管的范围各不相同，互相之间没有重叠：模型行为、命令拦截、资源控制。任何一层出问题，后面的层还在。

两个系统不会打架

现在 Claude Code 的 Fable 和 Codex 的 GPT 都在往同一个 worker 脚本派任务，一个自然的担心是：它们会不会互相抢资源？

不会。上一篇搭的选账号逻辑和并发控制都是全机级别的，靠的是本地的锁文件和额度缓存。GPT 派出去的 worker 进程和 Fable 派出去的 worker 进程，到了操作系统层面看，就是普通的进程，身份完全平等。它们占的是同一个并发位，查的是同一份额度数据，遵守的是同一套规则。

不需要额外做什么协调机制，因为从一开始它们就在同一个池子里。worker 脚本在设计的时候就没有"调用方身份"这个概念，所以天然地对所有调用方一视同仁。

搭建过程中两段有意思的经历

第一段。我想从 Claude Code 里启动 Codex，做一次完整的端到端测试。结果命令刚发出去，Claude 那边的门禁就把它拦了，Codex 那边压根没收到。

原因想想也合理。我的测试命令里包含了 claude -p 这几个字符，Claude 的门禁脚本扫到了就觉得不对劲，直接就动手了。它不知道这条命令的最终目的是去测 Codex 的 hook，它只看到了命令文本里的敏感关键词。

后来换了个做法：把测试用的提示词写进一个文件，然后用管道把文件内容送给 Codex。这样一来，实际执行的命令文本里不再包含那些关键词，Claude 的门禁也就不会触发了。

第二段。想验证 hook 到底能不能拦住违规命令。但指令文件在的时候，GPT 太守规矩了。我怎么诱导它，它都不会发出一条违规命令。hook 注册着呢，但一次都没被触发过。

想了想，这其实很合理：外面那层太有效了，里面这层自然就没有表现的机会。后来只能把指令文件临时移走，GPT 失去了"规矩"的约束，才开始"放飞自我"去碰那些平时不会碰的命令。这时候 hook 终于得到了上场的机会，也确实证明了自己能拦住。测完之后把指令文件放回去就好。

这两件事背后是同一个现象：多层防线叠在一起的时候，想单独验证某一层是否正常工作，得先把它外面的层暂时关掉。搭的时候觉得层越多越安全，测的时候才发现层越多越难测。这也算是多层防护方案的一个小小代价吧。

往后看

这套方案能走通，根本上是因为 worker 脚本起的子代理是一个独立进程，对调用方的唯一要求就是"能执行 shell 命令"。GPT 可以，理论上其他任何能跑 shell 的 AI 工具也可以接进来。

不过这也意味着整个架构建立在"用 shell 做桥梁"这个前提上。如果以后不同厂商的模型之间有了原生的互相调用通道，这座 shell 桥也许就可以拆了，门禁的实现方式也得跟着变。在那之前，这条路跑着挺顺的。