1.长期以来的痛点

我个人的开发经历：

我在使用 codex 等工具开发复杂任务时，通常是以这样的流程： 1.在 codex 中新建一个项目，开一个会话 A，在 A 中使用最强的模型（gpt-6-astra) 帮我分析规划任务，确定任务边界，明确需求，然后撰写一份大致开发文档 Doc。 2.新开一个会话 B，使用中等能力的模型（gpt-6.1-terra/sol) 按照开发文档 Doc 进行开发 3.初步完成之后，亲自检查，测试每个功能，不断反馈给模型更改调整。

痛点：

1.大模型和小模型处理到底哪个更擅长开发任务呢？Astra 虽然能力非常强，但是防御性编程很严重，而且询问次数 > 真正执行次数（可能是 gpt 模型的通病吧） 2.单个会话上下文太长了，每一次提一个小点都会思考很久，花费很多，我觉得这是一个很大的问题。新开一个会话 C，又需要（先浏览项目内容，弄清楚我的项目在做什么），每一次都需要人为来做一个铺垫 3.最大的问题，丢失特殊工具的使用方式，例如：在会话 B 中确定好了推送 Github 的方式，但是在新会话 C 中，频繁触发失败，除了 AGENTS.md 中的记忆，很多工具的使用方法仍需重新过一遍。

Super-agent 非常巧妙解决了这个问题！！！

2.Super-agent

2.1 解决的第一个矛盾：

所有任务给同一个 session —> 上下文连续，但是思考时间长，中间任务干扰，花费高 每个任务单独 session —> （会话 1，会话 2，会话 3…会话 1000）缺少连续性，会话多了，自己都找不到是哪个了🤡

DeepSeek 的解决方式：

由常驻的 Router 层统一承接人类交互与全局协调，由上下文隔离的 Worker 层并发执行具体任务。

简单来说：用户只与 Router 层（包工头）交互，用户甚至感觉不到 worker 层（工人）的存在。正如官方所说：Session 应当是系统的实现细节，而不应是用户的认知负担。 用户不必知道工人怎么怎么做，你只用专注于告知包工头该做什么就行了，工人怎么搭建不需要你去额外学习。

Router 的设计：

不同于先前的 AgentTeam 分配，Router 只负责接收任务，交付任务，本身不需要去实现具体的模块，所以化繁为简，使用一个较为轻量的模型就可以了，甚至可以不配备 Bash 工具。（有时候放手是为了更好）

Worker 的设计：

（官方已经讲解的很清楚了）Worker 不会直接与人类交互，其推理过程和工具调用不会直接输出到外部信道，而是向 Router 层汇报状态、由 Router 层统一向用户回复，从而在保障并发度与交付质量的同时避免多个会话各自回复带来的混乱。

2.2 解决的第二个矛盾：

传统模型 —> 人：你帮我 xxx 这个 pdf（接收到人类指令后才会执行） Subagent —> 自动监听群消息，邮件，日志等等，并自动过滤无关信息，分析明确的需求

DeepSeek 的解决方式：

程序策略与大模型相结合的两级过滤机制：

程序层策略（作为 Fast Path）

语义层策略（作为 Slow Path）

简单来说：有点类似 关键词 + 语义过滤 - 第一级过滤：划分范围和来源白名单，主动过滤无关信息 - 第二级过滤：通过提示词指导 LLM 判断语义

2.3 解决的第三个矛盾：

经典 ReActLoop  —>  接收指令 ->模型思考 ->模型规划 ->调用工具 ->思考回答 ->确认回复 用户从发送指令后一直等待，直到收到模型回复 Subagent —>  接收指令 ->模型思考 ->模型规划 ->调用工具（->思考回答 ->确认回复）->立即返回 用户发送指令后，模型开始调用工具时就返回通知，用户就不必等待

DeepSeek 的解决方式：

将同步的 ReAct Loop改为异步的 start() 和 stop()，构成**异步 ReAct Loop。**模型调用 start() 后立即收到“已启动（Started）”的返回，循环不再等待该工具；在后台工具执行完成后，系统再将最终结果作为一条新的事件消息投递进会话；同时，模型也可以根据上下文调用 stop() 主动终止执行时间过长的后台命令。

简单来说：有点像 CPU 的并行处理

2.4 解决的第四个矛盾

现有 Agent —> AgentLoop 的计算、会话状态以及代码仓库与本地工具链等执行环境绑定在同一台设备上，关机即停止。 Super-agent —> 将 AgentLoop 解耦为“云端无状态弹性容器”，将整体拆解为几个模块，更换设备也能接入 AgentLoop

DeepSeek 的解决方式：

第一步先将推进 Agent Loop 的计算与持久化的会话状态分离，使 Agent 摆脱单机生命周期限制、实现云端持久在线； 第二步再将云端的 Agent Loop 与重状态的执行环境解耦，让真实工作环境留在原地并支持跨设备访问。

简单来说：把一个 AgentLoop、持久化存储、重状态像积木一样，通过两步解耦拆开

结尾

很喜欢原贴在最后的一句话：回顾整套设计，我们并没有提出全新的理论，而是将计算机系统中经典的工程思想应用到了 Agent 系统的构建中。用承认“不新”的方式，把“新”落在了更扎实的地方。

期待 DeepSeek 的下一个大作！