DeepSeek 的 Super-Agent 图：路由器很酷，评论区先问上下文怎么分

DeepSeek Harness 发了一篇文章，配图解释 Super-Agent 怎么跑。图里先对比传统做法：每个任务一个会话，聊天、GitHub、邮件之间来回切。Super-Agent 改成一个代理跨平台跑多个任务。

架构不复杂。一个常驻路由器接收来自聊天、GitHub、邮件的事件，按规则过滤，再分给对应的工人。图里举了 PR 评论的例子：有人评论 PR，路由器把评论发给负责这个 PR 的工人处理。聊天线程里提到问题或需求，Super-Agent 也能自动响应。上下文管理是重点：大部分上下文存在外部数据库，需要时才加载，避免提示信息越塞越长。

有网友把这张图翻成中文，信息更直观。

另一位网友贴了 TL;DR 图，基本把路由、工人、事件驱动三件事压缩到一张图里。

评论区没有停在“模型强不强”。有网友说，router 加 isolated workers 像一家好工作室的跑法。有网友盯上 per-worker context，认为一个巨大的共享上下文才是 agent 常见的崩点。还有网友问得更具体：多个工人共用一个用户聊天时，每个工人读全部历史消息，还是只读路由器转发的那部分。这个问题直接落到实现细节。

也有人关心主 agent 怎么检查子 agent 的工作再用结果。这个点比“能并行”更接近落地。并行不难画，难的是谁对结果负责，检查发生在哪一层，失败后怎么回收。还有网友判断，子 agent 越加越多，路由和共享上下文会先成为瓶颈，单个模型反而不是最卡的地方。

图传开后也有不同声音。有人问能不能把字体做正常点，有人直接回了一句，能不能别把好文章做成 AI slop。另一边，有网友把同一套架构剪成一分钟视频，省掉读长文的步骤。

原文在 DeepSeek Harness。Super-Agent 的看点可能落在编排和上下文拆分上。图里最值得抄的部分，是路由器把工作交出去，工人各自带着有限上下文干活，主 agent 还要负责验货。模型能力当然重要，但评论区的问题更诚实：多 worker 之后，路由、上下文隔离和检查流程会先暴露短板。