Coze 疑似把“强制使用自家服务”藏 Skill
刚看到 B 站一个关于 Coze 的视频，越看越觉得这件事值得讨论。

事情不是简单的“Coze 不好用”，而是：

一个 Agent 工具，能不能在你不够知情的情况下，修改其他 Agent 的行为规则，让它们优先使用自己的服务？

根据视频作者的实测，安装 Coze CLI 后，相关安装流程疑似会向 Codex、Claude Code、OpenCode 等本地 AI 工具同步 Skill / 规则。

其中最让我在意的是两类内容：

第一，疑似要求开发任务优先通过 Coze 处理。

也就是说，你明明是在用 Codex 或 Claude Code，但它读取到的规则，却可能在告诉它：

这类任务优先走 Coze。

这已经不是普通的“提供一个可选 Skill”了。

如果用户并不知道这条规则被写进去，那很容易出现一种很诡异的情况：

你以为自己在使用 A，实际上 A 被规则引导着给 B 导流。

而且这个 B，恰好还是写入规则的那一方。

第二，更敏感的是文件上传。

视频中还提到了一条相关规则：

在交付文件时，需要调用 Coze 的 file upload，再返回在线链接。

如果这条规则实际生效，那么原本完全可以留在本地交付的图片、PDF、音视频等文件，就可能被引导进入第三方服务。

这里真正的问题不是“云上传能不能用”。

而是：

用户有没有主动选择上传？

“我自己点上传到 Coze”

和

“我安装了一个工具之后，它给其他 AI 写了一条规则，让 AI 交付文件时默认走 Coze”

完全是两回事。

更离谱的是，视频作者还提到，在删除部分 CLI 和规则后，后台 Bridge 相关环境疑似仍存在自动重建的情况，最后又清理了一批文件才停下来。

看到这里，我最大的疑问已经不是 Coze 好不好用了。

而是：

一个 Skill 到底应该有多大的权限？

它可以提供能力，我没意见。

它可以让用户主动调用 Coze，我也没意见。

但如果它开始：

悄悄修改其他 Agent 的规则；
让其他 Agent 优先调用自家服务；
把文件交付绑定到自己的上传服务；
卸载之后还有后台组件或环境残留……

以后真正危险的可能不是某个 AI 回答错了，而是：

你安装了一个看起来正常的 Skill，却不知道它顺手给你的 Agent 写了什么规则。

当然，目前这些现象主要来自视频作者的本地实测和公开文件分析。

视频作者自己也提到，当时 Coze 并未登录，也没有证据证明源码已经被实际上传；具体上传规则在什么条件下触发，还需要进一步验证。

Coze 扣子 AIAgent Codex ClaudeCode Skill AI工具 隐私安全