智能机器人观察 — 工业机器人、人形机器人、具身智能与服务机器人产业资讯与深度分析

<figure><img src="https://img.huxiucdn.com/ai/ai-general-cover/202608/27/33299-prod-db-general-1-1787796742718.png?imageView2/1/w/1440/h/810/|imageMogr2/strip/interlace/1/quality/85/format/png" /></figure>小红书用户“一只喵喵喵”发了一篇帖子，标题能把宇宙条的法务直接吓出心脏病来：《豆包工作扒光你的隐私》。按照原帖作者的说法，豆包工作刚安装完成，就扫描了电脑上的多个Agent目录，把放在Codex、Claude、Gemini等产品下面的Skill都找了出来，其中还有一些作者自己开发、尚未......本文来自微信公众号：<a href="https://mp.weixin.qq.com/s/mojtM1yr9IDESuU9Qkz0ug" style="text-decoration: none;" target="_blank"> ZAI科技 </a>，作者：Kevin小红书用户“一只喵喵喵”发了一篇帖子，标题能把宇宙条的法务直接吓出心脏病来：《豆包工作扒光你的隐私》。按照原帖作者的说法，豆包工作刚安装完成，就扫描了电脑上的多个Agent目录，把放在Codex、Claude、Gemini等产品下面的Skill都找了出来，其中还有一些作者自己开发、尚未公开、仍在测试的Skill。整个过程既没有事前提示，也不是用户主动发起。作者的原话相当有冲击力：豆包工作“直接全吃进去了”。<figure><img height="1440" src="https://img.huxiucdn.com/article/content/26-08-27/435bfa80-3a1c-40ab-8998-fb535d5c24ba.png" width="1080" /></figure>豆包工作团队的舆情管理水平相当值得肯定：根据评论区截图，官方客服向用户致歉，并表示“目前我们已关闭该功能，后续会改为用户自主选择的手动导入方式”。<figure><img height="844" src="https://img.huxiucdn.com/article/content/26-08-27/306b9fae-4fe3-4c05-9473-ef251c50e17d.png" width="1080" /></figure>目前原帖已经删除。事情留下的几个问题，仍然值得拆开看：桌面App真的可以不经授权扫描并复制文件吗？Agent互相导入Skill是不是行业惯例？这算不算侵犯隐私？以及，既然豆包工作能迅速关闭这项功能，为什么一开始没有让用户自己选择？“扒光隐私”，这帽子确实扣得有点大客观地说，小红书原帖的标题确实有些情绪化。目前能够确认的，是豆包工作曾经自动扫描多个预设的Agent Skill目录，并主动完成复制工作，将其他Agent安装的Skill复制到豆包工作的相关目录。但原帖所说的“全盘扫描”，还缺少严格的技术证据。豆包工作扫描几个已知的Agent目录，与遍历整块硬盘上的所有文件，不是一回事。作者展示的另一张截图中，豆包工作给出的解释是：Skill的发现和列表展示发生在本地，不会批量上传；只有对话中真正调用某个Skill时，系统才会读取完整的SKILL.md，把它放进对话上下文，发送给模型服务器推理。从技术角度说，这套解释是说得通的。云端模型要按照Skill工作，当然需要看到Skill指令，就像用户在聊天框里粘贴一段文字一样。因此，“豆包工作扒光隐私”这个结论超出了现有证据。但帽子扣得太大，不代表帽子下面空无一物：未经提示读取和导入其他Agent的Skill，本身就是一个需要解释的产品行为。Agent等应用软件对磁盘操作，并不困难很多人的第一个疑问是：一个App扫描了我的文件，操作系统不需要弹窗申请授权吗？如果你熟悉安卓和iOS的授权机制，这个答案多少有点反常识：大部分时候，桌面系统不会为每一次普通文件读取都弹窗。Windows主要依靠账户的访问令牌和文件ACL，也就是访问控制列表，判断一个程序能不能打开文件。程序由当前用户启动，通常也就继承了这个用户的权限。只要ACL允许，系统便会把文件句柄交给程序，不需要每打开一个文件都弹窗询问。macOS在传统文件权限之外，又增加了一层TCC，全称可理解为Transparency Consent and Control，也就是“透明度、用户同意和控制”。它专门管理摄像头、麦克风、照片、通讯录等隐私资源，也会保护桌面、文稿、下载、邮件等特定位置。App第一次访问这些受保护资源时，系统可能弹窗询问；想要获得Full Disk Access，也就是完全磁盘访问，更需要用户单独开启。但TCC并不是给用户目录里的每个文件夹都站一个保安。像.codex/skills、.claude/skills这样的隐藏目录，如果不在桌面、文稿、下载等受保护位置，又没有受到其他文件权限限制，App仍然可能直接读取。我们总结一下：从纯技术角度看，豆包工作不需要额外向操作系统申请一次“Skill目录读取权”，并不奇怪。豆包工作客服说对的那一半：Agent确实在互相“偷家”按照原作者的截图，豆包工作把这种做法解释成“行业通用规则”。这句话不能直接等同于“大家都可以不问就搬”，但它确实说中了一半现实。现在的Agent产品，确实在积极读取和迁移其他产品留下的资产。更准确地说，行业正在把Skill、配置、记忆、MCP、工具权限和工作目录，看作可以迁移的用户工作环境。常见做法包括初始化时检测已知目录、在Import页面列出可导入来源，或者通过命令让用户主动发起迁移。原因也不复杂。用户换一个聊天机器人很容易，换一个已经调教了几个月的Agent却很麻烦。Skill、配置、记忆、MCP、工具权限和工作目录，共同构成了用户真正的使用环境。新平台如果能一键接过来，用户就不必重新调教一遍。就这个事而言，行业里也确实出现过一些过度热情的迁移设计：不只复制，还会建议归档旧目录；不只提示，还会把确认按钮做得比取消按钮更顺手。结果就是，新工具搬家完成了，旧工具的工作环境却被动改变。迁移功能一旦跨过“用户确认”这条线，就很容易从便利变成冒犯。所以，Agent互相“偷家”确实是行业现实。Skill正在成为一种可以携带的用户资产，也是各个平台都想接手的现成生产力。豆包工作没说的另一半：别人为什么通常会先问？行业里普遍存在迁移功能，却不等于大家都直接复制。一些偏开源路线的工具会在初始化时检查已知目录，发现其他Agent后询问用户是否迁移。更重视合规和企业客户的商用Agent，则通常会把导入流程放在明确的Import页面，或者等用户输入导入命令后，再开始扫描和展示。一个是自动检测后提示，一个是用户手动启动。路径不同，共同点却很明确：用户知晓，并主动同意这次迁移。类似的场景其实早就存在。浏览器收藏夹本质上也是用户电脑里的文件或者数据库，Edge有能力读取Chrome的收藏夹，Chrome同样可以找到其他浏览器的数据。操作系统一般不会替浏览器判断，这些收藏夹到底该不该搬走。所以浏览器自己补上了这一步：第一次启动时，明确告诉用户发现了哪些浏览器，询问是否导入收藏夹、历史记录或者密码。用户点了确认，它才开始搬。这并不是操作系统强迫浏览器弹出的窗口，而是产品主动把选择权留给用户。系统授予的是文件访问能力，用户决定的是这次具体的数据迁移。Skill比收藏夹还要复杂，里面可能放着自己开发的脚本、工作流程和测试内容。浏览器搬几个网址尚且会问，Agent搬走一套工作方法，当然更应该提前说一声。别以为欧美Agent们就一定更在乎用户感受，真金白银的法律压力往往才是设计决策的驱动因素。欧盟《电子隐私指令》第5条第3款规定：原则上，访问用户终端设备中已经存储的信息，需要在明确告知后取得同意；只有完成用户明确请求的服务所严格必需的访问，才可能适用例外。如果用户根本没有主动要求迁移Skill，“完成用户请求所必需”这条理由就很难站稳。如果Skill中包含姓名、客户信息、内部流程等个人数据，GDPR还会进一步要求处理透明、目的明确、范围最小，并落实默认数据保护。美国没有一部完全对应GDPR的统一联邦法律，但加州CCPA同样要求适用企业在收集个人信息之前说明类别和用途，并保证收集行为与目的合理、相称。美国FTC也长期把隐瞒数据处理、违反既有隐私承诺的做法纳入“不公平或欺骗性商业行为”的监管范围。当然，这些法律不能直接推出“豆包工作这次必然违法”。产品适用哪个国家的法律、本地扫描是否构成特定法律意义上的收集、Skill中有没有个人信息，都需要具体判断。但它们足以解释，为什么国际产品宁愿多做一个Import页面，也不愿直接搬走。对用户多问一句，成本很低；对公司里的法务和合规部门来说，却能减少上线以后的大麻烦。GDPR的处罚成本，足够让任何一家严肃公司认真对待。批量上传的可能性不大，可自研Skill仍然不能随便搬稍微阴暗一点说，人看到了一个错误以后，会不自觉地怀疑是不是还存在其他错误。在这里也一样，很多人会追问：它没问过我就偷偷复制，不会也没问过我就偷偷上传了吧？这种担心可以理解，但从利益和技术逻辑看，豆包工作批量上传所有Skill的必要性并不高。首先，很多通用Skill本来就是公开文件，平台完全可以从公开仓库取得，没有必要绕道用户电脑再拿一遍。其次，用户在豆包工作里提出了什么任务、调用了哪个Skill、怎样纠正结果，只要模型在云端运行，平台本来就能看到这些交互。为了了解豆包工作的使用情况，再去秘密打包本地Skill，多少有点多此一举。个体化Skill和调试数据确实可能有价值，但单个用户的一点修改并不是什么金矿。真正有训练价值的，往往是大规模的“任务—执行—失败—纠正—成功”轨迹。只有一份孤零零的SKILL.md，既缺少上下文，也不一定能在另一套环境中运行。不过，原作者特别强调，其中有一些不是从公开渠道下载的Skill，而是自己开发、尚未公开、仍在测试的私人Skill。这类Skill本质上已经接近一套未发布的软件和工作流。除了SKILL.md，里面还可能包含作者自己编写的脚本、工具调用方法、测试代码和业务规则。它有没有巨大的商业价值是一回事，是否允许另一个Agent读取和复制，则应该由开发者本人决定。即使豆包工作只在本地完成复制，也会让这些非公开Skill进入另一个Agent的发现和调用范围。按照豆包工作给出的解释，Skill一旦在对话中被实际调用，完整内容还会作为上下文发送给云端模型。因此，本地复制本身已经扩大了这些自研Skill可能被读取和传输的范围。目前没有证据证明豆包工作批量上传了Skill，这一点需要讲清楚。但没有批量上传的证据，也不能让未经同意复制非公开Skill变得合理。这里涉及的已经不是迁移一份公开资源，而是把别人尚未发布的开发成果直接搬进了自己的系统。快速响应值得肯定，如果提前把选择权交给客户则更好豆包工作的处理速度值得肯定。客服没有继续用“行业惯例”硬顶，而是迅速关闭功能，并明确表示后续改为用户自主选择的手动导入。至少从结果看，团队听进去了。但这里也留下了一个有意思的问题：既然功能可以迅速关闭，为什么一开始没有准备确认流程？豆包工作显然对这项功能设置了云端开关，也就是产品开发中常见的Feature Flag。客服决定关闭以后，后台只要把类似auto_import_skills的配置从开启改成关闭，客户端下一次获取配置时，便不再自动导入其他Agent的Skill。其实只要在On和Off之外增加一个导入推荐页面的配置选项，并将其设置为默认，就可以很好地平衡用户数据保护和产品体验。相信今天字节的小伙伴已经用上Trae来进行Vibe Coding了，这类页面连同基本逻辑，并不是很重的研发任务。把一次争议，变成建立信任的机会豆包工作这次没有被证明“扒光了用户隐私”。它的问题更具体，也更容易解决：一个原本有价值的迁移功能，省掉了用户应该拥有的那次确认。办公场景和普通家用软件终究不同。Agent接触的可能是合同、财务数据、代码、客户资料和内部流程。用户不会只关心功能好不好用，也会关心App看到了什么、复制了什么、哪些留在本地、哪些去了云端。哪怕用户自己不具有区分能力，这种担心依然值得重视。豆包工作能够快速关闭功能并承诺调整，说明团队具备回应用户的速度。下一步如果能把数据保护做得更透明，把检测、导入和云端同步变成清晰可选的流程，这次争议未必只是一笔负资产。对办公Agent来说，数据保护本身就是产品能力。边界交代得越清楚，用户越敢把重要工作交给它；信任感越强，产品进入个人办公和企业场景也会越顺利。操作系统允许App读取，只解决了技术问题。让用户知道并作出选择，解决的才是产品问题。豆包工作已经迈出了修正的一步，接下来只需要把后台拥有的操作权，在前台变成用户的知晓权。

豆包工作扒光你的隐私？别急着扣帽子，这事儿不简单

📌 概要