Kimi Work 反馈功能被指自动上传最近 5 个 agent 会话：无提示、无法单独关闭

SecurityOnline 于 8 月 18 日报道，显示：用户点击应用内反馈按钮提交问题时，客户端除上传诊断日志外，会自动把最近更新的 5 个 agent 会话记录打包上传。反馈界面从头到尾没有披露这些附件，也没有单独退出上传的选项。这些记录包含模型请求、工具定义与 MCP 工具元数据，单个会话的压缩包上限约 8MB。

结论来自 RuntimeWire 8 月 15 日发布的调查：开发者在 Windows 防火墙中阻断 Kimi.exe 出站流量后提交了一条测试反馈，客户端为 5 个不同会话各生成一个压缩包并逐一开始上传，全部被防火墙拦截，主进程日志留下「ok: 0/5 archives uploaded in 166ms」。报道发布前，RuntimeWire 已向月之暗面发出置评请求，截至发布未获回应。

一次反馈，五个会话：客户端先排序再打包

RuntimeWire 的静态追踪显示，反馈表单提交前，渲染进程并行启动两个后台任务：上传诊断日志，以及上传原始会话记录。后者调用 conversations.list 列出全部会话，按最后更新时间（updatedAt）排序后取前 5 个——处理器根本不接收「当前会话」作为参数。

选中的会话由随客户端安装的后台组件 Daimon 各生成一个 ZIP 归档，与诊断日志包一起经 /file/upload_simple 上传，随后才提交反馈正文。这套流程不只在对话页面生效：账户菜单、正在进行的对话、插件页、生成网站预览四个入口的反馈共用同一套收集逻辑；插件页的反馈表单甚至禁用了用户上传图片，提交时仍执行同样的打包上传。

每个压缩包上传完成后返回的对象名，被写进反馈正文中一个隐藏元数据前缀 rawRecordsObjectNames 之下；正常附件字段 file_object_names 留给用户自己选择的图片。用户在表单里能看到的，只有问题描述和可选截图。

结果正如 SecurityOnline 所总结：即使反馈针对的只是一个小故障，其他近期工作——独立的编码项目、文档处理任务、无关的 agent 自动化运行——都可能被一并打包发给 Kimi 团队。

「0/5 archives uploaded in 166ms」：防火墙测试实录

RuntimeWire 提取了生产版 app.asar 与 Daimon 0.5.49 Windows 包（7 月 24 日构建）做静态分析，未修改任何文件，并公布了相关文件的 SHA-256 哈希。反馈按钮的调用链被完整追踪：渲染进程 → preload IPC → 桌面主进程 → Daimon 归档生成器 → /file/upload_simple 与 /user/feedback 两个 HTTP 端点。

运行验证中，测试者先为已签名的 Kimi.exe 建立临时出站防火墙阻断规则，再从 Work > Plugins 打开反馈，输入无害文本「RuntimeWire test.」提交。客户端随即选出 5 个不同的会话 ID，为每个生成归档并进入上传阶段，全部以 ERR_NETWORK_ACCESS_DENIED 失败。

主进程日志（%APPDATA%\kimi-desktop\logs\main.log）记下 5 次失败后输出「ok: 0/5 archives uploaded in 166ms」。防火墙保证了记录没有离开机器，也证实了该处理器在生产环境中真实执行。测试版本为 Kimi Desktop 3.1.5（release 3.1.5+c88420152）、Daimon 0.5.49、Electron 41.7.2、Windows x64，测试方声明没有查看或传输任何会话内容。

另一个值得记录的细节：Daimon 0.5.49 注册的生产控制方法 conversations.getRawRecordsArchive 与日志标签 FeedbackRawRecords，RuntimeWire 都没有找到任何公开先例——五会话选择逻辑此前没有任何公开文档。

压缩包里是 wire.jsonl：模型请求、工具定义与 MCP 元数据

对每个选中的会话，Daimon 会找出主 agent 的 agents/main/wire.jsonl 以及所有子 agent 的记录文件。Kimi 官方文档把这份文件描述为主 agent 的「完整通信记录」（据 RuntimeWire 引用），支持会话恢复与重放，其中包含带工具 schema、请求参数和 MCP 工具清单的请求痕迹。

规模限制是明确的：单个会话归档最多包含 100 个记录文件，每个文件读取最近 500 条 JSONL 记录；单个 ZIP 上限 8 MiB，5 个归档的客户端侧上限约 40MB，另加独立的桌面日志包。

Daimon 确实做了清洗，但只按大小和编码判断：移除疑似大段 base64 的数据块、把超长值替换为长度加哈希标记、普通字符串限制在 8,192 字符内、格式异常的记录替换为含 256 字符预览的诊断信息。它不检查密码、API 密钥、访问令牌、私有源码、shell 输出或敏感文件路径，限制以内的普通字符串原样保留。

归档清单还会记录本地会话路径、记录路径和处理统计。对比之下，Kimi CLI 提供单独的显式会话导出流程，其文档警告导出文件可能包含代码、命令输出和文件路径，要求用户分享前自行检查内容；反馈流程没有任何同类警告或审查步骤。

反馈框不列附件，帮助页只说「设备和账户上下文」

Kimi Work 的反馈窗口让用户描述问题，并提示可以上传或粘贴图片，但不列出即将上传的诊断归档、5 个会话压缩包或它们的合计体积；没有附件预览、同意框，也没有选择会话的控件。

Kimi 的公开帮助页只说应用内报告会自动附带「设备和账户上下文」，未提及最近 agent 会话的原始记录；RuntimeWire 在 8 月 15 日复查时该文档为最新版本。月之暗面 8 月 4 日生效的隐私政策允许公司收集可能包含对话内容的会话信息、反馈数据和日志，措辞覆盖的是 Kimi 处理的各类信息，并未提到反馈会附带 5 个无关会话的压缩包。

RuntimeWire 点出了用户看不到的产品选择：一份插件报告、网站预览报告或普通账户报告，可以携带 5 个无关近期会话的有界记录，而这些会话可能涉及不同的项目、文件夹、客户或凭据。

核心问题：收集范围与告知不足

两家媒体对事件性质的判断一致：目前没有证据表明这是传统意义上的安全漏洞，测试也没有发现远程利用路径；行为只在用户主动点击反馈按钮时触发，不提交反馈，会话就不会上传。问题出在数据收集范围和用户知情上。

分析作者本人随后把发现发布到，写道：「这些会话里可能有任何东西，而你完全不知道自己在把它们全部发给 Kimi。我已经发邮件提醒他们了。」

8 月 15 日，X 用户 Michael Guo（@Michaelzsguo，自称从事 AI agent 与 AI-native 组织建设）用中文转述了这项发现，并给出了他的判断：对 agent 产品来说这是一条明确红线，「Agent 权限越大，它接触的数据越敏感；任何超出用户当前操作范围的数据上传，都应该 explicit disclosure + explicit consent。否则，帮你工作的 Agent，很容易变成你根本不知道它在向外发送什么的 Agent。」

RuntimeWire 在报道末尾列出了月之暗面需要回答的问题：该行为何时随哪个版本上线、哪些桌面版本和平台包含它、上传的归档在服务器保留多久、谁可以访问、服务端是否再做额外脱敏。用户侧则至少需要三样东西：提交前能查看拟上传的附件、把收集范围限制在正在报告的会话、以及不提供会话记录也能提交反馈。

在月之暗面给出回答之前，用户唯一确定的边界来自 SecurityOnline 的确认：不点反馈按钮，会话就不会被上传。