多 Agent 协作边界：什么时候该拆角色，什么时候别拆

一个容易犯的错

去年我在做一个代码审查工具时，顺手把「需求分析 → 实现 → 测试 → Review」拆成了四个 Agent。跑起来之后发现，四个 Agent 有 70% 的时间在互相等消息、互相复述上下文。实际干活的 token 不到总量的一半。

多 Agent 看起来像团队协作——分工明确、各司其职。但这种类比有个前提：任务本身的边界足够清楚。如果任务互相纠缠，拆出来的 Agent 只会制造更多上下文传递、更多冲突、更多「你刚才说了什么」的来回。

Beam AI 在 2026 年的一份生产实践报告中给过一个数字：在他们 benchmark 过的任务里，单 Agent 在 64% 的任务上持平甚至优于多 Agent 方案。多 Agent 的平均准确率提升只有 2.1 个百分点，成本大约翻倍。

这不是一篇「多 Agent 不好」的文章。我想讨论的是一个更具体的问题——什么时候该拆，什么时候别拆，拆了之后怎么管住边界。

理论底色：什么时候多 Agent 有意义

Anthropic 在 2024 年底发布的《Building Effective Agents》中给了一条总原则：从最简单的方案开始，只在你有证据表明简单方案不够用时才加复杂度。这条原则听着像废话，但在工程实践中经常被反过来执行——先搭一个多 Agent 架子，然后花三个月调它为什么不能正常工作。

LangChain 在 2026 年初的一篇架构选型文章里把多 Agent 的基本模式分成四类：子智能体（subagents）、技能（skills）、交接（handoffs）、路由（routers）。前两者侧重能力分工，后两者侧重流程分工。不管哪种模式，都有一个共同前提——被拆开的部分必须有独立的输入、独立的输出、独立的验证标准。

Cobus Greyling 在一篇关于多 Agent 设计原则的文章里总结得更直接：避免宽泛的预定义框架，因为这种框架「会塞进不匹配的元素，降低适用性、增加故障点」。模块化拆分的目的是让每个部分都能独立理解、独立测试、独立替换。

arXiv 上 2025 年 6 月的一篇论文《Divide-and-Conquer Is What LLM-Based Multi-Agent System Need》用实验数据验证了一个直觉：多 Agent 辩论（Multi-Agent Debate）在 2 个 Agent 时准确率最高（45.5%），然后随着 Agent 数量增加持续下降到 39%（5 个 Agent）。协作开销的增长速度超过了分工带来的收益。

把这些观点汇总，我得到一个判断框架：

编排模式：从流程图说起

拆完角色之后，下一个问题是：它们之间怎么协作？不同的编排模式决定了上下文怎么流转、冲突怎么处理、最终谁拍板。

这张图涵盖了三种最常见的编排模式。Beam AI 的报告里把它们分得更细，我结合自己的实践经验做了简化：

上下文传递：最容易被低估的问题

多 Agent 系统的难点不在拆分，而在上下文传递。每个 Agent 有自己的上下文窗口，当你把任务从一个 Agent 交给另一个 Agent 时，你实际上在做一次有损压缩。

Anthropic 的研究系统在实践中发现了一个叫「传话游戏」的问题：如果所有信息都要经过编排器中转，编排器的上下文窗口很快就会饱和。他们的解决方案是让工作 Agent 直接写入外部存储，其他 Agent 直接读取，避免信息在编排器那里绕一圈。

# ❌ 所有信息经过编排器中转（传话游戏）
class CentralizedRouter:
    def route(self, task, worker_output):
        # 编排器的上下文不断膨胀
        self.context += worker_output  # 所有工人输出都堆在这里
        next_task = self.plan_next(self.context)  # 越来越慢、越来越贵
        return next_task
 
# ✅ 工人直接写入共享存储，编排器只读摘要
class SharedMemoryBus:
    def __init__(self):
        self.store = {}  # 按任务 ID 分区
 
    def write(self, task_id, output):
        self.store[task_id] = output
 
    def read_summary(self, task_id):
        # 编排器只读摘要，不读原始输出
        return summarize(self.store[task_id])

Galileo AI 在一份多 Agent 协调策略报告里给出了几条具体的工程建议：

• 给每个 Agent 的对话设置最大轮次和超时时间，防止循环消耗。
• 共享存储必须有访问规则——按任务 ID 分区、设生命周期上限、每次写入记录任务 ID。
• 对关键操作设置多 Agent 投票机制，防止单个 Agent 的错误判断直接生效。

# ❌ 无限循环的 Agent 对话
def run_debate(agents, topic, max_rounds=None):
    # 没有上限，可能永远收敛不了
    while not converged(agents):
        for agent in agents:
            agent.respond(topic)
 
# ✅ 有超时、有轮次上限、有不收敛时的退出策略
def run_debate_safe(agents, topic, max_rounds=3, timeout_seconds=120):
    rounds = 0
    while rounds < max_rounds and not converged(agents):
        if time_elapsed() > timeout_seconds:
            return escalate_to_human(topic)  # 兜底
        for agent in agents:
            agent.respond(topic)
        rounds += 1
    return aggregate(agents)  # 取当前最优共识

权限与写入边界

多 Agent 系统里最容易出现的工程问题是写入冲突。两个 Agent 同时修改同一个文件，后写入的直接覆盖前一个的改动。

# ❌ 多个 Agent 写入同一批文件，无协调
class FileWritingAgent:
    def run(self):
        write_file("config.yaml", self.changes)      # Agent A 写了配置
        write_file("src/main.py", self.implementation)
 
class AnotherFileWritingAgent:
    def run(self):
        write_file("config.yaml", self.other_changes)  # Agent B 覆盖了 Agent A 的配置
        write_file("src/utils.py", self.implementation)
 
# ✅ 写入范围按职责严格隔离
class ConfigAgent:
    """唯一有权修改配置的 Agent"""
    allowed_paths = ["config.yaml", "config/*.yaml"]
 
    def run(self):
        for path in self.changes:
            assert path in self.allowed_paths
            write_file(path, self.changes[path])
 
class ImplementationAgent:
    """只能修改 src/ 下的代码文件"""
    allowed_paths = ["src/**/*.py"]
 
    def run(self):
        for path in self.changes:
            assert path_matches(path, self.allowed_paths)
            write_file(path, self.changes[path])

Beam AI 报告中提到的「确定性职责分配」原则也适用于写入边界：每个 Agent 必须有明确的、不重叠的写入范围，拒绝未经授权的重分配。

验收：谁说了算

多 Agent 系统的最后一个边界问题是验收。谁来判断最终产出是合格的？如果让参与工作的 Agent 互相评审，很容易出现「互相认可但没有交付证据」的情况。

我在实践中见过一种模式：实现 Agent 写完代码后，让测试 Agent 跑测试。测试全部通过，任务完成。但测试用例本身可能覆盖了不该覆盖的场景，或者遗漏了关键路径。两个 Agent 共享了同一套理解，它们可能一致地错了。

Anthropic 的多 Agent 研究系统里保留了人工审核环节。他们在报告中写道，自动化验证无法完全替代人工判断——特别是当 Agent 倾向于选择「看起来正确但实际质量不高」的结果时。

# ✅ 验收者独立于生产者，且有独立的验证标准
class AcceptanceGate:
    def __init__(self, producer_agent, verifier_agent):
        self.producer = producer_agent
        self.verifier = verifier_agent
 
    def run(self, task):
        output = self.producer.execute(task)
 
        # 验证者使用不同于生产者的评估标准
        verification = self.verifier.check(
            output,
            criteria=[
                "事实准确性",      # 不是「看起来对不对」
                "来源可信度",      # 不是「有没有来源」
                "逻辑一致性",      # 不是「读起来顺不顺」
                "覆盖完整性",      # 不是「有没有遗漏」
            ],
        )
 
        if not verification.passed:
            # 带着具体反馈回到生产者，不是简单说「不行」
            return self.producer.revise(output, verification.issues)
 
        return output

决策清单

在决定是否拆分 Agent 之前，我通常会逐项检查以下问题。如果有一半以上答案是「否」，就不该拆。

• 每个 Agent 是否有明确的、可以用一句话描述的独立职责？
• 每个 Agent 的输入和输出是否可以形式化定义（不依赖其他 Agent 的内部状态）？
• 不同 Agent 是否需要不同的工具集或权限级别？
• 每个 Agent 的产物是否可以独立验证，不需要看到其他 Agent 的完整上下文？
• 子任务之间是否存在顺序依赖？如果存在，依赖的部分是否有明确的传递契约？
• 是否定义了写入边界（哪些文件/资源每个 Agent 可以修改）？
• 是否有冲突处理策略（当 Agent 的产出矛盾时怎么办）？
• 是否有独立的验收者（不参与生产的角色来判断最终质量）？
• 是否设置了上下文传递的上限（最大轮次、超时、token 预算）？
• 是否有兜底策略（当多 Agent 循环不收敛或超时时的退出机制）？
• 拆分后的总成本（token + 延迟 + 维护复杂度）是否确实低于单 Agent 方案？
• 是否有评测方案能证明多 Agent 方案在目标指标上优于单 Agent？

这个清单不是理论 checklist，是踩坑之后总结的。每一条背后都有一个「当初没检查这一项」的故事。

什么时候别拆

说了很多什么时候该拆，最后说说什么时候别拆。

如果你发现自己在画多 Agent 架构图时，需要大量箭头来表示 Agent 之间的通信——停下来。这些箭头就是未来的故障点、延迟来源和调试黑洞。

Anthropic 的建议很朴素：如果一个任务用更好的提示词、更丰富的上下文、或者一个更强的模型就能解决，就不要拆。多 Agent 系统「用延迟和成本换取更好的任务表现」，这笔交易只在任务复杂度确实超出单 Agent 能力时才划算。

具体而言，以下场景我倾向于不拆：

1. 任务上下文高度连贯：前后步骤需要完全相同的理解，拆了就会丢信息。
2. 产物必须整体一致：部分合格不等于整体合格，验收时还是得看全貌。
3. 团队只有一个人：维护多 Agent 系统的心智负担不低，一个人同时调三个 Agent 的提示词和协调逻辑容易崩溃。
4. 还没有跑通过单 Agent 方案：在单 Agent 上都没验证过的任务逻辑，拆成多 Agent 只会让问题更难定位。

Beam AI 的数据再次给出了量化参考：单 Agent 在 64% 的任务上已经够用。剩下的 36%，才是多 Agent 需要上场的地方。

拆不拆，最终取决于你对任务结构的理解。多 Agent 不是架构升级，是架构选择。选对了省力，选错了费钱。

参考资料

1. How We Built Our Multi-Agent Research System — Anthropic Engineering：Anthropic 多 Agent 研究系统的完整架构说明，包含编排器-工人模式和并行化策略。
2. Building Effective Agents — Anthropic Research：Anthropic 关于 Agent 构建的总原则，强调从简单方案开始。
3. 6 Multi-Agent Orchestration Patterns for Production — Beam AI：六种生产级编排模式的对比，包含失败模式和成本分析。
4. Choosing the Right Multi-Agent Architecture — LangChain：LangChain 对四种多 Agent 架构模式的总结和选型建议。
5. Six Core Design Principles for Multi-AI Agent Systems — Cobus Greyling：模块化分解、通信模式和职责边界的设计原则。
6. 10 Multi-Agent Coordination Strategies to Prevent System Failures — Galileo AI：十种协调策略，覆盖确定性职责分配、超时控制、写入隔离和投票机制。
7. Divide-and-Conquer Is What LLM-Based Multi-Agent System Need — arXiv：关于多 Agent 辩论中 Agent 数量与性能关系的实验研究。
8. Multi-Agent AI Orchestration Guide & 2026 Updates — Codebridge：多 Agent 编排的工程实践指南和 2026 年趋势更新。