多智能体工程实践升级版：基于 Spring AI Alibaba 构建可扩展、高并发、生产级方案策划系统

多智能体工程实践升级版：基于 Spring AI Alibaba 构建可扩展、高并发、生产级方案策划系统

1. 引言

当业务问题从“问答”升级到“方案生成、任务拆解、跨角色协同、执行闭环”时，单一智能体往往很快碰到能力边界。

原因并不复杂：

• 单 Agent 擅长基于统一上下文做推理，但不擅长同时兼顾多个专业角色
• 复杂场景下上下文越来越长，提示词污染、角色混叠、输出不稳定问题会放大
• 业务系统真正需要的不只是“一段回答”，而是“可落地、可审计、可扩展、可治理”的结果

因此，多智能体系统的价值不在于“让多个模型一起说话”，而在于把复杂任务拆成可治理的工程单元，让不同角色智能体以受控方式协同完成目标。

本文不再停留在 Demo 层面，而是从企业架构和生产落地视角，完整讲清楚如何基于 Spring AI Alibaba 构建一个用于“活动/营销方案策划”的多智能体系统，并重点回答四个工程问题：

• 多智能体为什么比单智能体更适合复杂策划类任务
• 如何设计一个具备高并发、可扩展、可观测、可容错的多智能体架构
• Spring AI Alibaba 在生产场景中如何组织代码、配置模型、治理调用链路
• 如何将样例代码升级成可在线上运行的生产级实现

2. 业务场景与问题拆解

2.1 真实业务背景

以一家大型营销服务公司为例，客户提交一次活动策划需求后，通常需要经过以下几个专业环节：

• 创意策划：输出主题、亮点、玩法、传播点
• 财务规划：输出预算结构、成本测算、盈亏边界
• 执行设计：输出时间排期、资源配置、现场执行流程
• 风险控制：输出合规风险、舆情风险、供应链风险
• 方案汇总：整合为可交付、可评审、可执行的正式方案

传统方式通常由多个岗位人工串行协作，常见问题包括：

• 周期长：专业角色串行作业，交付速度慢
• 协同成本高：多轮沟通反复对齐，信息损耗明显
• 质量不稳定：高度依赖个人经验，输出标准不统一
• 扩展性差：业务峰值到来时很难快速扩容
• 知识沉淀弱：经验分散在人和文档中，难以固化为可复用能力

2.2 为什么必须采用多智能体

对于“生成一份完整策划方案”这类任务，本质上不是一个问答问题，而是一个复合型认知工作流，具备以下特征：

• 角色异构：创意、财务、执行关注点完全不同
• 目标冲突：创意追求新颖，财务追求成本可控，执行追求确定性
• 结果需要整合：最终输出必须统一口径而不是多份答案并列
• 过程需要审计：必须知道每个子结论从哪里来、谁生成、何时生成

这意味着系统设计不能只是“并发调用几个 Prompt”，而应当具备：

• 任务拆解能力
• 角色隔离能力
• 结果整合能力
• 失败恢复能力
• 成本控制能力
• 可观测与审计能力

3. 多智能体系统的核心原理

3.1 多智能体不只是“多个 Bot”

多智能体系统的本质，是把复杂任务映射成一个受控协同网络。它通常包含四类核心对象：

• Planner：任务规划者，负责拆解任务与确定执行路径
• Specialist Agent：专业角色智能体，负责在限定职责内产出结果
• Orchestrator：编排协调器，负责任务调度、并发控制、超时治理、状态流转
• Synthesizer/Judge：整合与评审者，负责冲突消解、方案汇总、结果校验

如果从架构角度看，多智能体系统更像“一个 AI 驱动的分布式业务流程引擎”，而不是简单的聊天机器人组合。

3.2 多智能体协作的三种常见模式

模式一：并行分工

适合相互独立的子任务，例如：

• 创意方案
• 财务测算
• 执行流程

优点：

• 延迟低
• 易扩展
• 结构清晰

缺点：

• 子结果之间可能互相矛盾

模式二：串行增强

一个智能体的结果作为下一个智能体的输入，例如：

• 先生成初版创意
• 再让执行 Agent 判断是否可落地
• 再让财务 Agent 测算预算是否超限

优点：

• 结果更一致

缺点：

• 时延更长
• 上游错误会向下游传播

模式三：规划 + 执行 + 裁决

先由 Planner 拆解任务，再由多个 Agent 执行，最后由 Judge 进行评分或裁决。

这是企业级最常用的模式，因为它兼顾：

• 灵活性
• 可治理性
• 可观测性
• 质量控制

本文的方案策划系统，采用的是“规划弱化版 + 并行执行 + 统一整合”的模式。之所以不引入完全自治式 Planner，是因为在多数企业场景中，任务类型相对稳定，过强的自主规划反而会带来不确定性和成本上升。

4. 整体架构设计

4.1 总体架构图

4.2 分层设计

从工程落地角度，建议把系统拆成 5 层：

1. 接入层

负责：

• HTTP / OpenAPI 接入
• 鉴权
• 请求幂等
• 流量限制
• 灰度控制

2. 编排层

负责：

• 任务拆解
• 智能体选择
• 并发执行
• 超时控制
• 重试与降级
• 状态机流转

3. 智能体层

负责：

• 角色提示词管理
• 上下文构造
• 工具调用
• 模型输出结构化
• 领域规则约束

4. 领域服务层

负责：

• 预算规则
• 活动模板
• 风险规则
• 审批约束
• 业务知识库检索

5. 基础设施层

负责：

• 模型调用
• 缓存
• 消息队列
• 持久化
• 监控告警
• 配置中心

4.3 为什么要引入 Orchestrator

很多 Demo 代码会把“并发调用多个 Agent”的逻辑直接写在 Controller 里，这在生产环境中很快会失控。

Orchestrator 的价值在于把 AI 编排从业务接口中剥离出来，成为独立的可治理组件。它至少应承担以下职责：

• 建立任务上下文，如 requestId / tenantId / scene / budgetLimit
• 根据场景动态选择 Agent 集合
• 控制并发度，避免线程池或模型调用被打爆
• 对每个 Agent 应用超时、重试、熔断、隔离策略
• 聚合结果并记录执行轨迹
• 输出统一的结构化结果，供后续整合器消费

5. 关键技术选型

5.1 技术栈建议

5.2 为什么 Spring AI Alibaba 适合这类系统

相比手写 HTTP 调用模型接口，Spring AI Alibaba 的价值主要体现在：

• 模型调用抽象统一，便于替换不同模型提供方
• 可以更自然地组织 Prompt、Message、Options
• 能与 Spring Boot 的配置体系、Bean 生命周期、可观测体系对接
• 更容易沉淀出企业内部标准化 AI 开发范式

但需要明确一点：Spring AI Alibaba 解决的是“模型接入和基础 AI 编程抽象”，并不直接解决“多智能体生产编排”。编排、治理、幂等、容错、审计，仍然需要我们在应用层自己设计。

6. 生产级领域建模

如果只是返回一段字符串，很难支撑后续审计、回放、重试、质量分析。因此建议从一开始就做结构化建模。

6.1 核心对象

public enum AgentRole {
    CREATIVE,
    FINANCE,
    EXECUTION,
    RISK,
    JUDGE
}

public enum TaskStatus {
    PENDING,
    RUNNING,
    SUCCESS,
    PARTIAL_SUCCESS,
    FAILED,
    TIMEOUT
}

import java.math.BigDecimal;
import java.time.Instant;
import java.util.List;
import java.util.Map;

public record PlanningRequest(
        String requestId,
        String tenantId,
        String scene,
        String customerName,
        String requirement,
        BigDecimal budgetUpperLimit,
        Instant deadline,
        List<String> constraints,
        Map<String, Object> ext
) {
}

import java.time.Instant;

public record AgentTask(
        String taskId,
        String requestId,
        AgentRole role,
        String prompt,
        Instant createdAt
) {
}

import java.time.Instant;
import java.util.Map;

public record AgentResult(
        String taskId,
        AgentRole role,
        boolean success,
        String rawOutput,
        Map<String, Object> structuredOutput,
        String errorCode,
        String errorMessage,
        long latencyMs,
        Instant finishedAt
) {
}

import java.time.Instant;
import java.util.List;

public record PlanningResponse(
        String requestId,
        T