[控场AI]
· 4 分钟阅读· 2,346 字

DeepSeek Harness rc.2 实测:多Agent协作与并行搜索

DeepSeek Harness rc.2 实测:多Agent协作与并行搜索

DeepSeek Harness rc.2 实测:多Agent、Git审阅与并行搜索是亮点,但入口偏桌面端。

B站UP主紫牙对 DeepSeek Harness rc.2 预发布版进行了上手实测。该版本距上一版累计166个提交,重点在多Agent协作、Git工作流整合与并行搜索。实测显示,一个主代理可带三个子代理共享任务面板,任务状态直接标注在列表中,但团队面板仅限桌面端,命令行无入口;Git工作流用新建工作树、改文件、提交三条命令跑通,审阅页面支持按分支、提交、文件类型切换,接近真实 code review 场景;网页搜索并行10个请求耗时5.2秒,串行约34秒,差距超6倍。设置与正式版/开发版渠道切换同样只在桌面端提供。结论是:频繁开PR、写代码且愿意在桌面端工作的开发者值得尝鲜,以对话为主或强依赖命令行的用户可观望,生产环境不应使用预发布版。

DeepSeek Harness 的 rc.2 候选版在发布后引起了不少开发者的关注。B站UP主紫牙在“产品雷达”第一期里,没有复述更新日志,而是直接上手实测了几个关键功能。距离上个版本,这个预发布版累计了166个提交,重点集中在多Agent协作、Git工作流整合以及并行搜索能力上。以下结合他的实测体验,拆解这次更新的实际价值与适用边界。

距离上个版本166个提交

多Agent组队:结构清晰,但入口受限

这次更新最受关注的是多代理协作。实测中,一个主代理可以带领三个子代理协同工作,共享左侧的任务面板,任务状态会直接标注在列表里,进度一目了然。这种设计让复杂任务的拆解和追踪变得更直观,不需要在多个窗口之间来回切换。

不过,团队面板目前只在桌面端提供,命令行没有入口。UP主也只验证了结构层面的可用性,深度的协作效果还需要更多场景测试。对于习惯命令行的开发者来说,这个功能暂时只能“看得见、摸不着”。

团队面板目前只在桌面端

多Agent协作(Multi-Agent) 指由一个主代理(orchestrator)将复杂任务拆解为子任务,分派给多个子代理并行或串行执行,再由主代理汇总结果的架构模式。与单Agent相比,它的优势在于任务可分解、上下文可隔离、子任务可并行,因而更适合长链路、多信息源的复杂场景。常见实现包括主从式(主代理调度、子代理执行)与对等式(代理间协商)两类。DeepSeek广告 Harness 采用的是主从式结构,主代理带三个子代理,共享任务面板的设计本质上是一种轻量的可观测性机制,让开发者能直接看到每个子任务的状态流转,而不必依赖日志排查。需要注意的是,多Agent的收益高度依赖任务拆解质量与子代理间的上下文传递效率,结构可用并不等于协作效果理想。

Git工作流:三条命令跑通真实审阅

Git工作数是另一个实用向的更新。UP主用一个演示仓库实测了新建工作数、改文件、提交这三条命令,流程顺畅。更值得关注的是审阅页面,顶部可以按分支、提交、文件类型切换,力度更接近真实的代码review场景。

对于每天开PR、频繁切换分支的开发者,这种审阅体验能减少在网页和本地工具之间跳转的成本。它把代码审阅的上下文收拢到了一个界面里,按提交或文件类型过滤的灵活性,比简单的diff视图更贴近实际工作流。

审阅页面顶部可以按分支提交文件类型切换

Git工作树(Git Worktree) 是 Git 自 2.5 版本起提供的机制,允许在同一个仓库下同时检出多个工作目录,各自指向不同的分支,而共享同一份 .git 对象库。相比传统的“复制仓库”或“stash 后切分支”,工作树避免了重复克隆带来的磁盘与同步开销,也不必打断当前工作区即可并行开发另一条分支。这正是它在 Agent 场景下有价值的原因:代理可以在独立工作树中修改文件、提交变更,而不干扰用户正在编辑的主工作区。文中“新建工作数”应为“新建工作树”的口误,对应的是 git worktree add 一类命令。

网页搜索:并行请求带来数量级提升

网页搜索的实测数据比较亮眼:10个请求并行耗时5.2秒,串行大概需要34秒,差距超过6倍。重点不在单次搜索的速度,而在于并行架构带来的吞吐提升。当任务需要同时检索多个信息源时,并行请求能显著压缩等待时间。

这个改进对依赖实时信息的Agent任务尤其关键。多Agent协作场景下,子代理可能同时发起搜索请求,并行能力直接决定了整体任务的响应效率。UP主没有展开底层的调度实现,但从实测结果看,并行化是这次更新里最能被感知的性能变化。

并行请求与串行请求 的差异来自网络 I/O 的等待特性。串行执行时,总耗时约等于各请求延迟之和;并行执行时,若请求之间互不依赖且服务端不限流,总耗时接近最慢的那一个请求。文中 10 个请求 5.2 秒对 34 秒,正是这一模型的直观体现。工程上通常用异步 I/O、协程或线程池实现并发,并配合连接池复用、超时控制与失败重试来保证稳定性。需要留意的是,并行度并非越高越好:目标站点可能有速率限制,过高的并发会触发限流甚至封禁,因此实际产品中往往需要并发上限与退避策略。

渠道切换与设置:桌面端优先,命令行缺席

重视设置只在桌面端提供,命令行没有开关。正式版和开发版的渠道切换同样如此。这意味着偏好命令行工作流的开发者在版本管理和设置调整上会受到限制,需要切换到桌面端完成。

命令行没有开关

这种“桌面端先行”的策略在预发布阶段并不罕见,但对于高度依赖命令行的开发者而言,体验上的割裂感是真实存在的。UP主也提到,这个版本更适合“天天开PR、写代码”的人尝鲜,只聊天的用户可以再等等。

谁该升级,谁该再等等

从实测来看,rc.2 的价值集中在多Agent协作的结构、Git审阅的便利性以及并行搜索的性能提升上。如果你日常写代码、频繁处理PR,并且愿意在桌面端工作,这个预发布版值得一试。但如果你的使用场景以对话为主,或者强依赖命令行入口,现阶段可以保持观望。

需要强调的是,生产环境不应使用预发布版。166个提交的迭代量说明改动不小,预发布版的稳定性需要更多真实场景验证。UP主在视频结尾也向观众征集下期想看的项目,说明这类实测还在持续。

#DeepSeek Harness#多Agent协作#Git工作流#并行搜索#预发布版实测#AI编程工具#代码审阅
分享:

相关推荐