Dust

一句话定位

Dust 是一个面向企业工作场景的 AI Agent 构建与运营平台（不是库），采用 monorepo：front（Next.js + TypeScript，承载 agent/assistant 业务逻辑、MCP 工具生态、对话与编排）+ core（Rust 执行引擎，承载块式 Dust App 编排、数据源/RAG、tokenizer 与 provider 适配）。其设计目标是让团队”用配置而非写代码”搭出多工具、多数据源、可治理、可观测的工作型 agent，并跑在 Temporal 持久化工作流之上。

设计理念 / 顶层架构

Dust 是 platform 范式，核心取舍是”把 agent 拆成可配置的服务管道”，而非提供一个 Agent 类给开发者继承。理解它必须抓住 front 与 core 的分工：

• core（Rust 执行引擎）：定位是一个块式 (block-based) 数据流编排器——“Dust App = 一组带版本哈希的 Block 的有向序列”。App（core/src/app.rs:29）解析一份 DSL spec（pest 语法），实例化 14 种 Block（core/src/blocks/block.rs:75 的 BlockType 枚举：Input/Data/DataSource/Code/LLM/Chat/Map/Reduce/Search/Curl/Browser/While/End/Database…），然后 App::run（core/src/app.rs:305）按拓扑顺序执行，块之间通过 Env.state（core/src/blocks/block.rs:41）传值、用 Tera 模板 ${BLOCK.key} 引用上游输出。core 还独占了性能/隔离敏感的能力：data_sources + Qdrant 向量检索（core/src/data_sources/）、tokenizer（tiktoken / sentencepiece，core/src/providers/llm.rs:33）、以及历史上的多 LLM provider 适配（core/src/providers/{openai,anthropic,mistral,...}.rs）。core 编译为多个二进制服务（core-api、oauth、sqlite-worker，见 core/Cargo.toml），front 通过 HTTP（CoreAPI，front/types/core/core_api.ts:490 createRun / :532 createRunStream）调用它。

• front（TypeScript 业务层 / Web 应用）：定位是用户态的一切——agent 配置、对话、工具编排、权限治理、可观测。这里有一个关键的架构演进：真正的”agent 推理循环”已从 core 的 Dust App 上移到 front 的 Temporal 工作流。agentLoopWorkflow（front/temporal/agent_loop/workflows.ts:185）是一个 step 循环（最多 MAX_STEPS_USE_PER_RUN_LIMIT 步）：每步 runModelAndCreateActions（调 LLM 决定下一动作）→ 若产出工具调用则 runToolActivity 执行 → 回灌结果 → 下一步。LLM 调用本身也在迁移：旧路径经 core 的 assistant-v2-multi-actions-agent Dust App（front/lib/api/assistant/call_llm.ts:48 的 runMultiActionsAgent，注释明说是”临时 wrapper，待 direct LLM router 就绪后移除”），新路径是 front 原生的 LLM router getLLM（front/lib/api/llm/index.ts:50，直连 Anthropic/OpenAI/Google/Mistral/xAI/Fireworks 客户端）。工具 = MCP：所有 agent 能力（含内置和第三方集成）统一抽象为 MCP server（front/lib/actions/mcp_internal_actions/servers/index.ts 注册了 60+ 个：notion/github/salesforce/gmail/jira/run_agent…）。

简言之：core = 引擎（块编排 + RAG + tokenize + 旧 provider）；front = 大脑与外壳（agent loop on Temporal + MCP 工具 + 配置/治理/可观测），二者通过 CoreAPI HTTP 边界解耦。

平台用法（取自 README——它本身不提供 hello-world 代码，而是指向托管平台与文档）：

# Dust 是平台，不是 pip/npm 库。典型用法是：
# 1. 在 dust.tt 创建 workspace，连接数据源 (Notion/Drive/Slack/GitHub...)
# 2. 在 Agent Builder 中配置一个 agent：选模型 + 挂工具(MCP server) + 挂数据源 + 写指令
# 3. 通过 Web/Slack/API 与 agent 对话；agent loop 在后台 Temporal 工作流中执行
# 参考: https://docs.dust.tt  (user guides and developer platform)
#
# 本地自托管: docker-compose.yml 启动 front(Next.js) + core(Rust) + Postgres + Qdrant + Elasticsearch

组件实现（横向逐项）

设计权衡与特性

• 平台而非库：与 ConnectOnion（“两行起一个 agent”的库）或 LangChain 式 SDK 截然不同——Dust 不暴露给开发者一个 Agent 类去 import，而是一整套服务(Next.js + Rust + Temporal + Postgres + Qdrant + Elasticsearch)。强项是企业级：RBAC/审计/数据源连接器/可观测/沙箱治理开箱即用；代价是重，几乎无法”嵌入”到别人的应用里，只能整体部署或用 SaaS。
• TS/Rust 双语分工的清晰边界：把”快变的业务逻辑、工具生态、对话/权限”放 TypeScript（迭代快），把”性能/隔离敏感的 tokenize、向量检索、块编排”放 Rust（稳、快），中间用 CoreAPI HTTP 解耦。这是该框架最有借鉴价值的架构决策。
• 正在进行的两处大迁移（看源码必须知道）：① agent loop 从 core 的 Dust App 上移到 front 的 Temporal 工作流——core 的块式引擎正退化为”被调用的 LLM/RAG 执行器”而非 agent 大脑；② LLM 调用从 core provider 迁到 front 原生 LLM router（call_llm.ts:48 自述是临时 wrapper）。所以”core 是执行引擎、front 是 agent 层”这句话正确，但 agent 的推理循环如今在 front，不在 core。
• 一切皆 MCP：工具调用统一收敛到 MCP 协议（内置 server 也按 MCP 实现），连子 agent (run_agent) 和 skills 都暴露为 MCP server。好处是工具/集成/委派/技能用同一套规格、审批、可观测；这是相对少见的”把 MCP 当内部统一总线”的设计。
• Temporal 作为 agent 运行时：用持久化工作流跑 agent loop，天然获得断点续跑、可取消/中断/优雅停止(workflows.ts:202-220 三种 signal)、HITL 审批暂停后恢复——比纯进程内 while 循环健壮得多，但也把 Temporal 变成硬依赖。
• 强工程规范：CODING_RULES.md 极其详尽（禁 enum、禁参数突变、禁 as、禁 N+1、business 层不得返回 HTTP 错误码、沙箱 root 命令必须绝对路径防 PATH 劫持等），可作为大型 agent 平台工程治理的范本。
• 待确认：① stars 数为约值，需以仓库实际为准；② core 中 provider/LLM 相关代码在迁移期可能与 front 新 router 并存，具体哪些模型走哪条路径依 feature flag 而定（getFeatureFlags），随版本变化。

关联

• component-taxonomy · multi-agent-orchestration · single-vs-multi-agent
• 同范式(platform)：connectonion · 源码：agents-example/dust/