多 Agent 协作如何真正落地：拆角色、定流程、配信号

一、为什么单 Agent 不够用

很多团队第一次做 Agent 时，都会写一个“全能助手”：一个提示词里既要理解需求，又要查资料、写代码、做评审、输出报告。开始时跑得很快，一旦任务变长就会出现三个典型问题：上下文被历史对话塞满，关键信息被淹没；一个环节出错，后面所有步骤跟着错；没人能说清现在进行到哪一步、卡在哪一个环节。

多 Agent 的价值不是“Agent 越多越厉害”，而是把一个长任务拆成可分工、可检查、可重试的小任务。华为云 AI 办公实践中心里的案例很能说明这一点：面试场景不是一个 Agent 从头聊到尾，而是破冰、技术面试、HR 面试、评估报告等角色分工；智慧课堂也不是一个 Agent 包办课件、作业和学情分析，而是按教学环节拆开。角色越清晰，错误越容易定位，系统也越容易复用。

二、第一步：拆角色，按产出物拆而不是按模型拆

拆角色最常见的错误，是按“模型能力”拆，例如一个负责“思考”、一个负责“行动”。这样拆完，两个 Agent 的边界仍然模糊，互相推诿。正确的做法是按产出物拆：每个 Agent 只对一份明确的产出负责。

以面试流程为例，可以这样拆：

• 破冰 Agent：产出是候选人背景摘要和本次面试的关注点，输入是简历与岗位要求；
• 技术面试 Agent：产出是分项评分与可复现的追问记录，输入是背景摘要与岗位技能清单；
• HR 面试 Agent：产出是沟通、稳定性与期望的评估，输入是前两轮的结论摘要，而不是全部原始对话；
• 评估 Agent：产出是综合报告与录用建议，输入是三份结构化评分，输出必须引用评分依据。

每个角色都要写清四件事：输入是什么、输出是什么、不能做什么、失败时返回什么。尤其是最后一点：如果技术面试拿不到关键信息，Agent 应该返回“信息缺失：缺少项目职责说明”，而不是编造一个看似完整的评分。把“承认缺失”写进角色契约，是多 Agent 系统可靠性的起点。

三、第二步：定流程，用状态机代替自由聊天

角色拆好之后，不要让 Agent 们“自由商量”。自由讨论看起来智能，实际上难以复现、难以测试、难以设上限。更稳妥的做法是把流程画成状态机：破冰完成才能进入技术面试，技术面试与 HR 面试可以并行，但评估必须等两者都完成；任何一步失败，流程进入重试或人工接管，而不是继续往下编。

流程设计时要先定三条规则：

1. 轮次上限：同一环节最多重试两次，第三次直接升级为人工处理或返回缺失清单；
2. 超时与降级：外部工具调用超时时，先用缓存或简化路径降级，不要无限等待；
3. 人工接管点：在涉及录用、预算、对外发布等不可逆动作之前，必须留出人工确认环节。

并行也不是越多越好。并行适合互不依赖的环节，例如课件准备与学情分析可以同时做；但评估类环节必须串行，因为它依赖前面的全部结论。先画依赖图，再决定哪些可以并行，系统会少很多竞态问题。

四、第三步：配信号，让 Agent 用结构化事件沟通

多 Agent 之间最脆弱的一环是沟通。如果 Agent 之间直接转发整段聊天记录，信息会迅速膨胀，而且每个 Agent 对“现在该做什么”的理解都会漂移。解决办法是配信号：Agent 之间传递的不是闲聊，而是结构化事件。

一个最小可用的事件可以这样定义：

{
  "task_id": "interview-20261028-001",
  "from": "tech-interviewer",
  "type": "task_completed",
  "summary": "已完成三道系统设计追问，候选人在并发控制上表述不清",
  "scores": {"system_design": 3, "coding": 4},
  "missing": ["高并发下的缓存一致性方案"],
  "next": "hr-interviewer"
}

信号要做到三点：带任务编号，任何事件都能追溯到同一任务；带状态变化，而不只是文本；带下一步指向，让编排器不需要猜。心跳也是一种信号，但必须节流：每分钟汇报一次进度摘要就够了，不要把每一次工具调用都广播给所有 Agent，否则关键信号会被心跳淹没。

五、一个可复用的最小编排骨架

下面是一个语言无关的骨架思路，可以直接对应到 Python 或 TypeScript 实现：

from dataclasses import dataclass, field

@dataclass
class AgentSpec:
    name: str
    input_keys: list[str]
    output_keys: list[str]
    max_retries: int = 2
    # 每个 Agent 只声明自己需要和产出的字段，
    # 编排器据此检查依赖是否齐全，而不是把全部上下文都塞给它。

@dataclass
class TaskState:
    task_id: str
    stage: str = "icebreaking"
    artifacts: dict = field(default_factory=dict)
    missing: list[str] = field(default_factory=list)

# 编排器的职责只有四件：
# 1. 检查当前阶段的输入是否齐全；
# 2. 按依赖图调度下一个 Agent；
# 3. 收到完成信号后推进状态，收到失败信号后重试或升级；
# 4. 把所有事件写入同一条任务日志，便于复盘。

这个骨架的关键不在代码量，而在约束：Agent 不能绕过编排器私下通信；状态只能由编排器推进；所有产出都要落到 artifacts 里，而不是只留在对话历史中。做到这三点，后续加一个新角色、换一个模型、接一个新工具，都不需要重写整个流程。

六、实践中常见的五个坑

1. 心跳刷屏：Agent 每步都广播“我还在运行”，关键的完成与阻塞信号被淹没。做法是心跳只发摘要，关键事件单独发，并且按任务编号聚合展示。
2. 消息转发丢上下文：A 把一段对话原样丢给 B，B 拿到了文字却丢了结论。做法是转发时必须附带结构化摘要与任务编号，原始对话只作为可查的附件。
3. 状态跳转不一致：两个 Agent 各自维护一份进度，导致评估提前开始。做法是只允许编排器写状态，Agent 只发事件、不直接改状态。
4. 工具调用没有幂等：重试时重复发邮件、重复下单。做法是每个外部动作带请求编号，服务端按编号去重，重试先查结果再决定是否重发。
5. 评估标准事后定：报告写完才争论“多少分算通过”。做法是先写评分标准与通过线，再开始面试或评审，评估 Agent 只执行标准、不临时发明标准。

七、上线前的检查清单

• 每个 Agent 的输入、输出、禁区、失败返回是否都写清了？
• 依赖图是否画出来了，哪些串行、哪些并行是否说得清？
• 失败、超时、重试上限、人工接管点是否都定义了？
• 事件是否带任务编号、状态变化与下一步指向？
• 关键动作是否可审计、可回放、可按任务编号检索？
• 外部调用是否带请求编号，是否做了去重？
• 评估类产出是否引用了前置环节的结构化结论，而不是凭印象？
• 有没有在真实数据上跑通一遍，而不是只在演示用例上跑通？

八、结语

多 Agent 系统的竞争力，往往不在单个模型有多强，而在流程与信号是否可观测、可测试、可回放。拆角色解决“谁负责什么”，定流程解决“按什么顺序做”，配信号解决“如何知道进展与失败”。把这三件事做扎实，一个面试天团、一个智慧课堂、一个活动策划团队，才能从演示变成每天都能稳定跑的工具。