10. 多智能体协作框架

Multi-Agent Framework 描述 FlowNex 如何从单 Agent 执行演进为多 Agent 协作。

FlowNex 多 Agent 协作框架

多 Agent 协作的目标不是让多个 Agent 同时聊天，而是让复杂任务可以被拆解、分派、执行、审查、合并和回滚。

10.1 多 Agent 协作目标

多 Agent 协作主要解决以下问题：

  1. 单 Agent 难以稳定完成长链路复杂任务。
  2. 不同子任务需要不同专业能力。
  3. 执行、审查、汇总应由不同角色承担。
  4. 多个任务产物需要共享文件空间。
  5. 失败后需要局部重试或回滚。

典型复杂任务：

基于客户资料、项目文档、最近会议纪要和销售数据，
生成一份客户经营分析报告，
并检查是否符合公司模板和风险规范。

这个任务可以拆为资料检索、数据分析、报告撰写、风险审查和最终汇总。每个环节由不同 Agent 角色承担更合理。

10.2 角色模型：Planner / Researcher / Executor / Reviewer / Synthesizer

第一期建议采用受控角色模型。

Planner

负责：

  1. 理解用户目标。
  2. 拆解任务。
  3. 生成 Task Graph。
  4. 分配 Agent 角色。
  5. 判断依赖顺序。
  6. 定义最终交付标准。

Researcher

负责：

  1. 检索知识库。
  2. 搜索外部资料。
  3. 阅读 AGFS 文件。
  4. 汇总上下文。
  5. 输出结构化资料包。

Executor

负责：

  1. 调用 Tool。
  2. 运行脚本。
  3. 处理文件。
  4. 生成中间产物。
  5. 输出阶段性结果。

Reviewer

负责：

  1. 检查事实依据。
  2. 检查格式要求。
  3. 检查风险和遗漏。
  4. 对产物提出修改建议。
  5. 决定是否需要回滚或重试。

Synthesizer

负责：

  1. 汇总各子任务结果。
  2. 消除冲突。
  3. 统一表达风格。
  4. 生成最终回复或最终交付文件。

10.3 Task Graph

Task Graph 是多 Agent 协作的核心数据结构。

它描述：

  1. 用户目标。
  2. 子任务节点。
  3. 节点依赖。
  4. 节点负责 Agent。
  5. 节点输入。
  6. 节点输出。
  7. 节点状态。
  8. 失败策略。

建议模型：

AgentTaskGraph
  graphId
  tenantCode
  conversationId
  rootTaskId
  status
  createdBy
  createTime

AgentTaskNode
  nodeId
  graphId
  parentNodeId
  roleType
  skillCodes
  toolCodes
  knowledgeAccess
  agfsCheckpointId
  status
  inputManifest
  outputManifest

AgentTaskEdge
  edgeId
  graphId
  fromNodeId
  toNodeId
  dependencyType

Task Graph 不应第一期设计得过于自由。推荐先支持 DAG，避免循环依赖。

10.4 子任务分发与回收

Planner 生成 Task Graph 后，control-center 可以按依赖关系分发子任务。

子任务分发流程：

flowchart LR
    A["Planner 生成 Task Graph"] --> B["control-center 创建子 Task"]
    B --> C["agent-runtime-gateway 分配 runtime"]
    C --> D["share-harness 执行子任务"]
    D --> E["回传子任务结果"]
    E --> F["更新 Task Graph 节点状态"]
    F --> G["触发后继节点"]

子任务输出应结构化写入：

  1. Task Step。
  2. AGFS 文件。
  3. output manifest。
  4. runtime event。
  5. 节点状态。

10.5 Agent Handoff

Agent Handoff 表示一个 Agent 将上下文、产物或问题交给另一个 Agent。

Handoff 不是简单转发自然语言，而应包含结构化上下文：

  1. 来源节点。
  2. 目标节点。
  3. 交接原因。
  4. 输入文件。
  5. 输出文件。
  6. 已完成结论。
  7. 待解决问题。
  8. 风险提示。

示例：

{
  "fromRole": "Researcher",
  "toRole": "Writer",
  "reason": "research_completed",
  "files": [
    "/workspace/research/customer-context.md",
    "/workspace/research/policy-evidence.md"
  ],
  "summary": "已完成客户背景和政策依据整理，待生成报告正文。"
}

10.6 共享知识与共享文件

多 Agent 协作需要两类共享上下文：

  1. 共享知识。
  2. 共享文件。

共享知识由 Knowledge System 提供。

每个子任务都应继承或收窄根任务的 knowledgeAccess，不能绕过用户和 Skill 权限。

共享文件由 AGFS 提供。

每个子任务可以读写同一个 project_space 或 task_space，但应通过 checkpoint 区分不同 Agent 的修改。

建议规则：

  1. 根任务创建 AGFS checkpoint。
  2. 每个子任务开始前创建子 checkpoint。
  3. 子任务产物写入约定目录。
  4. Reviewer 可以基于 checkpoint 回滚某个子任务。
  5. Synthesizer 只读取已通过审查的文件。

10.7 审阅、合并与最终输出

多 Agent 结果不能简单拼接。

Reviewer 和 Synthesizer 需要完成：

  1. 事实核对。
  2. 格式检查。
  3. 冲突消解。
  4. 质量评分。
  5. 引用整理。
  6. 最终输出生成。

最终输出可以是：

  1. 普通回复。
  2. Markdown 报告。
  3. Excel 文件。
  4. PPT。
  5. 飞书文档。
  6. AGFS 文件路径。

最终输出应关联：

  1. 来源子任务。
  2. 来源文件。
  3. 来源知识。
  4. Reviewer 结论。
  5. 用户反馈。

10.8 失败恢复与回滚

多 Agent 协作中，失败恢复比单 Agent 更重要。

失败类型包括：

  1. 子任务超时。
  2. Tool 调用失败。
  3. 知识召回不足。
  4. 文件写入冲突。
  5. Reviewer 不通过。
  6. Synthesizer 合并失败。

恢复策略：

  1. 重试当前节点。
  2. 换 Agent 或模型重试。
  3. 降级使用更少上下文。
  4. 回滚当前节点 checkpoint。
  5. 跳过非关键节点。
  6. 请求人工介入。

所有失败恢复动作都应写入 Task Graph 事件，便于审计和复盘。