Skill 可以说「用 web_search 再 write_file」，没有工具的话这些词只是空话。用户让 agent「搜今天 AI 新闻并存成 Markdown」时，真正发生的是：调搜索后端、在沙箱写文件、再用 present_files 交给前端。Tools 是 agent 对外交互的通道，在 config.yaml 声明，按场景装配。

让 agent 写「带引用的行业对比报告」时，若没有固定流程，常见结果是随便搜几条、不落盘、格式散。Skills 把可复用步骤写成 Markdown 操作手册：系统提示词里先放技能目录，agent 需要时再读全文，按手册一步步做，报告结构更稳。

用户要调研 Cursor、Windsurf、Cline 三款工具并各写约五百字分析时，单个 Lead Agent 只能串行：搜完 A 再写，再搜 B。总耗时接近单任务的三倍，搜索过程里的噪声还会堆进主上下文，后面的判断越来越糊。DeerFlow 用 Sub-Agents 把这件事拆开：主智能体当项目经理，多个子代理各自开工，最后只交回结构化结果。

网页 Gateway 解决了浏览器侧的登录与 API。实际办公里更常见的入口是飞书、Slack、Telegram、钉钉：在聊天窗口 @ 机器人一句，就把任务丢给 agent。各平台消息格式、认证方式和限流策略都不一样，按平台各写一套调度逻辑会迅速失控。DeerFlow 的 IM Channels 把外部消息翻译成统一入站结构，经 MessageBus 交给 agent，再把回复翻译回原平台。渠道只负责收发，调度与线程映射集中在 Manager；新增一个平台，主要是实现一个 Channel 子类，不必复制半套运行时。

网页里输入「查今天天气」并发送，浏览器实际打的是类似 POST /api/threads/{id}/runs/stream 的请求。服务器必须确认调用者身份、是否有权访问该 thread、是否伪造跨站请求，还要把流量路由到正确 handler。这些逻辑若复制到每个接口，既难维护也容易漏洞。DeerFlow 用 FastAPI 构建 Gateway，把路由分发、身份认证、权限校验、用户隔离和 CSRF 防护收成统一入口；进门之后才轮到 Runtime 起 run、SSE 推流。多用户并存时，「张三看不到李四的对话」也靠这一层兜住。