DeerFlow 使用入门：从智能体创建、用户隔离到微信接入与业务系统对接

最近体验了字节跳动开源的 DeerFlow，重点研究了智能体创建、会话与记忆、MCP、微信接入，以及公司员工如何使用统一智能体查询自己的业务数据。本文尽量用通俗语言说明它能做什么、怎么使用，以及哪些功能仍需二次开发。

说明：本文参考 DeerFlow 2.1 系列及截至 2026 年 11 月的官方文档。开源项目更新较快，界面和配置项请以实际部署版本为准。

一、DeerFlow 是什么？

DeerFlow 是字节跳动开源的智能体运行框架（Agent Harness），也提供可直接使用的 Web 工作台。

简单说，大模型负责思考，DeerFlow 负责组织大模型去做事：拆分任务、调用工具、处理文件、执行代码、调用子智能体，并尽量持续完成复杂工作。

例如，告诉它“整理今天的工作日报”，它不仅可以生成文字；如果配置了日报系统的 MCP 工具，还可以查询已有记录、按格式整理内容，甚至在获得授权后把日报写回业务系统。

可以把它的组成理解为：

概念	通俗理解	主要作用
大模型（LLM）	大脑	理解问题、推理和生成内容
Harness	工作执行框架	组织任务、模型、工具、上下文和运行过程
智能体（Agent）	有专门职责的助手	按设定角色完成工作
Skill	工作操作手册	告诉智能体如何完成某类任务
MCP / Tool	可以使用的工具	查询系统、调用接口、执行操作
Sandbox	独立工作间	执行命令、处理文件、生成成果
Subagent	临时分工的助手	处理主智能体委派的子任务

DeerFlow 不是大模型本身，也不是只有聊天界面的 AI 产品。它的特点是为智能体提供较完整的执行环境。

二、先认识 DeerFlow 的主要功能

在 Web 工作台中，可以看到以下常用功能（菜单名称可能随版本略有变化）：

功能	能做什么
模型	配置 DeepSeek、Qwen 或兼容 API 的其他模型
用户	管理登录用户、启用或停用账号
智能体	创建有专属角色、Prompt、工具和 Skill 的智能体
对话 / 项目	保存聊天历史，按项目组织工作
定时任务	按指定时间或周期运行任务
Token 用量	查看模型调用和 Token 消耗
能力中心	配置 MCP、Skill 和扩展插件
记忆	管理从历史对话中提取的长期信息
子智能体	配置可由主智能体调用的专业助手
渠道	对接微信、企业微信、飞书、钉钉等消息入口

初次使用建议先完成模型配置 → 创建智能体 → 添加工具 → 通过网页验证，再接入微信，排查问题会更容易。

三、用户怎么管理？数据会不会混在一起？

DeerFlow 提供基础的用户认证及管理员角色。首次初始化可以创建管理员账号，也支持普通用户账号和部分 SSO 接入方式。

用户不仅用于登录，还是系统进行数据隔离的重要依据。

数据	默认隔离方式	举例
会话	按用户隔离	张三不能直接查看李四的聊天记录
文件	按用户、会话划分目录	张三上传的日报不会自动进入李四的工作区
长期记忆	按用户范围存储；部分记忆还有智能体作用域	不同用户的个人偏好不应混用
自定义智能体	默认归创建者所有	张三新建的智能体不会自动成为全员共享智能体
沙箱	与会话工作区关联，具体隔离强度取决于沙箱模式	不同任务可使用独立的文件执行环境

这里要特别注意：用户数据隔离不等于完整的企业资源权限管理。

例如，“张三只能查询自己的日报”不能仅靠聊天记录隔离保证，还必须由日报系统的接口核验张三的业务身份与数据权限。

另外，公司可以只让一个 admin 登录 DeerFlow，但不代表系统天然就支持所有员工共用 admin 创建的自定义智能体。这是后面微信方案需要特别处理的问题。

四、怎么创建自己的智能体？

假设要创建一个公司通用的“日报填写助手”，基本步骤如下：

管理员进入 「智能体」→「新建智能体」。
填写名称、简介，例如 daily-report、日报填写助手。
设置角色和行为要求，明确它负责什么、不负责什么。
选择模型，并给它配置需要使用的 Skill、MCP 或其他工具。
保存后发起一段真实对话，验证能否正确理解和完成日报任务。

SOUL.md 是什么？

DeerFlow 的自定义智能体可以使用 SOUL.md 定义角色与行为，类似一份“岗位职责说明书”。例如：

# 日报填写助手

## 角色定位
你是一名企业工作日报助手，帮助员工整理和查询日报。

## 工作要求
- 使用简体中文回答，表达简洁。
- 将工作内容整理为“完成事项、问题风险、后续计划”。
- 信息不足时先向员工确认，不编造工作内容。
- 保存或查询日报前，使用已经验证的员工身份。
- 涉及提交、修改等操作时，先取得员工确认。

不要把它和 SKILL.md 混淆：

SOUL.md：这个智能体是谁，应该怎样做事。
SKILL.md：遇到某类任务时，具体应该按什么步骤操作。

比如“日报助手”的 SOUL.md 约束回答风格，“日报生成 Skill”则可以规定整理日报的具体格式和流程。

子智能体又是什么？

当任务复杂时，主智能体可以临时委派子智能体执行部分工作，例如资料收集、文件处理或命令执行。子智能体通常使用独立的临时上下文，把结果交还主智能体；它不是一个必须由用户单独登录和聊天的账号。

五、如何接入自己开发的 MCP？

MCP 可以理解为“让智能体使用外部工具的统一接口”。例如自己开发一个日报 MCP，向 DeerFlow 提供：

get_my_daily_report：查询当前员工的日报；
save_my_daily_report：保存当前员工的日报。

在新版页面里，进入 「能力中心 → 工具与集成 → 添加 MCP 插件」，按提示填写服务信息即可。常见内容包括 MCP 名称、连接方式、服务地址及认证信息。

例如远程 MCP 可能使用：

名称：daily-report
类型：Streamable HTTP
地址：https://mcp.example.com/mcp
认证：按服务端要求配置

这里填的必须是真正实现 MCP 协议的服务地址，不能把普通 REST API 直接当成 MCP 地址。

能力中心通常区分：

平台提供：管理员统一配置的共享 MCP，供符合权限要求的用户使用；
我的插件：属于当前登录账号的个人 MCP 配置。

添加完成还应检查智能体是否选择了对应工具、工具是否已启用、调用是否成功。把 MCP 分配给智能体，只是让它具备调用能力，不是自动授予业务系统的数据访问权限。

六、会话、上下文、记忆有什么区别？

这三个概念非常容易混淆。

概念	通俗解释	主要用途
会话（Thread）	一段持续保存的聊天和任务过程	下次继续之前的工作
上下文（Context）	当前这一轮模型实际看到的内容	让模型理解正在处理什么
长期记忆（Memory）	从历史对话提取并保存的重要信息	在新会话中复用个人偏好或背景

例如，今天整理日报用一个会话；明天继续聊天，系统可以沿着原会话历史工作。即使新建会话，长期记忆仍可能帮助智能体记住员工喜欢的日报格式。

“事实、摘要、全部”是什么意思？

在 「设置 → 记忆」 中：

事实：一条条具体信息，例如“用户偏好简洁的日报格式”；
摘要：把较多历史信息概括成整体背景；
全部：同时查看事实和摘要。

部分版本中的摘要区域为只读，事实则可以手工维护。

上下文窗口怎么查看？

进入 「设置 → 模型 → 编辑模型 → 高级设置」，可以查看或填写“上下文窗口”和“最大输出 Token 数”。

上下文窗口：模型一次能够处理的内容上限；
最大输出 Token：单次生成内容的上限。

如果留空，不能直接理解为“无限制”或“默认 128K”。实际还要看模型服务及运行配置。聊天界面里显示的累计 Token 用量，也不等于当前上下文占用量。

七、DeerFlow 怎样对接微信？

DeerFlow 支持微信 iLink 消息渠道。大致逻辑是：

员工微信发送消息
       ↓
微信渠道接入 DeerFlow
       ↓
识别微信用户、找到对应会话
       ↓
智能体执行任务（必要时调用 MCP）
       ↓
将结果回复到微信

1. 先开启微信渠道

下面是一个示意配置，具体字段要以所部署版本的 config.yaml 和官方文档为准：

channels:
  session:
    assistant_id: lead_agent
  wechat:
    enabled: true
    qrcode_login_enabled: true
    allowed_users: []
    state_dir: ./.deer-flow/wechat/state

channel_connections:
  enabled: true
  require_bound_identity: false
  wechat:
    enabled: true

其中：

channels.wechat.enabled：开启微信消息渠道；
qrcode_login_enabled：允许首次初始化时通过二维码建立微信机器人连接；
channel_connections.enabled：开启渠道账号连接管理功能；
require_bound_identity: false：允许未绑定 DeerFlow 登录账号的微信身份在开放机器人模式下使用。

安全提醒：allowed_users: [] 在微信渠道中代表不限制微信用户。如果是公司内部使用，不能只依赖这个开放配置，至少应增加员工准入、账号绑定和业务权限校验。开放模式也要确认不同微信身份分别落入独立的运行数据空间。

2. 微信扫码其实有两种，不要混淆

第一种：初始化机器人。管理员按 DeerFlow 的 iLink 流程扫码，让 DeerFlow 获得微信渠道连接凭据。这不是“给每个员工绑定公司身份”。

第二种：员工身份绑定。如果员工已经有 DeerFlow 账号，官方提供“在设置页面生成一次性连接码 → 微信向机器人发送 /connect <code>”的连接流程。

但是，如果公司的要求是“DeerFlow 只保留一个管理员登录账号，普通员工不注册 DeerFlow”，则不应该把所有员工都绑定到管理员账户。更适合采用开放渠道身份隔离，再额外建立与公司业务用户的绑定关系。

微信机器人通常通过主动轮询接收消息，不需要专门给微信开放公网回调地址；但服务器仍须能够访问相应微信服务，并保存渠道状态。Docker 部署时要持久化 state_dir，防止容器重建后丢失登录状态。

3. 多个员工可以用微信与同一个智能体聊天吗？

可以实现这种体验，但要区分“渠道支持多人”与“自定义智能体是否共享”。

微信渠道本身可以接收不同员工发来的消息；
不同微信用户的会话可以分开保存；
但管理员创建的自定义智能体默认归管理员所有，不能直接假定其他独立用户都能调用它。

如果先验证“全公司共用一个日报助手”，可以暂时将默认主智能体配置为日报用途，测试多人对话。若要让员工直接使用管理员创建的某个自定义智能体，需要再做共享范围与路由权限适配。

八、只有一个管理员，怎样让全公司员工使用日报智能体？

这是一个比较典型的企业需求：

DeerFlow 只有 admin 一个后台管理账号；管理员创建并维护“日报填写助手”；员工不进入 DeerFlow，只用自己的微信聊天。

建议把系统拆成两个身份：

管理身份：一个 admin，负责模型、MCP、智能体和平台配置；
使用身份：员工的微信渠道身份，负责识别“谁在聊天”，不能都当作 admin。

一个简单的落地顺序：

管理员部署 DeerFlow、配置模型与日报 MCP；
创建和测试日报智能体；
启用微信渠道，让几个员工测试独立聊天；
增加“管理员智能体共享”或固定的公共智能体路由；
最后实现员工微信与公司用户的身份绑定。

其中第 4、5 步通常属于面向公司业务的适配开发，不是扫码之后 DeerFlow 就自动全部完成。

九、最关键的一步：微信用户如何对应公司系统员工？

假设公司日报系统中：

张三的业务用户 ID 是 10001；
李四的业务用户 ID 是 10002。

张三通过微信发消息：“帮我查昨天的日报。”系统不能只靠大模型猜测他是谁，必须先可信地把微信身份绑定到公司用户 ID。

推荐：首次绑定一次，以后自动识别

① 员工登录公司业务系统（已验证身份）
              ↓
② 选择“绑定微信智能助手”
              ↓
③ 生成短时有效、一次性绑定码或绑定页面
              ↓
④ 员工在微信完成绑定确认
              ↓
⑤ 后端核对：公司用户身份 + 真实微信渠道身份
              ↓
⑥ 保存关联关系，之后微信聊天自动识别员工

如果希望做到“只扫码、不输入命令”，可以开发绑定 H5 页面或微信适配入口；但不能认为普通网页一打开就天然获得了可靠的微信用户 ID。具体身份获取和确认方式，取决于采用的微信接口、授权能力及机器人渠道，必要时要设计一次性绑定码作为补充。

可以在业务系统中保存一张关联表（以下为示例数据）：

微信渠道身份	公司用户 ID	绑定状态
wx_user_a	10001	已绑定
wx_user_b	10002	已绑定

这里要使用渠道提供的稳定身份标识，不能用微信昵称作为唯一身份。

绑定成功后，查日报的完整过程

张三在微信中说：“查一下我昨天的日报”
                  ↓
DeerFlow 收到消息，识别渠道用户 wx_user_a
                  ↓
绑定服务查到：wx_user_a → 公司用户 10001
                  ↓
日报智能体调用查询日报的 MCP
                  ↓
业务系统验证身份和数据权限，只查询 10001 可访问的数据
                  ↓
DeerFlow 将查询结果回复给张三

最重要的安全原则：不能让大模型随意传入 user_id=10002 就查到李四的数据。身份必须由可信后端确定，业务系统还要再次鉴权。实际对接中可以使用短期用户授权凭据、可信网关或 MCP 请求拦截器注入经过验证的身份信息。

DeerFlow 另外提供面向平台后端的 Internal Auth：受信任的后端可以调用 DeerFlow API，并使用独立的运行用户标识区分不同员工，而不必为每个员工创建 DeerFlow 登录账号。它适用于自建微信接入层或企业系统主动调用 DeerFlow 的场景；平台密钥只能放在后端，不能发给员工或前端页面。

十、沙箱和文件管理简单了解

智能体要分析 Excel、运行 Python、生成报告，就需要一个实际执行任务的环境，这就是 Sandbox（沙箱）。

例如，员工上传一个 Excel，要求统计数据，DeerFlow 可以在沙箱中读取文件、执行分析脚本、生成图表，然后把结果作为文件提供给员工。

常见沙箱模式：

模式	通俗解释	适合场景
Local	在运行环境中直接执行，隔离较弱	本地开发测试
Docker AIO	在独立容器内执行任务	多用户部署
K8s Provisioner	通过 Kubernetes 创建独立执行环境	生产环境、规模化运行
E2B 等	使用外部沙箱服务	根据基础设施选择

DeerFlow 的文件通常与用户 + 会话关联，上传文件、工作文件和输出成果分开组织。文件归属隔离与沙箱安全隔离是两件事：即使会话目录分开，多人正式使用时仍建议采用容器化沙箱，并限制网络、资源和可访问目录。

十一、定时任务和数据同步怎么做？

DeerFlow 还支持定时任务，例如“每天晚上提醒我填写日报”“每周五生成工作周报”。常见调度方式包括单次执行、Cron 周期执行以及固定间隔执行，具体能力以版本和调度配置为准。

如果想把聊天或任务结果写回公司系统，需要区分两种情况：

需求	适合的方式
员工主动要求保存日报	智能体调用日报 MCP / API
平台需要持续保存全部会话、任务状态或运行审计	后端事件、API 拉取或自行开发 Webhook 同步

不要只靠 Prompt 要求智能体“每次聊天都调用 MCP 保存记录”。模型可能漏调用工具。平台级同步应由后端确定性地完成。

十二、实际落地时，我会先验证哪些事情？

如果要做“一个管理员维护、多名员工通过微信使用公司日报智能体”，建议按这个顺序测试：

模型可用：在网页上能正常对话、调用工具。
智能体可用：日报助手的角色、Skill、MCP 都能工作。
微信可用：至少两名员工能分别发消息并收到回复。
会话隔离：张三、李四的聊天历史不混用。
记忆隔离：不同员工的个人偏好不互相串用。
共享能力：管理员维护的同一份日报智能体可以被授权员工调用。
身份绑定：微信身份能准确匹配公司系统员工，支持解绑和重新绑定。
业务权限：张三不能通过改写提示词查到李四的日报。
文件与安全：上传文件、生成文件、MCP 凭据和沙箱互不越权。
稳定性：微信断连、服务重启、任务失败后能恢复或重试。

十三、总结

DeerFlow 可以理解为一套让大模型真正执行任务的智能体框架。它不仅有聊天能力，还具备模型配置、自定义智能体、Skill、MCP、子智能体、会话、记忆、沙箱、文件、定时任务和消息渠道等能力。

对于“公司统一使用智能体”这个场景，最值得记住的是四句话：

管理员账号负责配置，不等于所有员工都应该共享管理员身份。
微信扫码初始化机器人，不等于员工已经完成公司身份绑定。
共享智能体配置与隔离员工会话、记忆，是两个需要同时满足的目标。
MCP 负责执行业务操作，真正的数据访问权限必须由业务后端校验。

把这些关系理顺后，就能比较清楚地区分：DeerFlow 哪些能力开箱即用、哪些需要配置、哪些需要针对企业实际业务做适配。

官方参考资料

posted @ 2026-11-05 09:42 人艰不拆_zmc 阅读(19) 评论(0) 收藏举报

刷新页面返回顶部