一、今天主要学了什么？

今天继续学习 AI Agent 相关内容，重点不再只是停留在“一个 Agent 能不能调用工具”这个层面，而是开始理解更复杂的 Agent 系统设计。

之前学习 Agent 的时候，我对它的理解大概是：

Agent = LLM + Prompt + Tool + Memory + 外部能力

也就是说，一个 Agent 不是简单地调用一次大模型，而是可以根据用户目标，结合提示词、工具、上下文记忆等能力，完成更复杂的任务。

但是当我进一步接触到实际项目之后，发现 Agent 项目里经常会出现一些更复杂的概念，比如：

  • 单 Agent
  • 多 Agent
  • Supervisor Agent
  • Planner Agent
  • Executor Agent
  • ReAct 模式
  • Plan-Execute-Replan 模式
  • 工作流 Workflow
  • outputKey
  • SSE
  • Flux
  • ChatMemory

这些概念如果只看名字，很容易混在一起。今天的学习重点，就是把这些概念之间的关系慢慢理清楚。

二、我之前对多 Agent 的误解

一开始我对“多 Agent”的理解有点偏简单。

我原来以为：

一个项目里有一个聊天 Agent，又有一个运维 Agent，那这是不是就算多 Agent？

后来发现，这种理解不够准确。

如果一个系统里只是有多个功能模块，比如：

  • 普通对话模块
  • 运维问答模块
  • 知识库问答模块
  • 告警查询模块

这并不一定就叫多 Agent。

因为它们可能只是普通的业务功能拆分，本质上还是由一个核心 Agent 或一个 ChatClient 在处理请求。

真正意义上的多 Agent，更强调的是：

在一次任务执行过程中，多个具备独立职责的 Agent 之间发生协作。

比如一个智能运维任务：

用户问：

“帮我分析一下这个服务为什么频繁报警。”

如果系统内部只是一个 Agent 直接调用日志工具、监控工具、数据库工具，然后回答用户，那它更像是单 Agent。

但如果系统内部拆成：

  • Supervisor Agent：负责总控和调度
  • Planner Agent：负责制定排查计划
  • Executor Agent：负责执行具体工具调用
  • Replanner Agent：根据执行结果调整下一步计划

这时候就更接近多 Agent 协作。

所以，今天我理解到一个关键点：

多 Agent 不是“工具多”，也不是“功能多”，而是多个 Agent 在同一个任务中承担不同角色，并且存在协作关系。

三、一个 Agent 到底是什么？

今天也重新梳理了一下 Agent 的基本组成。

一个 Agent 通常不是一个简单的 Controller，也不是一个普通 Service 方法，而是一个围绕大模型构建的智能执行单元。

它通常包括：

组成部分 作用
LLM 负责理解、推理、生成
Prompt 约束 Agent 的角色和行为
Tool 提供外部操作能力
Memory 保存上下文和历史状态
Planning 负责拆解任务
Execution 负责执行动作
Reflection / Replan 根据结果调整策略

所以，一个 Agent 可以理解成：

一个拥有明确角色、目标、工具和上下文能力的智能执行单元。

比如在运维场景中，一个 Agent 不只是回答“报警是什么”，它还可能需要：

  1. 理解用户的问题；
  2. 判断是否需要查告警；
  3. 判断是否需要查日志；
  4. 调用 Prometheus、CLS、数据库等工具；
  5. 根据工具返回结果继续分析；
  6. 最后生成排查结论。

这就已经不是普通问答，而是具备一定任务执行能力的 Agent。

四、单 Agent 和多 Agent 的区别

今天学习过程中，一个比较重要的问题是：

怎么判断一个项目是单 Agent 还是多 Agent？

我的理解是，可以从几个角度判断。

1. 看是否有多个明确的 Agent 角色

如果代码中只是一个 ChatClient，绑定了一堆工具，比如：

chatClient.prompt()
        .user(message)
        .call()
        .content();

然后这个 ChatClient 可以调用知识库工具、日志工具、监控工具等，那它更像是单 Agent。

因为虽然工具很多，但真正做决策的核心还是一个 Agent。

但是如果代码中出现类似：

SupervisorAgent supervisorAgent = SupervisorAgent.builder()
        .name("ai_ops_supervisor")
        .description("负责调度 Planner 与 Executor 的多 Agent 控制器")
        .model(chatModel)
        .systemPrompt(buildSupervisorSystemPrompt())
        .subAgents(List.of(plannerAgent, executorAgent))
        .build();

这里就明显不只是一个 Agent 了。

因为它里面有：

  • supervisorAgent
  • plannerAgent
  • executorAgent

而且它们之间还有上下级调度关系。

这种结构就更像多 Agent。

2. 看是否存在任务拆分和角色协作

单 Agent 通常是：

用户输入 → Agent 判断 → 调用工具 → 返回结果

多 Agent 通常是：

用户输入 → Supervisor 判断任务类型 → Planner 制定计划 → Executor 执行任务 → Supervisor 汇总结果 → 返回用户

也就是说，多 Agent 更强调“协作流程”。

例如：

用户问题
  ↓
Supervisor Agent 识别任务
  ↓
Planner Agent 拆解步骤
  ↓
Executor Agent 调用工具执行
  ↓
Supervisor Agent 汇总结果
  ↓
返回最终答案

这种流程就比单 Agent 更复杂，也更适合处理多步骤任务。

3. 看每个 Agent 是否有独立的 Prompt 和职责

多 Agent 的核心不是简单多写几个类，而是每个 Agent 都有自己的职责边界。

例如：

Agent 职责
Supervisor Agent 总控、调度、判断下一步
Planner Agent 负责制定计划
Executor Agent 负责执行工具调用
Replanner Agent 负责根据结果调整计划

如果这些角色都有独立的 Prompt、独立的任务目标，那么它就更像多 Agent 系统。

如果只是一个 Agent 绑定很多工具，那只能说这个 Agent 能力比较多，但不一定是多 Agent。

五、Supervisor Agent 怎么理解？

今天重点看到了 SupervisorAgent 这个概念。

一开始我觉得：

这不就是又包了一层吗？为什么要弄这么复杂？

后来理解到，SupervisorAgent 的作用有点像“总指挥”。

它不是直接干所有事情，而是负责判断：

  • 当前任务应该交给谁处理？
  • 是否需要 Planner 制定计划？
  • 是否需要 Executor 调用工具？
  • 子 Agent 返回的结果是否足够？
  • 是否需要继续补充执行？
  • 最终怎么汇总给用户？

所以 SupervisorAgent 的重点不是“工具调用”，而是“调度决策”。

可以类比成一个团队：

Supervisor：项目经理 / 调度中心
Planner：方案设计人员
Executor：执行人员
Tool：具体工具
LLM：每个 Agent 背后的推理能力

这样理解之后，多 Agent 的结构就清晰很多了。

六、Plan-Execute-Replan 是什么？

今天还学习了 Plan-Execute-Replan 这种 Agent 设计模式。

它可以理解成一种任务执行流程：

Plan：先制定计划
Execute：执行计划
Replan：根据执行结果重新规划

例如用户问：

“帮我分析订单服务最近为什么响应变慢。”

Agent 可能不会直接回答，而是先规划：

1. 查询订单服务最近的监控指标；
2. 查看 CPU、内存、QPS、响应时间；
3. 查询最近异常日志；
4. 判断是否和数据库慢查询有关；
5. 汇总可能原因。

然后 Executor 开始执行这些步骤。

如果执行过程中发现：

日志里没有明显异常，但是数据库连接池耗尽。

那么 Replan 就会调整后续计划：

继续查询数据库连接池指标和慢 SQL 情况。

所以 Plan-Execute-Replan 的核心价值是：

Agent 不只是一次性回答，而是可以边执行、边观察、边调整。

这比普通的问答更接近真实任务处理过程。

七、ReAct 和 Plan-Execute-Replan 的区别

之前学习过 ReAct，今天也把它和 Plan-Execute-Replan 做了对比。

ReAct 的核心是：

Reasoning + Acting

也就是：

一边思考，一边行动。

它常见的执行过程是：

Thought：我需要先查监控
Action：调用监控工具
Observation：返回 CPU 使用率很高
Thought：可能是流量突增，需要继续查 QPS
Action：调用 QPS 查询工具
Observation：QPS 确实升高
Final Answer：总结原因

而 Plan-Execute-Replan 更偏向：

先整体规划，再执行，再根据结果修正计划

简单来说：

模式 特点
ReAct 边想边做，适合动态工具调用
Plan-Execute-Replan 先规划，再执行，再调整，适合复杂任务
Workflow 流程更固定，适合业务流程编排
Multi-Agent 多个 Agent 分工协作，适合复杂系统

我现在的理解是：

ReAct 更像 Agent 的思考与行动模式；
Plan-Execute-Replan 更像复杂任务的执行策略；
Workflow 更像固定业务流程；
Multi-Agent 更像多个角色之间的协作架构。

这几个概念不是互斥关系，而是可以组合使用。

比如一个多 Agent 系统里，Executor Agent 内部也可以使用 ReAct 模式；Supervisor 整体又可以采用 Plan-Execute-Replan 流程。

八、outputKey 怎么理解？

今天还学习了 outputKey 这个概念。

一开始看到 outputKey 的时候，感觉它好像只是一个普通字段，但其实它在 Agent 协作中很重要。

我的理解是：

outputKey 就是把某一步 Agent 的输出结果保存到一个指定的变量名里，方便后续步骤继续使用。

比如 Planner Agent 生成了一个排查计划：

{
  "plan": [
    "查询服务监控",
    "查询异常日志",
    "分析数据库慢查询"
  ]
}

如果给这个结果设置：

outputKey = "diagnosisPlan"

那么后续 Executor Agent 就可以从上下文中拿到：

diagnosisPlan

然后根据这个计划继续执行。

所以 outputKey 的作用有点像：

上一步结果的命名存储

在多 Agent 或工作流系统中，它主要解决的是：

上一个 Agent 的输出，怎么传给下一个 Agent？

如果没有类似 outputKey 的机制，每个 Agent 之间的数据传递就会很混乱。

九、Flux 和 SSE 的关系

今天还顺带学习了 Flux 和 SSE。

SSE 是：

Server-Sent Events

也就是服务端向客户端持续推送数据的一种 HTTP 技术。

它常用于大模型流式输出，比如：

模型正在生成中...
一个字一个字返回给前端...

而 Flux 是响应式编程中的一个概念，常见于 Spring WebFlux。

Flux 可以理解成：

一个可以连续产生多个数据的异步数据流。

在 Agent 项目中，如果使用流式响应，后端可能会返回：

Flux<String>

然后通过 SSE 持续推送给前端。

所以我现在对它们的理解是：

Flux：后端代码层面的数据流
SSE：HTTP 传输层面的推送方式

也就是说：

Flux 负责“产生一段一段的数据”，SSE 负责“把这些数据推给前端”。

两者经常一起出现，但不是同一个东西。

十、ChatMemory 和会话记忆

今天也继续理解了 Agent 中的会话记忆。

普通的大模型调用本身是无状态的。

也就是说，每次请求如果不传历史记录，大模型其实并不知道之前聊过什么。

所以 Agent 项目中通常会设计 ChatMemory。

最简单的 ChatMemory 可以直接保存在内存中，例如用 Map 存储：

Map<String, List<Message>> memory = new ConcurrentHashMap<>();

其中 key 可以是 sessionId，value 是这个会话对应的历史消息。

这样就可以实现：

不同 sessionId 对应不同聊天记录

如果后续项目要做得更完整，也可以把历史记录放到 Redis、MongoDB、数据库中。

比如：

存储方式 特点
内存 Map 简单，但服务重启数据丢失
Redis 适合高性能会话缓存
MongoDB 适合存储结构化聊天记录
MySQL 适合业务系统统一管理

今天也理解到，MongoDB 经常用于存储聊天记录，是因为聊天消息本身结构比较灵活，比如：

{
  "sessionId": "xxx",
  "role": "user",
  "content": "帮我分析一下报警",
  "timestamp": "..."
}

这种文档型数据和 MongoDB 的模型比较契合。

十一、今天对 Agent 项目的理解变化

今天最大的收获是，我对 Agent 项目不再只是停留在“调用大模型 + 调工具”的理解。

之前我可能会认为：

只要能调工具，就是 Agent。

现在理解更清楚了：

工具调用只是 Agent 的基础能力，真正复杂的 Agent 系统还需要任务规划、状态传递、流程控制、多角色协作和上下文管理。

尤其是在智能运维场景中，Agent 不能只是简单回答用户问题，而是要能完成类似下面这样的链路：



用户提出问题
  ↓
识别问题类型
  ↓
判断是否需要查知识库
  ↓
判断是否需要查监控
  ↓
判断是否需要查日志
  ↓
根据结果继续分析
  ↓
必要时重新规划
  ↓
输出排查结论


这就涉及到了：


    
 
  • ReAct
    • 
 
  • Tool Calling
    • 
 
  • Memory
    • 
 
  • RAG
    • 
 
  • Multi-Agent
    • 
 
  • Workflow
    • 
 
  • Plan-Execute-Replan
    • 



这些能力组合起来，才更接近一个真正可用的 Agent 系统。




十二、今天的总结


今天的学习重点可以总结成一句话：



 
从“一个 Agent 会调用工具”，进一步理解到“多个 Agent 如何分工协作完成复杂任务”。




今天主要理解了几个核心点：


    
 
  1. 多 Agent 不是工具多，而是多个 Agent 有明确职责并参与同一个任务；
    2. 
 
  2. Supervisor Agent 更像调度中心，负责管理和协调子 Agent；
    3. 
 
  3. Planner Agent 负责制定计划，Executor Agent 负责执行动作；
    4. 
 
  4. Plan-Execute-Replan 适合复杂任务，可以边执行边调整；
    5. 
 
  5. ReAct 更强调推理和行动交替进行；
    6. 
 
  6. outputKey 用于保存上一步结果，方便后续 Agent 或流程继续使用；
    7. 
 
  7. Flux 是后端响应式数据流，SSE 是服务端向前端推送数据的方式；
    8. 
 
  8. ChatMemory 解决的是多轮对话记忆和上下文延续问题。
    9. 

 
  

        # AIGC
      
        # 人工智能
      
        # 学习
      
  
 
 Logo 
AtomGit开源社区
 
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
 
 
  
更多推荐
  
cover
 
高效AI专著生成：实测优质工具，快速产出20万字专业专著
 
 
avatar AtomGit开源社区
 
cover
 
AI专著生成神器来袭！10分钟搞定20万字专著，专业高效新体验！
 
 
avatar AtomGit开源社区
 
cover
 
2026 官方适配：OpenClaw 接入 DeepSeek V4，百万上下文实战
 
 
avatar AtomGit开源社区