作者｜冬梅
当 AI 已经能够独立写代码、修复 Bug，甚至连续工作几个小时，人类为什么反而越来越忙了？
这可能是今年 AI Agent 领域一个颇为矛盾的现象。
过去，程序员需要亲手编写代码。如今，开发者可以同时启动多个 Coding Agent，让它们分别完成需求开发、代码审查、测试和文档编写。模型的执行能力越来越强，人类却不得不在不同窗口之间来回切换：检查任务进度、处理报错、回答问题、决定下一步做什么。
原本是为了减轻工作负担的 AI，某种程度上又制造出了一份新工作——管理 AI。当一个人可以指挥十几个 Agent，真正限制生产力的，可能已经不是模型能写多少代码，而是人类还有多少精力盯着它们。
10 月 31 日，DeepSeek Harness 团队围绕这一问题公开了一项名为 Super-agent 的设计探索，并同步开放了研究原型代码。
与外界熟悉的大模型发布不同，这次 DeepSeek 没有推出参数量更大的模型，也没有展示新的推理基准成绩，而是试图重新设计 Agent 与人类协作的方式。
其核心思路可以概括为：让 Agent 从一个等待指令的执行工具，变成能够感知工作环境、接收任务、持续执行并在必要时主动寻求人类协助的协作者。
此次公开的原型项目名为 dsh-superagent-prototype，代码发布在 DeepSeek AI 官方 GitHub 组织下，采用 MIT 许可证。它基于此前开源的 DeepSeek Harness 构建，主要面向软件开发场景，可以连接 GitHub 和飞书，在授权范围内接收请求、创建任务，并由独立的执行 Agent 完成工作。
项目地址：https://github.com/deepseek-ai/dsh-superagent-prototype
这次发布之所以值得关注，不仅因为 DeepSeek 开始探索更自主的 Agent 系统，还因为它触及了一个比模型能力更难解决的问题：当 AI 可以承担越来越多的工作，应该怎样设计一套系统，让人类真正从管理这些工作的过程中解放出来？
1
AI 越能干，人为什么反而越忙？
要理解 Super-agent，首先需要看清当前 Agent 系统的一个局限：大多数 Agent 仍然以单次任务为中心。
用户发出指令，模型理解任务，调用工具，执行若干步骤，最后返回结果。这套模式适合处理边界相对清晰的工作，例如修复一个 Bug、开发一项功能，或者检索一份资料。
但实际的软件研发并不是一个接一个独立任务的简单叠加。
一个问题可能从 GitHub Issue 开始，随后进入代码修改、Pull Request 审查、CI 测试和持续讨论。开发者可能今天提出需求，明天补充约束，几天后又在同一个 PR 中提出新的修改意见。
传统 Agent 面临的困难在于，它往往依赖用户主动发起下一轮任务。
如果测试失败，是否需要人类重新提示？如果有人在 PR 中补充了反馈，Agent 能否知道这属于之前的工作？如果同时存在十几项任务，又由谁来决定哪些需要继续执行、哪些需要暂停？
这些问题已经超出了单纯提高模型推理能力的范畴。
DeepSeek Harness 团队提出的设计原则就比较有意思了：尽可能少地占用人类注意力，同时提供尽可能多的价值。
根据其公开的设计文档，系统中的一条消息、一次通知、一个问题，甚至管理界面上的一个元素，都需要考虑是否值得占用人的注意力。
由此，Super-agent 并不鼓励 Agent 更频繁地汇报工作。恰恰相反，它要求 Agent 只在结果已经可以使用、确实需要人类决策，或者任务无法继续时才打扰用户。
对于一个软件研发团队来说，理想状态不是每天收到几十条“正在分析代码”“已经完成初步测试”的消息，而是打开工作界面时，只看到真正需要自己处理的事情。
这也是 Super-agent 与普通聊天式 Agent 的一个关键区别：它不再把每次对话当作工作的中心，而是把持续存在的任务作为系统的组织单位。
2
Super-agent 核心技术是什么？
从公开原型来看，Super-agent 并不是通过训练一个拥有特殊能力的新模型来实现的。
它采用的是分层 Agent 架构：由一个主 Session 负责接收事件、判断任务是否应该启动以及分配工作，再由独立的 Executor Session 负责具体执行。
这一设计与传统的单 Agent 循环有明显不同。
整个系统中，最值得注意的是以下几个设计。
首先，Agent 开始具备持续感知外部事件的能力。传统 Coding Agent 通常需要用户进入聊天窗口发出指令，而 Super-agent 将 GitHub、飞书等工作入口抽象为 Source。Source 不仅可以接收消息，还负责维护事件读取位置、识别事件来自哪里，并把相关消息归入对应的工作线程。
例如，开发者在 GitHub Issue 中提出需求，随后又在评论中补充条件，系统不必将每条消息都视作一个全新的任务，而是可以根据 Thread 和已有 Ticket 之间的关联，判断后续事件是否属于正在进行的工作。
其次，系统把“是否应该执行任务”与“如何执行任务”分开，这一步非常关键。
在 Super-agent 中，外部消息首先进入评估流程 Eval。系统根据发送者身份、规则和已有任务状态，判断是否应该接受这项工作。一旦接受，系统会创建 Ticket，同时生成相应的 Mandate，即任务的授权依据和执行边界。随后，Assignment 将 Ticket 分配给 Executor，由后者在独立的会话和工作目录中执行。
这种设计意味着，Agent 可以在不同任务之间保持相对独立的上下文，同时由主 Session 统一管理任务的接收与流转。
第三，任务的生命周期不再依赖一次 Agent 对话。这是该设计中容易被忽略、却具有实际价值的部分。
传统系统中，一次 Agent Session 结束，往往意味着当前任务也随之结束。但在真实开发中，PR 提交后还可能收到审查意见，测试失败后还需要重新修改代码。Super-agent 将 Ticket 与 Executor Session 分离。一个 Ticket 可以先结束当前执行阶段，在收到新的有效反馈后重新恢复，而不必把整个任务重新创建一遍。同时，Ticket 与 Thread 之间可以建立订阅关系。后续的相关事件会继续被送到对应任务，使 Agent 能够在原有工作基础上继续处理。
这些设计共同指向一个目标：让 Agent 管理的是一项持续变化的工作，而不是一次孤立的聊天。
3
让 AI 少说话，让人少操心
Super-agent 的设计中，还有一个有点反常识的地方：它不追求让 Agent 随时汇报工作，而是希望系统能够自行区分什么值得打扰人类。
在公开原型中，每个 Ticket 都有明确的工作状态，包括等待执行、正在工作、等待外部事件、等待人工回答、等待审查、受阻或失败等。
这些状态决定了任务何时继续、何时暂时停止，以及哪些情况需要人类介入。比如，一个 Agent 已经完成代码修改并提交 PR，接下来需要人工审查。此时，系统可以释放该任务占用的执行资源，同时保留任务状态。等到审查意见出现，相关事件又可以唤醒原来的任务。
如果模型遇到无法自行决定的问题，则可以将任务标记为等待人工回答，而不是不断尝试猜测用户意图。
这种设计还延伸到了具体的运行机制。
根据执行文档，原型会为不同 Ticket 创建独立工作目录和 Session。在任务包含后台 Shell 进程或子 Agent 时，系统不会因为当前对话轮次结束就立刻宣布工作完成，而是继续等待执行结果。
后台任务也并非无限运行。文档规定，常规后台工作在每个轮次结束后最多继续 30 分钟，达到限制后会终止相应 Shell 任务并记录状态；子 Agent 则有单独的生命周期处理规则。
在并发调度上，系统还为人工消息或状态查询预留了额外的执行槽位，以避免普通任务占满资源后，人类无法及时干预正在进行的工作。
这些机制看起来琐碎，却触及了 Agent 落地过程中的现实困难：模型能否完成任务只是第一步，如何管理资源、保存状态、恢复中断，以及在恰当的时候把控制权交还人类，同样影响最终体验。
4
更自主的 Agent，谁来决定它能做什么？
当然，Agent 越主动，也意味着越需要明确的权限边界。假设一个 Agent 接入了公司的 GitHub 和飞书。如果任何一条聊天消息、任何一份外部文档都能指挥它修改代码，那么所谓的自动化很容易演变成安全风险。
DeepSeek 团队在 Super-agent 原型中专门设计了一套授权机制。
其中，Mandate 是关键概念。它不仅记录某项任务为什么被允许执行，还包含授权范围、规则版本及授权依据等信息。
换言之，模型可以负责判断某个任务应该如何处理，却不能仅凭自己的判断扩大权限。
公开文档明确要求，聊天内容、评论以及引用的文档只能作为判断输入，不能直接修改系统既有的访问权限和授权范围。
对于未经明确请求、但可能值得主动处理的工作，原型设置了三种接纳模式：
off：不接纳推断出的主动任务。
observe：评估是否值得执行，但只记录判断，不真正启动。
auto：满足已配置规则后，可以自动接受并执行。
默认采用 observe 模式。团队建议先观察 Agent 的判断是否合理，再逐步扩大自动执行范围。
这一设计实际上是在自主性与可控性之间寻找平衡。系统并非接收到任何事件就自动执行，而是让主动行为建立在事先授权的规则之上。
不过，原型仍然存在需要重视的安全边界。
其执行文档披露，Executor Session 可以以部署者的操作系统用户身份运行命令，而工作目录和命令限制并不等于完整的安全隔离。因此，在具备敏感凭据或生产环境权限的机器上直接运行，仍有风险。
这也说明，Super-agent 目前更适合作为架构研究和受控环境实验，而不能直接等同于经过生产验证的企业级自主 Agent。
