mirror of
https://github.com/bytedance/deer-flow.git
synced 2026-05-22 07:56:48 +00:00
b62ac7672a
Agent-Logs-Url: https://github.com/bytedance/deer-flow/sessions/a5f192e7-8034-4e46-af22-60b90ee27d40 Co-authored-by: foreleven <4785594+foreleven@users.noreply.github.com>
49 lines
3.2 KiB
Plaintext
49 lines
3.2 KiB
Plaintext
import { Callout, Cards } from "nextra/components";
|
|
|
|
# 为什么选择 DeerFlow
|
|
|
|
<Callout type="info" emoji="🦌">
|
|
DeerFlow 起源于深度研究,但逐渐演化为一个通用的长时序 Agent 运行时——支持技能、记忆、工具和协作调度。
|
|
</Callout>
|
|
|
|
DeerFlow 的诞生是因为现代 Agent 系统需要的不仅仅是一个聊天循环。一个真正有用的 Agent 必须能够进行长时序规划、将任务拆解为子任务、使用工具、操作文件、安全地运行代码,并在复杂任务中保持足够的上下文连贯性。DeerFlow 正是为提供这样的运行时基础而构建的。
|
|
|
|
## 从深度研究起步
|
|
|
|
DeerFlow 的第一个版本围绕一个具体目标设计:生成真正有深度的研究产出,而不是轻量级聊天机器人的概要总结。核心思路是让 AI 系统像研究团队一样工作:制定计划、收集来源、交叉验证发现,并输出有实际深度的结构化结果。
|
|
|
|
这个定位是有效的,但项目很快揭示了更重要的东西。团队不仅将 DeerFlow 用于研究——他们将其应用于数据分析、报告生成、内部自动化、运营工作流,以及其他同样需要多步骤执行的任务。
|
|
|
|
共同点是清晰的:有价值的部分不仅仅是研究工作流本身,而是其背后的运行时能力。
|
|
|
|
## 研究是第一个技能,而非整个系统
|
|
|
|
这种使用方式的转变带来了一个关键结论:深度研究应该被视为更广泛 Agent 运行时中的一项能力,而不是整个产品的定义。
|
|
|
|
因此,DeerFlow 从一个以单一研究模式为中心的项目演化为一个通用的长时序 Agent Harness。在这个模型中,研究仍然重要,但它成为众多技能中的一项,而非系统的固定形态。
|
|
|
|
这就是为什么 DeerFlow 被描述为 **Harness**,而不仅仅是框架或应用。
|
|
|
|
## 为什么 Harness 很重要
|
|
|
|
Harness 是一个带有主张的 Agent 运行时。它不只是暴露抽象接口。它打包了 Agent 在真实环境中做有用工作所需的基础设施——工具访问、技能加载、沙箱执行、记忆、子 Agent 协调和上下文管理。
|
|
|
|
这让开发者可以专注于他们试图解决的问题,而不是重复构建相同的基础设施层。
|
|
|
|
## DeerFlow 解决的问题
|
|
|
|
DeerFlow 专注于以下几个具体问题:
|
|
|
|
**长时序执行**:大多数有用的任务不能在单次推理中完成。DeerFlow 的架构假设工具调用、规划和多轮推理是正常情况,而非特例。
|
|
|
|
**上下文管理**:随着任务变长,上下文窗口压力成为主要挑战。DeerFlow 通过摘要压缩、范围隔离的子 Agent 上下文和文件系统作为外部记忆来主动管理这一问题。
|
|
|
|
**技能组合**:不同的工作类型需要不同的方法。DeerFlow 让技能成为可组合的能力包,而不是把所有内容硬编码到主 Agent 逻辑中。
|
|
|
|
**沙箱执行**:真实任务需要文件操作和命令执行。DeerFlow 提供一个隔离的工作区,让 Agent 可以安全地进行实际操作。
|
|
|
|
<Cards num={2}>
|
|
<Cards.Card title="核心概念" href="/docs/introduction/core-concepts" />
|
|
<Cards.Card title="Harness 与应用" href="/docs/introduction/harness-vs-app" />
|
|
</Cards>
|