群聊没人@，AI自己交PR？国内实验室公开「更自主」智能体架构
- 发布于
群里有人吐槽软件卡顿，还没人@机器人，后台已经在复现问题、写修复、交 Pull Request——这不是科幻预告，而是 DeepSeek Harness 团队10月31日晚公开的一套架构探索里，写进案例的一幕。
第一财经、IT之家同日报道了这篇题为《Super-agent 设计探索：迈向更自主的 Agent 系统》的技术文章。核心不是「又一个聊天机器人」，而是想把 AI智能体从「等人点名」往「持续在线、能并行、能主动」推进一步。文章同时强调：基于同思路的内部实例已在跑，GitHub 上的 dsh-superagent-prototype 是研究原型，非正式产品。
先记住三句话
- 能力：Router＋多 Worker；事件驱动；群聊无人@也可识别缺陷并尝试交 PR。
- 定位：架构探索／研究原型，不是已上架的正式产品。
- 边界：提示词注入、端侧凭据、跨设备权限仍是待解问题——越「自主」，越要先谈授权、验收与署名。
报道里写了什么
据第一财经，当团队成员在群聊反馈软件问题时，即使没有人主动@ AI，系统也能识别潜在缺陷，在后台尝试复现并寻找修复方案。IT之家转述更细：现有主流设计仍以单一 Session 为基本单位，一个人通常只能同时跟进约3至5个活跃会话；限制进一步提升的，越来越像是人的注意力，而不只是单次任务能不能做完。
团队把这种形态称为 Super-agent，并归纳四项基础特征：连续、高效、主动、持久——同一任务可在即时通讯与 GitHub 评论等渠道间连续推进；可并行处理多项复杂任务；可持续观察环境事件并自行推进值得处理的事项；并尽量保持长期在线、可从异常恢复。
「无人@也交PR」长什么样
公开材料里有一张示意很直观：在消息很多的产品用户群里，没人@、也没人指派，Super-agent 静默监听；用户随口描述一个 macOS 桌面端误触缺陷后，它在后台复现、排查，再提交带前后对比的 Pull Request，并写出根因判断。
另一张示意则展示同一任务如何在 IM 群聊与 GitHub 评审之间连续推进：维护者在群里点名功能需求，AI智能体交 PR；评审意见回到 GitHub，它再改；最后又在群里同步「已合并」。人仍在做决策与验收，但切换会话、同步上下文的琐碎，被系统层接走了一部分。
架构：Router ＋ 多 Worker
整体思路可以概括成几块：双层架构、事件驱动、面向人的交互、计算与状态及环境分离，以及外部 Watchdog。
双层是骨架：Router 层承接人类交互、维护全局上下文并分派任务；Worker 层在相互隔离的会话里并发执行。Worker 不直接对用户回复，而是把状态和结果汇报给 Router，由后者统一对外沟通。
事件侧，群聊消息、邮件与日程、代码审查评论、CI 结果等被称为 Trigger；先经程序规则过滤，再交大模型判断是否行动。对已分配任务的事件流，Worker 可订阅对应 Thread，后续相关事件可直通 Worker，减轻 Router 负担。文章还提到异步 ReAct、投机执行、Inline & Spill 与链式召回等机制——这些属于工程细节，本文不展开复述。
实验数字怎么读
初步实验对比了 Super-agent、去掉事件直通的变体，以及两种提示词配置下的「单 Session＋Subagent」。每次约300条消息、约20条工作请求，方案各跑5次。结果显示：Super-agent 任务完成时间 p50／p95 约 12.4／15.7 分钟；中性提示下的单 Session 方案 p95 约29.5分钟。
团队自己写明：实验基于合成负载和简化环境，主要评估调度与协作，并不衡量单个任务的实际执行能力。把它当成「自动写代码有多强」的分数，会读歪。
研究原型，不是正式产品
GitHub 仓库 deepseek-ai/dsh-superagent-prototype 的 README 开篇用加粗声明写得很清楚：这是 research prototype for reference only, not an official DeepSeek product——仅供参考的研究原型，非正式产品；代码来自团队日常开发，大量工程由 coding agents 完成，可能仍有缺陷，风格与工程实践未必一致，使用前请自行审查与适配。仓库还说明：为公开发布做过适配，与内部版本及文章描述并不完全相同，文中部分设计属于未来方向，原型里尚未实现。
文章同时列出仍待解决的问题：Router 如何随任务规模扩展、更长程记忆、脱离 Session 后的人机协作、不同实例之间的通信，以及安全与隐私。尤其云端 AI智能体接入本地设备后，提示词注入、端侧凭据泄露、跨设备权限都需要进一步解决。
更自主之后，责任怎么分
能力演示越「主动」，组织里越要先问三件事：谁授权它听群、改代码、交 PR？谁验收合并？出错时署名与追责落到谁？
在生成式人工智能服务场景下，《生成式人工智能服务管理暂行办法》强调服务提供者对安全等事项的主体责任——对外提供生成式 AI 服务的，不能把合规理解成「模型自己看着办」。职务协作里，授权范围、验收标准、成果署名最好写进流程，而不是等 PR 已经合进主干再补锅。若 AI智能体要带本地凭据、跨设备执行，个保与网安视角下的最小权限、访问控制、日志审计，也应一并设计；公开材料自己也把提示词注入与凭据风险列为待解项。
这些不是要泼冷水，而是提醒：架构探索可以大胆；落到团队日常，边界要先画小、再放大。
今天就能带走的清单
- 先定性再试用。 公开仓库与文章口径一致：研究原型／架构探索，非正式产品；评估时按原型标准，别按正式 SLA。
- 群聊「主动」＝默认监听？ 若准备试点，先书面约定：监听哪些群、哪些事件可自动开 Worker、何种结果必须人工确认后才能交 PR／合并。
- 授权／验收／署名拆开写。 谁可以让 AI智能体改哪些仓；谁有合并权；自动生成的提交信息与作者字段怎么标。
- 凭据与权限按「待解」对待。 端侧 daemon、云端状态、跨设备访问——默认最小权限，敏感凭据不进提示词，操作留审计。
- 读实验数字要连着免责声明。 p50／p95 反映的是调度协作实验，不是单任务质量榜。
越是「没人@也会动」的系统，越依赖人事先把「能动到哪」说清楚。DeepSeek 把双层架构与主动修复的案例摊开，是一次有画面的技术公开；对使用者而言，真正可带走的，不只是 Router 和 Worker 这两个词，还有授权、验收与权限边界这张清单。
本文据第一财经、IT之家报道及 GitHub 公开 README 核对。属普法／安全提示分享，不构成法律意见。
来源
第一财经：《DeepSeek发布全新Agent架构》（2026-10-31）https://www.yicai.com/news/103419784.html IT之家：《DeepSeek 提出 Super-agent 架构设计：Router 与 Worker 双层架构，探索更自主的 Agent 系统》（2026-10-31）https://www.ithome.com/1/020/615.htm GitHub：deepseek-ai/dsh-superagent-prototype（README「research prototype… not an official DeepSeek product」）https://github.com/deepseek-ai/dsh-superagent-prototype
AI 与法律：前沿、判例、合规。
本站文章仅供学习交流，不构成法律意见或执业建议。