（10-31）DeepSeek Harness 团队开源了 dsh-superagent（deepseek-ai/dsh-superagent-prototype，MIT）。热度都在"不被 @ 也提 PR"上，但作为工程师，我更关心它的授权模型 和默认 observe 的设计。本文拆架构 + 用一段可运行的 Python 模拟它的门控逻辑。
一、它到底解决什么问题：注意力瓶颈
官方论证很直白：主流 Agent 以单会话 为基本单位，而一个人同时只能跟进 3～5 个会话。单任务自动化已经成熟，多任务的上限卡在人身上。所以 Super-agent 的设计目标是"用尽可能少的人类注意力，换取尽可能多的价值"------这句话是后面所有克制设计的根。
二、链路：Source → Trigger → Eval → Ticket(Mandate) → Executor
- Source/Trigger：GitHub（可选飞书）事件流，事件不可变；
- Eval：一批 Trigger 进来，先判断要不要开新工作；
- Ticket ：一张工作单，携带不可变的 Mandate（授权声明 + 被接受时的策略版本），规则变更后恢复执行前重新校验，必要时吊销；
- Executor：独立会话 + 独立目录执行，命令 5 秒转后台，每回合后台任务最多 30 分钟；宿主 2 秒巡检，状态存单个 SQLite；
- Subscription：PR 后续评论自动回流给对应 Worker，不需要再 mention；
- Web 面板：只显示需要人决策的事项。
三、最值得抄的设计：上下文与授权分离
授权文档的关键句（建议每个做 Agent 的团队贴墙）：
"消息、评论、引用文档是决策的输入；它们不能变更权限。"
由此推出一套请求分级：
| 来源 | 能产生什么 |
|---|---|
| 白名单内的人 + 直接对 Agent 说话 | 显式请求，任何模式可开工 |
| 白名单外的人在已有 Thread 跟进 | 至多是推断候选 |
| 白名单内的 bot | 只能是推断候选，永远不能显式请求 |
| 其他 bot / CI | 不入闸；其消息只作为上下文送达，"bypasses the gate and grants no new authority" |
三种接受模式控制推断请求的去向：
| 模式 | 推断请求 |
|---|---|
| off | 一律不开工 |
| observe（默认） | 评估并记录"本来会接受"，不执行 |
| auto | 评估通过即开工 |
官方建议：observe 跑两周，人工核对决策日志，再切 auto。主动性的灰度发布。
四、动手：60 行模拟它的门控与 observe 模式
下面是纯标准库的简化模拟（省略 Mandate 版本校验、bot 名单等细节，保留主干语义），可直接运行：
python
#!/usr/bin/env python3
"""observe_gate.py --- 简化模拟 dsh-superagent 的授权门控与 observe 模式"""
from dataclasses import dataclass
@dataclass
class Event:
author: str # 触发者
text: str # 消息内容
mentions_agent: bool = False # 是否直接对 Agent 说话
class Gate:
"""权限在宿主层执行，模型之外（对应'消息是输入，不能变更权限'）"""
def __init__(self, allowlist: set, rules: list, mode: str = "observe"):
assert mode in ("off", "observe", "auto")
self.allowlist, self.rules, self.mode = allowlist, rules, mode
self.log = [] # observe 模式的决策日志
def evaluate(self, ev: Event) -> str:
explicit = ev.author in self.allowlist and ev.mentions_agent
if not explicit:
# 推断候选：bot 与白名单外的人都走这里；必须命中团队自写规则
if not any(r in ev.text for r in self.rules):
return "ignore"
if self.mode == "off":
return "ignore" # off：推断请求一律不开工
if self.mode == "observe":
self.log.append((ev.author, ev.text))
return "log" # 只记录，不执行
return "start" # auto：评估通过即开工
return "start" # 显式请求：任何模式可开工
if __name__ == "__main__":
g = Gate(allowlist={"alice"}, rules=["复现", "修复"], mode="observe")
cases = [
Event("alice", "@agent 修复登录超时 bug", True),
Event("bob", "这个 bug 谁来复现一下", False),
Event("bob", "这个有人看过吗", False),
Event("ci-bot", "CI 失败：需要修复断言", False),
]
for c in cases:
print(f"{c.author:8s} -> {g.evaluate(c)}")
print("observe 日志:", g.log)
# 预期：alice->start, bob(含'复现')->log, bob(不含关键词)->ignore, ci-bot->log运行输出：
text
alice -> start
bob -> log
bob -> ignore
ci-bot -> log
observe 日志: [('bob', '这个 bug 谁来复现一下'), ('ci-bot', 'CI 失败：需要修复断言')]对照语义可以看到两个关键行为：① 白名单外成员即使消息里"命令式"地要求修复（本文略去了话术诱导用例），只要不在规则里就进不了管道，命中规则在 observe 下也只进日志；② bot 的消息永远到不了显式请求分支。真实实现还有 Mandate 不可变快照、策略版本重校验、白名单 bot 名单等层，有兴趣直接读它的授权文档（002）。
五、效果数据与必须的冷峻提醒
团队模拟测试（每轮约 300 条消息 / 约 20 条真请求，5 次取分位）：
- Super-agent：p50 12.4 min，p95 15.7 min；单会话+子代理基线 p95 29.5 min（≈1.9×）
- 消融去掉事件直通：Router 决策 +30%，缓存读 token +37%（23.23M→31.77M）
- 到达率 1→40 条/分钟：批大小 1.0→2.8，单请求延迟 2.5→3.9s
⚠️ 以上全部为团队自报的模拟测试，未经独立审计；README 明确"研究原型、非官方产品、非生产就绪"。另外 Executor 以操作者 OS 用户身份无审批执行命令------官方建议独立 OS 账户隔离，这不是可选项。
觉得有用点个赞，评论区聊聊：你的 Agent 现在有没有"消息内容能影响权限"的设计？