Claude Code 源码十大亮点04:In-Process Teammate

Digital Strategy Review | 2026

Claude Code 十大亮点解读 04｜同进程 Teammate Runtime：在性能和隔离之间找到更好的平衡

文 / 果叔 · 阅读时间 / 8 Min

写在前面

多 Agent 走到协作层，最容易卡住的地方就是运行形态怎么选：太重会拖垮体验，太轻又会把边界做乱。Claude Code 这一层很值得看，因为它给出的并不是折中口号，而是一套真正能跑起来的中间路线。

同进程 Teammate Runtime：在性能和隔离之间找到一个极佳平衡点

多 Agent 系统走到协作这一步，通常会卡在一个老问题上：

• 每个 Agent 都起独立进程，隔离强，但成本高、同步复杂

• 全塞同一个主上下文，成本低，但边界混乱

Claude Code 的答案是：引入 in-process teammate。

它不是独立 OS 进程，也不是主 Agent 的普通子调用，而是一个运行在同一进程中的、具备独立身份和任务状态的 teammate。

一、为什么要做 in-process teammate

如果你只做普通 subagent，其实已经能实现一些委派了。但 Claude Code 想解决的是更进一步的问题：

• 多个 Agent 长时间协作

• 彼此有明确团队身份

• 能被 UI 统一查看

• 仍然保持较低运行成本

如果全用 tmux pane 或独立子进程来做，这套系统会变得很重。

于是 Claude Code 选择了一个非常务实的折中：

同进程运行，但身份、权限、任务、消息都做专门隔离。

Claude Code 选择的是第三条路：不走重进程，也不把边界全部抹平。

二、这个设计最妙的地方：它不是“偷懒地共用进程”

有些系统说自己“轻量多 Agent”，实际只是把多个逻辑分支塞进一个事件循环里，根本谈不上隔离。

Claude Code 不是这样。

它为 in-process teammate 做了很多专门机制：

• 独立 AbortController

• teammate identity

• 独立 task state

• AsyncLocalStorage / teammate context

• 独立 pending user messages

• 专门的 permission bridge

• 与 leader 的 mailbox 协作

所以它的本质不是“多个 Agent 恰好在同一进程”，而是：

多个 Agent 在同一进程中，以专门的上下文与状态壳运行。

三、`spawnInProcessTeammate` 解决了什么

spawnInProcess.ts 这一层主要负责：

01 生成 teammate 的稳定身份

02 创建独立 abort controller

03 创建 teammate context

04 构造 InProcessTeammateTaskState

05 注册到 AppState

也就是说，它做的是把 teammate 正式注册成系统对象。

这一步很重要，因为它意味着 teammate 不是 runAgent 的一个参数，而是一个在系统里真实存在、可被追踪的执行体。

四、`inProcessRunner.ts` 才是 teammate 真正跑起来的地方

这个文件的意义在于：它没有另搞一套特殊 Agent 引擎，而是让 teammate 最终也回到同一套 runAgent(...) 上。

换句话说：

• 同进程 teammate 有自己的外壳

• 但核心推理执行仍然是 Claude Code 的标准 agent loop

这是一种非常成熟的架构取舍：

• 外层按运行形态分化

• 内层尽量共用执行引擎

这样就不会出现“普通 subagent 一套行为，teammate 又是另一套奇怪行为”的问题。

五、为什么这个设计对 UI 非常友好

因为 teammate 最终是 task，所以 REPL 可以非常自然地支持：

• teammate 列表

• transcript 查看

• 用户给 teammate 注入消息

• teammate 的 pending 状态与运行状态

如果 teammate 只是若干后台 Promise，这些体验会非常难实现。

Claude Code 通过 in-process teammate 设计，把“协作中的其他 Agent”也纳入了统一可视化对象体系。

这正是它的 UI 看起来比普通终端 Agent 更像“协同工作台”的原因之一。

六、性能上的优势非常现实

1. 启动快

不用反复起新进程，也不必额外建太多 IPC 基础设施。

2. 共享运行时环境

同一进程里，很多基础能力可以共享：

• 已初始化的运行环境

• 部分缓存

• 状态桥接

• 权限交互通道

3. 适合大量轻量级协作

某些任务其实只需要：

• 快速搜代码

• 跑几个只读分析

• 做短平快验证

这些场景下，用 in-process teammate 比重型隔离 Agent 更划算。

七、当然，它也不是万能的

这类设计的边界也很明确。

1. 隔离程度不如独立进程 / worktree / remote

如果任务非常重、非常长，或者需要更强环境隔离，同进程 teammate 未必是最佳选择。

2. 权限和控制面必须做得更仔细

因为它共享主进程，所以更需要 leader permission bridge、mailbox、context 隔离来防止混乱。

3. 生命周期处理要非常小心

中断、切后台、用户注入消息、shutdown request，都必须处理得很稳，不然很容易出现悬挂状态。

Claude Code 恰恰是在这些细节上做得足够扎实，才让这条路线可用。

八、一张图看懂这件事

九、结论

同进程 teammate runtime 之所以是亮点，不是因为它“更省资源”这么简单，而是因为它在：

• 运行成本

• 身份隔离

• 控制面统一

• 协作体验

之间取得了非常好的平衡。

很多系统在多 Agent 这一步，要么太重，要么太乱。 Claude Code 用 in-process teammate 给出了第三种答案：

不必每个 Agent 都是独立进程，但每个 Agent 都必须是独立对象。