DeerFlow 配置系统权威指南：config.yaml 与 extensions_config.json 的加载机制、热重载边界与运维实践

DeerFlow 配置系统权威指南config.yaml 与 extensions_config.json 的加载机制、热重载边界与运维实践【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow导读DeerFlow 的运行时行为由两份配置协同驱动以config.yaml为主体的AppConfig管理模型、工具、沙箱、内存、子代理等核心能力以extensions_config.json为载体的ExtensionsConfig负责 MCP 服务器与技能Skills的接入与运行时扩展。本文以仓库内 backend/packages/harness/deerflow/config/AGENTS.md 为骨架结合配置加载、缓存签名、热重载边界等底层源码实现完整梳理这两份配置文件的查找优先级、版本升级、自动重载、重启边界以及字段语义。读完你将能够独立完成 DeerFlow 的首次配置、安全地做“热更新”、准确判断哪些字段修改后必须重启 Gateway并掌握持久化后端与扩展配置的选型要点。一、配置家族总览两份文件、两套模型DeerFlow 把“主运行配置”和“扩展接入配置”刻意拆成两份独立文件二者有各自的解析器、查找路径和加载生命周期配置文件项目根目录Pydantic 模型解析入口承载内容主配置config.yamlAppConfigAppConfig.from_file()models、tools、sandbox、skills、memory、database等核心运行参数扩展配置extensions_config.jsonExtensionsConfigExtensionsConfig.from_file()MCP 服务器mcpServers、技能开关skills、中间件middlewares从源码目录看二者都属于 backend/packages/harness/deerflow/config 配置包config.yaml由 app_config.py 负责解析extensions_config.json由 extensions_config.py 负责解析。值得一提的是AppConfig.from_file()在加载主配置时会顺带调用ExtensionsConfig.from_file()读取扩展文件并把config.yaml中声明的extensions字段目前支持middlewares以逐字段覆盖的方式合并进扩展配置详见本文第七节因此在运行时两者是同一个配置视图。官方推荐的部署形态是把config.yaml放在项目根目录repository rootbackend/与 Gateway 进程通过上溯查找来发现它。仓库根目录自带的 config.example.yaml 与 extensions_config.example.json 就是各自的标准模板。二、查找优先级显式参数、环境变量与目录上溯2.1config.yaml的四级查找链AppConfig.resolve_config_path()见 app_config.py按如下顺序解析配置文件路径显式config_path参数——代码调用AppConfig.from_file(config_path...)时直接指定DEER_FLOW_CONFIG_PATH环境变量——适合容器/编排场景指定绝对路径当前目录下的config.yaml——即backend/目录内父目录项目根目录下的config.yaml——官方推荐位置。第 3、4 级本质是搜索模式解析逻辑会调用existing_project_file((config.yaml,))在调用方所在目录及其父目录中向上寻找。源码中还保留了_legacy_config_candidates()兼容查找用于 monorepo 场景下回退到旧的 backend/仓库根默认位置。只有当全部搜索都失败时resolve_config_path()才抛出FileNotFoundError。2.2extensions_config.json的查找链与可选语义ExtensionsConfig.resolve_config_path()见 extensions_config.py的优先级与主配置完全一致显式config_path参数DEER_FLOW_EXTENSIONS_CONFIG_PATH环境变量当前目录backend/下的extensions_config.json向后兼容mcp_config.json父目录项目根目录下的extensions_config.json——官方推荐位置。但扩展配置有一个关键差异前两级是显式断言后两级是可选回退。当既没传显式参数、也没设环境变量且搜索位置都没有找到文件时ExtensionsConfig.resolve_config_path()返回None系统按未配置扩展处理正常运行MCP 服务器与技能都是可选项。反之一旦操作者显式传了config_path或设置了DEER_FLOW_EXTENSIONS_CONFIG_PATH就意味着必须使用这一个文件——文件不存在哪怕之前存在、后来被删除会直接抛出FileNotFoundError让配置错误尽快暴露。2.3 MCP 工具缓存的热路径特例主规则之外存在一个刻意收窄的例外MCP 工具缓存的过期检查backend/packages/harness/deerflow/mcp/cache.py 中的_resolve_config_path会在本地捕获上述FileNotFoundError把它视作未配置。这样做的原因是如果运行中一份原本有效的extensions_config.json被删掉缓存不应在每次请求的热路径上直接抛异常而是降级为继续服务最后一次已知有效的工具集合。2.4 Docker 开发环境中的挂载约束Docker 开发模式会把项目目录挂载到容器内/app/project并把DEER_FLOW_CONFIG_PATH/DEER_FLOW_EXTENSIONS_CONFIG_PATH都指向该目录。官方文档特别提醒可变配置文件要放在目录 bind mount下而不是单文件 bind mount。原因是宿主机编辑器在保存时常以替换文件的方式写盘单文件挂载在文件被替换后可能失效或读到陈旧内容目录挂载则能持续跟随宿主机文件的变化。三、首次配置与配置版本化Config Versioning3.1 起步复制模板无论使用哪种部署方式第一步都是把示例配置复制为正式配置# 在项目根目录执行 cp config.example.yaml config.yamlconfig.example.yaml顶部注释明确说明默认配置文件路径是项目根目录下的config.yaml可通过DEER_FLOW_PROJECT_ROOT显式定义该根目录或用DEER_FLOW_CONFIG_PATH指向特定文件运行期状态默认落在根目录的.deer-flow下可用DEER_FLOW_HOME改到其他可写数据目录。3.2config_version的检测与自动合并config.example.yaml中有一个config_version字段当前示例版本为40。每次配置 schema 发生变更时开发者都应在config.example.yaml中递增该版本号。Gateway 启动时AppConfig._check_config_version()见 app_config.py会做如下比较读取用户config.yaml的config_version在用户配置文件目录向上最多 5 层搜索config.example.yaml取其config_version用户版本低于示例版本时打印告警config.yaml (version N) is outdated缺失config_version视为版本 0pre-versioning 时代的配置同样会被识别为过时告警文本直接给出修复命令运行make config-upgrade自动合并缺失字段。版本比较在解析流程的最前端执行——from_file()中先调用_check_config_version(config_data, resolved_path)再做后续的环境变量替换与模型校验。升级合并命令对应根目录 Makefile 的config-upgradetarget第 82-83 行实际执行 scripts/config-upgrade.sh它会以config.example.yaml为蓝本把用户文件缺失的新增字段自动合并进本地config.yaml。3.3 配套容错整段注释导致的nullconfig.example.yaml中大量区块以整段注释方式呈现例如models:下面只有注释示例。PyYAML 会把这类只有注释的顶层键解析成None若不做处理cp config.example.yaml config.yaml后首次启动就会收到晦涩的 pydantic 校验错误。为此AppConfig提供了一个model_validator(modebefore)钩子_drop_null_config_sections()见 app_config.py解析前剔除值为None的顶层节让各字段回退到默认值list 节回退为[]对象节回退为默认配置对象。注意sandbox这类没有默认值且必填的节即使为空也会正确报错因为没有可回退的默认值。四、配置缓存与签名式自动重载4.1get_app_config()单例 自动重载跨模块的兼容层通过get_app_config()见 app_config.py暴露配置实例。它返回一个进程内缓存单例但会在以下两种情况下自动重新加载解析出的配置文件路径发生变化例如运行时DEER_FLOW_CONFIG_PATH指向了别的文件文件内容签名变化。模块级状态记录了_app_config_path、_app_config_mtime与_app_config_signature。每次调用get_app_config()都会重新 stat 文件并计算签名三者任一不同即触发重载并刷新缓存元数据。若需要强制重载或清空缓存可调用reload_app_config()/reset_app_config()。4.2 内容签名为什么 mtime 不够配置文件签名的核心实现在 file_signature.py。签名是一个(mtime, size, sha256_hexdigest)三元组设计目标是覆盖裸 mtime 比较会漏掉的一类场景同一秒内的两次编辑mtime 粒度不够mtime 保持不变或倒退的操作git checkout、保留时间戳的cp -p/ 备份还原、tar/rsync切换到另一个 mtime 小于等于旧记录的新文件对象存储 / 网络挂载上 mtime 可能长期陈旧的场景。实现上有两个值得注意的细节即使 mtime 与 size 都没变仍会全量计算 sha256。因为同一秒内换入字节数相同但内容不同的文件会让 mtime 和 size 都保持不变只有内容摘要能发现这种替换若文件无法 stat整个签名返回None文件不存在是独立状态若 stat 成功但内容不可读则返回(mtime, size, None)的部分签名。正是这套(mtime, size, sha256)机制保证了 Gateway 与 LangGraph 的读取始终能对齐config.yaml的编辑结果——即便跑在 mtime 不可靠的挂载上。config/app_config.py与mcp/cache.py两个调用方共享这一份实现避免相同逻辑复制漂移。4.3 附带优化O(1) 名称索引AppConfig在校验后通过_build_name_indexes()见 app_config.py为models、tools、tool_groups建立name - config的字典索引使get_model_config()/get_tool_config()/get_tool_group_config()变成 O(1) 查找而非 O(n) 顺序扫描。这些查找位于每次 agent 构建与工具调用的热路径上例如一次web_search工具调用可能触发 2-3 次get_tool_config。由于每次配置重载都会构造全新的AppConfig索引也随之重建重复名称通过setdefault保留首个条目维持旧的首匹配语义。五、热重载边界下一条消息生效还是必须重启这是 DeerFlow 配置系统最重要的心智模型运行类字段可以热更新基础设施字段必须重启。其背后动机来自仓库 issue #3144 描述的场景——Gateway 的请求依赖每次请求都通过get_app_config()解析AppConfig因此每轮运行per-run字段在下一条消息上就能生效不必重启整个服务。5.1 无需重启下一条消息即生效的字段Gateway 请求依赖链每次请求都会穿透到get_app_config()因此对config.yaml的编辑会在下一条消息被感知覆盖以下字段族models[*].max_tokens等模型级运行参数summarization.*上下文压缩title.*自动标题生成memory.*记忆系统subagents.*子代理委托总开关verification.*工具结果校验tools[*]工具配置Agent 系统提示词system prompt。架构上有一个明确的约束AppConfig有意不缓存到app.state。lifespan()中保留一个局部变量startup_config只服务于一次性启动引导工作并把它传给langgraph_runtime(app, startup_config)。这样每个请求仍然走get_app_config()的最新值而启动期已经完成的一次性装配引擎、单例、IM 客户端等不会被新配置意外半刷新。5.2 必须重启STARTUP_ONLY_FIELDS注册表基础设施字段在启动时被一次性捕获引擎、单例、通道客户端、日志 handler运行期改动config.yaml不会重建它们因此需要重启 Gateway。权威清单只存在于一处reload_boundary.py模块中的STARTUP_ONLY_FIELDS字典见 reload_boundary.py它把每个重启必改字段映射为人类可读的为什么 重启哪个子系统。当前注册的字段与原因如下表注册路径启动期捕获位置修改后需要做什么pluginsload_extensions()仅在create_app()时运行一次进程级中间件注册表不会因编辑重建增删改插件需重启databaseinit_engine_from_config()在langgraph_runtime()启动时执行SQLAlchemy 引擎持有连接池切换后端需重启含postgres_schemacheckpointermake_checkpointer()启动时绑定持久化 checkpointer含 SQLite WAL / busy_timeout修改需重启run_eventsmake_run_event_store()启动时选定 memory 版 / SQL 版实现冻结在app.state.run_events_config切换实现需重启agent_storagelanggraph_runtime()启动时校验backend与database.backend是否一致db 后端的同步引擎首次使用后进程级缓存切换后端需重启stream_bridgemake_stream_bridge()启动时构造流桥单例修改需重启sandboxget_sandbox_provider()缓存 provider 单例_default_sandbox_provider换sandbox.use类路径需重启skills.container_pathAIO / E2B Provider 启动时规范化并固化 skills 挂载根沙箱身份、挂载、远端元数据、技能同步都依赖这一固定根修改该挂载根需重启log_levelapply_logging_level()仅在 app 启动时运行修改需重启loggingconfigure_logging()仅在启动时安装/移除 trace-context filter 与增强 formatter修改logging.enhance.*需重启channelsstart_channel_service()启动时启动 IM 通道客户端飞书、Slack、Telegram、钉钉修改channels.*需重启channel_connections启动时接线连接仓库与通道 worker路由器把合并后的 provider 配置缓存在app.state修改需重启schedulerScheduledTaskService启动时构建并启动后台轮询任务不重建修改需重启所有 Gateway Pod涉及多实例租赁mcp_tasksMcpTaskService启动时构建并启动后台轮询修改需重启subagent_runtime共享的原生子代理准入控制器与隔离执行循环启动时配置改进程槽位/队列策略需重启subagent_batches持久化子代理批服务启动时构建修改调度限额/租赁需重启run_ownershipRunOwnershipConfig在langgraph_runtime()启动时被捕获进RunManager租赁心跳后台任务随之创建修改需重启dedupe_storagemake_inbound_dedupe_store()在 ChannelService 构建时解析去重存储进程内 memory 或共享 Postgres修改需重启5.3 双向防漂移机制startup-only:前缀为了让运维人员在 IDE 里直接看到这字段要重启注册表与 schema 之间建立了一条双向钉死的约束所有注册字段的Field(description...)都通过format_field_description()生成统一的startup-only:前缀见 reload_boundary.py并在前缀后附带该字段的正常文档说明前缀文本就是注册表里的人类可读原因因此把鼠标悬停在 IDE 的字段上即可看到重启原因无需来回翻查文档表格新增一个重启必改字段必须同时更新注册表任何 schema 字段只要用了startup-only:前缀就必须在注册表里登记这种漂移由 backend/tests/test_reload_boundary.py 的测试双向强制注册的字段必须带此前缀带此前缀的字段必须已注册。任何文档扫描器 / lint 钩子 / 文档生成器都应基于这份注册表驱动而不是去重新解析散文。5.4 例外scheduler.recursion_limit整个注册表里有一个刻意设计的例外scheduler.recursion_limit不在scheduler的启动期快照范围内。launch_scheduled_thread_run在每次定时派发时通过get_app_config()现读该值因此对它的 YAML 编辑会作用于下一次定时运行无需重启轮询器。这意味着你可以放心热调定时任务的递归深度上限。5.5logging.enhance的精确边界logging.enhanceenabled/format只控制日志输出——即日志记录是否携带trace_id字段、以何种格式携带。需要明确的是Trace ID 的签发是无条件的——Gateway 的X-Trace-Id响应头与 Langfuse 的deerflow_trace_id元数据无论该开关如何配置都始终存在详见 backend/packages/harness/deerflow/AGENTS.md 的 Request Trace Context 一节。该字段位于注册表中属于重启必改项。六、持久化后端解析database与兼容层checkpointer新版配置引入统一的database节作为Gateway 的 LangGraph checkpointer、LangGraph Store 与 DeerFlow SQL 仓库三者共用的后端选择器。仓库根 config.example.yaml 中该节的默认形态为database: backend: sqlite sqlite_dir: .deer-flow/dataapp_config.py中的_apply_database_defaults()见 app_config.py会在该节缺失时自动补上backend: sqlite与sqlite_dir: .deer-flow/data两个默认值保证开箱即用。兼容层规则如下已废弃的checkpointer节仍然向后兼容当checkpointer存在时它仅对 LangGraph checkpointer 与 Store 生效覆盖database的同名职责应用仓库application repositories即 DeerFlow 自己的 SQL 仓储始终跟随database。源码注释还解释了为什么database的重载边界如此严格database是重启必改字段init_engine_from_config()在启动时构建 ORM 引擎且不会因编辑重建。如果只热重置 checkpointer/Store 单例而不重启会造成半迁移——checkpoint 表落进新 schema而 ORM 行仍写旧 schema且没有任何错误暴露。要求文档化的重启能保证部署自洽。另一个关联细节在_apply_singleton_configs()见 app_config.py当旧的checkpointer配置变化时运行时会调用reset_checkpointer()/reset_store()重置相应单例使依赖 checkpointer 后端的运行时单例同步刷新。title、summarization、memory、subagents、tool_search、guardrails、authorization、stream_bridge等小节也在加载时同步到各自的进程内单例层保证热更新后行为一致。七、config.yaml顶层 Schema 速览从 config.example.yaml 的节标题与 app_config.py 的字段声明可归纳出以下核心分区7.1 模型与工具models[]LLM 配置列表。核心字段包括use类路径形如package.module:Class、supports_thinking、supports_vision以及各 provider 专属字段。示例片段doubao-seed-1.8展示了完整的声明形态models: # - name: doubao-seed-1.8 # use: deerflow.models.patched_deepseek:PatchedChatDeepSeek # model: doubao-seed-1-8-251228 # api_base: https://ark.cn-beijing.volces.com/api/v3 # api_key: $VOLCENGINE_API_KEY # context_window: 262144 # supports_thinking: true # supports_vision: true配置值以$开头的会被resolve_env_variables()递归解析为环境变量如$OPENAI_API_KEY且环境变量缺失时直接抛出ValueError避免带空密钥启动。ModelConfig还声明了use_responses_api与output_version两个字段可在仍使用langchain_openai:ChatOpenAI的前提下显式开启 OpenAI/v1/responses。tools[]工具配置含use变量路径与group。tool_groups[]工具的逻辑分组。补充模型约定vLLM 推理模型应使用deerflow.models.vllm_provider:VllmChatModel对 Qwen 风格解析器优先使用when_thinking_enabled.extra_body.chat_template_kwargs.enable_thinking配置DeerFlow 也会把旧的thinking别名归一化处理。7.2 沙箱、技能与代理sandbox.use沙箱 provider 类路径。默认示例为本地 providerdeerflow.sandbox.local:LocalSandboxProvider其中allow_host_bash默认false本地 provider 并非安全隔离边界并支持mounts数组把宿主目录以只读/读写方式映射进沙箱。skills.path/skills.container_path宿主与容器内的技能目录。AIO 与 E2B provider 会在启动时快照container_path其本地/远端后端与 Kubernetes provisioner 要求该路径是保留平台挂载之外的一个规范化绝对非根路径自定义根参与确定性沙箱身份E2B 还会把根记录进远端元数据。这正对应注册表中skills.container_path这一条嵌套的重启必改项同一节里唯一一个边界与其他叶子字段不同的。skills.deferred_discovery默认false沿用全量元数据注入。置为true时把包含完整元数据的available_skills提示词块替换为紧凑的skill_index仅技能名并注册describe_skill工具让 agent 按需拉取元数据——这是延迟技能发现模式的总开关。7.3 标题、压缩、子代理与记忆title自动标题生成enabled、max_words、max_chars、model_name。model_name为null时走快速本地回退显式指定model_name时走prompt_template的 LLM 路径。summarization上下文压缩enabled、触发条件、保留策略。subagents.enabled子代理委托的主开关。subagent_runtime重启必改原生子代理共享的进程内准入控制——max_running、有界异步等待队列、queue/reject 策略与队列超时普通子代理与持久化批量子代理共用。subagent_batches重启必改持久化批量子代理的显式调度限额默认关闭含 total / live / running 三个维度以及 leases / retries / 结果上限。memory记忆系统全套参数——enabled、storage_path、debounce_seconds、shutdown_flush_timeout_seconds、model_name、max_facts、fact_confidence_threshold、injection_enabled、max_injection_tokens以及陈旧记忆复核staleness review一族的staleness_review_enabled、staleness_age_days、staleness_min_candidates、staleness_max_removals_per_cycle、staleness_protected_categories、staleness_max_lifetime_multiplier、staleness_max_extension_days。7.4 其他值得注意的顶层节config.example.yaml中还包含token_usage、token_budget、max_recursion_limit、tool_search、tool_output、suggestions、input_polish、loop_detection、read_before_write、safety_finish_reason、uploads、skill_scan、agents_api、skill_evolution、run_events、agent_storage、run_ownership、authorization、scheduler、mcp_tasks等节分别对应各自的行为开关。定时任务节的参考形态为scheduler: enabled: false multi_instance: false # 跨 Gateway 实例开启租赁感知恢复 poll_interval_seconds: 5 lease_seconds: 120 max_concurrent_runs: 3 queue_timeout_seconds: 3600 min_once_delay_seconds: 60 recursion_limit: 1000 # 例外每条调度消息现读可热更新与入站去重相关的dedupe_storage节在config.example.yaml中给出了详尽的选型注释backend: auto默认在database.backendpostgres时走 Postgres、否则回退进程内 memory storememory只限本进程多副本下不同副本收到的重投 webhook 无法去重不适合多 worker 部署postgres通过应用库跨 Pod 共享去重状态是多副本部署的必选项。八、extensions_config.jsonSchema 详解仓库根目录的 extensions_config.example.json 展示了扩展配置的完整形态其顶层含三个键mcpServers、skills、middlewares另有mcpInterceptors示例。8.1mcpServersMCP 服务器注册表每个条目是服务器名 - 配置对象支持字段enabled、typestdio/http/sseMCP 规范里的transport写法会被normalize_mcp_transport_alias自动归一化为type、command、args、env、url、headers、oauth、description、routing、tools、tool_call_timeout、session_init_timeout。一个 stdio 型 GitHub 服务器与一个 HTTP 型 OpenViking 服务器的完整示例都在extensions_config.example.json中可直接照抄。两个超时字段的语义边界值得精确记忆session_init_timeout约束服务器拉起即工具发现与持久化 stdio 会话初始化避免一个挂死的服务器无限阻塞 agent 构造。默认值取自DEFAULT_MCP_SESSION_INIT_TIMEOUT即60 秒设为null可禁用。普通 HTTP/SSE 任务的临时会话初始化也复用它。tool_call_timeout约束单次工具调用。在所有传输上约束 stdio 调用与持久化任务调用其余 HTTP/SSE 工具使用传输层超时。routing与tools提供软路由提示routing.modeprefer时向模型上下文注入mcp_routing_hints提示priority取值被钳制在 0-100数值大者先渲染keywords是操作者编写的何时优先用此工具关键词。当tool_search延迟工具加载把被提示的工具延后时McpRoutingMiddleware还可在模型调用前自动提升auto-promote匹配的延迟 schema——但它不会硬性禁用其他工具。逐工具的tools.toolname.routing可为单个工具覆盖服务器级路由见示例中 postgres 服务器对query工具的priority: 100覆盖。与mcpServers并列的task_toolsets可把服务器声明为普通 MCP 后台任务契约以submit_tool/status_tool/cancel_tool三个原始工具名绑定到稳定的本地任务名如示例中的report-generation。8.2 全局 MCP 路由参数tool_search.auto_promote_top_k该值在config.yaml的tool_search节配置见 app_config.py 中ToolSearchConfig的加载默认3、钳制在1..5。生效条件苛刻且安全仅当tool_search.enabledtrue时生效仅作用于routing.modeprefer且keywords非空的延迟 MCP 工具对 lead agent延迟目录由全量配置的 MCP 集合构建自动提升绝不授予权限——某个活动技能的运行时策略仍会过滤模型可见的 schema、tool_search结果与执行过程。也就是说路由提升改变的只是模型看到哪些 schema而非哪些工具能被执行。8.3skills与middlewaresskills技能名 - {enabled: bool}的状态映射控制哪些技能对 agent 可见/可用。middlewares零参数AgentMiddleware类路径列表同时作用于 lead 与 subagent 运行时目前无法分别配置。这些文件应视为可信操作者配置因为中间件会执行代码。config.yaml - extensions可以在校验后覆盖这里的字段——覆盖是逐字段replace-per-field而非列表拼接即config.yaml里声明的extensions.middlewares会整体替换而非追加extensions_config.json中的同名列表。8.4 运行时修改与原子写入Gateway API 端点与DeerFlowClient方法可以在运行期增删改 MCP 服务器、切换技能状态它们对extensions_config.json的写入统一走共享的原子替换辅助函数先写临时文件再替换见 extensions_config.py 中的原子写实现避免半写文件被读取。相比之下middlewares属于操作者控制的纯配置文件扩展点不通过运行时 API 暴露。九、端到端配置工作流小结综合以上机制一套推荐的 DeerFlow 配置运维工作流是初始化cp config.example.yaml config.yaml按需编辑扩展接入编辑项目根目录的extensions_config.json模板见extensions_config.example.json。多环境容器或 CI 中通过DEER_FLOW_CONFIG_PATH/DEER_FLOW_EXTENSIONS_CONFIG_PATH显式指文件显式模式文件缺失会立刻报错本地开发依赖目录上溯查找把配置放项目根目录即可。升级升级 DeerFlow 版本后若日志提示config.yaml过时运行make config-upgrade自动合并新字段若升级后配置仍报 schema 错误多半是某节被整段注释成null可直接删除该节让默认值接管。热更新判定改动models[*].max_tokens、summarization.*、title.*、memory.*、subagents.*、verification.*、tools[*]或系统提示词保存即可在下一条消息生效改动上表列出的任何重启必改字段或直接在 IDE 中看到字段描述带startup-only:前缀必须重启 Gateway。scheduler.recursion_limit与config.yaml的extensions.middlewares属于例外可分别按调度轮与消息级生效。持久化选型新部署一律在database节统一声明后端只有需要checkpointer/Store 走一套、应用仓库走另一套的过渡期才使用已废弃的checkpointer节覆盖前者。多副本部署务必把dedupe_storage指到 Postgres。故障排查配置未生效时先确认文件路径是否真的落在解析链路上扩展文件的可选回退与显式断言行为不同若显式路径下文件被误删Gateway 会明确抛FileNotFoundError而 MCP 工具缓存则会降级到最后一次已知有效的工具集合继续服务。十、源码导航想深入时读哪些文件以下相对路径可作为进一步阅读的入口配置加载与热重载核心app_config.pyresolve_config_path、from_file、_check_config_version、get_app_config、_build_name_indexes重启边界注册表reload_boundary.pySTARTUP_ONLY_FIELDS、format_field_description及其双向防漂移测试 test_reload_boundary.py内容签名file_signature.pyget_config_signature的(mtime, size, sha256)语义扩展配置extensions_config.py解析优先级、原子写、MCP 路由/超时模型与 MCP 缓存热路径特例 cache.py配置子模型同一目录下的database_config.py、model_config.py、memory_config.py、skills_config.py、sandbox_config.py、subagent_runtime_config.py、scheduler_config.py等按主题逐个精读完整示例config.example.yaml、extensions_config.example.json顶层架构上下文backend/packages/harness/deerflow/AGENTS.mdTrace Context、MCP 系统等交叉引用章节。【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考