OpenClaw 里默认模型、会话模型、子代理模型、ACP 模型到底有什么区别？

很多人刚用 OpenClaw 时，都会冒出一个问题：既然 TUI 里能换模型，Telegram、Discord 这类消息渠道接入后也能在会话里换模型，那默认模型到底还有什么意义？

答案是：有，而且非常关键。因为 OpenClaw 里的“模型”其实不止一层，至少要分成默认模型、会话模型、子代理模型和 ACP 模型。它们分别解决的是系统起步、当前对话、独立执行和外部编码运行时四种不同问题。

OpenClaw 模型层级关系图：全局默认 → 会话覆盖 → 子任务分流 → 外部编码运行时

一张表先看懂四层模型

1. 默认模型：系统的起步基线

默认模型解决的是一个非常底层的问题：当系统还没被明确指定该用哪个模型时，第一步该由谁来接住消息。

它主要负责这些场景：

• 新会话第一次回复
• TUI 新建会话
• Telegram 新私聊、新线程
• 会话重置后的回退
• 某些自动任务、心跳或隐式任务的兜底

所以默认模型不是为了限制用户，而是为了保证 OpenClaw 在“无人指定”的时候也能稳定起步。

2. 会话模型：当前对话真正运行的模型

会话模型解决的是：当前这段聊天，实际由谁来回答。

比如你在 TUI 里切模型，或者在 Telegram 对话过程中换了模型，本质上就是在修改当前会话模型。它只影响当前这段对话，不会自动覆盖整个系统的全局默认。

可以这样理解：

• 默认模型：系统启动默认档
• 会话模型：当前正在开的这一档

3. 子代理模型：把复杂任务拆出去单独干

子代理模型主要用于“主会话负责沟通和规划，执行型任务拆出去单独跑”的场景。

比如这些任务就很适合交给子代理：

• 改仓库代码
• 批量处理文件
• 跑测试
• 长时间执行的自动化流程

这样做的好处是主会话上下文更干净，执行日志不会把对话主线淹没，同时也能给子任务单独指定更合适的模型。

4. ACP 模型：外部编码运行时专用

ACP 模型比子代理再往前走一步，它不只是“换一个模型”，而是直接把任务交给外部编码运行时。

典型就是：

• Codex
• Claude Code
• Gemini CLI

这时切换的已经不只是回答者，而是一整套运行时、线程方式、agent 会话和执行上下文。所以 ACP 模型本质上是“外部编码代理”的模型层，而不是普通聊天层。

为什么这四层不能混成一个模型设置

因为它们解决的问题根本不同：

• 默认模型解决“起步”
• 会话模型解决“当前聊天”
• 子代理模型解决“独立执行”
• ACP 模型解决“外部编码运行时”

如果硬把这四层揉成一个“统一模型设置”，看起来简单，实际会导致新会话、当前会话、子任务和外部代理互相干扰，最后反而更难理解。

实际工作流里它们怎么配合

1. 新消息进来，系统先用默认模型接住。
2. 如果当前会话已切模型，后续回复由会话模型负责。
3. 如果任务复杂，主会话把执行部分拆给子代理模型。
4. 如果你明确要求“用 Codex / Claude Code / Gemini CLI 做”，就会进一步转到 ACP 模型对应运行时。

怎么设置更合理

• 默认模型：选一个稳定、适合多数新会话起步的模型。
• 会话模型：按当前任务临时切换，追求灵活性。
• 子代理模型：优先给执行型任务使用更适合编码和测试的模型。
• ACP 模型：仅在明确要用 Codex、Claude Code、Gemini CLI 这类外部运行时时启用。

最后总结

OpenClaw 的模型体系不是重复设计，而是一套分层调度机制。

默认模型负责系统起步，会话模型负责当前聊天，子代理模型负责独立执行，ACP 模型负责外部编码运行时。

理解了这四层，你就不会再把“默认模型有没有意义”理解成单一问题，而会意识到它其实是 OpenClaw 整个调度逻辑的底座。