多智能体系统实战：基于 AgentScope Java 构建高并发故事创作平台

最新推荐文章于 2026-05-01 21:30:51 发布

原创

最新推荐文章于 2026-05-01 21:30:51 发布 · 479 阅读

多智能体系统实战：基于 AgentScope Java 构建高并发故事创作平台

1. 引言：为什么故事创作平台适合多智能体架构

在 AIGC 应用快速落地的这几年，很多团队在做“故事创作”“营销文案”“教育内容生成”“游戏剧情设计”等业务时，最先采用的通常是单次 Prompt + 单模型调用的实现方式。这种方式适合 PoC，但一旦进入真实生产环境，很快会暴露出三个问题：

单次生成链路过长，Prompt 越写越复杂，质量不可控。
高并发场景下，模型调用耗时高、成本高，系统吞吐难以提升。
业务需求不断扩展后，能力边界不清晰，系统难以维护和演进。

故事创作平台尤其典型。一次高质量的故事生成，通常并不是“一个模型一次输出”就能完成，而是由多个相对独立但又相互关联的任务组成：

题材理解与意图澄清
世界观和角色设定
情节大纲规划
分章节正文生成
语言风格统一
安全审核与质量评估
用户偏好记忆与二次编辑

这类任务天然适合拆分为多个 Agent 协作完成。每个 Agent 负责单一职责，通过调度器完成编排、状态传递与结果汇总。这样可以把“大模型黑盒问题”转化为“可拆解、可观测、可扩展的工程系统”。

本文将以 AgentScope Java + Spring Boot + Kafka + Redis + PostgreSQL + Kubernetes 为核心技术栈，系统讲解如何构建一个面向生产环境的高并发故事创作平台。重点不只在“怎么跑起来”，而在：

多智能体协作的核心原理
高并发与可扩展架构设计
生产级代码组织与治理策略
真实业务场景下的工程落地方法

2. 业务目标与系统约束

2.1 业务目标

我们假设平台面向以下场景：

C 端用户在 Web/App 中发起“故事创作”请求
支持题材、风格、目标读者、篇幅、角色设定等多维输入
支持秒级返回任务受理结果，异步查看创作进度
支持章节化生成、续写、重写、局部润色
支持高峰期每秒数百到数千个创作请求

2.2 核心技术约束

相比传统 CRUD 系统，多智能体故事平台还有几类额外约束：

外部依赖不稳定：LLM API 可能超时、限流、偶发失败
生成质量非确定性：同样输入不一定得到完全一致输出
长链路编排：一次请求涉及多个 Agent 和多个中间状态
成本敏感：Prompt 长度、模型选择、重试策略都会影响成本
可观测性要求高：必须知道每一步耗时、失败点、Token 消耗

因此，这不是一个“简单调用大模型”的系统，而是一个兼顾业务质量、性能、稳定性和成本的分布式协作系统。

3. 为什么选择 AgentScope Java

AgentScope Java 的价值不在于“再封装一次 LLM”，而在于它更适合构建有明确协作边界的多 Agent 运行时。对于 Java 技术栈团队而言，它有几个现实优势：

更容易融入现有 Spring Boot 微服务体系
更适合与 Kafka、Redis、数据库、中台能力打通
更符合企业级团队对类型安全、可测试性、工程规范的要求
更方便做线程池治理、连接池治理、链路监控和资源隔离

从工程视角看，AgentScope Java 适合作为“智能体运行时与协作框架”，而不是替代整个业务系统。更合理的定位是：

Spring Boot 负责 API、配置、生命周期和工程基础设施
AgentScope Java 负责 Agent 定义、消息传递、协作编排
Kafka/Redis/DB 负责异步解耦、状态存储与缓存
Kubernetes 负责部署、弹性扩缩容和故障恢复

4. 生产级架构总览

4.1 逻辑架构

4.2 分层设计

可以把系统拆成五层：

接入层
包括 API Gateway、鉴权、限流、灰度发布、Trace 注入。
应用层
提供故事创建、续写、重写、查询进度、获取结果等接口。
编排层
由 Story Orchestrator 负责 DAG 编排、并发调度、超时控制、失败补偿。
Agent 执行层
不同 Agent 负责特定能力，如情节、角色、章节、风格、审核。
基础设施层
Redis、Kafka、PostgreSQL、对象存储、监控、Kubernetes。

4.3 为什么不是“所有 Agent 都同步调用”

很多初版系统会把 Agent 编排写成一串同步调用：

Intent -> Plot -> Character -> Chapter -> Style -> Review

这种设计在功能上可行，但在生产上问题很大：

整个接口耗时取决于最长链路，用户体验差
任一步超时都会拖慢整体响应
Web 线程被长时间占用，吞吐快速下降
失败恢复困难，中间结果无法复用

更合理的方式是：

接口层只做任务受理，快速返回 taskId
编排层异步驱动任务状态机
可并行的 Agent 尽量并行
中间结果持久化，支持断点续跑
通过事件驱动实现弹性扩展

5. 多智能体协作原理：从链式调用到 DAG 编排

5.1 多智能体系统的本质

多智能体系统并不是“多个模型实例同时跑”，而是将复杂任务分解成一组可治理的子任务，并通过标准协议在 Agent 之间传递上下文、约束与产出。

在故事创作场景中，推荐使用 DAG 编排 而不是单纯串行：

其中：

用户需求解析 必须最先执行
情节规划 与 角色设定 可以并行
章节生成 依赖前两者结果
风格统一 和 质量审核 在后置阶段处理

这类 DAG 设计的收益非常明显：

减少关键路径耗时
明确依赖关系，便于失败重试
支持节点级扩容和独立优化
更适合做任务级可观测性

5.2 上下文管理原则

多智能体协作最大的隐患之一是上下文失控。一个 Agent 输出过长，会直接导致后续 Prompt 膨胀、成本升高、质量下降。

实践中要遵守三条原则：

结构化传递，不传自由文本大杂烩
Agent 之间尽量传 JSON 结构，而不是整段自然语言。
只传必要上下文，不传全部历史
章节生成只需要角色卡、世界观、大纲片段，不需要完整系统日志。
中间结果持久化，按需加载
上下文不要总放在内存里，应支持从 Redis 或数据库按阶段恢复。

6. 核心领域模型设计

6.1 故事任务实体

在生产系统里，首先要把“故事创作请求”建模为任务，而不是一次 HTTP 调用。

public class StoryTask {
    private Long id;
    private String taskId;
    private String userId;
    private String genre;
    private String theme;
    private String audience;
    private Integer targetWords;
    private String status;
    private String currentStage;
    private Integer progress;
    private String resultVersion;
    private Instant createdAt;
    private Instant updatedAt;
}

这里的关键字段有：

status：PENDING、RUNNING、PARTIAL_SUCCESS、SUCCESS、FAILED
currentStage：当前运行到哪一个 Agent 阶段
progress：便于前端轮询或推送展示
resultVersion：支持重写、续写、多版本编辑

6.2 上下文快照模型

为了支持断点续跑和问题排查，建议维护上下文快照：

public class StoryContextSnapshot {
    private String taskId;
    private String stage;
    private String payloadJson;
    private String promptTemplateVersion;
    private String modelName;
    private Integer promptTokens;
    private Integer completionTokens;
    private Long latencyMs;
    private Boolean success;
    private String errorCode;
    private String errorMessage;
    private Instant createdAt;
}

这类快照非常重要，它决定了系统是否真正可运维：

线上质量回溯依赖它
Prompt 优化依赖它
成本分析依赖它
失败补偿和灰度回滚依赖它

7. 生产级工程架构设计

7.1 服务拆分建议

随着规模增长，建议不要把所有逻辑都塞进一个服务。比较合理的拆分如下：

服务	核心职责	是否无状态
`story-api-service`	对外 API、鉴权、任务创建、结果查询	是
`story-orchestrator-service`	DAG 编排、状态机推进、超时控制	是
`story-agent-worker`	执行具体 Agent 任务	是
`llm-gateway-service`	模型路由、熔断、限流、降级、审计	是
`story-query-service`	查询聚合、报表、运营接口	是