SuperBrain：给 Agent 接上外脑

当你的电脑上同时装着 Claude、Codex、Kimi、Qoder CN 等命令行工具时，问题就不再是「有没有 AI」，而是怎么把它们接进同一套能长期用下去的工作流：谁来调度、提示词怎么传、输出格式变了怎么办、后续怎么维护。这些细节凑在一起，就是一层需要单独处理的连接与协作。

SuperBrain 处理的正是这一层——它负责宿主 Agent 与外部 CLI 之间的连接与协作，而不是再造一个模型。要判断它对你有没有用，先看两个最直接的问题：能装在哪、能叫谁。

Skill 获取地址：https://github.com/Niall-Young/SuperBrain

能装在哪、能叫谁

SuperBrain 是一个需要你显式调用的 Agent Skill，宿主 Agent 至少需要具备 Skill 与子智能体能力，是否兼容仍需按宿主的实际能力确认；项目说明以 Claude Code 为示例宿主，并在安装说明里列出了 Cursor、Windsurf、Codex 等宿主对应的 skills 目录——注意，这些是示例和目录说明，并未逐一做过兼容性实测。能叫谁：本次源码包内置了四个外脑 CLI 席位——Claude、Codex、Kimi、Qoder CN。一句话概括它的价值：它把「外接 AI」做成了一层可配置、可维护的东西，而不是一次性演示。下面把「装在哪」和「叫谁」分开讲，因为它们是两层不同的事。

两层接入：宿主与外脑

SuperBrain 的接入分两层，这是全文最容易混、也最值得先分清的地方。

上层是宿主 Agent：负责承载 Skill、显式调用流程并整合结果，需要具备 Skill 与子智能体两种能力。下层是外脑 CLI：充当圆桌上的席位，每个席位是一个已安装的命令行工具，负责独立作答。两层的接入方式和验证方式完全不同——宿主看的是能力，外脑看的是工具装没装、能不能被找到、输出能不能被解析。

容易混的原因在于名字会串层：项目说明既拿 Claude Code 当宿主示例，又把 Codex 同时列为宿主之一和默认外脑席位。同一个名字出现在两层，不意味着「这个宿主绑定这个外脑」。判断之前，先想清楚这句话说的是哪一层。

接入矩阵

把两层落成一张表，你可以直接截图带走。表中「默认还是示例」区分出厂名单与举例说明；「验证方式」告诉你靠什么确认可用；「表述边界」是要一起记住的限定条件。

几个要点：Claude 与 Qoder CN 都走 claude-json 解析格式，Codex 与 Kimi 各不相同——这种不对称来自项目自带的配置，不是排版错误。特别记住一句：四个内置席位的可执行文件、传输方式与解析格式，是本次源码包内置的默认适配映射，不是这些 CLI 永久不变的接口承诺；它们升级后是否仍兼容，要按后面的判断依据复核。

默认四席位

内置四席位是「出厂名单」，不是你这台机器的现状。「支持」不等于已安装、已登录、有额度。

配置允许 2 到 4 个唯一席位；流程还有一道门槛——第一轮只有一个席位成功时不能进入第二轮，至少两个第一轮席位成功才达到门槛。第一次上手前，用项目自带的本地自检确认哪些外脑 CLI 能被找到。它只检查可执行文件是否存在、能否返回版本号——即便自检发现两个可执行文件，也不等于真实调用一定成功，因为登录状态、额度与真实调用都不在它的检查范围内，这一点务必记住。想跑起来，至少还要满足三样前提：Python 3.9 及以上；宿主的 Skill 与子智能体能力；至少两个已安装并登录的外脑 CLI。

附一个真实快照：2026 年 8 月 27 日，本机跑通了 9 项单元测试，自检识别默认四个席位全部可用，版本分别为 Claude Code 2.1.78、Codex CLI 0.150.0、Kimi 0.38.0、Qoder CN 1.1.31。这只是某一台机器、某一天的记录，换台机器未必一样。

自定义席位

默认名单不满意，可以换。外部席位通过一份 JSON 配置整体覆盖——注意是整体覆盖，不是增量补一个席位，配置里声明了哪些席位就用哪些，未声明的不会保留；配置读取有优先级——命令行参数 --config、环境变量 SUPERBRAIN_CONFIG、内置默认，依次生效。

每个席位要声明六个字段：id、label、executable、args、prompt_transport、output_format，分别对应席位标识、名称、可执行文件、参数、提示词传输方式和输出解析格式。可选的传输方式只有 stdin、argv 两种；可选的输出解析格式只有 text、claude-json、codex-jsonl、kimi-jsonl 四种。它们是一组封闭选项，不会自动协商。

边界一并说清：只有符合这两种传输和四种解析契约的 CLI，才能靠一份 JSON 接入。这不是「任意 CLI 零代码即插即用」——超出契约的部分，正是下一章的内容。

维护与升级

三级处理路径

这是全文最值得带走的一节。判断变化该改配置还是改代码，唯一依据是：这份输出现在还能不能被现有解析逻辑消化——不是配置里那个格式名变没变。处理分三级：

第一级，改配置就够。变化仍能由可执行文件、参数、传输方式或现有输出格式表达——换席位、改路径、改参数、在 stdin 与 argv 之间切换、改用已支持的输出格式——修改 JSON 配置即可，通过 --config 或 SUPERBRAIN_CONFIG 生效。

第二级，改完配置必须补验证。任何一次配置或环境变动后：先跑本地自检，再跑单元测试，最后再做一次低风险的真实咨询。顺序可以灵活，边界要清楚——自检只确认可执行文件与版本，单独跑它不能证明登录状态、真实调用和输出解析仍兼容；低风险真实咨询是维护建议，能补上自检覆盖不到的登录、真实调用与解析验证，但只说明这一次链路跑通，不是唯一的验证手段，也不构成兼容保证。

第三级，配置不够，必须改代码并补测试。两种情况都算这一级：一是输出结构变了但格式名没变——真实输出已无法被现有解析逻辑消化，即使席位仍写着 claude-json 这类旧名称；二是需要四种之外的全新输出格式——除改解析逻辑外，还要扩展受支持格式集合、补协议说明和测试。

一句话记分界：格式名沿用旧值不等于兼容；名字换了也不一定就要改代码——只要真实输出的形状仍落在某种解析器能处理的范围内，配置层就能解决。

没有自动升级器

本次源码包未提供自动更新或自动迁移命令——CLI 或宿主升级后，要你自己动手同步。

建议按这个顺序走（这是维护建议，不是内置功能）：先同步新版 SuperBrain 目录，再保留并重新指向你的自定义席位配置，然后运行单元测试、跑一次本地自检，最后挑一件低风险的真实问题咨询一次。前两步解决「代码换新了」，后两步帮助判断「新环境还能不能用」——自检只查可执行文件与版本；低风险真实咨询能补上它没有覆盖的真实调用和解析验证，但只说明这一次链路跑通。

把这套顺序当成习惯，SuperBrain 就从「一次性的演示」变成「能长期维护的接入层」。

它如何工作、为什么可信

把机制压缩到一节讲清楚。SuperBrain 需要显式调用，默认不会偷偷接管任务。它组织的是两轮咨询：

主脑先冻结自己的基线——在读到任何外部答案之前先形成判断；请求结构显式拒绝接收「主基线」字段，外脑全程看不到它。这是为了降低锚定：先有自己的答案，再听别人的，是流程层面的隔离，不等于数学上消除所有偏差。第一轮，所有可用席位在各自独立的工作目录里并发作答，彼此看不见，作用是减少相互影响、保留独立视角。第一轮至少两个席位成功，才进入第二轮——每个成功席位读到一份脱敏后的同侪复审：已知席位名被替换成 Peer A、Peer B 这类标签，这是身份字符串脱敏后的复审，不是强匿名，也不保证能凭内容风格完全对不上号。读完修订自己的方案，最终由你的主智能体整合判断。

结果写进一份审计记录，包含状态、时间、问题、门槛和每个席位两轮的结果。状态三态：complete 表示全部配置席位第二轮成功，partial 表示达到最低完成数，failed 表示未达门槛。注意：complete 只代表流程完整，不代表答案正确——最终判断始终由主智能体负责。

运行也有边界：席位跑在独立临时目录里，默认 Codex 席位是只读沙箱，Claude 与 Qoder CN 禁用工具；但显式调用仍会把脱敏后的任务包发给配置的外部 CLI，敏感资料不要放进请求。单次调用默认超时 180 秒、总体 480 秒，不自动重试；单席位输出捕获上限 200 万字节、请求材料总字符上限 4 万，超出的部分会被截掉或按该席位错误处理。

四步接入自检

如果决定试一次，可以按这四步开始：

第一步，确认宿主 Agent 具备 Skill 与子智能体能力。第二步，跑一次本地自检，看清哪些外脑 CLI 能被找到——它不覆盖登录与额度。第三步，查看并准备好席位配置，必要时用 JSON 指定你想接入的 CLI。第四步，最好再挑一件低风险的真实问题显式调用一次，看完整结果和运行状态记录——作为维护建议，它能补上自检覆盖不到的登录、真实调用与解析验证。

要不要把外脑变成常态，决定权始终在你。