多任务智能体编排：从会话驱动到常驻实体的架构演进

一、问题的重新定位：瓶颈从模型转移到了人

过去两年，技术团队讨论智能体时，焦点几乎都落在模型能力上：推理是否足够强、工具调用是否稳定、上下文窗口是否够长。但当模型能力跨过某个阈值之后，一个新的瓶颈浮现出来，而且它不在机房里，而在工位上。

一个被反复验证的经验数字是：一个人同时能有效跟进的活跃会话，通常只有 3 到 5 个。这不是意志力问题，而是注意力资源的硬约束。实际工作中很容易复现这个上限——用智能编程工具同时推进需求梳理、代码生成、测试修复、文档撰写，开到第五、第六个对话窗口时，就开始出现状态混淆：哪个窗口里提过需求变更、哪个窗口已经跑完验证、哪个窗口还在等待回复，全靠人脑记账。一旦记错，就要重新翻看历史消息，切换成本呈非线性上升。

于是问题被重新定义：单个任务的上限取决于模型能力，多任务的上限取决于人的注意力。 模型每天都在变强，但人还是那一个人，能同时盯住的窗口就这么几个。真正值得讨论的，不是如何让模型更聪明，而是模型已经够用的前提下，如何让它不再需要人一个窗口一个窗口地喂。

二、常见偷懒方案及其结构性缺陷

面对上述瓶颈，工程上最常见的应对是：给本地单会话的智能体接上命令行入口、工具协议或各类连接器，让它能接收外部消息。表面上看，智能体有了“耳朵”，可以被事件驱动了。但这种改造只是增加了输入通道，底层限制一个都没有解决。

可以归纳为四个结构性问题：

1. 仍然是同步会话模型。 智能体与一次交互强绑定，遇到长耗时操作（大规模构建、批量数据校验、长时间推理）就会阻塞，会话挂起期间无法推进其他工作。
2. 上下文相互污染。 多个任务的对话历史挤在同一条会话链路里，任务 A 的背景信息会干扰任务 B 的判断，切换任务等于切换注意力，也等于丢失状态。
3. 生命周期绑定在终端上。 电脑合盖、终端关闭、网络抖动，整个执行链路就停摆，任务无法在无人值守时段继续推进。
4. 人工维持成本高。 连接器要配置、会话要重启、状态要手动恢复，维持这样一套东西本身就要消耗大量人力，反而加重了注意力负担。

这四点共同指向一个结论：问题的根源不是输入通道不够，而是智能体被囚禁在“某一个手动驱动的会话”里。 只要智能体的存在形式仍然是会话，它就必然继承会话的全部限制。

三、出路：把智能体从会话中解耦为常驻实体

真正的出路是做一次存在形式的改变：把智能体从“某个手动驱动的会话”中解耦出来，变成一个持续存在的实体。它应当具备三项核心能力：

• 跨会话保留上下文：任务状态不随窗口关闭而消失，而是持久化在实体内部，任何入口接入都能接续推进；
• 同时推进多个复杂任务：任务之间彼此隔离，各自拥有独立的上下文空间与执行队列；
• 任务之间互不干扰：一个任务的失败、阻塞或重试，不影响其他任务的进度与状态。

业界把这类智能体及其背后的系统架构称为 Super-agent（超级智能体）。这个称呼的重点不在“超级”，而在“实体”——它不再是一次对话的附庸，而是一个有生命周期、有状态、有调度能力的常驻服务。

一个直观的对比可以说明差异：

会话驱动模型：
  用户 → [会话1: 任务A] → 结束即销毁
  用户 → [会话2: 任务B] → 结束即销毁
  状态随窗口生灭，任务无法跨入口接续
常驻实体模型：
  任务A ─┐
  任务B ─┼→ [常驻智能体实体] → 持久化状态存储
  任务C ─┘        ↑
             多入口接入（即时消息 / 代码托管平台 / 定时触发）

在这个模型下，同一个开发任务可以在即时消息里发起、在代码托管平台上继续推进；智能体可以在公开反馈渠道中持续监听，即使没有人点名，也能自行定位根因并提交修复变更。这不是“更聪明的模型”，而是“更合理的运行形态”。

四、四个基本特征：连续、高产、主动、常驻

Super-agent 的架构设计可以围绕四个基本特征展开，它们既是能力描述，也是验收标准。

4.1 连续性：状态不随入口切换而丢失

连续性要求智能体在任何时刻都能回答三个问题：目标是什么、已完成什么、下一步是什么。实现连续性的关键是把“会话历史”升级为“任务状态”。会话历史是线性的消息流，任务状态则是结构化的：目标、约束、已完成步骤、待办事项、关键产物引用。

工程上通常需要一套持久化状态层，把任务状态与执行日志分离存储。每次接入新入口时，智能体先加载状态、再复述摘要、最后继续执行。一个可行的状态摘要格式如下：

{
  "task_id": "task-2024-xxxx",
  "goal": "为目标模块补齐边界条件校验并补充单元测试",
  "constraints": ["不改变现有公开接口", "覆盖率不低于既定阈值"],
  "done": ["定位缺失校验的分支", "生成补丁草案"],
  "next": ["运行测试套件", "根据失败用例修订补丁"],
  "artifacts": ["patch://draft-001", "log://test-run-003"]
}

有了这份状态，人不需要靠记性去记每个窗口聊到哪了，智能体自己就能接续。

4.2 高产性：多任务并行而非多窗口轮转

高产性不是让智能体“更快地做一件事”，而是让它“同时做多件事”。这要求架构上支持任务级并行：每个任务有独立的上下文空间、独立的执行队列、独立的资源配额。调度层负责在任务之间分配算力与工具调用额度，避免某个长任务饿死其他任务。

这里的关键设计是上下文隔离。不同任务的提示词、中间产物、工具返回结果必须物理隔离，不能共用同一条消息链路。隔离带来的直接收益是判断准确性：任务 B 的输入不会再被任务 A 的历史误导。间接收益是可观测性：每个任务的执行轨迹独立可查，失败归因变得清晰。

4.3 主动性：从被动响应到事件驱动

主动性意味着智能体不再只对“用户发言”作出反应，而是对“事件”作出反应。事件来源可以是代码提交、议题变更、监控告警、定时触发、外部消息等。智能体订阅事件，自主判断是否需要介入，必要时自行定位根因并产出修复方案。

主动性的工程难点在于抑制误触发。事件驱动系统如果缺乏收敛机制，很容易演变成噪声放大器。常见做法是设置分级策略：低置信度事件只记录不动作，中置信度事件生成待确认建议，高置信度事件才允许自动执行变更，并保留可回滚的审计记录。

4.4 常驻性：脱离终端生命周期独立运行

常驻性要求智能体的运行不依赖某个用户的终端会话。它应当部署为长期运行的服务，具备故障恢复、任务重放、状态快照等能力。终端关闭、网络中断、客户端升级都不应导致任务丢失；服务重启后，未完成任务应能从最近的状态快照继续。

这一特征对基础设施提出了明确要求：持久化存储、可靠消息队列、执行日志与监控告警缺一不可。常驻性也是前三个特征的物理基础——没有常驻运行，连续性和主动性都无从谈起。

五、实践建议：先承认注意力的上限

架构演进不意味着个体工作方式可以不变。相反，在过渡阶段，最实用的建议是先承认自己只能盯 3 到 5 个窗口，并围绕这个约束建立纪律：

1. 控制并发窗口数量。 同时开启的对话不要超过注意力上限，超出的任务应交给常驻实体排队，而不是靠人轮转。
2. 每个窗口第一句话写清边界。 明确“这个窗口只做 X”，把任务范围前置声明，减少后续歧义。
3. 切换前先做三句话复述。 隔一段时间切回某个窗口时，先让智能体用三句话复述目标、已完成部分和下一步，再继续推进。这个小动作把记忆负担从人转移到了状态层。
4. 把长任务交给常驻实体。 构建、批量校验、长时间推理等阻塞型操作，不应占用人的交互窗口，而应提交给后台任务队列。

六、结语

Super-agent 的价值不在于模型又强了多少，而在于它重新划分了人与系统的分工：人负责定义目标与约束，系统负责维持状态、调度任务、监听事件。当智能体从会话的附庸变成常驻的实体，多任务的上限就从“人能盯几个窗口”变成了“系统能调度多少任务”。对于正在把智能体引入研发流程的团队而言，这可能是比模型选型更值得优先投入的架构决策。