AI知识库

Dust.tt

企业级 AI 代理与知识工作平台，支持连接 Notion、Slack、GitHub、Google Drive 等数据源，构建可共享、可治理的团队智能体

Dust.tt 是一款面向团队和企业的 AI 智能体平台，核心卖点不是单纯提供一个聊天框，而是让组织把公司知识、业务工具和主流大模型接进同一套工作流里，快速做出可被团队直接调用的 AI agents。它强调“让代理真正理解你的公司上下文”：一边连接 Notion、Slack、GitHub、Google Drive、Confluence 等知识源，一边允许创建面向销售、客服、知识管理、工程、法务、数据分析等场景的专用代理。因此，把 Dust 放在 AI 导航站的“知识库 / RAG”分类里是合适的——它并不是底层向量库本身，而是把企业知识检索、上下文调用、代理编排与多模型选择封装成了完整产品。

这是什么产品

Dust 的官网直接把自己定义为 “Build your team of AI agents”。这句话很关键：它的定位不是单个面向个人的 AI 助手，而是一个支持团队共建、共享、治理和迭代的代理平台。对企业来说，真正难的不是“调用一个大模型”，而是如何把公司内部散落在文档、消息、代码仓库、表格和业务系统里的上下文接入，让 AI 既能回答问题，又能在权限边界内稳定工作。Dust 的产品设计就是围绕这个问题展开。

从官方产品页和文档页来看，Dust 主要有三层能力。第一层是统一入口：团队成员可以像使用聊天工具一样直接 @dust 或 @某个专用 agent 发起任务。第二层是知识与工具层：管理员或 builder 可以把内部数据源、网站、文件夹、表格、各类 SaaS 工具接进来，让 agent 有真实上下文可查。第三层是治理与扩展层：支持权限、空间、数据源管理、共享工具、开发者平台、API、触发器与自动化，把它从“问答机器人”提升到“企业 AI 工作台”。

如果用更直白的话描述，Dust 有点像把“企业版 AI 搜索 + 团队知识问答 + 智能体编排 + 工具集成”捏成一个产品。它比 NotebookLM、ChatPDF 这类单点知识问答产品更重，也比单纯的向量数据库或 RAG SDK 更接近业务落地。对于想快速把 AI 引入组织流程的团队，它提供的是一个更接近成品的中间层。

核心功能与工作流

Dust 的核心能力首先体现在“代理可定制”。官方文档提到，创建 agent 时需要定义 instructions、tools & knowledge，也就是说明代理行为规则、可调用工具和可检索知识范围。与普通聊天机器人不同，Dust 默认就把 agent 当成一个可配置对象，而不是固定人格。你可以为销售团队建一个客户情报代理，为客服团队建一个知识应答代理，为工程团队建一个代码与事故处理代理，为法务团队建一个合同审阅代理。

第二个核心能力是知识接入。官网与文档都明确提到 Dust 可以连接 Notion、Slack、GitHub、Google Drive、Confluence、外部网站等来源，文档导航里还列出了更长的连接器清单，包括 Jira、HubSpot、Snowflake、Microsoft 系列、Zendesk、Notion MCP、Slack tools 等。对 RAG / 企业知识库场景来说，这意味着它不是让用户先手工上传几个 PDF，而是支持把原本就分散在工作系统里的资料接过来，让代理在回答时主动搜索、提取和组合上下文。

第三个能力是多模型选择。产品页写得很明确：可以选 OpenAI、Anthropic、Gemini、Mistral 等模型，而且当更好的模型出现时可以切换。这个设计对企业很实用，因为很多团队不希望被单一模型绑定，往往会根据任务类型、成本、速度、合规要求来切换不同底层模型。Dust 把这个能力作为平台层能力暴露出来，而不是要求团队自己在底层做模型路由。

第四个能力是协作与分享。文档说明用户既可以使用默认的 @dust，也可以调用同事创建的专用 agents，还能在同一会话中串联多个代理完成任务。例如先让一个 agent 生成客户总结，再让另一个 agent 基于总结写邮件。这个“多代理协作”非常接近真实团队工作方式：不同代理承担不同子任务，最后在同一条工作链路中完成。

第五个能力是扩展性。Dust 不只做检索问答，官网还强调可以 build custom connections、custom integrations、custom agentic tools，并通过 API、Zapier、Make、n8n、Power Automate、Slack、浏览器扩展、Teams 等方式把能力接到外部系统里。也就是说，Dust 既能作为企业知识问答前台，也能作为业务自动化的一环。

如何开始使用

Dust 的上手路径相对清晰。首先，团队需要注册工作区并进入 Web 应用。根据官方文档，用户上来就能先使用默认的 @dust 代理，它会基于已经集成的内部文档回答问题。这一步适合快速感受产品：如果工作区已经接好了数据源，成员几乎可以马上开始“问公司知识库问题”。

第二步是创建自己的第一个 agent。官方 quickstart 页面给出完整流程：点击 Create，从空白或模板开始；用 Sidekick 辅助起草 instructions；为代理添加 tools & knowledge；在预览区测试；最后补上名称、描述、标签和访问控制。这个流程说明 Dust 把“代理构建”做成了产品化界面，而不是只面向开发者的 YAML 或代码配置。对业务团队而言，这降低了尝试门槛。

第三步是连接数据源。对知识库场景来说，这一步最关键。文档建议给 agent 选择正确的数据空间、连接的资料源，并补充描述，帮助代理判断何时使用这些数据。也就是说，Dust 并不是粗暴地把所有资料一股脑喂进去，而是鼓励围绕具体任务做范围控制。官方 best practices 甚至明确提醒：代理能访问的数据越多，检索到正确内容的概率反而可能下降。这个设计思路比较符合实际 RAG 经验。

第四步是发布与共享。Dust 支持把 agent 发布给工作区成员使用，也支持设置仅自己和编辑者可见。对于企业推广来说，这一点很重要：不是所有实验性代理都适合立刻公开，而成熟度高的代理则可以快速在团队内扩散。文档还提到可以通过标签改善 discoverability，让团队更容易找到合适的 agent。

第五步是把使用入口嵌到现有沟通流里。除了 Web 应用，Dust 还支持在 Slack 中调用，在自动化工具中触发，也有浏览器扩展和 Teams 集成。对很多企业来说，真正提升采用率的关键不是代理多强，而是入口是否出现在员工原本就高频使用的系统里。Dust 这一点考虑得比较完整。

价格与开源状态

Dust 当前公开定价页给出了比较清晰的分层：Pro 面向小团队和初创公司，最低从 1 名成员开始；Enterprise 面向 100 人以上组织，强调多工作区、SSO 等企业级能力。官网同时提供 14 天免费试用入口，这意味着它不是完全闭门的销售驱动产品，至少中小团队可以先试起来。

不过，在当前公开页面可直接抓取到的信息里，具体的按席位价格数字并没有完整展示出来，因此如果你需要精确预算，还是要以 Dust 实时 pricing 页面或销售报价为准。页面还能看到 “Free credits for programmatic usage” 的提示，说明 API、Google Sheets、Zapier 等程序化调用场景可能会附带一定额度设计，但详细计费规则仍建议查看官方说明。

在开源状态上，Dust 不是开源项目本体。它更像一款商业化的企业 SaaS 平台。不过官网页脚给出了 GitHub Repo 链接，说明官方确实开放了部分开发者资源或仓库用于集成、示例或平台生态建设。对最终用户来说，核心平台仍是托管式服务，而不是一个可以自行完整私有部署的开源知识库系统。

因此，Dust 更适合那些希望快速购买并落地企业 AI 能力的团队，而不是坚持全栈自建、希望完全掌控底层检索链路和推理基础设施的技术组织。如果你更偏向后者，可能会去选开源 RAG 框架、向量数据库、编排平台组合搭建；如果你更看重落地速度、权限治理和业务团队可用性，Dust 的商业形态反而是优势。

适合谁

Dust 最适合三类人。第一类是企业内部 AI 推动者，包括 IT、Ops、知识管理负责人、数据团队和各业务部门里的 builder。因为它允许这些人先做出一批可用代理，再逐步推广给更多团队成员。第二类是知识密集型团队，例如销售、客服、产品、工程、法务、市场等，需要频繁查找公司内部资料、生成回复、总结文档或跨系统整合信息。第三类是希望在不深写代码的前提下快速落地 AI 工作流的中大型组织。

从官方 use cases 可以看出，它不是把某个行业做得极深，而是围绕通用职能做横向适配：销售做 account snapshot 和外呼内容，客服连知识库做即时回答，知识团队打通数据孤岛，数据分析团队让非技术成员也能查询公司数据，工程团队接 IDE / 代码 / issue 上下文，法务团队做合同审阅与政策问答。换句话说，Dust 适合“信息流很多、协作很多、知识分散很多”的组织。

但它未必适合个人轻量用户。如果你只是想上传几篇论文、问几个 PDF 问题，Dust 可能显得太重；如果你只是想做一个公开网站聊天机器人，也许还有更轻更便宜的工具。Dust 真正的价值在于“组织内知识 + 团队协作 + 多系统接入 + 治理”。脱离这些场景，它的优势很难完全释放。

优势与限制

Dust 的优势很明显。第一，产品完成度高。相比从向量库、嵌入模型、检索策略、Agent 框架、权限系统自己拼装，Dust 直接给了团队一个可用平台。第二，连接器和工具面广，不局限于单一文档上传。第三，多模型与多代理机制让它不容易被某个单点能力限制。第四，重视企业治理，包括访问控制、空间、共享、分析、安全合规，这些恰恰是企业 AI 落地中最容易被忽视但最关键的部分。第五，产品明确面向团队 adoption，而不是只面向少数技术专家。

限制也同样存在。首先，它是商业 SaaS，组织需要接受把一部分 AI 中间层能力托管给外部平台。其次，越是功能丰富的平台，配置复杂度通常也越高：你需要管理数据接入、权限边界、代理指令质量、工具选择、标签体系和推广策略，不能指望“接上就自动变聪明”。再次，Dust 并不是底层 RAG 引擎研究工具，如果你的团队想对检索策略、排序逻辑、评测体系、模型微调做非常细的底层控制，它未必像自建方案那样灵活。最后，公开价格细节披露有限，预算评估往往需要进一步试用或联系销售。

另外要强调的是，Dust 文档明确提醒代理访问数据越多，命中正确信息的概率未必越高。这说明即便在成熟平台上，RAG 也不是“无限喂数据”就能成功。团队仍然要做信息架构、数据源选择和代理职责拆分。Dust 提供了工具，但不替代产品设计与知识治理本身。

对比与选择

如果把 Dust 和 Chatbase、DocsBot、AskYourPDF、ChatPDF 这类工具相比，Dust 更偏“企业级代理平台”，后者更偏“文档问答产品”。后者往往适合快速做一个面向单站点、单知识包或单聊天入口的问答助手，而 Dust 更适合把多个知识源、多个代理和多个业务系统编织在一起，构成组织级 AI 层。

如果和 Notion AI、Google NotebookLM 这类知识型助手相比，Dust 的差异在于开放性和中立性更强。它不是附着在某一家文档系统内部，而是试图跨 Slack、Notion、GitHub、Drive、网站、数据库等多源工作。对于知识分布在多个 SaaS 的组织，这种跨源能力很关键。

如果和 LangChain、LlamaIndex、Haystack、RAGFlow、Dify 这类偏开发或平台化产品相比，Dust 更商业化、更多面向业务团队；而这些产品往往给技术团队更大的可塑性、自托管可能性和底层控制权。简单说：Dust 偏“买来用并推广”，Dify / RAGFlow 这类更偏“搭来改并深度定制”。没有绝对谁更好，关键看团队资源与目标。

因此选型建议是：如果你要的是企业内部快速可用、带权限与团队协作的知识代理平台，Dust 很值得进入候选名单；如果你要的是完全自控、可自部署、可深改底层链路的 RAG 技术栈，Dust 可能不是第一优先，但可以作为你评估“成品平台体验上限”的参考对象。

结论

Dust.tt 是一个很典型的“把企业知识库与 AI 代理做成产品”的案例。它没有停留在文档问答层，而是进一步覆盖了数据连接、工具调用、多模型、多代理协作、权限与工作流集成，使它更像一层组织级 AI 操作系统。对需要把公司知识真正转化成可调用生产力的团队来说，这个方向是有吸引力的。

如果你所在组织已经有大量知识沉淀在 Slack、Notion、GitHub、Drive、Confluence 等工具里，并且希望让不同部门以较低门槛创建各自的专用代理，Dust 的产品形态会很对路。它不是最轻的，也不是最开源的，但在“企业知识接入 + 团队代理落地”这件事上，完成度和现实感都比较强。

一句话总结：Dust 适合那些想把 RAG 和 AI agents 真正用进团队工作，而不是只停留在 demo 阶段的组织。