技术知识库 · 工具评测 · · 国科智飞 Gavin
Easel：社媒内容 Agent 的五层工作流
浙大与北大实验室开源的内容 Agent 工作台：112 个技能、六维账号画像、发布归因闭环。亮点和红线都很清楚。
Easel 是浙江大学 ZJU-REAL Lab 与北京大学 OpenDCAI Lab 联合开源的社媒内容 Agent 工作台，Apache-2.0 协议，2026 年 8 月底才开源。它基于 OpenClaw 构建，把 112 个内容技能组织成「发现 → 策划 → 创作 → 发布 → 归因」五层工作流，目标是从一个想法直接产出可发布的图文与音视频，覆盖小红书、抖音、快手、知乎、B站、微信视频号六个平台。
需要先说明它不是什么：它不是提示词合集，也不是模板库。仓库里既有 Python CLI，也有 FastAPI + React 的 Web 工作台（默认 7860 端口），技能大多带可运行的脚本，产物按项目归档在本地，不是聊完就散。
从目录结构就能看出它的野心。 根目录分成几块：easel/ 是 Python CLI（chat、web、skill、doctor 等命令），web/ 是 FastAPI 后端加 React 工作台，skills/ 按五层组织技能并附带跨技能脚本，profiles/ 每个账号画像一个目录，outputs/ 归档内容项目与最终产物，openclaw/ 放隔离的 profile 与 gateway 同步脚本。判断一个 Agent 项目是认真做工程还是演示壳子，看目录结构往往比看 README 更快。
能力与亮点
五层工作流是完整的。 发现层做热搜聚合、垂类趋势、内容缺口、竞品与跨平台差异分析；策划层做账号定位、受众画像、选题矩阵评分、系列规划、分镜脚本与内容日历；创作层覆盖文案、卡片、海报、信息图、TTS、配音、字幕、剪辑、AI 视频等；发布层有质量门禁、敏感与版权检查、多平台格式适配；归因层回收播放与互动数据、做评论洞察和内容复盘。
账号画像是差异化的核心。 每个账号有一份独立的六维画像——定位、风格、受众、平台、偏好红线、长期记忆。输出不是一次性抽卡，而是随使用越来越贴合真实账号。
归因回流画像，形成闭环。 这是它最值得借鉴的设计：发布后回收数据，把有效的选题结构和表达沉淀回画像，下一次创作自动带上。所谓数据资产飞轮，在内容侧的具体实现就是这个动作。
技能是真干活的。 图片、卡片、配音、字幕、剪辑、发布等技能都配有可运行脚本，成品落进 outputs/ 目录，素材、中间文件、元数据按项目保存，可以安全重试和修改。
一份素材多平台形态。 母版内容按平台格式与字数改写为小红书卡片、短视频脚本、知乎长文等，不用为每个平台从头再来。六个平台不是平均用力，每个平台的格式规则都写进了对应技能里，这也是「一份母版多平台」能成立的前提。
隔离做得比较克制。 Easel 使用独立的 OpenClaw profile，不会覆盖本机已有的 OpenClaw 配置，Apache-2.0 协议可商用。
局限与坑
项目极新，社区数据有限。 2026 年 8 月底开源，属于典型的早期项目，接口和行为都可能变化，不适合直接压在生产流程上。
上手门槛不低。 重度依赖 OpenClaw 和 Anthropic 的模型 Key，需要 Node 22.19 与 Python 3.10+；要跑媒体能力还得装 FFmpeg 和 Playwright Chromium，部分媒体能力依赖外部服务。
平台风控是必须正视的红线。 官方文档明确警告：部分平台（尤其小红书）可能检测自动化行为，导致验证、限流甚至风控；建议只用于预览和草稿，最终由人工确认后手动发布。任何批量自动发布方案都不该绕过这条提醒——账号安全比省下来的时间值钱。
112 个技能是广度，不是质量保证。 技能数量多，但成片质量取决于背后的模型和外部服务，把它当「一键爆款工厂」会失望。它更像一个把流程跑通的工作台，判断和把关仍然在人。
归因闭环的实际效果取决于平台。 回收数据依赖各平台的开放程度，能拿到的粒度不同，闭环的成色要按平台分别评估，不要默认每个渠道都有同样的数据反馈。
学术背景带来的一类特殊内容。 项目方有研究背景，仓库里附了论文解读卡、小说、生活分享、视频成片等真实产物，做知识类账号的人可以顺带用它的论文解读能力。这也从侧面说明：它的强项是把素材加工成内容形态，不是凭空生成爆款选题。
适用场景
- 有技术能力的内容团队、工作室，需要把内容生产流水线化；
- 希望内容资产本地归档、自己掌控数据的人；
- 已经在用 OpenClaw，想升级成完整内容工作台的团队；
- 想把「选题—创作—复盘」固化成可复用流程的运营负责人。
不适合：完全不碰命令行的个人用户；对账号风控零容忍、不接受任何自动化风险的品牌方；没有模型 API 预算的团队。
选型建议
先只启用发现与策划两层。这两层风险最低、收益最直接——选题矩阵和竞品分析本来就要花时间，让 Agent 先跑起来，看输出质量是否及格。
发布环节坚持「Agent 产草稿、人工来确认」，把官方警告当硬约束执行。媒体能力按需安装，先用文字和卡片类技能验证价值，再决定要不要引入 FFmpeg 与 Playwright 这套更重的依赖。
最后，把仓库的更新节奏和 issue 响应情况观察两周。新项目最怕的不是功能少，而是方向变。等它的画像系统和归因闭环被更多用户验证之后，再考虑接入真实账号的长期内容计划。把它的五层工作流当成一套可裁剪的流水线，而不是必须全开的系统。