Dust：企业智能体最难的不是能力，而是边界

三十万个智能体之后，真正的问题才开始^*

^* 本标题为 DataHub 编辑判断，用于概括案例的核心张力，非 Dust 或 Anthropic 的原文表述。下文各小节标题中的隐喻性表达同理。

Dust 是一家总部位于欧洲的初创公司，产品定位是"面向人机协作的多人 AI 平台"。团队不大，但客户名单包括 Datadog、Vanta 和 1Password 等技术公司。Dust 的核心主张是：最了解业务的人——运营负责人、客户支持经理、入职流程设计者——应该能自己构建 AI 智能体，而不需要写代码。

官方视觉

产品与工作场景

按照 Anthropic 官方案例的说法，Dust 客户团队累计部署了超过 300,000 个智能体。这个数字本身并不能回答一个更关键的问题：这些智能体到底在做什么？如果它们只是回答问题，那 30 万和 3 万没有本质区别。Dust 所描述的使用方式远不止问答——智能体需要读取企业知识库和业务系统，然后向这些系统写回结果：更新 CRM、生成报告、触发工作流。

这意味着智能体不再是一个"查询窗口"，而是一个"执行者"。一旦智能体开始跨系统行动，三个问题同时出现：它能连续执行多少步而不出错？它能看到和操作哪些数据？更长的执行链会带来多少额外的 token 成本？

图 1 · 问题结构 从"部署数量"到"运行条件"：智能体跨系统执行时的三重约束

执行链变长之前，先画清权限的线^*

^* DataHub 编辑标题。

Dust 的产品允许客户从下拉菜单中选择智能体背后的模型，不需要改代码。在这些对比中，Dust CTO Stanislas Polu 观察到一个一致的模式：Claude 在指令遵循、细致写作和可靠工具调用三个维度上表现突出。但选对模型只是第一步——更关键的决策是：当模型能力足够强时，如何确保智能体只在被允许的范围内行动？

Dust 的检索管线连接了 100 多个数据源，并提供跨子智能体委派工作的框架。连接范围越大，治理机制就越重要。官方案例列出了三层控制：权限感知检索确保智能体只能检索到用户有权访问的数据；基于角色的访问控制限制智能体可以调用哪些工具；审计日志记录每次操作，使行为可追溯。

从 4–5 步到 8 步以上：执行循环的重新设计

在权限边界确立之后，Dust 才着手解决执行深度问题。Polu 描述了此前的限制。他的原话是："Our existing defaults, three tools per run with a maximum of eight, were too restrictive. The model would hit the tool limit and produce truncated results."这句话中"three tools per run with a maximum of eight"的确切含义存在歧义——"eight"可以理解为工具数上限，也可以理解为调用次数上限，原文未进一步澄清。可以确定的是：此前的默认配置对工具使用施加了较低的限制，导致模型触达上限后产生截断结果。

较早的模型在少量工具调用之后确实容易产生不可靠的输出。官方原文的表述是：较早的模型在超过少量工具调用后会产生截断或不可靠的结果；当 Claude 能够准确地串联多个步骤后，Dust 提高了上限。Dust 重新设计了执行循环，将单次运行的上限扩展到 24 次工具调用。官方案例称，实际观察到的自主工具调用深度从 4–5 步增加到 8 步以上，且不需要工程层面的代码变更。

DataHub 根据产品机制重构出一种可能的决策关系：权限感知检索、角色控制和审计日志，为更长的执行链提供治理条件。但官方案例没有披露这些能力的建设先后，因此不能据此断言 Dust 一定是先完成治理、再放开执行深度。

图 2 · 实施路径与人机协作 Dust 的产品决策：治理、深度与成本的三个维度

十分钟的深度研究，和它带来的成本账

执行链变长后，Dust 构建了一类新的工作流：深度研究智能体。这类智能体可以编排子智能体，跨数据仓库、网页和内部来源进行综合研究，单份报告的运行时间达到 10 分钟以上。Polu 观察到，新版 Claude 模型在研究任务中的行为发生了质变："新的 Claude 模型不只是回答问题；它会主动探索相邻信息，并跨来源进行综合。"他以一次研究任务为例，提到模型查阅的来源数量从 5 个增长到 14 个；原文未说明这是平均值、典型值还是单次观察。

但更长的运行时间直接带来了更高的 token 消耗。这不是一个意外——它是执行深度的必然代价。为了处理这项成本，Dust 与 Anthropic 的 Applied AI 团队合作优化提示缓存，最终落地了一个三层结构。

图 3 · 系统架构 三层提示缓存：按复用范围组织长任务上下文

与此同时，Dust 采用了 Model Context Protocol（MCP）——Anthropic 发布的开放协议，用于连接模型与工具。Dust 同时作为 MCP 客户端和服务端运行：作为客户端，智能体通过标准接口访问任何兼容工具（创建工单、更新 CRM、查询数据库），无需为每个工具构建定制集成；作为服务端，Dust 将自己的智能体和上下文暴露给其他 MCP 感知系统。

成本下降了，调用加深了——但"做得更好"还没有证据

缓存优化的效果首先体现在账单上。

每天节省约 10,000 美元是一个需要谨慎解读的数字，但需要注意它的口径：这是整体模型支出下降 18%–19% 的近似日换算额，两者描述的是同一个结果。整体支出的统计范围、基准期、币种换算条件和任务量变化均未披露。对于其他组织来说，这个数字不能直接外推——它取决于 Dust 的具体工作负载规模和模型使用模式。

在采用层面，官方原文称"深度研究和工作流编排等用例帮助 Dust 在团队间扩展，推动了客户组织平均 70% 的每周活跃使用率"。这个指标的信息量有限：我们不知道分母是什么（全部付费用户？全部注册用户？），不知道"活跃"的行为门槛（登录一次算不算？还是必须完成一次智能体运行？），也不知道这个数字覆盖了多少客户组织。此外，原文将深度研究等用例与 70% 活跃率放在同一句话中，但两者之间的因果关系并未被独立验证。

Dust 内部的工程实践变化

官方案例还提到了 Dust 自身团队的变化。工程师使用 Claude Code 作为日常编码伙伴、GitHub Action 审查拉取请求，并将明确范围的任务转化为可审查的 PR。一位工程师构建了一个技能，可以在编码过程中从 Dust 平台拉取公司上下文。Polu 称，AI 编写的代码在 Dust 内部从 2025 年初的约 30% 增长到 60%–90%，具体比例因工程师而异，这一转变在数周内完成。

但整个案例中最值得注意的缺失是：所有量化结果都在描述"过程变化"（调用更深、成本更低、使用更频繁），而没有一个指标直接衡量"结果质量"。我们知道智能体可以连续调用 8 步以上的工具，但不知道这些调用是否产生了正确的结果。我们知道深度研究智能体可以运行 10 分钟以上，但不知道生成的报告质量如何评估。

三个约束、一条决策链，和仍然开放的问题

Dust 案例的价值不在于任何单一数字，而在于它展示了一条完整的决策链：当智能体从"回答问题"升级为"跨系统执行"，执行深度、权限边界和 token 成本三个约束必须被放在同一个产品问题中讨论。

图 4 · 结果口径与证据边界 Dust 案例中已量化、部分量化和未量化的三类证据

从 Dust 案例中可以核对的三个问题

DataHub 判断：以下三条是 DataHub 基于案例信息提炼的核对问题，供正在考虑类似部署的团队参考。它们源自对 Dust 产品决策的编辑分析，不是 Dust 或 Anthropic 的官方建议。其适用性取决于读者自身的组织规模、技术栈和治理成熟度。

• 治理机制是否先于执行深度到位？Dust 的做法是在放开执行深度之前，先确保每个智能体的数据访问和工具调用都在权限边界之内——权限感知检索、角色控制和审计日志。官方案例未明确标注两者的时间先后，但从产品逻辑看，治理是执行深度的前提条件。对于其他团队，具体机制可以不同，但值得核对的问题是：在扩大智能体的行动范围之前，权限边界是否已经就位？
• 是否区分了观察值和系统上限？"8 步以上"是观察到的工具调用深度，"24 次"是执行循环的上限。两者不是同一个指标，不应混为一谈。在评估自己的智能体能力时，同样需要区分"模型能做到什么"和"系统允许做到什么"。
• 缓存是按复用范围还是按任务类型设计的？Dust 的三层缓存不是按"研究任务""客服任务"分类，而是按"全局共享""工作区共享""用户独有"分层。这个设计原则适用于任何需要处理长上下文重复的场景。