Easel火了一个月：AI发小红书，卡在风控上
alitrack约 6 分钟9 月的中文 AI 圈，「浙大开源社媒 Agent Easel」刷过一波屏：微博、知乎、B 站同天出现种草文，登上 GitHub Trending 日榜，一个月攒下 2574 颗星。它宣称 AI 帮你发现热点、写文案、做图做视频，然后一键发到小红书、抖音、B 站、知乎、公众号等七个平台。
我把源码 clone 下来通读了一遍，顺手跑了它自带的检测脚本。一句话结论：Easel 的发布脚本是真货，但小红书自动发布这一关，官方自己都建议人工确认。
它真正能稳定干的事，是「AI 把内容和图都备好，你扫一眼再点确认」的半自动模式。下面把拆开看到的细节讲清楚。
● ● ●
先说它到底是什么
很多人以为 Easel 是一个完整的 AI Agent，拆开看发现它更像一个高水平的组装层：执行引擎用的是 OpenClaw（一个 39 万星的开源 Agent 网关），自己写的是三块东西——一个 Python 命令行工具、一个 FastAPI 网页工作台、114 个社媒技能。
这个组装水平相当高。举两个例子：网页对话有两条通路（直连常驻网关和拉起命令行），两条通路写不同的话记录文件，中途切换会静默丢光上下文，于是它按会话锁死通路，注释里把踩坑过程写得明明白白；再比如所有发布脚本在真正发出去之前，必须过一道内容安全闸门——API Key、内网地址这类敏感信息直接拦截退出，且这道闸门做进了 CI 检查，写代码绕不过去。
顺带一提背景：这是浙大 REAL Lab 联合北大 OpenDCAI Lab 的研究落地项目，主力作者一个人贡献了约 97 次提交，提交邮箱后缀是 xiaohongshu.com——这也解释了为什么七个平台里，小红书的链路做得最深。
● ● ●
发小红书那一关，风控是真的
README 的使用提示第一条就写着：谨慎自动发布到小红书，平台可能检测自动化操作，存在验证、限流或账号风控风险。
源码里的细节比 README 更直白：
无头的 Chromium 浏览器会被小红书识别，报错误码 300012。Easel 的应对是换用 CloakBrowser 内核，并要求干净的家庭宽带 IP——机房 IP 或代理出口会在登录前就被拦住。 反检测手段是常规款：关掉浏览器的自动化特征、逐字符打字模拟真人、锁定中文环境、登录态持久化。对付平台的专业风控，够不够很难说。 底层脚本移植自开源项目 xiaohongshu-mcp（1.6 万星），上游作者自称跑了一年没封号。这个说法属于 go-rod 版本的自述，移植成 Playwright 之后行为是否等价，没有验证记录。 最关键的一条：Easel 的小红书技能里写死了「发布前必须跑一次 dry-run 预演，给用户看最终标题、正文和图片，确认后才真发」。真发布的命令需要显式加 --exec参数。
所以「AI 自动发小红书」的实际形态是：AI 登录你的账号、备好内容、走完预演，最后一步由人点确认。卡点不在 Easel，在小红书的风控现状——把它当无人值守的发布机器用，封号风险自己扛。
● ● ●
七个平台，七条路
拆开发布脚本，七个平台的技术路线各不相同，这张表是全文最值钱的部分：
有个反直觉的发现：七个平台里最稳的反而是公众号。它绕开了官方 API 的 AppID、密钥和 IP 白名单要求，管理员扫码登录后台，直接用后台网页接口传封面、传正文图片、建草稿。整个流程只创建草稿，不自动群发——平台容忍度高，账号风险接近零。
● ● ●
114 个技能，一半是提示词
Easel 的招牌是 114 个技能，README 说「技能是真执行，不是功能清单」。逐个数了一遍，这句话对一半：
发布和媒体制作类是真脚本：共享脚本层 49 个 Python 文件、两万三千行，小红书发布脚本一个文件就 1064 行，普遍带离线自检。我实测跑了四个自检，全部通过。 约 40 个策略分析类技能（选题评估、竞品分析、内容矩阵之类）是纯提示词：目录里只有一份 SKILL.md，没有任何脚本，产出质量完全取决于你接的哪个大模型。
这不算造假——技能文件里老老实实登记了每个技能的来源仓库，小红书脚本移植自谁、排版技能买断自谁都写得清楚。但如果你冲着「114 个可执行技能」去装它，预期要先砍半。
● ● ●
星数是真热度，坑也是真坑
翻完全部 issue 和 PR，这个项目的口碑画像很立体：
23 个 issue 里 48% 是安装问题。Windows 的 PowerShell 5.1 直接报错，macOS 有三处静默失败，「装的时候碰到无数 bug」是原话。 394 个 fork 对 2574 颗星，比例 15%，远高于一般项目。翻 fork 用户的主页会发现一个模式：装不上，fork 一份自己改安装脚本，顺便提个带补丁的 PR。星数和 fork 数里有一块是「自救现场」。 有媒体实测后写了一篇《我花一下午装了个开源 AI 神器，最后发现核心功能是坏的》，指向的 bug（多行指令被换行符截断）在 issue 区能对上号，官方后续版本修掉了。 微信交流群满 200 人进不去了，有用户在 issue 里求助。
热度是真的，用户是真的，坑也是真的。34 天、139 次提交、四个版本，这是一个高速迭代中的早期项目，不是一个打磨完的成品。
● ● ●
普通人该怎么用它
两个建议。
第一，判断这类「一个月几千星」的开源项目，看 issue 结构比看星数准。星数可以被投放脉冲推高，issue 区骗不了人：安装类 issue 占比高说明工程粗糙，带补丁的 PR 多说明真有人在生产环境用，功能请求少说明大家是来干活的、不是来许愿的。Easel 三条全占，画像就是一个「方向被验证、工程在早期」的项目。
第二，对已经有内容工作流的人，拆资产比整体部署划算。Easel 是 Apache 2.0 协议，那几个发布脚本可以单独抠出来用：小红书发布脚本自带预演和自检，公众号扫码建草稿的通道对被 IP 白名单卡住的人来说是条新路，七平台的字数和画幅约束表（小红书标题 20 字、B 站 80 字、公众号首图 2.35:1）拿来就能查。整体部署的成本别忘了算：一个大模型 API 的 key 是硬门槛，全功能还要再配视频和语音的 API，这是一笔真实的月度开销。
一句话收尾：Easel 把「AI 社媒运营」这个方向做到了开源世界里目前最完整的一档，但「完整」和「能无人值守」是两回事——它最诚实的地方，恰恰是 README 里那句「谨慎自动发布到小红书」。
● ● ●
参考来源
Easel 仓库：https://github.com/ZJU-REAL/Easel Easel 项目页：https://zju-real.github.io/Easel/ README 使用提示（小红书风控警告）：https://github.com/ZJU-REAL/Easel/blob/main/README.md 小红书发布脚本上游 xiaohongshu-mcp：https://github.com/xpzouying/xiaohongshu-mcp OpenClaw（Easel 的执行引擎）：https://github.com/openclaw/openclaw