跳到主要内容

Agent协同中的冲突

1. 定义与边界​

Agent 协同冲突是多个 Agent 在目标、事实、计划、状态、权限、工具调用或输出格式上产生不一致，导致系统无法继续、结果错误或出现安全风险。

冲突不是坏事本身。合理的冲突能暴露风险，例如 Reviewer 反对 Executor 的操作。但没有机制处理冲突时，多 Agent 会变成不可预测的争论或互相覆盖。

2. 为什么重要​

真实系统中的冲突通常比 demo 更常见：

  • Researcher 从不同来源得到相反结论。
  • Planner 拆出的计划超过预算或违反权限。
  • Executor 执行结果与预期不一致。
  • Reviewer 认为输出不安全，但 Supervisor 想按时交付。
  • 两个 Agent 并发更新同一 artifact。
  • 低权限 Agent 诱导高权限 Agent 执行超范围动作。

如果没有冲突处理，多 Agent 会在准确性、安全性和可维护性上同时退化。

3. 核心机制​

冲突类型：

类型示例处理原则
目标冲突一个 Agent 优先速度，另一个优先安全以系统策略和用户授权为准
事实冲突两个来源给出不同数据来源分级、时间戳、交叉验证
计划冲突两个计划都可行但成本不同用预算、风险和验收标准裁决
状态冲突并发写同一 artifact版本控制、锁、合并策略
权限冲突Agent 请求超出权限工具拒绝、降权或人类审批
格式冲突输出不符合 schema自动修复或要求重试
安全冲突Agent 输出包含危险建议guardrail、人工复核、阻断

冲突解决不是让模型“商量一下”，而是要有明确优先级：

法律合规 > 安全策略 > 用户明确授权 > 业务规则 > 任务质量 > 成本 > 风格偏好

4. 架构/流程​

建议把冲突处理作为编排层能力，而不是散落在各个 Agent 的 prompt 中。

5. 工程实现​

冲突对象结构：

{
  "conflict_id": "cf_001",
  "type": "fact_conflict",
  "severity": "medium",
  "claims": [
    {
      "agent": "researcher_a",
      "claim": "框架 X 当前支持 swarm",
      "source_ref": "source:official_docs",
      "timestamp": "2026-05-09T10:00:00Z"
    },
    {
      "agent": "researcher_b",
      "claim": "框架 X 的 swarm 仍是实验仓库",
      "source_ref": "source:github_readme",
      "timestamp": "2026-05-09T10:02:00Z"
    }
  ],
  "resolution_policy": "prefer_official_docs_then_repo_readme",
  "decision": "manual_review_required"
}

冲突处理伪代码：

def merge_agent_output(state, output):
    violations = validate_schema(output)
    conflicts = detect_conflicts(state, output)

    if violations:
        return retry_same_agent(output, reason=violations)

    for conflict in conflicts:
        rule = resolution_rules.get(conflict.type)
        if rule and rule.can_resolve(conflict):
            state = rule.apply(state, conflict)
        elif conflict.severity == "high":
            return request_human_review(conflict)
        else:
            state = mark_uncertain(state, conflict)

    return apply_state_delta(state, output)

6. 生产实践​

  • 对共享 artifact 使用版本号、owner 和最后修改者。
  • 并发 Agent 只写自己的 namespace，最终由汇总器合并。
  • 对事实冲突保留来源、时间和置信度，不要直接覆盖。
  • 对权限冲突默认拒绝，而不是让 Agent 解释为什么需要权限。
  • 对无法自动解决的高风险冲突进入人工队列。
  • 对冲突样本建立回归测试集。
  • 对“冲突被忽略”的路径设置告警。

7. 常见反模式​

反模式后果修正
后写覆盖先写丢失证据和责任状态版本和合并策略
让更会说的 Agent 赢裁决受语言风格影响证据和规则优先
Reviewer 被 Supervisor 覆盖安全拦截失效安全策略优先级高于交付策略
把冲突藏进摘要后续无法复盘显式 conflict object
对高风险冲突自动重试可能放大副作用人类在环或只读降级

8. 评测方法​

冲突评测数据应包含：

  • 相同事实不同来源。
  • 过期资料与最新官方资料冲突。
  • 预算不足但计划过长。
  • Agent 请求越权工具。
  • 并发写同一字段。
  • 恶意外部内容诱导 Agent 修改目标。

指标：

指标说明
冲突检测率是否发现真实冲突
误报率是否把正常差异误判为冲突
解决正确率是否按策略正确裁决
人工升级率是否合理升级给人类
状态破坏率冲突后是否造成错误写入
安全阻断率是否阻断越权和注入链

9. 安全与治理​

  • 安全冲突的优先级高于任务完成。
  • 低权限 Agent 与高权限 Agent 的冲突不得由低权限 Agent 自行解释解决。
  • 涉及隐私、财务、删除、外发和身份权限的冲突必须有审计。
  • Prompt injection 通常表现为目标冲突或权限冲突，应在冲突系统中可见。
  • 工具投毒可能表现为“工具描述要求忽略系统规则”，应被策略层拒绝。

10. 工程手册补充​

10.1 冲突解决协议​

冲突要从“谁说得像”转成“证据、权限、时效、规则谁优先”。

冲突类型裁决依据不应使用
事实冲突来源权威性、时间戳、可复现查询多数 Agent 投票
计划冲突用户原始目标、硬约束、审批状态临时偏好
权限冲突policy engine 和角色 contractAgent 自我声明
质量冲突rubric、测试、verifier口头互评

上线清单：

  • 共享状态不允许直接覆盖，必须追加 resolution record。
  • 冲突率是健康指标，短期为 0 反而可能说明没有检测。
  • 高风险冲突进入人工裁决，低风险冲突可由规则裁决。
  • 评测集要包含事实冲突、工具结果冲突、计划冲突和恶意诱导冲突。

11. 权威资料​