你有没有觉得，现在的AI编程助手再强，也还是个"叫一下动一下"的工具。
你在对话框里提需求，它在这一个会话里干活。会话一关，上下文全没；同时来五件事，它只能排队；想让它盯着GitHub仓库、有人提Issue就自动处理，更是无从谈起。
10月31日晚间，DeepSeek Harness团队把这套问题的答案开源了，项目名叫dsh-superagent-prototype，几天时间拿到4.8k多star，主语言TypeScript。它不是一个聊天机器人，而是一个常驻的、能自己接单自己干活的超级智能体原型。
先声明：这是研究原型，不是正式产品README开头就写得很直白：这是研究代码，仅供参考，不是DeepSeek官方产品，不要直接拿去生产环境跑。
代码大部分是团队日常开发中由编码智能体写出来的，开源前做过适配，和内部版本、以及论文《Exploring Super-agent Design: Towards a More Autonomous Agent System》里描述的实现并不完全一致，论文里有些设计还只是未来方向。
它的运行形态是DeepSeek Harness的一个插件组合包。Harness是DeepSeek做的智能体运行环境，核心理念是"一切皆插件"，模型、工具、技能、会话都以插件形式挂载。dsh-superagent就跑在这个底座上，目前专注服务一个GitHub仓库，也可以接入飞书。
整套设计只围绕一个原则：省注意力我觉得这个项目最值得琢磨的，不是某个技术点，而是它的哲学。
文档里反复强调一句话：占用尽可能少的人类注意力，交付尽可能多的价值。
注意，是"注意力"而不是"时间"。一条消息、一个通知、一个提问、一个设置项，都在消耗人的注意力。任何东西如果带来的价值抵不上它消耗的注意力，就删掉。
由此推出几条很硬的行为规则：
只在被明确要求时、或者团队写好的规则允许时才行动，绝不自己找活干；干活期间保持安静，只有结果就绪、需要人做决定、或者实在干不下去时才说话；一次只问一个具体问题，用结构化表单，而不是把问题埋在长篇报告里；按影响停止，而不是按努力停止：本地改动要做到可评审的结果，需要设计决策的就带着明确问题停下来；诚实汇报，草稿就标未完成，失败就报失败，绝不绕过限制来逃避提问。文档里甚至专门警告：不要用它制造批量PR、群发消息这种"工作量"，一个能代表整个团队行动的智能体，也能浪费整个团队的注意力。
它怎么工作：从事件到工单要理解机制，先记住几个核心概念。整套领域模型很克制，业务需求都落成这些概念的属性，不随便加新概念。
**Source（来源）**是事件流，现在有两个实现：GitHub和飞书。GitHub侧能监听通知、订阅的Issue和PR、CI状态变化、PR被合并或关闭；打开开关后还能接收仓库里所有新Issue、新PR和评论。飞书侧接收实时事件、历史消息恢复和话题轮询。
**Trigger（触发）**是一条不可变的事件，带着发送者等元数据，是审计和幂等的基本单位。同一个Trigger接收两次，只会产生一个工单。
**Eval（评估）**负责判断这批事件是不是新工作，分两层：第一层Gate（准入）是确定性的规则检查，看发送者是谁、有没有在允许名单里、有没有@机器人；第二层Assessment（研判）才是模型给出的判断。Eval本身不保存任何状态。
评估通过后，会生成一个Mandate（授权）和一个Ticket（工单）。授权记录了策略版本、范围、强度、匹配的规则和发送者身份，是不可变的；工单则是授权工作的执行单元，有自己的状态机，不跟着执行器的状态走。
最后通过**Assignment（派工）**把工单交给一个Executor（执行器），结果通过Channel（渠道）回到来源，比如在原话题下回复、或者直接给出一个PR。
还有一个精妙的设计叫Subscription（订阅）。工单和事件线程之间是多对多关系，后续讨论不用再@机器人，消息会自动扇出到订阅了该线程的所有工单，作为上下文送达。但上下文就是上下文，不授予任何新权力，工单仍然受原始授权约束。
Router加Worker的双层架构这也是外界报道最多的一点。系统里有两类会话：
主Session叫orchestrator，也就是Router，负责评估事件、接单和分派工单、回复消息，工具集更小，专注路由；
每个工单会开一个独立的Executor Session，名字叫worker加工单ID，还配一个独立的工作目录，典型做法是用git worktree拉出独立检出，互不干扰。
这意味着多个任务可以真正并行推进，每个worker在自己的会话和目录里干活，崩了也不影响别的工单。worker还能派生用standard预设的子智能体，嵌套子智能体只继承工单允许的工具，工单结束就失去权限。
长命令处理也很实用：前台shell命令跑5秒还没结束，自动转成后台任务，这样worker马上能接收新消息，不用干等。一轮结束后后台任务最多给30分钟，超时就杀掉并上报等待。
并发上有个细节我很喜欢：并发槽位满的时候，会额外留一个槽给人的消息或状态查询，保证新工作永远不会挡住人继续推进已有工单。
授权模型：三种接单模式，默认先观察谁能让它干活，是被代码强制约束的，消息、评论、引用的文档都只是决策输入，改不了权限。
允许名单按Source分别维护，不同平台的身份不做映射——一个人同时有GitHub和飞书账号这件事，只是写在提示词里让智能体自己读。
接单模式有三种，是策略的一部分：
off：所有推断类候选一律不接，比如没@它的消息、机器人的消息、名单外人员的追问；observe（默认）：推断类候选照样研判，研判通过也只记录成"本会接单"的忽略决定，不真的执行；auto：推断类候选研判通过后才真正接单。而明确请求——也就是允许名单上的人直接@它——在任何模式下都生效。
官方建议的上线路径很稳：先在observe模式跑，看它记录的"本会接单"决定对不对，确认靠谱了再切auto。机器人账号比如dependabot发来的消息，最多成为推断候选，永远不能发起明确请求、也不能停掉工单。
规则变更同样讲究：策略版本一变，运行中的评估直接丢弃、事件重新排队；变化会通知受影响的在途工单，但不立刻撤销已有授权，避免留下半截工程。
合并PR这件事，默认交给人执行器可以在自己的PR上启用自动合并，但默认规则相当保守：PR是为这个工单开的、已经就绪、必要审批覆盖了最新提交、而且新增加删除总行数少于200行，才允许自动合并。推新版本前还要先撤回自动合并。
而且它不会用机器人账号自己点合并——GitHub会把合并记在点击者头上。要自动合并，得在交付要求里指定另一个账号的CLI，否则默认就是人来合并。
想强制审批，就去分支保护里设规则，提示词约束的是智能体行为，代替不了GitHub的合并规则。
一个只显示"需要你处理什么"的面板打开Harness网页侧边栏的Superagent面板，它只回答三个问题：现在有什么需要我处理？系统是否健康、干的事对不对？某件工作从触发到评估到工单的完整历史是什么？
面板按Overview、Source、Trigger、Eval、Execution、Settings分标签。最能体现哲学的是：待人工处理的工单排在最前面，健康状态不占任何空间。工单状态标签都是大白话，比如"等待答复""等待评审""受阻·失败"，而不是内部状态码。
工单的生命周期也清楚：待派工、执行中、等待触发、等待答复、等待评审、受阻失败，每个状态都有可检查的判定条件，互斥且覆盖全部情况。
部署上手：让智能体陪你装安装步骤很多，所以它的设计是让你找自己的编码智能体，说一句"读一下仓库里的SETUP.md，陪我把dsh-superagent配好"。
然后它一次只问一个短问题，给出推荐答案，收集完再展示完整计划，确认后才动手。密钥类操作不会在聊天里问，会整理成命令让你在自己终端执行。
环境要求包括Node.js 22.19以上、pnpm、git 2.32以上、tmux、Python3.8以上、GitHub CLI 2.48以上，以及对应版本的DSH。默认配置里有独立的superagent配置文件、3082端口、agent开头的分支前缀，还有一个每小时从你自己的配置文件执行的检查，保证插件挂了能自动修复。
开发验证则简单直接：
pnpm check
这一条会跑完类型检查、测试和构建。
我的看法这个项目的价值，我觉得分两层。
对想落地自主智能体的团队，它给出了一套相当完整的参考实现：事件驱动、双层架构、授权与上下文分离、结构化的人工交接、失败恢复和重启续跑，这些都是真实工程里绕不开的坑，而且文档编号组织、每个概念只在需要时才引入，读起来很顺。
对普通开发者，它更大的价值是传递一种判断标准：智能体不是越主动越好，而是越克制越可信。先从最小的允许名单和observe模式开始，逐步放开，比一上来就放手让它满仓库提PR靠谱得多。
局限也要说清楚：它绑死DeepSeek Harness生态，目前只盯一个仓库，开源版和论文、内部版都有差异，README自己都承认可能有bug、工程风格不统一，拿过来必须先审再改。MIT协议倒是很宽松。
如果你在思考怎么让AI真正融入团队日常协作，而不只是当一个问答工具，这套原型值得周末拉下来读一读。
项目地址：https://github.com/deepseek-ai/dsh-superagent-prototype