精华速览

DeepSeek Harness 团队发布架构长文，介绍其“永远在线”Agent 的设计思路。团队指出，现有 Agent 多以单个 Session 为单位且彼此独立，而一个人通常只能同时跟进 3 到 5 个活跃 Session，因此多任务处理的上限受限于人的注意力，而非模型能力。为此，团队将 Agent 设计成类似操作系统的结构，让多个任务在统一调度下持续运行，减少对人工切换和盯守的依赖。文章的核心结论是：单任务表现取决于模型能力，多任务规模则取决于系统能否接管人的注意力管理。该思路指向 Agent 从单次对话工具向常驻任务平台的演进，但具体调度机制、资源开销与可靠性表现尚待更多信息披露。

要点透视

  • DeepSeek Harness 团队发布架构长文，主题是设计一个“永远在线”的 Agent。
  • 团队提出判断：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
  • 团队观察到，一个人通常只能同时跟进 3 到 5 个活跃 Session。
  • 现有 Agent 以单个 Session 为单位，Session 之间彼此独立，并行推进多项工作时需要人工在多个会话间切换。
  • 该团队的应对方式是把 Agent 设计成“操作系统”式结构，由系统层统一管理多任务，而非依赖人逐个盯守会话。
  • 文章将多任务能力的瓶颈从模型侧转向系统调度与注意力管理侧，属于 Agent 架构层面的思路调整。

文章拆解

这篇架构长文的价值，在于它把 Agent 的竞争焦点从“模型有多强”部分转移到了“系统能替人管多少事”。过去一年，Agent 产品大多围绕单次任务闭环展开：用户给出目标，模型规划并执行，结束后会话归档。这种模式在单任务上可以持续受益于模型能力提升，但一旦进入并行场景，瓶颈就落到人身上——用户需要记住哪些会话在跑、哪些卡住了、哪些需要确认，实际能同时跟进的活跃 Session 只有 3 到 5 个。团队把这一现象概括为“多任务的上限取决于人的注意力”，并据此选择操作系统式的架构方向，逻辑上是自洽的。

从设计含义看，“操作系统”类比至少包含两层：一是统一的任务调度，让多个 Session 不再彼此孤立，而由系统层分配执行资源、维护状态；二是常驻运行，Agent 不因用户离开而停止，从而把人的角色从“逐会话盯守”转为“例外处理”。如果这一层能够成立，Agent 的使用形态会从工具调用转向任务托管，用户可同时推进的工作数量不再直接受限于注意力带宽。

对行业和用户的影响主要体现在产品形态上。若多任务调度成为系统能力，Agent 平台的竞争点将转向任务队列管理、状态可见性、异常上报和资源成本控制，而非单纯比拼单轮回答质量。对用户而言，收益是并行处理能力提升，代价则可能是对系统调度逻辑的依赖加深——用户需要信任系统判断哪些任务该继续、哪些该暂停。

值得关注的变量包括：系统如何界定任务优先级和冲突处理，常驻运行带来的算力与费用开销如何控制，多任务并发下的错误传播是否会被放大，以及用户如何保持对批量任务的可观测性。素材未披露具体调度机制、并发规模上限和实测数据，这些关键细节尚待确认。潜在风险在于，若系统层调度不够透明，用户可能从“注意力不足”转为“失控感增强”，多任务效率的提升也可能被排查成本抵消。

查看原文