当Agent 能同时干活，谁来守住人的注意力

本文来自微信公众号： DARE to B2B ，作者：申飞 Dare，原文标题：《当 Agent 能同时干活，谁来守住人的注意力》设想一个研发团队的工作日：群聊里有人报了问题，一条Pull Request收到评审意见，另有一项任务等着验收。

每件事单独交给Agent，未必困难。难的是人要记住各自走到哪一步、哪条新消息属于哪项任务、什么时候需要自己出面。DeepSeek Harness团队在《Super-agent设计探索》和随文开源的研究原型中，直指问题卡点：单任务的上限更多取决于模型，多任务的上限会碰到人的注意力。

他们尝试让系统接管任务分派、上下文衔接和异常恢复，使人不用一直守着多个对话窗口。我更关心其中的边界：何时接手、做到哪一步、何时安静等待、何时请人拍板。这些事若说不清，Agent越主动，人越要替它收拾乱动和串线。

原文把工作分给两层：常驻的Router接收来自聊天、GitHub等渠道的信息，维持任务之间的关联，并把具体工作交给彼此隔离的Worker。Worker处理任务，再向Router汇报；

对外沟通由Router统一负责。这解决了一个很实际的麻烦。如果所有任务挤在一个会话里，长任务会挡住新消息，细节也容易串线。如果每条消息都新开会话，人又得自己把背景重新拼起来。Router／Worker的分工把这两种负担从使用者手里接过去。

它也意味着Router的职责必须克制：它若亲自下场处理每个任务，就会重新成为队列里最慢的那个人。新消息也不必全由Router从头重判。群聊消息、代码评审、CI结果等外部事件进来后，系统先按来源和授权规则筛掉明显不该处理的噪声，再让模型判断需要语义理解的候选；

已经归属某项任务的后续消息，则顺着订阅关系直接送给对应Worker，省去Router反复分拣同一条任务线的开销。随文开源的原型（dsh-superagent-prototype，阅读原文访问对应的GitHub仓库）把这条链路落成了具体步骤：外部渠道收到事件后，先评估是否建立工作项，再带着授权范围交给执行器。

不过原型目前的覆盖面还很有限，围绕单个GitHub仓库运转，飞书只是可选接入来源；仓库说明也直言，公开版本与团队内部版本及文章描述并不一致，文中提到的部分方向尚未实现。看这套设计时，需要把架构蓝图和现成可用的代码分开。

持续监听环境，容易被讲成“没人吩咐也会干活”。可在企业里，主动性先是一道授权题：谁的消息可以启动任务？群聊里的讨论算请求，还是背景？一条评论能让Agent修改代码，是否也能让它对外发消息？

原型的设计原则给出了一个克制的做法：只有有人明确请求，或团队写下允许主动行动的规则，系统才开始工作；没人需要决策或使用结果时，保持安静。每个工作项都会记录授权依据与范围，新增的主动规则也要求先在“只记录本该做什么、不实际动手”的观察模式下试跑。

团队若要让Agent长期接入真实工作流，先得看这些约束能不能管住手——自动提交PR固然省事，但一条未经授权的PR同样会消耗评审时间，甚至把错误带进共享仓库。一旦Agent横跨群聊、代码平台和本地电脑工作，账单之外的代价会迅速显露：误报提醒消耗同事注意力，错误分派让两条工作线互相干扰，而执行环境里直接放着代码、凭据和权限。

原文承认，云端Agent接入端侧设备后，提示词注入、凭据泄露和跨设备控制仍是开放问题。原型部署文档也专门提示，其执行预设拥有操作系统用户级的广泛访问能力，仅靠系统账户包装并不能实现进程隔离。

试用范围、运行账户和可接触的资料，必须在部署前就划定。状态和授权，不能只留在会话记忆里我自己的工作流里，Grok Bot下的主机器人——feibot负责总编排，Codex等执行端承接具体任务；

跨任务交接会留下任务卡、必要背景、当前状态和剩余审批。这样做的原因很朴素：换一个会话继续干活时，我不想靠翻长聊天记录，才弄清稿件是草稿、已审核，还是已经发布。尤其发布和外部发送，必须单独辨认授权，不能从“已经写完”推断出来。

这与原文强调的全局协调、执行隔离和显式状态有相通之处，但不是同一套Super-agent实现。我没有把所有入口统一成持续在线的Router，也没有证明这套做法能把任务耗时缩短多少。

它给我的直接教训是：任务可以交给多个Agent，状态和授权却不能只留在某个Agent的记忆里。否则，人只是从亲自干活，变成替一群会话补背景。对企业来说，这个对照比“部署一个更自主的Agent”更有用。

先选一条任务流，例如从问题反馈到修复PR，写清谁能发起、哪些事件可自动续办、什么动作必须由人验收。再记录三件事：人被打断了多少次，任务从请求到可验收结果用了多久，误触发和返工发生在哪里。

没有这些记录，所谓减少注意力消耗仍是设计目标，不是已发生的经营结果。实验支持了什么原文给出了一组初步对照：合成消息流中，每次约300条消息、约20条工作请求，各方案重复5次。编码工作由耗时工具替代，测的是调度与协作，不是实际写代码的质量。

Super-agent方案报告的任务完成时间为p50 12.4分钟、p95 15.7分钟；中性提示下的单会话加Subagent方案，长尾等待被拉长到p95 29.5分钟。这个结果说明，在给定负载与提示设置下，系统级分工比指望主会话临场决定是否委派更稳定；

但它尚不足以推出真实团队会获得同幅度收益。文章还发现，在这组负载下，去掉已订阅事件的直通机制，任务完成时间基本相近，但Router需要多做约30%的决定，总读缓存token从2323万增至3177万。

这组结果显示，事件直通省下了路由决策和上下文读取开销；完成时间没有明显变化，真实编码质量则不在实验测量范围内。更长期的记忆、更多任务下Router如何扩展，以及不同权限边界的Agent如何协作，也都还待检验。

我会把这次开源看作一份可拆解的工程样本，而不是采购清单。真要在团队里试，先从一个仓库、一类明确请求、一组可撤回的授权开始。只有当系统能少问无效问题、持续交出可验收结果，同时没有把权限和噪音成本转嫁给人，人的注意力才算真正被还回来。

资料：DeepSeek Harness团队《Super-agent设计探索》；deepseek-ai/dsh-superagent-prototype。实验数据与原型说明均以原始材料为准。