03. 配置文件：看懂 config.yaml

配置文件不是填表

很多人跑 Agent 项目，会把配置文件当成“缺什么填什么”。

DeerFlow 不太适合这样看。

它的配置会直接影响任务怎么跑：模型怎么调用、搜索怎么接、MCP server 怎么加载、sandbox 怎么执行、tracing 怎么记录。

所以这一篇先建立配置地图。

先从样例文件看

官方样例在仓库根目录：

config.example.yaml

实际使用时，通常复制成：

config.yaml

不要直接在样例文件上改。这样后面更新官方仓库时，比较容易对照差异。

第一组：模型配置

模型配置决定 Agent 用哪个 provider 和哪个模型。

你需要关心：

provider
model
api_key
base_url
timeout

第一轮只配一个主模型。不要同时配多个 provider，否则出问题时很难判断是哪个模型在响应。

验证方式也很简单：启动后发一个短任务，看日志里是否真的打到了你配置的 provider。

第二组：搜索和抓取

研究型 Agent 需要资料来源。

搜索相关配置一般决定：

用哪个搜索 provider
是否需要 API key
返回多少结果
是否允许抓取网页正文

这里最容易出现的问题是：搜索返回了标题和摘要，但没有拿到正文。写研究报告时，只靠摘要很容易产生幻觉。

所以后面做终局实战时，会强调“拿不到正文就不要硬写”。

第三组：MCP 配置

MCP 让外部工具变成 Agent 可调用能力。

配置里通常会出现 server、transport、command、args、env 这类字段。

建议第一轮只接只读服务。

不要一上来接有写权限的数据库、云服务或内部系统。Agent 还没稳定前，先降低副作用。

第四组：Sandbox 配置

Sandbox 解决的是执行边界。

你要看清楚：

执行在哪里发生
文件保存到哪里
是否允许访问宿主机路径
是否用 Docker 隔离

如果你后面要让 Agent 生成报告、写文件、执行脚本，这一组配置就很关键。

第五组：Tracing 和运行记录

Agent 失败时，最怕只看到一句“任务失败”。

tracing 配置可以帮你看：

模型调用
工具调用
中间事件
最终输出

DeerFlow 仓库里有 tracing 相关模块，配置也会影响能不能把一次 run 看清楚。

推荐配置顺序

不要一次全开。

更稳的顺序是：

模型
|
搜索
|
sandbox
|
tracing
|
MCP
|
memory

每加一组配置，就跑一次小任务验证。

这一篇你要记住

config.yaml 不是启动前的杂项。

它决定了 DeerFlow 这个 Agent 系统能用什么模型、能看什么资料、能调用什么工具、能不能安全地产生文件，以及出错后能不能查清楚。

下一篇开始看整体架构。