Dropbox 推出了一套基于 MCP（模型上下文协议） 与内部知识系统 Dash 的工程实践，让安全设计产物直接接入代码审查工作流。AI Agent 不再是辅助搜索，而是主动识别设计意图与实现之间的差距，将安全文档从“被动存档”变成“主动输入”。
在大型工程组织中，安全要求通常在设计评审阶段就已被敲定。但问题在于：这些要求直到更后期的代码审查阶段才会真正得到验证——而此时参与审查的工程师，往往已经缺少完整的设计上下文。
威胁模型、设计文档和安全要求，都是独立产物，与代码库分开存储。随着系统不断演进，这些文档很容易过时，或与实际实现脱节。
一个反复出现的结果是：工程师和代码审查人员必须手动追溯代码变更背后的安全意图。这不仅增加了工作量，也提高了遗漏安全要求或执行不一致的风险。
设计评审 → 文档归档 → 数月后代码审查 → 人工回溯上下文 → 安全要求被遗漏
设计评审 → Dash 索引 → 代码审查时 AI Agent 自动检索 → 安全要求主动呈现 → 审查人员直接确认
注：对比基于 Dropbox 公开工程博客，传统流程为行业通病，AI 驱动流程为该团队已落地实践。
Dropbox 的方案将 Dash 作为内部文档系统的集中式索引和检索层，MCP 则提供标准化协议，使 AI 系统能够在代码审查等开发者工作流中获取并使用这些上下文信息。
具体流程：创建 Pull Request 后，系统识别代码变更，通过 MCP 从 Dash 中检索相关威胁模型和安全要求。这些上下文直接呈现在审查界面中，工程师无需再到不同系统间手动搜索。
关键区别在于：它不只是检索。AI Agent 会将检索到的上下文与 Pull Request 本身进行比较——识别适用的安全要求，找出设计意图与实际实现之间可能存在的差距。
注：Dash 保留原有基于权限的检索、加密和审计日志，确保敏感文档仍遵循组织访问边界。
Dropbox 工程负责人 Ishan Mishra 在接受采访时，反复强调了三个设计原则。这些原则决定了这套系统如何与开发者建立信任，而非破坏信任。
一个诚实的注脚：
最初，这只是一个简单的检索系统——帮你找到一份文档。但 Dropbox 团队很快发现，单纯的检索不足以改变工作流。关键在于下一步：分析这些上下文与具体代码变更之间的关系。
找到相关文档，附在审查界面中，工程师仍需自行判断是否适用。
识别适用的安全要求，找出设计意图与实际实现之间的差距，生成可操作的发现。
Mishra 总结了这个转变的关键：“它不会取代安全审查人员，但会让代码审查不再只是泛泛的代码质量检查，而是建立在最初设计意图的基础之上。”
为什么选择 MCP？而不是直接集成到 CI 或代码审查系统？
标准化——MCP 提供了一种统一方式，让代码审查 Agent 不需要知道信息存在哪里，也不需要了解具体的检索方式。它只需要请求相关上下文，而 Dash 在后台负责检索和访问控制。这使得整个架构更容易复用，安全审查只是第一个应用场景。
很多 AI 编程工作流都专注于独立生成或审查代码。这当然有用，但它忽略了一个更大的问题：为什么要编写这些代码。
Dropbox 的实践揭示了一个更广泛的经验：当 AI Agent 能够建立在组织过去已经做出的决策之上，而不仅仅是关注当前任务时，它的价值会大幅提升。
同样的模式适用于安全之外的领域——隐私要求、API 格式约定、架构决策。当 AI 能够将具体实现与组织已有的知识连接起来时，它的价值都会更大。
AI 辅助的最高价值，不是让工程师写代码更快，而是帮助组织在关键决策节点上，保留和利用那些已经积累的集体知识。
Dropbox 已公开 MCP + Dash 集成方案的核心设计思路，该模式不仅适用于安全审查，也可用于合规验证、设计评审、API 治理等工程工作流。开发者可通过 Dash 文档系统与 MCP 协议构建自己的上下文感知审查工具。