Claude Code、Cowork 与 KnowSales：如何在不同 AI 工作空间复用同一份销售记忆
用 Claude Code 和 Cowork 调用 KnowSales MCP 的真实工作流：读取客户档案、产品知识和沟通记录，受控写回 activity，并完成写后读回。
结论先说
Claude Code 和 Cowork 不必分别维护两套销售资料。更可靠的做法是：让两个 AI 工作入口都通过 MCP 使用同一套 KnowSales 销售上下文，同时为每个入口创建独立、最小权限的凭据。
分工可以很清楚：
- Claude Code 适合结构化检索、批量整理、文件处理和可重复执行的工具工作流；
- Cowork 适合在通用办公任务中组合文件、搜索、连接器与较长步骤；
- KnowSales 保存客户 profile、沟通 activity、产品知识和权限化工具；
- MCP 让两个入口在需要时读取或写入同一套业务对象。
截至 2026 年 8 月 28 日，KnowSales 用户已在 Claude Code 和 Cowork 的日常工作中持续完成双向读写。这里的“实测”是 KnowSales 用户的实际使用证据，不是 Anthropic 对 KnowSales 的官方认证，也不保证未来所有版本和账号环境自动兼容。
为什么不要把销售记忆分别留在两个 AI 对话里
如果同一位销售在 Claude Code、Cowork 和其他 AI 产品之间切换，最容易出现四种断裂：
- 一个入口知道最新客户进展，另一个还停留在旧对话；
- 产品规格被复制成多个版本，无法确认哪份最新；
- 当次会议、客户长期偏好和 AI 推测混在一起；
- AI 说“已经保存”，但无法从真实客户页面或对象接口读回。
这不是模型记忆长度的问题，而是业务事实没有稳定归属。聊天历史适合保存任务上下文，不适合替代客户与产品的系统记录。
Claude Code 与 Cowork 应该如何分工
| 任务 | Claude Code 更适合的情况 | Cowork 更适合的情况 |
|---|---|---|
| 客户研究 | 需要多工具、明确步骤和结构化输出 | 需要结合办公文件与自然语言协作 |
| 批量核对 | 需要重复处理多个对象并输出清单 | 需要人工在过程中查看和调整 |
| 产品资料 | 需要分析文件结构、字段或批量内容 | 需要阅读、整理和制作办公产出物 |
| 客户回复 | 需要证据提取、模板或可重复 workflow | 需要自然对话、上下文讨论与润色 |
| 写回 KnowSales | 适合明确工具、参数和读回步骤 | 适合用户在任务中确认后沉淀结果 |
这张表不是能力排名。实际体验会受模型、账号、权限、客户端版本和任务类型影响。最重要的是：两个入口都不要形成新的事实孤岛。
Anthropic 官方资料说明，Claude Code 可以通过 MCP 连接外部工具和数据；Claude 的 remote custom connectors也可供 Claude、Cowork 等入口使用，但远程连接由 Anthropic 云端发起，网络和管理员设置必须符合要求。具体接入方式应以当前官方界面为准。
KnowSales 提供的不是“整库塞给模型”
KnowSales MCP 将销售数据拆成明确工具。当前实际可见工具取决于 API Key allowlist、凭据 scope 与工作区角色，不存在对所有连接都固定一致的工具数量。
常见工作流可能使用：
| 阶段 | 典型工具 | 目的 |
|---|---|---|
| 搜索客户 | search_customers、list_customers | 查重并找到候选客户 |
| 精确读取 | get_customer | 核对公司、画像和稳定事实 |
| 读取沟通 | search_activities、get_activity | 取得具体历史事件与来源对象 |
| 产品问答 | search_knowledge、get_product_info | 查找产品、FAQ 与销售知识 |
| 保存画像 | save_customer_info | 写入缓慢变化的公司与联系人信息 |
| 保存活动 | save_activity | 记录本次邮件、电话、会议与下一步 |
写入工具需要相应权限。默认知识只读凭据不会因为 Agent 提出写入请求就自动获得写权限；客户建档、团队知识管理和外部共享也应使用不同凭据模板。
一条可靠的跨入口工作流
第一步：从同一客户身份开始
用户给出公司名、邮箱域名、联系人或其他硬标识符。AI 先用 search_customers 查候选，再通过 get_customer 核对。仅凭行业词或产品词相似，不能认定是同一个客户。
第二步：只读取完成任务所需的上下文
回复询盘通常需要：
- 客户 profile 中的稳定背景；
- 最近几条相关 activity；
- 与问题直接相关的产品知识；
- 必要时的最新公开网页来源。
没有必要把整个工作区全部送入模型。工具化检索可以缩小数据范围，也让来源更容易核对。
第三步：事实、推断和草稿分层
AI 输出应明确区分：
- 客户已确认；
- 我方历史记录；
- 产品知识库当前版本；
- 网页或第三方说法；
- AI 推断与待确认问题。
如果价格、规格、交期或合同条件缺少证据，应停在草稿与待确认状态。
第四步：只写入用户确认的结果
稳定公司背景进入 profile；当次邮件、电话、会议、客户承诺和下一步进入独立 activity。不要因为 AI 已经生成了草稿，就把尚未发送的内容写成已发生事实。
第五步：写入后必须读回
保存完成后，再使用 get_customer 或 get_activity 读取真实对象，核对：
- customer ID 是否正确；
- activity ID 是否生成；
- 业务发生时间是否正确；
- 正文、下一步和相关产品是否一致；
- 是否错误影响另一位同名客户。
只有真实对象读回一致，才能把这次任务视为完成。
一个脱敏示例：从产品问题到客户回复
“公司 A”询问某设备是否适用于一种新材料，并附上一份规格文件。
在 Claude Code 中，销售可以先让 Agent：
- 查找公司 A 并核对域名；
- 读取其最近一次测试记录；
- 搜索相关机型与应用知识；
- 从附件提取尺寸、材料和产能要求；
- 输出“已确认 / 待工程确认 / 建议回复”三部分。
之后，销售可以在 Cowork 中继续讨论措辞、整理会议材料或生成办公文档。两个入口都可以按需再次读取 KnowSales，而不是依赖从另一个聊天窗口复制的摘要。
客户回复真正发出后，再写入一条 activity，并读回检查。若工程尚未确认参数，activity 应记录“已向工程询问”，而不是把建议参数写成产品承诺。
每个入口为什么应该使用独立 Key
| 做法 | 风险 | 更稳妥的方式 |
|---|---|---|
| Claude Code 与 Cowork 共用一把长期 Key | 无法单独撤销或区分入口 | 每个客户端单独创建 Key |
| 所有入口都给完整写权限 | 单次配置错误影响范围过大 | 默认只读，需要沉淀时再给受控写入 |
| Key 放进仓库、截图或共享文档 | 凭据可能长期泄露 | 使用客户端安全配置或环境变量 |
| 只看连接状态为绿色 | 不能证明权限与工具正确 | 验证 tools/list 和实际允许/拒绝调用 |
| Agent 说保存成功就结束 | 可能写错对象或根本未写入 | 按 customer/activity ID 读回 |
KnowSales 当前的 API Key 工具列表会同时受到凭据 allowlist、scope 和工作区角色约束。不同入口分开授权，既便于问题定位，也便于撤销。
上线前的六项验收
- Claude Code 与 Cowork 分别能列出工具；
- 只读 Key 看不到客户写入工具；
- 使用一个已知产品条目完成读取与来源核对；
- 使用一个身份明确的脱敏测试客户完成读取；
- 只在授权环境中写入一条无歧义 activity；
- 使用返回的 ID 读回，并在 KnowSales 页面核对同一对象。
客户端版本或管理员策略变化后，应重新执行验收，而不是依赖上一次成功。
当前能力边界
- KnowSales 已提供客户、活动、产品知识和权限化 MCP 工具，但不同凭据的工具范围不同；
- Claude Code、Cowork 与 KnowSales 的双向使用来自用户持续实测，不是厂商认证；
- Claude 的连接器、权限和套餐规则由 Anthropic 决定，可能变化；
- AI 仍可能选错对象、遗漏来源或误解文件，重要商业事实必须人工复核；
- KnowSales 内置 Agent 是补充入口，不用来取代 Claude Code 或 Cowork 的通用办公体验。
相关阅读
下一步
连接 Claude Code、Cowork 或其他 AI 工作空间到 KnowSales。建议先为每个入口创建独立的最小权限 Key，只做读取验收；确实需要写回时，再升级权限并完成一次真实对象读回。
兼容状态核对日期：2026 年 8 月 28 日。本文中的公司 A 为合成示例，不对应任何真实客户。