DeerFlow 后端开发指南LangGraph 超 Agent 的架构分层、运行时调度与工程实践【免费下载链接】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-flowDeerFlow 是一个基于 LangGraph 的开源长时程long-horizonSuperAgent 系统其后端把沙箱执行、持久记忆、子代理委派与可扩展工具链统一在每线程隔离环境中运行。本文以 backend/AGENTS.md 为主线系统讲解其后端架构分层、运行时核心RunManager / run_agent / StreamBridge、并发与调度约束、常用开发命令、测试纪律与关键功能实现帮助你理解如何在这个仓库中安全地开发、测试与维护一个生产级 Agent 运行时。读完本文你将掌握DeerFlow 后端 Harness 与 App 双层的严格依赖规则及其实施方式、make dev等一键命令背后的完整启动矩阵、LangGraph 图运行与 SSE 流式桥接的底层调用链、调度器与多实例下的并发约束、以及 Plan Mode / 上下文压缩 / 文件上传 / 视觉支持等核心功能的配置与原理。架构概览四端口、三层职责DeerFlow 采用单进程运行 Agent、反向代理统一入口的全栈架构。在开发机上各组件通过固定端口协作组件端口职责Gateway API8001REST API 内嵌的 LangGraph 兼容 Agent 运行时Frontend3000Next.js Web 界面Nginx2026统一反向代理入口对外访问地址为http://localhost:2026Provisioner8002可选仅在沙箱配置为 provisioner / Kubernetes 模式时启动Docker 开发环境可选启用从启动模式看本地前台开发make dev、Docker 开发与生产部署共享同一套 Agent 运行路径Gateway 进程内通过RunManager组织一次运行调用run_agent()并通过StreamBridge对外发布事件流。三者的核心实现都落在 backend/packages/harness/deerflow/runtime/ 目录。Nginx 将/api/langgraph/*重写转发到 Gateway 原生/api/*路由从而让 LangGraph SDK / Studio 客户端能够以 LangGraph 兼容协议访问内嵌运行时。请求 - Nginx(2026) ├── /api/langgraph/* - Gateway(8001) 内嵌 LangGraph 运行时重写为 /api/* ├── /api/* - Gateway(8001) 其他 REST API └── / (非 API) - Frontend(3000) Next.js项目结构一份清晰的代码地图backend/AGENTS.md 给出了从仓库根出发的目录树其关键分层可归纳为根层Makefile根命令入口、config.yaml主应用配置示例见 config.example.yaml、extensions_config.jsonMCP server 与 skills 运行时配置。backend/本篇文章聚焦的后端。packages/harness/deerflow-harness可发布 Agent 框架包导入前缀deerflow.*内含 agent 编排、sandbox、subagent、tools、mcp、skills、config、models 等全部运行时子模块packages/extension-api/面向宿主无关的公开扩展契约导入前缀deerflow_extension_api.*app/FastAPI Gateway 应用层与 IM 渠道接入导入前缀app.*scripts/benchmark/可复现的后端基准评测tests/测试套件docs/细分领域文档。frontend/Next.js 前端。skills/public/提交的公共技能与custom/gitignored 的自定义技能。Harness 包内部再细分以backend/packages/harness/deerflow/为例文档标注了核心子模块的语义agents/LangGraph Agent 系统其中lead_agent/为主 Agent 工厂与系统提示词、middlewares/为中间件链、thread_state.py定义ThreadState模式、sandbox/沙箱执行sandbox.py抽象接口、local/本地文件系统 Provider、tools.py的 bash / ls / read / write / str_replace、middleware.py生命周期管理、subagents/委派系统builtins/通用与 bash Agent、executor.py后台执行引擎、registry.pyAgent 注册表、mcp/、extensions/Python 插件加载器、models/带 thinking / vision 的模型工厂、skills/、config/、community/搜索/抓取、图像搜索、AIO 沙箱等。Harness / App 分层一条 CI 强制执行的依赖铁律DeerFlow 后端刻意拆成两层且依赖方向严格单向Harnessbackend/packages/harness/deerflow/可独立发布为deerflow-harness的 Agent 框架包包含构建与运行 Agent 的一切编排、工具、沙箱、模型、MCP、技能、配置。导入前缀deerflow.*。Appbackend/app/不发布的应用程序代码含 FastAPI Gateway API 与 IM 渠道集成飞书、Slack、Telegram、钉钉。导入前缀app.*。依赖规则一句话App 可以导入 deerflowdeerflow 绝不能反向导入 app。该约束不是口头约定而是由 backend/tests/test_harness_boundary.py 用 AST 静态扫描全部 Harness 包 Python 文件、凡出现from app./import app.即判失败的 CI 测试强制保证。从源码结构看这样的设计保证了 Agent 框架包具备可独立测试、可发布、可被外部宿主嵌入复用的能力。导入惯例示例来自文档并可直接对照代码# Harness 内部 from deerflow.agents import make_lead_agent from deerflow.models import create_chat_model # App 内部 from app.gateway.app import app from app.channels.service import start_channel_service # App - Harness允许 from deerflow.config import get_app_config # Harness - App禁止会挂 CI # from app.gateway.routers.uploads import ... # ← will fail CI配套的还有包导入卫生规则deerflow.agents与deerflow.subagents两个包根对外暴露重量级 graph / executor 入口点但采用惰性加载——如make_lead_agent是 LangGraph Server 解析的具体工厂函数但把 lead-agent 与 skill-cache 的 import 放在函数体内保证导入包本身保持轻量。只需要轻量类型、配置或注册表的内部模块应直接导入具体子模块避免导入包根时连带拉入整个工具图或子代理执行器干扰状态 / schema 导入性能。另一个跨存储一致性细节ThreadMetaStore.search()需保证 JSON 过滤语义在内存、SQLite 与 PostgreSQL 三端完全一致——missing 不同于 null、bool 不同于 int、float 过滤需接受整型或实型 JSON 数值经由json_value_matches。运行时核心RunManager run_agent StreamBridge文档明确所有启动方式下Agent 运行时都由 Gateway 内的RunManagerrun_agent()StreamBridge组成代码位于 backend/packages/harness/deerflow/runtime/。从源码可以进一步定位三者的真实位置RunManager类定义于 backend/packages/harness/deerflow/runtime/runs/manager.py#L219run_agent()协程定义于 backend/packages/harness/deerflow/runtime/runs/worker.py#L761其职责注释为Execute an agent in the background, publishing events to bridge并从RunContext解包 checkpointer、store、event_store、thread_store 等基础设施依赖StreamBridge抽象基类定义于 backend/packages/harness/deerflow/runtime/stream_bridge/base.py#L57。SSE 事件流的两个消费模式围绕流式桥接backend/AGENTS.md 记录了多个必须谨慎处理的契约值得重点理解write_file/str_replace参数增量以有界批次流式输出面向多模式multi-modemessages-tuple消费者单模式single-mode消息消费者则保留原有的逐 chunk契约。非消息帧会先冲刷待发批次values只是可选的完整状态快照而不是批量发送的前提条件。stream_subgraphs启用时子图帧保留自己的命名空间SSE 事件名为values|ns采用 LangGraph Platform 风格而不是伪装成根帧。原因文档以 issue #4399 记录委派子代理会继承父级 checkpoint 命名空间若把它的values快照以裸values发布会整体替换 SDK 客户端视角中的整个线程视图。只关心根运行消费者的组件文件工具 chunk 批处理器、子代理事件持久化、LLM 错误回退检测需要忽略带命名空间的帧。Web 前端不请求子图流式输出子任务进度通过根命名空间的task_*自定义事件上报。后台子代理身份双 ID 刻意分离子代理在后台运行时其身份被刻意拆成两个维度Provider 侧tool_call_id作为关联键贯穿ToolMessage、task_*SSE 事件、持久化的生命周期事件、前端卡片以及公开的ExtensionData.scope_id契约内部存储为SubagentResult.external_task_id。服务端侧execution_id由SubagentExecutor.execute_async()生成作为SubagentResult.task_id用于进程级注册表、轮询、取消、超时处理与清理。关键原因是 Provider 生成的 ID 在多个父 run 之间不保证全局唯一因此绝不能充当注册表的所有权键调度器闭包应持有自己的SubagentResult而不是每次再通过可变的全局注册表解析所有权。子代理的终端 token 用量随当前 run 的ToolMessage.additional_kwargs传递并从消息状态归因绝不经由进程级 Provider-ID 缓存。调度任务必须复用同一套 run 生命周期定时任务何时执行由调度器决定但必须走现有 run 路径下发而不是另起一套并行执行栈。实现上调度启动通过launch_scheduled_thread_run传入scheduler.recursion_limit默认 1000与 Web UI 的recursion_limit: 1000一致受max_recursion_limit上限钳制该值在派发时从get_app_config()读取。后台调度器默认单实例。若要开启多实例租约感知恢复scheduler: multi_instance: true # 需要以下前置否则启动时拒绝该配置multi_instancetrue的硬性前置包括共享 Postgres、run_ownership.heartbeat_enabledtrue、run_events.backenddb。在这种模式下对端启动时保留在跑的调度 run过期的 launch 声明回到持久队列过期的 run 租约被原子接管陈旧的 launch 写入由租约所有权做 fencing基于 Postgres advisory lock 的预算使max_concurrent_runs成为launching/running行共享的全局上限。定单任务的单活跃实例约束uq_scheduled_task_run_active唯一约束确保每个任务最多一个非终止 occurrencestatus IN (queued,launching,running)queued持久化且能跨重启存活launching携带短期的 owner/expiry 租约是唯一允许调用正常 Gateway launch 路径的状态running关联到持久化 run。每个 occurrence 还提供稳定的 run 准入幂等键因此恢复后的 launch 重试会复用同一个持久化 run。复用线程触发ConflictError时launching回退为queued非冲突的 launch 错误则变为终态failed。等待中的行不占用max_concurrent_runs预算由原子队列认领强制执行重复触发会在唯一活跃行上合并同一线程的 FIFO 会把更早的queued、launching、running行都视为阻塞项。暂停 / 删除会原子性中断已有的queued行并拒绝launching/running行PATCH / 恢复会拒绝一切活跃状态且变更错误只对queued工作宣传暂停取消语义。手动触发允许在父级调度保持暂停时入队并运行。恢复与多实例对账按任务 ID / run ID 的确定性顺序锁住 task/run 对且必须在释放短期 launch 声明前重建run_id、started_at与实时错误状态。超时会把 occurrence 标记为失败并推进到下一个调度点防止无休止立即重排。长时间 MCP 任务走独立持久任务运行时长时 MCP 工作不把远端任务 ID / 状态轮询留在 Agent 循环内而是交给独立的持久化任务运行时McpTaskServicemcp_tasks基于租约的恢复机制。Agent 只看得见submit数据库才是事实来源ThreadState只接收有界的当前线程投影。完整的租约、取消 fencing、投递幂等、管理工具暴露等契约见 backend/packages/harness/deerflow/mcp/AGENTS.mdMCP 任务通知重试、死信队列、以及 cancel 端点对 worker 已停止时返回的 503都属于同一契约的一部分。extensions_config.json 的并发原子写extensions_config.json由 Gateway 在运行时写入PUT/PATCH /api/mcp/config、MCP 启用开关、技能更新因此生产 compose 以读写方式挂载它而config.yaml保持:roHelm 会把 ConfigMap 种子复制到可写的 home-volume 目录后再启动 Gateway。这里有一层易踩坑的并发细节每次读-改-写都要同时持有extensions_config_write_lock进程内与 sidecar advisoryextensions_config_file_lock跨进程因为单靠进程内锁会在多 worker 间丢失更新。更隐蔽的是Docker 把 compose 文件本身当作挂载点而 Linux 对挂载点执行rename()会返回EBUSY即使挂载可写所以atomic_write_extensions_config保留临时文件 rename主路径只在EBUSY时回退为原地覆写。该回退刻意非原子写一半崩溃会截断文件它存在只是因为否则写入永远不可能成功每个目标只对首次出现的 fallback 记 warning其他 errno 照常向上抛。这些行为分别由 backend/tests/test_compose_extensions_config_writable.py、backend/tests/test_extensions_config_atomic_write.py 与 backend/tests/test_helm_extensions_config_writable.py 固定。命令体系从根 Makefile 到 backend Makefile根目录命令全栈应用make check # 检查系统依赖是否齐备 make install # 安装全部依赖前端 后端 make extension-install SOURCE... # 安装并启用可信 Python 扩展接受 package|git-url|dir make extension-list # 列出已配置的 Python 扩展 make extension-enable NAME... # 启用一个已安装扩展 make extension-disable NAME... # 禁用扩展但不卸载 make extension-remove NAME... # 卸载托管扩展 make detect-thread-boundaries # 盘点后端 executor/thread/event-loop 边界 make dev # 启动全部服务Gateway Frontend Nginx含 config.yaml 预检 make start # 本地以生产模式启动 make stop # 停止全部服务另有辅助入口make setup交互式初始化向导、make doctor诊断配置与系统要求、make config/make config-upgrade生成 / 合并配置后者把 config.example.yaml 的新字段并入既有config.yaml、make docker-start/make up等 Docker 化路径。扩展相关命令在根 Makefile 中通过环境变量传递参数如DEER_FLOW_EXTENSION_SOURCE由deerflow extensions子命令消费。backend 目录命令仅后端开发make install # 安装后端依赖uv sync --locked make dev # Gateway API带热重载端口 8001 make gateway # 仅 Gateway API端口 8001不带 reload make test # 离线测试不含 live / blocking-io make test-live # 在线测试真实 API make test-blocking-io # 对 tests/blocking_io/ 执行严格 Blockbuster 门禁 make test-shard SPLITS4 GROUP2 # 按耗时感知的某一片示例4 片中第 2 片 make test-shard-durations # 刷新 .test_durations 耗时基线 make lint # ruff lint make format # ruff format make migrate-rev MSG... # 自动生成一条新的 alembic revision从 backend/Makefile 可以看到几个值得注意的实现细节make dev会预先创建并排除DEER_FLOW_HOME默认backend/.deer-flow与backend/sandbox于 Uvicorn reload 监视器之外--reload-exclude。文档明确告诫不要用裸uvicorn --reload替代它——Agent 任务会在DEER_FLOW_HOME下写 Python 与其他运行时文件若不排除会导致运行中 Gateway 被热重载重启。数据库迁移只有一个执行路径Gateway 启动时经bootstrap_schema自动执行alembic upgrade head因此没有migrate/migrate-stamp目标migrate-rev会先构建一个临时 SQLite 到最新 head再对活体 ORM 模型做 diff干净检出也无需预先存在./data/deerflow.db。make test-shard的耗时文件只读、用least_duration分片、以--durations-path协调避免并行 CI 任务竞写。四种启动矩阵速查本地前台本地守护进程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—前后端连接配置前端通过环境变量对接后端NEXT_PUBLIC_LANGGRAPH_BASE_URL默认/api/langgraph经 nginxNEXT_PUBLIC_BACKEND_BASE_URL默认为空串经 nginx。从根目录执行make dev时前端会自动经由 Nginx 连接绕过 Nginx 直连则使用http://localhost:8001访问 Gateway。生产make start支持SKIP_FRONTEND_BUILD1复用已有前端构建。开发工作流TDD 是强制项不是建议backend/AGENTS.md用MANDATORY、No exceptions强调每个新功能与 bug 修复都必须带单元测试。测试写在backend/tests/下命名遵循test_feature.py改动前后都要跑make test与make test-blocking-io测试通过才算功能完成轻量 config/utility 模块优先写无外部依赖的纯单元测试若模块在测试中出现循环导入问题在tests/conftest.py里加sys.modulesmock已有deerflow.subagents.executor的现成先例。常用运行方式make test # 默认离线测试 make test-blocking-io # 严格阻塞 IO 门禁 make test-live # 显式在线集成测试需 config.yaml 与凭据会调真实 API PYTHONPATH. uv run pytest tests/test_feature.py -v # 运行单个测试文件两个测试纪律点直接收集/执行tests/test_client_live.py时除非设置DEER_FLOW_RUN_LIVE_TESTS1否则默认跳过不要把这个 opt-in 加进默认 CIJina 请求失败日志测试会设置哑 API key避免每次进程一次的缺失 key 警告干扰测试顺序或分片布局。后端基准测试可复现、离线、不外泄backend/scripts/benchmark/ 存放独立、可复现、度量生产后端行为的评测。基准可以 import 它度量的生产函数但不得另造一套替代运行时实现。纪律包括每个外部数据集必须钉住不可变 revision 与 SHA-256调用方提供本地数据集路径评测命令不得静默下载数据永不提交上游数据集正文、凭据、完整 provider 请求或响应头提交的 manifest 只能含稳定 ID 与来源定位符合成样例须自我标识provider 凭据与端点从具名环境变量读取模型 ID、推理参数、prompt、重试规则、时钟与随机种子都要固化在评测配置中公开的原始结果可含 case ID、策略决策、模型假设、评分与非机密响应元数据数据集问题、参考答案、记忆内容与完整 provider 载荷保留在被忽略的本地运行目录离线选择用固定时钟与确定性排序结果必须记录所用 config、manifest、prompt、dataset 与 git revision。其中deermem_eviction/子基准专门评估 DeerMem 生产用select_facts_for_capacity()只对比历史confidence策略与 PR #4789 引入的可选hybrid-v1不要新增第三种淘汰策略。运行命令示例在backend/下执行PYTHONPATH. uv run python -m scripts.benchmark.deermem_eviction validate-contracts PYTHONPATH. uv run python -m scripts.benchmark.deermem_eviction validate --dataset $LONGMEMEVAL_ORACLE_PATH PYTHONPATH. uv run python -m scripts.benchmark.deermem_eviction run-policy \ --dataset $LONGMEMEVAL_ORACLE_PATH \ --output-dir /tmp/deermem-eviction-policy-run PYTHONPATH. uv run pytest tests/test_bench_deermem_eviction_*.py -q这些离线测试不得要求网络、provider 凭据或 LongMemEval 数据集小型的 LongMemEval 形状 fixture 必须由测试合成生成。并发类基准scripts/benchmark/concurrency/度量 N 个独立 OS 进程对users表的争用而非 asyncio task覆盖 SQLite vs Postgres——正是 backend/docs/CONFIGURATION.md 要求 Postgres 的场景。worker.py直连 SQLAlchemy跳过编排器已跑过的那次约 8.5s 的 Alembic 引导并镜像应用对 SQLite 的按连接 PRAGMA 设置run_concurrency_bench.py播种一次性 Postgres schema用 READY/GO 屏障同步 worker 后再计时任何崩溃、短操作数或errors 0都以非零码退出。Postgres 运行需经--pg-url提供一次性数据库不触碰 public 库uv run python scripts/benchmark/concurrency/run_concurrency_bench.py \ --backend sqlite --workers 2,4,8,16 --ops-per-worker 50 --read-ratio 0.7 uv run pytest tests/test_bench_concurrency.py tests/test_bench_worker.py -q关键功能速览从配置参数到实现原理Web Search 时效过滤DDG、Brave、Tavily、SearXNG 的web_search共享可选参数time_rangeday|week|month|year省略则保持请求形态不变。映射关系DDG 映射为d|w|m|y、Brave 映射为pd|pw|pm|py、Tavily / SearXNG 原样透传。时效性方面DDGS 9.14.1 只使用启用的 Brave、DuckDuckGo 与 Yahoo 引擎这些引擎遵循timelimitauto/all解析为该集合不兼容的已配置引擎会被剔除集合为空时回退到它DDGS 升级后需复检该行为。多文件上传与自动文档转换端点POST /api/threads/{thread_id}/uploads支持 PDF、PPT、Excel、Word经markitdown转换复制前先拒绝目录输入保证上传全有或全无从活跃事件循环调用时每个请求复用一个转换 worker文件存于当前用户桶下线程隔离目录users/{user_id}/threads/{thread_id}/user-data/uploadsIM 渠道通过user_idkwarg 显式线程化归属见 IM Channels → Owner-scoped file storageHTTP / 内嵌调用方经get_effective_user_id()解析单请求内重名文件自动追加_N后缀避免后文件截断前文件HTTP 上传先以.upload-*.part暂存字节通过尺寸校验后原子替换目标暂存文件对上传列表、Agent 上传上下文与沙箱列举/搜索工具全部隐藏并在 Gateway 启动时清扫硬崩溃遗留HTTP 上传/列举/删除的处理器把文件系统工作交给deerflow.utils.file_io.run_file_io一个保留 ContextVar 的专用文件 IO 执行器非挂载沙箱上传经SandboxProvider.acquire_async()取得沙箱后将read_bytes()与sandbox.update_file()一并卸载执行挂载上传路径跳过沙箱获取与逐文件同步AIO 远端 / provisioner 部署要求显式且准确的sandbox.thread_data_mounts: true省略则保留后端自动探测Agent 经UploadsMiddleware收到上传文件清单标题生成继续使用原始用户请求而非注入的上传上下文包装器纯附件消息回退到New Conversation标题详见 backend/docs/FILE_UPLOAD.md。Plan ModeTodoList用于复杂多步任务的计划模式通过 TodoList 中间件实现运行时配置开关config.configurable.is_plan_mode True提供write_todos工具做任务跟踪同一时刻只有一个任务in_progress实时更新详见 backend/docs/plan_mode_usage.md。上下文压缩Context Summarization接近 token 上限时自动对会话做摘要在config.yaml的summarization键下配置触发类型tokens、messages 或 max input 的比例fraction保留较新消息、对更早消息做摘要手动压缩走POST /api/threads/{id}/compact复用同一个DeerFlowSummarizationMiddleware写出带更新后messages与summary_text的新 checkpoint且只 bump 相应渠道版本该路由与手动状态更新共享reserve_checkpoint_write()边界其短命checkpoint_write线程操作与 run 准入共享持久化活跃线程唯一性约束可同时防住 worker 内与跨 worker 的 checkpoint 写竞争详见 backend/docs/summarization.md。视觉支持Vision对supports_vision: true的模型ViewImageMiddleware处理会话内图片view_image_tool被加入 Agent 工具集图片转 base64 后作为隐藏消息追加到模型请求携带保留 ID 前缀与服务端自有元数据标记Gateway 从不可信输入剥离该标记中间件必须两个标识齐备才识别自有消息中间件在wrap_model_call内注入因此载荷永不进入 graph 状态checkpoint 只保留轻量viewed_images元数据客户端自选 ID 得以保留它还在每次重建前从请求中清扫自有消息避免被中断 run 遗留在旧 checkpoint 中的载荷被再次重发代码风格、文档政策与更细粒度 AGENTS.md代码风格统一为用ruff做 lint 与 format行长上限 240 字符Python 3.12带类型注解双引号、空格缩进仓库实行文档同步政策每次代码变更后必须更新README.md面向用户的功能、安装、用法与AGENTS.md面向开发的架构、命令、工作流、内部系统。根 CLAUDE.md 通过AGENTS.md导入后者因此编辑AGENTS.md会同时更新两者。此外backend 各代码子目录内还有更细粒度的AGENTS.md例如 backend/packages/harness/deerflow/runtime/AGENTS.md、backend/packages/harness/deerflow/mcp/AGENTS.md从本文件拆分出的子系统章节遵循就近原则——按目录树中最近的那一份为准。backend/docs/提供了按功能深挖的文档入口backend/docs/CONFIGURATION.md全部配置项说明backend/docs/ARCHITECTURE.md架构细节backend/docs/API.mdAPI 参考backend/docs/SETUP.md环境搭建backend/docs/FILE_UPLOAD.md文件上传功能backend/docs/PATH_EXAMPLES.md路径类型与用法backend/docs/summarization.md上下文压缩backend/docs/plan_mode_usage.mdPlan Mode / TodoList小结DeerFlow 后端的工程化精髓可以概括为三句话用 Harness / App 单向依赖保住 Agent 框架的可发布边界用RunManager run_agent() StreamBridge统一本地开发、Docker 与生产的唯一运行路径把调度、子代理与 MCP 长任务全部收敛到同一条持久化、租约化、幂等化的执行栈上用强制 TDD、离线基准与文档同步政策保证这个快速演进的仓库始终可测、可复现、可理解。若要在本仓库继续深耕建议从 backend/packages/harness/deerflow/runtime/ 的源码与它就近的AGENTS.md读起那里是理解 DeerFlow 运行时正确性约束的最佳入口。【免费下载链接】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），仅供参考