Dust 团队知识协作教程：受限 Pod、资料权限、Agent 周报与人工验收

这篇教程要完成的工作

目标是在 Dust 中建立一个受限团队 Pod，让运营、产品与技术围绕同一项目资料协作。Agent 读取获准共享的文件和链接，生成带来源的项目周报草稿；成员确认事实、修正任务与负责人后，才把结论发布到团队正式渠道。

这是一份配置与验收流程，不表示我已进入你的 Dust 工作区或连接实际内部资料。先用脱敏样本完成试点，再决定是否放入客户记录、合同或生产连接器。Dust 的 Pod 能汇集协作上下文，但不会自动替你定义资料分级、业务审批和谁有权对外发送。

开始前准备：一个具体项目，三类资料

选择一个业务范围清楚的项目，例如“新功能上线周报”。指定 Pod Editor、资料负责人和最终批准人。准备一份当前路线图、一份已批准的 FAQ、一份风险清单，以及几条带日期的状态更新。把旧版路线图和无权限文件作为验收样本，不要误当正式知识上传。

先写清资料分级：

类型	放置建议	谁可见
可供项目组共享的正式资料	连接原系统或放入受限 Pod	项目组成员
临时草稿、Agent 生成的状态稿	Pod Files 与任务讨论	同一 Pod 成员
客户合同、人事或财务敏感资料	单独 Restricted Pod 或保留原系统	经授权的小组
旧版、撤销资料	保留作测试但标明失效	仅测试范围

官网的 Pods 概览明确说明：Pod 内成员共享对话、任务与文件，没有成员内部的“私密角落”。这意味着邀请一个新成员，就需要考虑其查看历史文件和讨论的权限。先从最小成员集开始。

第一步：创建 Restricted Pod

在 Dust 左侧 Pods 区域选择 New，给 Pod 起可识别的项目名，例如“产品上线协作试点”，写清目的和负责人。官方入门文档显示创建时可选 Open 或 Restricted，Restricted 默认仅邀请成员进入；敏感项目不要切成组织内所有人可加入的 Open。

在 Pod Settings 添加说明：项目目标、唯一正式资料来源、每周汇报时间、哪些事项必须人工决定。说明不能代替权限，但能给 Agent 和成员一个一致的上下文。创建后确认可见状态仍为 Restricted，并让非成员尝试搜索或打开 Pod，记录访问结果。

为 Pod 指定至少一名 Editor 负责成员和可见性；普通 Member 只执行日常阅读、讨论和任务。官方成员与角色文档列出 Editor 可以管理成员、角色和 Pod 可见性。离职或换项目时要复查成员，而不是仅停用外部共享链接。

第二步：决定资料是同步还是上传

已有资料如果在 Notion、Google Drive 或 Confluence 持续维护，优先评估 Dust 的 Connections；项目专属的草稿和结果可以放入 Pod Files。Pods 文档区分这两层：Connections 由源系统决定同步节奏，Pod Files 中写入的文件可立即供 Agent 搜索。不要把复制文件当作自动同步。

进入 Files，添加少量可共享样本。官方Files 文档说明，可上传文件、建立文件夹，或从 Company Data 添加已连接的资料。它特别提示：能链接到 Pod 的 Company Data 应可供每位 Pod 成员访问。不能因为某个人能打开一个私密文档，就把它复制进全组共享 Pod。

为每份资料记录文件名、来源 URL、更新时间、版本、负责人和是否可用于回答。例如：

资料	来源	生效日期	负责人	使用范围
发布计划 v3	原项目系统	2026-09-28	产品经理	周报事实来源
常见问题 v2	知识库	2026-09-20	支持负责人	对外措辞草稿
风险清单	Pod Files	每周更新	技术负责人	仅内部讨论

资料反复变更时，确定由谁更新、是否覆盖同一文件、旧版怎样标为过期。先在原系统维护主数据，再让 Agent 汇总，能避免多份“最终版”互相矛盾。

第三步：把 Agent 任务写成可审核的工作单

在 Pod 对话里说明目标、允许来源、输出结构和不能执行的动作。可用类似以下指令作为试点：

根据本 Pod 中标记为当前有效的发布计划、FAQ 和风险清单，生成本周项目状态草稿。每条结论写出依据的资料名与日期；资料冲突时列出冲突，不自行决定哪份正确。输出“已完成、阻塞项、待确认、下一步负责人”四部分。不要对外发邮件、更新 CRM、删除文件或把任务标为已批准；缺少信息时列出需要人工回答的问题。

这条说明不是安全边界。真正的连接器权限、工具调用权限和 Pod 成员范围还需要在配置里控制。不要把“请遵守权限”写进提示词后就给 Agent 一个能读全公司资料的账号。

先让 Agent 处理三条公开或脱敏任务。检查它是否引用当前版本、有没有把旧版计划当结论、能否区分事实和推断、在资料缺失时是否如实说不确定。记录每次人工修正原因，不要只挑最好的一次输出截图。

第四步：把状态草稿变成明确的人类任务

周报草稿应该在 Pod 中由负责的人检查。把有争议的结论转成待确认任务，例如“上线日期由产品经理确认”“安全问题由技术负责人核实”。任务要有负责人、期限、原文链接和完成标准。

Agent 可以在 Pod 中创建任务和文件，但这不代表它有权替业务负责人批准。建议建立一个简单状态约定：

1. 待核对：Agent 列出问题，尚未验收来源。
2. 已核对：资料负责人确认事实与版本。
3. 待批准：项目负责人确认对外表达。
4. 已发布：经过批准的人将最终版本放到正式渠道。
5. 需更正：新资料出现，回到待核对并保留修订记录。

这些是团队自己制定的业务状态，不是声称 Dust 原生具有一套适用于所有公司的审批状态机。外发、写 CRM 或编辑第三方文档前，按连接器实际能力设置工具权限和人工审批。

第五步：做权限和版本回归测试

至少用项目 Editor、普通 Pod Member 和非成员三个身份测试。非成员不应读到受限 Pod；普通成员能看到的范围要与团队事先定义一致。再测试一份仅某部门可见的原系统文件，核对它是否被错误复制进 Pod Files 或通过宽权限工具被 Agent 找到。

准备五类输入：

• 当前有效文件中的明确信息。
• 两份资料日期不同、结论冲突。
• 已撤销的旧政策。
• 当前资料没有答案的问题。
• 不在该成员权限内的内容。

合格输出要么引用正确来源，要么说明不确定、请求负责人确认。旧资料、越权内容和猜测不应被包装成确定事实。资料更新、成员变化、Agent 配置变化后重新跑测试，不要只在初次上线时跑一次。

第六步：检查输出、外部动作和失败恢复

让 Agent 只生成一份周报草稿，再由人检查。若要接入 Google Docs、Slack 或其他外部系统，先把读权限与写权限分开；在测试环境中验证“拒绝审批”“接口超时”“同一事件重复触发”会怎样处理。每次正式发布最好保留源文件版本、审核人、最终输出地址和执行时间。

如果连接器或 Agent 把报告直接写成一个可见的外部文件，先确认接收范围。一个 Restricted Pod 里的内容，一旦复制到开放的 Docs 或 Slack 频道，原 Pod 的限制不能继续保护那份副本。

对于失败重试，记录外部结果 ID；重试前检查是否已经成功写入，避免一条状态稿变成多份重复周报。若平台不能直接提供所需幂等控制，就在外部自动化或人工审核流程中实现。

第七步：算清每周成本和上线门槛

截至 2026 年 9 月 30 日，Dust 价格页显示 Free 为一次性 500 credits；Pro 月付 €30/席/月或年付折合 €24/月，8,000 credits/席/月；Max 月付 €150 或年付折合 €120/月，40,000 credits/席/月，未含 VAT。不同模型、检索、代码和工具调用耗额不同。先用十次代表任务统计实际 credits，再估算每周任务数和团队席位数。

上线门槛可由项目负责人写成表：

指标	建议验收方式
当前资料引用	逐条可回到来源及生效日期
冲突识别	旧版和新版互相矛盾时标出差异
无权限资料	不被普通成员或 Agent 结果带出
人工修正	记录每篇周报修订分钟数与主要原因
外部动作	只有批准的版本进入正式渠道
成本	记录每次任务实际 credits、席位费与管理员时间

数字阈值应由你的业务负责人设定。单看“生成速度很快”无法说明流程可靠；如果每份周报都需要长时间事实纠错，应该先改资料组织与提示说明。

常见问题和排查

**Agent 用了旧资料：**检查文档是否真的从原系统同步，还是早先复制到 Pod Files 的快照；核对最新版本的来源日期和文件名。必要时暂时移除旧副本，并重新跑回归问题。

**某成员看到不该看的内容：**先确认 Pod 是否为 Restricted，再检查成员、Company Data 链接、上传文件和 Agent 的工具授权。不要仅靠隐藏某条对话解决，因为同一 Pod 中没有成员内部私密空间。

**回答不带出处：**在任务说明里要求每条结论有来源文件与日期，并把“没有可靠出处”列为未完成。仍应人工抽查，不能把生成的链接直接视为正确。

**费用增长：**按模型、工具、检索和多次重试拆解实际 credits。先限制深度研究的触发条件，再核算 Pro 与 Max 席位分配，注意免费 500 credits 不每月刷新。

官方参考

• Dust Pods 概览
• 创建 Pod 与可见性
• Pod 成员与角色
• Pod Files 与 Company Data
• Dust 价格与套餐限制
• Dust 安全说明