前述：请了一个管家来帮你处理复杂事务，但这个管家不是一个人，而是一个分工明确的团队——有人负责制定计划，有人负责监督进度，有人负责具体执行。Multiagent-OpenManus 就是这样一套"数字管家团队"，它基于 Spring AI Alibaba Graph 构建，复刻了 OpenManus 的核心能力，让多个 AI 智能体像人类团队一样协作完成复杂任务。

一、概述

简单来说，你给系统一个复杂任务，比如：

“帮我查一下阿里巴巴最近一周的股价，生成趋势图表，并保存为图片。”

放在传统单 Agent 系统里，这往往是一次"开盲盒"——你发一段长长的 Prompt，祈祷 AI 一次性把事情做对。但在这个多智能体系统里，事情变得结构化了：

  1. 规划师（Planning Agent） 接到任务后，不会急着动手，而是先坐下来写一份"施工图纸"：第一步查数据、第二步整理数据、第三步画图、第四步保存。
  2. 监工（Supervisor Agent） 拿着这份图纸，站在工地门口，一个步骤一个步骤地检查。做完一步，看看结果，决定"继续下一步"还是"收工"。
  3. 工人（Step Executing Agent） 真正动手干活，它配备了全套工具箱：搜索引擎、浏览器、Python 执行器、文件保存器。

整个过程就像人类管理团队一样：先计划，再执行，边做边检查。

二、技术架构：团队的"基础设施"

2.1 技术栈一览

组件 作用 类比
Spring Boot 3.x Web 框架和依赖管理 整个团队的办公楼
spring-ai-alibaba-graph-core 工作流引擎 团队内部的协作流程手册
spring-ai-alibaba-starter-dashscope 阿里云大模型接入 团队成员的"大脑"（通义千问）
ReactAgent ReAct 模式的智能体 具备"思考-行动"能力的员工
ToolCallback 工具调用封装 员工手里的专业工具箱

2.2 什么是 ReAct 模式？

这里要停下来解释一下，因为原文只是提了一嘴。ReAct 是 Reasoning + Acting 的缩写，是智能体领域非常经典的一种设计模式。

想象一个侦探破案：

  • 推理（Reason）：“现场有脚印，说明嫌疑人从后门进入。”
  • 行动（Act）：“我去后门调取监控录像。”
  • 观察（Observe）：“监控显示嫌疑人穿着红色外套。”
  • 再推理：“红色外套……这和目击证人的描述一致。”

ReAct 模式就是让 AI 也遵循这个循环：思考 → 行动 → 观察 → 再思考。ReactAgent 就是封装了这个循环的智能体，它会在"想"和"做"之间反复迭代，最多执行你设定的轮次（比如 10 次）。

2.3 核心架构图

生成步骤清单

continue

end

步骤执行结果

可选工具

用户输入

Planning Agent
规划师
📝 制定计划

Supervisor Agent
监工/调度员
🧠 判断继续或结束

Step Executing Agent
执行工人
🔧 调用工具执行

输出最终结果

🧰 工具箱
• GoogleSearch
• BrowserUseTool
• PythonExecute
• FileSaver
• DocLoader

三、核心组件详解：认识每一位"团队成员"

3.1 Planning Agent（规划师）

人设：团队里的"战略家"。接到任务后不急着动手，而是先拆解。

技术实现：

ReactAgent planningAgent = new ReactAgent(
    "planningAgent",      // 名称
    planningClient,       // ChatClient，连接大模型
    Builder.getFunctionCallbackList(),  // 工具列表：只有 PlanningTool
    10                    // 最大迭代次数
);

它唯一的工具是 PlanningTool。这很有意思——规划师不需要去搜索网页或执行代码，它只需要管理计划。就像项目经理不需要亲自写代码，但需要把 Jira 任务拆清楚。

System Prompt 的核心逻辑：

当用户说"帮我查阿里巴巴股价并生成图表"时，规划师会输出一个结构化的"施工图纸"：

{
  "planId": "plan_001",
  "title": "查询阿里巴巴股价并生成图表",
  "steps": [
    "1. 使用 GoogleSearch 搜索阿里巴巴最近一周股价数据",
    "2. 使用 BrowserUseTool 打开财经网站采集具体数据",
    "3. 使用 PythonExecute 执行脚本生成趋势图表",
    "4. 使用 FileSaver 将图表保存为 PNG 文件"
  ]
}

为什么需要专门的规划师？

在单 Agent 系统里，规划和执行混在一起，很容易"边做边想"，结果做到一半发现方向错了。把规划独立出来，相当于先画图纸再施工，能大幅减少返工。

3.2 Supervisor Agent（监工）

人设：团队里的"调度中枢"。它不做具体工作，但掌握着整个项目的方向盘。

核心逻辑：

public String think(OverAllState state) {
    String nextPrompt = (String) state.value("step_prompt").orElseThrow();

    // 检查是否收到"完工信号"
    if (nextPrompt.equalsIgnoreCase("Plan completed.")) {
        state.updateState(Map.of("final_output", 
            state.value("step_output").orElseThrow()));
        return "end";  // 宣布收工
    }

    return "continue";  // 继续下一步
}

工作流程图解：

User Step Executing Agent Supervisor Agent Planning Agent User Step Executing Agent Supervisor Agent Planning Agent alt [还有未完成的步骤] [所有步骤已完成] loop [步骤循环] 提交计划（4个步骤） 检查当前步骤提示 派发步骤任务（continue） 执行工具调用 返回执行结果 检测到 "Plan completed." 返回 final_output（end）

设计精妙之处：Supervisor 模拟了人类管理者的决策方式——不是一次性把所有任务扔给执行者，而是一步一验收。每完成一步，执行者把结果交回，Supervisor 看看是否达标，再决定下一步。这种"小步快跑、及时反馈"的机制，让复杂任务变得可控。

3.3 Step Executing Agent（执行工人）

人设：团队里的"全能技工"。接到 Supervisor 派发的具体步骤后，立即动手。

技术实现：

ReactAgent stepAgent = new ReactAgent(
    "stepAgent",
    stepClient,
    Builder.getManusAgentFunctionCallbacks(),  // 全套工具
    10
);

工具箱详解：

工具 功能 典型场景
GoogleSearch 网络搜索 “搜索阿里巴巴最新财报”
BrowserUseTool 浏览器自动化 “打开网页、点击按钮、截图”
PythonExecute 执行 Python 代码 “数据分析、生成图表、数学计算”
FileSaver 文件保存 “保存 txt、py、html、png 等文件”
DocLoader 读取本地文件/目录 “查看已有文件内容作为参考”

执行过程示例：

假设 Supervisor 派发了步骤 3：“使用 PythonExecute 生成趋势图表”。

Step Agent 的 ReAct 循环会这样运转：

思考：用户需要股价趋势图，我手头有股价数据，应该用 matplotlib 画图。
行动：调用 PythonExecute，传入绘图代码。
观察：代码执行成功，返回了图表文件路径 /tmp/chart.png。
思考：任务完成，向 Supervisor 汇报结果。

3.4 PlanningTool（计划管理工具）

人设：团队里的"项目管理系统"（类似 Jira 或 Trello）。LLM 可以通过调用它来创建、更新、追踪计划。

支持的操作：

// 创建计划
planningTool.run("{command: 'create', plan_id: '1', title: '查询股价', steps: ['...']}")

// 更新计划内容
planningTool.run("{command: 'update', plan_id: '1', ...}")

// 列出所有计划
planningTool.run("{command: 'list'}")

// 标记步骤状态（done / in_progress / pending）
planningTool.run("{command: 'mark_step', plan_id: '1', step_index: 0, status: 'done'}")

为什么需要它？

因为 LLM 本身没有"记忆"能力。你告诉它"这是第 3 步"，它可能过一会儿就忘了。PlanningTool 把计划结构化地存储起来（虽然当前是内存存储，见后文问题分析），让系统能随时查询"现在做到哪一步了"、“下一步该做什么”。

四、工作流状态管理：团队的"共享白板"

在多智能体协作中，状态管理是核心难题。每个 Agent 都需要知道"现在发生了什么"，就像团队成员需要共享一块白板，随时查看项目进度。

4.1 状态键与更新策略

OverAllStateFactory stateFactory = () -> {
    OverAllState state = new OverAllState();
    
    // 注册状态键和对应的更新策略
    state.registerKeyAndStrategy("plan", new ReplaceStrategy());           
    state.registerKeyAndStrategy("step_prompt", new ReplaceStrategy());    
    state.registerKeyAndStrategy("step_output", new ReplaceStrategy());    
    state.registerKeyAndStrategy("final_output", new ReplaceStrategy());   
    return state;
};

这里要补全一个概念：ReplaceStrategy 是什么？

在状态管理中，当多个 Agent 先后更新同一个键时，系统需要知道如何合并新值和旧值。ReplaceStrategy 是最简单的策略——直接覆盖。也就是说，新的 step_output 会直接替换旧的，而不是追加。

为什么用这个策略？因为在这个架构里，Supervisor 每次只关心当前步骤的最新结果，不需要历史累积。如果需要保留历史，可以使用 AppendStrategy 或其他自定义策略。

4.2 状态流转全景

用户请求

提交计划(plan)

continue
派发步骤(step_prompt)

返回结果(step_output)

end
输出结果(final_output)

planning_agent

supervisor_agent

step_executing_agent

4.3 边定义（工作流连接）

// 1. 开始 → 规划师
.addEdge(START, "planning_agent")

// 2. 规划师 → 监工
.addEdge("planning_agent", "supervisor_agent")

// 3. 监工 → 执行者（条件边：根据 think() 返回值路由）
.addConditionalEdges("supervisor_agent",
    edge_async(supervisorAgent::think),
    Map.of("continue", "step_executing_agent", "end", END))

// 4. 执行者 → 监工（循环边）
.addEdge("step_executing_agent", "supervisor_agent")

条件边（Conditional Edge） 是整个工作流的灵魂。Supervisor 的 think() 方法就像一个路由函数，返回 "continue" 就把流量转发给执行者，返回 "end" 就直接结束工作流。这种设计让系统具备了动态决策能力，而不是死板地按固定顺序执行。

五、接口说明

目前系统对外暴露了一个极简的 HTTP 接口：

接口 方法 路径 功能
对话 GET /manus/chat 发送任务，获取最终结果

请求示例：

# 简单任务
curl "http://localhost:8080/manus/chat?query=你好"

# 复杂任务（涉及多步推理和工具调用）
curl "http://localhost:8080/manus/chat?query=帮我查一下今天北京天气怎么样"

返回示例：

{ "final_output": "今天北京天气晴朗，气温15-25℃，适合出行。" }

💡 设计说明：当前接口是同步阻塞的。对于复杂任务，可能需要几十秒甚至几分钟（多次 LLM 调用 + 工具执行）。生产环境中建议改为异步接口或SSE 流式返回，避免 HTTP 超时。

六、⚠️ 深度问题分析 & 优化方案

原文列出了 6 个问题，这里我把每个问题的技术原理和替代方案补全，让你不仅知道"怎么做"，还知道"为什么这么做"。

问题 1：内存存储无持久化

现状：

// PlanningTool 内部
private Map<String, Map<String, Object>> plans = new HashMap<>();

问题本质：HashMap 存储在 JVM 堆内存中。服务重启、OOM、或者横向扩容（多实例部署）时，计划数据会全部丢失。

优化方案：

@Component
public class PlanningTool implements BiFunction<String, ToolContext, String> {
    
    @Autowired
    private StringRedisTemplate redisTemplate;
    
    private static final String PLAN_PREFIX = "openmanus:plan:";
    
    public void savePlan(String planId, Map<String, Object> plan) {
        // 使用 Redis Hash 存储，支持过期时间
        redisTemplate.opsForHash().putAll(PLAN_PREFIX + planId, plan);
        redisTemplate.expire(PLAN_PREFIX + planId, Duration.ofHours(24));
    }
    
    public Map<String, Object> getPlan(String planId) {
        return redisTemplate.opsForHash().entries(PLAN_PREFIX + planId);
    }
}

进阶建议：如果计划数据需要长期归档，可以引入 MySQL/PostgreSQL 做持久化，Redis 只做缓存层。

问题 2：Prompt 硬编码在代码中

现状：

String PLANNING_SYSTEM_PROMPT = """
    你是一个任务规划专家...
    请按以下格式输出...
    """;

问题本质：Prompt 是 LLM 应用的"业务逻辑"。写死在代码里意味着每次调优都需要重新编译、打包、部署，迭代效率极低。

优化方案：

application.yml 配置：

manus:
  prompts:
    planning: classpath:prompts/planning.txt
    step: classpath:prompts/step.txt
    supervisor: classpath:prompts/supervisor.txt

代码加载：

@Value("${manus.prompts.planning}")
private Resource planningPromptResource;

@PostConstruct
public void init() throws IOException {
    String planningPrompt = Files.readString(planningPromptResource.getFile().toPath());
    // 现在可以在运行时热更新 Prompt 了
}

更进一步：结合 Spring Cloud Config 或 Nacos，实现配置中心热更新，不重启服务就能调整 Prompt。

问题 3：模型配置不够灵活

现状：Planning Agent 和 Step Agent 共用同一个模型配置。

问题本质：规划任务和执行任务对模型的能力要求不同：

  • 规划需要强逻辑推理能力，适合用参数规模较大的模型（如 qwen3-max）。
  • 执行更多是工具调用和格式化输出，可以用更快、更便宜的模型（如 qwen3-32b）。

优化方案：

# application.yml
manus:
  models:
    planning:
      name: qwen3-max
      temperature: 0.2  # 低温度，输出更稳定
    step:
      name: qwen3-32b
      temperature: 0.7  # 稍高温度，应对多样化工具场景
    supervisor:
      name: qwen3-max
      temperature: 0.1  # 极低温度，判断结果要稳定

@Configuration
public class ModelConfig {
    
    @Bean
    public ChatClient planningClient(
            @Value("${manus.models.planning.name}") String model,
            DashScopeApi api) {
        return DashScopeChatClient.builder()
                .dashScopeApi(api)
                .defaultOptions(DashScopeChatOptions.builder()
                        .withModel(model)
                        .withTemperature(0.2)
                        .build())
                .build();
    }
    
    @Bean
    public ChatClient stepClient(
            @Value("${manus.models.step.name}") String model,
            DashScopeApi api) {
        return DashScopeChatClient.builder()
                .dashScopeApi(api)
                .defaultOptions(DashScopeChatOptions.builder()
                        .withModel(model)
                        .withTemperature(0.7)
                        .build())
                .build();
    }
}

问题 4：工具执行缺少超时控制

现状：PythonExecute 或 BrowserUseTool 可能无限期阻塞。

问题本质：工具调用本质上是外部进程调用（执行 Python 脚本或启动浏览器），如果没有超时保护，一个"死循环"的脚本就能拖垮整个工作流。

优化方案：

@Component
public class PythonExecute {
    
    private static final long TIMEOUT_SECONDS = 30;
    
    public ToolExecuteResult run(String toolInput) {
        ExecutorService executor = Executors.newSingleThreadExecutor();
        Future<ToolExecuteResult> future = executor.submit(() -> executeCode(toolInput));
        
        try {
            return future.get(TIMEOUT_SECONDS, TimeUnit.SECONDS);
        } catch (TimeoutException e) {
            future.cancel(true);  // 中断线程
            return new ToolExecuteResult(
                "❌ 执行超时（" + TIMEOUT_SECONDS + "秒）。请检查代码是否包含无限循环或耗时操作。"
            );
        } catch (Exception e) {
            return new ToolExecuteResult("❌ 执行异常: " + e.getMessage());
        } finally {
            executor.shutdownNow();
        }
    }
}

补充建议：对于浏览器操作，可以设置 Playwright 的 setDefaultTimeout：

page.setDefaultTimeout(30000);  // 30秒页面操作超时
page.setDefaultNavigationTimeout(30000);  // 30秒导航超时

问题 5：没有错误重试机制

现状：某个步骤失败后，整个工作流直接终止。

问题本质：LLM 调用和工具执行都有概率性失败（网络抖动、模型幻觉、网页临时不可用）。没有重试机制，系统的鲁棒性很差。

优化方案：

在 Spring AI Alibaba Graph 中，可以通过包装 Node Action 实现重试：

// 为 Step Executing Agent 添加重试装饰器
AsyncNodeAction stepActionWithRetry = AsyncNodeAction.node_async(state -> {
    int maxRetries = 3;
    Exception lastException = null;
    
    for (int i = 0; i < maxRetries; i++) {
        try {
            return stepAgent.apply(state);
        } catch (Exception e) {
            lastException = e;
            // 指数退避：1秒、2秒、4秒
            Thread.sleep(1000 * (1 << i));
        }
    }
    // 重试耗尽，返回错误信息
    state.updateState(Map.of("step_output", "步骤执行失败（已重试" + maxRetries + "次）: " + lastException.getMessage()));
    return state;
});

更优雅的方式：使用 Spring Retry 框架：

@Retryable(
    retryFor = {ToolExecutionException.class, LLMException.class},
    maxAttempts = 3,
    backoff = @Backoff(delay = 1000, multiplier = 2)
)
public String executeStep(OverAllState state) {
    return stepAgent.apply(state);
}

问题 6：BrowserUseTool 的依赖陷阱

现状：BrowserUseTool 依赖 Playwright 或 Selenium，但服务器环境往往缺少浏览器。

问题本质：浏览器自动化工具需要完整的浏览器二进制文件和对应的系统依赖库（如 GTK、字体库等）。在 headless 服务器上，这往往不是"装个 Chrome"那么简单。

完整解决方案：

方案 A：服务器原生安装（Ubuntu）

# 1. 安装系统依赖
sudo apt-get update
sudo apt-get install -y libnss3 libatk-bridge2.0-0 libxss1 libgtk-3-0

# 2. 安装 Playwright Python 依赖
pip3 install playwright

# 3. 下载浏览器二进制文件（Chromium、Firefox、WebKit）
playwright install chromium

# 4. 验证
python3 -c "from playwright.sync_api import sync_playwright; p = sync_playwright().start(); b = p.chromium.launch(); print('OK'); b.close(); p.stop()"

方案 B：Docker 部署（推荐，隔离性好）

FROM mcr.microsoft.com/playwright/java:v1.40.0-jammy

# 已经内置了 Playwright 和浏览器依赖
WORKDIR /app
COPY target/*.jar app.jar

ENV DASHSCOPE_API_KEY=${DASHSCOPE_API_KEY}
EXPOSE 8080

ENTRYPOINT ["java", "-jar", "-Xmx4g", "app.jar"]

⚠️ 注意：Playwright 的 Docker 镜像很大（约 1-2GB），因为包含了 Chromium、Firefox 和 WebKit 三套浏览器。如果只用 Chromium，可以基于 ubuntu:22.04 自行精简。

七、部署实操指南：从本地到生产

7.1 环境准备

软件 版本要求 作用
JDK 17+ 运行 Spring Boot
Maven 3.8+ 编译打包
Python 3.8+ PythonExecute 工具的后端
Playwright 最新 BrowserUseTool 的后端（可选但推荐） 
# Ubuntu 一键安装
sudo apt update
sudo apt install -y openjdk-17-jdk maven python3 python3-pip

# 验证
java -version   # 应显示 17 或更高
mvn -version    # 应显示 3.8+
python3 --version  # 应显示 3.8+

7.2 获取 API Key

  1. 访问 DashScope 控制台
  2. 创建 API Key
  3. 安全提醒：不要把 Key 提交到 Git！使用环境变量或配置中心管理。

7.3 本地运行

# 进入项目目录
cd /home/tht/examples-main/spring-ai-alibaba-graph-example/multiagent-openmanus

# 配置环境变量（推荐）
export DASHSCOPE_API_KEY="sk-你的API-Key"

# 编译
mvn clean package -DskipTests

# 启动
mvn spring-boot:run

看到如下日志表示启动成功：

🚀 Started GraphApplication in X.XXX seconds
🎯 Application is running on port 8080

7.4 接口测试

# 测试 1：简单对话（验证服务连通性）
curl "http://localhost:8080/manus/chat?query=你好"

# 测试 2：搜索任务（验证 GoogleSearch）
curl "http://localhost:8080/manus/chat?query=帮我查一下今天北京天气"

# 测试 3：代码执行（验证 PythonExecute）
curl "http://localhost:8080/manus/chat?query=计算1到100的累加和并用Python打印"

# 测试 4：浏览器操作（验证 BrowserUseTool，如果已安装）
curl "http://localhost:8080/manus/chat?query=打开百度首页并告诉我标题是什么"

7.5 生产部署：Systemd 方式

步骤 1：上传 JAR 包

# 服务器上创建目录
mkdir -p /opt/openmanus && cd /opt/openmanus

# 本机打包后上传
mvn clean package -DskipTests
scp target/multiagent-openmanus-*.jar root@your-server:/opt/openmanus/

步骤 2：创建 Systemd 服务

sudo vim /etc/systemd/system/openmanus.service

写入以下内容：

[Unit]
Description=OpenManus Multi-Agent Service
After=network.target

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/opt/openmanus

# JVM 配置：根据服务器内存调整
ExecStart=/usr/bin/java \
    -jar \
    -Xmx4g \
    -Xms2g \
    -XX:+UseG1GC \
    -XX:MaxGCPauseMillis=200 \
    /opt/openmanus/multiagent-openmanus-*.jar

# 环境变量
Environment="DASHSCOPE_API_KEY=sk-你的API-Key"
Environment="PYTHON_PATH=/usr/bin/python3"

# 进程保护
Restart=always
RestartSec=10
StartLimitInterval=60s
StartLimitBurst=3

[Install]
WantedBy=multi-user.target

步骤 3：启动并启用

sudo systemctl daemon-reload
sudo systemctl start openmanus
sudo systemctl enable openmanus  # 开机自启

# 查看状态
sudo systemctl status openmanus

# 查看日志
sudo journalctl -u openmanus -f -n 100

7.6 生产部署：Docker 方式（推荐）

Dockerfile：

# 使用包含 Playwright 的 Java 基础镜像
FROM mcr.microsoft.com/playwright/java:v1.40.0-jammy

LABEL maintainer="your-team@company.com"

WORKDIR /app

# 安装 Python（基础镜像可能缺少）
RUN apt-get update && apt-get install -y python3 python3-pip \
    && rm -rf /var/lib/apt/lists/*

# 复制 JAR
COPY target/multiagent-openmanus-*.jar app.jar

# 健康检查
HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \
    CMD curl -f http://localhost:8080/actuator/health || exit 1

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "-Xmx4g", "-Xms2g", "app.jar"]

构建与运行：

# 构建镜像
docker build -t openmanus:latest .

# 运行容器
docker run -d \
    --name openmanus \
    -p 8080:8080 \
    -e DASHSCOPE_API_KEY="sk-你的API-Key" \
    -e SPRING_PROFILES_ACTIVE=prod \
    --memory=6g \
    --cpus=4 \
    --restart=unless-stopped \
    openmanus:latest

# 查看日志
docker logs -f openmanus

7.7 Nginx 反向代理配置

由于复杂任务可能需要几分钟才能完成，Nginx 的超时配置必须放宽：

server {
    listen 80;
    server_name manus.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        
        # 基础代理头
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # ⚠️ 关键：长连接和流式响应支持
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_cache off;
        
        # ⚠️ 关键：超时设置（单位：秒）
        proxy_connect_timeout 300;  # 连接超时 5 分钟
        proxy_send_timeout 300;     # 发送超时 5 分钟
        proxy_read_timeout 300;     # 读取超时 5 分钟
        
        # 大响应体支持（如果返回文件）
        client_max_body_size 50m;
    }
}

八、常见问题排查手册

问题现象 根因 解决方案
Python 执行失败 服务器未安装 Python 或缺少依赖 sudo apt install python3 python3-pip
浏览器操作报错 Playwright/Chromium 未安装 执行 playwright install chromium
LLM 调用超时 网络到 DashScope 不稳定 检查 curl -I https://dashscope.aliyuncs.com，或增加超时配置
内存溢出 OOM JVM 堆内存不足或 Python 脚本内存泄漏 增加 -Xmx8g，或限制 Python 执行内存
工具执行被拒绝 internalToolExecutionEnabled(false) 配置下工具调用异常 检查 ToolCallback 是否正确注册到 Agent
计划丢失 服务重启后内存数据清空 接入 Redis 持久化（见问题 1）
返回结果为空 Supervisor 判断逻辑异常或 LLM 未返回有效内容 检查日志中的 step_output 和 final_output

九、总结：这个项目的价值

Multiagent-OpenManus 不仅仅是一个"能跑通"的示例，它展示了一套可落地的多智能体协作范式：

✅ 分层架构：规划、调度、执行三层分离，职责清晰
✅ ReAct 模式：每个 Agent 都具备"思考-行动"的自主能力
✅ 循环执行：Supervisor 的动态决策让工作流具备弹性
✅ 工具丰富：搜索、浏览、编程、文件操作覆盖大多数办公场景

最核心的设计亮点在于 Supervisor Agent。它用极简的逻辑（continue vs end）实现了复杂的状态机控制，模拟了人类管理者"制定计划 → 分步验收 → 决定下一步"的本能工作方式。

如果你要在此基础上进行二次开发，建议优先解决持久化和超时控制两个问题，这是从"Demo"走向"生产"的必经之路。

# spring boot # 人工智能 # java
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

扣子（Coze）漫画视频生成完整解析

扣子漫画视频是的流水线式自动生成，从文字主题到完整成片，全程由 LLM、图像、视频、语音模型协同完成，本质是把传统漫剧制作的全部自动化。下面从完整解析。

avatar AtomGit开源社区

智能的底层规律——从数据到算法的必然进化趋势

先抛出两个现象的结论，短视频的兴起完美契合了数据极致压缩的趋势。意识是数据的极致压缩与演化。如果我们将“数据”理解为原始的经验、刺激或记录，而“算法”理解为可执行、可泛化的规则或模型，那么从生物进化和AI发展的双重视角来看，——但这里的“必然”需要放在适应性系统与信息压缩的规律下来理解。

avatar AtomGit开源社区
cover

技术选型观察__数字孪生应用构建：零代码工具与专业开发套件的适配边界

avatar AtomGit开源社区