多智能体协作中的会话隐藏与任务路由设计

一、问题本质：不是模型不够强，而是人的注意力不够用

在多智能体协作场景中，一个非常容易被忽略、但又极其现实的瓶颈是：人的注意力是有限资源。

当开发者同时维护多个智能体会话时，常见状态是这样的：

• 一个会话在跑代码生成；
• 一个会话在查日志、分析报错；
• 一个会话在整理需求文档；
• 还有一个会话在等待用户确认方案。

如果每个会话都是一个独立窗口、独立上下文、独立状态，使用者的脑子里就必须同时维护四套进度、四套规则和四套“下一步该做什么”的记忆。这已经不是工具效率问题，而是认知负荷问题。

因此，真正值得讨论的技术命题不是“如何让单个智能体更强”，而是：

如何让一个用户能够同时管理多个并行执行的智能体，而不被会话状态淹没。

这个问题的核心诉求可以概括为一句话：会话应当是系统的实现细节，而不应成为用户的认知负担。

二、三层结构：触发器、路由器与工作会话

要把会话从用户面前“藏起来”，一个比较直观且工程上可行的做法，是引入分层架构。

1. 事件触发器

事件触发器位于系统最外层，负责接收外部输入。输入形式不限于文本，还可以包括：

• 定时任务触发；
• 代码提交事件；
• 监控告警回调；
• 消息队列消费；
• 人工指令。

触发器的作用不是执行任务，而是把现实世界中的变化转换成系统内部可以理解的事件。

例如，一条“构建失败”的通知进入系统后，触发器只需要完成两件事：识别事件类型，交给下一层处理。

2. 常驻路由器

路由器是系统中长期在线的中枢组件。它不负责具体执行复杂任务，而是承担以下职责：

• 接收来自触发器的事件；
• 判断事件意图；
• 选择合适的工作会话；
• 将会话执行结果汇总返回给用户。

这一层的关键设计原则是：路由器必须足够轻。

如果路由器本身承担了过多业务逻辑，它就会退化成另一个复杂会话，从而重新引入状态管理问题。

3. 工作会话

工作会话是真正干活的执行单元。每个工作会话通常面向特定任务域，例如：

• 代码生成与修改；
• 日志分析与故障排查；
• 文档处理与信息抽取；
• 测试用例生成；
• 数据查询与报表整理。

工作会话可以并行存在，各自维护独立上下文。用户不需要直接感知它们的存在，只需要向路由器表达目标，再由路由器完成分发与回收。

三、架构收益：从“多窗口切换”到“单入口派发”

这套结构的最大价值，是把用户的交互模型从“管理多个会话”转变为“面向单一入口派发任务”。

传统模式下，用户的心智模型可能是：

打开窗口A -> 查看进度 -> 切到窗口B -> 补充上下文 -> 切到窗口C -> 确认结果

而在分层路由模式下，用户的心智模型可以简化为：

向入口描述任务 -> 等待汇总结果 -> 必要时补充信息

会话之间的切换、上下文保存、状态同步，全部由系统内部完成。

用一个简化的伪代码表示：

def handle_user_request(event):
    intent = router.classify(event)
    session = session_pool.get_or_create(intent)
    result = session.execute(event)
    return result

用户看到的只是输入和输出，中间的过程被封装起来。对于轻量级、高并发的任务派发场景，这种模式能够明显降低操作成本。

四、关键难点：路由器凭什么判断该派给谁

上述架构看起来清晰，但真正困难的地方在于路由判断本身。

当任务足够复杂、目标不够明确时，路由器会面临几个现实问题：

1. 意图边界模糊

用户说“帮我看一下这个报错”，可能涉及代码问题、环境问题、配置问题或数据问题。如果没有足够上下文，路由器很难准确判断应该调用哪一个工作会话。

2. 跨会话依赖增多

很多真实任务不是单会话能完成的。例如“排查一个问题并修复代码”，需要先进入分析会话，再进入修复会话，再进入验证会话。路由层需要维护跨会话的任务编排状态，这比单纯分发复杂得多。

3. 上下文需要迁移

当任务从一个会话转移到另一个会话时，哪些上下文需要保留、哪些可以丢弃、哪些需要压缩，都是工程上的实际难题。处理不当会导致信息丢失或上下文膨胀。

因此，路由层的能力上限，往往决定了整个系统能否从“小秘书”走向“工程指挥”。

五、适用边界：轻任务与重工程要分开看

从实际使用经验来看，这套架构在轻量任务场景下表现良好，但在严肃工程场景下仍有明显差距。

适合的场景

• 信息汇总；
• 简单分析调研；
• 固定格式报告生成；
• 例行检查；
• 单轮或少量多轮任务。

这类任务目标清晰、边界明确、结果容易判断，路由层不需要承担过多推理压力。

不适合的场景

• 大型项目开发；
• 复杂故障定位；
• 长周期任务编排；
• 需要持续决策与人工确认的流程；
• 多团队协同工程。

在这些场景中，真正承担“超级智能体”角色的，往往仍然是人本身。用户需要在多个执行单元之间切换、记录状态、判断优先级、纠正方向。目前的自动化路由还难以替代这种综合判断能力。

六、工程实践建议

如果开发者希望在自己的系统中实现类似能力，可以考虑以下几点。

1. 先限定任务域

不要一上来就追求通用路由。优先选择边界清晰的任务类型，例如“日志分析”“代码审查”“周报生成”。在有限任务域内，路由准确率更容易保证。

2. 让路由器保持可观测

路由器做出的每一次分发决策，都应该有日志记录。用户需要能够看到：

• 为什么选择了这个会话；
• 任务当前处于哪个阶段；
• 是否需要人工介入。

可观测性是防止系统退化为“黑盒”的重要手段。

3. 支持人工接管

自动路由失败时，系统应允许用户手动指定执行单元，或者直接进入某个工作会话查看细节。自动化和人工操作之间需要平滑切换。

4. 渐进式引入编排能力

先在单会话内部完成闭环，再逐步增加跨会话编排。不要一开始就设计复杂的任务依赖图，否则维护成本会迅速上升。

七、总结

把会话从用户认知负担中移除，是多智能体协作走向工程化的一个重要方向。事件触发器、常驻路由器与工作会话的三层结构，为单入口管理多任务提供了一条可行路径。

但它并不是银弹。

在轻量派发场景下，这套设计能够显著降低操作成本；在复杂工程场景下，真正的瓶颈仍然在于意图理解、跨会话状态管理与人工决策介入。路由层的能力上限，决定了系统能走多远。

对于开发者而言，更务实的做法是：先在明确边界内验证路由效果，再根据真实使用反馈逐步扩展任务域。只有这样，才不会把“把会话藏起来”做成“把问题藏起来”。