Agent 真正的瓶颈，是你同时只能盯 3 到 5 个会话

开发者 Rohit 在 DeepSeek Harness（下称 DSH）的 super agent 源码里泡了两天，写了一串笔记。他开头那句判断值得单独拎出来：如果你在造 Agent，限制你的早就不是模型能想多深，是你不行。一个人同时能跟住的活跃会话，大概 3 到 5 个。超过这个数，上下文就开始互相污染，人肉切换的成本比模型推理还高。

DSH 官方那篇架构长文把这件事说透了：多任务处理的瓶颈在人，不在模型。所以他们把会话从产品层拆掉，塞进系统内部当实现细节。用户面对一个连续的 Agent，底下几个 Worker 并行跑，互不干扰。

Rohit 的笔记基本是在验证这套拆法，他总结了 5 条可以直接拿走的东西，每条都有具体做法。

路由和执行分开

一个 Router 层只跟人打交道，派活。每份活分给一个 Worker，Worker 带自己的上下文，工具齐全，但从不直接对外说话。Worker 的推理过程和工具调用记录留在内部，由 Router 统一回人。

这解决的是老架构里最别扭的地方：单会话跑 ReAct，一步做完才能走下一步，中途来了新消息只能排队。DSH 的数据是，单会话设计在模拟工作流里 p95 完成时间 29.5 分钟，Super-agent 架构压到 15.7 分钟。中间差的不全是模型速度，主要是调度方式。

在代码层过滤事件

事件进来先过确定性规则：来源、发送方、权限、白名单。大部分噪音在这一层就死掉，根本到不了模型。只有过了初筛的候选事件才进 LLM 做语义判断。

Rohit 的建议是先跑 observe 模式，看规则会拦下什么、放行什么，确认没问题再让它真动手。这个做法跟 DSH 的 Fast Path / Slow Path 是同一套思路：能用代码判的绝不问模型，省 token 也省延迟。

给每份活开一张 ticket

记录两件事：这份活是谁授权的，能走到哪一步。同一个触发重放一次，还是只出一张 ticket，不会重复开工。

评论区有人追问 ticket 模型对多步人工审批靠不靠谱。Rohit 的回复挺诚实：等待那部分能扛，门控那部分还不行。ticket 能跨重启活着，被卡住的 Worker 问一个具体问题，回答能路由回同一个 Worker。但审批目前是写在 prompt 里的，不是代码强制的。要多步审批，得往 ticket 上加显式的 gate 状态（计划已批、变更已批、部署已批），宿主在状态没齐时拒绝推进。

这段话比他那 5 条总结更值得留意。Agent 系统的可靠性短板，经常不在能力，在约束。

follow-up 直接送 Worker

PR 评论、审批结果、CI 回执，这些后续事件不需要再过一遍 Router。同一个 Thread 里的连续事件，直接透传给已经订阅它的 Worker。Router 只在冷启动和跨任务协调时出场。

DSH 的实验数据是，去掉这个直通机制，Router 每轮多做约 30% 的决策，cache-read tokens 从 23.2M 涨到 31.8M，多 37%。任务完成时间没明显变化。也就是说，直通不是为了更快，是为了让 Router 别被重复劳动拖死。

为崩溃而设计

发出的回复先存再发。重试时能查到那条已经发出去的 GitHub 评论，重启的 Worker 能捡起同一个工作区继续。

这一条听起来最不性感，但恰好是长时任务和非长时任务的分水岭。Agent 跑几分钟和在后台跑几天，工程要求的量级完全不同。

护城河的位置变了

评论区有人丢了一句：harness 的护城河已经死了。Rohit 接得干脆：内循环那层确实死了，opencode、pi、codex 都开源而且够好。护城河上移了，移到了授权、ticket、恢复，以及知道什么时候闭嘴。

这个判断有它的道理。模型能力在涨，脚手架在开源，剩下真正难做的，是怎么让一个持续在线的系统在人不在的时候不乱动、在人回来的时候说得清楚它干了什么。DSH 那篇长文里反复出现的 Watchdog、权限边界、上下文颗粒度，都是这个方向上的活。

Rohit 最后补了一句，各家应该按自己的场景造自己的 harness，别指望 Claude Code 这类产品替你留口子。这话不算新鲜，但从一个花两天读别人源码的人嘴里说出来，分量不太一样。

参考来源：Rohit 的推文串（@rohit4verse）、DeepSeek Harness 的架构文章《Exploring Super-agent Design》，以及评论区的公开讨论。