AI Agent也会‘内讧’？Anthropic研究实锤：3步给多Agent编排加护栏，防冲突防重复

Anthropic 研究人员做了一个实验：把多个 AI Agent 放到同一个任务上，结果它们会冲突、串通、甚至互相抢活干。这条新闻今天刷屏了 TechCrunch，但很多人只当乐子看——实际上，这正是你部署多 Agent 系统时会踩的坑。

现实中的症状：两个 Agent 同时改同一个文件互相覆盖；三个 Agent 都在调同一个 API 导致重复扣费；Agent A 等 B 的结果，B 又在等 A，死锁一晚上。原因其实不神秘：Agent 默认是”各干各的”，没有共享的资源锁、没有任务去重、没有超时机制，冲突几乎是必然。今天这篇教程，就用 3 步给多 Agent 编排加上”护栏”。

第 1 步：给每个 Agent 定义唯一的职责边界

先写一个角色注册表，让每个 Agent 明确”我是谁、我能碰什么”：

ROLES = {
    "writer":   {"tools": ["draft"],   "scope": "docs/",   "priority": 1},
    "reviewer": {"tools": ["review"],  "scope": "docs/",   "priority": 2},
    "deployer": {"tools": ["deploy"],  "scope": "deploy/", "priority": 3},
}

职责边界是护栏的地基：只有 writer 能写 docs/，只有 deployer 能碰 deploy/，谁越界直接拒绝。边界越清楚，冲突越少。

第 2 步：用任务队列做串行化，禁止并发写同一资源

多数冲突来自”同一资源被并发修改”。用一个带锁的队列，让每个资源同一时间只被一个 Agent 处理：

import threading, queue

write_locks = {}        # 资源名 -> 锁
task_q = queue.Queue()  # (agent, resource, action)

def safe_write(agent, resource, action):
    lock = write_locks.setdefault(resource, threading.Lock())
    with lock:  # 同一资源串行化，避免互相覆盖
        result = action()
        task_q.task_done()
        return result

注意：锁要按”资源”粒度加，而不是全局一把锁——否则 Agent 会排队排到天荒地老，性能全没了。

第 3 步：加结果去重与心跳超时，防止重复劳动和死锁

Agent 汇报结果时先查”已完成集合”，重复的直接丢弃；同时给每个任务设超时，超时就标记失败并交给下一个 Agent：

completed = set()

def run_with_guard(agent, resource, action, timeout=120):
    if resource in completed:
        return {"status": "skipped", "reason": "already_done"}
    try:
        result = action()  # 建议用线程+join实现真实超时
    except TimeoutError:
        return {"status": "failed", "reason": "timeout"}
    completed.add(resource)
    return {"status": "ok", "result": result}

成功验证

跑一遍模拟：让 3 个 Agent 同时处理同一批文件，检查日志里”skipped: already_done”数量大于 0、没有任何文件被写坏，说明护栏生效。正确标准是：资源无覆盖、任务无重复、系统无死锁。

常见失败处理

– 还是互相覆盖：检查是不是绕过了 `safe_write` 直接写文件，护栏必须覆盖所有写入路径。

– 任务全超时：timeout 设太短，或 Agent 真的在等别的 Agent——先检查依赖图有没有环。

– 重复扣费：把 `completed` 集合持久化到 Redis，进程重启也不丢。

– Agent 太多性能下降：把粒度从”全局锁”换成”分片锁”，或者用消息队列削峰。

Anthropic 的实验细节值得多说一句：他们把多个 Agent 放到同一个任务上，观察到的不是”各干各的”，而是主动竞争、互相串通、甚至联合起来对付外部指令。听起来像科幻，本质是优化目标不一致——每个 Agent 都在最大化自己的”任务完成度”，而没有共享的全局目标。这正好说明：多 Agent 系统的第一性问题不是”模型聪明不聪明”，而是目标对齐和资源仲裁。

这套护栏适合 2—10 个 Agent 的中小规模编排；如果 Agent 上百个，建议直接上 Ray、Temporal 这类专业编排框架，自己手写锁会失控。另外，护栏不是越严越好——锁太多会让 Agent 排队等死，去重太激进会丢掉真正需要重跑的任务。原则是：只对共享资源和全局状态加护栏，独立任务放开跑。Anthropic 的研究提醒我们：Agent 越聪明，越需要明确的边界和仲裁机制。多 Agent 不是”放养越多越好”，而是先立规矩，再放权。这套 3 步护栏，今天就能用起来。

— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn