背景与问题

在单 Agent 模式下，一个模型往往要同时承担需求理解、检索、规划、工具调用、代码生成与结果校验。任务一复杂，提示词会迅速膨胀，上下文也会混入大量无关信息，导致输出不稳定。于是很多团队开始尝试多 Agent 协作：让不同角色分别负责规划、执行、审查和总结。

观山静思
观山静思

但多 Agent 并不是银弹。如果没有清晰的角色边界，系统会退化成多个模型互相转发文本；如果没有统一消息总线，调用链会变成难以排查的网状结构；如果没有冲突消解机制，不同 Agent 可能基于不同事实或目标反复争执，最终增加时延和成本。本文聚焦三个工程问题：如何分工、如何通信、如何仲裁。

核心概念

角色分工：先定义契约，再写提示词

多 Agent 系统的第一步不是选择模型，而是拆分职责。常见角色包括：Planner 负责任务分解与优先级排序，Researcher 负责检索与事实整理，Executor 负责调用工具或执行代码，Reviewer 负责质量检查，Arbitrator 负责冲突仲裁，Memory Manager 负责长期记忆与摘要压缩。

每个角色都应有明确契约：输入是什么、输出是什么、能调用哪些工具、不能做什么、何时结束。例如，Reviewer 不应直接改写最终方案，而应输出结构化审查意见；Researcher 不应做业务决策，而应提供带来源的证据。这样可以减少角色越界，也便于后续做单元评估。

消息总线：把对话变成可追踪事件

很多早期多 Agent 实现采用点对点调用：A 调 B，B 调 C，C 再回 A。这种方式调试困难，且容易形成循环。更稳妥的做法是引入消息总线，将 Agent 间交互抽象为事件。事件可以包括 task.created、plan.proposed、tool.result.received、review.failed、conflict.detected 等。

消息信封建议至少包含追踪 ID、发送方、接收方或主题、消息类型、负载、模式版本、时间戳和过期时间。追踪 ID 用于全链路回放，模式版本用于兼容演进，过期时间用于避免陈旧消息触发副作用。

from dataclasses import dataclass

@dataclass
class AgentMessage:
    msg_id: str
    trace_id: str
    sender: str
    topic: str
    payload: dict
    schema_version: str = 'v1'

这段代码用于定义统一消息结构。实际项目中，还可以加入签名、优先级、重试次数和幂等键。消息总线本身可以用内存队列、Redis Stream、Kafka 或云消息服务实现，关键不在组件，而在消息契约是否稳定。

冲突消解：从争论转向裁决

多 Agent 冲突通常分为四类：事实冲突、计划冲突、资源冲突和策略冲突。事实冲突是不同 Agent 给出不同事实；计划冲突是执行顺序不一致；资源冲突是多个任务抢占同一工具、文件、预算或外部接口；策略冲突是风险偏好不同，例如一个 Agent 倾向自动执行，另一个要求人工确认。

消解冲突时，不建议让多个 Agent 无限对话。更好的方式是设定裁决规则：安全问题优先升级人工；事实问题优先采用带证据、时间更新、来源可信度更高的结果；计划问题由 Planner 或 Arbitrator 根据目标函数裁决；资源问题通过锁、队列、预算和幂等键控制。

def resolve_conflict(conflicts):
    if any(c.kind == 'safety' for c in conflicts):
        return 'human_review'
    if any(c.kind == 'fact' for c in conflicts):
        return pick_best_evidence(conflicts)
    return planner.replan(conflicts)

这段伪代码展示冲突分流思路：安全类冲突不能自动吞掉，事实类冲突交给证据排序，计划类冲突回到规划器重排。生产环境中，还应记录裁决原因，方便复盘和评估。

实践步骤与检查清单

  • 第一步：定义任务边界。先明确哪些任务适合自动化，哪些必须人工确认。不要一开始就让多 Agent 全自动完成高风险操作。
  • 第二步：拆分最小角色。从 Planner、Executor、Reviewer 三个角色开始，确有必要再增加 Researcher、Critic、Memory Manager。
  • 第三步：设计消息契约。为每类事件定义字段和校验规则，禁止直接传递自由文本长上下文。
  • 第四步：建立共享状态。将任务目标、约束、已完成步骤、待确认事项放入结构化状态对象，而不是让每个 Agent 各自维护记忆。
  • 第五步：加入预算控制。为每个任务设置最大轮次、最大 token、最大工具调用次数和最大耗时。
  • 第六步：实现冲突仲裁。明确谁有最终裁决权，并保留证据链。
  • 第七步：做轨迹评估。不仅评估最终答案，还要评估规划是否合理、工具调用是否必要、审查是否发现问题。

常见坑与建议

  • Agent 数量过多。角色越细，沟通成本越高。建议以可测试性为准，而不是追求架构图好看。
  • 提示词职责模糊。如果一个 Agent 既能规划又能执行还能审查，很容易产生自我强化错误。职责要互斥。
  • 缺少 trace_id。没有追踪 ID，多 Agent 问题几乎无法复盘。每条消息、每次工具调用、每个模型响应都应能关联到同一任务。
  • 上下文无限拼接。把所有历史消息塞给每个 Agent，会导致成本上升和注意力稀释。应使用摘要、检索和结构化状态。
  • 忽略幂等。消息重试可能导致重复调用工具或重复写入数据。工具调用应带幂等键，写操作要可安全重放。
  • 没有停止条件。两个 Agent 互相要求修改，可能陷入死循环。应设置最大轮次和升级路径。
  • 只评估最终结果。多 Agent 系统的问题常出现在中间步骤。建议对规划、检索、执行、审查分别建立指标。

延伸阅读方向

  • 多智能体框架与协议。可以关注 LangGraph、AutoGen、CrewAI、OpenAI Swarm、MCP、A2A 等方向，具体能力与接口请以官方文档为准。
  • 分布式系统模式。事件溯源、Saga、最终一致性、幂等消费者、死信队列等概念，对多 Agent 通信和恢复机制很有参考价值。
  • 评估体系。可进一步研究轨迹评估、LLM-as-judge、人工抽检和回归基准集，避免只看单次输出。
  • 安全与权限。多 Agent 能调用工具后，最小权限、审计日志、沙箱执行和人工审批会变得比模型能力更重要。

参考来源

免责声明：本文内容整理自公开网络资料，仅供学习交流参考，不代表观山书院立场。如涉及版权侵权，请联系我们删除。

联系邮箱：chenxj.g@gmail.com