求职派第二期重构成了一个类似 OpenClaw 的多 Agent 架构，8 个分层，每层职责独立。
| 层级 | 作用 |
|---|---|
| IM 渠道层 | 接入微信、飞书、钉钉 |
| 消息网关 | 统一消息格式、签名校验、用户 ID 映射 |
| 对话管理 | 意图识别、会话状态、消息路由 |
| 业务 Agent | 各个求职业务能力 |
| 工具调用 | MCP、搜索、文件读写、浏览器 |
| 模型路由 | 多模型切换、用户偏好 |
| 任务调度 | 定时任务、心跳、推送 |
| 消息推送 | Agent 结果回送 IM |
消息从 IM 进来，经过渠道适配、事件发布、意图识别、Agent 路由，最终由业务 Agent 处理后原路返回。
这篇内容就是帮大家拆解这套架构，消息怎么流转、意图怎么识别、Agent 怎么注册和路由、不同用户怎么用不同模型。
| 目标 | 落地方式 |
|---|---|
| 多渠道 | 渠道抽象层 + 微信/钉钉/飞书三个独立模块 |
| 多模型 | 模型供应商抽象 + OpenAI/智谱/阿里/Anthropic 四家 |
| 多 Agent | 统一 Agent 接口 + 身份采集/岗位抓取/岗位推荐等独立模块 |
| 多工具 | 可插拔工具：浏览器自动化、岗位检索等 |
| 多任务 | 任务调度 + 一次性/周期/延时任务 |
| 用户隔离 | 会话状态、任务、偏好按用户 ID 隔离 |
分层逻辑直接借鉴了 OpenClaw 的设计思路。
01、消息从 IM 到 Agent 的流转路径
消息从 IM 到达后，先经过渠道适配层。
这一层只做一件事：把微信、钉钉、飞书各自不同的消息格式统一成一个标准结构，包含消息内容、用户 ID、媒体文件等字段，然后通过事件总线发布出去。
下游所有模块看到的都是同一个结构，完全不需要关心消息来自哪个平台。
回复