简介：大模型能力提升正推动Agent从“一次一任务”的单会话形态，走向跨会话保持上下文、并行推进多任务的连续实体。本文对比传统单会话Agent与Super-agent两类架构，从任务并发、上下文管理、触发方式、人机协作、安全与运维等维度拆解核心差异，并给出场景选择、选型建议与迁移注意事项，帮助技术团队判断是否以及如何向多任务并行的新形态演进。
过去一年，以编码场景为代表的单任务Agent已经充分验证了一件事：大模型能够调用工具解决复杂问题，并且越来越少地需要人类持续监控与逐步干预。与此同时，模型在多Agent协同上的能力也在提升，跨会话的组织与调度开始变得可行。在这一背景下，人的角色正从“底层执行的操作者”逐步上移为“高层决策与最终验收的把关者”。
能力提升也催生了新的应用形态。近期，个人助手类应用集中涌现：它们直接接入日常的消息、日程、邮件与工作平台，持续观察信息流并协助处理事务。这种“持续在线、事件驱动”的工作模式并不局限于个人场景，在软件开发等商业场景中同样具有价值。
然而问题也随之而来：现有主流Agent仍以单一会话为基本单位，会话之间彼此独立。当用户并行推进多项工作时，必须手动切换并记住各个Session的上下文。实践中，一个人通常只能同时跟进3到5个活跃Session。这形成了一条清晰的分界线：单任务的上限取决于模型能力，而多任务的上限取决于人的注意力。
近期，某头部大模型团队公布了其下一代Agent harness（运行框架）理念，提出了一种被称为Super-agent的Agent形态与系统架构，试图打破上述限制。本文即围绕这两类形态展开系统性对比，回答四个问题：两者有何相同点与本质差异？在单会话Agent上外挂连接器的“中间路线”为什么不够？哪些场景适合哪类形态？如果决定演进，迁移时需要注意什么？
单会话Agent是目前的主流形态。它的基本运行模型是：用户手动发起一次会话，Agent在该Session内接收指令、调用工具、产出结果；会话结束或挂起后，其上下文与其他Session相互隔离。典型代表是各类编码助手、命令行Agent与聊天式助手。这类Agent的价值在于把“一个明确任务”做得越来越好——单任务的上限随模型能力提升而不断提升。
其结构性限制在于：它被绑定在“单次手动会话”上。任务不发起，它不工作；会话之间，上下文不互通；并行多任务时，真正的调度者其实是人。
Super-agent是一种新的Agent形态及其配套系统架构：打破Agent与单次手动会话的绑定，使其成为一个能跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。
在该理念中，第一个被明确阐述的基础特征是“连续”：用户可以直接在即时通讯（IM）、代码托管平台的合并请求评审等熟悉的工作界面与它交互，感觉始终只存在一个Agent，不需要去思考“Session X的上下文中是否包含Y信息”。例如，用户先在IM中提出采用方案A，随后又在代码评审评论里改为方案B，Agent能够理解这是同一个人的意图更新，并自动调整执行方向。
从定义可以直接推演出Super-agent的能力要求：跨会话的统一上下文与任务状态、多任务并行且互不干扰、事件驱动的持续在线运行。需要强调的是，Super-agent并非某一个具体产品，而是一种形态与架构理念；个人助手只是其中一类应用，在团队协作的软件开发等商业场景中同样适用。
尽管形态差异显著，两者在技术根基与目标上高度一致，这也是二者可以放在同一演进曲线上讨论的前提：
换言之，差异不在于“能不能用工具解决一个任务”，而在于“能同时、连续、自主地处理多少个任务，以及以什么系统结构来支撑”。
单会话Agent以Session为原子单位，一次聚焦一个任务；用户并行推进多项工作时，实际上是人扮演了调度器角色，在不同Session间手动切换、搬运上下文。受注意力限制，一个人通常只能跟进3到5个活跃Session——这正是“多任务上限取决于人的注意力”的含义。
Super-agent把调度职责从人转移到系统：多个任务以互不干扰的方式并行推进，上下文由架构统一维护。此时多任务上限不再由人的注意力决定，而由系统的调度能力、资源与可靠性决定，理论上可随基础设施扩展。
单会话架构中，上下文的生命周期与Session绑定：会话结束，上下文即中断；跨会话信息需要人手动复制粘贴或在提示词中重述，这也解释了为什么用户需要“记住Session X里有没有Y信息”。
Super-agent要求跨会话保持上下文：同一个任务在IM群聊与代码评审之间连续推进时，两处的讨论、决策与代码变更都汇聚到同一份任务状态中。上下文的归属对象从“会话”变成了“任务/实体本身”。
单会话Agent是“人发起、同步执行”：执行过程往往同步阻塞直到任务完成或超时；若运行在本地设备上，设备离线或关机，Agent即停止运行。
Super-agent是“事件驱动、持续在线”：它持续观察信息流（如群聊中的反馈、评审中的评论），在无人显式召唤（如未被@）的情况下，也能主动定位问题根因并提交修复合并请求。这要求Agent的运行时不依附于某台本地设备，而以常驻服务的方式存在。
单会话形态下，人的参与方式是“逐步监督 + 手动切换”；Super-agent形态下，人的参与上移为“设定目标、做出决策、验收结果”，交互界面则回到用户熟悉的工作界面（IM、代码评审等），而非要求用户迁移到一个新的专用控制台。
两者对系统组件的要求差异很大，可用示意性伪代码对比：
# 单会话Agent：以Session为基本单位session = create_session()result = session.run(instruction) # 同步阻塞，任务结束即终止# 新任务 = 新Session；上下文不互通；设备离线即停止# Super-agent：以连续实体为基本单位agent = super_agent.bootstrap(identity, permissions, memory)loop on events: # 事件驱动，常驻运行agent.observe(im, code_review, ...) # 持续观察多个信息流agent.schedule(parallel_tasks) # 多任务并行，互不干扰agent.sync(unified_task_state) # 跨会话统一任务状态
单会话Agent的组件需求非常轻量：一个模型接口、一组工具、一个会话进程即可。Super-agent则至少需要：常驻运行时与调度器、跨会话的统一状态与记忆层、事件接入与消息路由、身份与权限管理、动作审计与回滚机制。这类组件与云上的消息队列、函数计算、容器平台、日志服务、监控告警等通用能力一一对应（百度智能云及主流云服务商均提供此类通用类目），也因此更适合以云端托管方式构建。
单会话Agent运行在个人设备与个人账号之下，权限边界相对简单。Super-agent以连续实体身份接入多个平台并主动行动，安全模型复杂得多：需要细粒度授权（能读哪些频道、能写哪些仓库）、最小权限原则、敏感动作的审批门禁、完整的动作审计链，以及出错后的回滚手段。“主动行动”是把双刃剑，权限设计必须先于能力设计。
单会话Agent近乎零运维，成本主要是一次会话的推理成本与个人时间。Super-agent引入了典型服务化系统的运维负担：可用性保障、故障恢复、容量规划、版本升级、监控告警与日志治理，同时多任务并行会显著放大推理与资源消耗。它用更高的固定成本，换取“人的注意力”这一最稀缺资源的释放。
面对多任务需求，一种自然的想法是：不改造架构，直接在现有本地单会话Agent上做扩展——接入命令行工具、通用工具连接协议或外部消息连接器。这条路可行，但存在结构性天花板：
换言之，中间路线解决的是“接入”问题，而Super-agent要解决的是“运行模型”问题：前者是给单会话装上更多管道，后者是更换引擎。这也是该理念强调需要“Agent形态及其系统架构”层面整体设计的原因。
| 对比维度 | 单会话Agent | Super-agent |
|---|---|---|
| 基本单位 | 单一Session，会话间隔离 | 跨会话连续实体 |
| 任务并发 | 串行，一次一项 | 多任务并行、互不干扰 |
| 上下文归属 | 会话内，人工搬运 | 任务/实体，架构统一维护 |
| 触发方式 | 用户手动发起 | 事件驱动、持续观察 |
| 运行载体 | 本地设备为主，离线即停 | 常驻运行时，云端托管 |
| 人的角色 | 逐步监督、手动切换 | 决策与验收 |
| 多任务上限 | 人的注意力（约3~5个活跃会话） | 系统调度与资源，可扩展 |
| 接入成本 | 低，开箱即用 | 较高，需平台化基础设施 |
| 运维复杂度 | 近乎零运维 | 服务化运维（监控、恢复、审计） |
| 安全模型 | 个人权限，边界简单 | 跨平台细粒度授权与审计 |
| 典型场景 | 一次性任务、轻量编码辅助 | 并行多任务、团队协作、事件驱动值守 |
适合继续使用单会话Agent的场景：
适合Super-agent形态的场景：
给出几条条件化的判断原则，而非绝对结论：
若计划从单会话形态向Super-agent形态演进，建议重点关注：
单会话Agent与Super-agent的差异，本质上是“以会话为中心”与“以连续实体为中心”两种运行模型的差异：前者把单任务做到了能力上限，但把多任务的调度成本留给了人；后者通过跨会话上下文、多任务并行与事件驱动的常驻运行，把人的角色上移到决策与验收，使多任务上限从“人的注意力”转移到“系统的架构能力”。与此同时，这一形态也带来了更高的接入、运维与安全设计成本。对技术团队而言，合理的路径不是非此即彼，而是根据任务并行度、上下文复杂度、运维能力与安全要求做条件化判断：以单会话Agent处理即时性任务，当多任务并行的痛点足够明显时，再依托成熟的基础设施稳步演进到Super-agent形态。