Super-agent解析：在主Agent之上加一层

一、从命名说起：super- 是方位，不是等级

谈论Super-agent，最容易踩的坑是望文生义——把它理解成“超级Agent”，即能力更强、无所不能的单体智能体。但这个命名里的“super-”，取的并不是“更优越”的含义，而是英语中一个表示“above、over（在其之上）”的方位前缀，与表示“under、below（在其之下）”的“sub-”恰好成对。这类成对前缀在技术词汇里随处可见：

• superscript（上标）对 subscript（下标）；
• superclass（父类）对 subclass（子类）；
• superset（超集）对 subset（子集）；
• superlinear（超线性）对 sublinear（次线性）。

按同样的构词逻辑，Super-agent指的是在“正在干活的主Agent”之上再加一层；而Sub-agent则是在主Agent之下再挂一层。两者方向相反：一个向上抽象，一个向下分解。理解了这个命名逻辑，后续关于分层架构的讨论才有共同的坐标系。

二、回顾Sub-agent：向下分解的编排模式

目前多数Agent系统的常见形态是“主Agent + 子Agent”：

• 主Agent作为用户入口，负责意图理解、任务拆解、结果汇总；
• 子Agent各司其职，承担检索、代码生成、数据分析等专项执行；
• 主Agent通过工具调用或消息传递把子任务派发给子Agent，并回收结果。

这种向下分解带来三个收益：

1. 上下文隔离：子Agent只携带与自身任务相关的上下文，避免主对话被中间过程撑爆；
2. 职责单一：每个子Agent的提示词与工具集可以按任务定制，行为更稳定；
3. 并行潜力：相互独立的子任务可以并发执行，缩短总耗时。

但它也有结构性局限：主Agent被迫承担太多角色——它既是规划者，又是执行者，还是记忆载体和质量裁判。当任务周期变长、步骤变多时，这一层会迅速过载：上下文膨胀、规划漂移、出错后缺乏系统的评估与恢复机制。

三、Super-agent：向上抽象的元控制层

Super-agent的思路，是把“元层面的工作”从主Agent中剥离出来，放到其上的一层。这一层不直接执行具体任务，而是负责：

1. 全局规划与任务受理：把用户的长期目标转化为阶段计划，必要时先澄清需求再开工；
2. 过程监督与评估：对主Agent产出的中间结果做验收，判断是否达标；
3. 重规划与异常恢复：评估不通过时调整计划，决定重试、回滚或更换路径；
4. 记忆与经验沉淀：跨会话维护目标状态、关键结论与教训，形成可复用的长期记忆；
5. 资源与预算控制：约束整体的时间、调用次数与成本预算。

这与面向对象中 superclass 与 subclass 的关系有微妙的相似：超类定义协议与约束，子类负责具体实现。映射到Agent分层里，就是上层定义“做什么、何时算完成”，下层实现“具体怎么做”。

四、三层职责划分与协作协议

把两层视图合并，可以得到一个更完整的分层模型：

• Super-agent（元控制层）：目标→计划→验收→重规划，维护长期记忆与全局状态；
• 主Agent（编排层）：接收阶段任务，拆解为子任务，调度子Agent并汇总结果；
• Sub-agent（执行层）：围绕单一专项任务循环调用工具，产出确定性较强的结果。

伪代码示意：

class SuperAgent:
    """元控制层：不直接干活，负责计划、验收与记忆"""
    def run(self, goal):
        plan = self.plan(goal)                       # 全局规划
        for phase in plan.phases:
            report = self.orchestrator.execute(phase)        # 委派主Agent
            verdict = self.evaluate(report, phase.acceptance) # 验收
            if not verdict.passed:
                plan = self.replan(plan, verdict.feedback)    # 重规划
        self.memory.consolidate(goal, plan)          # 经验沉淀
        return self.summarize(plan)
class OrchestratorAgent:
    """主Agent：任务拆解与子Agent调度"""
    def execute(self, phase):
        results = [self.dispatch(t) for t in self.decompose(phase)]
        return self.aggregate(results)
class SubAgent:
    """子Agent：专项执行"""
    def dispatch(self, task):
        return self.tool_loop(task)

层与层之间建议采用显式契约通信：上层传给下层的应是结构化的任务说明（目标、约束、验收标准），下层回传的应是结构化结果（结论、依据、未决问题），而不是整段原始对话。这既压缩了上下文，也让每一层的职责边界变得可测试。

五、什么场景值得加这一层

分层不是免费的：每多一层，就多一次模型调用、多一份提示词维护成本、多一处理化损失。是否引入Super-agent，可以参考以下判断。

适合引入的信号：

• 任务周期长、跨多次会话，需要稳定的全局目标与长期记忆；
• 产出质量需要系统性验收，而不是靠主Agent“自说自话”；
• 任务路径不确定性高，中途重规划是常态而非例外；
• 多个主Agent实例需要共享经验或被统一调度。

不必引入的情况：

• 单轮问答、步骤明确的短流程，主Agent加子Agent已足够；
• 简单场景硬加元控制层，只会放大延迟与成本，还可能引入新的失控点。

六、落地时的四个实践要点

1. 验收标准要可判读：尽量把“做得好不好”转化为可核对的清单或可执行的检查，减少上层评估的主观漂移；
2. 压缩要有取舍：向上传递的信息必然有损，需明确哪些是必须保留的关键状态（目标、约束、已验证结论），哪些可以丢弃（中间细节）；
3. 控制层数：Super、主、Sub三层已能覆盖绝大多数场景，盲目堆层会让调试与可观测性迅速恶化；
4. 全链路留痕：每一层的输入输出、评估结论、重规划理由都应记录，便于回放定位问题。工程上可以依托云平台的日志服务、监控告警与模型服务等通用能力搭建这套观测体系。

七、常见误区

• 误区一：把Super-agent理解成“能力更强的Agent”。它描述的是位置关系（在其之上），不是能力等级；
• 误区二：认为分层越多越智能。每层都是成本与误差来源，分层的价值来自职责是否真正解耦；
• 误区三：上下层职责重叠。如果Super-agent既做规划又插手具体执行，分层就退化成了更贵的单层系统。

结语

Super-agent构想的真正价值，不在“造一个更聪明的Agent”，而在于把Agent系统的控制平面与执行平面分开：向下分解解决“怎么把活干细”，向上抽象解决“怎么把方向把稳”。理解super-与sub-这对前缀背后的方位含义，就抓住了这场讨论的关键——在主Agent之上加一层元控制，让它看得更全、想得更远；在主Agent之下加一层执行，让它做得更快、更专。两者结合，才构成应对长周期复杂任务的完整解法。