科技Bestblogs·AI Engineer··AI 生成
三台机器上的 AI 智能体舰队：真正坏掉的环节
这是一篇 AI 编程智能体重度用户的一手复盘，揭示了比技术更棘手的瓶颈：人类注意力。作者 Kyle Jaejun Lee 详细记录了从单机 tmux 扩展到三台机器过程中暴露的五大故障模式，包括智能体不愿委派、凭证污染和评审入口分散。文章的核心贡献是提出了一个面向智能体的架构层级和基于文件的状态管理模式，并预言未来将走向类似 Kubernetes 的调度层。适合正在实际搭建或运维多智能体系统、对编排痛点的"坑"和"解"有真实需求的技术实践者。原文 ↗原文 ↗
核心观点
- ▍在扩展到多机多智能体系统时，真正的瓶颈是人类的注意力以及智能体之间的协调机制，而非硬件或模型能力。
- ▍未来大规模智能体调度的方向是面向智能体的 Kubernetes 层，智能体只需声明需求（计算、密钥、工具），由调度层决定在哪里运行。
- 01作者最初在 tmux 中运行多个智能体，被迫同时扮演调度器、记忆和评审者三个角色，导致自己的注意力最先成为扩展瓶颈。
- 02作者放弃了模型内的 compact 操作，改为将状态（任务、历史、交接产物）存储到文件工作区中。这样即使经历上下文 reset、崩溃或机器重启，工作也不会丢失。
- 03引入了显式的评审网关：智能体的计划必须等待人类批准后才能继续执行，避免了操作者逐一进入工作窗口检查。
- 04多机协同暴露了五类具体故障：智能体不愿委派任务给其他机器上的同伴、tmux 窗格在远程机上不可读、单个机器内存耗尽、某个 workspace 的凭证泄漏到其他机器、笔记本合上导致任务中断。
- 05当前架构的支撑组件包括：Git、SSH、按机器隔离的状态目录、PR 作为工作单元、集中评审网关和 Discord 作为路由终点。
反方 / 局限
- — 作者描述的架构和层级是高度手动的，可能不适用于需要大量自动化和低延迟交互的场景；文中提到的未来 Kubernetes 层仍处于构想阶段，未有具体实现或验证。
前置背景
技术原理
平行视角
未来推演
延伸追问