输入来源：Patsnap 内部 AI Transformation 讨论（@Yang Si-Ting / @顾晓龙 / Sofie）。本文把买方的真实诉求与他们正在权衡的方案，对齐到 Dokki 的定位与合作路径。配套：同文件夹《Patsnap 合作 Deck 大纲》（含方案 A/B 报价）、根目录《AI transformation》（内部分工 CHAIN）。
一句话结论
Patsnap 的诉求其实是两层，不是一件事：
Layer A — 知识 / 工作流底座：每个部门的每个 workflow 能有序、可编辑地沉淀成 playbook，新知识有地方持续产生、被 agent 复用。→ 这是 Dokki 的主场，o365 / 钉钉 / Confluence 都不是 agent / MCP 原生，承载不了「可编辑的 playbook + 多 agent 协作写入」。
Layer B — Enterprise Context Layer：知识散落在 CRM、客服、BI、Jira、公有云等 10+ 系统里，需要统一被 agent 检索调用。→ 这才是他们在权衡 Vespa 自建 vs Glean 类的战场。
Dokki 的正确定位：不与 Layer B 二选一，而是坐在它之上做统一调用 / 协作 / 沉淀面。 无论 Patsnap 最终选 Vespa 还是 Glean，Dokki 都是 agent 和人真正「干活、写入、复用」的那一层。
一、Stakeholder 诉求纪要（输入）
角色 | 关注点 / 原话要点 |
|---|---|
Yang Si-Ting | AI transformation 方向：自建知识库，要有序、有条理、可编辑 playbook / 步骤；目标是把每个部门每个 workflow 都沉淀下来，且能按每个人需求灵活改动；需要更好的公司整体知识库 + agent/MCP 权限管控。年底目标：每个部门至少有几个 workflow 用这套新 AI workflow 去做并沉淀。 |
顾晓龙 | 负责文档库选型。标准：适合企业级管理 + MCP 要强大。盘点了中西方现有三大知识库（o365 / 钉钉 / 自部署 Confluence），认为三者各有用途、难互相取代；将继续找适合中西方全员的体系，包括 Sofie 提到的 Dokki。 |
Sofie | 主动引入 Dokki 进入选型视野。（内部分工中负责 agent 管理 / 工作流搭建。） |
关键事实：买方已把 Dokki 纳入选型清单，且选型负责人（顾晓龙）的两条硬标准——企业级管理 + 强 MCP——正好是 Dokki 的两个卖点。这是一个「已进入考虑集」的机会，不是冷启动。
二、Layer A：文档库 / 知识底座选型
顾晓龙盘点的三大体系都成熟，但都不是为「agent 协作 + workflow 沉淀」设计的。Dokki 不替代它们，而是补上增量沉淀层。
体系 | 优势 | 对 AI native 的局限 |
|---|---|---|
o365（SharePoint / OneDrive / 三件套） | 西方全员熟悉、合规成熟 | 非 agent / MCP 原生；新知识沉淀弱，无法承载可编辑 playbook |
钉钉文档 & 知识库 | 国内全员习惯、组织架构集成深 | 封闭生态，对外 MCP / agent 调用能力弱 |
自部署 Confluence | 已买断、可控 | 无法升级、非 agent 原生、长期维护成本高 |
Dokki | MCP 原生（可进可出）、可编辑 playbook、融合式 RAG、org→workspace→resource 三级权限、CRDT 多 agent 并发写入 | 定位为增量沉淀层；存量迁移需配合，不强求替换三件套 |
对买方的话术：不要求大改、不要求从头新建（呼应他们「不要大改 / 集成现有 / 全员普及优先」的前提）。存量继续放 o365 / 钉钉 / Confluence，新产生的知识和 workflow 通过 MCP 无缝沉淀进 Dokki，让 agent 直接复用。
三、Layer B：Enterprise Context Layer（Vespa vs Glean）
买方知识不止在文档里，还分布在多套系统。这是他们正在纠结的真问题。
涉及系统盘点：
文档 / 知识库：o365、钉钉、自部署 Confluence
CRM：Salesforce、销售易
数字化运营 / BI：观远
客服：七鱼、Zendesk
研发 / 项目：Jira
公有云：AWS、Tencent、OCI
营销：Hubspot、径硕
会话智能：Gong、钉钉 A1
产品知识：帮助中心、GTM 材料
维度 | 方案 1：Vespa 自建 | 方案 2：Glean 类 | Dokki 的关系 |
|---|---|---|---|
形态 | 自建检索（多模态 embedding + 混合检索），嫁接 o365 + 钉钉 + Confluence | 成熟产品开箱即用，agent 经 Glean MCP 读取各源 | 不二选一：Dokki 是上层调用 / 协作面 |
能力 | 快；全文 / 关键词 / 混合 / 多模态 | 成熟、覆盖广 | Dokki 融合式 RAG 负责「新沉淀知识」的检索 |
中国系统兼容 | 自己处理，可控 | 差：国内系统 RBAC 难获取、各有玩法、延迟问题 | Dokki MCP 原生，已接 MCP 的系统直接复用，减少造轮子 |
成本 / 工作量 | 数据处理量大，需 search 团队支持 | license + 集成轮子多、难维护 | — |
权限 | 自行治理 | 国内系统 RBAC 难统一 | Dokki org→ws→resource + RBAC（开发中）提供统一权限面 |
诚实结论：Dokki 不是 Glean 的替代品。Layer B 的「跨 10+ 异构系统检索」无论谁做都重，尤其国内系统 RBAC 是公认硬骨头。Dokki 的价值是——无论 Patsnap 选 Vespa 还是 Glean，检索出来的上下文最终要有人 / agent 去用、去写、去沉淀，那一层就是 Dokki。同时，对于已经能做成 MCP 的系统，Dokki 原生消费，省掉一部分「造轮子」。
四、推荐路径（对齐年底目标）
呼应 Yang Si-Ting 的年底目标「每部门至少几个 workflow 用新方式沉淀」：
Phase 0（即刻）：选 1–2 个有现成数据源 MCP 的部门（如 GTM / SEO，已有可复用脚本）做样板，跑通「MCP + 大模型 + 存 Dokki + 发布」闭环。
Phase 1（短期）：Layer A 落地——新知识 / workflow 一律沉淀进 Dokki，存量三件套不动；Dokki 融合式 RAG 先服务新沉淀内容。
Phase 2（中期）：Layer B 决策——按「有多少系统能干净地暴露 MCP」来定 Vespa vs Glean；Dokki 作为统一消费面接入二者。
Phase 3（年底）：横向铺开到各部门，每部门沉淀数个可复用 playbook；RBAC 权限模型上线，支撑全员级管控。
五、商业 / 合作结构
沿用《Patsnap 合作 Deck 大纲》已有两套（细节见该文档，此处不重复）：
方案 A：投资 / 内部孵化。
方案 B：直接售卖——AI 功能按 token（内部价 vs 外部价），席位按月整体收费（避免抑制建群）。席位制天然贴合「全员普及」的年底目标。
待办：Patsnap 专属报价需单独细化——已在 Dokki Dev《需求看板》挂「Dokki × Patsnap 竞品对标方案 + 合作 Solution 报价」(进行中 / P1)。本文不含具体数字，以该 todo 产出为准。
六、待确认 / Next Steps（按 stakeholder 分工）
[ ] 顾晓龙：把 Dokki 正式纳入选型对比表，明确「企业级管理 + 强 MCP」两条标准下 Dokki vs 三件套的评分。
[ ] 顾晓龙 / Search 团队：评估 Layer B——盘点各系统 MCP 暴露成熟度，输出 Vespa vs Glean 的决策依据。
[ ] Sofie：选定 Phase 0 样板部门，搭第一批 agent / 工作流。
[ ] Dokki 侧（Brad）：① 出 Patsnap 专属报价；② 准备 RBAC / 企业管理上线时间点（对方明确关注 agent/MCP 权限管控）。
[ ] 同步会：Yang Si-Ting ↔ 顾晓龙 先对齐文档库体系方向，再拉 Dokki 进一轮 demo。
开放问题（继承自 Deck 大纲附录）
跨 workspace 调阅文件的权限边界
workspace 按项目建 vs 按人员管理；workspace 过百如何检索
权限粒度：部门 / 职级 / 目录 vs 内容隔离（法务场景）