DeepSeek 开源 dsh-superagent 编码智能体原型，以 PR 回复 GitHub 与飞书请求

DeepSeek 发布了 dsh-superagent，这是一个以 MIT 许可证开源的研究原型，属于一种编程 agent，它接收来自 GitHub 和飞书的请求，并以 pull request 的形式作答。我们阅读了它的授权与执行文档，在此解释其权限模型、安全默认值，以及每位运维人员在安装前都该读的那一行。

该仓库描述的是一个面向单一 GitHub 仓库的主动式编程 agent。当一位被允许的人请求它做事时，它会创建一个工作项（称为 Ticket），在自己的会话和文件夹中完成工作，并在请求发起的地方回复。Web 面板只列出需要人处理的事项。

它声明的原则是：尽可能少占用人的注意力，尽可能多地提供价值。它对请求只确认一次，工作期间保持安静，等到结果就绪、需要决策或无法完成时再发声。

安装方式是让一个编程 agent 按照 SETUP.md 操作，一次只问一个问题。README 没有说明它由哪个模型驱动。

显式：被允许的人向 agent 发起请求，或在已有 Ticket 的会话中跟进 推断：未列入名单的人在某个 Ticket 的会话中跟进；来源机器人列表中的机器人在向 agent 发起请求 不予接纳：任何其他机器人；准入表忽略的任何情况；accept 模式关闭时的所有推断情形

每个来源都有一张带安全默认值的准入表。被允许但未向 agent 发起请求的人：推断。未列入名单但向 agent 发起请求的人：忽略。未列入名单且未向 agent 发起请求的人：忽略。

把“未列入名单且发起请求”这一格设为显式，就会允许该会话中的任何人在提及 agent 时请求它做事。文档建议将其用于专门的支持会话。这也正是最需要谨慎对待的设置。

主动工作需要有书面规则，而 accept 模式决定实际会发生什么。

显式请求在所有模式下都有效。文档建议先从 observe 模式开始，只有在审阅过它本会采取的行动之后，再切换到 auto。

每个被接纳的 Ticket 都带有一份 Mandate，记录它为何被允许：规则、发送者、策略版本。只有三件事会改变 Mandate：accept 创建它，人的 stop 撤回它，检查失败则撤销它。

在已结束的 Ticket 恢复之前，宿主会再次检查 Mandate。把某人从允许名单中移除后，依赖该人的 Ticket 就可能无法通过检查。文档指出，消息、评论和引用的文档都是输入，它们不能改变权限。这是防范通过 issue 评论进行提示注入的正确界线。

摘自 docs/003-execution.md：每个 Ticket 都会获得一个名为 worker- 加 Ticket ID 的 worker 会话，并在执行根目录下拥有自己的文件夹，默认是 state 目录的 work 文件夹。Executor 会话以运维人员的操作系统用户身份运行命令，无需审批。

因此，这个 agent 拥有你用户账户所拥有的一切：SSH 密钥、云凭证、其他仓库。Shell 命令在 5 秒后转入后台，而一轮对话之后，后台工作最多再获得 30 分钟，随后任务会被终止。

我们的解读是：授权模型控制的是谁可以请求。它并不限制 worker 一旦运行起来能触碰什么。那部分责任在你自己身上。