IndyDevDan · 30:29 · 发布 2026-07-06 · 7548次观看(截至抓取) · 观看原视频
主旨
用终端复用器 CMUX 给 Claude Code、Pi、Codex 等多个编码 agent 提供可编程访问,借此解决多智能体编排里”看不见、启动慢、扩不动”三个共性痛点。
核心论点
- 多智能体编排的真实瓶颈不是选哪种模式(Ralph 待办循环、loop engineering、经典 subagent 委派各有拥趸),而是三个共性问题:能否编程式访问 agent、能否监控以改进、能否快速批量启动。(→ 详解1)
- “看不见的 agent 就是改不了的 agent”——agentic engineering 与 vibe coding 的分野在于是否持续观察 agent 的过程细节并据此强化或纠偏。(→ 详解2)
- CMUX 的心智模型是 window/workspace/pane 三层,配合 send/read/open/close 四个编程原语,让人和 orchestrator agent 都能像操作真实终端一样驱动它。(→ 详解3)
- 三层编排(orchestrator-lead-worker)配合可编程访问,能做到任意 agent 互相 prompt,通信信道是扁平的,而不是严格自上而下的黑箱层级。(→ 详解4)
- 遇到生产级紧急问题时,横向铺开多种模型/工具并行竞速,是”scale your compute to scale your impact”最直接的落地场景。(→ 详解5)
- CMUX 相对 tmux 的核心差异化不是美观或主题,而是”programmatic access”这一项能力本身;代价是目前仅支持 Mac,且工具尚年轻、通知联动偶有失灵。(→ 详解6)
知识点详解
1. 多智能体编排的三个共性痛点 02:53
作者把当下五花八门的编排流派(Ralph 待办循环、loop engineering、三层委派等)先搁置一边,认为无论选哪种流派,真正卡住规模化的是三件事:agent 没有programmatic access、监控成本随 agent 数量线性上升、以及每次手动搭建新团队都慢。
第一个痛点最根本:“no programmatic access to your agents”意味着人必须一直守在循环里,agent 永远跑不出人的反应速度。第二个痛点是”booting an agent team by hand kills the agentic speed”——手动逐个开终端、逐个粘 prompt,团队一大就撑不住。
作者由此把评估任何编排工具的标准收敛成同一把尺子:能不能给出程序化的送指令/读结果/开关窗口能力。这也是他挑 CMUX 而不是先挑某种编排哲学的原因——问题先行,工具后行。
2. 可见性是能改进的前提 03:19
核心口号是”an agent you can’t see is an agent you can’t improve”。作者观察到不少工程师在批量起 agent 后就”关掉大脑”、不再复盘过程,把该强化的成功模式和该剔除的失败模式一起忽略掉了。
CMUX 用 workspace 级别的颜色标识、tab、banner 和通知,让人可以随时跳进任意一个 agent 的画面看它在做什么,而不是只等最终输出。这个可见性本身就是后续做 Agentic Engineering 里”正向强化/负向纠偏”闭环的前提。
作者区分了 vibe coding 与 agentic engineering:前者只关心结果、不管过程;后者要求持续监控过程,才谈得上迭代改进 agent 的行为。CMUX 解决的正是”看得见”这一层。
3. CMUX 的心智模型与四个编程原语 07:23
CMUX 的空间层级是 window→workspace→pane 三层:window 是最外层容器,workspace 是一组终端/agent 的组合单位(作者习惯把整支 agent team 放在 workspace 一级),pane 是里面具体的终端窗格,一个 pane 内还能开多个 tab(surface)。
控制方式很简单,归结为四个动作:send key(发送按键/文本)、read(读取屏幕当前内容)、以及 open/close surface(开关窗格)。作者原话是”we can send information like send key… we can then read the screen”——这套 API 既可以人手动用,也可以让一个上层 orchestrator agent 反复调用,形成”发指令→读结果→再发指令”的闭环。
这套原语的好处是通用:不管背后是 Claude Code、Codex、Pi 还是任何 CLI agent,CMUX 都不关心具体工具,只负责操作终端本身。这让它天然支持跨工具编排,而不绑定某一家 agent 产品。
4. 三层编排与扁平通信 17:04
作者偏好的组织形态是 orchestrator→lead→worker 三层:orchestrator 在最上层驱动 lead,lead 再驱动具体干活的 worker agent。乍看是层级结构,但作者强调”any agent can prompt any agent”——借助 CMUX skill,任何一个 worker 也能直接去 ping 同级或其他团队的 agent,通信信道是扁平的。
这解决了传统公司式层级的老问题:信息只能沿着汇报线传递、跨部门协作要层层请示。CMUX 里三层只是”谁负责发起工作”的组织约定,而不是通信权限的硬限制。
作者演示了一个具体例子:在某个 Claude Code worker 里直接输入 cmux 触发 skill,去 ping 其他团队的 agent 状态。这说明三层结构与扁平通信可以并存,层级不必然带来沟通瓶颈。
5. 生产热修复场景:多agent并行竞速 19:29
针对”生产出问题、每秒都在流失用户”这类紧急场景,作者展示了一次性拉起 8 个 agent(不同编码工具×不同模型组合,包括 Claude Code、Codex、Pi 接 Minimax 与 GLM)去做同一次”大海捞针”式排查,谁先找到可用修复方案就先部署。
原话是”throw more compute at the problem, have your agents race toward a solution”——这是”scale your compute to scale your impact”最直白的落地:每种模型/工具都有各自的强弱项,当时间比 token 成本更贵时,并行铺开比串行试错划算。
演示中也暴露了工具的不成熟:部分 Pi agent 因环境变量问题没能启动,orchestrator 对完成通知的响应也一度卡住,作者坦言这可能是自己没把 agent 教对,也可能是工具本身通知联动还不够稳。
6. CMUX vs tmux:差异化只在可编程访问 22:16 / 25:03
作者把 CMUX 和老牌的 tmux 摆在一起比较,结论是 tmux 能做到的大部分事情 CMUX 也能做,CMUX 的优势是可定制的美观界面和更顺手的开发体验,但这些都是加分项,不是决定性的。
真正的分水岭是可编程访问本身。作者原话:“if a tool does not have programmatic access, I just completely ignore it”——这是他评估任何新工具的一票否决项。CMUX 目前只支持 macOS,Linux/Windows/WSL 用户仍需要 tmux 这类跨平台方案;另外作为一款年轻工具,通知联动等细节还在打磨中。
作者还展示了用 just 文件里的一条命令(jfast cc)秒开一整套三层 agent team,直接解决”第一千次启动”的效率问题——这依赖的同样是可编程访问,而不是 CMUX 独有的某个花哨功能。
可执行步骤
- 评估任何多 agent 编排工具前,先问它有没有 programmatic access(能否用代码/脚本发指令、读状态、开关会话),没有就直接跳过。
- 给自己的 agent 团队搭一个”能一眼看到每个 agent 在做什么”的界面(哪怕只是多开几个终端窗口),而不是丢一堆任务后就不管。
- 把常用的 agent 团队启动方式固化成一条命令(如 just 文件里的别名),避免每次手动重新搭建。
- 遇到时间紧迫、允许并行试错的任务(如紧急 bug 排查),考虑同时起多个不同模型/工具的 agent 竞速,取最先可用的结果。
关联
- 印证:Fable5被禁 从 orchestrator 模型侧(单 Fable 实例编排 15 sandbox)补上本片工具侧的「scale compute to scale impact」证据。
- 印证:Meta Harness(见Omnigent)与本片同属”给多个 AI 编码工具接上统一编排层”的判断——Omnigent 走 server 层统一配置的路线,CMUX 走终端复用器给出可编程访问的路线,殊途同归。
- 冲突:组织层级过深(见CC高阶课·组织层级)主张仿公司式 org chart 层级越深协作越差;本片的 orchestrator-lead-worker 三层恰是一种层级,但作者强调通信信道扁平(任意 agent 可直接 prompt 任意 agent),缓解了该批评所指的”信息只能沿汇报线走”的问题——两者对”层级本身是否有害”给出了不同侧重的回答。
- 互补:Pi v9 Agent Team 与本片同主题不同切入点——CMUX 给多 agent 提供可编程访问的终端层(window/workspace/pane + send/read/open/close 四原语);Pi v9 在 YAML 里直接定义 agent team、primary agent 当 dispatcher。两边殊途同归,CMUX 管 agent 启动与可视,Pi 管 agent 之间的协作分工。
一手来源与延伸
- cmux 官方仓库(GitHub, manaflow-ai/cmux)——开源、基于 Ghostty 的 macOS 原生终端,专为并行运行 AI 编码 agent 设计,视频中的 window/workspace/pane 与 socket API 均对应该仓库描述的功能。
术语
- programmatic access / agentic access(编程式访问:agent 或脚本能直接调用工具的 API 发指令、读状态,而非依赖人工点击输入)
- surface(CMUX 里 pane 内的具体标签页/终端会话单位)
- workspace(CMUX 里承载一组 pane/agent 的组织单位,作者习惯把整支 agent team 放在这一级)
- 三层编排 orchestrator-lead-worker(顶层驱动中层、中层驱动具体干活的底层,但通信不限于逐级)
金句
“An agent you can’t see is an agent you can’t improve.” → 监控不是可选项,是能持续改进 agent 行为的前提,这也是作者选工具的第一标准。 “If a tool does not have programmatic access, I just completely ignore it.” → 把”能否被程序调用”当作评估任何 agent 工具的一票否决项,比界面美观、功能多少都优先。
立场与利益
视频末尾提到自己另有一门付费的”tactical agentic coding”课程,并链接了此前讲”五大支柱”与”多层级编排”的旧视频;但对 CMUX 本身没有代言/赞助关系,评测立场是作为普通用户的实测与取舍(明确指出 Mac-only、通知联动不稳等局限),销售引导集中在视频尾部且与工具评测内容分离。
价值定位
面向已经在跑多个编码 agent、苦于”看不见进度、每次手动重搭团队”的实操者:视频给出的是具体可复制的操作画面(如何用 window/workspace/pane 组织团队、如何用四个原语编程控制),认知增量集中在”用什么标准挑编排工具”而非 CMUX 功能全集;对只跑单个 agent 或还在用聊天框交互的学习者,实操价值有限。
自检问题
- 作者评估任何多智能体编排工具时,放在第一位的一票否决项是什么? 答案:是否有 programmatic access(可编程访问)——没有就直接忽略该工具,不管它功能多丰富。见详解6 25:03
- CMUX 的空间层级模型分哪三层?各自对应什么? 答案:window(最外层容器)→workspace(一组终端/agent 的组织单位,作者把整支 team 放这一级)→pane(具体终端窗格,内部还可开多个 surface/tab)。见详解3 07:23
- 为什么说 CMUX 的三层 orchestrator-lead-worker 编排不是传统意义上的”深层级”? 答案:因为通信信道是扁平的——借助 skill,任意一个 worker agent 都能直接 prompt 同级或其他团队的 agent,而不必逐级向上汇报再转发,层级只决定”谁发起工作”,不限制信息流向。见详解4 17:04
- 视频里 8 agent 热修复竞速场景,选择”多工具多模型并行”而非”单一 agent 深入排查”的理由是什么? 答案:生产故障场景下时间比 token 成本更贵,每种模型/工具各有强弱项,并行铺开让”第一个找到可用方案的”胜出,比串行试错更快拿到能部署的修复。见详解5 19:29
- CMUX 目前最大的平台限制是什么? 答案:仅支持 macOS;Linux/Windows/WSL 用户仍需依赖 tmux 这类跨平台方案。见详解6 22:16