WorkBuddy 数据安全与客户咨询 FAQ 手册
本文档沉淀自 2026-05-26 至 2026-06-15 的多轮客户咨询对话，涵盖数据安全、产品形态、技术机制、生态竞品四大类共 32 个高频问题。
适用对象：售前架构师、客户成功经理、产品经理
更新时间：2026-06-15（Q1-Q17 为 5 月沉淀，Q18-Q32 为 6 月增量）
一、数据安全类（最核心）
Q1：我把文档/Excel 传给 WorkBuddy 的那一刻，产品方就有能力获取我的文档，对吗？
✅ 结论：对，这是物理事实。
- 任何 SaaS 产品，只要数据上传到服务端，厂商在技术层面就有能力获取
- 关键问题不是"会不会被获取"，而是"获取后怎么处理"
- 真正的数据安全保护来自：协议承诺 + 部署隔离 + 合同 SLA
Q2：「不落盘」承诺是什么意思？有几种强度？
✅ 「不落盘」分四级强度：
| 强度 | 名称 | 内容 | 法律效力 |
|---|---|---|---|
| L0 | 口头话术 | "我们不存你数据" | 几乎为零 |
| L1 | 用户协议 | 隐私政策写"处理后即删除" | 弱 |
| L2 | 商业合同 SLA | DPA + 违约赔偿 | 强 |
| L3 | VPC/私有化 | 数据物理上不离开客户环境 | 最强 |
关键：协议保护是"事后赔偿"，部署隔离才是"事前阻断"。
Q3：合同里要盯紧哪 4 个条款？
✅ 必盯 4 条款：
- 数据保留期（具体天数，不能是"处理完毕后"）
- 训练用途（明确不用于训练，不能是"可能改进服务"）
- 第三方共享（不分享给任何第三方，含子公司）
- 审计权 + 违约金（客户可审计 + 具体赔偿金额）
Q4：技术同事说"文档给豆包做切片处理，模型不会拼接原文，所以数据不会被训练"，对吗？
❌ 不对，这是话术陷阱。
三层错误：
- 混淆推理 vs 训练：切片是推理时的技术处理；训练是后台数据用途。两个独立系统/团队。
- 混淆上传 vs 入库：文档切片后通常落盘到对象存储，给了未来训练的可能。
- 混淆切片不拼接 vs 切片不被记忆：训练吃海量小片段，从来不需要"整份文件"，碎片就能学习。
类比反驳：
"你存银行的钱会不会被员工挪用？"
"不会，因为 ATM 取钱一次只能取 5000 块" —— 逻辑跳跃。
真正决定"是否被训练"的三件事：
- 协议写了什么（默认是否允许训练？能否关闭？）
- 部署在哪里（公有云 / VPC / 私有化）
- 合同有没有 SLA（违约赔偿、审计权）
结论：是否训练是法律 + 商业问题，不是技术问题。
Q5：豆包/通义千问处理文档时，是做 RAG 吗？
❌ 不一定，这是常见误解。
通用 LLM 产品处理文档实际有 3 种路径：
| 路径 | 触发条件 | 是否切片 | 是否 RAG |
|---|---|---|---|
| A. 全文进上下文 | 小文档（<50页）对话框直接传 | ❌ | ❌ |
| B. 代码处理（沙箱） | 中等文档 / 结构化数据 | ❌ | ❌ |
| C. RAG 切片向量化 | 知识库功能 / 超大文档 / 多文档库 | ✅ | ✅ |
关键分水岭：
- 对话框拖 PDF → 多数走 A 或 B，不是 RAG
- 创建"知识库"丢文档 → 才是 C，RAG
Q6：「切片 / 分片 / 分块」三个词是一回事吗？
❌ 不是，三个词容易被混用。
| 词 | 实际指 | 场景 |
|---|---|---|
| 切片（slicing） | RAG 把文档切成块，向量化入库 | 知识库 / RAG |
| 分片（sharding） | 数据/计算分布式拆分到多机 | 后端架构（跟数据安全无关） |
| 分块（chunking） | 长文本超过上下文窗口，分批喂给模型 | 推理时长文档处理 |
那位同事大概率说的是分块（chunking）：文档太长 → 拆块依次读 → 不还原成原文件存起来。
但他的论证依然不成立（不管哪个词）：
- 分块属于推理层，训练属于数据用途层 —— 两层独立，互不证明
- "不拼回原文"是伪命题 —— 模型不需要拼回（处理 token 序列），且不拼回 ≠ 不记得（GPT-3 已被证明能背诵训练集）
- 决定"是否被训练"的是协议条款 + 训练授权 + 数据治理流程 —— 跟分不分块、切不切片毫无关系
Q7：模型根本不"拼"东西，为什么说"不拼回原文"是伪命题？
✅ 技术层面深挖：
第一层：模型根本不"拼"东西
- LLM 工作流：原文 → tokenize → token 序列 → embedding → Transformer → 输出 token 概率
- 整个流程没有「拼接」这一步 —— 模型处理的是 token 序列，"拼回原文"是人脑的概念
- "模型不拼回原文"在技术上是废话，等于说"鱼不会走路"
第二层：训练 vs 推理是两条独立流水线
| 维度 | 推理（inference） | 训练（training） |
|---|---|---|
| 时机 | 用户每次提问时 | 离线批处理 |
| 数据流向 | 输入→权重→输出（权重不变） | 输入→loss→反向传播→更新权重 |
| "分块/切片"在哪 | 这一层 | 不在这一层 |
| "是否被记住" | 不留痕（理论上） | 被编码进权重永久记住 |
关键：分块是推理时怎么喂；训练是离线时数据用途。两条流水线物理独立，用前者论证后者无依据。
第三层：模型确实能"记住"原文（已被论文证实）
- GPT-2 训练集萃取攻击（Carlini et al., USENIX Security 2021）：从 GPT-2 提取出训练集真实数据，含姓名/电话/代码/新闻原文逐字一致
- Quantifying Memorization（Google 2022）：175B 模型对训练集中只出现 1 次的文本仍有约 1% 概率原文复现
- NYT vs OpenAI 诉讼（2023）：用特定 prompt 让 ChatGPT 输出与 NYT 文章一字不差的段落
结论：不拼回 ≠ 不记得。模型的"记忆"不是靠"拼回"，是靠权重编码的统计模式。
Q8：客户问"我上传了敏感文件，模型会不会能看到我的敏感文件信息"，怎么回答？
✅ 标准回答模板（售前必背）：
❌ 错误："不会，我们做了切片处理"（客户秒懂这是话术）
✅ 正确：
"模型一定会看到——这是它工作的前提，任何 AI 产品都绕不开。
真正的问题是看完之后会不会被记住、会不会被别人看到。
我们的承诺是：
1. 不进训练集（合同第 X 条）
2. 日志保留 X 天后自动删除（合同第 Y 条）
3. 跨用户严格隔离（架构保证）
如果你需要更高合规，我们提供 VPC 部署，数据完全在你的环境里，连'看到'都不发生在我们这边。"
这套话术的关键：先承认物理事实（建立专业可信感），再分层给承诺（合同+部署），最后给最高合规出口（VPC）。
Q9：VPC 方案，我的文件最后也是传到公网给模型了吧？为什么说 VPC 是物理隔离传不出来？
❌ 我前面说错的地方：
我说"VPC = 物理隔离传不出来"——这是话术，不是真相。
真相是："VPC"这个词被厂商滥用，里面藏了 3 种完全不同的部署模式，安全等级差好几个数量级。
「VPC 部署」3 种模式：
| 模式 | 数据在哪 | 模型在哪 | 推理时数据出 VPC 吗 | 真物理隔离吗 |
|---|---|---|---|---|
| 1. VPC 网络对接（伪 VPC） | 你的 VPC | 厂商公网 | ✅ 出（走专线，但还是出去了） | ❌ 假隔离 |
| 2. VPC 模型私有部署（真 VPC） | 你的 VPC | 你的 VPC（厂商把模型权重部署过来） | ❌ 不出 | ✅ 真隔离 |
| 3. 完全私有化 | 你的机房 | 你的机房 GPU | ❌ 不出 | ✅✅ 物理+网络双隔离 |
辨别真假 VPC 唯一硬指标：模型权重部署在哪。在客户 VPC = 真；在厂商公网 = 假。
验真 3 问（被厂商说"支持 VPC 部署"时反问）：
- 模型权重部署在哪？ 答"我们 VPC" → 模式 1；答"客户 VPC" → 模式 2
- 推理时数据出不出客户 VPC？ 答"走专线很安全" → 还是出去了；答"VPC 内闭环" → 真隔离
- 你们怎么升级模型？ 答"实时同步" → 有运维通道；答"客户审批人工部署" → 真隔离
二、产品形态类
Q10：WorkBuddy 小程序云上版本，在电脑上怎么查看？
✅ 3 条路径：
| 路径 | 操作 | 推荐度 | 说明 |
|---|---|---|---|
| A. 微信 PC 版直接打开 | 电脑装微信 PC 版 → 侧边栏小程序面板 → 找「腾讯 WorkBuddy」 | ⭐⭐⭐ 最推荐 | 会话跟手机端实时同步 |
| B. 手机扫码同步到 PC 客户端 | 手机端点右上角「在电脑打开」→ 电脑端自动弹出 | ⭐⭐ | 需要电脑端已装 PC 客户端 |
| C. Web 网页版 | 浏览器打开 codebuddy.cn → 微信扫码登录 | ⭐⭐ | 跟 PC 客户端账号体系打通 |
常见坑：
- 微信版本太低 → 小程序面板不显示
- 企业微信不支持小程序面板
- Linux 用户微信 PC 版功能受限
- 会话不互通：4 个端（PC/Web/小程序/CLI）= 4 套独立会话
Q11：WorkBuddy 小程序，云上的会话，能同步到 WorkBuddy 的 PC 客户端吗？
❌ 不能，这是产品架构决定的。
核心原因：
- 小程序云上版 = 微信小程序运行时 + 云端沙箱
- PC 客户端 = Electron 桌面应用 + 本地 Agent 运行时
- 4 个端（PC/Web/小程序/CLI）= 4 套独立会话，互相不打通
为什么不做跨端同步？
- 技术原因：上下文窗口、工具调用历史、文件上传记录——这些状态在桌面端和云端之间序列化成成本很高
- 产品定位：小程序 = 轻量随身用；PC 客户端 = 生产力主战场
- 合规考虑：跨端同步 = 数据在多端持久化，增加泄露面
正确工作流：
- 电脑上深度工作 → 用 PC 客户端
- 手机上随手问 → 用小程序
- 重要对话/文件处理 → 优先 PC 客户端
Q12：WorkBuddy 小程序端可以登陆企业版吗？
✅ 技术上可以，但有重要限制。
核心校准：
- 登录方式 ≠ 账号权益 —— 这两件事必须分开看
- 小程序端只有 1 种登录方式 = 微信授权 + 手机号
- 个人版 / 企业版区别不在登录方式上，而是在"你这个微信号绑定的腾讯云账号属于哪种租户"
翻译：小程序端根本没有"企业版登录入口"这个东西。企业版能力是跟着腾讯云账号体系走的，不是跟着登录入口走的。
所以正确说法不是"小程序不支持企业版"，而是：
"小程序登录入口只有微信一种；登录后你拿到个人版还是企业版能力，由这个微信绑定的腾讯云账号是否开通了 SaaS 企业版决定。"
三、技术机制类
Q13：WorkBuddy 在处理 Excel 的时候，本质的工作过程是怎样的？是把 Excel 给到大模型处理了吗？
❌ 不会把 Excel 喂给大模型。
Excel 不会被整个塞给大模型。大模型只是"指挥官"，pandas 才是"干活的工人"。
5 步流程：
- 文件落地：上传到本地工作空间，模型只看到「文件名 + 路径 + 大小」，不看内容
- Peek 探查：模型写代码
df.head()/df.shape/df.columns，只把 100 行输出回灌给模型 - 决策：模型基于 peek 结果写真正的统计代码（groupby/agg/...）
- 沙箱执行：pandas 真干活，这一步无大模型参与，数据不出沙箱
- 回灌+解读：只回灌结果（一张小表/几行数字），模型写自然语言解读
为什么这么设计（3 个根本原因）：
| 原因 | 说明 |
|---|---|
| Token 经济性 | 10 万行 Excel ≈ 200 万 token，上下文爆炸 |
| 准确性 | 模型直接看数据会幻觉，代码精确计算 |
| 安全性 | 数据只在沙箱，模型只见结果（VPC 版加固） |
关键差异：
- 截图：真给模型看（多模态视觉），1 张图≈1500 token，不爆
- Excel：必须代码处理，绝不能整表喂模型
Q14：如果用户是接口对接的数据呢，会传给模型吗？
✅ 分 3 种场景，3 种处理：
| 场景 | 谁调 | 数据是否进模型 | 例子 |
|---|---|---|---|
| A. 模型直接调 API（tool/MCP） | 模型 | ✅ 完整返回值进模型 | 查股票/天气/腾讯文档 |
| B. 模型写代码调 API | 沙箱 | ❌ 只有处理后摘要进模型 | 拉 10 万订单做统计 |
| C. 平台预集成连接器 | 客户端/平台层 | ⚠️ 脱敏后进模型 | 企微/腾讯会议/iWiki |
会进模型的（要警惕）：
- tool 调用返回值、模型主动调的 API 响应
- 用户输入文字、贴的截图（vision）
- 上传文档的 摘要（不是全文）
不会进模型的（默认安全）：
- 沙箱代码处理过的中间数据
- 大文件原始内容（Excel/CSV/PDF 全文）
- VPC 内被脱敏过滤掉的字段
- 数据库里没被查到的数据
Q15：如果是文档呢，模型会阅读全部文档吗，还是会写代码再本地沙箱阅读？
✅ 分 3 档处理策略：
| 档位 | 文档规模 | 处理方式 | 数据是否全进模型 |
|---|---|---|---|
| 1. 小文档（<50 页） | 单份 PDF/Word/MD | 直接抽文本进上下文 | ✅ 全进 |
| 2. 中等文档（50-500 页） | 单份大手册 | 模型写代码 + PyPDF2 处理 | ❌ 只进摘要/相关段 |
| 3. 超大/多份（>500 页 或 ≥10 份） | 知识库 | RAG（embedding + 向量检索） | ❌ 只进 Top K 段 |
类型对照：
| 类型 | 默认档位 |
|---|---|
| MD/TXT | 1 |
| 小 PDF (<20页) | 1 |
| 大 PDF (>20页) | 2 |
| Word | 1-2 |
| Excel | 2 强制 |
| PPT | 1 |
| 扫描件 | 1 + OCR |
| 知识库 | 3 (RAG) |
关键校准：
- PDF/Word/PPT 都先转纯文本，不是图像形式进模型
- 模型会动态切档：开始走档位 1，发现内容长 → 主动切档位 2
- 贴长文本进对话框 = 全文进模型（售前最常被忽视的盲点！客户以为不上传就安全）
Q16：WorkBuddy 的安全沙箱机制是怎么定义的，包括沙箱是什么时候创建的？
✅ WorkBuddy 没有"一个沙箱"，至少 3 种沙箱混用 —— 工具级 / 会话级 / 任务级，触发时机、隔离强度、销毁时机完全不同。客户问"你们有沙箱吗"，得反问"你说的是哪种"。
WorkBuddy 沙箱 3 种类型：
| 维度 | 1. 工具级 | 2. 会话级 | 3. 任务级 |
|---|---|---|---|
| 本质 | 单次命令的子进程 | 一整个云端 workspace 容器 | 临时部署/预览的独立容器 |
| 跑在哪 | 本地（PC 客户端）或云端（小程序/Web） | 云端容器集群 | 云端容器集群（CloudStudio sandbox） |
| 何时创建 | 模型每次调 Bash/Python 时 | 会话开启 / 用户首次进入云端 workspace 时 | 模型主动调 cloudstudio_deploy 等部署工具时 |
| 隔离方式 | 进程级（cwd 限制 + 超时 + 工具白名单） | 容器级（独立文件系统/独立网络/资源配额） | 容器级（独立公网域名 + 独立运行时） |
| 生命周期 | 命令结束就销毁 | 会话关闭/超时回收（小时级） | 任务完成或闲置回收 |
| 销毁后数据 | stdout/stderr 写回模型上下文，临时文件随进程消失 | 容器整体销毁，挂载卷视配置而定 | 容器整体销毁 |
| 典型对应 | 你让 WorkBuddy 跑一行 pandas 处理 Excel | 你在 codebuddy.cn 网页版打开一个项目 workspace | 你让 WorkBuddy 把 HTML 部署到云上预览 |
Q17：有时候会出现同一个任务会话中，之前的上下文不见了，是什么原因？
✅ 先区分两类"上下文消失"：
| 类型 | A. 模型上下文压缩 | B. UI 历史消失 |
|---|---|---|
| 发生位置 | 后端 LLM 输入层 | 前端渲染/缓存层 |
| 现象 | AI 突然忘了前面 | 滚不到上面的消息 |
| 用户体验 | "刚说的它怎么忘了" | "界面上找不到那条" |
| 消息本身 | 消息存在，AI 看不全 | 消息在不在 AI 眼里另说，但屏幕上人看不到 |
你这种情况的 4 类根因（按概率排序）：
- 虚拟列表渲染上限：超长会话只保留最近 N 条 DOM
- 本地缓存截断：IndexedDB / 文件存储只留最近 X 条
- 分页加载接口失败：滚到顶要拉历史，接口挂了静默失败
- 后端持久化策略截断：服务端只存最近 Y 轮（最严重）
自查 4 步 —— 3 分钟定位是哪类：
- 滚到最顶看有没有"加载更多/loading"圈 —— 有 = 第 3 类（分页问题）；什么都没有 = 第 1 或第 2 类
- 关闭 WorkBuddy 完全重启 → 重开同一会话 —— 历史回来了 = 第 1 类内存渲染；还是没 = 第 2 类缓存或第 4 类后端
- 换一台设备登录同账号打开同会话 —— 另一台有 = 本端缓存问题；两端都没 = 第 4 类后端截断（最坏情况）
- 直接问 AI："你还记得我们一开始聊 XX 那段吗？" —— 它能复述 = 纯 UI 层 bug，数据其实在；它也不记得 = A+B 都中了
四、售前实战话术模板
话术 1：客户问"你们有沙箱吗"
❌ 错误："我们有安全沙箱，所以您的数据不会泄露"（被秒拆）
✅ 正确（分版本）：
对 PC 客户端用户：
"工具级隔离——AI 生成的代码跑在受限子进程里，cwd 锁定工作目录，命令结束即销毁。但本质还是您本地的进程，所以安全靠的是数据根本没上云，不是沙箱本身。"
对云上版/企业版客户：
"三层沙箱：工具级（每次命令独立子进程）+ 会话级（独立容器，会话结束销毁）+ 任务级（部署预览独立容器）。容器之间网络/文件系统完全隔离。但请注意：沙箱执行结果会回到模型上下文——所以真正的数据安全要看合同条款（保留期/训练用途），不是沙箱。"
对最高合规客户：
"我们提供 VPC 模式 2 + 网络出站白名单——沙箱跑在客户 VPC 内的 GPU 集群上，连出站都受您的网络策略管控。这是把沙箱机制和部署隔离叠加起来。"
话术 2：客户问"XX 厂商说他们做切片处理，所以数据安全"
✅ 正确回应：
- 先问："你说的切片是 RAG 切片，还是长文档分块？"（暴露对方词不达意）
- 再说："不管哪种，这些都是推理时的技术细节，不能证明数据用途"
- 收尾："数据会不会被训练，只看用户协议第 X 条 + 商业合同，技术机制不背书合规"
话术 3：客户问"VPC 是不是绝对安全"
✅ 主动甩 3 个反方压测点，建立专业可信感：
- 运维通道：厂商升级模型、排查故障时进得来——合同要写"运维必须客户审批 + 全程录像"
- 模型权重保护反向监控：厂商怕模型被拿走 → 加密/限速/水印 → 客户在自己 VPC 里反被监控
- "逻辑 VPC" 陷阱：有的 "VPC" 是厂商在自己机房划个 VLAN 给你用，物理机还是共享 → 不是真物理隔离
所以最高合规永远是模式 3：自建机房 + GPU 自买 + 模型私有授权。
七、6 月增量：数据安全深化
Q18：客户有数十万行表格数据，在 WorkBuddy 上运行，表格数据会泄漏给大模型训练吗？
✅ 结论：数十万行物理上喂不进大模型，"整张表被训练"是伪命题。
数十万行 ≈ 几百万 token，远超模型窗口（128K~200K），所以根本进不了模型。WorkBuddy 走代码处理路径：模型只当"指挥官"写代码，pandas 在沙箱当"工人"啃全量数据。
模型从头到尾只接触 3 样东西：
- 文件元信息（名 / 路径 / 大小）
- 几十行样本（
df.head()） - 最终结果数字
六步真实路径：
| 步骤 | 动作 | 模型看到什么 |
|---|---|---|
| 1 文件落地 | 上传到工作空间 | 只有文件名/路径/大小 |
| 2 Peek 探查 | 模型写 df.head()/df.shape | 几十行样本+列名+行数 |
| 3 写统计代码 | 模型基于样本写 pandas/SQL | 自己写的代码 |
| 4 全量计算 | 沙箱 pandas 独立跑 | 无模型参与，数十万行不出沙箱 |
| 5 产出结果 | 体积从几百万 token 骤降 | — |
| 6 解读结果 | 模型拿汇总数字写分析 | 几十~几百 token 的结果 |
"会被训练吗"分两层看：
- 第一层：全量表进不了模型 → 无从被训练
- 第二层：那"几十行样本 + 结果"会不会被训练 = 协议 + 部署 + 合同问题（非技术问题）
两种破例（售前要主动声明）：
- 用户手动把表格内容粘进对话框 → 绕过沙箱，这部分会进模型
- 超大表被当知识库做 RAG 向量化 → 切片落对象存储，是另一条路径
正常"上传 Excel 让我分析"默认走代码路径，不是 RAG。
Q19：如果是接口对接的数据呢，会传给模型吗？
✅ 分 3 种场景，3 种处理（接 Q14）：
| 场景 | 谁调 | 数据是否进模型 |
|---|---|---|
| A. 模型直接调 API（tool/MCP） | 模型 | ✅ 完整返回值进模型 |
| B. 模型写代码调 API | 沙箱 | ❌ 只有处理后摘要进模型 |
| C. 平台预集成连接器 | 客户端/平台层 | ⚠️ 脱敏后进模型 |
判断口诀：模型亲自调的（A）→ 返回值进模型；模型写代码让沙箱调的（B）→ 只有结果摘要进。数据量大就走 B。
八、6 月增量：产品形态与多端
Q20：WorkBuddy PC 端能打开移动端云上创建的任务吗？
❌ 不能（接 Q11）。
- 小程序云上版的任务 = 跑在云端容器里
- PC 客户端的任务 = 跑在本地 Agent 运行时里
- 4 个端（PC/Web/小程序/CLI）= 4 套独立会话，互不打通
想跨端用，正确做法：
- 重要文件 → 在 PC 客户端重新上传处理
- 或把小程序端结果复制/导出，手动带到 PC 端
不要期待"手机建的任务 PC 自动出现"——架构上就不通。
Q21：右上角默认助手「WorkBuddy Beta」能改名吗？
❌ 内置默认助手名字锁死，改不了。
- 「智能体设置」里只有"禁用插件 / 禁用团队"两个开关，没有名称字段 → 证明名字是系统写死的
- 想要自定义名字（如「囷囷」）→ 新建一个自定义助手：主界面「专家」入口或「➕ 新建助手」，名称/人设/技能随你定
- 新建后右上角切换过去用，把默认那个晾一边
售前提醒：客户想要品牌化命名（如「XX 客服」），引导走自定义助手，别在默认助手上找改名入口。
Q22：网站访问白名单能设置吗？入口在哪？
✅ 能力存在，但入口属企业管控范畴。
- 白名单本质 = 沙箱出站网络管控（控制 AI 生成的代码能访问哪些外部站点）
- 个人版用户通常看不到入口；企业版的白名单一般在企业管理后台（仅管理员可见）或 VPC 安全组层面配置
- 透明披露：没有公开文档给出精确路径，建议直接问产品侧/管理员
售前要点：白名单是企业级管控能力，跟"出站 vs 入站"要分清——白名单管的是出站（代码往外连），不是入站（谁能访问你）。
九、6 月增量：技术机制深化
Q23：本地沙箱 coding 中，大语言模型扮演什么角色？
✅ 模型是"大脑/指挥官"，不是"工人"。
- 模型不亲自处理数据，它负责：理解需求 → 写代码 → 看执行结果 → 决定下一步
- 真正干活的是沙箱里的 Python/Node/pandas —— 数据在这层流动，模型碰不到原始数据
- 这就是为什么"数十万行表"安全：工人（沙箱）啃全量，大脑（模型）只看汇报
一句话：模型动嘴（写代码+读结果），沙箱动手（跑代码+啃数据）。
Q24：Agent 的 Tool Call 是干什么用的？
✅ Tool Call = 模型"点单"，平台"上菜"的闭环机制。
完整闭环：
- 模型决定要用某个工具 → 输出一段 JSON 请求（工具名 + 参数）
- 平台审计这次调用（命令安全检查）
- 沙箱执行工具，拿到结果
- 结果回灌给模型上下文
- 模型判断是否还要再调（不够就再点单，够了就总结）
关键认知：模型本身不会执行任何操作，它只会"说要调什么"。真正执行靠平台的工具运行时。这是 Agent 和普通聊天机器人的本质区别。
Q25：上下文折叠的技术实现和作用是什么？
✅ 作用：解决长会话超出模型 token 上限的问题。
触发→处理流程：
- 触发：上下文接近模型窗口上限
- 切分：保留最近 N 轮原文（保留区）
- 生成摘要：把更早的历史压缩成摘要
- 替换重组：摘要 + 保留区 = 新上下文
- 续跑：在压缩后的上下文上继续
三种策略：
| 策略 | 做法 | 代价 |
|---|---|---|
| 截断 | 直接丢最早的 | 简单粗暴，丢信息 |
| 摘要 | 早期历史压成摘要 | 平衡，有信息损耗 |
| 分层记忆 | 摘要 + 关键信息单独存 | 最优，实现复杂 |
用户侧表现：有时"AI 突然忘了前面" = 折叠时把那段压进摘要、细节丢了（接 Q17 上下文消失 A 类）。
Q26：Graph RAG 过时了吗？
❌ 没过时，但要看场景。
- 普通 RAG：把文档切片向量化，按相似度召回 Top K —— 适合"事实查找"
- Graph RAG：在切片之上再建实体关系图谱，能回答"多跳推理"问题（A 和 C 通过 B 有什么关系）
判断用哪个：
| 需求 | 选择 |
|---|---|
| 单点事实查找（"X 的定义"） | 普通 RAG 够了 |
| 关系推理（"谁和谁有关联"） | Graph RAG 有价值 |
| 全局摘要（"整个库讲了什么"） | Graph RAG 优势明显 |
结论：Graph RAG 是普通 RAG 的"增强款"，不是替代关系，更不是过时——只是成本更高，按场景选。
十、6 月增量：SDK 与生态
Q27：WorkBuddy 客户端有 API / SDK 开放吗？
✅ 区分两个层面：
- WorkBuddy 客户端本身：是终端产品（壳），通常不直接对外开放"客户端 API"
- 底层 CodeBuddy 有 Agent SDK：TS + Python 双语言，
npm install @tencent-ai/agent-sdk，提供 14 个 Hook 事件
"客户端 API"概念澄清：客户端是给人用的 GUI，不是给程序调的接口。真正能被二次开发调用的是底层 Agent SDK，不是客户端。
Q28：客户能基于 CodeBuddy Agent SDK 封装成类似 WorkBuddy 的客户端吗？
✅ 能封装壳和内核，但底座永远依赖平台。
三层边界：
| 层 | 内容 | 客户能自己做吗 |
|---|---|---|
| ① 壳 | UI、多端入口、交互 | ✅ 完全自由 |
| ② 内核 | Agent 编排（基于 SDK） | ✅ 可封装 |
| ③ 底座 | 模型 / 算力 / 计费 | ❌ 永远依赖平台 |
翻译：客户可以做一个"长得不一样的 WorkBuddy"，但模型推理、算力、计费这层绕不开腾讯。壳和编排是客户的，发动机是平台的。
Q29：客户说 Coze 支持拉起本地的 Codex 和 Claude Code，形成跨平台多 Agent，怎么实现的？
✅ 机制：反向通道 + 本地 CLI 发现 + 远程代理执行。
- 本地跑一个 bridge 进程（如
npx coze-bridge），建立到云端的反向通道 - bridge 发现本地已装的 CLI（codex / claude-code 等）
- 云端 Coze 通过反向通道远程触发本地 CLI 执行，结果回传
本质：Coze 在云端当编排大脑，本地 bridge 当"手"，把本地 Agent 当成远程工具调用。
Q30：这类 Agent 编排层产品的真实价值是什么？
✅ 价值真实，但护城河浅。
编排层（胶水层）做四件事：
- 连接 —— 把分散的 Agent/工具接到一起
- 编排 —— 定义多 Agent 协作流程
- 远程触达 —— 跨设备/跨平台调度
- 工作台 —— 给用户一个统一操作界面
反方压测（护城河浅在哪）：
- 夹在模型底座（上游有议价权）和终端入口（下游抢用户）之间
- 连接和编排能力容易被复制
- 一旦模型厂商/入口方自己做编排，胶水层被挤压
结论：解决真实痛点（多 Agent 协作乱），但长期要么向上做模型、要么向下抢入口，单纯做胶水难守。
十一、6 月增量：概念科普（客户常问的"这是什么"）
Q31：pandas / SQL / groupby / sum 这些是什么？是脚本吗？
✅ 是数据处理的代码工具，不是"脚本"那么笼统。
| 名词 | 是什么 | 类比 |
|---|---|---|
| pandas | Python 的数据处理库（操作表格） | Excel 的代码版 |
| SQL | 查询数据库的语言 | 跟数据库对话的话术 |
| groupby | 按某列分组 | Excel 数据透视的"行分组" |
| sum / agg | 分组后求和/聚合 | 透视表的"值=求和" |
"生成 pandas"是什么意思：模型写一段用 pandas 库的 Python 代码，让沙箱执行去处理表格。不是模型自己算，是模型写代码让工具算。
类似 pandas 的工具库：Polars（更快）、NumPy（数值计算）、Dask（超大数据分布式）、DuckDB（SQL 直查文件）。
Q32：Python / Node.js / npm / Git 这四个是什么？
✅ 开发者四件套：
| 工具 | 是什么 | 一句话 |
|---|---|---|
| Python | 编程语言 | 数据/AI 最常用的语言 |
| Node.js | JavaScript 运行环境 | 让 JS 能跑在电脑上（不只浏览器） |
| npm | Node 的包管理器 | 装 JS 第三方库的"应用商店" |
| Git | 版本控制工具 | 代码的"时光机+协作系统" |
跟 WorkBuddy 的关系：沙箱里内嵌了这四件套，所以 AI 写的代码能直接跑、能装库、能管版本——这就是"运行环境一致化"（根治"在我电脑上是好的"）。
十二、一句话沉淀（售前必背）
"切片+不拼回=数据不被训练"是伪逻辑 —— 混淆推理 vs 训练、上传 vs 入库、切片不拼回 vs 切片不被记忆。
"不落盘"承诺是分级的 —— L0 口头 / L1 用户协议 / L2 商业合同 SLA / L3 VPC/私有化。
"传出去 = 被获取"是物理事实 —— 协议保护是事后赔偿，部署隔离才是事前阻断。
"VPC 物理隔离" ≠ 数据不出公网 —— 只有模式 2（模型权重部署到客户 VPC）才是真隔离；厂商口中 "VPC" 多数是模式 1（VPC 网络对接） —— 走专线 ≠ 不出去了。
沙箱解决"代码跑在哪"，不解决"数据流向哪"。
真正的数据安全 = 沙箱（执行隔离）+ 合同（用途承诺）+ 部署（VPC 网络隔离）+ 治理（权限审计），四件套缺一不可。
客户问"模型会不会看到我的敏感文件"——这是个伪问题。
一定会看到（物理事实）。
真问题是"看完之后"——这才是合同+部署能管的地方。
十三、附录：咨询最终收束链
- 第一轮：「不落盘」四级强度（L0-L3）+ 4 条款必盯
- 第二轮：切片/分片/分块三词区分 + 技术机制 ≠ 合规承诺
- 第三轮：模型不"拼" + 推理 ≠ 训练 + 论文证据（GPT-2/Google/NYT）
- 第四轮：客户真问题不是"会不会看到"，是"看完之后"
- 第五轮：VPC 3 模式 + 验真 3 问
- 第六轮：沙箱 3 类型 + PC vs 云反直觉 + 5 反方压测 → 数据安全四件套（沙箱+合同+部署+治理）
- 第七轮（6月）：数十万行表走代码路径 + 模型只当指挥官 + Tool Call 闭环 + 沙箱位置由端形态决定（与版本正交）
- 第八轮（6月）：SDK 三层边界（壳/内核/底座）+ Coze Bridge 反向通道 + 编排层护城河浅 + 概念科普（pandas/四件套/上下文折叠/Graph RAG）
*本文档由 WorkBuddy 协助整理，基于真实客户咨询场景沉淀。如需更新或补充，请联系产品架构师。*