---
title: 'Opus 4.6 多 Agent 编排:tmux、agent 沙箱与可观测性的端到端组合'
video_id: RpUTF_U4kiw
url: https://youtu.be/RpUTF_U4kiw
title_en: "Claude Code Multi-Agent Orchestration with Opus 4.6, Tmux and Agent Sandboxes"
channel: IndyDevDan
published: 2026-02-09
duration: "24:02"
topics: [多 Agent 协作, Claude Code 工作流, Claude Code 定制扩展, Agent 工程]
noted: 2026-07-08
value: A
views: '5.6万'
---


[![封面](https://i.ytimg.com/vi/RpUTF_U4kiw/maxresdefault.jpg)](https://youtu.be/RpUTF_U4kiw)

> IndyDevDan · 24:02 · 发布 2026-02-09 · 5.6万次观看(截至抓取) · [观看原视频](https://youtu.be/RpUTF_U4kiw)

> 🔥 观众最高回放 [01:41](https://youtu.be/RpUTF_U4kiw?t=101) — 开篇论断多 agent 编排已成为能动工程的新瓶颈、约束落在工具+人而非模型,并随即切换到终端演示。

## 主旨

视频演示在 Opus 4.6 上把 Claude Code 的实验性多 agent 编排能力、tmux 终端分屏、agent sandbox(E2B)与多 agent 可观测系统四件套组合起来跑两轮 4-agent 并行工作的端到端流程——验证把 spec 写在 prompt 里、让 subagent 自己拉资源、自己并行、自己收尾——在真实全栈应用上能不能跑通。

## 核心论点

1. **能动工程的瓶颈已不在模型——多 agent 编排把约束从模型转回"工具+人"两件事上**,真正稀缺的是 prompt/context 工程的工程能力与配套工具链。([[#1-主张转位能动工程的新瓶颈是工具你-0018|→ 详解1]])
2. **多 agent 编排要可被工程化,必须同时配可观测性——"看不见就没法改进"**,两件套缺一不可,沙箱只解决了"在哪跑"没解决"怎么知道跑得好不好"。([[#2-三层基座tmux-终端分屏--agent-沙箱--多-agent-可观测性-0124|→ 详解2]])
3. **tmux 的 pane 既是多 agent 的可视化层也是并发单元**——主 agent 用一句话触发,Claude Code 就把每个 subagent 派到独立 pane 并发跑,人可以在 pane 间切换追问、监督、回查。([[#3-第一次演示主-agent-派生-8-个-subagent-并行排查代码库-0246|→ 详解3]])
4. **从触发到收尾的多 agent 编排是五步定式:create team → create tasks → spawn agents → work in parallel → shutdown + delete team**——工作完成后强制关掉 subagent 是为了逼出"重置上下文重新开始"的好习惯。([[#4-第二次演示两组各-4-个-subagent-并行重挂应用到新沙箱-0557|→ 详解4]])
5. **新工具栈是底层[[Agent Teams]]功能的对外接口**(TeamCreate / TeamDelete / TaskCreate / TaskList / TaskGet / TaskUpdate / SendMessage),按职责切成 team management、task management、communications 三类——理解分层比记工具名更重要。([[#5-编排全生命周期与强制-shutdown-习惯-1225|→ 详解5]])
6. **看似花哨的多 agent 编排底下仍是"core four"(context / model / prompt / tools),Agent 编排就是 tools 这一项的下钻**——模型变强是给定的,人能优化的仍是这四件套的工程质量。([[#6-新工具栈与core-four框架-1225|→ 详解6]])

## 知识点详解

### 1. 主张转位:能动工程的新瓶颈是"工具+你" [00:18](https://youtu.be/RpUTF_U4kiw?t=18)

开篇作者明确放下 Opus 4.6 的跑分,只抓一个论点:"The real big idea I want to cover with you today is multi-agent orchestration. The game on the field is changing." ([00:18](https://youtu.be/RpUTF_U4kiw?t=18))。他接着把这轮"游戏规则变了"具体化:"The true constraint of agentic engineering now is twofold. It's the tools we have available and it's you and I."([00:35](https://youtu.be/RpUTF_U4kiw?t=35))

这与 [[Harness]] 概念页里多源印证过的主张——能动工程的成败九成落在 harness、模型只占一成——是同一条主张的 IndyDevDan 版变体——区别在于他特意把"工具"和"你自己"并列,而不是只把约束压到 harness 一词上。模型变强是不可控变量,工具选择与 prompt/context 工程能力才是工程师能持续投资的两条腿。

这一节也是本片对 vibe coder 与 engineer 分界线的总铺垫。后续所有演示都建立在这个论点上:多 agent 编排能力(模型端)已经给到,能不能用好完全取决于人能否把 spec、上下文、监控、收尾都设计好。

### 2. 三层基座:tmux 终端分屏 + agent 沙箱 + 多 agent 可观测性 [01:24](https://youtu.be/RpUTF_U4kiw?t=84)

视频一开篇就把多 agent 编排的工程化框架讲清楚:"we're going to use agent sandboxes as a playground to understand and to really dive into two key big ideas: multi-agent orchestration and multi-agent observability."([01:24](https://youtu.be/RpUTF_U4kiw?t=84))。两层"大想法"是编排与可观测性,沙箱是承载它们的"游乐场"——三者缺一不可,这是后续所有 demo 的工程底座。

具体角色:tmux 提供 pane 级别的并发可视层,主 agent 每派生一个 Subagent 就给它分配一个 pane,所有 subagent 同时跑、进度可见;agent sandbox(E2B)给每个 subagent 一个独立、12 小时寿命、可丢弃的远端运行环境,避免它们互相污染本地机器、也避免 agent 操作失误搞坏作者自己的开发环境;多 agent 可观测系统记录所有 session start / session end / tool call / task update 事件,人可以在任意时刻回查任意 agent 在那一刻的具体工具调用与上下文。

这三个组件与后来 IndyDevDan 在 [[2026-07-06-CMUX实测终端复用器解决多智能体编排三大痛点|CMUX 实测]] 里强调的"programmatic access"是同一思路的早期形态——本片用 tmux pane,后片用 CMUX 的 send/read/open/close 编程原语,演化方向是"可编程、可监控"。

### 3. 第一次演示:主 agent 派生 8 个 subagent 并行排查代码库 [02:46](https://youtu.be/RpUTF_U4kiw?t=166)

作者在终端里键入 `Build a new agent team for each code base in this directory. Have an agent summarize and how to set it up.`([02:46](https://youtu.be/RpUTF_U4kiw?t=166))。这行 prompt 一发,主 agent 自动创建任务列表、组建 team、给每个代码库分派一个 Subagent——在 tmux 里同时开 8 个 pane 并发跑,可视层立刻填满整个屏幕。

观察指标有三:第一是 tmux pane 的并发开/关,subagent 一启动就开 pane、收工就关 pane,生命周期清晰;第二是 Claude Code Hooks 触发的多 agent 可观测事件流,所有 tool call 都被实时记录,演示里作者点开某条 swim lane 看到 1 分钟内累积 160 次 tool call([04:06](https://youtu.be/RpUTF_U4kiw?t=246));第三是上下文用量的节约,主 agent 任务结束后只用了 31% 的 context window,其余 69% 留作下一步迭代([04:11](https://youtu.be/RpUTF_U4kiw?t=251))。

这条 demo 的真正结论是"编排接口要够简单到一句 prompt 触发"——人不需要先写 orchestration config,只需要把目标与规则说清楚,Claude Code 自行决定团队结构、任务拆解、并发窗口、上下文切分。这是 [[Harness]] 在"tools"这一栏的具体落地,工具链到位了,人就不用动手写调度代码。

### 4. 第二次演示:两组各 4 个 subagent 并行重挂应用到新沙箱 [05:57](https://youtu.be/RpUTF_U4kiw?t=357)

第二轮演示把编排粒度从"fan-out 8"收紧到"两组各 4 个"。作者写道"build a new agent team... using agent sandboxes... use the backslash reboot and mount one through four in their own agent sandbox. Be sure to set up every agent."([06:54](https://youtu.be/RpUTF_U4kiw?t=414))。

工程上的关键点不再是"能不能并行",而是"如何把上下文里的每个细节都明示给 subagent"——作者刻意把 skills、back slash command、目标目录、可观测工具全部列出来,这样 subagent 在自己的干净 context window 里也能复现完整工作流。这也是 Claude Code 实验性多 agent 编排与早期 Meta Harness 思路的差异:不靠中心 orchestrator 把所有信息 push 给子 agent,而是让子 agent 在自己的上下文里"按需重学"。

中途遇到一个真实工程问题:第一组 4 个跑完后,作者发现需要处理剩下 4 个——他让 subagent 把剩余目录名 `PB copy` 到剪贴板、再开第二个 tmux 会话跑同一 prompt([08:05](https://youtu.be/RpUTF_U4kiw?t=485))。这是把"团队扩展"做成可复制操作的工程习惯——一次 prompt 模板跑 4 个,复制模板再跑剩下 4 个,而不是把 8 个写进同一条 prompt 寄望 subagent 一次跑完。

### 5. 编排全生命周期与强制 shutdown 习惯 [12:25](https://youtu.be/RpUTF_U4kiw?t=745)

整段演示的最后一步是收尾:作者强调"when the work is done, you want to delete the agents. This forces a good pattern of context engineering where you reset the context and start over."([17:28](https://youtu.be/RpUTF_U4kiw?t=1048))。这是本片除了"如何起"之外最值得记的一条——多 agent 编排不是"开个 team 一直挂着",而是工作完成就拆、context window 重置、下次再从干净环境起。

整套动作被作者凝练成五步定式:"Create the team, create the tasks, spawn the agents, work in parallel, shut them all down, delete the team."([21:35](https://youtu.be/RpUTF_U4kiw?t=1295))。这条流水线后来被反复出现在他的多 agent 编排讨论中,也与 [[2026-07-06-CMUX实测终端复用器解决多智能体编排三大痛点|CMUX 实测]] 里"启动/观测/扩容/收回"是同一套方法论。

视频还演示了"迭代式编排"——发现两个 app 数据缺失后,作者没有自己去修,而是再开一支新 agent team: "spin up a new agent team to do this work for you. Give them all the context they need, skills, Sandbox backslash command."([15:19](https://youtu.be/RpUTF_U4kiw?t=919))。多 agent 编排被用来当 ad-hoc 修复队,而不是一次性 plan-and-execute——这是对 [[2026-02-09-Claude Code Agent Team 实时协作编码|Cole Agent Team 实时协作编码]] 里 contract-first spawning 的工程补充:不是所有任务都适合"先定契约再并行",有些调试任务更适合"看见 bug 就开新 team 去修"。

### 6. 新工具栈与"core four"框架 [12:25](https://youtu.be/RpUTF_U4kiw?t=745)

新工具栈按职责分成三层:team management(TeamCreate / TeamDelete),task management(TaskCreate / TaskList / TaskGet / TaskUpdate),communications(SendMessage——最重要,所有 agent 之间的通信都走它)([20:49](https://youtu.be/RpUTF_U4kiw?t=1249))。理解分层后,后续版本升级(再加新工具)只是某一层加项,不会破坏心智模型。

视频结尾作者把整套编排能力收口到一句更普适的命题:"Everything is the core four."([20:38](https://youtu.be/RpUTF_U4kiw?t=1238))。所谓"core four"就是 context / model / prompt / tools 四件套——多 agent 编排是 tools 这一项的下钻,Opus 4.6 是 model 这一项的具体值,prompt engineering 决定 subagent 怎么被启动,context engineering 决定 subagent 自己的窗口里装什么。可观测性是横切层,把"core four"运行中的所有事件都接出来。

这条框架与 [[Harness]] 概念页里的"harness 是你搭的上下文/规则/工具/workflow 的集合"是同一条主张的极简版表达:四件套的工程化封装就是 harness。当 IndyDevDan 在结尾说"How can we understand the capabilities available to us to accelerate our engineering work"([22:02](https://youtu.be/RpUTF_U4kiw?t=1322)),他强调的也是同一个问题——"用好"永远是工程师自身能力的延伸,模型变强与新功能发布不会自动把它变简单。

## 可执行步骤

- [ ] 评估是否要上多 agent 编排:任务能被拆成 N 个相互独立的工作单元时再上,否则用单 agent + 多次调用更划算。
- [ ] 给 Claude Code 配好 tmux(`tmux` 命令 + pane 切分快捷键 Ctrl+B + 方向键),让 subagent 启动后自动开 pane,先看到全貌再决定要不要介入。
- [ ] 把 agent sandbox 接到 E2B(或其他类似平台),用环境变量注入 API key,subagent 跑在沙箱里、结果回传,本地机器不被污染。
- [ ] 启用多 agent 可观测系统(本片推荐作者自己的开源实现),把 session start / tool call / task update 全部落库——编排的可视化一半在 tmux pane、一半在事件流。
- [ ] 每次触发 agent team 前先把 prompt 写"工程师写给工程师"那种完整:目标、可用 skills、目标目录范围、失败回退路径,不要写"用 agent team 修一下",subagent 没有共享上下文,信息缺失直接等于返工。
- [ ] 跑完一轮后强制 `delete team`、重置 subagent 上下文,不要积累跨任务的"长上下文 agent"——本片明确说这是 context engineering 的好习惯。
- [ ] 真正紧急(生产事故)场景下考虑横向铺多种工具/模型的 subagent 竞速,取第一个可用结果先部署,token 比时间便宜。

## 关联

- 互补(同主题不同终端层):[[2026-07-06-CMUX实测终端复用器解决多智能体编排三大痛点|CMUX 实测]] — IndyDevDan 半年后的续作,论证 tmux 的 pane 控制不构成"programmatic access",真正的可编程访问需要 CMUX 这类终端复用器给 send/read/open/close 四原语;本片用 tmux 做可视化,CMUX 实测论证 tmux 在可编程性上的上限已到。判定变量:只是需要"看见每个 subagent 在做什么"用 tmux 已经够,要"用 orchestrator agent 反向控制 subagent"再上 CMUX。
- 互补(同主题不同实现):[[2026-02-23-The Pi Coding Agent 课程/11-v9-Agent-Team|Pi v9 Agent Team]] — IndyDevDan 自家 Pi 课程里给出的 agent team 实现,核心是 YAML 配置文件 + primary agent 改当 dispatcher,本片则演示 Claude Code 实验性多 agent 编排(TeamCreate/TaskCreate/...)的实际跑法。判定变量:想要 vendor-locked 的"声明即用"用 Claude Code 实验功能,想要全可定制+模型不绑定走 Pi YAML。
- 互补(同功能不同深挖):[[2026-02-09-Claude Code Agent Team 实时协作编码|Cole Agent Team 实时协作编码]] — Cole Medin 同期同功能深挖,补上 subagent↔Agent Teams 的完整取舍、2-4 倍 token 量化、可见性缺陷与 contract-first spawning 解法;本片侧重视觉化与端到端实操。判定变量:想知道"为什么用 / 不用、何时用"读 Cole,想看"实际跑起来什么样 / 怎么配 tmux"读本片。
- 印证(主概念同源):[[Agent Teams]] — 本片所演示的"主 agent 派生 subagent + 共享任务列表 + tmux pane 可视化"是 [[Agent Teams]] 概念页里"队友能互相对话辩论 + 主 session 兼 team lead + 实验性功能 + 需 settings.json 开启"特征集合的具体落地,与 [[2026-03-08-Claude Code 六个层级|Chase·Claude Code 六个层级]] Level 6、Nick Saraev 14 章、Cole 02-09 等多源同向印证。
- 印证(工程哲学同源):[[Harness]] — 本片结尾"Everything is the core four (context / model / prompt / tools)"是 [[Harness]] 概念页里"harness 占能动工程 90%"主张的极简变体,本片把 harness 拆成四件套并把"多 agent 编排"明确归类到 tools 这一项下钻,与 [[2026-06-25-Harness为王的能动工程大师课|Harness 大师课]]、Chase·六个层级、Omnigent 元 Harness 多源印证。
- 互补(可观测性抓手):Claude Code Hooks — 本片多 agent 可观测系统的事件源就是 Claude Code Hooks(SessionStart / SessionEnd / UserPromptSubmit / PreToolUse / PostToolUse 等钩子),把 hook 落库就是把 agent 行为变成可回查时间线;本片未细讲 hook 本身,Claude Code Hooks 概念页能补足钩子的写法与配置位置。

- 进阶:[[2026-02-02-Claude Code 任务系统:反 hype 视角下的多 Agent 编排进阶|Claude Code 任务系统进阶]] — 同频道一周后的续作,把本片的任务系统 + Agent Teams 推进到用 Template metaprompt 把编排沉淀成可复用模板;本片给工具栈与可观测全景,续作给模板化方法,先读本片建立全景再读续作学沉淀。
## 一手来源与延伸

- [Opus 4.6 模型发布说明(Anthropic)](https://www.anthropic.com/news/claude-opus-4-6) — 视频 description 引用的 Opus 4.6 官方页面,介绍模型新能力与适用场景(本片开篇只用 Opus 4.6 作为载体,核心仍讲多 agent 编排)。
- [Claude Code Orchestration / Agent Teams 官方文档](https://code.claude.com/docs/en/agent-teams#set-up-agent-teams) — 本片"五步定式 + 新工具栈"的官方落地,TeamCreate/TeamDelete/TaskCreate/TaskList/TaskGet/TaskUpdate/SendMessage 的命名与开启方式均以该文档为准;视频里"$enable_experimental_agent_teams=1"环境变量是该文档的标准开关。
- [Multi-Agent Observability(开源)](https://github.com/disler/claude-code-hooks-multi-agent-observability) — 视频演示的 agent 事件流观测系统,由作者 IndyDevDan 自维护,基于 Claude Code Hooks(SessionStart/PreToolUse/PostToolUse/UserPromptSubmit 等)实现事件落库与可视化面板。
- [Agent Sandbox Skill(开源)](https://github.com/disler/agent-sandbox-skill) — 视频里的 agent sandbox 操控入口,封装 E2B 的 sandbox 创建/挂载/重启等操作,本片演示 `\`reboot` 命令的来源。
- [Tmux Getting Started(官方)](https://github.com/tmux/tmux/wiki/Getting-Started) — tmux 安装与基础使用,视频里多 agent 并行可视化的底层(创建 session / 切 pane / Ctrl+B + 方向键 等快捷键均沿用此文档惯例)。
- [E2B(云端 agent 沙箱平台)](https://e2b.dev/) — 本片所有 sandbox 实例的运行环境,12 小时寿命、可丢弃、隔离,subagent 在里头跑 setup/挂载/数据初始化等高破坏性操作而不影响本地机器。

## 术语

- multi-agent orchestration(多 agent 编排:一个主 agent 指挥多个 subagent 并行协作完成一件大任务,强调"团队协作"而非"顺序调用")
- multi-agent observability(多 agent 可观测性:把每个 agent 的 session/tool call/task update 等事件落库成可回查时间线,避免"看不见就没法改")
- agent sandbox(agent 沙箱:在隔离环境里让 agent 安全执行高破坏性操作,本片用 E2B,12 小时寿命、可丢弃)
- tmux pane(tmux 的终端分屏单元,本片每个 subagent 独占一个 pane,人可在 pane 间切换)
- core four(context / model / prompt / tools 四件套,IndyDevDan 用它把所有 agent 工程活动归类)
- scale your compute to scale your impact(用更多算力换更多工程产出,本片反复强调的多 agent 编排口号)
- TeamCreate / TeamDelete(创建/删除一支 agent team 的工具,多 agent 编排的入口/出口)
- TaskCreate / TaskList / TaskGet / TaskUpdate(管理 team 内任务列表的四件套工具)
- SendMessage(subagent 之间通信的专用工具,是多 agent 协作的关键链路)

## 金句

> "The true constraint of agentic engineering now is twofold. It's the tools we have available and it's you and I." — 把多 agent 时代的能力瓶颈明确从"模型不够强"转回"工具+人",与 [[Harness]] 的"90% 在 harness"是同一主张的不同表达,值得抄下来作多 agent 工程的元主张。回跳 [00:35](https://youtu.be/RpUTF_U4kiw?t=35)

> "When the work is done, you want to delete the agents. This forces a good pattern of context engineering where you reset the context and start over." — 多 agent 编排"用完即删"的硬习惯,把 context engineering 从建议变成纪律。回跳 [17:28](https://youtu.be/RpUTF_U4kiw?t=1048)

> "Create the team, create the tasks, spawn the agents, work in parallel, shut them all down, delete the team." — 多 agent 编排的 5 步定式,可作为自己写多 agent workflow 时的标准模板。回跳 [21:35](https://youtu.be/RpUTF_U4kiw?t=1295)

> "Everything is the core four." — 把多 agent 编排、prompt engineering、context engineering 等概念全收口到 context / model / prompt / tools 四件套,避免被新功能名词牵着走。回跳 [20:38](https://youtu.be/RpUTF_U4kiw?t=1238)

## 立场与利益

- 与利益同向(待印证):harness 决定能动工程九成效果、新工具让多 agent 编排平民化——这是 IndyDevDan 反复主张,与 [[Harness]] 概念页里多源印证一致,但作者在 description 挂了带 `?y=RpUTF_U4kiw` ref 参数的付费课链接 `https://agenticengineer.com/tactical-agentic-coding`,且课程里专章"Agentic Horizons"也覆盖多 agent 编排,本片部分价值论证与卖课同向。采信前可对照 Chase 六个层级 / Cole Agent Team / Nick Saraev 高阶课 等独立信源——多源已印证 harness 主张,主线可采信。
- 利益中性:tmux pane 演示、agent sandbox 接入、Claude Code 实验性多 agent 编排的五步定式、TeamCreate/TaskCreate/SendMessage 等新工具栈——这些是 Anthropic 官方功能 + 开源工具的实操演示,作者在其中既不是赞助商也不是代理,可独立验证。
- 与利益反向(单独标,最可信):作者全程在用 API billing 而非订阅 plan 跑 Opus 4.6,并明确说"this is going to burn a hole in my wallet. Drop a like, drop a comment... pay for some of this API usage."([11:02](https://youtu.be/RpUTF_U4kiw?t=662))——主动暴露多 agent 编排的真实成本,且不引导观众立刻去订阅 Claude Max 解决,而是承认"模型变强不可控,工具选择才是工程师能优化的一层"——这条与"工具能平民化多 agent 编排"的销售主张同源,但在成本承认上反向,值得单独标。

利益证据一行:description 唯一的导流是 `tactical-agentic-coding?y=RpUTF_U4kiw`(带 ref 参数的付费课),与"harness 90%"同向;没有 affiliate 工具链接。

## 价值定位

对**正在用 Claude Code 并想从"单 agent + 串行"过渡到"多 agent + 并行"的工程师**:

- 适合谁:已熟练 Claude Code 日常用法、想验证多 agent 编排在自己真实全栈应用上能否跑通的进阶用户;对还在 vibe coder 阶段的学习者本片价值有限(片里"vibe coders fall apart"是开篇定调)。
- 解决什么:把"多 agent 编排 + tmux + agent sandbox + 可观测性"四件套的真实工程形态一次看全——不是工具介绍,是"8 个 subagent 并行排查 8 个代码库 / 两组各 4 个 subagent 并行重挂应用到新沙箱"这种带具体数字的端到端演示;同时给出"五步定式"(create team / create tasks / spawn / parallel / shutdown+delete)作为可照搬的 workflow 模板。
- 认知 vs 实操:五步定式、tmux pane 切分、agent sandbox 接入、可观测系统接入均拿来即用;"core four"与"瓶颈在工具+人"是认知层(改变你看 agent 工程的视角);"scale your compute to scale your impact"是 motto,知道就行。
- 与 [[2026-02-09-Claude Code Agent Team 实时协作编码|Cole Agent Team 实时协作编码]] 重叠(同功能同周发布):本片独有 tmux pane 可视化 + agent sandbox 工程化 + "5 步定式 + 用完即删"的硬纪律 + "core four" 框架 + API 成本真实承认;Cole 那边独有 subagent vs Agent Teams 选型铁律 + 2-4 倍 token 量化 + contract-first spawning 解法。

## 自检问题

1. IndyDevDan 把多 agent 时代能动工程的新瓶颈定义为什么?为什么?
   **答案**:两件事——"the tools we have available and it's you and I"。模型变强是不可控变量,工程师真正能持续投资的是工具选择(orchestration framework / sandbox / observability)与自身 prompt/context 工程能力。见详解1 [00:35](https://youtu.be/RpUTF_U4kiw?t=35)。
2. 多 agent 编排的"5 步定式"具体是什么?为什么最后一步"shutdown + delete"必须做?
   **答案**:Create the team → Create the tasks → Spawn the agents → Work in parallel → Shut them all down + Delete the team。最后一步强制 shutdown 是为了逼出"重置上下文重新开始"的 context engineering 好习惯,避免 subagent 跨任务积累长上下文导致 [[Context Rot]]。见详解5 [21:35](https://youtu.be/RpUTF_U4kiw?t=1295) 与 [17:28](https://youtu.be/RpUTF_U4kiw?t=1048)。
3. "Core four"是哪四件?多 agent 编排落在哪一件上?
   **答案**:Context / Model / Prompt / Tools。多 agent 编排是 Tools 这一项的下钻——具体表现就是 TeamCreate / TaskCreate / SendMessage 等新工具栈与 tmux / agent sandbox / observability 等配套基础设施;Opus 4.6 是 Model 这一项的具体值,prompt engineering 决定 subagent 怎么被启动,context engineering 决定 subagent 自己的窗口里装什么。见详解6 [20:38](https://youtu.be/RpUTF_U4kiw?t=1238)。
4. tmux pane + agent sandbox + 多 agent 可观测系统在多 agent 编排里分别解决什么问题?
   **答案**:tmux pane 是"看得见"层——主 agent 每派生一个 subagent 就开一个 pane 并发跑,人可以在 pane 间切换追问、监督、回查;agent sandbox(E2B)是"在哪跑"层——给每个 subagent 一个独立、12 小时寿命、可丢弃的远端运行环境,避免 subagent 互相污染本地机器与作者开发环境;多 agent 可观测系统是"怎么知道跑得好"层——把 session start / tool call / task update 全部落库成可回查时间线。三者缺一不可:只跑不用 tmux pane 看不见、只用 sandbox 没有可观测性就不知道 agent 在做什么、只装可观测没 pane 也没法实时介入。见详解2 [01:24](https://youtu.be/RpUTF_U4kiw?t=84) 与详解3 [04:06](https://youtu.be/RpUTF_U4kiw?t=246)。
5. 多 agent 编排新工具栈按职责分几类?各类的代表工具是哪些?
   **答案**:三类——team management(TeamCreate / TeamDelete)、task management(TaskCreate / TaskList / TaskGet / TaskUpdate)、communications(SendMessage,被作者明确点为"the most important one of all probably")。理解分层后,后续版本再加新工具只是某一层加项,不会破坏心智模型。见详解6 [20:49](https://youtu.be/RpUTF_U4kiw?t=1249)。