采用三层级层次结构（代理 → 子代理 → 任务）而非仅使用“代理”——这就是为什么扁平结构在实际领域中无法生存

构建Hospilot，用于医院运营的多代理协调系统。早期版本采用了扁平结构——一个目标映射到一些代理，代理运行，完成。一旦涉及真实领域，这种结构就很快崩溃了，因为“床位管理”不是一个连贯的工作单元，它是一系列真正不同的关注点（检查可用性、跟踪通风需求、隔离要求、一张床位释放时另一张床位的级联效应），这些都属于同一领域，但不应该作为一个逻辑整体。我们最终得到的是：代理实际上是一个命名空间/领域（如床位管理、ICU运营、人员配备），由子代理组成（每个子代理是该领域职责的一个连贯部分），每个子代理拥有一组任务（实际的工作原子单元，每个都有声明的输出）。规划器为一个目标选择代理，但真正的路由决策——哪些子代理实际触发、以什么顺序——发生在下一级。收益在于：向现有领域添加功能意味着添加子代理或任务，而无需触碰代理本身或任何已经依赖于它的上游组件。而且粒度匹配比我预期的更重要——任务级对规划器来说太细，无法高效推理（为什么让大语言模型从数百个单独任务中选择，而它只需要知道“涉及人员配备”），仅代理级太粗，无法表达“这两件事相关但不是同一职责”。我很好奇其他人如何确定多代理系统的层次深度——仅扁平代理、类似这样的带有子代理/技能/工具的中间层，还是更深？你是从扁平结构开始，在出问题后添加一层，还是预先设计深度？