从 OpenClaw 看多 Agent 系统的架构设计
一、架构概述
求职派借鉴 OpenClaw 的分层思想,将传统 AI 聊天应用改造成一个支持多渠道、多 Agent、多模型、多工具的业务系统。
核心思想是:通过统一接口和路由机制,让各模块独立扩展,避免业务逻辑集中在一个 Service 中。
二、整体架构
微信 / 飞书 / 钉钉
↓
渠道适配层
↓
统一消息网关
↓
MessageRouter
│
├── 身份校验
├── 系统命令
├── 会话管理
└── 意图识别
↓
AgentRouter
↓
AgentRegistry
│
┌────┼────┐
↓ ↓ ↓
简历 岗位 面试 Agent
│ │ │
└────┼────┘
↓
Agent Runtime
│
├── Memory
├── Tools / MCP
└── ModelProvider
↓
GPT / GLM / Claude
↓
ResponseEvent
↓
原渠道回送
另外,Scheduler 可以独立触发 Agent,实现定时任务和主动推送。
三、核心架构设计
1. 分层解耦
将消息接入、业务处理、模型调用、工具调用拆分成独立模块。
例如新增飞书渠道,只需要实现 ChannelAdapter,不需要修改业务 Agent。
设计价值:降低耦合,提高扩展性。
2. Agent 注册与路由
所有 Agent 实现统一接口,通过 Spring 自动扫描并注册到 AgentRegistry。
消息路由器根据用户意图选择对应 Agent:
JOB_SEARCH → JobSearchAgent
RESUME → ResumeAgent
INTERVIEW → InterviewAgent
新增业务时,只需注册新的 Agent,不需要修改核心路由代码。
设计价值:插件化扩展,符合开闭原则。
3. 分级意图识别
采用三级分类策略:
系统命令精确匹配
↓
关键词权重匹配
↓
LLM 兜底分类
简单请求直接通过规则处理,复杂请求才调用大模型。
设计价值:减少 Token 消耗,降低响应延迟。
但要处理否定表达和多意图,避免单纯关键词匹配造成误判。
4. 多模型适配
通过 ModelProvider 接口屏蔽不同模型厂商的差异。
业务 Agent
↓
ModelResolver
↓
ModelProvider
↓
OpenAI / 智谱 / Anthropic
Agent 不需要关心底层使用哪个模型。
设计价值:业务逻辑与模型供应商解耦,支持动态切换。
5. 会话管理与用户隔离
系统通过 SessionManager 维护用户与 Agent 的绑定关系。
例如:
userId → ResumeAgent
TTL = 6小时
连续对话可以复用当前 Agent,减少重复意图识别。
与此同时,Memory、用户画像、任务和模型偏好都需要按用户隔离。
设计价值:保证上下文连续性,避免用户数据串用。
四、架构中的技术取舍
| 设计
|
优势
|
注意事项
|
Spring Event
|
简化模块间通信
|
不等于可靠消息队列
| |
文件存储 Session
|
降低部署成本
|
多实例需共享存储
| |
关键词分类
|
成本低、速度快
|
存在误判风险
| |
会话绑定
|
减少重复路由
|
需要支持意图切换
| |
工具按需挂载
|
节省 Token
|
需要做好权限控制
|
目前这套系统更接近 模块化单体架构(Modular Monolith),不必为了多 Agent 而过早引入微服务。
当并发量、任务复杂度增加时,再逐步考虑分布式存储、可靠消息队列、任务重试和监控体系。
五、总结
这套架构最值得借鉴的是三个思想:
分层解耦 + 插件化扩展 + 统一路由。
它的本质不是让多个 AI 自主协作,而是构建一套 AI 业务编排框架:
-
渠道负责接收消息。
-
Router 负责选择 Agent。
-
Agent 负责业务处理。
-
Tool 负责执行外部操作。
-
ModelProvider 负责模型适配。
最终实现:新增一个渠道、Agent、工具或模型时,尽量不修改已有核心代码。
这也是这套架构最值得沉淀和复用的设计思想。