用户在微信上发了一句“帮我看看有没有合适的 Java 岗位”，求职派需要快速做出判断：这条消息应该交给岗位推荐 Agent，还是岗位检索 Agent，还是身份采集 Agent？
一个多 Agent 系统的核心难题不是“每个 Agent 能做什么”，而是“用户发了一条消息，系统怎么知道该派谁上场”。
这个判断做错了，后面的一切都是白费功夫。
上一篇我们拆解了 LangGraph4j 在工作流内部的条件边路由，那是数据驱动的确定性分支。但在对话场景下，用户说的是自然语言，路由的第一步是理解意图。
这篇文章会拆解求职派的消息路由全流程。
一条 IM 消息从到达系统到找到正确的 Agent，中间经过了哪些判断？为什么要分三层做意图分类？会话绑定又省掉了多少次不必要的分类调用？
01、消息从 IM 到 Agent
用户在微信上发了一条消息，消息先经过渠道适配层转成了统一格式，然后通过 Spring 事件总线发送到消息路由器。
消息路由器是整个系统的调度中枢，收到消息后会依次执行七个判断步骤。
第一步，身份检查。 如果用户的画像信息不完整（没有技能、教育背景等），系统会拦截消息，把用户转到身份采集 Agent，先把画像补齐了再说。
第二步，系统命令检查。 消息是不是以 / 开头？如果是 /help、/reset、/agents 这类系统命令，直接交给命令分发器处理，不走后续的意图分类流程。
第三步，显式 Agent 切换。 用户如果发的是 /job-recommend 这样的命令，直接路由到对应的 Agent，跳过意图分类。
第四步，会话绑定检查。 当前会话是否已经绑定了一个 Agent？如果绑定了，而且没有过期，就继续用这个 Agent 处理消息，不需要重新分类。
第五步，意图分类。 前面四步都没有命中的消息，才会进入意图分类器。分类器会判断用户想做什么，是推荐岗位、检索岗位、查询进度，还是别的什么。
第六步，Agent 匹配。 拿到意图分类结果后，从 Agent 注册表里找到支持这个意图的 Agent，按优先级选一个。
第七步，绑定并执行。 把选中的 Agent 绑定到当前会话，然后执行 Agent 的处理逻辑，把结果返回给用户。
七步里有四步是“短路”操作，命中了就直接返回，不走后续流程。
这个设计的核心目标是尽量少调用大模型。
// 身份不完整 → 拦截到身份采集
if (identityAgent.triggerToCollectIdentity(conversationInfo, msg)) {
return;
}
// 系统命令 → 直接执行
if (commandDispatcher.isSystemCommand(userMessage)) {
commandDispatcher.executeComma...
回复