没有人敲下这条请求

一览

一个仓库，读取时间为 2026 年 11 月 2 日。

两天内 star 数就过了万，这说明的是需求有多旺，而不是设计有多好。设计在 000 到 003 这几份文档里，而它们格外值得花时间——因为在为数不多的公开成果中，它把主动性当作一个授权问题，而不是一个提示词问题。

主动性真正打破了什么

请求驱动的智能体免费拿到了授权，而这份「免费」在它消失之前是看不见的。有人打开了你的产品，完成了认证，然后敲了字。身份在第一个 token 之前就已确立。意图由「敲字」这个动作本身确立。范围由「在哪里敲」确立。随后你的权限系统只需判断那个人是否可以做那件事——这是一个可解的问题，因为两半信息都是随请求一起到达的。

主动式智能体一样都没有。触发它的是一次状态变化：出现了一条评论、一次构建失败、一个标签被挪动、一条规则命中了。没有已认证的会话，因为没人打开任何东西。没有被表达出来的意图，因为没人表达——是一条规则推断出来的。而这个触发，来自任何持有 GitHub 账号的人都能写入的界面。所以这不是一个带安全脚注的交互问题：授权模型必须重建；如果跳过这一步，你交付出去的东西就是一个远程代码执行端点，而它的触发口令写在你仓库的 issue 列表里。

这与环境权限是同一类结构性问题，只是向前挪了一层。在那里，智能体已经握着权限，而检查来得太晚。在这里，权限是在触发点上被组装起来的；如果触发点是攻击者的文字，那么下游任何检查都没有在看正确的问题。

真正承重的那句话

文档 002 把规则表述得不能更直白：消息、评论和被引用的文档是「决策的输入；它们无法改变那些权限」。许可名单、规则与授权由宿主强制执行；任何以内容形式到达的东西都不能编辑它们。

这就是一份写下来的指令层级，只不过它针对的是触发界面，而不是提示词。而且在那些最容易偷懒的地方，这套设计都把它贯彻下去了：

• 订阅不等于权限。智能体正在关注的线程上的消息，只会作为上下文进入工单，不授予任何新权限。它可以读到某个机器人的评论并据此行动，但不能被它命令。
• 机器人自成一类。GitHub App、以 [bot] 结尾的登录名和飞书机器人，只有在某个来源列出它们时才可能产生「推断候选」，永远不能产生显式请求——也永远不能发出停止。其余一概不予受理。
• 执行者不能替人作保。一个人在线程里说「停」，是一次由评估器裁定的普通触发。执行者不被允许自行宣称有人要求它停下。
• 权限是重新核验的，不是缓存的。每一份授权在工单恢复之前都会重新核验——对照来源、策略版本、名单成员资格与机器人名单。把某人从许可名单里移除，经由此人接受的那些授权会在下一次重新核验时被撤销。

最后这一条，建过审批流的人值得读两遍。大多数系统把一次批准当作持久的授予：批过一次，便一路带着走。而这里，一份授权是一个「此刻仍须成立」的主张，核验点在恢复之时——正是这种设计，才能让一名已离职员工的长期授权真的停止生效。这与凭据有效期是同一套纪律，只是作用对象从令牌换成了行动的许可。

仓库里最有意思的一行是那个默认值

接受模式有三档——off、observe 和 auto——默认是 observe。在 observe 模式下，一次评估为正的结果会被记为「本会接受」，而什么都不会被真正接受。显式请求在任何模式下都照常生效。

也就是说，这个主动式智能体出厂时主动性是关着的，开着的是一份「它本会采取哪些主动行动」的日志。这就是影子模式，只不过作用于授权而非模型质量；而它之所以是正确的默认值，原因多数团队都要花大钱才学到：「这条规则是不是太宽了？」这个问题，从规则文本里推不出答案，只能从一周的决策记录里读出来。

文档 000 把同一件事写成了建议——从窄处起步，用一份短的许可名单，主动工作只做记录，等记录下来的动作看起来没问题之后再放宽。如果你只从这次发布里拿走一样东西，就拿这一条：主动式智能体的发布单位不是智能体，而是规则，而每条规则都要有一段影子期。

而执行层什么都没声称

文档 003 是这份坦白开始承重的地方。每个工单都有自己的会话，命名为 worker-<ticket id>，并在执行根目录下有自己的目录。路由会话与工作者会话各有命令预设，前者工具集更小；还有一份被阻止的命令清单，它们「在以名称调用时会失败」。然后文档说明了这一切到底值多少：「这些包装器与目录建立的是默认值，不是安全边界。」工作者仍然可以用绝对路径运行一个程序。执行者会话「以运维者的操作系统用户身份、未经审批地运行命令」。

由此有两个推论，而它们指向相反的方向。

第一个是针对这个原型本身的警告：请用一个「你能接受攻击者拥有其权限」的用户去跑它，放在一台「你能接受攻击者触达」的机器上，因为这套设计并没有声称别的。在它碰到任何你在意的东西之前，先给它配上沙箱与隔离模式里讨论的那种围堵，并注意文档 003 完全没有描述任何网络出口限制。

第二个是一句称赞，也是这次发布值得一写的理由。一份会点明自身「非边界」之处的设计文档，比一份暗示自己拥有实则没有的边界的文档，既更罕见也更有用。这个领域里最危险的产物，是一张架构图，上面有一个写着「沙箱」的框，而通篇没有一句话说这个框是靠什么来强制执行的。而在这里，强制执行恰好被点明在它确实存在的地方——宿主的策略层——也恰好在它并不存在的地方被明确放弃。

合并规则，以及它约束的是谁

还有一块值得单独拎出来，因为当团队让智能体靠近发布流程时，错的往往正是这一块。默认指令只允许对「由该工单自己开启、处于 ready 状态、head commit 上已获得必需批准、且改动少于 200 行」的拉取请求启用自动合并；在推送下一个修订之前，智能体会先撤销自动合并；默认情况下它绝不以自己的账号启用自动合并。然后文档明确指出，这些指令「约束的是智能体，不是 GitHub 的合并规则」——真正的强制执行需要开启分支保护，并设置为「有新提交时作废既有批准」。

这一组区分，就是智能体治理的全部，浓缩成一句话。提示词里的一条指令，是关于智能体意图的策略。一条分支保护规则，是关于结果的策略，由智能体压根联系不上的东西来强制执行。200 行这个阈值是个合理的启发式，它不是控制；作废既有批准才是控制。团队常常交付了前者，却相信自己拥有后者——这正是监控完整性里描述的那种失效：做检查的东西，不能被受检查的东西触达。

该从里面拿走什么

README 指向一篇配套文章《Exploring Super-agent Design: Towards a More Autonomous Agent System》，并说明公开的原型与 DeepSeek 内部版本有差异，文章里的部分设计属于尚未在此实现的未来方向。所以请把代码当作例证，把文档当作真正的交付物。其中四条可以直接搬到你正在构建的任何东西上：

• 把门与活分开。由一个地方裁定工作是否可以开始，并且由宿主强制执行，而不是交给智能体自己的判断。一切以文字形式到达的东西都是这个决策的输入，永远不是它的修饰语。
• 先给发送者分类，再给请求分类。人、已列出的机器人、未列出的机器人，以及「是否直接对它说话」，这四个廉价事实在模型介入之前就能解决大半问题。参见自动批准与许可名单。
• 让默认值只做记录。每条主动规则先以影子模式交付，凭证据提升它，并保留把它降回去的能力。
• 在恢复时重新核验。一个长期运行的工单必须重新挣得它的权限，因为它等待的这段时间里，世界变了。

还有一样东西不该拿走：隔离模型。这个原型自己的文档告诉你它不是边界，而这恰恰是设计被搬进产品时最容易被丢掉的那类句子。授权层是被认真工程化的部分。沙箱是你仍然欠用户的那部分。

延伸阅读

本站相关：

• 主动式智能体——同一个问题的产品侧。
• 指令层级——为什么不能允许内容去编辑权限。
• 定时与触发式智能体——运营那些不由人发起的工作。
• 沙箱与隔离模式——这个原型拒绝声称自己拥有的那种围堵。

项目来源：

• deepseek-ai/dsh-superagent——仓库及其九份设计文档
• docs/002-authorization.md——上文引用的授权设计
• docs/003-execution.md——执行设计，含「非边界」的那段表述