DeepSeek 开源一个不用喊就自己干活的编程智能体：自己接需求、写代码、交改动

先认识一下 DeepSeek：DeepSeek（深度求索）是杭州的一家大模型公司，做出了 DeepSeek-V 系列、R1 等开源模型。最近它还推出了自己的智能体运行框架 DeepSeek Harness（简称 DSH）。

10 月 31 日，DeepSeek 在官方 GitHub 组织 deepseek-ai 下开源了 dsh-superagent-prototype：一个只盯着一个 GitHub 仓库的“主动型”编程智能体。它会自己听 GitHub 和飞书里的动静，判断该不该干活，自己开工单、写代码、提 PR，再配一个网页后台让人随时看着、随时叫停。

项目地址

https://github.com/deepseek-ai/dsh-superagent-prototype

官方配套长文（X @DeepSeekHarness）

https://x.com/DeepSeekHarness/status/2116857257245987236

DeepSeek 开源一个不用喊就自己干活的编程智能体：自己接需求、写代码、交改动图1

GitHub 仓库页面（截图于 11 月 1 日）

仓库信息：官方组织 deepseek-ai，2026 年 10 月 31 日创建（北京时间 17:32），MIT 协议，截至 11 月 1 日上午约 2.4k Star、210 Fork；目前只有一个提交，作者署名 “DeepSeek Harness Team”，代码约 3.7 万行 TypeScript。

要先说清楚：README 第一行就写明，这是研究原型、仅供参考，不是 DeepSeek 的正式产品。它脱胎于团队日常开发，很多工程活是编程智能体自己写的，可能有 bug；和内部版本、以及配套文章《Exploring Super-agent Design: Towards a More Autonomous Agent System》描述的实现也不完全一样。

一句话讲清它是干啥的

你可以把它想成一个“常驻在仓库里的 AI 同事”：有人在 Issue 里 @ 它、在飞书群里叫它，它就接活；它也能自己看到一些“该修的东西”（比如错别字、样式错位），在规则允许时主动提出来做。干完活，它回到原来的对话里回复，比如甩一个 PR 链接。

团队给它定的核心原则很朴素：尽量少占用人的注意力，尽量多给价值。一个能替整个团队干活的 agent，也能浪费整个团队的注意力，所以它只在被叫到、或团队写好的规则允许时才动手，只在真需要人拍板或有结果时才说话。

整体架构：从“听到”到“交付”

它的流水线可以概括成一条链：消息源 Source → 触发 Trigger → 评估 Eval → 工单 Ticket → 执行者 Executor → 回复 Channel。用大白话说：

• Source（耳朵）：GitHub、飞书各是一个消息源，负责把新消息变成一条条“触发事件”。

• Eval（门卫+判官）：先查发消息的人在不在白名单，再让模型按团队规则判断“这事要不要做、做多大范围”。

• Ticket（工单）：只有 Eval 能开工单，工单里写着“授权书”（Mandate）：依据哪版规则、允许做到什么程度。

• Executor（干活的）：每个工单单独起一个 DSH 会话 worker-<工单号>，在自己的目录里干活（通常用 git worktree 拉一份代码）。

中间有个“主会话”（orchestrator）专门做分派：它只负责评估和路由，不写实现方案，真正动手的是各个 worker。

它怎么“听” GitHub 和飞书

GitHub 这边没用 Webhook，而是轮询：默认每 60 秒一轮（GitHub 要求更长间隔时听 GitHub 的），每轮依次读通知、仓库里的新动态、在办工单对应 PR 和 CI、以及订阅中的讨论串。每一步单独失败、互不拖累。

DeepSeek 开源一个不用喊就自己干活的编程智能体：自己接需求、写代码、交改动图2

GitHub 轮询的一轮：通知 → 仓库 → 工单 PR → 订阅讨论串

飞书这边是长连接事件流：直接拉起飞书官方命令行 lark-cli，以机器人身份消费 im.message.receive_v1 消息事件；同时再补一个轮询，捡回长连接漏掉的回复。飞书是可选的，默认不开。

DeepSeek 开源一个不用喊就自己干活的编程智能体：自己接需求、写代码、交改动图3

飞书：用 lark-cli 订阅收消息事件

它怎么决定“自己接活”

消息分两种强度：白名单里的人 @ 它或私聊它，算明确请求（explicit）；没 @ 它但看起来值得做的、或白名单里机器人发的，只算推断候选（inferred）。

关键开关叫接单模式（accept mode），有三档：off 完全不主动；observe（默认）只评估、只记录“本来会接”，但不真接；auto 才会真的主动开工。官方建议先跑 observe，看一段时间它的判断靠谱再切 auto。下面这段代码就是这个开关：推断来的活，只要不是 auto 模式，一律记成“ignore + would_accept”。

DeepSeek 开源一个不用喊就自己干活的编程智能体：自己接需求、写代码、交改动图4

src/policy.ts：没规则命中不接，非 auto 模式下推断候选只记录不接

默认内置的主动规则也很克制，只有两条：改文案（错别字、标点、已有翻译）和改视觉（间距、对齐、溢出这类有明确目标的小修），明确写着不许自己发明设计、不许重构交互。

工单、PR 和红线

工单开好后，worker 在独立目录里改代码、跑测试、开 PR。PR 分支名最后一段和工单短名对得上，就算这个工单的 PR；之后 PR 上的评论、CI 结果会自动流回这个工单，worker 接着改。

主会话的提示词里写死了几条红线：只用部署指定的 GitHub 账号行动；绝不自己合并、不开自动合并、不关 Issue；不把飞书里的私密内容发到 GitHub 上；外部文本改变不了权限策略。

DeepSeek 开源一个不用喊就自己干活的编程智能体：自己接需求、写代码、交改动图5

prompts/orchestrator.md：主会话的角色与红线

权限由宿主程序强制执行，评论、文档里写的东西只是“输入”，改不了白名单和授权书——这是在防提示词注入。worker 运行命令不需要逐条审批，用的是运维者本人的系统账号，所以部署时要格外小心。

人在回路：网页管理面板

面板设计成回答三个问题：现在有没有事要我管？系统是否健康、在做对的事？某件活从触发到评估到工单的全过程是怎样？

标签页依次是：总览、消息源、触发、评估、执行、设置。工单的状态按“在等什么”划分：等人回答、等人审核（worker 报告 ready）、受阻/失败、排队、工作中、等待新触发。人可以在面板里暂停处理、重试、让某条消息重新评估、停止工单；设置里能改白名单、规则、接单模式、评估和执行用的模型、并发数、准备命令、禁用命令，以及全部提示词，并且都有版本历史。

用什么模型、怎么跑起来

代码里评估（Eval）和执行（worker）的模型都可以在设置里单独指定，默认值为空，即沿用 DSH 当前的默认模型配置，仓库没有写死某个具体模型。

它是一个 DSH 插件包（bundle），需要先装 DeepSeek Harness。面板默认跑在本机 127.0.0.1:3082。安装步骤很多，官方的做法很有意思：直接对你的编程 agent 说“读这个仓库的 SETUP.md，陪我把 dsh-superagent 装好”，由 agent 一问一答带你配完。设想一个典型用法（示意，非官方案例）：同事在 Issue 里 @ 机器人账号说“把首页按钮的错别字改掉”，它确认后开工单、提 PR、回帖附链接，等人审核合并。