🦌 DeerFlow - 2.0
English | 中文 | 日本語 | Français | Русский
2026 年 2 月 28 日,DeerFlow 在 2.0 版本发布后荣登 GitHub Trending 🏆 第一名。衷心感谢我们出色的社区——是你们创造了这一切!💪🔥
DeerFlow(Deep Exploration and Efficient Research Flow,深度探索与高效研究流)是一个开源超级 Agent 框架,通过编排子 Agent、记忆和沙箱来完成几乎任何任务——并由可扩展的技能驱动。
deer-flow-720p.mp4
Note
DeerFlow 2.0 是一次从头重写。 它与 v1 没有任何共同代码。如果你在寻找原始的深度研究框架,它维护在 1.x 分支——该分支仍欢迎贡献。主动开发已迁移至 2.0。
官方网站
欢迎访问我们的官方网站,了解更多信息并观看真实演示。
字节跳动火山引擎编程计划
我们强烈推荐使用 Doubao-Seed-2.0-Code、DeepSeek v3.2 和 Kimi 2.5 来运行 DeerFlow
了解更多
中国大陆地区的开发者请点击这里
InfoQuest
DeerFlow 已新集成由 BytePlus 自主研发的智能搜索与抓取工具集——InfoQuest(支持免费在线体验)
目录
🦌 DeerFlow - 2.0 官方网站
字节跳动火山引擎编程计划
InfoQuest
目录
一行命令 Agent 配置
快速开始 配置
运行应用 部署规格
方式一:Docker(推荐)
方式二:本地开发
高级沙箱模式
MCP Server
IM 频道
LangSmith 追踪
Langfuse 追踪
同时使用两个提供商
从深度研究到超级 Agent 框架
核心功能 技能与工具 Claude Code 集成
子 Agent
沙箱与文件系统
上下文工程
长期记忆
推荐模型
内嵌 Python 客户端
文档
⚠️ 安全须知 不当部署可能引入安全风险
安全建议
贡献
许可证
致谢 主要贡献者
Star 历史
一行命令 Agent 配置
如果你使用 Claude Code、Codex、Cursor、Windsurf 或其他编程 Agent,可以用一句话将配置说明交给它:
Help me clone DeerFlow if needed, then bootstrap it for local development by following https://raw.githubusercontent.com/bytedance/deer-flow/main/Install.md
该提示词面向编程 Agent。它会告诉 Agent:如有需要则克隆仓库,有条件时选择 Docker,最终给出确切的下一条命令以及用户仍需提供的缺失配置。
快速开始
配置
克隆 DeerFlow 仓库
git clone https://github.com/bytedance/deer-flow.git cd deer-flow运行配置向导 在项目根目录(
deer-flow/)下执行:make setup这将启动一个交互式向导,引导你选择 LLM 提供商、可选的网络搜索,以及执行/安全偏好(如沙箱模式、bash 访问权限和文件写入工具)。向导会生成一个最小化的config.yaml并将你的密钥写入.env,整个过程约需 2 分钟。向导还支持配置可选的网络搜索提供商,也可以暂时跳过。随时运行make doctor以验证你的配置并获取可操作的修复提示。高级/手动配置:如果你更倾向于直接编辑config.yaml,可改为运行make config以复制完整模板。完整参考(包括 CLI 支持的提供商、Codex CLI、Claude Code OAuth、OpenRouter、Responses API 等)请参见config.example.yaml。手动模型配置示例models : - name : gpt-4o display_name : GPT-4o use : langchain_openai:ChatOpenAI model : gpt-4o api_key : $OPENAI_API_KEY - name : openrouter-gemini-2.5-flash display_name : Gemini 2.5 Flash (OpenRouter) use : langchain_openai:ChatOpenAI model : google/gemini-2.5-flash-preview api_key : $OPENROUTER_API_KEY base_url : https://openrouter.ai/api/v1 - name : gpt-5-responses display_name : GPT-5 (Responses API) use : langchain_openai:ChatOpenAI model : gpt-5 api_key : $OPENAI_API_KEY use_responses_api : true output_version : responses/v1 - name : qwen3-32b-vllm display_name : Qwen3 32B (vLLM) use : deerflow.models.vllm_provider:VllmChatModel model : Qwen/Qwen3-32B api_key : $VLLM_API_KEY base_url : http://localhost:8000/v1 supports_thinking : true when_thinking_enabled : extra_body : chat_template_kwargs : enable_thinking : trueOpenRouter 及类似的兼容 OpenAI 的网关应使用langchain_openai:ChatOpenAI加base_url进行配置。如果你希望使用提供商特定的环境变量名称,可通过api_key显式指定(例如api_key: $OPENROUTER_API_KEY)。若要通过/v1/responses路由 OpenAI 模型,继续使用langchain_openai:ChatOpenAI并配合use_responses_api: true设置output_version: responses/v1。对于 vLLM 0.19.0,请使用deerflow.models.vllm_provider:VllmChatModel。对于 Qwen 风格的推理模型,DeerFlow 通过extra_body.chat_template_kwargs.enable_thinking切换推理模式,并在多轮工具调用对话中保留 vLLM 的非标准reasoning字段。旧版thinking配置会自动规范化以保持向后兼容。推理模型可能还需要服务端以--reasoning-parser ...启动。如果你的本地 vLLM 部署接受任意非空 API 密钥,仍可将VLLM_API_KEY设为占位值。CLI 支持的提供商配置示例:models : - name : gpt-5.4 display_name : GPT-5.4 (Codex CLI) use : deerflow.models.openai_codex_provider:CodexChatModel model : gpt-5.4 supports_thinking : true supports_reasoning_effort : true - name : claude-sonnet-4.6 display_name : Claude Sonnet 4.6 (Claude Code OAuth) use : deerflow.models.claude_provider:ClaudeChatModel model : claude-sonnet-4-6 max_tokens : 4096 supports_thinking : trueCodex CLI 读取~/.codex/auth.jsonClaude Code 接受
CLAUDE_CODE_OAUTH_TOKEN、ANTHROPIC_AUTH_TOKEN、CLAUDE_CODE_CREDENTIALS_PATH或~/.claude/.credentials.jsonACP agent 条目与模型提供商分开配置——如果你配置了
acp_agents.codex,请将其指向 Codex ACP 适配器,例如npx -y @zed-industries/codex-acp在 macOS 上,如有需要请显式导出 Claude Code 认证信息:
eval " $( python3 scripts/export_claude_code_oauth.py --print-export ) "
API 密钥也可手动在 .env(推荐)中设置,或在 shell 中导出:
OPENAI_API_KEY=your-openai-api-key TAVILY_API_KEY=your-tavily-api-key
运行应用
部署规格
在选择如何运行 DeerFlow 时,请参考下表作为实用起点:
| 部署目标 | 起步配置 | 推荐配置 | 备注 |
| 本地评估 / make dev | 4 vCPU,8 GB RAM,20 GB 可用 SSD | 8 vCPU,16 GB RAM | 适合单个开发者或搭配托管模型 API 进行一次轻量会话。2 vCPU / 4 GB 通常不够用。|
| Docker 开发 / make docker-start | 4 vCPU,8 GB RAM,25 GB 可用 SSD | 8 vCPU,16 GB RAM | 镜像构建、绑定挂载和沙箱容器比纯本地开发需要更多余量。|
| 长期运行服务器 / make up | 8 vCPU,16 GB RAM,40 GB 可用 SSD | 16 vCPU,32 GB RAM | 适合共享使用、多 Agent 运行、报告生成或较重的沙箱工作负载。|
以上数字仅涵盖 DeerFlow 本身。如果你同时托管本地 LLM,请单独为该服务评估规格。
Linux 加 Docker 是持久化服务器的推荐部署目标。macOS 和 Windows 最好作为开发或评估环境使用。
如果 CPU 或内存使用率持续高位,请先减少并发运行数,再考虑升级到更高规格档次。
方式一:Docker(推荐)
开发模式(热重载,源码挂载):
make docker-init # Pull sandbox image (only once or when image updates) make docker-start # Start services (auto-detects sandbox mode from config.yaml)
make docker-start 仅在 config.yaml 使用 provisioner 模式(sandbox.use: deerflow.community.aio_sandbox:AioSandboxProvider 配合 provisioner_url)时才启动 provisioner。
Docker 构建默认使用上游 uv 镜像仓库。如果你在受限网络中需要更快的镜像源,请在运行 make docker-init 或 make docker-start 之前导出 UV_INDEX_URL=https://pypi.tuna.tsinghua.edu.cn/simple 和 NPM_REGISTRY=https://registry.npmmirror.com。
后端进程会在下次访问配置时自动读取 config.yaml 的更改,因此在开发过程中更新模型元数据无需手动重启。
Tip
在 Linux 上,如果基于 Docker 的命令因 permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock 而失败,请将你的用户添加到 docker 组并重新登录后再试。完整修复方法请参见 CONTRIBUTING.md。
生产模式(本地构建镜像,挂载运行时配置和数据):
make up # Build images and start all production services make down # Stop and remove containers
统一的 nginx 端点默认同源,不发送浏览器 CORS 头。如果你运行跨域或端口转发的浏览器客户端,请将 GATEWAY_CORS_ORIGINS 设置为逗号分隔的精确来源列表,例如 http://localhost:3000;Gateway 随后会应用 CORS 允许列表并进行匹配的 CSRF 来源校验。
Important
Gateway 在进程中保存运行状态(RunManager 和流桥接),因此生产模式默认使用单个 Gateway worker(GATEWAY_WORKERS=1)。在没有共享跨 worker 流桥接(目前尚不可用)的情况下增加 worker 数量,会破坏运行取消、SSE 重连、请求去重和 IM 频道功能,因为 nginx 不使用粘性会话,每个 worker 都保有自己的运行状态。请通过增加 CPU/RAM(或将数据库和沙箱迁移至专用层)来纵向扩展单个 worker,而不是提高 GATEWAY_WORKERS。
详细的 Docker 开发指南请参见 CONTRIBUTING.md。
方式二:本地开发
如果你更倾向于本地运行服务:
前提条件:请先完成上方的"配置"步骤(make setup)。make dev 需要项目根目录下存在有效的 config.yaml。可设置 DEER_FLOW_PROJECT_ROOT 来显式定义项目根目录,或设置 DEER_FLOW_CONFIG_PATH 来指向特定配置文件。运行时状态默认位于项目根目录下的 .deer-flow,可通过 DEER_FLOW_HOME 修改;技能默认位于项目根目录下的 skills/,可通过 DEER_FLOW_SKILLS_PATH 修改。启动前请运行 make doctor 验证配置。在 Windows 上,请从 Git Bash 运行本地开发流程。原生 cmd.exe 和 PowerShell 不支持基于 bash 的服务脚本,WSL 也无法保证正常运行,因为部分脚本依赖 Git for Windows 工具(如 cygpath)。
检查前提条件:
make check # Verifies Node.js 22+, pnpm, uv, nginx安装依赖:
make install # Install backend + frontend dependencies + pre-commit hooks(可选)预拉取沙箱镜像:
# Recommended if using Docker/Container-based sandbox make setup-sandbox(可选)加载示例记忆数据以供本地查看:
python scripts/load_memory_sample.py该命令将示例 fixture 复制到默认本地运行时记忆文件,以便评审人员可立即测试Settings > Memory。最短评审流程请参见 backend/docs/MEMORY_SETTINGS_REVIEW.md。启动服务:
make dev
启动模式
DeerFlow 在 Gateway API 内部运行 Agent 运行时。开发模式启用热重载;生产模式使用预构建的前端。
| | 本地前台 | 本地守护进程 | Docker 开发 | Docker 生产 |
| 开发 | ./scripts/serve.sh --dev make dev | ./scripts/serve.sh --dev --daemon make dev-daemon | ./scripts/docker.sh start make docker-start | — |
| 生产 | ./scripts/serve.sh --prod make start | ./scripts/serve.sh --prod --daemon make start-daemon | — | ./scripts/deploy.sh make up |
| 操作 | 本地 | Docker 开发 | Docker 生产 |
| 停止 | ./scripts/serve.sh --stop make stop | ./scripts/docker.sh stop make docker-stop | ./scripts/deploy.sh down make down |
| 重启 | ./scripts/serve.sh --restart [flags] | ./scripts/docker.sh restart | — |
Gateway 拥有 /api/langgraph/* 并在 nginx 后将这些公共的 LangGraph 兼容路径转换为其原生 /api/* 路由器。
Docker 生产部署
deploy.sh 支持分开构建和启动:
# One-step (build + start) deploy.sh # Two-step (build once, start later) deploy.sh build # build all images deploy.sh start # start pre-built images # Stop deploy.sh down
高级配置
沙箱模式
DeerFlow 支持多种沙箱执行模式:
本地执行(直接在宿主机上运行沙箱代码)
Docker 执行(在隔离的 Docker 容器中运行沙箱代码)
Docker 执行配合 Kubernetes(通过 provisioner 服务在 Kubernetes Pod 中运行沙箱代码)
在 Docker 开发模式下,服务启动遵循 config.yaml 沙箱模式。在本地/Docker 模式下,provisioner 不会被启动。
参见沙箱配置指南以配置你偏好的模式。
MCP Server
DeerFlow 支持可配置的 MCP 服务器和技能以扩展其功能。对于 HTTP/SSE MCP 服务器,支持 OAuth 令牌流(client_credentials、refresh_token)。详细说明请参阅 MCP Server Guide。
IM Channels
DeerFlow 支持从即时通讯应用接收任务。配置完成后,各 Channel 会自动启动——所有 Channel 均无需公网 IP。
DeerFlow 还可以在工作区 UI 中向用户开放自有的 IM Channel 连接。当 channel_connections 启用时,已登录用户可通过侧边栏或"Settings > Channels"绑定 Telegram、Slack、Discord、飞书/Lark、DingTalk、微信或企业微信。该功能复用已有的出站 channels.* 传输通道,因此无需公网 IP 或服务商回调 URL。绑定后,IM 消息的处理将使用所连接的 DeerFlow 用户账号。有关配置和安全说明,请参阅 IM Channel Connections。
| Channel | Transport | Difficulty |
| Telegram | Bot API(长轮询) | 简单 |
| Slack | Socket Mode | 中等 |
| 飞书 / Lark | WebSocket | 中等 |
| 微信 | 腾讯 iLink(长轮询) | 中等 |
| 企业微信 | WebSocket | 中等 |
| DingTalk | Stream Push(WebSocket) | 中等 |
在 config.yaml 中进行配置:
channels : # LangGraph-compatible Gateway API base URL (default: http://localhost:8001/api) langgraph_url : http://localhost:8001/api # Gateway API URL (default: http://localhost:8001) gateway_url : http://localhost:8001 # Optional: global session defaults for all mobile channels session : assistant_id : lead_agent # or a custom agent name; custom agents are routed via lead_agent + agent_name config : recursion_limit : 100 context : thinking_enabled : true is_plan_mode : false subagent_enabled : false feishu : enabled : true app_id : $FEISHU_APP_ID app_secret : $FEISHU_APP_SECRET # domain: https://open.feishu.cn # China (default) # domain: https://open.larksuite.com # International wecom : enabled : true bot_id : $WECOM_BOT_ID bot_secret : $WECOM_BOT_SECRET slack : enabled : true bot_token : $SLACK_BOT_TOKEN # xoxb-... app_token : $SLACK_APP_TOKEN # xapp-... (Socket Mode) allowed_users : [] # empty = allow all telegram : enabled : true bot_token : $TELEGRAM_BOT_TOKEN allowed_users : [] # empty = allow all wechat : enabled : false bot_token : $WECHAT_BOT_TOKEN ilink_bot_id : $WECHAT_ILINK_BOT_ID qrcode_login_enabled : true # optional: allow first-time QR bootstrap when bot_token is absent allowed_users : [] # empty = allow all polling_timeout : 35 state_dir : ./.deer-flow/wechat/state max_inbound_image_bytes : 20971520 max_outbound_image_bytes : 20971520 max_inbound_file_bytes : 52428800 max_outbound_file_bytes : 52428800 # Optional: per-channel / per-user session settings session : assistant_id : mobile-agent # custom agent names are also supported here context : thinking_enabled : false users : " 123456789 " : assistant_id : vip-agent config : recursion_limit : 150 context : thinking_enabled : true subagent_enabled : true dingtalk : enabled : true client_id : $DINGTALK_CLIENT_ID # Client ID of your DingTalk application client_secret : $DINGTALK_CLIENT_SECRET # Client Secret of your DingTalk application allowed_users : [] # empty = allow all card_template_id : " " # Optional: AI Card template ID for streaming typewriter effect
注意事项:
assistant_id: lead_agent直接调用默认的 LangGraph 助手。如果
assistant_id设置为自定义 Agent 名称,DeerFlow 仍会通过lead_agent路由,并将该值作为agent_name注入,从而使自定义 Agent 的 SOUL/config 在 IM Channel 中生效。IM Channel Worker 在内部调用 Gateway 的 LangGraph 兼容 API,并自动附加进程本地内部鉴权信息,以及线程和运行创建所需的 CSRF cookie/header 对。
在 .env 文件中设置对应的 API 密钥:
# Telegram TELEGRAM_BOT_TOKEN=123456789:ABCdefGHIjklMNOpqrSTUvwxYZ # Slack SLACK_BOT_TOKEN=xoxb-... SLACK_APP_TOKEN=xapp-... # Feishu / Lark FEISHU_APP_ID=cli_xxxx FEISHU_APP_SECRET=your_app_secret # WeChat iLink WECHAT_BOT_TOKEN=your_ilink_bot_token WECHAT_ILINK_BOT_ID=your_ilink_bot_id # WeCom WECOM_BOT_ID=your_bot_id WECOM_BOT_SECRET=your_bot_secret # DingTalk DINGTALK_CLIENT_ID=your_client_id DINGTALK_CLIENT_SECRET=your_client_secret
Telegram 配置
与 @BotFather 对话,发送
/newbot,并复制 HTTP API token。在
.env中设置TELEGRAM_BOT_TOKEN,并在config.yaml中启用该 Channel。
Slack 配置
前往 api.slack.com/apps → Create New App → From scratch,创建一个 Slack App。
在 OAuth & Permissions 下,添加 Bot Token Scopes:
app_mentions:read、chat:write、im:history、im:read、im:write、files:write。启用 Socket Mode → 生成一个具有
connections:write权限范围的 App-Level Token(xapp-…)。在 Event Subscriptions 下,订阅 Bot 事件:
app_mention、message.im。在
.env中设置SLACK_BOT_TOKEN和SLACK_APP_TOKEN,并在config.yaml中启用该 Channel。
飞书 / Lark 配置
在飞书开放平台创建应用 → 启用机器人能力。
添加权限:
im:message、im:message.p2p_msg:readonly、im:resource。在事件下,订阅
im.message.receive_v1并选择长连接模式。复制 App ID 和 App Secret,在
.env中设置FEISHU_APP_ID和FEISHU_APP_SECRET,并在config.yaml中启用该 Channel。
微信配置
在
config.yaml中启用wechatChannel。在
.env中设置WECHAT_BOT_TOKEN,或设置qrcode_login_enabled: true以进行首次二维码引导绑定。当
bot_token不存在且启用了二维码引导时,请查看后端日志中 iLink 返回的二维码内容,并完成绑定流程。二维码流程成功后,DeerFlow 会将获取到的 token 持久化保存至
state_dir,以便后续重启使用。对于 Docker Compose 部署,请将
state_dir挂载至持久化卷,以确保get_updates_buf游标和已保存的鉴权状态在重启后仍然有效。
企业微信配置
在企业微信 AI Bot 平台创建机器人,并获取
bot_id和bot_secret。在
config.yaml中启用channels.wecom,并填入bot_id/bot_secret。在
.env中设置WECOM_BOT_ID和WECOM_BOT_SECRET。确保后端依赖项中包含
wecom-aibot-python-sdk。该 Channel 使用 WebSocket 长连接,无需公网回调 URL。当前集成支持接收文本、图片和文件消息。Agent 生成的最终图片/文件也会回传至企业微信会话。
DingTalk 配置
在 DingTalk 开发者后台创建 DingTalk 应用,并启用机器人能力。
在机器人配置页面,将消息接收模式设置为 Stream 模式。
复制
Client ID和Client Secret,在.env中设置DINGTALK_CLIENT_ID和DINGTALK_CLIENT_SECRET,并在config.yaml中启用该 Channel。(可选) 如需启用流式 AI 卡片回复(打字机效果),请在 DingTalk 卡片平台创建一个 AI 卡片模板,然后将
config.yaml中的card_template_id设置为该模板 ID。同时还需申请Card.Streaming.Write和Card.Instance.Write权限。
当 DeerFlow 在 Docker Compose 中运行时,IM Channel 在 gateway 容器内执行。此时,请勿将 channels.langgraph_url 或 channels.gateway_url 指向 localhost,而应使用容器服务名称,例如 http://gateway:8001/api 和 http://gateway:8001,或设置 DEER_FLOW_CHANNELS_LANGGRAPH_URL 和 DEER_FLOW_CHANNELS_GATEWAY_URL。
命令
Channel 连接完成后,您可以直接在聊天中与 DeerFlow 交互:
| 命令 | 说明 |
| /new | 开始新对话 |
| /status | 显示当前线程信息 |
| /models | 列出可用模型 |
| /memory | 查看记忆 |
| /help | 显示帮助 |
不带命令前缀的消息将被视为普通聊天——DeerFlow 会创建一个线程并以对话方式回复。
LangSmith Tracing
DeerFlow 内置了 LangSmith 集成,用于可观测性。启用后,所有 LLM 调用、Agent 运行和工具执行均会被追踪,并在 LangSmith 控制台中可见。
将以下内容添加至 .env 文件:
LANGSMITH_TRACING=true LANGSMITH_ENDPOINT=https://api.smith.langchain.com LANGSMITH_API_KEY=lsv2_pt_xxxxxxxxxxxxxxxx LANGSMITH_PROJECT=xxx
Langfuse Tracing
DeerFlow 还支持 Langfuse 可观测性,适用于 LangChain 兼容的运行。
将以下内容添加至 .env 文件:
LANGFUSE_TRACING=true LANGFUSE_PUBLIC_KEY=pk-lf-xxxxxxxxxxxxxxxx LANGFUSE_SECRET_KEY=sk-lf-xxxxxxxxxxxxxxxx LANGFUSE_BASE_URL=https://cloud.langfuse.com
如果您使用的是自托管 Langfuse 实例,请将 LANGFUSE_BASE_URL 设置为您的部署 URL。
Trace 关联字段。 每次 Agent 运行都会附加 Langfuse 的保留 Trace 属性,以便 Sessions 和 Users 页面自动生效:
session_id= LangGraphthread_id—— 将同一对话的所有 Trace 归组user_id= 来自get_effective_user_id()的有效用户(无鉴权模式下回退为default)trace_name= 助手 ID(默认为lead-agent)tags=[env: , model: ](未设置时省略)
这些属性在图调用根节点处注入至 RunnableConfig.metadata,对 Gateway 路径(runtime/runs/worker.py::run_agent)和嵌入路径(client.py::DeerFlowClient.stream)均适用,因此任何 LangChain 兼容的回调都可以读取它们。设置 DEER_FLOW_ENV(或 ENVIRONMENT)可按部署环境为 Trace 打标签。
同时使用两个提供商
如果同时启用了 LangSmith 和 Langfuse,DeerFlow 会同时附加两个 Tracing 回调,并将相同的模型活动上报至两个系统。
如果某个提供商被显式启用但缺少必要凭据,或其回调初始化失败,DeerFlow 会在模型创建期间初始化 Tracing 时快速失败,并在错误信息中指明导致失败的提供商。
对于 Docker 部署,Tracing 默认禁用。在 .env 中设置 LANGSMITH_TRACING=true 和 LANGSMITH_API_KEY 可启用该功能。
从深度研究到超级 Agent 底座
DeerFlow 最初是一个深度研究框架——而社区将它推得更远。自发布以来,开发者们将它的应用场景远远拓展到了研究之外:构建数据管道、生成幻灯片、搭建仪表盘、自动化内容工作流。这些都是我们从未预料到的。
这让我们意识到一件重要的事:DeerFlow 不只是一个研究工具,它是一个底座——一个能让 Agent 真正完成工作的运行时基础设施。
于是我们从头重建。
DeerFlow 2.0 不再是一个需要手动拼装的框架,而是一个超级 Agent 底座——开箱即用,完全可扩展。它基于 LangGraph 和 LangChain 构建,内置了 Agent 所需的一切:文件系统、记忆、技能、沙箱感知执行,以及针对复杂多步任务的规划与子 Agent 派生能力。
按原样使用,或拆开来按你的方式重塑。
核心功能
Skills & Tools
技能(Skill)让 DeerFlow 几乎能做任何事。
标准的 Agent Skill 是一个结构化的能力模块——一个 Markdown 文件,定义了工作流、最佳实践以及对辅助资源的引用。DeerFlow 内置了用于研究、报告生成、幻灯片制作、网页生成、图像和视频生成等技能。但真正的威力在于可扩展性:添加你自己的技能、替换内置技能,或将它们组合成复合工作流。
技能按需加载——仅在任务需要时加载,而非全部一次性加载。这使上下文窗口保持精简,让 DeerFlow 在 Token 敏感的模型下也能良好运行。
用户可以在请求开头使用 /skill-name 为单次对话显式激活某个已启用的技能,例如 /data-analysis analyze uploads/foo.csv。DeerFlow 会将该技能的 SKILL.md 作为隐藏的当前轮上下文加载,同时将基础提示词限制为技能元数据。Slash 激活方式遵守技能禁用设置、自定义 Agent 技能白名单,以及现有的 Channel 命令(如 /new 和 /help)。
通过 Gateway 安装 .skill 归档包时,DeerFlow 支持标准的可选前置元数据(frontmatter),如 version、author 和 compatibility,不会因此拒绝本身有效的外部技能。
工具遵循同样的设计理念。DeerFlow 内置了一套核心工具集——网页搜索、网页抓取、文件操作、Bash 执行——并通过 MCP 服务器和 Python 函数支持自定义工具。随意替换,随意添加。
Gateway 生成的后续建议在解析 JSON 数组响应前,现在会对纯字符串模型输出和 block/list 形式的富内容进行统一规范化处理,从而避免提供商特定的内容包装器静默丢弃建议。
# Paths inside the sandbox container /mnt/skills/public ├── research/SKILL.md ├── report-generation/SKILL.md ├── slide-creation/SKILL.md ├── web-page/SKILL.md └── image-generation/SKILL.md /mnt/skills/custom └── your-custom-skill/SKILL.md ← yours
Claude Code 集成
claude-to-deerflow 技能让你可以直接从 Claude Code 与运行中的 DeerFlow 实例交互。发送研究任务、查看状态、管理线程——无需离开终端。
安装技能:
npx skills add https://github.com/bytedance/deer-flow --skill claude-to-deerflow
然后确保 DeerFlow 正在运行(默认地址为 http://localhost:2026),并在 Claude Code 中使用 /claude-to-deerflow 命令。
你可以做到的事:
向 DeerFlow 发送消息并获取流式响应
选择执行模式:flash(快速)、standard(标准)、pro(规划)、ultra(子 Agent)
检查 DeerFlow 健康状态,列出模型/技能/Agent
管理线程和对话历史
上传文件进行分析
环境变量(可选,用于自定义端点):
DEERFLOW_URL=http://localhost:2026 # Unified proxy base URL DEERFLOW_GATEWAY_URL=http://localhost:2026 # Gateway API DEERFLOW_LANGGRAPH_URL=http://localhost:2026/api/langgraph # LangGraph API
完整 API 参考请参阅 skills/public/claude-to-deerflow/SKILL.md。
Sub-Agents
复杂任务很少能在单次执行中完成。DeerFlow 会对其进行分解。
主导 Agent 可以动态生成子 Agent——每个子 Agent 都有其独立的上下文范围、工具集和终止条件。子 Agent 在条件允许时并行运行,返回结构化结果,再由主导 Agent 将所有内容综合为连贯的输出。启用 token 用量追踪后,已完成的子 Agent 用量将归因到对应的调度步骤。
这就是 DeerFlow 处理耗时数分钟乃至数小时任务的方式:一个研究任务可能会扇出为十几个子 Agent,各自从不同角度展开探索,最终汇聚成一份完整报告——或一个网站——或一份附带生成视觉素材的幻灯片。一个框架,众多双手。
Sandbox & File System
DeerFlow 不只是谈论做事,它有自己的计算机。
每个任务都拥有独立的执行环境,包含完整的文件系统视图——技能、工作区、上传文件、输出结果。Agent 可以读取、写入和编辑文件,可以查看图片,在安全配置下还可以执行 shell 命令。
使用 AioSandboxProvider 时,shell 执行在隔离容器内运行。使用 LocalSandboxProvider 时,文件工具仍会映射到宿主机上按线程划分的目录,但宿主机 bash 默认禁用,因为它并非安全的隔离边界。仅在完全可信的本地工作流中才应重新启用宿主机 bash。
这就是"拥有工具访问权限的聊天机器人"与"拥有真实执行环境的 Agent"之间的本质区别。
# Paths inside the sandbox container /mnt/user-data/ ├── uploads/ ← your files ├── workspace/ ← agents' working directory └── outputs/ ← final deliverables
Context Engineering
隔离的子 Agent 上下文:每个子 Agent 在独立的上下文中运行,无法访问主 Agent 或其他子 Agent 的上下文。这一设计确保子 Agent 能够专注于当前任务,不受主 Agent 或其他子 Agent 上下文的干扰。
摘要压缩:在一次会话中,DeerFlow 会主动管理上下文——对已完成的子任务进行摘要、将中间结果卸载到文件系统、压缩不再直接相关的内容。这使它能够在漫长的多步骤任务中保持专注,而不会撑爆上下文窗口。
严格的工具调用恢复机制:当 provider 或中间件打断工具调用循环时,DeerFlow 现在会在强制停止的 assistant 消息中剥离 provider 级别的原始工具调用元数据,并在下次模型调用前为悬空调用注入占位工具结果。这可防止严格校验 tool_call_id 序列的 OpenAI 兼容推理模型因历史记录格式错误而调用失败。
Long-Term Memory
大多数 Agent 在对话结束后便会忘记一切。DeerFlow 则不然。
跨会话之间,DeerFlow 会持续构建关于你的个人档案、偏好和积累知识的持久记忆。使用越多,它对你的了解就越深——你的写作风格、技术栈、常用工作流。记忆存储在本地,完全由你掌控。
记忆更新现在会在写入时跳过重复的事实条目,避免相同的偏好和上下文在多次会话中无限累积。
Recommended Models
DeerFlow 与模型无关——它可与任何实现了 OpenAI 兼容 API 的 LLM 协同工作。尽管如此,以下能力越强,表现越佳:
长上下文窗口(100k+ tokens),用于深度研究和多步骤任务
推理能力,用于自适应规划和复杂任务分解
多模态输入,用于图像理解和视频内容理解
强大的工具调用能力,用于可靠的函数调用和结构化输出
Embedded Python Client
DeerFlow 可作为嵌入式 Python 库使用,无需运行完整的 HTTP 服务。DeerFlowClient 提供对所有 Agent 和 Gateway 能力的进程内直接访问,返回与 HTTP Gateway API 相同的响应 schema。HTTP Gateway 还暴露了 DELETE /api/threads/{thread_id},用于在 LangGraph 线程本身被删除后清除 DeerFlow 管理的本地线程数据:
from deerflow . client import DeerFlowClient client = DeerFlowClient () # Chat response = client . chat ( "Analyze this paper for me" , thread_id = "my-thread" ) # Streaming (LangGraph SSE protocol: values, messages-tuple, end) for event in client . stream ( "hello" ): if event . type == "messages-tuple" and event . data . get ( "type" ) == "ai" : print ( event . data [ "content" ]) # Configuration & management — returns Gateway-aligned dicts models = client . list_models () # {"models": [...]} skills = client . list_skills () # {"skills": [...]} client . update_skill ( "web-search" , enabled = True ) client . upload_files ( "thread-1" , [ "./report.pdf" ]) # {"success": True, "files": [...]}
所有返回 dict 的方法均在 CI 中通过 Gateway Pydantic 响应模型进行校验(TestGatewayConformance),确保嵌入式客户端与 HTTP API schema 保持同步。完整 API 文档请参见 backend/packages/harness/deerflow/client.py。
Documentation
Contributing Guide - 开发环境搭建与工作流说明
Configuration Guide - 配置与安装指南
Architecture Overview - 技术架构详解
Backend Architecture - 后端架构与 API 参考
⚠️ Security Notice
Improper Deployment May Introduce Security Risks
DeerFlow 具备系统命令执行、资源操作和业务逻辑调用等高权限核心能力,默认设计为部署在本地可信环境中(仅可通过 127.0.0.1 回环接口访问)。若在未采取严格安全措施的情况下将 Agent 部署于不可信环境——例如局域网、公有云服务器或其他多端点可访问的环境——可能引入安全风险,包括:
未授权的非法调用:Agent 功能可能被未授权的第三方或恶意网络扫描器发现,触发大量未授权请求,执行系统命令、文件读写等高危操作,可能造成严重安全后果。
合规与法律风险:若 Agent 被非法调用以实施网络攻击、数据窃取或其他违法活动,可能导致法律责任与合规风险。
Security Recommendations
注意:我们强烈建议将 DeerFlow 部署在本地可信网络环境中。 如需跨设备或跨网络部署,必须实施严格的安全措施,例如:
IP 白名单:使用
iptables,或部署具备访问控制列表(ACL)的硬件防火墙/交换机,配置 IP 白名单规则,拒绝所有其他 IP 地址的访问。认证网关:配置反向代理(如 nginx)并启用强预认证机制,拦截所有未经认证的访问。
网络隔离:在条件允许的情况下,将 Agent 与可信设备置于同一专用 VLAN 中,与其他网络设备隔离。
保持更新:持续关注 DeerFlow 的安全功能更新。
Contributing
欢迎贡献!开发环境搭建、工作流及贡献指南请参见 CONTRIBUTING.md。
回归测试覆盖范围包括 Docker sandbox 模式检测,以及 backend/tests/ 中的 provisioner kubeconfig-path 处理测试。后端阻塞 IO 诊断工具可在仓库根目录通过 make detect-blocking-io 运行:它会静态扫描后端业务代码中可能在后端事件循环上运行的阻塞 IO,打印简洁摘要,并将完整 JSON 结果写入 .deer-flow/blocking-io-findings.json。JSON 中包含紧凑的审查记录,字段包括 priority、location、blocking_call、event_loop_exposure、reason 和 code。Gateway artifact 服务现在会强制将活跃 Web 内容类型(text/html、application/xhtml+xml、image/svg+xml)以附件形式下载,而非内联渲染,从而降低生成 artifact 的 XSS 风险。
License
本项目以开源方式发布,采用 MIT License。
Acknowledgments
DeerFlow 建立在开源社区卓越成果之上。我们由衷感谢所有使 DeerFlow 成为可能的项目与贡献者——我们真正站在巨人的肩膀上。
特此向以下项目致以诚挚谢意,感谢其不可或缺的贡献:
** LangChain **:其卓越的框架驱动了我们的 LLM 交互与链式调用,实现了无缝集成与强大功能。
** LangGraph **:其对多 Agent 编排的创新方式,对实现 DeerFlow 复杂工作流发挥了不可或缺的作用。
这些项目彰显了开源协作的变革力量,我们为能在其基础上继续构建而深感自豪。
Key Contributors
衷心感谢 DeerFlow 的核心作者们,正是他们的远见、热情与奉献使这一项目得以成真:
** Daniel Walnut **
** Henry Li **
你们坚定不移的投入与专业精神,是 DeerFlow 成功的核心驱动力。能与你们携手踏上这段旅程,我们深感荣幸。
687

被折叠的 条评论
为什么被折叠?



