AI代理互怼：多智能体协作的陷阱与解法

两个AI代理接到了一个简单任务：研究某个主题并写一份摘要。结果呢？第一个代理搜索了公司信息，第二个代理也搜索了同样的信息。接着第一个代理觉得摘要写得不对，重写了一遍；第二个代理不同意，又改了回去。27次API调用后，你得到了一张3美元的账单和一份比免费版ChatGPT还差的摘要。

这就是多智能体协作——那些炫酷演示从不告诉你的真相。

多智能体系统的隐秘痛点

多智能体系统有一个很少被提及的秘密：两个代理协作，往往比一个代理单干更糟。

问题不在于单个代理能力差，而在于没人告诉它们如何避免互相踩脚。想象一下大学里的小组作业：五个聪明人，零协调，截止前一分钟Google Doc上十七个冲突的编辑版本。多智能体AI系统以完全相同的方式失败：代理A获取数据，代理B获取相同的数据（因为没人告诉它A已经做过了）；代理A格式化回复，代理B用不同方式重新格式化。它们循环、重复、矛盾——你的token账单飙升，质量却下降。

多智能体系统（Multi-Agent System） 指由多个自主 AI 代理组成、通过消息传递或共享状态协同完成任务的架构。每个代理通常拥有独立的系统提示词、工具集和上下文窗口。与单代理相比，多代理的卖点是“专业化分工”——研究员负责检索、写手负责生成。但代价是引入了协调开销：代理之间没有共享记忆，无法感知彼此已执行的动作，因此极易出现重复劳动、写冲突和无限循环。学术上常把这类失败归类为“协调失败”（coordination failure），其 token 成本随代理数量呈超线性增长，而输出质量却可能因相互覆盖而下降。

“再加一个代理”为何是个陷阱

“需要研究和写作？加一个研究员代理和一个写手代理！”这个宣传很诱人，但缺乏协调时实际发生的情况是：

# 你期望的
researcher_result = researcher.run("查找Acme公司Q3营收")
writer_result = writer.run(f"总结这段内容: {researcher_result}")

# 实际发生的
researcher_result = researcher.run("查找Acme公司Q3营收")
# 写手忽略researcher_result，自己又搜了一遍
# 研究员看到写手的草稿，觉得不对，重新研究
# 循环直到达到最大迭代次数或钱包告急

解决方案不是去掉代理，而是加入一个比AI更“笨”的东西：契约。

契约胜过智能

反直觉的真相是：最好的多智能体系统不是拥有最聪明代理的系统，而是拥有最严格交接规则的系统。

一个最小化的协调契约可以阻止80%的多智能体混乱：

class AgentContract:
    def __init__(self):
        self.completed_tasks = {}
        self.ownership = {}

    def claim_task(self, agent_id: str, task: str) -> bool:
        """只有一个代理能拥有任务，禁止重复。"""
        if task in self.ownership:
            return False  # 已被认领
        self.ownership[task] = agent_id
        return True

    def submit_result(self, agent_id: str, task: str, result: str):
        """一旦提交，任务即完成，其他代理不得重写。"""
        if self.ownership.get(task) != agent_id:
            raise ValueError(f"{agent_id}不拥有任务{task}")
        self.completed_tasks[task] = result
        return True

    def get_result(self, task: str) -> str:
        """只读访问已完成的工作。"""
        return self.completed_tasks.get(task, None)

没有机器学习，没有嵌入向量，没有向量数据库。只有一个字典，声明“这个任务属于这个代理，一旦完成就是完成了”。

契约式协调（Contract-based Coordination） 借鉴了分布式系统中的“租约”（lease）和“所有权”（ownership）思想：任何共享资源在任一时刻只能有一个写入者，且写入前必须先获得租约。在 AI 代理场景中，这意味着用一个轻量的状态存储（字典、Redis 或数据库表）记录“任务→代理”的映射，代理在执行前先原子性地“认领”任务，完成后标记为不可变。由于不依赖语义理解或嵌入相似度判断，契约机制几乎零延迟、零幻觉，且行为完全可预测——这正是它比“让代理自己商量”更可靠的原因。

三条规则解决多智能体混乱

观察了数十个多智能体配置后，以下是真正有效的规则：

规则一：先认领，再工作。 每个代理必须在开始前调用claim_task()。如果已被他人认领，就跳过。零重复。

规则二：一个写手，多个读者。 认领任务的代理是唯一写入结果的代理，其他人通过get_result()获得只读权限。没有冲突编辑。

规则三：分歧向前，不向后。 如果代理B认为代理A的结果有误，它不直接重写，而是创建一个新任务——"revision_of_research"——认领它并写入改进版本。审计线索保持清晰，你能真正调试发生了什么。

contract = AgentContract()


**只读访问（Read-only Access）** 是防止冲突编辑的关键手段。在多代理系统中，如果多个代理都能写入同一份结果，就会出现“最后写入者获胜”的覆盖问题，且难以追溯谁改了什么。通过 `get_result()` 返回不可变副本，其他代理只能读取而不能修改，任何改进都必须以新任务的形式提交。这与 Git 的分支模型类似：主干只读，修改走新分支，从而保留完整的审计线索，让调试从“猜哪个代理改坏了”变成“查看任务历史”。
# 研究员认领并完成研究
contract.claim_task("researcher", "find_q3_revenue")
data = researcher.run("查找Acme公司Q3营收")
contract.submit_result("researcher", "find_q3_revenue", data)

# 写手只读研究结果，认领写作任务
research = contract.get_result("find_q3_revenue")
contract.claim_task("writer", "write_summary")
summary = writer.run(f"总结: {research}")
contract.submit_result("writer", "write_summary", summary)

# 如果写手不同意研究结果，它提交新任务
contract.claim_task("writer", "research_revision_request")
contract.submit_result("writer", "research_revision_request",
    "Q3营收数据似乎过时——请重新核查")

令人不安的真相

大多数团队根本不需要多智能体系统。一个精心设计提示词、工具齐全的单代理，在90%的使用场景中都能每次都击败两个陷入循环争论的代理。

多智能体协调只有在以下情况才值得：你确实有需要不同系统提示词、不同工具集或不同信任边界的任务。如果你的“研究员”和“写手”可以是同一个代理通过两个不同的函数调用来完成，那你根本没有多智能体问题，你只有一个带任务列表的单代理。

代理本身不是难点，协调才是。而最好的协调看起来一点都不像AI，反而更像无聊的软件工程。

你是否有过在生产环境中真正保持协调的多智能体系统？哪种交接模式拯救了你？欢迎在评论区分享你的配置——我尤其好奇代理数量，以及契约和消息队列哪个效果更好。

信任边界（Trust Boundary） 指系统中不同组件被授予不同权限与信息访问范围的划分。在多代理架构中，信任边界是判断是否真正需要多代理的核心标准之一：如果某类任务涉及敏感数据、需要独立审计，或必须使用受限工具集，那么把它隔离到独立代理中是合理的；反之，如果所有代理共享相同的工具和权限，那么多代理只是增加了协调成本而没有带来隔离收益。实践中，团队常误把“提示词不同”当作多代理的理由，但单代理通过函数调用切换提示词即可达到同样效果。