🌐 官方网址:
https://github.com/magicpsyche/RedNote-Agent
(RedNote-Agent 为开源项目,无官方托管的在线体验站。访问 GitHub 仓库获取源码后,按文档配置模型 API 并启动 Next.js 应用,即可在本地浏览器中使用完整的输入、画布编辑和导出功能)
📌 工具简介
RedNote-Agent 是一款面向小红书内容运营及电商场景的开源“文案 + 生图 + 排版一体化” Agent,由开发者 magicpsyche 于 2026 年初开源。它的设计目标不是做一个单点的文案生成器或 AI 绘图工具,而是把一篇小红书笔记从“策划”到“成图”的完整链路塞进同一个工作流:用户输入产品信息和语气要求,Agent 自动生成结构化文案并附带 Seedream 生图提示词,调用模型产出背景图,再依据文案和背景图生成可拖拽编辑的排版画布,最终导出 1080×1440 的小红书规格图片。技术栈采用 Next.js APP Router 前后端一体,默认文案模型为豆包 1.8,默认生图模型为豆包 Seedream 4.5,前端提供画布式编辑和图层控制,后端通过 Server Actions 串联各生成步骤。项目在 2026 年初的“国产多模型实战 PK 大赛”中以 74.52 分获得关注,定位清晰:对个人创作者是一台“创意发动机”,对品牌团队则试图把文案、美工、主管三人反复拉锯的流程压缩为一人一键完成。
⚡ 主要功能
- 结构化文案与生图提示词同步生成:输入产品信息和语气要求后,LLM 返回结构化的 CopyResult,其中直接携带专为 Seedream 准备的中文生图提示词,文案和视觉指令在同一个步骤中产出,避免了“先写文案、再想配图提示词”的二次转换损耗
- Seedream 高质量背景图生成:使用豆包 Seedream 4.5 生成 2304×3072 的高分辨率背景图,提示词中强制包含留白描述和负向约束(排除文字、水印、低质量内容),为后续排版预留可用的文本区域
- AI 排版画布与可视化编辑:依据文案和背景图自动生成排版配置,前端以画布形式渲染,文本图层支持拖拽位置、编辑内容和调整层级(zIndex),用户可以在 AI 生成的基础上做精细的视觉调整,而不是只能接受一个不可编辑的成品
- 一键导出小红书规格图片:通过 html-to-image 导出 1080×1440 的逻辑尺寸图片,导出前会强制恢复画布尺寸、等待字体加载并内联背景,避免跨域图片导致的画布污染和导出失败
- 前后端一体,部署即可用:Next.js App Router 提供完整的输入表单、生成状态提示、画布编辑和预览界面,后端 Server Actions 串联文案生成、生图和排版三个核心步骤,不需要额外拼接多个服务
- 默认模型开箱配置:默认文案模型为 bytedance/doubao-1.8,生图端为 bytedance/doubao-seedream-4.5,与火山引擎生态衔接顺畅,减少了模型选型和接入的决策成本
- 分步 Action 与流式状态反馈:生成过程按步骤拆分为独立的 Action,前端可以分阶段展示进度和状态,异常时会清理背景预览并设置错误态,而不是让用户面对一个黑盒等待
- 面向电商商品卡片批量生成的潜力:项目定位明确提及“小红书及电商商品卡片批量生成”,其结构化输入和自动化链路适合需要批量产出商品笔记草稿的场景,而非仅限单篇精品笔记
💰 价格信息
RedNote-Agent 本身完全开源免费,不收取软件授权费或订阅费。实际使用成本来自两个层面:一是运行 Next.js 应用所需的服务器或本地计算资源;二是调用文案模型和 Seedream 生图模型产生的 API 费用。如果使用默认的豆包系列模型,按火山引擎的 token 和出图单价计费;如果替换为其他 OpenAI 兼容模型,则按对应厂商的价格执行。据社区讨论的参考数据,轻量使用时租用云平台的月成本约在 50 元至 200 元区间,重度高频使用可能达到上千元,具体取决于生成频率和模型选择。项目本身没有内置的免费额度或在线体验站,所有成本都需要用户自行通过 API 渠道承担。对于有技术能力自托管、且生成量可控的个人或小团队,这种“开源软件免费 + 按量支付模型费用”的模式比订阅制 SaaS 更灵活,但需要用户自己对预算和消耗节奏负责。
👥 适合人群
有前端或全栈能力、愿意自行部署和维护 Next.js 应用的技术型小红书创作者和独立开发者;希望把“文案—配图—排版”三个环节合并为一条自动化流水线、减少在多个工具之间搬运素材的个人创作者和小团队;需要批量产出商品笔记草稿、对单篇的精细度要求可以适当妥协的电商运营和品牌内容团队;以及想研究“Agent 如何串联多模态生成与排版编辑”这一工作流的技术爱好者和 AI 应用开发者。RedNote-Agent 尤其适合“有一定技术底子、追求流程闭环和可定制性、不介意自己承担 API 成本”的用户。如果核心诉求是零部署、打开网页即用的轻量工具,或者完全不具备任何开发环境配置能力,它的使用门槛会成为实际障碍;如果只需要单点文案或单张配图,专用的写作或绘图工具可能更直接。
✅ 优点
- 真正实现了“文案—生图—排版”的端到端闭环,而不是三个独立工具的松散拼接:LLM 生成的文案直接携带生图提示词,生图结果直接进入排版画布,数据流在系统内部自然流转,减少了人工在环节之间复制粘贴和格式转换的工作量
- 排版阶段提供了可拖拽、可编辑的画布,而不是只能导出一张不可修改的成品图:文本图层的位置、内容和层级都可以调整,保留了人工干预和精修的空间,这在“AI 生成即终稿”的同类工具中是一个务实的差异化设计
- 默认模型选型务实:豆包 1.8 负责结构化文案,Seedream 4.5 负责高质量背景图,两者在中文理解和出图质量上有基础保障,且与火山引擎生态的衔接降低了模型接入的摩擦
- 开源 + 可自托管,数据和流程完全自主:生成记录、图片和配置都保存在用户自己的环境中,不被第三方 SaaS 锁定,适合对内容隐私和流程可控性有要求的用户
- 导出环节处理了 canvas 跨域和字体加载等工程细节,避免了“生成看起来没问题、导出就失败”的常见坑,产品在技术完成度上超出了许多开源 demo 的水平
- 项目定位明确指向“小红书内容运营及电商”,对商品卡片批量生成有潜在的适配性,不是泛化的通用工具,场景聚焦带来了功能设计上的针对性
- 在国产多模型实战 PK 大赛中获得分数和曝光,代码全部开源可审计,对于愿意自己动手的技术用户来说,透明度和可修改性都较高
⚠️ 缺点
- 没有官方托管的在线版本,部署门槛是最大的实际障碍:需要克隆仓库、配置 Node.js/Next.js 环境、填入模型 API 密钥、启动服务,对非技术用户来说这不是“下载即用”的工具,而是一个需要开发和运维能力才能跑起来的项目
- 视觉策略阶段在技术报告中标注为“暂缓”,意味着排版审美和视觉决策的自动化程度可能还不完整,生成的排版结果仍需人工做一轮审美判断和调整,不能指望它独立产出“设计感达标”的成品
- 文案和配图的质量高度依赖所接入的模型,默认豆包模型在中文场景下有基础保障,但如果用户为了控制成本而选用较弱的模型,生成结果的可用性会明显下降,需要在效果和费用之间做权衡
- 作为个人开源项目,文档完备性、异常处理的鲁棒性和长期维护的稳定性无法与商业产品相比,遇到环境配置或 API 兼容性问题时,主要依赖自行排查和社区讨论
- 成本需要用户自己全程承担和监控:没有免费额度,每一次文案生成和出图都会产生 API 费用,高频使用或调试过程中的反复生成可能导致费用超出预期,需要用户对消耗节奏有主动管理意识
- 如果核心需求只是偶尔写一两篇笔记、做几张图,部署和维护一个 Next.js 应用的投入产出比并不高,轻量级的在线工具或直接使用豆包/Seedream 的原生界面可能更省事
- 项目聚焦小红书单平台,如果内容需要分发到抖音、公众号或其他渠道,排版规格和文案风格的适配需要额外处理,不具备跨平台的多格式输出能力
💡 使用技巧
- 部署前先明确自己的技术边界:如果你不熟悉 Node.js 环境配置和 API 密钥管理,建议先评估是否有技术伙伴可以协助,或者先用豆包和 Seedream 的原生界面手动走一遍“文案→生图→排版”的流程,确认这个工作流对你的实际价值后,再决定是否投入时间部署自动化版本
- 首次运行时,先用一个简单的产品信息跑通完整链路:输入 → 文案生成 → 背景图生成 → 画布渲染 → 导出,确认环境配置、API 连通性和导出功能都正常,再逐步增加输入复杂度和生成频率
- 在输入产品信息时,除了卖点,尽量把目标人群、语气风格和必须出现的关键词写清楚。LLM 生成的文案和生图提示词都会受到这些输入的直接影响,信息越具体,后续环节的返工越少
- 生图环节的提示词已经内置了留白和负向约束,但如果你对背景风格有特定要求(如“暖色调”“极简”“有生活感”),可以在输入阶段或生成后通过调整提示词来引导,而不是等到排版阶段才发现背景与文案不搭
- 排版画布的编辑能力是 RedNote-Agent 相比“一键出图”工具的关键优势:不要直接导出 AI 生成的初始布局,花几分钟调整文本图层的位置、字号和层级,尤其是标题和关键卖点的可读性,这一步对最终图片的点击率影响很大
- 如果主要用途是批量测试选题或商品卡片,建议控制单次生成的页数和复杂度,先用较低成本的模型组合跑量筛选方向,再对胜出的方向用更强的模型做精细生成,避免在调试和探索阶段消耗过多 API 费用
- 对导出的图片,在发布前做一轮人工检查:文案的事实准确性、图片中是否出现意外的文字或畸变、品牌元素是否清晰,AI 生成的内容在正式使用前仍然需要 accountable 的人工确认
- 如果团队中有多人使用,可以考虑将部署实例放在共享的服务器上,但需要注意 API 密钥和生成记录的管理权限,避免不同成员的消耗混在一起难以追溯










暂无评论内容