使用 OpenClaw 的多代理编排模式

单个人工智能代理可以自动化流程。精心策划的代理系统可以实现业务功能的自动化。区别在于代理如何跨边界协调、沟通和处理故障。多代理编排是一门工程学科，它区分了一组独立的机器人和一个连贯、可靠的自治系统。

OpenClaw 提供了多代理编排的原语：类型化消息总线、代理注册表、切换协议、共享内存命名空间以及跨代理边界跟踪请求的分布式跟踪。本指南涵盖了四种基本编排模式、何时使用每种模式、如何在 OpenClaw 中实现它们以及设计时所针对的故障模式。

要点

• 主管-工作人员模式是最常见的架构：一个编排代理分解目标并将其委托给专门的工作人员。
• 管道模式最适合顺序文档处理或多步骤数据转换，其中每个阶段都会为下一个阶段生成输入。
• 共识模式使多个独立代理能够评估同一问题，从而降低高风险决策中单代理错误的风险。
• 做市商模式将任务动态分配给最有能力的可用代理，从而实现负载平衡和优雅降级。
• 跨代理通信使用 OpenClaw 的类型化消息总线 — 无原始字符串传递，代理之间无共享可变状态。
• 分布式跟踪对于多代理调试至关重要 - 每条消息都携带跨越代理边界的相关 ID。
• 当系统中的一个代理不可用时，代理边界处的断路器可防止级联故障。
• ECOSIRE 为复杂的企业自动化工作流程设计并实施多代理架构。

---

基金会：OpenClaw 的代理通信模型

在介绍模式之前，了解 OpenClaw 代理如何通信非常重要。共有三种机制，每种机制都有不同的权衡：

消息总线是同一系统中代理之间的主要通信通道。代理将键​​入的消息发布到命名通道；其他代理订阅这些频道。消息由总线代理（Redis Streams 或 Kafka，可配置）保存，因此如果接收代理暂时不可用，消息也不会丢失。

直接调用允许一个代理直接调用另一代理的公开技能并等待响应。从调用者的角度来看，这是同步的，适用于调用代理在获得结果之前无法继续操作的低延迟工作流。谨慎使用——它会在代理之间创建紧密耦合。

共享内存命名空间允许同一系统内的代理读取和写入内存存储的共享区域。这适用于传递大型上下文对象（正在处理的文档、跨阶段丰富的客户资料），而无需通过消息有效负载序列化它们。

// Publishing a message
await messageBus.publish("document.classified", {
  documentId: "DOC-4521",
  type: "vendor-invoice",
  confidence: 0.94,
  storageKey: "incoming/doc-4521.pdf",
});

// Subscribing to messages
messageBus.subscribe("document.classified", async (message) => {
  await extractionAgent.handle(message);
});

所有消息均包含相关 ID、时间戳、源代理 ID 和架构版本。模式版本允许消息总线根据其声明的合约验证消息，并在到达接收代理之前拒绝格式错误的消息。

---

模式 1：Supervisor-Worker

Supervisor-Worker 模式是应用最广泛的多智能体架构。 Supervisor 代理接收顶级目标，将其分解为子任务，将每个子任务分配给专门的 Worker 代理，监控进度并综合结果。

User/System Goal
      ↓
[ Supervisor Agent ]
  ├─ task 1 → [ Worker Agent A ]
  ├─ task 2 → [ Worker Agent B ]
  └─ task 3 → [ Worker Agent C ]
      ↓
[ Supervisor Agent ] ← results from all workers
      ↓
Synthesized Response

何时使用：当复杂的目标需要异构专业知识时。主管处理协调逻辑；工作人员是擅长做一件事的领域专家。

OpenClaw 实施：

export const SupervisorAgent = defineAgent({
  name: "due-diligence-supervisor",
  skills: ["decompose-goal", "assign-workers", "synthesize-results"],
  async run({ goal, workerRegistry, messageBus }) {
    // Decompose goal into tasks
    const tasks = await decomposeGoal(goal);

    // Assign to appropriate workers
    const assignments = tasks.map((task) => ({
      task,
      worker: workerRegistry.findBestMatch(task.type),
    }));

    // Publish tasks and wait for results
    const results = await Promise.allSettled(
      assignments.map(({ task, worker }) =>
        messageBus.requestReply(`worker.${worker.id}.tasks`, task, { timeoutMs: 60_000 })
      )
    );

    // Synthesize
    const successfulResults = results
      .filter((r) => r.status === "fulfilled")
      .map((r) => r.value);

    return synthesize(goal, successfulResults);
  },
});

关键设计决策：

• 主管不应包含领域逻辑——它只应进行协调。
• 工作人员应该是无国籍且独立可扩展的。
• 失败的工作任务由主管重试，而不是由工作人员内部重试。
• 主管级别的任务超时可防止缓慢的工作人员阻塞整个工作流程。

真实示例：尽职调查自动化系统，主管将公司审查分解为分配给财务分析人员、法律文件审查人员、市场研究人员和背景调查人员的并行任务。主管将所有调查结果合并成统一的尽职调查报告。

---

模式 2：管道

管道模式对代理进行排序，以便每个代理的输出成为下一个代理的输入。它非常适合文档处理、数据丰富以及每个步骤都按照定义的顺序转换或丰富有效负载的任何工作流程。

Input Document
    ↓
[ Stage 1: Ingestion Agent ]
    ↓
[ Stage 2: Classification Agent ]
    ↓
[ Stage 3: Extraction Agent ]
    ↓
[ Stage 4: Validation Agent ]
    ↓
[ Stage 5: Integration Agent ]
    ↓
Output: ERP Record

何时使用：顺序工作流程，具有清晰的阶段边界和每个步骤的转换。非常适合高吞吐量文档处理。

OpenClaw 实施：

OpenClaw 的 Pipeline 原语管理阶段链、处理故障并支持基于有效负载内容在任何阶段进行分支。

import { definePipeline } from "@openclaw/orchestration";

export const InvoicePipeline = definePipeline({
  name: "invoice-processing",
  stages: [
    { agent: "document-ingester", timeout: 30_000 },
    {
      agent: "document-classifier",
      timeout: 15_000,
      branch: {
        "vendor-invoice": "invoice-extractor",
        "credit-memo": "credit-memo-extractor",
        "unknown": "human-review-queue", // Branch to exception handling
      },
    },
    { agent: "invoice-validator", timeout: 20_000 },
    { agent: "invoice-enricher", timeout: 10_000 },
    { agent: "erp-integrator", timeout: 30_000, retries: 3 },
  ],
  onFailure: {
    agent: "exception-handler",
    preservePartialState: true,
  },
});

关键设计决策：

• 每个阶段都应该是幂等的——如果它使用相同的输入运行两次，它将产生相同的输出。
• onFailure 处理程序接收部分管道状态，以便它可以从最后一个成功阶段恢复而不是重新开始。
• 分支允许不同的文档类型在分类后遵循不同的子管道。
• 使用共享内存命名空间在阶段之间传递大型有效负载（文档缓冲区），而不是通过消息总线序列化它们。

故障处理：当 M 个成功阶段后 N 阶段失败时，管道状态在 M 阶段进行检查点。故障解决后（手动纠正，依赖性恢复后重试），管道以相同的负载从 M+1 阶段恢复。

---

模式 3：共识

共识模式针对相同的输入运行多个独立代理，并要求它们在系统行动之前达成一致（在阈值内）。它相当于第二意见的多智能体，在高风险决策中最有价值，因为单智能体的错误会造成高昂的代价。

Input
  ├─ → [ Evaluator Agent A ] → assessment A
  ├─ → [ Evaluator Agent B ] → assessment B
  └─ → [ Evaluator Agent C ] → assessment C
          ↓
  [ Consensus Resolver ]
    ├── unanimous or majority? → act
    └── no consensus? → escalate to human

何时使用：高风险决策（贷款审批、欺诈检测、医疗记录分析、合同条款审查）、可能操纵单个代理的对抗性输入，或不同模型具有互补优势的情况。

OpenClaw 实施：

export const FraudConsensusCheck = defineAgent({
  name: "fraud-consensus",
  async run({ transaction, evaluators }) {
    // Run all evaluators in parallel
    const assessments = await Promise.all(
      evaluators.map((evaluator) =>
        evaluator.assess(transaction)
      )
    );

    const fraudVotes = assessments.filter((a) => a.isFraud).length;
    const totalVotes = assessments.length;
    const agreementRatio = fraudVotes / totalVotes;

    if (agreementRatio >= 0.67) { // Supermajority fraud detection
      return { decision: "block", confidence: agreementRatio, assessments };
    } else if (agreementRatio === 0) { // Unanimous clear
      return { decision: "allow", confidence: 1 - agreementRatio, assessments };
    } else {
      // Disagreement — escalate with all assessments for human review
      return { decision: "escalate", confidence: null, assessments };
    }
  },
});

关键设计决策：

• 评估代理应该使用不同的模型或不同的提示策略来尽量减少相关的失败。使用相同模型和相同提示的两个代理通常会达成一致——这违背了目的。
• 共识阈值是可配置的。一致同意适用于不可逆转的行动；简单多数足以做出可逆转的决定。
• 升级路径需要容量规划 - 如果升级率很高，则需要调整评估器标准。

---

模式 4：做市商

做市商模式维护一个工作人员代理池，并在任务到达时动态地将任务分配给最合适的可用工作人员。工人登记他们的能力和当前负荷；做市商将每个任务路由到最佳匹配。

Task Queue
    ↓
[ Market-Maker Agent ]
    ├── Worker A: [language-translation] load: 30%
    ├── Worker B: [language-translation] load: 80%
    └── Worker C: [language-translation] load: 10%  ← assigned

何时使用：任务量变化很大的高吞吐量系统。无需更改路由逻辑即可水平扩展工作代理。还可以实现优雅的降级——如果专业工作人员不可用，做市商可以路由到性能较低的通用工作人员，而不是让任务失败。

export const TranslationMarketMaker = defineAgent({
  name: "translation-market-maker",
  tools: ["worker-registry", "task-queue"],
  async run({ tools }) {
    while (true) {
      const task = await tools.taskQueue.dequeue("translation.pending");
      if (!task) { await sleep(100); continue; }

      const workers = await tools.workerRegistry.getAvailable({
        capability: "language-translation",
        targetLanguage: task.targetLanguage,
      });

      if (workers.length === 0) {
        // No specialist available — try generalist
        const generalists = await tools.workerRegistry.getAvailable({ capability: "general-translation" });
        if (generalists.length === 0) {
          await tools.taskQueue.requeueWithDelay(task, { delayMs: 5000 });
          continue;
        }
        workers.push(...generalists);
      }

      // Select worker with lowest load
      const selected = workers.sort((a, b) => a.currentLoad - b.currentLoad)[0];
      await selected.dispatch(task);
    }
  },
});

关键设计决策：

• 工作人员负载报告必须准确且低延迟。过时的负载数据会导致分布不均匀。
• 后备链（专家→通才→延迟队列）可防止容量不足时任务丢失。
• 工作人员在启动时自行注册并在正常关闭时取消注册。健康检查轮询会自动删除崩溃的工作人员。

---

交叉模式：分布式追踪

无论您使用哪种编排模式，分布式跟踪对于生产多代理系统都是不可协商的。每条消息都带有 correlationId 和 spanId。当代理创建子任务（在主管模式中）或将工作传递到下一个阶段（在管道模式中）时，它会创建一个新的跨度作为当前跨度的子级。

// Middleware that injects tracing into all agent message handlers
agent.useHook("preRun", (ctx) => {
  ctx.span = tracer.startSpan(ctx.skill, { childOf: ctx.message.parentSpan });
  ctx.span.setTag("agent.id", ctx.agentId);
  ctx.span.setTag("correlation.id", ctx.message.correlationId);
});

agent.useHook("postRun", (ctx) => {
  ctx.span.finish();
});

通过分布式跟踪，您可以跨所有代理边界可视化任何任务的完整执行树，这对于调试延迟问题和意外行为非常有用。

---

要避免的反模式

共享可变状态：多个代理在未经协调的情况下写入同一数据存储记录会导致更新丢失和竞争条件。使用消息总线进行协调；代理人拥有自己的状态。

同步链长于三个代理：如果代理 A 调用 B，而 B 又调用 C，而 C 又同步调用 D，则延迟会增加，并且故障波及半径会很大。通过检查点将长同步链分解为异步管道阶段。

具有域逻辑的主管代理：主管应该协调，而不是执行域工作。当主管开始包含提取逻辑或验证规则时，它就变成了一个变相的庞然大物。

代理之间的隐式契约：消息模式应在总线级别进行版本控制和验证。当发送者更改其输出格式时，采用消息结构而不是验证消息结构的代理会默默地失败。

---

常见问题

如何处理主管-工作人员系统中一些工作人员成功而另一些工作人员失败的部分故障？

主管收到所有工作任务的结果，包括成功和失败的结果。综合技能根据目标决定如何处理部分结果：对于某些目标，部分结果足以产生有用的输出；而对于某些目标，部分结果足以产生有用的输出。对于其他人来说，所有结果都是必需的。为主管配置最低成功阈值 - 如果成功的工作人员比例少于该比例，则升级而不是产生可能具有误导性的部分输出。

同一个代理可以同时参与多个编排模式吗？

是的。代理只是一种服务 - 它可以是一个主管-工作人员系统中的工作人员，同时也可以是管道中的一个阶段，并作为评估者参与共识检查。每次调用都是独立的。关键要求是代理在调用之间是无状态的（有状态数据存储在内存存储中，而不是代理实例变量中），因此多个并发调用不会干扰。

高吞吐量系统的消息总线开销是多少？

使用 Redis Streams 作为消息总线后端，对于 64KB 以下的消息，消息发布/订阅延迟通常低于 2 毫秒。对于每分钟处理数千个文档的高吞吐量管道来说，与每个阶段的处理工作相比，这可以忽略不计。对于极高吞吐量的系统（每天数百万条消息），Kafka 提供更高的持续吞吐量，但代价是更高的操作复杂性。

当单个代理不断发展时，如何对多代理系统进行版本控制？

版本代理在其清单中独立使用语义版本控制。消息总线根据消息声明的模式版本验证消息。当代理更改其输出模式（重大更改）时，它会更改主要版本，并且总线将旧模式消息路由到先前版本。两个版本在迁移窗口期间同时运行。 Supervisor 或 Pipeline 配置指定了每个工作线程所需的版本，让您可以完全控制推出时间。

当任务具有依赖性时，做市商模式如何处理任务排序？

做市商适用于独立任务——可以按任何顺序执行的任务。对于具有依赖关系的任务，请改用 Pipeline 或 Supervisor 模式，它们会显式强制执行排序。如果您混合有独立任务和依赖任务，则主管模式效果很好：主管将独立任务分派到做市商池并管理其余任务的依赖顺序。

---

后续步骤

多代理编排释放了单个代理无法处理的自动化复杂性。本指南中的模式（Supervisor-Worker、Pipeline、Consensus 和 Market-Maker）涵盖了绝大多数企业自动化用例。关键是为问题的通信结构选择正确的模式，而不是强迫每个问题都进入单一架构。

ECOSIRE 的OpenClaw 多代理编排服务 为复杂的多代理系统提供架构设计、实施和持续优化。我们的团队为每月处理数百万份文档的文档处理系统、24/7 运行的财务分析管道以及协调十几个专业代理的人力资源自动化系统设计了编排架构。

联系 ECOSIRE 讨论您的多代理架构需求。