It Works Without Being @-Mentioned: DeepSeek Moved Scheduling, Caching, and Watchdogs into the Agent — Trading 4x Tokens for Half the Completion Time
It Works Without Being @-Mentioned: DeepSeek Moved Scheduling, Caching, and Watchdogs into the Agent — Trading 4x Tokens for Half the Completion Time
Part One: What Was Open-Sourced on October 31 Is Not the Agent You’re Used To
On the evening of October 31, 2026, the DeepSeek Harness team published a long post on their exploration of “autonomous agents” and open-sourced the prototype code under MIT: deepseek-ai/dsh-superagent-prototype.
Super-agent, in one sentence: a coding agent that lives online permanently, works without being @-mentioned, advances multiple tasks in parallel, and recovers by itself when things break.
Its mode of operation: watch a GitHub repository (optionally connect a Feishu group); when someone complains about a bug in an Issue or mentions a need in chat, it opens its own ticket, works in an isolated session and directory, and delivers back to the original conversation — usually a Pull Request.
One measured detail captures the state of things well:
Filed an Issue on GitHub without @-mentioning anyone. 49 seconds later Super-agent replied automatically; within 2 minutes a PR landed, one line changed, CI passed. The whole operation cost 4 fen (about half a US cent).
There are more autonomous cases: when a tilde in model output got rendered as strikethrough, and the group was still arguing whether to fix it in training or in the rendering rules, the PR was already submitted; for a double-click misfire bug, it diagnosed the cause and attached before/after screenshots.
But the boundary must be stated up front: DeepSeek explicitly says this is a research prototype, not a product. It watches a single GitHub repository, doesn’t support GitLab/Gitee, its admin panel is Chinese and English only, version 0.1.0. As of November 1 the repo had roughly 2,800 stars.
So why is this worth dissecting carefully? Because the problem it solves isn’t “models aren’t strong enough” — it’s “human attention isn’t enough.”
Part Two: Why It Had to Split Into Two Layers — A Person With 10 Windows Open
The team’s starting point was a very concrete observation:
“I usually have about 10 agent terminal windows open. Once they’re actually running simultaneously, I can’t manage more than about 4.”
The bottleneck isn’t compute — it’s people. As models work continuously for longer, “how many sessions must a human switch between” becomes the new ceiling. You open 10 windows: the 5th is waiting for your confirmation, the 7th threw an error, the 9th finished but you haven’t looked — your attention has become the system’s throughput bottleneck.
DeepSeek’s answer was to move decades-old computer systems ideas into the agent: scheduling, caching, storage-compute separation, watchdog. Concretely, two layers:
┌─────────────────────────────────────────┐
│ 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 │
└─────────────────────────────────────────┘
The Router is the foreman; the Workers do the work. Three things make this split work:
First, the Router never touches concrete tasks. It only reads messages, judges whether something is worth doing and whether the requester has permission, then dispatches. Because it never touches tasks, its context stays short, so a lightweight model suffices — while Workers get the strongest model. This “light Router, heavy Worker” configuration directly compresses cost.
Second, every Worker has its own context and directory. That’s the basis for “parallel without switching sessions.” Three tickets run simultaneously, each in its own directory and branch, mutually undisturbed. In the measured test the panel showed “running 3/3” — default concurrency is three.
Third, context isolation solves pollution. In a single-session scheme, you’re on task A when a message for task B arrives; the two contexts blend and the model gets confused. In the two-layer architecture, B goes to a different Worker and A’s context is untouched.
# 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}")
This explains a counterintuitive phenomenon: total token consumption is higher in the two-layer design (4x, as we’ll see), yet each Worker’s context is “cleaner.” The accuracy gain from a clean context may be worth more than the tokens saved.
Part Three: Five Modules, Each Borrowed from an Operating System
DeepSeek says plainly that the design’s logic is to “move classic computer systems ideas — scheduling, caching, storage-compute separation, watchdogs — into agent architecture.” One by one:
① Two-layer architecture (covered above) — corresponds to OS process scheduling.
② Event-driven plus subscription direct-pass — corresponds to interrupt handling. The Router doesn’t poll; new events are pushed to it. That “direct-pass” matters a lot — the data later shows it saves 37% of tokens.
③ Asynchronous multi-channel interaction — corresponds to different I/O channels. The same agent must be short in group chat and long in a 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}")
Behind this design sits a clear-eyed judgment: transplanting a single-user-terminal interaction style directly into a group chat — dumping verbose reasoning and dense tool calls verbatim — is an information disaster in multi-person collaboration. So Super-agent locks all verbose reasoning inside Worker sessions, and only the Router speaks externally, under the rule that “a single reply must not exceed 100 words; the sending channel rejects anything longer.”
Note the wording: not “we recommend under 100 words,” but “the channel rejects.” This is a very effective engineering move — put the rule in the infrastructure, not the prompt. Prompts get ignored by models; channels don’t.
④ Storage-compute separation — corresponds to virtual memory. Agent state (context, memory) and execution (inference, tool calls) are managed separately, so multiple Workers can share underlying state without each copying it.
⑤ External watchdog — corresponds to the hardware watchdog timer. Installation automatically creates an hourly self-check job that restarts the service if it dies. This detail looks trivial but is the precondition for “7×24 resident” — a resident agent without a watchdog is just a script that happens to run for a long time.
Part Four: The Data — Trading 4x Tokens for Half the Completion Time
Now the hardest part: the official ablation experiment.
Setup: driven by group-chat and GitHub CI message streams, about 300 messages per run with about 20 work requests; coding work replaced by a latency-only tool (to avoid real code quality interfering); each scheme run 5 times.
# 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")
Four conclusions come out, each worth stating separately.
Conclusion one: p95 drops from 29.5 to 15.7 minutes — nearly halved.
That’s the most direct payoff of the two-layer design. Why is single-session p95 so bad? Because a single session gets interrupted constantly by new messages — you’re on A, B’s message arrives, the model has to re-understand B and possibly respond, and A is shelved. Of 300 messages only 20 are work requests; the other 280 are interference. The essential problem with single-session: all interference acts on the same context.
Conclusion two: changing the prompt doesn’t fix it.
A “delegation-first” prompt moved single-session p50 from 20.4 to 13.8 — looks like it caught up. But p95 only went from 29.5 to 29.0, essentially unchanged.
Why? Because the tail isn’t determined by “willingness to delegate” but by “whether the architecture permits parallelism.” Under the neutral prompt, 5 out of 5 runs never called the Subagent at all — everything ran in the main session, p95 hit 29.5. With delegation-first, 4 of 5 delegated, but the remaining one judged the work “small” and did it itself, re-forming the tail.
This is a highly instructive data point for anyone building agents: prompts improve the mean, not the tail. The tail requires architecture.
# 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()
Conclusion three: the price is 4x tokens.
Super-agent reads 23.23 million cached tokens per experiment; single-session needs only 6.05 million — the former is 3.84x the latter.
That absolute number sounds alarming. But converted to money it looks completely different:
# 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}")
The extra 17.18 million tokens, priced at cache-hit rates, cost only 0.3 to 0.7 yuan.
That’s the economic core of the whole thing: Super-agent’s approach is one that only works if caching is cheap. It repeatedly reads the same context. If cache hits cost the same as misses, this architecture goes bankrupt immediately. DeepSeek’s cache-hit price is 1/50 of the miss price (0.02 vs 1.0 yuan), which is what turns 4x tokens into a “negligible cost.”
Seen from another angle: this isn’t a universal architecture — it’s one highly sensitive to its own vendor’s pricing. Port it to a model with expensive caching and the math collapses.
Conclusion four: removing the direct-pass keeps speed but raises tokens 37%.
This ablation is elegant. Without direct-pass, completion time is basically unchanged (12.6 / 15.5, marginally better within noise), but the Router’s decision count rises about 30%, and read-cached tokens go from 23.23M to 31.77M — up about 37%.
What does that tell us? Direct-pass doesn’t improve speed; it saves tokens. Without it, the Router has to repeatedly “check” for new events, and every check re-reads context — the price of polling is redundant reads.
# 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}")
This is the old OS question of “interrupt vs. poll,” reappearing verbatim in agent architecture. Polling is simple to implement but wastes cycles when idle; interrupts (event-driven) are more complex but wake only when something real happens. DeepSeek chose interrupts: 37% more implementation complexity for 37% fewer tokens.
Part Five: The Router Gets Faster as It Gets Busier — the Counterintuitive Economics of Batching
The second experiment is even more counterintuitive. The team load-tested the Router layer alone: Router on a real model, Workers on mock models, raising trigger rate from about 1 per minute to about 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.")
The prettiest line in this table is the last: per-decision inference time drops from 6.4 seconds to 1.6 — a 75% reduction.
What happened? When triggers get dense, the Router merges backlogged messages into a batch: batch size goes from 1.0 to 2.8. But single-request latency only rises from 2.5 to 3.9 seconds (1.56x) — far slower than the batch growth (2.8x). So one inference serves 2.8 decisions, and the amortized cost per decision falls.
That’s the economics of “busier means faster”: under rising load, batching amortizes fixed overhead. It’s the same principle as database group commit and GPU batch inference.
And there’s a strategic implication: at current team scale, premature horizontal sharding isn’t needed. A single Router hasn’t hit its ceiling at 40 triggers per minute, and sharding would sacrifice “global context continuity” — which is one of the core values of the two-layer design.
# 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: The Hard Rule in the Prompt Is More Worth Copying Than the Architecture
The architecture may not be copyable (it requires changing the Harness and the infrastructure), but one thing is usable as-is: the prompts in the prototype repo.
DeepSeek’s stated core principle for the system is one sentence:
“Occupy as little of a human’s attention as possible; deliver as much value as possible.”
It reads like a slogan, but it derives a whole set of executable rules. Because an AI that can work for the entire team can also waste the entire team’s attention — every extra sentence it says, multiplied by team size, is enormous loss. So the prompts spend a lot of space curing verbosity:
# 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}")
The estimate is illustrative, but it reveals the order of magnitude of “verbosity cost”: a ten-person team, if the agent sends 30 messages of 300 words daily, spends hundreds of person-hours a year just reading. Capping each at 100 words saves two thirds.
More important is how the rule is enforced:
# 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}")
Those five words — “the channel rejects it” — are the most engineering-flavored stroke in the whole prompt design. They turn “specification” from “hope the model complies” into “violation means it cannot be sent.” Anyone building agents knows: prompts are soft constraints; channels are hard constraints. Anything that can be made a hard constraint shouldn’t be left soft.
Two more behavioral rules are worth noting:
- Speak only when a decision or acceptance is needed — don’t narrate the process;
- Ask one question at a time — don’t dump a string of questions on a person.
The second matters especially. “Asking five questions at once” looks efficient but makes it impossible to respond quickly — people simply don’t answer when they don’t know where to start.
Part Seven: 4 Fen per Bug Fix — the Measured Cost Ledger
Back to the opening hands-on test. The developer recorded these token costs (off-peak pricing):
# 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")
Five interactions, 0.69 yuan total. Fixing a real bug (7 minutes including locating, editing, and testing) cost 0.18 yuan.
What does that price mean?
# 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}")
But a very heavy qualifier is required: 0.18 yuan only holds when the agent actually fixes it correctly.
One detail in the test deserves special attention — “cannot reproduce, silently gives up,” 5 minutes, 0.12 yuan. That entry is more valuable than a successful fix, because it shows the system has cost-ceiling awareness: it tried, couldn’t reproduce, and quietly gave up rather than stubbornly hacking away.
# 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}")
“Knowing when to give up” is the most underrated agent capability. An agent that never stops will eventually hand you a wrong PR — and reviewing a bad PR (human time at the 15-yuan level) costs a hundred times the token cost (0.1-yuan level). So setting a “try, then stop” boundary is worth more than making the model try harder.
And note: “silently gives up when it can’t reproduce” echoes that earlier prompt principle — occupy as little human attention as possible. It doesn’t come say “I couldn’t reproduce this, can you provide more info,” because it knows that sentence itself consumes your attention and most likely won’t help.
Three Engineering Details That Get Overlooked
Before building your own resident agent, three details deserve separate mention. They aren’t architecture, but they decide whether the thing actually runs.
First, tickets need physical isolation, not just logical isolation. Every ticket in the prototype gets its own directory and branch. That sounds fussy; in fact it’s the key anti-incident measure. If three tickets share one working directory, two concurrent edits to the same file overwrite each other, branches tangle, and commits get mixed — and none of it errors at runtime; it explodes only at merge time. Directory and branch isolation lets the filesystem — the oldest, most reliable mechanism there is — absorb concurrency safety, which is far simpler and steadier than writing locks in the application layer.
Second, a stopped task shouldn’t be re-accepted. The prototype has a telling behavior: if a task is explicitly stopped by the user, submitting the exact same text again won’t be picked up. The stated reason is blunt — that would mean doing work the user explicitly called off, all over again. Behind it sits a restrained understanding of autonomy: autonomous does not mean presumptuous. A genuinely usable agent should distinguish “the user forgot” from “the user doesn’t want this,” and since the two look textually identical, the only recourse is a hard rule: once stopped, don’t proactively revive.
Third, supporting only one repository is a strength, not a gap. Compressing scope to the minimum early forces the real design problems out. Start with multi-repo, multi-platform, multi-language support and most of the energy goes into adapter layers, while architecture-level flaws — context pollution, tail latency, token explosion — get masked. The greatest value of a prototype phase isn’t coverage; it’s making structural problems surface early. Which explains why version 0.1.0 deliberately does one thing despite being capable of more.
Together these three details make one point: the real craft in this system isn’t in model invocation — it’s in boundaries. Directory boundaries, branch boundaries, behavioral boundaries, platform boundaries — every one replaces “hope the model behaves” with an engineering mechanism. And that’s exactly what agent products have most neglected over the past two years: everyone competes on model capability; few compete seriously on constraint design.
Part Eight: Judgment and Boundaries
First, the real contribution isn’t “another coding agent” but formally importing systems engineering into agent architecture. Scheduling (two layers), caching (storage-compute separation), interrupts (event direct-pass), watchdog (external self-check), batching (Router merging) — these five concepts are decades old in operating systems, but combining them inside an agent is new. It hints at a direction: future agent performance gains may come more from architecture than from models.
Second, the p95 number from 29.5 to 15.7 matters far more than p50. In production nobody cares about the average; everyone cares about the tail. And the tail’s cause is “being interrupted by new messages,” which isn’t a model capability problem but a session structure problem. That’s why prompt changes move p50 but not p95 — prompts change behavioral tendency; they can’t change structural constraint.
Third, the 4x token cost cannot be discussed apart from pricing. Cache hit at 0.02 yuan per million vs. miss at 1.0 — a 50x gap. Super-agent’s architecture is designed for a world where caching is cheap. Port it to a model with expensive caching and 4x tokens immediately goes from “0.3 yuan” to “a dozen yuan,” and the economics flip completely. So before copying the architecture, check your own cache pricing.
Fourth, “the channel rejects it” is a practice every agent builder should copy. Pushing key specifications from prompts down into infrastructure is one of the most effective reliability levers. For any rule “the model often doesn’t follow,” ask: can this be made a hard constraint?
Fifth, and most needing sobriety: this is still a research prototype, and the experiments are on synthetic load. The team says it plainly: “the experiments are based on synthetic load and a simplified environment, for preliminary reference only.” 300 messages, 20 requests, 5 repetitions — enough to indicate direction, not enough to prove conclusions. And it supports only one GitHub repository, only GitHub (no GitLab/Gitee), a Chinese/English-only panel, version 0.1.0.
A trackable framework: when evaluating this class of “resident agent,” look at five numbers — ① p95, not just p50 (the tail determines usability); ② token cost per task (not the total, but amortized per task); ③ cache hit rate (this decides whether 4x tokens is a disaster or a rounding error); ④ wasted-action rate (the share of attempts that produce nothing — this burns money directly); ⑤ human intervention frequency (the real scale of “autonomy”). Of those five, the first four have directional data from the official post; the fifth — human intervention frequency — was not given, and that is precisely the most core indicator of “autonomy.”
Sources: DeepSeek Harness team, “Super-agent Design Exploration: Toward a More Autonomous Agent System” (2026-10-31); GitHub
deepseek-ai/dsh-superagent-prototype(MIT, v0.1.0, README / SETUP.md / docs 000–006); Zhidongxi, “DeepSeek Open-Sources Again: Super-agent Architecture Revealed” (2026-11-01); Sina Finance, “DeepSeek Open-Sources Its ‘Super Agent’ — This AI Works Without Being @-Mentioned” (2026-11-01) and “I Actually Raised a DeepSeek Super Agent” (2026-11-02); AInformation, “DeepSeek Open-Sources a GitHub-Watching AI for Free” (2026-11-02). The context-pollution model, polling cost, attention cost, and give-up value calculations are inference and illustration based on public information, not official data; the team explicitly states the experiments used synthetic load and a simplified environment and are for preliminary reference only.