深入解析 Super-Agent 的请求分级与安全执行机制：智能体自主性如何走向可控？

一、问题不在“主动”，而在“判断”

去年团队里接过一个编程智能体，需求看起来并不复杂：监听代码仓库中的 issue 与评论，当有人描述 Bug 时，智能体尝试复现问题并提交修复 PR。从工程实现角度看，让智能体“动起来”并不难——一个事件回调、一段提示词、再调用代码生成能力，半天时间就能搭出原型。

但真正的麻烦发生在第二周。持续集成机器人在 PR 下自动贴出失败日志，智能体把这段日志当成了新的修改依据，重新生成一版代码；CI 再次失败，再贴日志，智能体继续修改。一个下午，它给同一个 PR 连续推了十几个提交。

更危险的情况出现在后面。一位同事在 issue 中贴出了从外部论坛复制的排查步骤，其中恰好包含“请删除缓存目录后重试”这样的描述性文字。智能体没有识别出这只是一段转述内容，而将其视作明确指令，直接执行了删除操作。

回顾这两次事故，核心问题并不是智能体缺少主动能力，而是缺少对输入来源和语义意图的分级判断。谁发来的消息？这个来源有没有资格触发动作？消息中的文字是给谁看的？是建议、讨论，还是明确指令？在早期方案中，这些判断几乎全部依赖提示词中的自然语言约束。然而提示词本身也只是模型上下文中的一部分，任何进入上下文的文字，都可能与系统约束争夺解释权。

因此，当看到 DSH 团队发布的 Super-Agent 方案时，最直观的感受是：他们遇到的是同一类问题，但拆解得更加系统。

二、把“请求”拆成两类：显式与推断

Super-Agent 在概念层面对智能体接收到的“请求”做了第一层切分：显式请求与推断请求。

显式请求，是指白名单内的人类成员直接点名智能体提出的要求。例如在协作群中明确 @ 智能体，并给出任务描述：“请检查最近一次提交对登录流程的影响”。这类请求具有明确的来源、明确的目标对象和可追踪的责任主体，是智能体最应该执行的任务类型。

推断请求，则完全不同。它是指智能体自己从环境中“发现”的线索或信号。例如群聊中有人讨论某个性能问题，但没有任何人要求智能体介入；又或者 CI 日志中出现异常，但异常本身并不构成对智能体的直接调用。推断请求的本质是智能体的主动观察，而不是外部对它的明确调用。

两类请求一旦混淆，智能体就会把一切环境噪声都当作任务信号。原始案例中 CI 机器人的日志被当作新需求，本质就是推断请求被错误提升为显式请求。这一区分的价值在于：它不依赖模型自身“理解到不该做”，而是在系统结构上就将任务来源分离开来。

三、推断请求的成交条件：规则命中 + 模式允许

光是区分还不足以控制风险。Super-Agent 进一步规定：推断请求要真正成为可执行任务，必须同时满足两个条件。

第一，命中团队事先定义好的规则库。规则库由团队自行维护，用来描述哪些环境信号值得被评估。例如可以定义：“当某条 PR 的 CI 连续失败次数超过阈值，且失败原因指向同一路径时，生成一个诊断候选任务”。规则的作用是预筛选，不等模型临时判断，而是让稳定、可审计的条件先行过滤。

第二，当前接收模式必须允许执行。Super-Agent 将接收模式分为三档：

模式	处理方式
off	推断请求一律不进入候选任务队列
observe	评估候选任务并记录“如果开启 auto 会如何处理”，但不执行
auto	评估通过的候选任务直接进入执行流程

默认模式是 observe。官方建议团队先在 observe 模式下运行一段时间，查看智能体每天“打算做什么”，逐条核对判断结果是否合理，再决定是否切换到 auto。

这套设计在工程上非常关键。一个具备主动性的智能体，在获得动作权限之前，先输出了完整的决策日志。团队不是通过“更聪明的模型”来保证安全，而是通过“先观察、再授权”的灰度机制来建立信任。如果早期案例中的智能体先以 observe 模式运行一周，CI 循环问题在第一天就能通过日志暴露出来，而不是等到十几个提交之后才被人工发现。

四、机器人消息的权限边界：只能作为线索

更值得关注的是，Super-Agent 对“机器人发出的消息”做了明确职权限制。

在系统定义中，机器人消息最多只能产生“推断候选”，永远无法构成显式请求。也就是说，CI 机器人贴出的失败日志、监控系统发出的告警、自动化工具返回的执行结果，都只能作为智能体的观察线索，不能让智能体“奉命行动”。

同时，机器人也不能具有叫停任务的能力。任务一旦进入执行流程，只有具备相应权限的人类成员或高优先级策略可以中止，机器人消息无法构成干预指令。

这条规则直接命中了原始故障的根源。CI 机器人贴日志并不是问题，智能体把日志当成命令才是问题。正确的处理方式是：日志可以被规则引擎分析，可以成为生成诊断任务的候选信号，但不能直接驱动修改动作。线索与命令之间的边界一旦明确，机器人循环反馈导致的自激行为就被结构性阻断。

五、权限在模型之外，由宿主程序执行

甚至更底层的限制，Super-Agent 也没有依赖模型自觉，而是把权限判断放在了模型之外的宿主程序层。

这意味着，智能体提出的任何动作计划——无论是修改代码、执行命令、删除目录，还是调用外部接口——都需要经过宿主程序独立校验。宿主程序依据事先配置的权限表、资源边界和变更策略进行裁决，而不是仅凭模型说“我应该可以这样做”。

举例来说，智能体可以提议“删除缓存目录”，但宿主程序会检查该路径是否在可删除白名单内、当前会话是否具有删除权限、变更是否处于受控窗口期。只要任一条件不满足，动作就被拦截，而不是进入执行队列。

这种“模型负责意图，宿主负责授权”的架构，解决了一个长期被低估的问题：大模型天然容易受到注入文本的干扰。不管提示词写得多么严密，只要恶意性或误导性内容进入上下文，模型就有可能产生越权意图。执行层的独立校验，相当于为智能体加了一道不经过模型语义理解的保险。

候选任务生成（模型层）
        ↓
意图解析与环境信号分析
        ↓
宿主程序权限校验（规则层）
        ↓
授权通过 / 拒绝 / 转人工

六、对智能体工程的启示

Super-Agent 的方案并不神秘，但它提出了一套可以被工程团队普遍借鉴的设计原则。

其一是请求分级。不是所有进入上下文的信息都具备同等的触发资格。显式指令和隐性线索被分开处理，来源身份和职权范围被纳入决策依据，这是智能体走向生产级落地的必要前提。

其二是观察先行。在智能体获得执行权限前，先让它在受限模式下运行并输出意图日志。这个灰度过程让团队有时间评估模型的行为模式，也把“算法信任”转化为“证据驱动的信任”。

其三是执行隔离。模型永远只生成意图，关键动作的外部授权和资源访问控制由宿主程序完成。这样即便上下文被注入、提示词被绕过，执行层的安全边界仍然存在。

过去，很多团队对智能体项目的惯性思维是：先做出来，再通过更精细的提示词修正行为。但除了让提示词更严格之外，更合理的方式是让系统结构本身变得可观测、可分级、可阻断。Super-Agent 给出的答案是：不要急着给智能体放权，先给它一本分好类的任务字典、一套可回放的决策日志，以及一个在模型之外站岗的执行守门人。