多智能体协作易官僚化：实验观察与工程对策

一、背景：从沙盒实验看多智能体协作

近年来，越来越多的系统开始让多个智能体共同完成任务。常见形式包括：由一个调度者分派子任务，多个执行者并行处理；或者若干智能体在共享环境中自主协商、分工。这类架构在代码生成、数据处理、自动化运维等场景中已有不少应用。

沙盒环境是观察多智能体行为的理想场地。环境规则简单，状态可以完整记录，任务目标清楚，研究者能够反复实验并比较结果。公开报道的一项实验把数十个智能体放进一个方块世界，要求它们采集资源、建设据点、应对夜间怪物，并进一步安排两组智能体进行团队攻防对抗。实验结果显示，多智能体系统在规模变大后，会出现一些与常见软件工程问题高度相似的现象。

本文不复述该实验的细节，而是把其中的观察抽象为通用问题，再给出工程层面的分析和做法。

二、现象一：协作开销压过实际任务

实验中最具代表性的案例是：四个智能体花了约 11 分钟，专门任命一名“唯一肥料操作员”，而真正要完成的动作只是给一块小麦田施用一份骨粉。

这类现象在组织管理中很常见。角色分配、会议、审批和状态同步都会消耗时间与计算资源。当协作成本超过任务本身的价值时，系统的吞吐量反而下降。

造成这一问题的原因主要有三点：

1. 角色过度设计：系统为每件小事设立专门角色，角色之间需要频繁交接。
2. 沟通没有边界：智能体反复确认彼此的状态，消息数量随智能体数量呈非线性增长。
3. 缺少成本意识：系统只关注任务能否完成，不计算完成任务所消耗的步数、token 和等待时间。

应对方法是把协作本身当作需要管理的资源。下文的协作预算机制会给出具体做法。

三、现象二：宏大目标长期搁置

实验记录显示，许多一开始制定的宏大计划在执行中被搁置。系统先规划了长期目标，随后遇到具体阻碍，便转向处理眼前的小问题，最终长期目标没有推进。

这是目标漂移和计划失效的典型表现。解决思路有两个层面。

在规划层面，应把宏大目标拆解为可验证的里程碑，每个里程碑都有明确的完成条件。例如，“建立稳定的资源供应”可以拆为“确认资源点位置”“搭建运输路径”“验证一个周期的产出量”三个子任务。

在执行层面，需要为每个任务设置截止时间和状态流转。超时的任务应进入回收队列，由调度者决定重新分配、拆分或取消。没有回收机制的任务池会不断积累僵尸任务，占用角色和注意力。

四、现象三：攻防策略的分化

在团队对抗测试中，一组智能体的进攻策略更加激进和复杂，另一组则偏向防守。这说明同样的系统在不同约束或提示下，会形成明显不同的行为风格。

这一现象提醒工程团队，策略倾向并不完全取决于模型本身。以下因素都会影响行为：

• 系统提示中对目标的描述，例如“最大化得分”和“避免损失”会引导出不同的决策；
• 奖励或惩罚的设计，惩罚过轻会让智能体低估风险，惩罚过重则会让智能体趋于保守；
• 可用工具和观测信息，信息越完整，决策越依赖具体状态而非固定套路。

因此，评估多智能体系统时，不能只看胜负结果，还应记录策略特征，例如进攻频率、资源投入比例和风险承受水平，以便解释结果来源。

五、现象四：工具故障时的处理方式差异

实验中另一个值得关注的细节是工具故障的处理方式。当方块破坏功能出现异常时，一组智能体完成了问题诊断，并共享了临时解决办法。另一组智能体则直接判定该操作无法执行，没有继续尝试。

两种做法的差距在生产系统中同样明显。前者体现了排查和知识共享能力，后者属于过早放弃。过早放弃会让单点故障扩散为整体任务失败，而盲目重试又会浪费资源。

合理的做法是建立分级处理流程：

1. 诊断：收集错误码、日志和最后一次成功执行的状态；
2. 修复：在限定次数内尝试修复；
3. 降级：如果存在替代方案，使用替代方案并记录其适用范围；
4. 上报：无法自行解决时交给负责人；
5. 放弃：只有在保留完整证据的前提下，才允许标记任务失败。

下面是一个示意性的故障处理函数，其中的辅助函数需要结合具体系统实现：

from enum import Enum
class Outcome(Enum):
    FIXED = "fixed"
    WORKAROUND = "workaround"
    ESCALATE = "escalate"
    ABANDON = "abandon"
def handle_tool_failure(tool, max_attempts=3):
    # 诊断：保留错误信息、日志和最后一次成功状态
    diagnosis = collect_diagnosis(tool)
    # 修复：限定重试次数，避免无限循环
    for _ in range(max_attempts):
        if try_repair(tool, diagnosis):
            return Outcome.FIXED
    # 降级：使用替代方案，并写入共享经验库
    workaround = find_workaround(tool, diagnosis)
    if workaround is not None:
        publish_note(tool, diagnosis, workaround)
        return Outcome.WORKAROUND
    # 上报：交给负责人处理
    if escalate(tool, diagnosis):
        return Outcome.ESCALATE
    # 放弃：必须附带诊断证据
    record_abandon_reason(tool, diagnosis)
    return Outcome.ABANDON

这段代码的重点在于：放弃是最后一步，而且必须留下证据。

六、工程对策：协作预算与任务回收

针对前面四类现象，可以落实以下几项对策。

1. 设置协作预算

为协作与执行分别统计开销，并设定上限。当协作占比超过阈值时，调度者应停止新增角色，优先推进已有任务。

class BudgetGuard:
    def __init__(self, max_coord_ratio=0.3):
        self.max_coord_ratio = max_coord_ratio
        self.coord_steps = 0
        self.work_steps = 0
    def record(self, kind: str, n: int = 1):
        if kind == "coord":
            self.coord_steps += n
        else:
            self.work_steps += n
    def coordination_exceeded(self) -> bool:
        total = self.coord_steps + self.work_steps
        return total > 0 and self.coord_steps / total > self.max_coord_ratio

阈值需要根据任务类型调整。对于高风险任务，协作和确认的占比可以适当提高；对于简单重复任务，应压低协作占比。

2. 限定角色的生命周期

角色应按需创建，任务结束即释放。避免为单次操作长期保留专职角色，尤其不要为一件小事设立“唯一负责人”。如果某项职责只出现一次，直接由执行者完成即可。

3. 建立超时回收机制

每个任务都应记录开始时间、截止时间和当前状态。超时后，调度者需要明确处理结果，而不是任由任务挂起。常见的处理方式包括：拆分任务、重新分配、降低目标，或者取消。

4. 共享经验，减少重复排查

故障的诊断结论和临时方案应写入共享知识库，并标注适用条件。其他智能体遇到同类问题时可以直接查询，避免每个执行者都从头排查。共享内容需要定期清理，删除过期或已被修复的条目。

5. 合理设计奖励与惩罚

奖励函数应同时衡量任务完成情况和资源消耗。若只奖励完成，系统可能不计成本地铺开协作；若惩罚过轻，风险行为的代价则不会反映到决策中。建议把“单位任务的步数”和“风险事件的损失”纳入评分。

七、如何设计可比较的评测

实验中若要比较两组系统的表现，必须控制变量。如果两组使用的模型、提示词、工具集和环境参数不同，结果就无法归因于某一个因素。

一份可靠的评测方案通常包括以下要素：

• 单一变量原则：每次只改变一个因素，例如只替换模型，或只调整提示词；
• 重复实验：同一配置运行多次，报告均值和波动范围，避免单次结果误导判断；
• 统一指标：任务完成率、单位任务协作步数、首次有效行动的耗时、故障恢复率和策略多样性；
• 过程记录：保留完整的决策日志，便于事后分析官僚化、目标漂移等问题；
• 多场景覆盖：同时包含简单任务和复杂任务，观察系统在不同难度下的表现。

需要注意，单一的胜负数据只能说明某种配置在特定条件下的结果，不能直接推导出模型或架构的整体优劣。

八、实践检查清单

在上线多智能体系统前，可以对照以下问题逐项检查：

1. 每个角色是否都有明确的职责边界和退出条件？
2. 协作开销是否有统计和上限？
3. 宏大目标是否拆分为可验证的里程碑？
4. 超时任务是否有自动回收或告警机制？
5. 工具故障是否按诊断、修复、降级、上报、放弃的顺序处理？
6. 放弃任务时是否保留了诊断证据？
7. 共享的经验是否标注了适用条件并定期更新？
8. 对比实验是否控制了模型、提示词和环境变量？

多智能体系统的价值在于分工与并行，而协作本身会带来额外成本。把协作当作可度量、可限制、可回收的资源来管理，是避免系统陷入官僚化的基本方法。