没人@它也干活: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)。文中的上下文污染模型、轮询成本、注意力成本、放弃价值等均为基于公开信息的推演与示意,非官方数据;官方明确说明实验基于合成负载与简化环境,仅作初步参考。