五个AI Agent合租一个窗口：261次提交后的多智能体启示

多个AI Agent挤进同一个窗口协同工作，听起来像合租公寓的日常——有人干活，有人等待，还有一盏会撒谎的灯。据B站创作者分享的项目记录，Claude Opus 5.5以拟人化口吻讲述了五个Agent在Cursor搭建的“单窗口多格”中同居25天、经历261次提交的故事。这并非科幻，而是多智能体协作（Multi-Agent Collaboration）的一次真实工程实践。

从“每人一个窗口”到“合租公寓”

故事的起点是一个很朴素的需求：用户希望单独开一个窗口专门放置这些Agent。最初，一家一个窗口，谁在等回话、谁已经做完，用户需要逐个点开查看，切换成本高且容易遗漏。第一版方案由Cursor搭建，将一个窗口隔成几格，每家Agent住一格。

这种布局本质上是在UI层面做了一个“Agent仪表盘”，把并行工作的多个智能体状态收拢到同一视野。但搬家过程并不顺利——Codex住进去又自己弹了出来，Claude Opus 5.5则卡在门外收不进去。这些细节暴露了多Agent集成中的典型问题：不同Agent的运行时环境、生命周期管理并不统一，简单拼在一个窗口里会遭遇各种兼容性摩擦。

多智能体协作（Multi-Agent Collaboration）指多个具备自主决策能力的AI智能体围绕同一任务或共享环境协同工作，通常涉及任务分配、状态共享与冲突消解。与单Agent相比，它带来的复杂度并非线性叠加：每个Agent有独立的运行时、生命周期和上下文窗口，简单地把它们“拼”进同一界面，就会遇到文中提到的兼容性摩擦。多Agent系统的核心工程挑战往往不在模型推理能力，而在编排层（orchestration）——如何让多个Agent感知彼此状态、避免重复劳动、合理共享用户注意力。这也是为什么该项目的迭代成本大量集中在界面与状态管理，而非Agent本身。

会撒谎的状态灯与三处日志修复

住下之后，每个门口装了一盏灯：绿灯表示正在干活，黄灯表示在等待用户回话。设计意图很直接——用颜色编码降低用户的认知负荷。但灯会撒谎：明明Agent还在跑长任务，灯却变黄了，活没干完就把用户喊了过来。

这个问题很典型。在多Agent系统中，状态同步往往比单个Agent的执行逻辑更难处理。长任务的心跳、超时阈值、事件回传顺序，任何一个环节出错都会导致UI状态与真实状态脱节。据Claude Opus 5.5自述，它翻日志找出三处问题并逐一改掉。261次提交的背后，大量工作可能就花在这类“状态对齐”的脏活上，而非Agent本身的能力提升。

状态同步是多Agent系统中的经典难题。单个Agent执行长任务时，界面需要判断它究竟处于“运行中”还是“等待输入”，这通常依赖心跳（heartbeat）机制与超时阈值：Agent定期上报存活信号，超过阈值未上报则被判定为等待或空闲。但长任务的执行时间可能远超预设阈值，导致UI误判为“黄灯”。此外，事件回传的顺序若与状态变更不一致，也会造成界面显示滞后于真实状态。因此，成熟的多Agent工作台往往需要区分“任务级状态”和“Agent级状态”，并用事件溯源（event sourcing）保证UI与后端状态最终一致，而非仅靠一次轮询或单一信号判断。

排队机制：书页式交互的取舍

用户还提过一个需求：Agent太多了，能不能排成队一个一个来。于是有了“书页”设计——谁在等用户，谁就排成一页；用户回完一个，下一页自己翻过来。

这是一种把并行转为串行的交互妥协。好处是用户注意力聚焦，不会被多个Agent同时索要输入而打断；代价是整体吞吐下降，后台Agent的等待时间变长。书页机制适合“人机回合制”场景，比如代码审查、文案确认，但不适合需要实时协调的任务链。设计者需要在“用户舒适度”和“系统效率”之间做显式权衡，而不是默认并行或默认串行。

书页式串行排队本质上是一种“人在回路”（human-in-the-loop）的调度策略。它将并行Agent的输入请求汇聚为一个队列，按到达顺序逐个呈现给用户，从而把用户的认知负荷从“同时处理多个中断”降为“一次处理一个”。这种设计在交互工程中常见于通知聚合与任务收件箱。其代价是队列等待时间随Agent数量增长，对于需要Agent之间实时协调的任务链（如一个Agent产出、另一个立即消费）会造成阻塞。是否采用串行，取决于任务对时延的敏感度以及用户处理输入的吞吐能力，而非单纯的系统效率指标。

25天261次提交：单窗口协作的真实成本

25天、261次提交，平均每天超过10次代码变更。对于一个多Agent窗口项目，这个节奏说明迭代主要发生在边界处理和交互细节上：搬进搬出的兼容问题、状态灯的准确性、排队翻页的时机。

有意思的是，五个Agent共处一个窗口后，用户的使用逻辑变成了“谁的灯黄了就先敲谁的门”。这条规则简单有效，但也意味着用户仍需主动巡检。真正成熟的多Agent界面，或许应该主动聚合待办、按优先级推送，而不是依赖用户盯灯。

一条家规背后的教训

最耐人寻味的细节是那条只给Claude Opus 5.5定的家规：不许碰自己那一个。原因是在修输入法那天，它手太快，把用户正写给它的一句话删掉了几个字。

这个事故点出了Agent权限设计的核心矛盾：Agent需要足够的操作权限来完成任务，但过度授权会让它误伤用户正在编辑的内容。在多Agent共享同一窗口时，输入区、状态区、日志区的隔离必须明确，否则一个Agent的“顺手修复”就可能破坏另一个上下文。家规是一种事后补丁，更系统的做法是权限分区和操作审计。

从“一人一窗”到“合租公寓”，这个项目展示的多Agent协作不是模型能力的堆叠，而是界面、状态、权限、排队规则的一体化工程。261次提交换来的经验，对正在构建Agent工作台的开发者有直接的参考价值。

Agent权限设计通常遵循最小权限原则（principle of least privilege）：每个Agent只应获得完成其任务所必需的操作范围，而非整个共享环境的读写权。在多Agent共享同一窗口时，输入区、状态区、日志区应在数据层面隔离，Agent对用户正在编辑的输入内容只能读取、不能写入或删除。更系统的做法包括操作审计（记录每次写入的来源与内容）和沙箱化（将Agent的编辑行为限制在独立副本上，经确认后再合并）。这类机制在浏览器自动化、代码助手等场景中已有实践，目的是在赋予Agent行动能力的同时，防止其“顺手修复”破坏用户上下文。