✅求职派多Agent架构总览，借鉴OpenClaw

## 为什么借鉴 OpenClaw 多 Agent 架构？ 求职派借鉴 OpenClaw，核心是为了解决**复杂业务的解耦与扩展问题**。项目中消息要历经 IM 渠道、意图识别、模型路由、Agent 执行、工具调用等多层处理，传统单体架构很难应对这种复杂度。OpenClaw 的分层解耦思想正好匹配： > **分层即解耦**：8 个分层各司其职，IM 渠道层只管格式统一，消息网关管路由，业务 Agent 只聚焦求职逻辑，互不感知，依赖事件总线而非直接调用。 > **增量扩展**：加一个业务 Agent 只是 `agents/` 目录下多一个文件，加一个新模型厂商只需在 `providers/` 下新建模块，不需要改任何已有代码。 ## OpenClaw 架构的核心优点 1. **层间松耦合**：渠道层和 Agent 层通过双向事件总线通信，渠道不知道路由存在，路由不知道是哪个渠道在监听，两边只依赖事件总线这一个抽象 2. **组件可插拔**：模型供应商、工具、Agent 都是统一接口 + 自动注册，Spring 扫描即生效 3. **职责单一**：每层只做一件事，不会有一处改、处处崩的问题 ## 为什么不做成多 Tool 或 WorkFlow？ Tool 和 WorkFlow 适合**流程固定、步骤明确**的任务（如"先爬数据再存库"），但**不适合复杂对话场景**： | 对比维度 | Tool / WorkFlow | 求职派的多 Agent 架构 | |----------|----------------|----------------------| | **交互模式** | 链式调用，线性执行 | 事件驱动，异步解耦 | | **状态管理** | 无状态，每次独立 | 有会话绑定，6小时维系上下文 | | **扩展维度** | 只能加工具 | 渠道、模型、Agent、工具均可独立扩展 | | **容错兜底** | 流程断裂即失败 | 意图识别失败可走关键词/大模型兜底，Agent 失败走默认对话 | **简单说**：Tool/WorkFlow 是一条流水线，而求职派需要的是一个"对话生态"——多渠道接入、多模型切换、多 Agent 路由、实时意图识别、会话保持、主动推送。用 Tool 去实现这些，代码会迅速膨胀成难以维护的"大泥球"，而 OpenClaw 式的分层架构让每个维度都能独立演进而互不干扰。