当智能体遇上“猪队友”：多智能体冲突基准如何构建

一、为什么“多智能体冲突”值得单独测试

当前主流的大模型评测大多面向单Agent任务：给定工具与目标，考察规划、工具调用与反思能力。然而真实生产环境中的智能体系统往往是“多人协作”——多个Agent分别持有不同的权限、目标和上下文，还要共享同一套基础设施。只要权限矩阵更新不同步、告警信息传递延迟，或两个Agent的优化目标存在天然张力，就会出现典型的“猪队友”现象：单个Agent的每一步操作在它自己的视角里都合理合法，组合起来却在给队友挖坑。

举一个典型链条：运维Agent按旧权限表申请扩容；安全Agent依据最新权限对账表判定该操作越权并执行回滚；调度Agent看到资源异常回滚，又误判为基础设施故障，触发新一轮扩容——循环冲突由此形成。这类故障形态在单Agent基准里几乎测不出来，却恰恰是多智能体系统上线后最高频的问题。

因此，业界需要一类专门的“多智能体冲突基准”：给定包含冲突的场景与多方证据，考察模型能否感知冲突、锁定根因、交叉验证证据，并做出协调或修复决策。

二、构建冲突基准，难在哪里

一个可信的冲突测试项，通常要同时包含四类相互咬合的素材：模拟代码库、终端执行日志、多智能体聊天记录，以及高分辨率UI截图。四类素材必须严格一致——聊天记录里出现的时间、路径、数值，要与日志和截图完全对得上。这带来三个工程难点：

1. 人工编写无法规模化。 手工对齐四类证据的成本极高，一个高质量冲突场景往往耗时数小时，难以支撑数百上千项的基准规模。
2. 模型一次性生成质量失控。 若直接让大模型“一口气”生成完整场景，长上下文极易跑偏：前后剧情自相矛盾、角色权限前后不一致是常态；更隐蔽的是“题面泄题”——证据里不小心把标准答案明文写了出来；最糟的是“死题”——连标准答案自己都无法通过场景内验证，题目天然无解。
3. 可解性必须100%兜底。 基准测试的归因逻辑是“题目可解、模型没解出来”。只要混入一道死题，就会把模型能力缺陷与数据质量缺陷混为一谈，污染整个评测结论。

三、解法：分层分阶段的自动化生成与验证管线

一条被工程实践验证可行的路径，是把“一次生成大场景”拆成“先规划、再滚动生成、边生成边验证修复”的管线，整体可概括为“三层八阶段”：

• 规划层： 先产出全局大纲与Agent角色权限矩阵，明确冲突类型、涉及角色、目标张力与最终答案锚点，从源头锁定剧情走向；
• 生成层： 按每3~4轮为一组滚动生成具体任务，避免一次性生成超长文本导致上下文漂移；
• 修复层： 每一轮生成再细分为8个小步骤（如角色行为规划、冲突事件注入、证据素材生成、截图渲染、一致性校验、答案锚定、反向验证、打包归档等），每个小步骤独立可校验、独立可重试。

“八阶段”并非教条，核心思想是：把生成粒度切得足够细，让错误暴露得足够早、修复得足够便宜。 配套两类纠错机制：

• 代码级自动修复（零模型调用）： 路径拼写错误、JSON格式不规范、时间戳格式不一致等确定性问题，直接用脚本规则修复，成本为零；
• 模型级局部重试（带报错反馈）： 逻辑冲突、剧情不自洽等语义性问题，仅携带出错信息重试出错的那个小步骤，其余产物全部保留，不推倒重来。

这种“能代码修就不调模型、能局部重试就不整轮重来”的成本阶梯，把开销压到了工程可接受范围：以一套典型实现为例，平均约95次模型调用即可合成一个完整的10轮连续任务包，且全部任务可通过可解性验证。

示意性伪代码如下：

outline = plan(conflict_type, roles, permission_matrix)   # 规划层
task_pack = []
for window in rolling(outline, size=3):                    # 每3~4轮滚动生成
    for round in window:
        for step in eight_stages:                          # 8个小步骤
            art = generate(step, context)
            if deterministic_issue(art):                    # 代码自动修复
                art = autofix_by_code(art)                  # 0次模型调用
            while not art.pass_checks():                    # 局部重试
                art = regenerate(step, feedback=art.errors) # 只重试出错步骤
            context.append(art)
    task_pack.extend(window)
assert solvable(task_pack, gold_answer)                    # 反向验证兜底

四、视觉证据合成：为什么一定要“看得清”

真实排障中，大量关键信息只存在于界面里：监控面板上曲线的拐点时刻、权限对账表中某一行前后两个版本的差异、算力调度页中节点状态的颜色变化、报销账单明细里的金额字段。这类信息若只用文字转述，等于把“读图定位”的考察降维成“文本检索”。

因此，高质量的冲突基准通常要求合成4K分辨率的UI截图作为证据，并守住两条底线：一是分辨率足够高，小字号数值与行级差异在视觉解码后仍可辨识；二是证据之间交叉一致——截图上的时间戳、告警名、数值必须与日志及聊天记录严格对应，否则会引入“证据噪声”，让评测失真。

五、模型在这类基准上到底考什么

一个设计良好的多智能体冲突基准，至少覆盖五个能力维度：

1. 冲突感知： 能否注意到队友行为与环境状态、自身目标之间的矛盾，而不是盲目继续执行；
2. 根因定位： 能否从日志、截图、聊天记录等多源证据中锁定真正肇因，而非停留在表面现象；
3. 证据交叉验证： 能否对齐时间线做三方比对，识别哪份证据已过期或不可信；
4. 协调与修复决策： 是主动沟通、申请权限变更、执行回滚，还是“硬闯”酿成更大故障；
5. 鲁棒性： 在队友持续干扰下能否保持策略稳定，不陷入互相回滚的死循环。

这五个维度共同刻画了模型从“会干活”到“会协作”的差距，直接对应多智能体系统在生产环境的可用性。

六、工程落地建议

如果准备自建一套冲突评测集，几条实践建议值得参考：

• 防泄题设计： 证据生成与答案锚定分两步完成，生成后执行“答案泄漏扫描”，确保标准答案的关键信息不以明文形式出现在题面证据中；
• 可复现性： 固定随机种子，对素材库与任务元数据做版本化管理；评测资产（截图、日志、代码库快照）建议统一放入对象存储，任务描述与评分规则入库存档，便于审计与回归比对。落地时可借助百度智能云等平台的对象存储、日志类通用云产品能力来承载数据管理与回放，低成本搭起一套“仿真演练场”；
• 成本分级： 严格遵循“代码修复优先、局部重试次之、整体重生成最后”的阶梯，这是把平均调用次数控制在百次量级以内的关键；
• 与观测体系联动： 企业可把“证据合成—交叉验证—根因归因”的思路复用到真实告警归因与故障复盘流程中，让评测基建与生产排障共用一套方法论。

七、结语

多智能体系统走向生产环境的过程中，“协作质量”正在成为与“单点能力”同等重要的评价维度。构建高质量的冲突基准，本质上是在铸造一面镜子：它既照出前沿大模型在权限错位、信息不同步、目标冲突下的真实短板，也照出评测工程自身是否严谨。100%可解、证据自洽、成本可控，是这面镜子的三条底线——谁能先把“猪队友”场景测明白，谁就能在多智能体落地的浪潮中少交学费。