agent-">一、背景：单任务Agent已经跑通，瓶颈正在转移

过去一年，以编程助手为代表的单任务智能体完成了一次关键验证：大模型不仅能生成内容，还能规划步骤、调用工具、读写代码、执行验证，并在失败后自我修正。更重要的是，人类在其中的角色持续后退——从逐步干预，退到关键节点确认，再到只做事后验收。

与此同时，模型在多智能体协同上的能力也在提升：任务可以拆分给不同角色，跨会话传递结果、汇总结论逐渐可行。这两条曲线叠加，催生了一类新的应用形态：个人助理类智能体。它们直接接入日常的即时消息、日程、邮件与协作平台，持续观察信息流并协助处理事务，呈现出“持续在线、事件驱动”的工作模式。

值得注意的是，这种模式并不专属于个人场景。在软件开发、运维响应、客户支持等商业场景中，一个始终在线、主动响应事件的智能体同样价值巨大。问题在于：现有主流Agent设计，还难以在多任务与团队协作的规模上支撑它。

二、为什么“单会话 + 外挂连接器”走不通

当前绝大多数Agent系统以单一Session为基本单位，Session之间彼此独立。这带来三个结构性问题：

1. 上下文被锁死在会话里。 用户并行推进多项工作时，必须手动切换Session并记住各自的上下文。实践中，一个人通常只能同时跟进3~5个活跃Session——单任务的上限取决于模型能力，多任务的上限却取决于人的注意力。
2. 同步阻塞的交互模型。 单会话Agent本质上仍是“你问我答”的同步流程：一个任务执行时，其他任务只能等待，人成了所有任务之间的串行调度器。
3. 本地依赖导致服务不连续。 以本地设备为宿主的Agent，设备离线即停止运行，无法承担“持续观察、随时响应”的职责。

一个常见的改良思路是：在现有单会话Agent上叠加命令行入口、外部连接器或标准化的工具接入协议，把消息、邮件等外部事件接进来。这能解决“接得上”的问题，却解决不了“跑得稳”的问题：会话依然是同步阻塞的，多任务的上下文依然容易互相污染，本地运行时依然不常驻，最终仍需大量人工维护。换言之，这只是给旧形态打补丁，而非形态本身的演进。

三、Super-agent：把Agent从“会话”升级为“实体”

要突破这些限制，需要打破Agent与单次手动会话之间的绑定，让它成为一个能跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。我们可以把这种Agent形态及其系统架构称为Super-agent（超级智能体）。

用两个典型场景描述它的行为边界（以下为技术示意）：

• 场景一： 同一个开发任务，先在即时消息群聊中讨论方案，随后转入代码托管平台的合并请求评审；评审中的新意见又回流到群聊同步。整个过程对用户而言始终是“同一个智能体在处理同一件事”，而不是两段互不相识的对话。
• 场景二： 智能体持续观察公共群聊中的反馈，在没有任何人@它的情况下，主动从反馈中识别缺陷、定位根因、提交修复并附上分析说明。

用户视角的体验可以概括为一句话：不需要再去想“Session X的上下文里有没有Y信息”。 例如，用户先在群聊里拍板采用方案A，随后又在合并请求评论里改主意换成方案B——Super-agent应能理解这是对同一任务的方向调整，并自动修正执行路径，而不是把它当成两条孤立对话。

四、四个基础特征

从工程视角，可以把Super-agent的形态归纳为四个基础特征：

1. 连续（Continuous）。 上下文挂载在“任务实体”上而不是“会话”上。用户可以在即时消息、代码评审、工单等任意熟悉的工作界面与它交互，入口可以换，任务状态不丢。连续性是其他一切特征的前提。
2. 并行（Parallel）。 多任务并发推进且互不干扰。这要求系统在任务之间做状态隔离与资源调度，单任务的失败或长耗时操作不得阻塞其他任务——正如操作系统用进程隔离取代了单道程序串行执行。
3. 常驻（Always-on）。 工作模式从“人发起、它响应”转变为“事件发生、它行动”。智能体订阅消息、评审、告警、日程等事件流，云端常驻运行时保证持续可用，事件驱动内核决定何时唤醒、何时静默。
4. 可组织（Organizable）。 单个Super-agent背后可以是一个被调度的工作组织：复杂任务被分解给不同角色的子智能体，结果汇聚、冲突仲裁后再向人汇报。人的角色由此从底层执行上移到高层决策与验收。

这四个特征共同指向一个判断：Agent的竞争维度，正在从“单次任务完成得多好”，转向“能否作为一个持续运行的组织成员存在”。

五、分层参考架构

要支撑上述特征，系统需要在传统“模型+工具循环”之外增加若干层。以下是一份可参考的分层设计：

• 接入层： 面向即时消息、代码托管、日历邮件、工单系统的通用连接器，负责协议适配、身份映射与消息规范化。
• 事件内核： 以消息队列与事件总线为核心，维护订阅规则、触发器、优先级与节流策略，把“世界的变化”翻译成智能体可处理的事件。
• 任务与上下文层： 核心抽象从Session变为Task。每个Task持有目标、状态机、相关方列表与分层记忆——工作记忆（当前推理窗口）、任务记忆（该任务的历史决策与产物）、组织记忆（跨任务共享的规范与知识），并结合向量检索与结构化状态存取。
• 执行层： 容器化的常驻运行时，支持断点续跑、幂等重试、工具调用的沙箱隔离与超时治理。
• 协同层： 调度器负责任务分解、子智能体编排、结果汇总与冲突仲裁。
• 治理层： 权限分级、操作审计、人工验收点与可观测性，构成主动行为的安全边界。

用一个示意性伪代码表达事件驱动内核的核心逻辑：

# 事件驱动内核（示意）
@subscribe("im.group_message", "pr.review_comment", "alert.fired")
async def on_event(event):
    task = task_router.match(event)          # 事件归属到已存在的任务，而非新建会话
    if task is None:
        task = task_manager.create(goal=event.summary())
    ctx = task.memory.restore()              # 跨会话恢复上下文
    plan = planner.replan(task, event, ctx)  # 例：评审中"方案A改方案B"触发计划修正
    scheduler.dispatch(plan, isolated=True)  # 并行推进，任务间互相隔离

值得强调的是，这类架构对底层基础设施的要求都可以映射到成熟的云原生通用类目：消息队列承载事件总线，容器平台承载常驻运行时，对象存储与向量检索承载分层记忆，日志服务与监控告警支撑可观测性。无论自建还是基于百度智能云等云平台的通用类目能力搭建，关键都不在单个组件，而在“以任务为中心”的状态设计与事件语义的规范程度。

六、落地之前的五个工程难题

1. 上下文一致性与意图裁决。 多入口输入必然带来指令冲突：群聊里说方案A、评审里改方案B，系统需要显式的意图裁决机制——例如采用“任务状态机 + 最新有效指令 + 关键决策需确认”的策略消歧，而不是简单拼接上下文。
2. 注意力的再分配。 人的角色上移到验收，意味着系统必须提供高质量的汇报与摘要能力：什么时候主动汇报、汇报到什么粒度、哪些决策必须等人拍板，需要产品层面的明确契约。
3. 可靠性工程。 常驻运行意味着故障面同步扩大：外部连接器抖动、事件重复投递、长任务中断都成为常态问题，幂等、重试、断点恢复与灰度发布是基本功课。
4. 主动行为的安全边界。 “无人@也主动提交修复”的能力与风险是一体两面：必须以权限分级、影响范围声明、审计日志和可回滚操作为前提，主动不等于越权。
5. 评测体系升级。 传统单任务完成率不再够用，需要引入并发压力下的任务干扰度、上下文保真度、事件响应时延、误触发率等系统级指标。

七、结语

回看Agent技术的发展路径：第一阶段证明了模型会用工具，第二阶段证明了人可以放手让它执行，而下一阶段的命题是——当人在底层执行中进一步退出，系统能否替人承担“记住所有会话、同时推进所有任务”的负担。Super-agent给出的答案是：把智能体从依附于会话的工具，升级为跨会话、常驻在线、可组织的连续实体。对开发者与企业而言，即便暂不整体重构，也应尽早在新系统中预留事件驱动、任务化建模与常驻运行时的架构余地——因为多任务协作的上限，最终将取决于系统架构，而不是人的注意力。