<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>开源 on 科技刺猬</title><link>https://kejiciwei.com/tags/%E5%BC%80%E6%BA%90/</link><description>Recent content in 开源 on 科技刺猬</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Sun, 01 Nov 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://kejiciwei.com/tags/%E5%BC%80%E6%BA%90/index.xml" rel="self" type="application/rss+xml"/><item><title>DeepSeek 开源"超级智能体"原型：没人 @ 它，它自己干活</title><link>https://kejiciwei.com/deepseek-super-agent/</link><pubDate>Sun, 01 Nov 2026 00:00:00 +0000</pubDate><guid>https://kejiciwei.com/deepseek-super-agent/</guid><description>&lt;p>10 月 31 日晚，DeepSeek Harness 团队发了一篇技术长文《Super-agent 设计探索》，同时在 GitHub 上开源了一个研究原型：dsh-superagent-prototype，MIT 协议，TypeScript 写的。这是一个常驻在线的编码智能体，盯住一个 GitHub 仓库，也可以接飞书群。它不像普通的聊天助手那样等人来问，而是长期在线、主动盯着自己负责的那摊事。&lt;/p>
&lt;p>它的工作方式很直白。被授权的用户在对话里 @ 它提需求，它就开一张工单，在独立会话里干活，最后回到原对话交付——通常是一个 Pull Request。需求、过程和结果都在同一条对话线索里，找人不用翻聊天记录，审代码直接看 PR，流程是完整的。对维护者来说，这种模式省掉的是来回沟通的工夫：不用在群里反复确认进度，工单和交付都在同一个地方，状态一目了然。&lt;/p>
&lt;p>切换到 auto 模式、自己写好规则之后，它更进一步：没人 @ 它，它也能按规则静默处理，比如复现并修复 Bug。规则由人来定，执行交给它，人在规则层面把关，而不是在每一步操作上点头。这正是&amp;quot;常驻&amp;quot;两个字的含金量——它不是随叫随到的工具，而是 24 小时在岗的同事。当然，规则写得好不好，直接决定它干活靠不靠谱，授权的范围也得先想清楚。&lt;/p>
&lt;p>架构是双层结构：Router 负责派活，Worker 负责干活，Watchdog 负责盯梢。文章里写明的核心判断是，人的注意力才是瓶颈——智能体要做的，是把活干完再来找人，而不是每一步都等着人点头。常驻干活的智能体，这周又多了一个，路子和 10 月 24 日那篇&lt;a href="https://kejiciwei.com/claude-duet-proactive-agent/">手机关机，AI 还在加班&lt;/a>里写的 Claude Duet 是同一个方向。&lt;/p>
&lt;h2 id="先看明白再动手试">先看明白，再动手试&lt;/h2>
&lt;p>不过这个原型的边界，官方写得很清楚：仅研究原型，不是 DeepSeek 的正式产品，与内部版本和文章描述不完全一致，部分设计是未来方向，原型里还没实现。实验数据来自合成负载，测的是调度能力，而不是写代码能力。换句话说，它证明的是&amp;quot;管得起来&amp;quot;，而不是&amp;quot;写得好&amp;quot;。&lt;/p>
&lt;p>所以它的正确用法，是拿来学架构、在测试仓库里试，而不是直接接生产。对想搞明白&amp;quot;常驻智能体到底怎么管起来&amp;quot;的开发者来说，这份开源代码的价值，恰恰在那些还没实现的部分里——它把一张路线图摊在了桌上，先看明白，再动手试。等它再成熟一些，常驻智能体或许会成为每个仓库的标配；眼下，它更像一份写给开发者的邀请：架构在这里，边界也在这里，剩下的，欢迎一起来试。&lt;/p></description></item></channel></rss>