从单 Agent 到多 Agent：技术实践方案与落地

从单 Agent 到多 Agent：封面图

背景引言

在我将 OpenClaw 部署至云服务器并完成飞书接入后，单一 Agent 已经在日常数据观测中发挥了实际价值。资产分析 Skill 上线后，我无需手动执行 SQL 查询，只需在飞书向 AI 发送一条查询指令，即可收到格式化的指标结果。这种体验在初期极大提升了我的工作效率。

然而，随着业务需求的扩展，我开始尝试将转化分析 Skill 和催收分析 Skill 逐步接入同一 Agent。问题随之而来：AI 在处理多条业务线的查询时开始出现「记忆混乱」——它偶尔会将资产数据的口径错误地套用到转化分析的场景中，或者在多轮对话后丢失了最初的任务目标。上下文长度有限、Skill 调度冲突、任务专注度下降等问题逐步显现，单一 Agent 的瓶颈清晰可见。

这些问题的本质并非 AI 模型能力不足，而是架构层面的设计局限。单 Agent 在面对多业务线、多维度的复杂任务时，其上下文窗口和任务调度能力存在天然上限。我开始思考：能否将不同业务线拆解为独立的 Agent，使各自专注于单一领域的分析与决策，并通过协作机制完成复杂的多维度任务？

从单 Agent 到多 Agent 的演进并非简单的数量叠加，而是一种架构层面的重新设计。本文完整记录了我在 OpenClaw 框架下，从单 Agent 架构走向多 Agent 协作的全过程，包括遇到的问题、技术选型、架构设计、实现方案以及最终的落地效果，供业务工作者参考。

一、为什么从单 Agent 开始

在构建 AI 数据分析助手的第一阶段，我选择了单 Agent 架构。这一选择并非偶然，而是基于当时业务场景和资源约束的综合决策。

快速验证业务场景

在项目初期，核心目标是尽快跑通资产分析这一条业务线，验证 AI 助手在实际工作中是否真正发挥作用。单 Agent 的优势在于架构简单、调试路径清晰——所有请求都流向同一个入口，所有 Skill 都加载在同一个上下文中。我可以在最短时间内完成从零到一的部署，将资产分析 Skill 跑通并投入使用。

这种路径适合所有刚起步的业务场景：先集中精力解决一个核心问题，不要在架构尚不成熟时就试图设计一个完美的多 Agent 系统。

单一业务线足够支撑日常使用

在资产分析 Skill 上线初期，日常查询需求集中在资产质量监控这一个维度。我需要查询的内容相对固定：D0 入催率、D0 利差、至今利差、坏账率等核心指标，以及按渠道、包体、客群等维度的拆分。单 Agent 在处理这类结构化查询时表现稳定，响应质量符合预期。

此时引入多 Agent 反而会增加不必要的复杂度。在业务规模和需求尚未充分验证之前，单 Agent 是性价比最高的选择。

成本与调试效率优先

从资源角度看，单 Agent 的上下文窗口和 Token 消耗远低于多 Agent 并行。在项目早期，数据量有限、对话轮次可控，单 Agent 的运行成本处于可接受范围。

从调试角度看，单 Agent 的日志链路清晰，问题排查路径短。当 Skill 返回结果不符合预期时，我只需检查单一 Agent 的上下文和调用记录，定位效率高，迭代速度快。

二、单 Agent 遇到的天花板

随着资产分析 Skill 逐步稳定运行，我将转化分析 Skill 和催收分析 Skill 陆续接入同一个 Agent，希望实现三大业务线的统一查询入口。然而，需求扩展带来的问题远比预期复杂。

上下文窗口的记忆混乱

当三个业务线的 Skill 同时加载在单一 Agent 中时，上下文窗口的负担显著加重。以一次跨业务线的分析场景为例：我先询问资产侧的 D0 入催率，再切换到转化侧的通过率，最后询问催收侧的还款率——AI 在处理完三轮不同业务语义的任务后，开始出现上下文丢失：它将资产的口径复用到转化场景中，或者混淆了两个业务的指标定义。

这种「记忆混乱」并非偶发现象，而是高频发生。根本原因在于：单 Agent 的上下文窗口需要同时承载三个业务线的概念、术语和数据字典，在长对话中有效信息密度持续上升，有价值的信息被稀释和覆盖。

Skill 调度的冲突

不同业务线的 Skill 在调用时机和输入输出格式上存在差异。当我在一次对话中连续发起多个跨业务线的请求时，Agent 需要频繁切换不同的 Skill 上下文，但切换过程中存在参数传递丢失和状态残留的问题。例如，资产分析 Skill 的查询结果被错误地传递给催收 Skill 的下一步计算，导致最终输出与业务预期不符。

这种冲突在单一 Skill 运行时几乎不会出现，但随着 Skill 数量增加，调度层面的问题逐步放大。

任务专注度下降

单一 Agent 在处理混合任务时，需要在同一上下文中切换「角色身份」——时而扮演资产分析师，时而扮演转化分析师，时而扮演催收分析师。这种频繁的身份切换消耗了大量上下文空间，也使得 Agent 在每个业务线上的专注度下降。实际表现为：AI 在处理资产数据查询时，开始倾向于生成泛化的分析回复，而非精准的结构化数据。

当业务需求从「单线查询」升级为「多线协同分析」时，单 Agent 的架构瓶颈已经无法通过调参或优化 Skill 来解决，必须从架构层面寻找解决方案。

三、多 Agent 架构设计思路

面对单 Agent 的架构瓶颈，我设计了一套以 CEO Agent 为协调入口、三个专业子 Agent 负责执行的主从 Agent 架构。

整体架构

**CEO Agent（协调入口）**作为用户交互的统一入口，部署在飞书对话的第一线。当用户在飞书发起任务时，CEO Agent 负责理解用户意图，判断任务属于哪条业务线，然后将任务分发至对应的专业子 Agent，最后将子 Agent 的返回结果汇聚后统一输出。

CEO Agent 拥有独立的调度规则（dispatch-rules.md），明确定义了每个子 Agent 的职责边界和任务分发逻辑，是整个架构的协调中枢。

**asset Agent（资产分析）**专门负责资产质量监控，接入资产分析 Skill，具备独立的工作区和工作流程规范，专注于资产入催率、利差、坏账率等核心指标的分析与输出。

**operation Agent（转化分析）**专门负责运营转化分析，接入转化分析 Skill，专注于申请到放款全链路的创单率、提单率、通过率，放款率等指标的分析与输出。

**collection Agent（催收分析）**专门负责催收团队管理，接入催收分析 Skill，专注于催收结清率、展期率，回款率等指标的分析与输出。

协作机制

CEO Agent 与三个子 Agent 之间通过任务分发与结果汇聚完成协作：

CEO Agent 接收用户在飞书的请求
判断任务类型，按调度规则分发至对应专业子 Agent（asset / operation / collection）
子 Agent 在独立工作区执行分析，完成后返回结果至 CEO Agent
CEO Agent 汇总各子 Agent 结果，按统一格式输出：核心结论、关键数据、主要异常点、哪一环影响最大、下一步建议

调度规则

CEO Agent 的调度规则包含两类场景：

单域问题：单一业务线的问题直接分配给对应子 Agent 处理。例如涉及入催率、利差的归 asset Agent，涉及转化率、领款率的归 operation Agent，涉及催收阶段表现的归 collection Agent。

跨域问题：涉及多条业务线的复杂问题，由 CEO Agent 拆解后分发至多个子 Agent 并行执行。例如日报和周报需要三大业务线协同，则同时分发至 asset、operation、collection 三个子 Agent，最后由 CEO Agent 统一汇总输出。

四、技术实现方案

以下是当前多 Agent 系统的完整配置方案，可直接交由 OpenClaw 执行，自动生成整套系统。

agents 配置

在 openclaw.json 的 agents.list 中注册 4 个 Agent，每个模型配置 MiniMax 作为备用：

{
  "id": "ceo",
  "name": "CEO Agent",
  "workspace": "/root/.openclaw/workspace/agents/ceo/workspace",
  "model": {
    "primary": "openai-codex/gpt-5.4",
    "fallbacks": ["minimax-portal/MiniMax-M2.7"]
  }
},
{
  "id": "asset",
  "name": "Asset Analyst",
  "workspace": "/root/.openclaw/workspace/agents/asset/workspace",
  "model": {
    "primary": "openai-codex/gpt-5.4",
    "fallbacks": ["minimax-portal/MiniMax-M2.7"]
  }
},
{
  "id": "operation",
  "name": "Operation Analyst",
  "workspace": "/root/.openclaw/workspace/agents/operation/workspace",
  "model": {
    "primary": "openai-codex/gpt-5.4",
    "fallbacks": ["minimax-portal/MiniMax-M2.7"]
  }
},
{
  "id": "collection",
  "name": "Collection Analyst",
  "workspace": "/root/.openclaw/workspace/agents/collection/workspace",
  "model": {
    "primary": "openai-codex/gpt-5.4",
    "fallbacks": ["minimax-portal/MiniMax-M2.7"]
  }
}

飞书入口配置

整个系统只有一个飞书入口——即 CEO 机器人账号。用户所有请求均通过该账号接入，由 CEO Agent 统一接收并完成调度分发。

目录结构

每个 Agent 独立工作区，包含以下文件：

agents/
├── ceo/
│   ├── SOUL.md           # CEO 角色定位与调度规则
│   ├── dispatch-rules.md  # 单域/跨域分发逻辑
│   ├── workflow.md       # CEO 工作流程
│   ├── MEMORY.md         # 跨板块记忆
│   └── workspace/        # CEO 工作目录
├── asset/
│   ├── SOUL.md           # 资产分析师定位
│   ├── workflow.md       # 资产分析工作流程
│   ├── skills.md         # 绑定 asset-metrics
│   └── workspace/
├── operation/
│   ├── SOUL.md
│   ├── workflow.md
│   ├── skills.md         # 绑定 apply-metrics
│   └── workspace/
└── collection/
    ├── SOUL.md
    ├── workflow.md
    ├── skills.md          # 绑定 collection-metrics
    └── workspace/

CEO Agent 调度规则

dispatch-rules.md 中定义任务分发逻辑：

单域问题直接分发：

入催率、利差、坏账率等 → asset Agent
通过率、领款率、转化链路等 → operation Agent
催回率、caseR、amtR 等 → collection Agent

跨域问题并行分发：

日报/周报 → 同时分发至 asset + operation + collection
渠道综合分析 → 同时分发至 asset + operation

汇总输出格式：

核心结论 → 关键数据 → 主要异常点 → 哪一环影响最大 → 下一步建议

Skill 绑定关系

Agent	绑定 Skill
asset	`asset-metrics`
operation	`apply-metrics`
collection	`collection-metrics`
ceo	不绑定计算 Skill，只做调度与汇总

任务流转路径

用户 → CEO Agent（唯一入口）→ 判断路由 → 分发至专业 Agent → 收集结果 → 汇总输出 → 用户

单域：用户 → CEO → 对应专业 Agent → CEO → 用户

跨域：用户 → CEO → 多个专业 Agent 并行 → CEO 汇总 → 用户

五、落地过程中的关键挑战与解决方案

多 Agent 架构的优势在设计层面清晰可见，但从单 Agent 演进到多 Agent 协作的过程中，我在实际落地时遇到了几个关键问题，并分别找到了可行的解决方案。

挑战一：Agent 间上下文隔离与共享的矛盾

问题描述

每个子 Agent 拥有独立的工作区和上下文，这意味着它们不会互相干扰，但同时也意味着某些共享信息需要显式传递。当 asset Agent 在分析中发现某渠道入催率异常升高时，这个信息不会自动同步至 operation Agent，后者在分析该渠道转化率时不会主动关联到资产质量的异常。

解决方案

CEO Agent 在汇总环节主动建立跨业务线的关联分析。dispatch-rules.md 中明确了「若多个 Agent 结论冲突，需指出冲突点并继续追问核实」的要求。当用户提出跨业务线问题时，CEO Agent 主动将任务分发至多个子 Agent，并在汇总阶段建立跨业务线的关联说明，而非简单拼接各 Agent 的独立结论。

挑战二：Skill 边界的划分问题

问题描述

三个子 Agent 各自绑定了不同的 Skill，Skill 之间的边界必须清晰，否则容易出现职责不清、重复调用的情况。如果某个 Skill 的查询口径发生变化，需要同步更新到所有引用该 Skill 的 Agent，任何一处遗漏都会导致数据不一致。

解决方案

每个子 Agent 拥有独立的 skills.md 文件，明确定义本 Agent 绑定的 Skill 及其使用规范。制定规范：各 Agent 只能调用自己 skills.md 中声明的 Skill，不得跨 Agent 调用。口径变更在各自 Agent 的 skills.md 中维护，由 CEO Agent 的 dispatch-rules.md 统一协调分发逻辑，在源头避免职责混乱。

挑战三：子 Agent 结果质量的把控

问题描述

单 Agent 时代，只需检查一个 Agent 的输出质量。多 Agent 协作后，需要同时监控三个子 Agent 的输出质量，并在 CEO 汇总阶段判断是否存在口径冲突或结论矛盾。落地初期，各 Agent 输出格式不统一，CEO Agent 汇总时需要二次加工才能统一格式。

解决方案

我制定了「统一输出模板」（output-template.md）作为强制规范，所有子 Agent 必须按固定格式输出：分析主题 → 核心结论 → 关键数据 → 维度拆解 → 异常点 → 原因判断 → 下一步建议。CEO Agent 在接收子 Agent 结果时，先检查格式是否合规，不合规则打回重算，确保最终汇总结果的格式一致性。

六、效果评估与对比

多 Agent 架构上线后，我对其在日常业务场景中的表现进行了系统性评估，重点对比了单 Agent 与多 Agent 在几个核心指标上的差异。

上下文记忆能力

单 Agent 在处理多轮对话时，上下文窗口会不断累积三个业务线的概念和术语。随着对话轮次增加，有效信息密度下降，AI 开始出现上下文丢失的情况——将资产口径错误套用到转化场景，或在长对话后丢失最初的分析目标。

多 Agent 中，每个子 Agent 拥有独立的上下文，互不干扰。asset Agent 的上下文只承载资产分析相关内容，operation Agent 只承载转化分析相关内容。这种隔离设计使得每个 Agent 的上下文始终保持高密度，不会因业务线增加而稀释。实际测试中，即使连续进行 20 轮跨业务线对话，每个子 Agent 仍能准确理解自身领域的任务目标。

任务专注度

单 Agent 在处理混合任务时需要频繁切换身份——从资产分析师切换至转化分析师，再切换至催收分析师。这种身份切换消耗了大量上下文空间，也使得 AI 在每个业务线上的专注度下降，表现为泛化的分析回复增多、精准数据减少。

多 Agent 中，每个子 Agent 锁定单一身份，专注度显著提升。asset Agent 只扮演资产分析师，operation Agent 只扮演转化分析师，collection Agent 只扮演催收分析师。实际测试中，三个子 Agent 的输出精准度均高于单 Agent 时代，结构化数据的完整性和准确性均有提升。

跨业务线分析能力

单 Agent 处理跨业务线问题（如「某渠道转化好但资产差」）时，需要在单一上下文中同时处理多条业务线的分析逻辑，容易出现口径混淆和数据错配。

多 Agent 处理跨业务线问题时，由 CEO Agent 统一接收后分发至多个子 Agent 并行执行，各子 Agent 在独立上下文中完成本业务线的分析后，结果汇聚至 CEO Agent 统一汇总。实际测试中，跨业务线问题的分析质量明显优于单 Agent，CEO Agent 能够在汇总时准确建立跨业务线的关联说明。

响应时间

单 Agent 由于所有任务都在同一上下文中处理，响应路径更短，单个问题的响应时间略低于多 Agent。

多 Agent 由于增加了 CEO 分发和结果汇聚环节，单域问题的响应时间略长于单 Agent。但跨业务线问题的响应时间反而更优——多个子 Agent 并行执行，相比单 Agent 串行处理，大幅缩短了总响应时长。

调度可靠性

单 Agent 调度逻辑简单，出错概率低，但无法处理复杂的跨业务线协同任务。

多 Agent 通过 dispatch-rules.md 实现了标准化的任务分发逻辑，所有单域问题直接路由至对应子 Agent，所有跨域问题由 CEO Agent 统一拆解分发。调度规则文件化后，调试和迭代路径清晰，当出现路由错误时可以直接定位到规则文件中的对应条目。

七、应用场景示例

多 Agent 架构的实际价值，最终需要通过具体业务场景来验证。以下是一次完整的业务周报生成演示，展示了 CEO Agent 协调三个专业子 Agent 协同完成任务的完整流程。

演示说明

本场景模拟了一次普通周报的生成流程，需要用到 CEO Agent 协调 Asset / Operation / Collection 三个专业 Agent 协同产出。所有指标名称、维度名称和数据来源均来自各 Agent 对应的真实数据仓库字段，用于演示多 Agent 分工能力、数据仓库映射能力以及报告生成能力。

协作流程

整个周报的生成遵循以下协作路径：

用户提出周报需求 → CEO Agent 拆解任务并分发 → 三个子 Agent 并行执行 → CEO Agent 汇总校验 → 输出最终周报

各 Agent 的具体职责如下：

CEO Agent确认统计周期、拆分子任务、定义统一交付结构，并在最终汇总时完成时间口径、字段口径、指标命名的一致性校验。

Asset Agent接入 asset-metrics Skill，对接 nigeria_asset.asset_data 数据源，生成放款规模、件均、资产入催、利差及维度拆解。

Operation Agent接入 apply-metrics 和 operation-data-metrics Skill，对接 nigeria_asset.apply_data 和 nigeria_asset.operation_data，生成申请、通过、领款、转化链路指标。

Collection Agent接入 collection-metrics Skill，对接 nigeria_asset.nigeria_collection_data，生成回收、展期、结清、caseR、amtR 等贷后指标。

周报核心结论示例

最终输出的周报包含以下核心结论：

放款规模：本周放款规模恢复主要依赖老客与后置老客，纯新仍未成为主拉动力。

转化：前置/后置纯新通过率偏弱，老客与多笔老客的转化效率显著更优。

资产：新客资产质量弱于老客，包体与 RG 分层差异显著，共债维度对多笔资产影响突出。

贷后：D0/S1 阶段回收较强，但 S3+ 金额回收承压，后段公司表现分化明显。

完整演示文档

完整的周报生成演示包含各业务线的详细数据图表、口径说明和校验记录，可参考以下链接：

https://github.com/QuantShawn/openclaw-multiAgents-project/blob/master/docs/06-multi-agent-weekly-report-demo.md

八、总结

本文完整记录了我从单 Agent 演进到多 Agent 协作体系的全部过程。

起点：今年二月底，我完成了 OpenClaw 的部署和飞书接入，资产分析 Skill 正式上线使用。每天在飞书向 AI 发送查询指令，即可收到格式化的指标结果，数据观测效率大幅提升。

瓶颈：随着业务需求扩展，我将转化和催收分析 Skill 陆续接入同一 Agent，但问题随之而来：上下文窗口的记忆混乱、Skill 调度冲突、任务专注度下降——单 Agent 在多业务线场景下的架构瓶颈清晰显现。

方案：我设计了一套以 CEO Agent 为协调入口、三个专业子 Agent（asset / operation / collection）负责执行的主从 Agent 架构。CEO Agent 统一接收飞书请求，通过 dispatch-rules.md 中的调度规则将任务分发至对应子 Agent，各子 Agent 在独立上下文中完成分析后，结果汇聚至 CEO Agent 按「统一输出模板」汇总输出。

落地：多 Agent 架构上线后，上下文记忆能力、任务专注度和跨业务线分析能力均显著优于单 Agent 时代。落地过程中通过制定 dispatch-rules.md 和 output-template.md 解决了上下文隔离、Skill 边界划分和结果质量把控三个关键挑战。