没人@它也干活:DeepSeek把调度、缓存、看门狗搬进Agent,用4倍token换掉一半完成时间
没人@它也干活:DeepSeek把调度、缓存、看门狗搬进Agent,用4倍token换掉一半完成时间
Part One:10月31日开源的东西,和你熟悉的Agent不是一回事
2026年10月31日晚,DeepSeek Harness 团队发了一篇长文,讲他们对"自主 Agent"的探索,同时把原型代码以 MIT 协议开源了:deepseek-ai/dsh-superagent-prototype。
这个叫 Super-agent(超级智能体) 的东西,一句话概括:一个常驻在线、不用人@也会主动干活、能同时推进多项任务、出问题能自己恢复的 Coding Agent。
它的工作方式是:盯住一个 GitHub 仓库(可选接飞书群),有人在 Issue 里抱怨一个 Bug、或者在群里提一句需求,它就自己开工单、在独立会话和目录里干活、干完回到原对话交付——通常是一个 Pull Request。
有个实测细节很能说明状态:
在 GitHub 提了一个 Issue,没有 @ 任何人。49 秒后 Super-agent 自动回复,不到 2 分钟 PR 就交到手上,改了 1 行代码,CI 通过。这一通操作总计花费 4 分钱。
还有几个更"自主"的案例:模型输出里的波浪号被渲染成删除线,群里还在争论该在训练里解决还是改渲染规则,PR 已经提交了;一个双击误触发的 Bug,它自己查明原因还附了修复前后对比截图。
但必须先说清楚边界:DeepSeek 明确写了,这只是一个研究原型,不是正式产品。它只监听一个 GitHub 仓库,GitLab/Gitee 不支持,管理面板只有中文和英文,版本 0.1.0。截至 11 月 1 日仓库约 2,800 星。
那么,为什么这个东西值得认真拆?因为它解决的问题不是"模型不够强",而是"人的注意力不够用"。
Part Two:为什么必须拆成两层——一个开10个窗口的人
DeepSeek 团队给这个问题的起点,是一句非常具体的观察:
“我平时开着大概 10 个 Agent 终端窗口,一旦真正同时跑起来,最多 4 个左右就管理不过来了。”
这个瓶颈不是算力,是人。当模型能连续干活的时间越来越长,“人要在多少个会话之间切换"就成了新天花板。你开 10 个窗口,第 5 个窗口在等你确认,第 7 个报错了,第 9 个已经跑完了但你还没看——你的注意力成了系统吞吐的瓶颈。
DeepSeek 的解法是把计算机系统里几十年的老思想搬进 Agent:调度、缓存、存算分离、看门狗。具体拆成两层:
┌─────────────────────────────────────────┐
│ Router (resident, always on) │
│ · sees all messages (GitHub / Feishu) │
│ · judges: worth acting on? authorized? │
│ · opens tickets, dispatches, never acts │
│ · lightweight model is enough │
└───────────────┬─────────────────────────┘
│ dispatch (isolated session + dir)
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Worker #1 │ │ Worker #2 │ │ Worker #3 │
│ own context │ │ own context │ │ own context │
│ own directory │ │ own directory │ │ own directory │
│ own branch │ │ own branch │ │ own branch │
│ strong model │ │ strong model │ │ strong model │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│ │ │
└─────────────────────┼─────────────────────┘
▼
┌─────────────────────────────────────────┐
│ Event bus + subscription direct-pass │
│ (Router reacts to new events instantly) │
└─────────────────────────────────────────┘
│
┌───────────────▼─────────────────────────┐
│ External Watchdog (hourly self-check) │
│ · restart if service dies │
│ · keeps the whole thing alive │
└─────────────────────────────────────────┘
Router 是包工头,Worker 是干活的。 这个分工的关键在于三点:
第一,Router 不碰具体任务。 它只看消息、判断值不值得干、有没有权限、然后把活派出去。因为不碰具体任务,它的上下文始终很短,用轻量模型就够了。而 Worker 才配最强的模型。这个"Router 轻、Worker 重"的配置,直接把成本压下来了。
第二,每个 Worker 有独立的上下文和目录。 这就是"不切会话也能并行"的实现基础。三个工单同时跑,各自在各自的目录、各自的分支上,互不干扰。实测中面板显示"执行中 3/3”,默认并发就是 3 个。
第三,上下文隔离解决了"污染"问题。 单会话方案里,你在干 A 任务,突然来一条 B 任务的消息,两个任务的上下文混在一起,模型开始混乱。双层架构里,B 任务被派给另一个 Worker,A 的上下文完全不受影响。
# Why context isolation matters: single session vs. two-layer
def context_pollution(single_session_msgs=300, work_requests=20):
"""
In a single session, all messages share one context window.
Interleaved work requests pollute each other's context.
"""
# Single session: every message competes for the same window
single_ctx_load = single_session_msgs # all in one window
# Two-layer: Router sees all, each Worker sees only its own ticket
router_ctx_load = single_session_msgs
worker_ctx_load = single_session_msgs / max(work_requests, 1) # roughly
return {
"single-session context load": f"{single_ctx_load} msgs",
"router context load": f"{router_ctx_load} msgs (but shallow)",
"per-worker context load": f"{worker_ctx_load:.1f} msgs (deep)",
"pollution risk (single)": "high — tasks interleave",
"pollution risk (two-layer)": "low — tasks isolated",
}
for k, v in context_pollution().items():
print(f" {k:32s} {v}")
这解释了一个反直觉的现象:双层架构的总 token 消耗更高(后面会看到是 4 倍),但每个 Worker 的上下文更"干净"。干净上下文带来的准确率提升,可能比省下来的 token 更值钱。
Part Three:五个模块,每个都是从操作系统抄来的
DeepSeek 明确说,这套设计的思路是"把计算机系统里的调度、缓存、存算分离、看门狗等经典思想搬进 agent 架构"。逐个看:
① 双层架构(上面已经拆过)——对应操作系统的进程调度。
② 事件驱动 + 订阅直通——对应中断机制。Router 不用轮询,新事件到达就直接推给它。这个"直通"很重要,后面数据会证明它省了 37% 的 token。
③ 异步多信道交互——对应不同的 I/O 通道。同一个 Agent,在群聊里要短、在 PR 里要长:
# Channel-aware output: the same agent, two very different formats
def channel_policy():
return {
"IM / group chat": {
"density": "low",
"goal": "minimize interruption",
"hard rule": "single reply <= 100 words; channel rejects longer",
"banned": "long sentences, semicolon chains, lists, rapid-fire multiple messages",
"when to speak": "only when a decision or acceptance is needed",
},
"GitHub PR / email / docs": {
"density": "high",
"goal": "structured async delivery",
"hard rule": "full problem background, change description, verification result",
"banned": "vague one-liners",
"when to speak": "at delivery time, once, completely",
},
}
for channel, d in channel_policy().items():
print(f"\n[{channel}]")
for k, v in d.items():
print(f" {k:16s}: {v}")
这个设计背后有一个很清醒的判断:把一个面向单人终端的交互方式直接搬进群聊,把冗长推理和密集工具调用原样输出,在多人协作里就是信息灾难。所以 Super-agent 把冗长推理全部关在 Worker 会话内部,对外只由 Router 说话,而且说了"单次回复不超过 100 词,超过发送通道直接拒收"。
注意这个措辞:不是"建议不超过",是"通道拒收"。 这是工程上非常有效的一招——把规范做进基础设施,而不是做进提示词。提示词会被模型忽略,通道不会。
④ 存算分离——对应虚拟内存。Agent 的状态(上下文、记忆)和执行(推理、工具调用)分开管理,这样多个 Worker 可以共享底层状态而不必各自复制。
⑤ 外部 Watchdog——对应看门狗定时器。安装时会自动创建一个每小时自检的定时任务,服务挂了就自己重启。这个细节很不起眼,但它是"7×24 常驻"的前提——没有 Watchdog 的常驻 Agent,只是一次性运行得比较久的脚本。
Part Four:实验数据——用4倍token换掉一半完成时间
现在看最硬的部分:官方做的消融实验。
实验设置:用群聊和 GitHub CI 消息流驱动,单次约 300 条消息,其中约 20 条是工作请求,编码工作用"只耗时的工具"代替(避免真实编码质量干扰),每种方案跑 5 次。
# The ablation: completion time vs. token cost
def ablation_results():
return [
{
"scheme": "Super-agent (two-layer + direct-pass)",
"p50_min": 12.4,
"p95_min": 15.7,
"cached_tokens_M": 23.23,
},
{
"scheme": "Super-agent, direct-pass removed",
"p50_min": 12.6,
"p95_min": 15.5,
"cached_tokens_M": 31.77,
},
{
"scheme": "Single session + Subagent tool (neutral prompt)",
"p50_min": 20.4,
"p95_min": 29.5,
"cached_tokens_M": 6.05,
},
{
"scheme": "Single session + Subagent tool (delegation-first prompt)",
"p50_min": 13.8,
"p95_min": 29.0,
"cached_tokens_M": 10.82,
},
]
print(f"{'Scheme':<52}{'p50':<8}{'p95':<8}{'Cached tok (M)'}")
print("-" * 82)
for r in ablation_results():
print(f"{r['scheme']:<52}{r['p50_min']:<8}{r['p95_min']:<8}{r['cached_tokens_M']}")
print("\nToken ratio vs single-session:")
base = 6.05
for r in ablation_results():
print(f" {r['scheme'][:48]:<50}{r['cached_tokens_M']/base:.1f}x")
跑出来的四个结论,每一个都值得单独说。
结论一:p95 从 29.5 分钟降到 15.7 分钟,接近腰斩。
这是双层架构最直接的收益。为什么单会话的 p95 这么差?因为单会话会被新消息不断打断——你正在干 A,B 的消息进来了,模型要重新理解 B、可能还要回应,A 就搁置了。300 条消息里只有 20 条是工作请求,剩下 280 条全是干扰。单会话方案的本质问题是:所有干扰都作用在同一个上下文里。
结论二:光改提示词不管用。
“优先委派"的提示词让单会话方案的 p50 从 20.4 降到 13.8——看起来追上了。但 p95 只从 29.5 降到 29.0,几乎没动。
为什么?因为长尾不是由"愿不愿意委派"决定的,是由"架构允不允许并行"决定的。中性提示下 5 次运行一次都没调用 Subagent,全在主会话里干,p95 到 29.5;优先委派后 5 次有 4 次委派了,但剩下那 1 次模型判断"这活很小"自己干了,于是又形成长尾。
这个数据对做 Agent 的人很有启发:提示词能改善平均值,改不了长尾。长尾要靠架构。
# Why prompts move the mean but not the tail
def tail_analysis():
"""
Tail latency comes from the rare case where the model decides
"I'll just do this myself" — and then gets interrupted repeatedly.
"""
scenarios = {
"neutral prompt": {
"delegation rate": "0/5 (0%)",
"p50": 20.4,
"p95": 29.5,
"tail cause": "everything runs in main session",
},
"delegation-first prompt": {
"delegation rate": "4/5 (80%)",
"p50": 13.8,
"p95": 29.0,
"tail cause": "the 1/5 self-execution case becomes the tail",
},
"two-layer architecture": {
"delegation rate": "enforced by design (100%)",
"p50": 12.4,
"p95": 15.7,
"tail cause": "no self-execution path exists",
},
}
print(f"{'Scenario':<28}{'Delegation':<26}{'p50':<8}{'p95':<8}{'Tail cause'}")
print("-" * 108)
for name, d in scenarios.items():
print(f"{name:<28}{d['delegation rate']:<26}{d['p50']:<8}{d['p95']:<8}{d['tail cause']}")
tail_analysis()
结论三:代价是 4 倍 token。
Super-agent 单次实验读缓存 2,323 万 token,单会话只要 605 万——前者是后者的 3.84 倍。
这个数字绝对值听着吓人。但换算成钱就完全不一样了:
# What 4x tokens actually costs
def token_cost():
"""
DeepSeek-V4.1-Flash pricing (CNY per million tokens).
Off-peak cache hit: 0.02; peak cache hit: 0.04
Cache miss input: 1.0; output: 4.0
"""
extra_tokens_M = 23.23 - 6.05 # 17.18M extra cached tokens
off_peak = extra_tokens_M * 0.02
peak = extra_tokens_M * 0.04
return {
"extra cached tokens": f"{extra_tokens_M:.2f}M",
"extra cost off-peak": f"{off_peak:.2f} CNY",
"extra cost peak": f"{peak:.2f} CNY",
"verdict": "the 4x token multiplier is cheap ONLY because cache hits cost almost nothing",
}
for k, v in token_cost().items():
print(f" {k:26s} {v}")
多出来的 1,718 万 token,按缓存命中价算,只多花 3 到 7 毛钱。
这就是整件事的经济学核心:Super-agent 的打法,是"缓存够便宜才玩得起"的打法。 它大量重复读取同一批上下文,如果缓存命中和未命中一个价,这套架构立刻破产。而 DeepSeek 的缓存命中价是未命中的 1/50(0.02 元 vs 1 元),才让 4 倍 token 变成"可以忽略的成本”。
换个角度看:这不是一个通用架构,而是一个"对自己家定价高度敏感"的架构。 如果把它搬到缓存很贵的模型上,账立刻算不过来。
结论四:去掉"订阅直通",速度不变但 token 涨 37%。
这个消融很精妙。去掉直通后,完成时间基本一样(12.6 / 15.5,甚至略好一点点,在噪声范围内),但 Router 的决定数增加了约 30%,读缓存 token 从 2,323 万涨到 3,177 万,增幅约 37%。
说明什么?直通不提升速度,但省 token。 因为不走直通,Router 就得反复去"看"有没有新事件,每次看都要把上下文读一遍——轮询的代价是重复读取。
# Polling vs. event direct-pass: why polling costs tokens
def polling_cost(events_per_min=1, poll_interval_s=5, minutes=60, ctx_tokens=15000):
"""
Polling re-reads context every time it checks, even when nothing happened.
"""
polls = minutes * 60 / poll_interval_s
wasted_polls = max(polls - events_per_min * minutes, 0)
wasted_tokens = wasted_polls * ctx_tokens
return {
"polls in an hour": f"{polls:.0f}",
"actual events": f"{events_per_min * minutes}",
"wasted polls": f"{wasted_polls:.0f}",
"wasted tokens": f"{wasted_tokens/1e6:.2f}M",
"direct-pass alternative": "0 wasted polls — Router is pushed only on real events",
}
for k, v in polling_cost().items():
print(f" {k:26s} {v}")
这就是操作系统里"中断 vs 轮询"的老问题,原封不动地出现在了 Agent 架构里。 轮询实现简单,但空转成本高;中断(事件驱动)实现复杂,但只在真有事的时候才唤醒。DeepSeek 选了中断,代价是多 37% 的实现复杂度,收益是省 37% 的 token。
Part Five:Router 越堵越快——批处理的反直觉经济学
第二个实验更反直觉。团队单独压测了 Router 层:Router 调真实模型,Worker 用 mock 模型,把触发速率从每分钟约 1 条提到约 40 条。
# Router batching: more load, cheaper per decision
def router_batching():
return {
"trigger rate (per min)": ["~1", "~40"],
"average batch size": [1.0, 2.8],
"single request latency (s)": [2.5, 3.9],
"per-decision inference time (s)": [6.4, 1.6],
}
data = router_batching()
keys = list(data.keys())
print(f"{'Metric':<34}{'Low load':<14}{'High load':<14}{'Change'}")
print("-" * 76)
for i, k in enumerate(keys):
if i == 0:
print(f"{k:<34}{data[k][0]:<14}{data[k][1]:<14}{'40x'}")
elif i == 3:
print(f"{k:<34}{data[k][0]:<14}{data[k][1]:<14}{'-75%'}")
else:
print(f"{k:<34}{data[k][0]:<14}{data[k][1]:<14}{data[k][1]/data[k][0]:.2f}x")
print("\nKey insight: latency grows 1.56x while batch grows 2.8x —")
print("per-decision cost falls because one inference serves 2.8 decisions.")
这张表最漂亮的地方在最后一行:单个决定分摊的推理时间,从 6.4 秒降到 1.6 秒——降了 75%。
发生了什么?当触发变密,Router 会把积压的消息合并成一批处理:batch 从 1.0 涨到 2.8。而单次请求耗时只从 2.5 秒涨到 3.9 秒(1.56 倍),远慢于 batch 的增长(2.8 倍)。于是"一次推理服务 2.8 个决定",分摊下来每个决定的成本就掉了。
这就是"越堵越快"的经济学:负载上升时,批处理把固定开销摊薄了。 它和数据库的 group commit、GPU 的 batch inference 是同一个道理。
而且这个结论还有个战略含义:在当前团队规模下,不需要过早做水平切分。 因为单个 Router 在 40 条/分钟的负载下还没触及瓶颈,一旦水平切分,就牺牲了"全局上下文连续性"——而这恰恰是双层架构的核心价值之一。
# Should you shard the Router? The tradeoff
def sharding_tradeoff():
return {
"single router": {
"throughput ceiling": "not yet hit at ~40 triggers/min",
"global context": "preserved — sees all events",
"decision quality": "high (full picture)",
"failure mode": "single point of failure (mitigated by watchdog)",
},
"sharded routers": {
"throughput ceiling": "much higher",
"global context": "lost — each shard sees a slice",
"decision quality": "lower (partial picture)",
"failure mode": "cross-shard coordination complexity",
},
"verdict": "at current scale, sharding costs more than it gains",
}
for k, v in sharding_tradeoff().items():
if isinstance(v, dict):
print(f"\n[{k}]")
for kk, vv in v.items():
print(f" {kk:22s}: {vv}")
else:
print(f"\n{k}: {v}")
Part Six:提示词里的那条硬规定,比架构更值得抄
架构未必抄得来(需要改 Harness、改基础设施),但有一件事拿来就能用:原型仓库里的提示词。
DeepSeek 给这套系统定的核心原则是一句话:
“尽可能少占用人的注意力,尽可能多带来价值。”
这句话看着像口号,但它推导出了一整套可执行规则。因为一个能替全团队干活的 AI,也能浪费全团队的注意力——它每多说一句废话,乘以团队人数,就是巨大的损耗。所以提示词花了大段篇幅治"话痨":
# Attention budget: why verbosity is a real cost
def attention_cost(team_size=10, messages_per_day=30, words_per_message=300,
read_speed_wpm=250):
"""
Each agent message costs every team member reading time.
"""
read_min_per_msg = words_per_message / read_speed_wpm
daily_min_per_person = messages_per_day * read_min_per_msg
team_daily_hours = daily_min_per_person * team_size / 60
team_yearly_hours = team_daily_hours * 250
# With the 100-word cap
capped_words = 100
capped_min = capped_words / read_speed_wpm
capped_daily = messages_per_day * capped_min
capped_team_hours = capped_daily * team_size / 60
capped_yearly = capped_team_hours * 250
return {
"verbose (300 words/msg)": f"{team_yearly_hours:.0f} person-hours/year",
"capped (100 words/msg)": f"{capped_yearly:.0f} person-hours/year",
"saved": f"{team_yearly_hours - capped_yearly:.0f} person-hours/year",
}
for k, v in attention_cost().items():
print(f" {k:28s} {v}")
这个估算当然是示意,但它揭示了"话痨成本"的量级:一个十人团队,如果 Agent 每天发 30 条 300 字的消息,一年就是几百人时的阅读成本。 而把每条压到 100 字以内,能省掉三分之二。
更关键的是执行方式:
# Prompt rule vs. infrastructure rule
def enforcement_comparison():
return {
"prompt-level rule": {
"example": "please keep replies under 100 words",
"enforcement": "model may ignore, especially under long context",
"failure mode": "silent — nobody notices until it's habitual",
"reliability": "low",
},
"infrastructure-level rule": {
"example": "channel rejects messages longer than 100 words",
"enforcement": "mechanically guaranteed",
"failure mode": "loud — send fails, visible immediately",
"reliability": "high",
},
}
for level, d in enforcement_comparison().items():
print(f"\n[{level}]")
for k, v in d.items():
print(f" {k:16s}: {v}")
“通道直接拒收"这五个字,是整个提示词设计里最有工程味的一笔。 它把"规范"从"希望模型遵守"变成了"违反就无法发出”。做 Agent 的人都懂:提示词是软约束,通道是硬约束。 能做成硬约束的,就不要留在软约束里。
还有两条行为规则值得记下来:
- 只在需要决策或验收时说话,不汇报过程;
- 提问一次只问一个,不甩一串问题给人。
第二条尤其重要。因为"一次问五个问题"看似高效,实际上让人无法快速回应——人会因为不知道从哪答起而干脆不答。
Part Seven:4分钱修一个 bug——实测成本账
回到最开始的实测。这位开发者记录的 token 消耗如下(闲时价格):
# Real-world measured costs from a hands-on test
def measured_costs():
return [
("installation", "10 min", 0.14),
("fix README typo", "2 min", 0.04),
("fix button typo + before/after screenshots", "6 min", 0.21),
("fix a small bug", "7 min", 0.18),
("cannot reproduce, silently gives up", "5 min", 0.12),
]
print(f"{'Task':<44}{'Time':<10}{'Cost (CNY)'}")
print("-" * 66)
total_time = 0
total_cost = 0
for task, t, c in measured_costs():
print(f"{task:<44}{t:<10}{c}")
total_cost += c
print("-" * 66)
print(f"{'TOTAL':<44}{'30 min':<10}{total_cost:.2f}")
print("\nPer-task average:", f"{total_cost/5:.2f} CNY")
五次交互,总共花了 0.69 元。 修一个真实 Bug(7 分钟,含定位、修改、跑测试)花 0.18 元。
这个价格意味着什么?
# What does 0.18 CNY per bug fix mean economically?
def economics(fix_cost_cny=0.18, engineer_hourly_cny=200):
"""
Compare agent cost against engineer time, for a trivial bug.
"""
# A trivial bug: engineer takes ~15 min including context switching
engineer_min = 15
engineer_cost = engineer_hourly_cny * engineer_min / 60
return {
"agent cost per fix": f"{fix_cost_cny:.2f} CNY",
"engineer cost per fix": f"{engineer_cost:.2f} CNY",
"cost ratio": f"{engineer_cost/fix_cost_cny:.0f}x cheaper",
"caveat": "only holds for bugs the agent can actually fix",
}
for k, v in economics().items():
print(f" {k:24s} {v}")
但这里必须加一个非常重的限定:0.18 元只在"Agent 能修对"的时候成立。
实测里有一个细节特别值得注意——“复现不了,静默放弃”,5 分钟,0.12 元。 这条比修好一个 Bug 更有价值,因为它说明系统有成本上限意识:试了、复现不了、就不吭声地放弃,而不是硬着头皮瞎改。
# The value of giving up: expected cost with and without a stop condition
def giveup_value(p_reproducible=0.6, cost_try=0.12, cost_thrash=2.50,
p_bad_fix_if_thrash=0.35, cost_bad_fix=15.0):
"""
Without a stop condition, the agent keeps trying and may submit a wrong fix.
"""
# With stop condition
expected_with = cost_try + (1 - p_reproducible) * 0
# Without stop condition: keeps thrashing, may produce a bad PR
expected_without = (
cost_try
+ (1 - p_reproducible) * cost_thrash
+ (1 - p_reproducible) * p_bad_fix_if_thrash * cost_bad_fix
)
return {
"expected cost with stop condition": f"{expected_with:.2f} CNY",
"expected cost without": f"{expected_without:.2f} CNY",
"saved": f"{expected_without - expected_with:.2f} CNY",
"bigger point": "a wrong PR costs far more than the tokens saved by trying harder",
}
for k, v in giveup_value().items():
print(f" {k:38s} {v}")
“会放弃"是 Agent 最被低估的能力。 一个不停尝试的 Agent,最终会给你一个错误的 PR——而审一个错 PR 的成本(15 元级别的人工时间),是 token 成本(0.1 元级别)的上百倍。所以设置一个"试过就停"的边界,比让模型再努力一点更值钱。
而且注意:“复现不了就不吭声"这个行为,恰好呼应了前面那条提示词原则——尽可能少占用人的注意力。它不来说"我没复现出来,你能提供更多信息吗”,因为它知道这句话本身就在消耗你的注意力,而且大概率没有用。
三个容易被忽略的工程细节
在动手写自己的常驻 Agent 之前,还有三个细节值得单独拎出来,它们不属于架构层,但直接决定这套东西能不能真的跑起来。
第一,工单之间必须有物理隔离,不能只有逻辑隔离。 原型里每个工单都有独立的目录和分支,这条看着啰嗦,实际上是防事故的关键。如果三个工单共用同一个工作目录,两个并发修改同一个文件,就会出现互相覆盖、分支错乱、提交内容混杂的情况——而且这种错误在运行时不报错,只在最后合并时才炸出来。用目录和分支做隔离,等于用文件系统这个最古老、最可靠的机制兜住并发安全,比在应用层写一堆锁简单得多,也稳得多。
第二,被叫停的任务不该被重提。 原型里有一个很值得玩味的行为:如果一个任务被用户主动停掉,之后用完全相同的文字再提一次,它不会接。理由写得很直白——那等于把用户明确叫停的活又干一遍。这个设计背后是对"自主"的克制理解:自主不等于自作主张。一个真正好用的 Agent,应该能分清"用户忘了"和"用户不想要了”,而这两者在文本上看起来完全一样,所以只能靠"停过就不再主动重提"这条硬规则来兜底。
第三,只支持一个仓库是个优势而不是缺陷。 早期把范围压到最小,能逼出真正的设计问题。如果一开始就支持多仓库、多平台、多语言,那大部分精力会花在适配层上,而架构本身的毛病——上下文污染、长尾、token 爆炸——反而会被掩盖。原型阶段最大的价值不是覆盖面,而是让结构性问题尽早暴露。 这也解释了为什么 0.1.0 版本明明能做更多,却故意只做了一件事。
这三个细节合起来说明一件事:这套系统真正的功夫不在模型调用上,而在"边界"上。 目录边界、分支边界、行为边界、平台边界——每一条都在用工程手段替代"希望模型自觉"。而这恰恰是过去两年 Agent 产品最容易忽略的地方:大家都在卷模型能力,很少有人认真卷约束设计。
Part Eight:判断与边界
第一,这个原型的真正贡献不是"又一个 Coding Agent",而是把系统工程的思路正式搬进 Agent 架构。 调度(双层)、缓存(存算分离)、中断(事件直通)、看门狗(外部自检)、批处理(Router 合并)——这五个概念在操作系统里都几十岁了,但组合进 Agent 还是新事。它暗示了一个方向:Agent 的性能提升,未来可能更多来自架构而非模型。
第二,p95 从 29.5 到 15.7 这个数字,比 p50 重要得多。 因为生产环境里没人在意平均值,大家都在意长尾。而长尾的成因是"被新消息打断",这不是模型能力问题,是会话结构问题。这也解释了为什么改提示词只能改善 p50、改不动 p95——提示词改的是行为倾向,改不了结构约束。
第三,4 倍 token 这个代价,不能脱离定价来谈。 缓存命中 0.02 元/百万 vs 未命中 1 元/百万,差 50 倍。Super-agent 这套架构是"为缓存便宜的世界设计的"。 如果把它搬到缓存昂贵的模型上,4 倍 token 立刻从"3 毛钱"变成"十几块",经济性完全翻转。所以抄架构之前,先看自己家的缓存价。
第四,“通道拒收"这个做法值得所有做 Agent 的人抄。 把关键规范从提示词下沉到基础设施,是提高可靠性的最有效手段之一。凡是"模型经常不遵守"的规则,都该问一句:能不能做成硬约束?
第五,也是最需要清醒的一点:这仍然是个研究原型,而且实验基于合成负载。 团队自己写得很清楚:“实验基于合成负载和简化环境,只作初步参考。“300 条消息、20 个请求、5 次重复,这个样本量足以说明方向,不足以证明结论。而且它只支持一个 GitHub 仓库、只支持 GitHub(不支持 GitLab/Gitee)、面板只有中英文、版本 0.1.0。
一个可跟踪的框架:评估这类"常驻 Agent"时,看五个数——① p95 而不只是 p50(长尾决定可用性);② 每任务的 token 成本(不是总量,是分摊到单个任务);③ 缓存命中率(这决定 4 倍 token 是灾难还是零头);④ 无效动作率(试了但没结果的占比,这直接烧钱);⑤ 人工介入频次(这是"自主"的真实刻度)。 这五个数里,前四个官方都给了方向性数据,第五个——人工介入频次——没给,而这恰恰是"自主"最核心的那个指标。
来源:DeepSeek Harness 团队《Super-agent 设计探索:迈向更自主的 Agent 系统》(2026-10-31);GitHub
deepseek-ai/dsh-superagent-prototype(MIT,v0.1.0,README / SETUP.md / docs 000–006);智东西《deepseek又开源了!公布super agent架构》(2026-11-01);新浪财经《刚刚,DeepSeek开源「超级智能体」!这 AI 牛马,没人 @ 都自己干活》(2026-11-01)、《DeepSeek「超级智能体」,我真养上了!》(2026-11-02);AInformation《DeepSeek、GitHubを見張るAIを0円公開》(2026-11-02)。文中的上下文污染模型、轮询成本、注意力成本、放弃价值等均为基于公开信息的推演与示意,非官方数据;官方明确说明实验基于合成负载与简化环境,仅作初步参考。