---
title: "用 AI 协调多个 Claude Code 会话"
subtitle: "从 tmux attach 到 agent 操控 agent 的个人实践"
last_updated: 2026-03-18
---

# 用 AI 协调多个 Claude Code 会话

## 问题的起点

我日常的工作方式是在 tmux 里同时开好几个 Claude Code，手动在两三个窗口之间切来切去并行干活。大部分时候这样效率很高——每个窗口一条任务线，互不干扰。

但问题出在第四件事上。**同时跟三条线还行，第四条就容易忘掉。** 忙着前三件事的时候，第四个窗口里 Claude Code 早就干完了在等我，或者卡在一个权限确认上等我点"允许"，我完全没注意到。等我想起来切过去看，已经过了二十分钟。

所以我开始想一个问题：**能不能让一个 AI agent 去操控另一个正在运行的 AI agent？** 如果可以，我就不用自己盯着每个窗口——让一个调度者 agent 替我看着就行。

这才是整套系统真正的核心出发点：不是某个具体产品，而是"agent 操控 agent"这个机制本身。

具体到调度者怎么跟我沟通，我在 OpenClaw 上跑了一个常驻的调度 agent，通过 Discord 跟我对话。但这一层更像是一个对外的壳——换成飞书 bot、Slack bot、甚至一个命令行脚本，都能做同样的事。真正难的不是这层壳，而是壳下面的问题：**这个调度者怎么接入我已经在跑的 Claude Code session？**

它是一个独立的 agent，有自己的 tool call（读文件、搜代码、跑命令），但这些工具操作的是它自己的环境。我 tmux 里正在跑的那几个 Claude Code？它看不到，也操控不了。它没法恢复一个已有的 session，也没法往一个正在运行的 Claude Code 里发指令。

## 调研：现有方案为什么都不够用

"AI 操控 AI"不是新概念，我花了不少时间调研现有方案。

首先要回答一个问题：**执行者选谁？** 调度者可以是任何能发指令的 agent——OpenClaw 上的、本地脚本里的都行——但执行写代码的那个 agent 选什么？OpenClaw 的 agent 底层用的也是 Claude 模型，模型能力本身没有差异，但它运行 agent 时用的是一个 Python 开源框架，不是 Claude Code 本身。我实际试用后发现，这个框架在功能丰富度上跟 Claude Code 还是有差距——Claude Code 有子进程调度、Plan Mode、Explore Agent 这些更激进也更好用的功能，在工具链和交互设计上更成熟。所以选 Claude Code 作为执行者，不是因为模型更聪明，而是因为它作为一个写代码的产品更完善。

确定了"下发给 Claude Code"这个方向之后，问题变成：怎么下发？

**Anthropic Agent SDK** — 官方的 SDK，我做了比较深入的学习。它的 `query()` 本质是 spawn 一个新的 Claude Code 子进程，通过 stdin/stdout 做 JSON 通信。能拿到结构化输出，但**只能创建新会话，不能接入已经在跑的 session**。它的 `resume` 功能也不是连接到运行中的进程——是从磁盘加载历史记录，spawn 新进程重放上下文。

**ACP 协议（Agent Client Protocol）** — 由 Zed 和 JetBrains 推动的 agent 间通信标准，我也做了深入调研。acpx 是它的无头 CLI 客户端，支持 13+ 种 coding agent 的统一操控。设计很有远见，但底层机制和 Agent SDK 一样：通过适配器 spawn 新进程，不能 attach 已有 session。

**Agora 框架** — 另一位个人开发者做的基于 tmux 的多 Agent 编排框架，我也在学习。它的设计很完整：投票、审批、状态机、Gate 门禁，三层架构解耦很干净。但它面向的是团队协作场景（多个 agent 民主讨论），我需要的是更直接的"调度者下指令，执行者去干"。而且它的 tmux 层是封闭管理的——只认自己创建的 pane，不能接管已有的 session。

**Claude Code Remote Control** — 官方的远程操控功能，能接入已有 session。但必须走 Anthropic 的云中继，不能自建，断网就没了。

**社区 Web UI** — claude-code-web、claude-code-webui 等项目，全是新建 session，不能 attach 已有的。

所有方案都倒在同一个问题上：**我 tmux 里已经开着好几个 Claude Code 了，上下文全在里面，新建进程意味着丢掉所有上下文。**

调研到最后发现，**tmux send-keys** 还是最直接的方案：

```bash
# 给正在运行的 Claude Code 发指令，就这么简单
tmux send-keys -t %3 "fix the login bug" Enter
```

加上 Claude Code 的 JSONL session 文件可以读到结构化的对话历史，两条通道一组合——输入走 tmux，输出读 JSONL——就是一个能 attach 已有 session 又能拿到结构化数据的完整方案。不需要框架，不需要 SDK，几十行脚本就能跑。

我把这个做成了开源项目 AImux。

## 意外收获：涌现智能

本来只是为了解决"干活时不能聊天"的问题。但用了一段时间后，我发现了一个比预期有意思得多的现象：

**下层 AI 会干出上层 AI 没想到的事。**

举个真实的例子。我需要打通"任务完成后自动通知"这条链路，给 Claude Code 的指令只有一句："看看 system event 为什么不工作。"

它自己干了什么：

1. 读平台源码 → 发现命令走 WebSocket
2. 跑命令 → ws 握手超时
3. 追代码 → Node.js event loop 被阻塞了 3 秒
4. 继续追 → 定位到**飞书插件的 jiti 编译器**卡住了整个进程
5. 建议禁用飞书插件 → 修复

我从来没提过飞书。它通过一层层源码分析自主找到了根因。

但故事没结束。修完这个 bug 后发现 system event 还是不好使——平台把触发事件的 reason 字段硬编码成了 "wake"，AI 收到的消息是一句毫无信息量的"如果没事就回 OK"。于是它又自主搜索，找到了另一个可行命令，验证通过，还顺手提了 3 个 issue。

**整个排查跨越 4 种方案，零人工干预。**

这就是我说的涌现智能——不是 prompt engineering 的结果，没有人在指令里写"检查插件是否阻塞 event loop"。而是执行者在过程中根据中间发现自主调整方向。

为什么只有在"下发"模式下才会出现？四个条件：

1. **完整工具链** — Claude Code 能读任意文件、跑命令、搜代码，调查链路不会断
2. **足够的自主空间** — 不是"帮我查第 42 行"，而是"看看为什么不工作"
3. **中间反馈闭环** — 每一步的报错自动成为下一步的线索
4. **不被打断** — 后台执行，没人催进度，agent 可以沉浸式追踪

如果上层 agent 自己做，它一边跟你聊天一边干活，每个操作阻塞对话，根本没法深入追踪。**分层本身就是涌现的前提。**

## 背后的关键：上下文管理

做 agent 开发有很多重要的事，但做下来我越来越觉得，**上下文管理是最核心的一件**。

分层之所以有效，本质上是因为它让每一层的上下文保持精简。调度者不需要知道执行者读了哪些文件、试了哪些命令、中间踩了什么坑——它只需要对两件事负责：**发出去的指令**和**收回来的结果**。中间的几十轮工具调用、几百行代码 diff，全部留在执行者自己的上下文里，不会污染调度者的窗口。

反过来，如果调度者把所有执行细节都吞进自己的上下文，它很快就会被细节淹没，做出的判断也会变差——该汇报的忘了汇报，该派活的自己动手干，正经事反而被挤掉了。

这跟人类团队的协作模式其实很像：一个靠谱的负责人不会坐在每个工位后面盯着代码写，他只关心"这件事交给谁了"和"结果怎么样"。中间过程交给执行者自己判断。**信息隔离不是偷懒，是让每个角色都能在自己的上下文密度下最好地工作。**

## 一个新认知：AI 没有意志力

搭这套系统踩过最大的坑不是技术问题，是认知问题。

我的调度器 agent 每次启动是全新 session。你告诉它"下次记得派活而不是自己做"，它回"好的我记住了"——然后下次启动，什么都不记得。

**AI agent 没有意志力，只有机制。**

人类可以说"下次注意"然后靠自制力改行为。AI 不行——如果一个规则没写在配置文件里，它就不存在。

所以我把所有运行逻辑写进了启动必读文件：

```markdown
# AGENTS.md（每次启动第一时间读）

你是调度器，不是执行者。

绝不做的事：
- 不要自己写代码——下发给 Claude Code
- 不要空头承诺"下次注意"——改文件改配置
- 不要反复轮询状态——用后台监听
```

这段话不是建议，是**运行时加载的系统指令**。

这个认知我觉得对所有做 agent 系统的人都适用：**"下次注意"是人类的解法，"写入文件"才是 agent 的解法。** 你想让 agent 改行为，别说，写。

## 一点感慨：想法的实现成本变低了

做 AImux 的过程让我很感慨。从发现问题到调研方案到写完代码到验证可行，前后也就几天。放两年前这是一个需要写几千行代码的"正经项目"，现在 AI 写了大部分代码，我主要在做决策和验证。

这不是我一个人的感受。最近跟朋友交流，或者在社区里逛，明显能看到更多有意思的个人项目冒出来。以前一个想法从"有意思"到"能用"之间有巨大的实现鸿沟，现在这个鸿沟在快速缩小。

**想法本身变得比以前更有价值了。** 因为实现不再是瓶颈，能想到别人想不到的点子才是。

## 想跟大家聊的

这套"AI 操控 AI"的玩法还在早期，有几个问题我自己也没想清楚，想听听大家的看法：

- **多层 agent 的信任边界怎么划？** 上层给下层多大的自主权？完全放手 vs 每步审批，中间有没有更好的平衡点？
- **涌现智能能被稳定复现吗？** 还是说它本质上是概率性的，只能创造条件然后等它出现？
- **你们有类似的实践吗？** 不一定是 tmux，任何"一个 AI 调度另一个 AI"的经验都想听。

项目开源在 GitHub: AImux，核心就是一个 skill 文件 + 几十行 Python，欢迎来看看和讨论。