本文用于说明 CountBot 接入外部编程工具的两种典型模式，并重点解释它们分别适合什么场景、怎么配置、怎么使用。

本文覆盖的外部编程工具包括：

• Codex

• Claude Code

• OpenCode

本文重点说明两种模式：

1. AI 模式 / 组合调用模式

IM 渠道先连 CountBot，再由 CountBot 的主 LLM 决策是否调用外部编程工具

2. 直通模式 / 中转模式

通过 CountBot 作为中转层，把微信 ClawBot 或其他 IM 消息直接转发到外部编程工具

说明：你提到的 “combo 调用”，下文统一按 CountBot 当前实际界面术语写成 AI 模式。

你提到的 “中转功能”，下文统一按 CountBot 当前实际界面术语写成 直通模式 / direct。

---

一、先看总图：两种模式的本质区别

这两种模式都能把：

• 飞书

• 企业微信

• 微信 ClawBot

• 其他 IM 渠道

和下面这些外部编程工具连接起来：

• codex

• claude

• opencode

但两者的核心区别在于：

• 第一种模式是 CountBot 先理解，再决定要不要调用工具

• 第二种模式是 CountBot 主要负责转发，不做主 LLM 级别的深度决策

可以先用一句话理解：

• AI 模式 = CountBot 是“大脑”，外部编程工具是“执行器”

• 直通模式 = CountBot 是“中转路由层”，外部编程工具更像“主执行端”

图片1：两种模式总览图

---

二、两种模式的快速对比

| 对比项 | AI 模式 / 组合调用模式 | 直通模式 / 中转模式 |

| — | — | — |

| 谁先处理消息 | CountBot 主 LLM | 外部编程工具 |

| CountBot 的角色 | 主控、理解、决策、编排 | 桥接、中转、会话与路由层 |

| 是否适合普通聊天 | 很适合 | 不适合，偏编码专用 |

| 是否适合复杂混合任务 | 很适合 | 一般 |

| 是否适合持续改代码 | 可以，但不是最极致 | 非常适合 |

| 是否能调用团队、技能、工具 | 更容易统一调度 | 主要走外部编程工具 |

| 渠道推荐 | 飞书、企业微信、微信群里的“综合助手” | 微信 ClawBot、持续编码窗口、专职 coder 入口 |

| UI 术语 | routing_mode=ai | routing_mode=direct |

如果你只是想要一个更自然、更像“AI 助理”的体验，优先用第一种。

如果你想把某个 IM 入口直接变成 Codex / Claude Code / OpenCode 的代理入口，优先用第二种。

---

三、两种模式共用的前置准备

无论你选哪一种模式，第一步都一样：

先把外部编程工具配置好

路径：

1. 打开 设置

2. 左侧选择 编程工具

当前这里可以配置外部编程工具 Profile。

你可以在这里新增或修改：

• claude

• codex

• opencode

编程工具页可以配置什么

当前前端支持：

• name

• command

• args

• working_dir

• session_mode

• history_message_count

• env

• inherit_env

• timeout

并且支持：

• 单独检查某个 profile 是否可用

默认内置的三种工具 Profile

CountBot 默认会生成外部编程工具配置文件，其中已经带了三个默认 profile：

1. Claude Code

• 名称：claude

• 默认会话模式：native

• 更适合原生持续会话

2. Codex

• 名称：codex

• 默认会话模式：history

• 更适合基于最近历史上下文的持续编码

3. OpenCode

• 名称：opencode

• 默认会话模式：history

• 更适合当作持续编码 CLI 执行器

三种会话模式怎么理解

1. 单次模式 stateless

每次只发当前请求，不带上下文。

特点：

• 最干净

• 最不容易串上下文

• 连续编码体验较弱

2. 最近历史模式 history

会把最近 N 条消息拼进 prompt，再发给外部工具。

特点：

• 最适合大多数连续编码场景

• codex、opencode 默认更适合这个模式

3. 原生会话模式 native

优先使用工具自己的原生会话能力。

当前实际规则是：

• 对 claude 更适合

• 非 Claude 工具如果设为 native，实际会回退到 history

一个非常重要的提醒

如果你同时启用了多个外部编程工具 Profile，而又没有明确指定要用哪一个，系统可能无法自动唯一确定 profile。

所以：

• 如果你只启用了一个 profile，系统更容易自动调用

• 如果你启用了多个 profile，最好在消息里明确说：

• 用 codex 帮我修这个报错

• 用 claude 帮我写个爬虫

• 用 opencode 帮我审一下这段代码

---

四、第一种模式：AI 模式 / 组合调用模式

这是最适合“IM + AI 助手 + 外部编程工具”组合协作的模式。

一句话理解

先由 CountBot 主 LLM 理解用户消息，再决定是否调用外部编程工具。

它的逻辑不是：

用户一发消息就直接扔给 codex / claude / opencode

而是：

用户消息 -> CountBot 主 AI 理解 -> 判断是否需要外部编程工具 -> 调工具 -> 整理结果 -> 回复 IM

这就是典型的“组合调用模式”。

---

五、第一种模式的链路长什么样

以飞书为例：

飞书用户消息

-> 飞书渠道接入 CountBot

-> CountBot 主 LLM 先理解任务

-> 如有必要，调用 external_coding_agent

-> external_coding_agent 调用 codex / claude / opencode

-> 工具结果回到 CountBot

-> CountBot 再组织成最终回复

-> 返回飞书

在这个模式里：

• CountBot 是主控

• 外部编程工具是执行器

• 最终回复风格仍然由 CountBot 控制

图3：AI 模式链路图

---

六、第一种模式怎么配置

第一步：配置外部编程工具

先按上一章把：

• codex

• claude

• opencode

配置好并启用。

第二步：配置 IM 渠道

路径：

1. 打开 设置

2. 左侧选择 IM 渠道

3. 选择你的渠道，例如：

• 飞书

• 企业微信

然后进入对应账号的高级功能或路由设置，确认：

• routing_mode = ai

这表示：

• 该账号走 AI 模式

• 消息先给 CountBot 主 AI

在这个模式下：

• external_coding_profile 不是强制项

• 因为不是一进来就直通外部工具

但如果你只希望它偏向某个默认工具，也可以进一步结合聊天里的 /coder 命令做临时切换。

第三步：保存渠道配置

一定要：

• 测试渠道

• 保存配置

• 确认账号已启用

否则 IM 聊天里不会真正生效。

---

七、第一种模式怎么用

用法 1：普通聊天，让 CountBot 自己判断

例如：

帮我分析一下这个报错可能是什么原因。

这时 CountBot 会先理解：

• 这是不是普通问答

• 这是不是需要调文件 / shell / 搜索 / 工作流 / 外部编程工具

如果它认为不需要外部编程工具，就不会调。

如果它认为需要，它可以进一步调用 external_coding_agent。

用法 2：显式告诉 CountBot 用哪个外部编程工具

例如：

用 codex 帮我修这个报错

用 claude 帮我写一个爬虫

用 opencode 帮我审一下这个 PR

当前系统会识别这类显式路由语句。

当用户明确说“用 codex / claude”时，CountBot 会优先调用 external_coding_agent，并把对应 profile 传进去。

用法 3：自然语言 + CountBot 继续做收口

这是第一种模式很重要的优势。

例如：

用 codex 帮我修这个 bug，修完后再顺便帮我总结一下改动点。

这类请求很适合 AI 模式，因为：

• CountBot 先调用外部编程工具执行

• 再把结果整理成更适合用户看的回复

也就是说，它既能用工具，也能收口解释。

---

八、第一种模式适合什么场景

推荐场景：

• 飞书里接一个“综合研发助理”

• 企业微信里接一个“技术支持助手”

• 既有聊天、又有方案、又有编码、又有团队协作的混合任务

• 既可能走工作流，也可能走工具，也可能走外部编程工具的复杂请求

一句话概括：

如果你要的是“AI 助手 + 外部工具”的组合能力，用第一种。

---

九、第一种模式的优点和边界

优点

• 更智能

• 更像真正的 AI 助手

• 能统一调度普通回答、工具调用、团队工作流、外部编程工具

• 最终回复更自然

边界

• 对“持续改代码”这种极强编码会话，未必比直通模式更直接

• 如果启用了多个外部 profile，最好明确指定 codex / claude / opencode

• 因为主 LLM 先处理，所以链路相对更长

---

十、第二种模式：直通模式 / 中转模式

这是最适合“把某个 IM 入口直接当成外部编程工具代理”的模式。

一句话理解

用户消息先进入 CountBot，但 CountBot 不再以主 LLM 身份深度处理，而是把消息直接转发给默认外部编程工具。

也就是说：

• CountBot 还在中间

• 但它主要负责中转、会话、路由、监控、回传

• 外部编程工具才是主要执行端

这就是你说的“利用 CountBot 中转功能”的本质。

在 CountBot 当前术语里，这对应：

• routing_mode = direct

“微信 ClawBot -> CountBot(中转) -> Codex/Claude/OpenCode -> 微信”

---

十一、第二种模式的链路长什么样

以微信 ClawBot 为例，可以理解为：

微信用户消息

-> 微信 ClawBot 接到消息

-> CountBot 微信渠道收到消息

-> CountBot 根据 direct 路由直接调用 external_coding_agent

-> external_coding_agent 调用 codex / claude / opencode

-> 结果返回 CountBot

-> CountBot 写入会话并回发微信

在这个模式里，CountBot 主要负责：

• 渠道接入

• 多账号路由

• 会话创建

• 历史拼装

• profile 选择

• 超时与取消

• 结果回传

所以它是：

• 路由层

• 会话层

• 中转层

但不是主要的“任务决策 LLM”。

---

十二、第二种模式怎么配置

第一步：配置外部编程工具

和第一种模式一样，先在：

• 设置 -> 编程工具

中把：

• codex

• claude

• opencode

配置好并启用。

第二步：配置微信渠道

如果你说的是“微信 ClawBot 接入”，当前 CountBot 里的对应入口是：

• 设置 -> IM 渠道 -> 微信

README 中把这项能力称为：

• 微信ClawBot接入

而实际图形化页面里显示的是：

• 微信

第三步：把该账号设为直通模式

进入目标微信账号的高级功能或路由配置后，设置：

• routing_mode = direct

并填写：

• external_coding_profile = codex

或

• external_coding_profile = claude

或

• external_coding_profile = opencode

这表示：

• 这个微信账号收到的普通消息

• 会直接转给默认外部编程工具

第四步：保存配置

一定要保存并确保账号启用。

一个非常重要的点

direct 模式下，external_coding_profile 是必须配置的。

如果你把路由设成 direct，但没填默认外部编程工具，后端会判定配置无效。

---

十三、第二种模式怎么用

用法 1：默认就是直通

当账号已经是 direct 模式时，普通消息就会直接转给默认外部编程工具。

例如你把微信 ClawBot 的默认工具设成 codex，那么用户发：

帮我修一下这个 Python 报错

这条消息就不会先由 CountBot 主 AI 深度决策，而是直接进入 codex。

用法 2：在聊天中切换当前会话的路由模式

IM 聊天里支持命令：

/route direct

/route ai

/route default

含义：

• /route direct：当前会话切到直通模式

• /route ai：当前会话切回 AI 模式

• /route default：恢复渠道后台默认配置

用法 3：在聊天中切换当前会话的外部编程工具

IM 聊天里还支持：

/coder codex

/coder claude

/coder default

含义：

• /coder codex：当前会话的直通代理切到 codex

• /coder claude：当前会话的直通代理切到 claude

• /coder default：恢复后台默认工具

注意：这些命令只影响当前会话

这是当前系统一个很重要的设计：

• 在 IM 聊天窗口里发 /route、/coder

• 只影响当前聊天会话

• 不会持久化写回后台默认配置

真正持久化的是：

• 在 IM 渠道 -> 对应账号 -> 高级功能 里保存的配置

---

十四、第二种模式为什么特别适合微信 ClawBot

因为很多人把微信 ClawBot 当成：

• 手机上的 coder 入口

• 随时发需求的编程代理入口

• 连续改代码的聊天入口

在这种场景下，用户想要的不是：

• 一个“先分析半天再决定调不调工具”的助手

而是：

• 一个“我一说话就直接进 codex / claude”的编程代理

这时直通模式更适合。

另外一个现实原因

微信渠道当前实现说明里写得很明确：

• 当前仅支持微信私聊

• 不支持群聊

所以它天然更适合作为：

• 私人 coder 助手

• 私聊开发代理

而不是群协作总控机器人。

---

十五、第二种模式下，会话模式尤其重要

因为直通模式下，消息会直接发给外部编程工具，所以 Profile 的 session_mode 会显著影响体验。

如果你用 Codex

推荐：

• history

原因：

• Codex 默认更适合带最近历史的持续编码

如果你用 Claude Code

推荐：

• native

原因：

• Claude 更适合原生会话能力

如果你用 OpenCode

推荐：

• history

原因：

• 更适合以最近聊天历史拼 prompt 的方式工作

如果你想要最干净的一次性执行

可以用：

• stateless

但通常不适合作为持续编码入口。

---

十六、第二种模式适合什么场景

推荐场景：

• 微信 ClawBot 作为手机上的 coder 入口

• 某个独立 IM 账号专门做 codex / claude 代理

• 用户希望“发一句话就直接开始改代码”

• 需要长期持续编码上下文的私聊场景

一句话概括：

如果你要的是“IM 就是外部编程工具代理”，用第二种。

---

十七、两种模式怎么选

你可以直接按下面这个思路选：

选第一种：AI 模式 / 组合调用模式

当你希望：

• 先聊天、再判断

• 不只是编码，还有普通问答、工具、团队、多角色协作

• CountBot 负责理解、编排和收口

• 飞书 / 企业微信里做一个综合型技术助手

选第二种：直通模式 / 中转模式

当你希望：

• IM 入口本身就是 coder 代理

• 少一层主 LLM 决策

• 更适合持续改代码

• 微信 ClawBot 或某个子机器人专职接外部编程工具

---

十八、推荐组合方案

实际落地时，最推荐的不是只选一种，而是两种并存。

例如：

方案 A：飞书综合助手 + 微信编码代理

• 飞书账号：routing_mode=ai

• 微信 ClawBot：routing_mode=direct

效果：

• 飞书负责综合协作

• 微信负责直接 coding

方案 B：同一渠道多机器人分工

例如飞书里：

• default 主机器人：ai

• coder 子机器人：direct

效果：

• 主机器人负责理解和调度

• 子机器人负责直接把编码任务送进外部工具

方案 C：同一账号默认 AI，遇到需要时临时切 direct

后台默认：

• routing_mode=ai

临时在会话里发：

/route direct

/coder codex

效果：

• 平时是综合助手

• 当前会话临时变成编码代理

---

十九、接口配置示例

如果你需要批量化配置，也可以直接走接口。

示例 1：飞书账号使用 AI 模式

POST /api/channels/update

{

"channel": "feishu",

"config": {

"enabled": true,

"account_id": "default",

"app_id": "cli_xxxxxxxx",

"app_secret": "xxxxxxxx",

"routing_mode": "ai",

"external_coding_profile": ""

}

}

示例 2：微信 ClawBot 账号使用直通模式

POST /api/channels/update

{

"channel": "wechat",

"config": {

"enabled": true,

"account_id": "default",

"base_url": "https://ilinkai.weixin.qq.com",

"token": "wechat-token",

"login_bot_id": "wx_bot_xxx",

"login_user_id": "wx_user_xxx",

"routing_mode": "direct",

"external_coding_profile": "codex"

}

}

示例 3：外部编程工具 Profile 配置示例

PUT /api/settings/external-coding-tools

{

"version": 1,

"profiles": [

{

"name": "codex",

"enabled": true,

"type": "cli",

"command": "codex",

"args": ["exec", "--skip-git-repo-check", "--cd", "{working_dir}", "-"],

"stdin_template": "{prompt}",

"working_dir": "",

"inherit_env": ["OPENAI_API_KEY"],

"session_mode": "history",

"history_message_count": 10,

"timeout": 900

}

]

}

---

二十、常见问题

1. 为什么我在飞书里说“用 codex 帮我修一下”，没有调用工具？

优先排查：

• 外部编程工具 profile 是否已启用

• codex 命令在后端环境里是否可执行

• 如果启用了多个 profile，是否正确说了具体名字

• 渠道是否已保存并启用

2. 为什么 direct 模式下消息没有转发成功？

优先排查：

• routing_mode 是否真的是 direct

• external_coding_profile 是否已填写

• 对应 profile 是否启用

• profile 命令是否可执行

3. 为什么 /coder codex 发了但没持久化？

因为：

• /coder

• /route

只影响当前会话，不会修改后台默认配置。

4. 微信 ClawBot 能不能像飞书那样做群聊协作？

当前微信渠道实现说明是：

• 支持私聊

• 不支持群聊

所以更适合做个人编码入口。

5. AI 模式和 direct 模式能混着用吗？

可以，而且非常推荐。

最常见的做法就是：

• 主机器人用 ai

• coder 入口用 direct

---