DeepSeek Superagent 入门：跟着一次任务，看懂接单、派工和续做
你给 AI 留了一条需求：“修一下启动说明里的错误。”
它开始处理后，你又说：“刚才那段再补一个例子。”过了一会儿，同事提出另一件事：“导出功能也有问题，能看看吗？”
系统需要分清：哪句话是原任务的补充，哪句话应该另开任务，结果又该发回哪里。
DeepSeek Superagent 管的就是这类工作：收到需求，决定是否接单，让执行助手去做，再把后续消息和结果接起来。
本文介绍的是官方公开的 dsh-superagent-prototype，它运行在 DeepSeek Harness，也就是 dsh 上。官方将它定位为研究原型，公开代码与内部版本、设计文章中的设想有差别。官方仓库
先看一次已经跑通的本地任务，再解释会话复用。第一次阅读，只需记住两个角色：Router 负责接单和派工，Worker 负责具体执行。
一次本地演示：发出需求，收到文件
为了看清派工，我们先做了一个本地下发页面，上方填写需求，下方嵌入真实的 dsh Superagent 面板。
页面和接入适配是我们添加的教学扩展，原版没有这个现成入口。 它替代了“从 GitHub 收到需求”的环节。我们也调整了本地启动检查和交付要求，让这一单只处理文件。后面的 Router 模型判断和 Worker 工具执行，都在实际运行。
第一步：下发一件容易核对的小事
我们输入：
请在本工单的工作目录中创建 hello.txt，
写入“你好，我是 Worker，已收到任务。”。
读取文件确认内容，再用中文交付文件路径和内容。
不要访问外部网站，不调用子 Agent，不操作版本仓库。
任务选得很小，方便把注意力放在“谁收到、谁接单、谁执行”。
下发前，面板里的到达、评估和接单数量均为 0。
第二步：系统收到，暂时不执行
点击“下发给 Router”后，页面显示 stored。dsh 的“触发”页也出现了同一条需求，状态是：
已排队，等待评估
“触发”就是系统收到的一条消息记录，官方称为 Trigger。
我们事先暂停了自动处理，此时没有开始派工。这个停顿能看清：收到需求和决定执行，是两个步骤。
需求已进入系统，但 Router 尚未开始判断。
第三步：Router 接单，建立工单
恢复处理后，“评估”页出现接单记录，理由是：
名单里的人明确请求，由主 Session 接单
系统随后建立了一张工单，保存原始需求、执行范围、状态和对应会话。这次范围很具体：创建 hello.txt，写入指定内容后交付。
这轮演示的工单编号以 f751fe7e45 开头，后续执行和回复对应同一张工单。
第四步：Worker 真正动手
打开工单的“Session”，也就是执行会话，可以看到实际工具记录：
- 确认工作目录。
- 写入
hello.txt。 - 读取文件，核对内容。
- 向系统汇报完成。
在读取工具的详情里，可以直接看到返回的文件内容：
右侧“结果”中的第 1 行，就是 Worker 从文件读回的内容。上方也能看到这张工单的完成回复。
第五步：结果回到原入口
页面先后收到“已收到”和“已完成”的回复，并列出文件路径和内容：
你好，我是 Worker，已收到任务。
我们另外检查了文件：确实存在，内容一致，为 UTF-8 文本，43 字节。Worker 会话显示这轮执行用时 11 秒；这是极小任务的单次记录，不能代表其他任务的速度。
同一张工单的结果回到下发页面，可以对照文件路径和内容检查。
这次跑通的流程是：
本地页面下发需求
↓
系统保存消息
↓
Router 接单，建立工单
↓
启动这张工单的 Worker 会话
↓
Worker 创建文件、读回验证
↓
完成结果返回本地页面
本次没有经过 GitHub 或 GitLab，也没有创建 PR 或 MR。PR/MR 是提交代码改动、请人审阅的申请；这次交付物直接是本地文件。
Router 管工作归属，Worker 把工作做完
可以把它想成一个接单台加几位执行者。
接单台看新消息、记任务、找到对应负责人。执行者调查问题、操作工具、检查结果。执行者忙着做事时，接单台仍能处理其他请求。
| 角色 | 主要职责 | 在本次演示里做了什么 | | --- | --- | --- | | Router | 判断接新单、接到旧任务，还是无需处理 | 接下创建文件的请求，确定工单范围 | | Worker | 完成要求，报告结果或问题 | 创建文件、读回确认、汇报完成 | | 后台程序 | 保存记录、投递消息、管理执行名额 | 建立工单与会话，把结果发回页面 |
后台程序维护已经确认的任务关系和状态，不需要每次让模型重新猜一遍。角色与执行说明
两个独立请求被接单，可以形成两个 Worker。执行名额足够时并行，不足时排队。Worker 还可以在任务内部调用子 Agent 帮忙，这次演示没有使用这一层。并发与子 Agent
下次来任务，会复用这个会话吗？
会话按工单创建，并持久保存。同一工单可以继续使用原会话；新工单会建立自己的会话。
用文件任务举例：
| 后来的消息 | 应当怎样处理 | | --- | --- | | “刚才那个文件再加一行说明。” | 属于原工单范围时，可以让旧 Worker 继续 | | “另外做一个天气网页。” | 作为新的工作重新接单 | | “谢谢，收到了。” | 可以不再开始工作 | | “先停下这个任务。” | 根据人的停止请求结束工作 |
这些是解释规则的例子，本次模型实测只完成了创建文件这一单。
原型会保存讨论与工单的联系。原讨论来了后续消息，可以先送回对应 Worker，包括正常完成后仍能恢复的工单。Worker 判断是否属于当前工作；超出范围，就交回 Router 重新判断。人明确停止的工单有额外限制，后续消息不会自动恢复它。后续消息与授权
因此，同一讨论里说“另外做个网页”，可能先到旧 Worker，再被退回重新派工。在同一个聊天里，不代表所有需求都属于同一张工单。
代码里的做法也很直观：会话编号由工单编号生成，形如 worker-工单编号；启动时先找已有会话，找不到才创建。会话创建代码、工单与会话绑定
它与长期培养一组专家 Agent 的区别
一种常见期待是：先准备前端、后端、写作等 Agent，让它们长期积累经验；任务来了，再交给擅长这件事的那个。
当前 Superagent 原型主要围绕工单组织工作。 它重点判断“这条消息属于哪件工作”。旧会话不会仅仅因为做过相似任务，就自动成为该领域的接单专家。
Router 的主要动作有四种：接新单、附到旧工单、停止、忽略。附到旧工单需要明确关联，主题相似本身不够。两次都提到“文件”，并不代表应该交给同一张工单。Router 路由规则
Grok Bot 则把长期存在的 Bot 放在产品中心。每个 Bot 可以保留自己的规则、偏好和工作记忆，Bot 之间也能交接任务，更接近持续维护一组有职责的助手。Bot 的记忆、Bot 之间交接工作
| 观察角度 | 当前 Superagent 原型 | Grok Bot | | --- | --- | --- | | 主要围绕什么组织 | 工单及其执行会话 | 长期存在的 Bot | | 重点保留什么 | 工单上下文、文件和记录 | Bot 的规则、偏好和工作记忆 | | 后续工作如何接上 | 找到原工单继续，或新建工单 | 继续找已有 Bot，或由 Bot 交接 |
长期 Bot 能协作，也不意味着一定能自动找到“最合适的专家”。角色设置和分工指令仍会影响结果。