← 返回周目标完成情况

替用户执行操作的合规与安全风险：以小红书为例

〇、结论先行

  1. 「替用户执行」本身并不必然高风险。 风险集中在三件事叠在一起的时候：用非官方通道接入（托管密码或 cookie、模拟浏览器操作、逆向接口）、做对外发布或和别人互动的动作、以真人的名义呈现。三者只要去掉一个，风险就会明显下降。
  2. v1 把「账号被封」「平台被起诉」都评为高风险，这里修正为有条件成立：只有在「全量托管、模拟真人」的形态下才是高。偶尔代发会被警告或限流，不至于封号；民事诉讼的先例集中在抓数据、搬运和洗稿，单纯给自己的账号发帖，没找到被诉的先例。维持高风险的只有一项：平台托管用户账号凭证。
  3. 两个场景差别很大。直播运营里，商品、订单、售后这些操作有成熟的官方授权通道（小红书电商开放平台），可以合规地替用户执行；风险集中在弹幕自动互动和 AI 主播身份这两处。账号运营里，最核心的「发笔记」反而还没有官方接口（write_notes 规划中），现成工具全都走非官方通道。
  4. 产品层面建议定五条红线（第五节），在这些红线之内，「替用户执行」可以做。

一、判断框架：用三个问题给任何一个执行动作定级

「替用户执行」是指平台 Agent 在第三方平台上以用户身份完成写操作。每个执行动作的风险，由三个相互独立的问题决定：

问题 风险由低到高 为什么决定风险
Q1 通道：用什么方式接入用户账号？ 官方授权接口（OAuth、服务商授权）＜ 用户在官方 App 里自己点确认 ＜ 托管凭证＋模拟浏览器操作 ＜ 逆向协议、绕过签名或风控 决定是否违反平台协议，是否构成不正当竞争乃至刑事风险，以及平台要不要背负凭证安全的责任
Q2 动作：替用户做什么？ 生成内容 ＜ 读取用户自己的数据 ＜ 发布内容 ＜ 和他人互动（评论、私信、弹幕）＜ 交易，以及处理第三方的个人信息（订单、售后） 决定影响面：只影响用户自己，还是会影响平台上其他人；会不会触发广告、电商、个人信息方面的监管
Q3 呈现：对外看起来是谁做的？ 声明了 AI ＜ 人确认后发布 ＜ 全自动、以真人身份呈现 现行规则的打击重点都是「AI 冒充真人」，如实声明本身就能大幅降低平台规则风险

下面第二节逐题给出证据，第三节把框架套到两个场景上。

二、证据与推论

2.1 Q1 通道：非官方通道违反协议是确定的；会不会升级为诉讼或刑事责任，取决于是否绕过防护

证据

推论

2.2 Q2 动作：互动类动作是平台的打击重点；交易类动作会牵出个人信息义务

证据

推论

2.3 Q3 呈现：如实声明 AI，能化解大部分平台规则风险

证据

推论

2.4 安全风险：与合规风险相互独立，主要由「Agent 手里有多大权限」决定

安全风险 何时出现 说明
凭证集中 托管密码或 cookie 拿到它就能完全接管用户账号，包括私信和改资料。按 GB/T 35273，口令属于个人敏感信息。平台成为撞库和内部人员作案的高价值目标；服务器从异地登录本身也容易触发风控、冻结账号。这是唯一一项不论规模大小都维持高风险的项目
令牌泄露 官方 OAuth 或服务商授权 权限受授权范围约束、可以撤销，风险可控。仍需加密存储、最小授权范围、到期刷新
提示注入 Agent 读取外部内容（评论、私信、弹幕、搜索结果），同时握有写权限 攻击者在评论或弹幕里埋一句指令，就可能诱导 Agent 发布违规内容或私信骚扰。直播弹幕自动回复是暴露面最大的形态：输入完全不可信，输出实时公开，没有人工复核的窗口（推断，非平台规则）
越权与追溯 Agent 自主多步执行 Agent 做了用户没让做的事。责任在法律上通常落在账号主体（即用户）身上，平台要有逐条的操作审计和撤回能力，才能厘清责任

三、场景分析

定级沿用第一节的三问。「现成工具」指开源或商用的、可以直接接入的方案。

3.1 账号运营（以教育类账号在小红书起号为例）

执行动作 现成工具或通道 Q1 / Q2 / Q3 定级 结论
选题、写稿、配图 任意大模型；团团自身 无需接入 / 生成 / 人确认后发布 低 可做。法定义务：AI 标识；推广内容遵守《广告法》（教育培训广告不得承诺效果）。注意：杭州互联网法院 2025-02 判决，一款提供「小某书种草文案」「伪原创」功能的 AI 写作工具构成不正当竞争，赔偿 20 万元（澎湃）。所以产品不能做洗稿和伪原创
发布笔记 xiaohongshu-mcp、post-to-xhs Skill 等，均为非官方 托管凭证＋模拟浏览器 / 发布 / 全自动 高（全量托管）；中（偶尔代发） C 端不用。用公司自有账号做演示可以，但要写明不能上线
发布笔记 分享 SDK 预填内容，或「复制文案＋下载图片」发布包 用户在官方 App 里点确认 / 发布 / 声明 AI ＋人确认 低 10 月只能做发布包。分享 SDK 官网已暂停接入，且不再预填标题和正文（见 3.3）；发布包随时能做
发布笔记 官方 OAuth write_notes 官方授权 / 发布 / 声明 AI 低 规划中。通过商务申请「特定场景」，拿到了才有合规的全自动
回复评论、私信 MCP 工具包里的互动 skill（非官方） 托管凭证 / 互动 / 模拟真人 高 不做。正好是 AI 托管公告点名的行为
回复私信 聚光「三方客服工具」官方授权（企业号和员工号，说明，二手来源，待核实） 官方授权 / 互动 / 需声明 中 只对企业号开放，需要商业授权。留作以后的选项
数据复盘 MCP 工具抓取主页和笔记数据（非官方） 模拟浏览器 / 读取 中 只读自己的数据，风险比抓取别人的低，但仍违反协议。有大规模、绕过防护时，可类比蝉妈妈案（判赔 490 万元，南方+）
数据复盘 用户上传截图或直接报数（陪跑原型的现行做法）；官方 read_notes、user_profile 规划中 用户自己提供 / 读取 低 可做

账号运营小结：可以替用户执行的部分是「生成」和「准备好发布包，由用户自己在小红书里发」。真正的全自动发布要等官方 write_notes。互动类动作不应该做全自动。

3.2 直播运营（以直播电商为例）

合作方的「AI 直播团队」由 9 个员工组成：主播定位、主题策划、选品、排品、脚本、预告物料、播前调试、复盘、售后。按现有设计，这些员工都是和用户多轮对话、由用户确认的形态，本身并不在用户账号上执行操作。下表评估的是「如果要让它们替用户执行」时，各动作的风险。

执行动作 现成工具或通道 Q1 / Q2 / Q3 定级 结论
主播定位、主题策划、选品、排品、脚本 9 个员工（ndclaw 专家） 无需接入 / 生成 / 人确认后执行 低 可做。商品信息要真实，宣传话术遵守《广告法》和《直播电商监督管理办法》
预告物料（发预告笔记） 同 3.1「发布笔记」 同上 同上 同 3.1：10 月做发布包，由用户确认发布
商品上架、订单、售后处理 小红书电商开放平台，服务商模式，商家在千帆 App 扫码授权（授权流程） 官方授权 / 交易＋第三方个人信息 / 商家身份 中（主要是数据合规） 可以合规地替用户执行。但要做到：签开发者协议、申请对应类目的接口权限、按要求处理加密数据；买家个人信息遵循最小必要，不原样送进大模型；和商家约定委托处理的条款
AI 数字人代播 各类商用数字人直播工具 官方开播 / 对外呈现 / 必须声明 中 合法的前提是：显著、持续地标识 AI（《直播电商监督管理办法》第三十七条），开启小红书「AI 声明」，并且不冒用他人形象（身份造假会直接关停、禁播）。画面或声音质量不达标会被限流。责任在直播间运营者，也就是用户；但平台提供数字人能力，自身也要满足标识办法规定的服务提供者义务
直播中场控（弹幕自动回复、自动欢迎和答谢） 第三方「直播助手」类外挂 非官方 / 实时互动 / 模拟真人 高 不做。抖音群控、直播外挂工具已有禁令和刑事判例；而且这是提示注入暴露面最大的形态
复盘 用户上传截图（现行做法）；千帆后台导出 用户自己提供 / 读取 低 可做

直播运营小结：电商类操作（商品、订单、售后）有官方通道，是「替用户执行」最适合先做的地方，代价是数据合规的工作量。直播中的实时互动和 AI 主播身份是两个红区：前者不做，后者必须声明 AI。

3.3 补充：分享 SDK 的接入方式与现状（2026-10-10）

依据小红书分享开放平台（agora.xiaohongshu.com）的官方文档。官网是前端渲染的页面，文档正文取自它的前端代码（main.2994670.js，最后修改 2026-07-07），2026-10-10 查阅。

接入方式：前端调用，唤起小红书 App，由用户在小红书里发布；服务端只负责签名。 分享 SDK 不是服务端接口，我方服务端碰不到发布这一步。

形态 谁来调用 服务端做什么
App SDK（Android、iOS、鸿蒙） 我方原生 App 调 SDK（Android 为 XhsShareSdk.shareNote），唤起小红书 App 不参与
JS SDK（H5 网页） 网页引入官方 JS 文件，前端调 xhs.share({ shareInfo, verifyConfig }) 唤起小红书 App；图片、视频必须是公网地址，不支持本地文件 加签两次：先用 appKey、appSecret 签名换 access_token（POST https://edith.xiaohongshu.com/api/sns/v1/ext/access/token，有效期不超过 24 小时，重复获取会让旧的失效，所以要在服务端集中缓存）；再用 access_token 为每次分享生成签名，连同 appKey、nonce、timestamp 返回前端

创业平台现在是网页，要接只能走 JS SDK。但眼下接不了，接上也只省几步：

  1. 官网已暂停接入：两种形态都要先在官网「快速接入」登记企业和应用，审核通过才拿到 appKey；官网的接入按钮现在显示「暂停接入」。2025-11 起已有开发者在接入文章下留言说申请停了（CSDN 评论区）。
  2. 不再预填文字：官方 JS SDK 文档开头写明「为维护平台内容生态健康，小红书分享SDK将不再支持自动填充标题、文案、话题等内容（图片和视频等媒体内容不受影响）」。接上以后，用户在小红书里仍要自己贴标题和正文；比起发布包，省掉的只是保存图片、打开小红书、挑图这几步。

所以 3.1 的「发布笔记」10 月只做发布包：平台备好标题、正文、话题和图片，用户一键复制文案、下载图片，自己打开小红书发，平台不接小红书的任何接口。代用户直接发笔记的官方接口 write_notes 仍是「规划中」（Scope 文档，2026-10-10 核对）。

四、对 v1 结论的修正

v1 结论 v2 结论 修正理由
用户账号被封：高 视情况而定：全量托管、模拟互动时为高；偶尔代发为中；官方通道或人确认＋声明 AI 时为低 AI 托管公告本身是分档处置的；只有「全量托管」和「用托管工具注册、发布、互动」才会封禁
违反用户协议：高 非官方通道：确定违反；官方通道：不涉及 风险由通道（Q1）决定，与「替用户执行」这个功能本身无关
平台被起诉：高 中；有逆向签名、绕过风控、批量多账号时升为高 能找到的先例集中在抓数据、搬运、洗稿；没找到单纯给自己账号发帖被诉的先例。但第十三条和抖音群控禁令说明，一旦规模化或绕过防护，风险就会上来
托管账号凭证：高 维持高 这是结构性风险，与规模无关
AI 内容标识：中，必做 维持，并扩展到直播（《直播电商监督管理办法》第三十七条） —
提示注入：中 对互动类动作上调为高，其他为中 弹幕和评论是完全不可信的输入，而输出实时公开
（v1 未覆盖） 新增：交易和售后带来第三方个人信息处理义务（中）；内容生成本身要避开洗稿和伪原创（中） 直播电商场景和 AI 写作工具案

五、产品红线建议

  1. 只走官方授权通道：不托管用户的密码或 cookie，不逆向签名，不绕过风控。官方没开放的动作，降级为「准备好结果，由用户在官方 App 里确认」。
  2. 对外发布默认要用户确认；互动类动作（评论、私信、弹幕）不做全自动。
  3. AI 标识全覆盖：生成内容加隐式标识，发布时提示用户勾选 AI 声明；直播使用 AI 时持续标识。
  4. 第三方个人信息最小化：订单和售后数据只用于履约，不原样进入模型上下文，留存审计记录，并和商家约定委托处理的条款。
  5. 不做洗稿、伪原创、批量多账号。

团团对接外部执行方时，建议在执行方登记里加两个字段：「通道类型」（官方授权、用户确认、非官方），以及「动作类型」（生成、读取、发布、互动、交易）。匹配时按第五节的红线过滤，标为「非官方」的执行方不对 C 端用户开放。

六、待核实