DeepSeek 的常驻 Agent 架构解读与思考
IM 改需求、GitHub 跟进,
仍能关联同一任务
几件事同时执行,
长任务进行时仍能接新请求
监听外部事件,
在授权内判断是否介入
持续运行、保存任务状态,
发生故障后尝试恢复
先按规则准入,再依据订阅关系,走模型判断或代码直送。
Worker 回报关键状态与结论,由 Router 协调并统一对外回复。
话题 = 同一个 PR、同一串群聊回复、同一封邮件往来
系统按规则准备输入;模型发现信息不足,再通过工具读取。
ID、摘要、关联对象
邻近消息与关键背景
完整内容在外部,留读取引用
先定位相关话题,再沿已建立的 ID 关系召回历史
引用关系让历史可追溯,但不会自动建立所有跨渠道关联。
“上次那个问题”有歧义时,仍需检索、确认或补充信息。
个人场景也一样:收到会议邀请 → 先查冲突、找背景、起草回复,你只要看一眼再发
场景:修复要用到 Mac 上未提交的代码,但这台 Mac 已经离线。
云端 · 计算
继续接收消息、协调任务
持久化存储 · 状态
保存会话与任务状态
依赖本地代码的操作,等设备恢复连接。
BYOM:接入自己的机器,通过本地 daemon 执行具备所需代码与工具的其他任务,可以继续。
不会自动接替 Mac 上尚未同步的工作环境Mac 离线时,本地操作暂停,云端仍可接消息、保存状态。
同一套两层架构,只比较后续消息是否按订阅关系直接送给 Worker。
| 指标 | 开启直送 | 关闭直送 |
|---|---|---|
| 每次运行的缓存读取量 | 23.2M token | 31.8M token 约 +37% |
| 完成时间 · 中位数 p50 | 12.4 分钟 | 12.6 分钟 |
| 完成时间 · p95 | 15.7 分钟 | 15.5 分钟 |
为何时间接近?Router 批处理可吸收额外事件;这组负载尚未压满吞吐。
这组负载里,直送减少了额外读取和路由开销,未明显缩短完成时间。
三个 Worker 各自完成任务,却对同一个模块采用了不同方案。
Worker 处理局部冲突,并报告影响。
Router 识别问题,交给专门的协调 Worker 分析依赖与方案。
把证据和选项交给有权决定的人。
前台需要多强,取决于系统留给它多少判断工作。
同样的修改,两种执行路径(示意)
固定交接开销可能超过执行时间
更依赖 Worker 的规划与进度反馈
| 对照维度 | DeepSeek Super-agent设计文 · 部分能力见原型 | Hive公开仓库说明 · 本地工作台 | Grok bot既有实践 · 未做对照实验 |
|---|---|---|---|
| 组织方式 | Router 派发完整任务 | Orchestrator 规划与派单 | 入口分工,执行者交接 |
| 协作载体 | Thread / Session 与订阅 | CLI 进程、任务图与报告 | 消息、文件与角色约定 |
| 进展判断 | 设计独立 Watchdog 巡检 | Worker 报告,人可介入 | 既有定时观察与人工跟进 |
| 证据范围 | 合成负载调度实验 | 功能与机制说明 | 小规模使用经验 |
接下来值得试:减少消息转述,能否降低人工跟进和返工?
一个负责持续跟进,另一个把开发、审查和成员状态放在同一工作台。
更多并发只是起点,还要让结果经过协调、验证和决策。
独立任务可同时推进
并发能力增强后,瓶颈可能转移到协调、验证与人的注意力。