一种简化的 agent 协作模式：supervisor

现在的多 agent 系统，协调方式基本都围绕"任务"来设计。Anthropic 那篇讲五种协调模式的文章，无论是 orchestrator-subagent、agent teams、message bus 还是

shared state，核心都差不多：协调者要理解任务，负责分解、派发、汇总，或者在 agent 之间传递信息。

这篇文章想说一个更简单的思路：把任务相关的工作全部拿掉，协调者只做一件事——协调资源。

设计

系统里只有三种角色：用户、agent、supervisor。

用户负责把任务拆开，分给不同的 agent，每个任务互不相干。

每个 agent 独立处理自己那份任务。它可以自己开 subagent，但那是它自己的事。

agent 之间不通信，也没有业务往来。

supervisor 不理解任何业务，只做几件确定的事：记录每个 agent 正在用哪些资源；两个 agent 撞上同一个资源时排个队；按用户给的优先级决定谁先谁后；发现某个

agent 掉线了，就把它的资源收回来。

supervisor 本身不承担业务工作，是个很轻的东西。它需要知道的信息只有"谁在用什么东西"，这一小份状态放在外面，随时可以重建。

和 Claude 那篇文章的对比

Claude 那五种模式的共同点，是协调者必须理解任务。orchestrator 要计划、要汇总结果；agent teams 的协调者要分配工作、收集产出；message bus 需要一个路由

器决定事件往哪走；shared state 干脆去掉协调者，让 agent 直接读写共享状态。

supervisor 模式站在另一个角度：协调者不理解任务，只理解资源。任务怎么分、怎么验收，是用户的事；agent 之间怎么交流，在这个模式里直接不需要。

解决了什么问题

这套设计对应几个常见毛病，一个一个说：

1. 
   

   协调者上下文膨胀。协调者不持有业务状态，需要跟踪的信息永远是那一小撮元数据，不会随着工作量变大。上下文不会越滚越大。

   
   


2. 
   

   信息瓶颈。orchestrator 模式里，subagent 之间发现的东西要绕回协调者转发，转几次细节就丢了。这里 agent 之间根本不通信，没有信息需要绕路。

   
   


3. 
   

   共享状态污染注意力。状态放在外部，agent 只按需接触自己那份资源，不会被无关信息带偏。

   
   


4. 
   

   协调者崩溃。协调者自己无状态，挂了不影响 agent 的工作，重启后从外面的状态恢复就行。

   
   


5. 
   

   循环空转。shared state 模式里，agent 会互相读到对方的写入，然后互相触发，烧掉大量 token 却不收敛。这里 agent 之间没有读写关系，这类循环从根上就不存
   
   在。

   
   

实际表现

昨天我简单写了一个程序试了一下, 工作方式如下：

1. 先开一个 codex 充当 supervisor


2. 开多个 codex 充当 slave. 然后让 codex 之间的工作有交叉

最后发现尽管 slave 之间发生了冲突，但是 supervisor 及时纠正了。效果还是很不错的。