Super-agent 设计探索：迈向更自主的 Agent 系统
DeepSeek 产品部 · 原文发布于微信公众号
01Super-agent
回顾过去两年基于 LLM 的应用形态的演变，chatbot 是其中的主流。它在封闭场景中解决问题，并在部分行业中实现了生产级别的落地。
当然，agent 的概念在早期产品中已初见雏形，例如内置在网络检索场景中的 tool use。随着模型能力的增强，以 Coding Agent 为代表的 agent 产品逐步成型：它们依托外部环境、执行多步任务、自行修正错误，已能稳定交付复杂产出，成为任务执行的可靠主体。此后，多 agent 系统开始受到关注，通过 agent 间的协作处理更复杂的任务。
我们相信，基于 agent 的软件形态会越来越多，并逐渐成为主流。在此背景下，我们尝试探讨 super-agent 这一概念，即未来软件系统的一种可能形态。
对于 super-agent 的最终形态，我们没有答案；目前我们正在一些小的场景中逐步迭代，打磨设计。
02常见问题
在讨论如何设计一个 super-agent 之前，先讨论我们在实践 super-agent 时遇到的常见问题。这些问题并非在所有场景中都会出现，但一旦出现，其代价往往远超收益。
注意力浪费
attention 是这个系统中最昂贵、最不可再生的资源。组成系统的每个部分只应在必要时占用 attention。
最常见的失败模式是：用户被无关的失败消息和修复消息不断打扰。这些消息本身对系统而言可能是必要信息，但对用户而言是噪音。用户从噪音中筛选出真正需要关注的信息需要成本；当失败与修复消息的量级超过用户承受能力时，用户将对系统的所有消息免疫——包括那些真正重要的。
从用户的角度看，整个系统应当是一个漏斗模型：尽可能多的信息经过尽可能多层的收敛，最终到达用户时已经是高度浓缩、必须由人来处理的信号。用户的注意力应当只被用在漏斗的末端。
如果系统不可避免地需要用户的注意力，我们称之为注意力义务。注意力义务应当被追踪、被记录，并作为系统设计的第一约束。
过度任务拆分
在围绕 agent 搭建的工作流中，一个非常大的 PR 往往难以被一次性处理。团队会倾向于将一个巨大的 PR 拆分成更小的任务，然后分配给多个 agent 并行推进；这本质上是团队先人肉拆解了一个巨大的任务。但拆分会产生一系列的连锁影响：
- 多个 agent 并行处理任务时，每一个都竭尽全力抢占一个 work item，它不断在自己的 session 中疯狂输出，刷新自己对问题的定义。
- 随着截止日期的逼近，agent 开始疯狂开启新的 session 处理新的 work item，并丢失早期 session 中的上下文。
- 修复 A 时破坏了 B；对修复 A 的修复又破坏了 C。
最终，在最关键的收尾阶段，团队却需要重新人工理解任务的前因后果。
模型对齐不等于操作者意图
模型的出厂对齐针对公司层面的整体意图（例如一个 OKR）；而对齐到操作者的具体动机在技术上仍具挑战：操作者的意图难以观测，与其有关的判断却往往依赖一些廉价的信号，例如一个任务的截止日期、一段工作记录、一次审批记录的时长。这类信号既廉价又不可靠，但它们往往会被系统放大。
work item 难以评估
一个任务的完成方式是组合爆炸的：如何拆分、如何排序优先级、如何决定 agent 数量与 work item 数量的比例、如何组织 context。这些决策不仅难以定义，其评估更是难上加难。
03设计原则
基于以上问题，我们总结出六条设计原则。它们相互支撑，共同指向一个目标：让系统在最小心智负担下交付最大价值。
系统的存在价值由其节省的注意力是否大于其消耗的注意力来衡量。一切设计都应围绕减少人的注意力义务展开。
系统的默认形态应当是无状态的。有状态意味着恢复成本、不一致风险与更高的注意力义务。
默认情况下，状态的权威存储应当只有一个，例如 git branch。任何镜像或缓存都应能从权威存储完整重建。
在新任务开始时，系统首先穷尽一切手段复用现有资源；session 与 workspace 都应被视为可复用的工具，而非一次性消耗品。
重构不改变行为，但留下踪迹。任何变更都应可追溯、可审计、可回滚。
先确立权限边界与审计机制，再逐步放开模型的权力。能力（capability）的增长不应先于约束。
04核心概念
在这些原则之下，系统由一组精简的核心概念构成。每个概念都有明确的职责边界，它们组合起来即可描述 super-agent 的完整运作。
| 概念 | 说明 |
|---|---|
| work item | 信息的基本单位，是系统与外部交互的核心；一个 work item 应当是一个符合 SMART 原则的、可交付的目标。 |
| attention | 一种约束，也是信号。谁的注意力、被什么占用、占用多久，都应被系统显式建模。 |
| source | 任务请求的来源，例如 GitHub、飞书。source 决定事件如何进入系统。 |
| backlog | 任务队列，是核心的共享数据结构；所有待处理的 work item 都在 backlog 中排队。 |
| goal | 描述任务的终态：完成时世界应该是什么样子，而不是逐步的操作指令。 |
| priority | 为 work item 设置预算（budget）与截止时间（deadline），约束系统愿意为其投入多少资源。 |
| plan | 描述「下一步做什么」的短期、可修正的计划，随执行不断被重写。 |
| capability | 权限契约：一个 agent 被允许做什么、以谁的身份、在哪些边界内。 |
| session | 任务的执行体，拥有独立的上下文与工作目录；仅操作者可重启。 |
| sharing | task 与 work item 可以与团队共享；共享使协作成为可能，也使注意力义务可分摊。 |
05基础设施
概念之下的底座是一组工程化的基础设施约定，用于消除 agent 工作流中最脆弱的环节。
| 设施 | 约定 |
|---|---|
| agent workspace | 每个 agent 拥有独立的、单仓库单目录的工作空间，彼此隔离、可随时回收重建。 |
| commit 幂等 | 对系统状态的修改应当幂等：重复执行同一操作不产生额外影响，这是自动化可靠性的前提。 |
| 有限信任的执行 | agent 在受控的权限与资源边界内执行；信任是按 capability 授予的，而非默认全给。 |
| 所有操作返回 JSON | 操作结果必须是机器可读的结构化输出，供上层 agent 消费与决策。 |
| 环境内检测 | 对环境状态的判断（如构建是否通过）应尽量在环境内部完成，而非依赖外部推断。 |
| 跨边界的数据流动 | 跨系统边界传递信息时，机器可读的工件（artifact）先行，人类可读的摘要随后。 |
| session 生命周期 | session 的创建、复用、回收有明确的生命周期管理，避免上下文无限膨胀。 |
06组合起来
principles、concepts 与 infra 的组合，构成了系统完成任务时心智负担最小的路径：
- 外部请求经 source 进入系统，成为一个 work item，进入 backlog；
- super-agent 依据 goal、priority 与 plan 决定处理顺序与方式，在 capability 允许的边界内派发给 session 执行；
- 执行过程中的所有变更落在单一事实来源上，且皆有踪迹；
- 只有当必须由人来决策或确认时，系统才经由漏斗末端占用人的 attention。
在这些设计之下，操作者的角色从「提示者」逐渐转变为「审计者」：不再逐步指示 agent 做什么，而是审视系统产出的计划与结果，并在边界处把关。
07总结
本文探讨了 super-agent 的设计。随着模型能力的增强，agent 会在越来越多的软件系统中承担更自主的角色，操作者也将从提示者转变为审计者。